Developpez.com

Télécharger gratuitement le magazine des développeurs, le bimestriel des développeurs avec une sélection des meilleurs tutoriels

Modélisation relationnelle : Quelles sont les règles d'or pour concevoir un bon MCD ?

Le , par wafiwafi, Membre averti
on m'a été posée et j'aimerais avoir votre avis sur la réponse que j'ai fournie.
Quelles sont les règles d'or pour concevoir un bon MCD?
Ma réponse : On ne peut parler d'un bon MCD que si on évoque les applications qui vont l'accompagner et l'étude de la complexité du programme pour minimiser les lectures et écritures sur disques sans parler du problème de la recherche des objets dans le cas d'une grande quantité d'informations dans les bases...
Pour moi, une règle de base à respecter est de bien s'assurer que le modèle construit de façon bien réfléchie, répond au cahier des charges fixé au départ. Parler de règle d'or au stade d'un MCD me parait prématuré; en résumé, on ne peut juger un bon MCD qu'à partir de ce que vous voulez en faire par la suite.
En essayant de réduire les classes au maximum par exemple, cela voudrait il dire qu'on a amélioré le MCD ? pour moi, ce n'est pas forcement le cas. Certaines personnes le font de façon automatique main non réfléchie.
Des règles à respecter existent, elles ne sont pas d'or mais imposées pour respecter la construction.
A travers vos diverses expériences, vous pouvez agir. Qui sait peut être des règles d'or existent réellement à ce stade.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :




Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 11/09/2009 à 17:05
Citation Envoyé par CinePhil  Voir le message
... Identifiant de type entier non nul non signé et auto-incrémenté : 4 octets
Numéro d'immatriculation française : au moins 8 caractères pour les anciennes plaques et au moins 7 pour les nouvelles, sans les espaces dans les deux cas.
Numéro de sécu : 15 caractères sans les espaces.

L'argument selon lequel une clé primaire de type entier sera plus performante me laisse toujours songeur. En effet, il faudra sûrement un deuxième index pour assurer les recherches sur l'identifiant "métier" écarté au profit de la clé numérique. On aura donc deux index au lieu d'un.

Oû est le gain en performances ?

Mais là j'avoue m'éloigner du MCD pour tomber dans le MLD voire dans le MPD ...

L'argument sur la stabilité est beaucoup plus recevable.

Dans le cas de la plaque d'immatriculation, on pourra noter que les nouvelles règles ( AA-000-AA) correspondent bien à un identifiant stable puisque la plaque d'immatriculation est désormais affecté au véhicule jusqu'à sa destruction.
Avatar de CinePhil CinePhil - Modérateur https://www.developpez.com
le 11/09/2009 à 17:29
Je ne me lasse pas de redonner le lien vers le blog de SQLPro au sujet des clefs auto-incrémentées.

Je cite quelques passages :
Plus modestement, un bonne clef serait donc d’un coût négligeable, par exemple une valeur numérique entière, bien entendu unique, au moins au sein du modèle qu’elle représente et enfin attribuée une fois pour toute durant la vie entière de l’objet qu'elle identifie.

Il semble donc évident que l’utilisation d’une clef naturelle est une fort mauvaise idée ! Et par voie de conséquence, un bon vieux numéro fait parfaitement l’affaire pour la plupart des cas.

Ensuite côté performances...
N'oublions pas que cette clé primaire sera utilisée comme clé étrangère dans d'autres tables de la BDD. Et la joiture entre deux (ou plus) entiers est plus rapide que la jointure entre deux colonnes de type VARCHAR(n), surtout si n est supérieur à 4.

Alors certes, le système va chercher dans l'index I_V_Immat de la table Vehicule le numéro d'immatriculation du véhicule mais ensuite pour donner à travers les Réservations enregistrées la liste des Personnes qui ont emprunté le véhicule, les jointure se feront avec des entiers et non pas avec un numéro d'immatriculation à au moins 8 caractères (sans les espaces pour les anciennes plaques françaises).

A partir d'un certain nombre d'emprunts enregistrés, la différence de temps de traitemetn peut devenir sensible.
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 11/09/2009 à 17:55
Citation Envoyé par CinePhil  Voir le message
Je ne me lasse pas de redonner le lien vers le blog de SQLPro au sujet des ...

SQLPro, qui a des avis très tranchés sur tous ces sujets ne détient pas la vérité révélée et absolue ...

Moi j'ai tendance à dire ... ça dépend ...

Ensuite côté performances...
N'oublions pas que cette clé primaire sera utilisée comme clé étrangère dans d'autres tables de la BDD. Et la joiture entre deux (ou plus) entiers est plus rapide que la jointure entre deux colonnes de type VARCHAR(n), surtout si n est supérieur à 4.

L'argument sur les jointures est tout à fait recevable ...

Par contre j'évite absolument les clés primaires en VARCHAR ...
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 11/09/2009 à 18:32
Il y a un motif qui n'est pas valable de l'utilisation de clefs générées et ce quel que soit l'algorithme.

Il est important dans l'édition de logiciels, car souvent un éditeur à tendance à exposer une couche de paramètrages importante à l'utilisateur. L'utilisation de clefs auto-incrémentées gérée uniquement par le sgbd client pose de sérieux problèmes de standardisation et devient une vraie plaie.

En outre, le problème est aussi valable sur les stratégies de sharding ou de persistence hétérogénes : des éléments d'une base peuvent être ne relation avec des éléments stockés dans une autre base représentant un autre domaine, ou dans un autre support.

Donc fondamentalement ce n'est pas toujours une bonne idée.
Avatar de CinePhil CinePhil - Modérateur https://www.developpez.com
le 11/09/2009 à 22:29
Citation Envoyé par Luc Orient  Voir le message
Par contre j'évite absolument les clés primaires en VARCHAR ...

On est bien d'accord là dessus !
Avatar de B.AF B.AF - Membre chevronné https://www.developpez.com
le 12/09/2009 à 10:17
En fait en rêgle de design aujourd'hui j'aurai plutôt tendance à

-Utiliser une clef technique (auto ou algo selon le sgbd) pour toutes les données sur lesquels je n'ai pas le décision de la norme
-Utiliser une clef codifiée pour toutes les données sur lesquels je défini leur norme

Si je dois identifier par exemple une plaque d'immatriculation, je considérerai que la norme de définition peut changer (d'ailleurs cas réel finalement) et j'utiliserai un identifiant automatique, et probablement une structure relationnelle pour identifier une immatriculation française avant 2008 ou après, us, belge,etc...

Si par exemple, j'ai besoin pour x raison d'avoir un registre applicatif dans la base, j'utilise généralement une codification alphanumérique sur char(n), mais avec une validation du contenu (pas de blanc, caractères spéciaux)..
D'autant qu'il s'agit généralement de données cachées ou de paramètres applicatifs, l'impact en performance est complétement négligeable.

Parfois sur des besoins très particulier des séries temporelles longues avec des grosses volumétrie, j'utilise aussi des clefs binaires, mais davantage pour des motifs de tris, donc je peux être amené à le faire en char(n), mais c'est un cas très spécifique.

Je pense qu'il ne faut pas avoir d'à priori, mais surtout utiliser la réponse appropriée à la question.
Avatar de hegros hegros - Membre Expert https://www.developpez.com
le 12/09/2009 à 11:29
Citation Envoyé par CinePhil  Voir le message
On est bien d'accord là dessus !

Théoriquement cela ne pose déjà aucun problème puisque nombre de clefs candidates peuvent être de ce type de données. C'est une contrainte technologique pour aujourd'hui mais est-ce là bien une règle qui va durer encore longtemps ?

J'ai vu et utilisé des clefs de type chaîne de caractère cryptée par exemple comme clef primaire cela n'a posé aucun problème particulier et il y a sûrement pleins d'exemples qui abondent aussi dans ce sens

Pour les identifiants automatique nous n'avons plus le choix puisque tout les sgbd le font automatiquement d'une manière ou d'une autre sans qu'on leur demande explicitement, cette clef technique n'a tout de même rien à faire dans un MCD dans un MLD/MPD ok et encore franchement elle n'a aucune valeur.

Immatriculation peut être une entité et pas un attribut type VARCHAR d'une voiture, le design est plus important que ces soucis de clé technique d'où ma règle d'or de ne pas la prendre en compte pendant la conception

Remarque, il n'est pas possible de faire des recherches ou appliquer un tri en utilisant un identifiant automatique dans ses requêtes SQL dans certains SGBD
Avatar de Luc Orient Luc Orient - Membre émérite https://www.developpez.com
le 12/09/2009 à 12:53
Citation Envoyé par hegros  Voir le message
Théoriquement cela ne pose déjà aucun problème puisque nombre de clefs candidates peuvent être de ce type de données. C'est une contrainte technologique pour aujourd'hui mais est-ce là bien une règle qui va durer encore longtemps ? ...

Je me suis peut être mal fait comprendre et je vais donc préciser ma pensée.

Quand j'écrivais que j'évitais les types VARCHAR pour les colonnes des clés primaires, c'était en comparaison avec des colonnes en CHAR.

En aucun cas, je n'exclus les colonnes en CHAR pour définier des clés primaires.
Avatar de hegros hegros - Membre Expert https://www.developpez.com
le 13/09/2009 à 0:24
Qu'est-ce que cela change ? varchar ce n'est pas une horreur c'est le contrôle ou la contrainte d'intégrité qui pose problème pour cet artifice de type caractère à taille variable ?

En prenant un autre modèle que le relationnel avec des tables et colonnes si vous prenez comme représentation un graphe avec par exemple les mib il me semble que chaque noeud est identifié par un varchar...
Avatar de wafiwafi wafiwafi - Membre averti https://www.developpez.com
le 19/09/2009 à 19:25
Merci à tous les intervenants qui ont laissé leurs empreintes de savoir dans lequel bien du monde piochera.
Si d'autres intervenants ont des idées sur le sujet; cela ne sera pas de refus.
Bien à vous tous
Avatar de fsmrel fsmrel - Expert éminent sénior https://www.developpez.com
le 25/09/2009 à 16:42
Bonsoir,

Citation Envoyé par B.AF  Voir le message
Au niveau conceptuel, le shéma est fabuleux
Il s'agit d'un shéma complêtement figé.
Voilà exactement l'exemple du MCD où de façon invariante on avancera que l'appli fonctionne, mais où malgrè moults arguments techniques, il est pauvre.


Merci de préciser quel est ce schéma qui ne trouve pas grâce à vos yeux. Si d’aventure c’est celui de vivicente, vous avez sans doute oublié qu’il débute dans la modélisation. Il ne vous est pas interdit de suivre l’exemple de CinePhil, qui n’hésite pas à montrer au débutant ce qui ne va pas, point par point, et comment apprendre à construire un MCD qui tienne la route (« Il aide, lui », Jean in Les Tontons flingueurs).

Et merci de respecter l’orthographe, vous ne facilitez pas la lecture.

Citation Envoyé par B.AF  Voir le message
Très pauvre, peu évolutif


Veuillez présenter les arguments vous permettant de pointer les défauts que vous relevez et ne pas vous contenter de dénigrer gratuitement. Présentez des solutions d’amélioration visant à l’enrichissement et à l’évolutivité du MCD.

Citation Envoyé par B.AF  Voir le message
aucune logique de composants


Que sont un composant ainsi qu’une logique de composants dans le contexte de l’élaboration de cette abstraction qu’est un MCD (Modèle Conceptuel de Données), objet de la discussion ? S’il s’agit des composants au sens UML (programme source, compilé, fichier de données, etc.) cet inventaire à la Prévert est hors sujet. C’est à la Direction de la Production informatique de l’entreprise de prendre ces choses en charge, en collaboration avec les équipes de développement. Un MCD ne traite que de l’univers du discours (l’entreprise).

Citation Envoyé par B.AF  Voir le message
d'un point de vue de conception pure, c'est une conception complêtement naïve


Encore une affirmation gratuite. Qu’est-ce qu’une conception pure ? Une conception naïve? Quel rapport existe-t-il entre ces deux concepts ?

Citation Envoyé par B.AF  Voir le message
Ca viole même une règle fondamentale de tout objet en ce bas monde : tout objet est amené à évoluer dans le temps.


Qu’est ce qu’un objet ?
1) Si un objet est quelque chose qui évolue qui dans le temps, alors c’est une variable au sens des langages de programmation, au même titre que la variable X, déclarée dans un programme P : au fil du temps, si X est par exemple du type entier, alors cette variable accueille successivement des valeurs qui sont des nombres entiers 1, 2, 3, etc. Ces nombres ne se situent ni dans le temps ni dans l’espace, mais on les fait apparaître par le truchement de X qui joue le rôle de médium.

2) Si un objet est une valeur, alors à l’instar d’un nombre entier il ne si situe ni dans le temps ni dans l’espace, c’est une constante et donc par définition il n’« évolue » pas.

A son tour, une entité-type E est une abstraction, en l’occurrence un type. Lors du passage au MLD (disons dans le cadre du Modèle Relationnel de Données), à cette entité-type on fera correspondre une variable relationnelle (relvar) E qui sera du type RELATION {A1 T1, A2 T2, ..., An Tn} (où Ai est un nom d’attribut et Ti le type de cet attribut) et qui prendra des valeurs de relations de ce type (relations pour abréger, êtres mathématiques fort intéressants qui bien entendu ne se situent ni dans le temps ni dans l’espace, puisque ce sont des constantes). Et bien entendu, le type RELATION {A1 T1, A2 T2, ..., An Tn} hérite de tous les opérateurs de l’algèbre relationnelle.

Citation Envoyé par B.AF  Voir le message
Là il n'y a aucune abstraction, aucun raisonnement objet, aucun raisonnement composant. C'est aussi en même temps la limite fondamentale de penser en relationnel.


Pour l’abstraction, voyez ce qui précède. Que vient faire ici le concept « objet » ? Celui de « composant » ? Qu’est-ce qu’un « raisonnement objet » ? Et, rebelote, un « raisonnement composant » ?

Quant au relationnel, c'est-à-dire la théorie relationnelle, commencez par l’étudier avant de parler de ses limites (à moins que vous ne soyez en mesure de les énumérer ici, de façon claire et objective). A toutes fins utiles, je vous renvoie à l’ouvrage de Date et Darwen : Databases, Types, and the Relational Model The Third Manifesto. Attention, il s’agit d’une étude très formelle, ramassée dans plus de 500 pages. Cela dit, que veut dire « penser en relationnel », sinon raisonner sur des ensembles (au sens de la théorie des ensembles), tant du point de vue structurel qu’algébrique ? Ou encore raisonner sur des prédicats, au moyen de la logique du 1er ordre et du calcul relationnel de tuples (ou de domaines) ?

Citation Envoyé par B.AF  Voir le message
je serai asssez intéressé de voir à quel MPD ce MCD correspond, est-ce du 1:1 ?


MPD est l’abréviation de « Modèle Physique des Données ». Le MPD traite de ce qui se passe dans la soute (organisation des espaces physiques, des index, etc.) Je suppose donc que vous avez voulu écrire « à quel MPD le MLD correspond » ou encore « à quel MLD ce MCD correspond ».

Dans le 1er cas, au nom de l’iindépendance physique, il n’y a pas de correspondance à établir entre les objets physiques et les entités mathématiques que sont le relations de la théorie relationnelle. Ainsi, entre une variable relationnelle (une table pour parler informellement) et un fichier il n’y a pas bijection : les relations (les valeurs prises par la variable relationnelle) peuvent être hébergées par plusieurs fichiers et un fichier peut héberger plusieurs relations de types différents. Cela reste sous le capot. De même, un n-uplet d’une relation n’a pas à correspondre à un enregistrement physique dans un fichier. Un n-uplet est lui aussi un être mathématique qui n’a pas à être contraint par l’organisation sous le capot. Ne cherchons pas à établir une quelconque correspondance entre la logique du 1er ordre et le fer à souder.

Dans le 2e cas, la production d’un MLD à partir d’un MCD est de préférence confiée à un AGL, mais elle est à vérifier et compléter par le DBA : opportunité de la mise en œuvre de variables relationnelles dans le cas des cardinalités 0,1 (notamment en ce qui concerne les associations-types réflexives), complétude des clés candidates d’une variable relationnelle, des dépendances fonctionnelles et multivaluées, des dépendances de jointure (y compris les dépendances de jointure généralisées), normalisation en cinquième forme normale (voire sixième dans le cas des données temporelles), définition des tables virtuelles (vues), définition des contraintes de base de données, de relation, d’attribut, de type. Etc. De même, certaines entités-types du MCD n’ont pas à faire l’objet de variables relationnelles, par exemple l’entité-type DATE qui ne fait que l’objet d’attributs de type DATE ou TIME, ou TIMESTAMP, etc. Quant à chercher une correspondance 1:1 entre un MCD et un MLD, on ne la trouvera pas, sauf peut-être dans des cas de figure simples.

Citation Envoyé par B.AF  Voir le message
Quant aux règles de gestion, là encore, une règle de gestion n'est pas nécessairement associée à 1 élément du modèle, mais peut l'être à n éléments et surtout à n événements, dont le pilotage peut potentiellement être délégué à un élément technique externe au stockage de données (architectures distribuées).


Qu’entendez-vous par « élément du modèle » ?

Par ailleurs, le pilotage des événements ne concerne pas le MCD (c'est-à-dire le QUOI), mais le MCT (c'est-à-dire le COMMENT, le QUAND, les conditions de déclenchement et toutes ces sortes de choses). Un MCD décrit l’univers su discours, c’est un ensemble de prédicats au sens de la logique du 1er ordre.

L’architecture distribuée est étrangère au sujet. Là encore, d’un point de vue MCD et MLD, on ne voit qu’un univers du discours pour le 1er, une base de données pour le 2e, même si dans ce 2e cas, d’un point de vue opérationnel, tout cela repose en fait, de façon transparente, sur plusieurs bases de données, gérées par plusieurs SGBD sur plusieurs machines. Encore une confusion des genres.

Citation Envoyé par B.AF  Voir le message
J'ai l'impression en fait qu'il y a confrontation de deux écoles :
- Ceux qui modélisent une base de données, donc MCD et MPD sont très liés, et le SQL est pris en compte dès le MCD
- Ceux qui définissent un domaine et ses objets, donc MCD et MPD sont lâches, et le MPD est la représentation technologique du MCD.


Quand on modélise un univers du discours (l'entreprise), il n’y a pas deux écoles. Chronologiquement, une fois que le SI a été urbanisé en [sous-]domaines, la direction de projet en partenariat avec la maîtrise d’œuvre (tant qu’à faire) produit un dossier de conception générale pour formaliser l’univers du discours avec un certain recul : pour chaque domaine (Référentiel Personnes, Contrats, Catalogue produits, etc.), on y trouve des MCD représentant les concepts, à grosse maille. Ensuite, à maille fine, toujours par [sous-]domaine, il y a production d’un dossier de conception détaillée dans lequel le MCD est muet quant au MLD et a plus forte raison quant au MPD. En ce qui concerne SQL, n’oublions pas que la direction de projet ignore tout de ce langage, ou à la longue, en a une idée plus ou moins précise, sans pour autant que cela vienne interférer avec la modélisation.

Par la suite, le concepteur du MCD et le DBA affecté au domaine (voire une équipe de DBA) ont un certain nombre d’entretiens avant que celui-ci ne produise le MLD (puis le MPD). Suite aux observations du DBA, le MCD utilisé pou la dérivation peut subir des modifications : révision des identifiants (qui ne doivent être composés que d’attributs artificiels ad-hoc, je vous renvoie une fois de plus à l’ouvrage de Tabourier, De l’autre côté de MERISE, page 81), typage des données, normalisation en BCNF, vérification des associations-types ternaires (et plus), pour voir si elles ne violent pas la quatrième forme normale, recherche des contraintes (notamment temporelles) qui peuvent être sous-traitées au SGBD, mise en œuvre des tables virtuelles (vues) en relation avec la spécialisation des entités-types, etc. Quant à prendre en compte le langage SQL quand débute la conception, c’est non. Ça n’est que lorsqu’on en arrive aux entretiens avec le DBA que celui-ci peut attirer l’attention sur les conséquences des choix de modélisation et ainsi faire réfléchir le directeur de projet qui peut revenir sur tel ou tel choix. Il arrive que certains aient la double casquette : concepteur et DBA, mais ça n’est pas pour autant qu’en tant que concepteur il faille s’adresser aux autres membres des équipes de conception en termes relationnels, tout en ayant en tête la théorie relationnelle qui permet d’éviter certaines erreurs de conception. A titre d’exemple, quand j’ai fait des remarques au débutant, je lui suggérais de normaliser en quatrième forme normale, mais sans le lui dire brutalement.

Quant à dire que le MPD (ou plutôt le MLD) « est la représentation technologique du MCD », c’est un peu court. Cette représentation « technologique » est à valider, évaluer à l’aune de la théorie relationnelle et la faire évoluer en conséquence.

Citation Envoyé par B.AF  Voir le message
Sur la lisibilité d'un modéle, là encore, c'est faisable si les domaines métiers traités sont triviaux. Il est normal que la complexité du métier (et donc non pas de description mais de ses événements et de ses workflows) influe sur le MCD.


Si le MCD complet comporte par exemple mille entités-types, la direction du projet aura pris la précaution d’urbaniser l’univers du discours en domaines (référentiels) sous-domaines et sous-sous-domaines, comme je l’ai déjà plus ou moins évoqué. Ainsi, on aura décomposé le projet en référentiels : Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Éditique, etc., peut-être une vingtaine, voire plus. Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur un ensemble de pages au format (disons) A3, chaque page constituant une vue suffisante pour qu’un développeur n’ait pas à avoir sur son bureau un tombereau de diagrammes.

Quant aux événements (au sens fonctionnel), s’ils doivent eux aussi faire l’objet d’un domaine, pourquoi pas, mais si leur traitement peut être complexe, cela ne doit pas avoir d’incidence sur le MCD, sinon ça n’est pas un MCD. Que l’on prenne en compte — suite à événements — les modifications portant sur une entité-type (par exemple le changement de dénomination d’une entité juridique, son changement de NAF, de régime fiscal, de catégorie juridique, etc.) ceci reste simple à représenter dans le MCD quand on sait distinguer les données actives des données historisées et qu’on ne fourre pas tout dans le même sac. (En cela, la connaissance de la sixième forme normale n’est pas inutile).

Citation Envoyé par B.AF  Voir le message
le MCD ne doit pas engendrer une dénaturation des règles de gestion des données.

Je ne vois même pas comment on peut réaliser un MCD sans connaitre les règles de gestion à priori, sauf à modéliser des éléments triviaux dont la connaissance est supposée commune à tous. Donc le MCD ne peut être qu'une résultante de l'analyse exhaustive des règles métier. Sinon, il s'agit simplement d'un modéle anémique, inutile, et avec un risque d'adhérence élevé.


Merci de ne pas sortir une phrase de son contexte pour en dénaturer le sens. Comme je l’ai déjà dit, les règles de gestion des données préexistent, elles sont consignées dans le dossier de conception détaillé. Par exemple, quand il est écrit qu’une facture comporte au moins une ligne de facture, cela se traduit dans le MCD par une cardinalité minimum 1. Si l’on remplace cette cardinalité par 0, alors il y a bien dénaturation d’une règle de gestion des données. C’est le reproche que je faisais à hegros qui préconise, je cite, de « Prendre en compte uniquement la partie maximum pour les cardinalités ».

Quant à « l’anémie » des MCD et de leur « risque d’adhérence élevé », les participants et les visiteurs de ce forum doivent se perdre en conjectures, sauf peut-être s’ils s’appellent Sganarelle. Isn't it a little fuzzy?

Il est vrai que certains « top models » paraissent anémiés et que certains modèles de pneumatiques peuvent manquer d’adhérence au sol, mais à part cela...

Citation Envoyé par B.AF  Voir le message
Pour la modélisation des relations ternaires, disons simplement que la logique relationnelle n'est pas adaptée à des "dépendances logiques polymorphiques".
Le modèle objet l'est.


Ça présente bien, mais je ne vois pas ce que vous appelez une « dépendance logique polymorphique » (ça s’appelle peut-être encore autrement ?) Je ne vois pas non plus ce que les relations ternaires ont à voir avec ça. Quant à l’aspect polymorphique proprement dit, voulez-vous signifier qu’il s’agit du polymorphisme de type, au sens UML ou du Modèle Relationnel de Données ? Si oui, cela est abondamment traité dans la théorie relationnelle (cf. par exemple les chapitres 12 à 16 de l’ouvrage déjà cité, Databases, Types, and the Relational Model The Third Manifesto).

Citation Envoyé par B.AF  Voir le message
Autant j'adhére au DDD, autant là je me sens en plein anachronisme.


Conclusion : il vous reste donc plus qu’une seule chose à faire : vous retirer (sur la pointe des pieds).

Citation Envoyé par B.AF  Voir le message
« Tous les hommes sont mortels » ou « Quelques hommes sont mortels »

C'est fondamentalement identique pour nous. Cela veut dire que tout ou partie des hommes au sens logique peut un jour faire l'objet d'un événement "mort".
La seule différence va être au sens technique. C'est dans la façon dont sera représenté physiquement la capacité à mourrir que sera gérée la différence.


Là encore, vous sortez une phrase de son contexte, pour partir ailleurs. J’ai expliqué à hegros que transformer une cardinalité minimum 1 en 0 revenait à confondre la quantification universelle et la quantification existentielle, donc affirmer que les deux énoncés « Tous les hommes sont mortels », « Quelques hommes sont mortels » sont équivalents, ce qui est évidemment une erreur logique très grave. Si vous voulez en savoir plus, je vous conseille par exemple la lecture de l’ouvrage de Quine méthodes de logique, « Énoncés catégoriques » et là vous apprendrez que le 1er énoncé est du type A (universelle affirmative) et le 2e du type I (Particulière affirmative).

Citation Envoyé par B.AF  Voir le message
Un MCD "bien formé" peut tout à fait aboutir à un MPD parfait, alors que dans sa logique, il est anémique et inutile.


Qu’entendez-vous par « logique » d’un MCD ? Et une fois de plus, par « MCD anémique » ?

Citation Envoyé par B.AF  Voir le message
faire valider un cahier des charges n'a jamais signifié que les régles de gestion sont bonnes. C'est juste un transfert de responsabilités qui sert plus souvent d'excuse et de prétexte que de mesure de la qualité et de recensement.


Si les règles de gestion des données ne sont pas bonnes, c’est que le chef de projet n’a pas su accoucher la maîtrise d’œuvre. Et si le projet échoue, il en portera la responsabilité. Si les règles de gestion des données sont incomplètes et si le MCD est bien construit, on le fera évoluer en conséquence.
Ceci dit, quelle alternative proposez-vous à la validation des dossiers ? Que faire pour s’assurer que les règles de gestion des données soient réputées valides ? Merci de nous éclairer de vos lumières (qui pour le moment éteignent).

Citation Envoyé par B.AF  Voir le message
Par rapport au SI le MCD est beaucoup trop pauvre pour être une formalisation utile.


Si le MCD est parfois trop pauvre c’est parce qu’il ne prend pas en compte des concepts tels que l’héritage, la composition, l’agrégation, les contraintes d’inclusion, exclusion et autres : il faut donc le faire évoluer en ce sens (je vous renvoie à la FAQ Merise).

Cela dit, un MCD est malgré tout un excellent moyen de communication, et comme je l’écrivais dans un message précédent :
« Le MCD doit être crédible et clair, au point que la MOE et les équipes de développement décident d’afficher au mur les vues qui les concernent, plutôt que de s’en servir comme de ballons de basket, la poubelle jouant le rôle de panier. »
Maintenant, si le MCD ne suffit pas, on peut se référer à ses compagnons, le MCT (Modèle Conceptuel de Traitement) et le MCC (Modèle Conceptuel de Communication).

Citation Envoyé par B.AF  Voir le message
Le MCD pour moi est surtout un formalisme techniquement dépassé, beaucoup trop confiné au SQL.


Merci de démontrer en quoi le formalisme MCD est techniquement dépassé. Quant à sa relation avec SQL, sachez que les SGBD utilisant ce langage ont été mis sur le marché seulement quelques années après que l’on a commencé à produire des MCD. Merise date de la fin des années soixante-dix et, en France, les entreprises ont commencé à vraiment utiliser les SGBDR en production une dizaine d’années plus tard.

Une fois de plus vous mélangez complètement les niveaux, vous amalgamez abstraction (modélisation des données) et réalisation (SQL).

Citation Envoyé par B.AF  Voir le message
Je trouve simplement qu'en 2009, le DDD est beaucoup plus productif et efficient..


Grand bien vous fasse. J’espère que l’efficience de votre modélisation s’accompagne de la validité des résultats obtenus.

Citation Envoyé par B.AF  Voir le message
Quand je lis
Je suis désolé, mais lors des séances de validation fonctionnelle d’un MCD, doivent être présents le chef de projet et/ou le concepteur (qui connaissent tous deux parfaitement le dossier), ainsi que l’équipe fonctionnelle de la Maîtrise d’Oeuvre qui, je le répète, comprend en général très vite le dossier et ce qui a été modélisé (sauf si le MCD ressemble à une toile d’araignée ou à un chef-d’œuvre d’art contemporain). A défaut, en l’absence de séances de relecture en commun, je ne donne pas cher du projet.

C'est effrayant, ça veut dire que la conception est un organisme mono cellulaire qui travaille en mode non collaboratif, que de facto, toute réalisation complexe et lourde est à proscrire.


Qu’y a-t-il d’effrayant à ce que la Maîtrise d’ouvrage organise des réunions pour s’assurer que les équipes du projet et la Maîtrise d’œuvre sont bien toujours en phase ? Pour s’assurer qu’il n’y a pas eu de dérive ? Pour mettre à plat les points à revoir ? Certes, en début de projet, les équipes du projet (les informaticiens) et la Maîtrise d’œuvre sont pratiquement en permanence ensemble, mais ensuite les informaticiens modélisent à partir des résultats des travaux effectués en commun. C’est la moindre des choses que la MOA surveille ses troupes et l’avancement du projet (domaine par domaine).

Je rappelle une fois de plus qu’on urbanise un univers du discours en domaines, sous-domaines, etc. Un projet de refonte du SI d’une entreprise importante (je sais de quoi je parle) entraîne nécessairement l’urbanisation, donc la modélisation de plusieurs domaines, ce qui a notamment pour objet d’éviter une réalisation complexe et lourde qui se traduirait par la mort du projet. Et cela a pour effet que l’on constitue des équipes homogènes, de taille raisonnable, tant côté informatique que MOE.

Citation Envoyé par B.AF  Voir le message
La pire chance d'échec du projet c'est de n'avoir que 2 personnes qui connaissent parfaitement le sujet...Pas de révision, pas de droit à l'erreur, risques de sélection "dogmatiques".


C’est bien pour cela que l’on urbanise les projets d’une certaine ampleur. Pour chaque domaine, il y a un chef de projet et son équipe, même principe côté Maîtrise d’œuvre. Si un chef de projet tombe malade, son adjoint assure l’intérim, etc.
Rassurez-vous tout cela fait largement plus que seulement deux personnes connaissant le sujet...

Citation Envoyé par B.AF  Voir le message
En fait en rêgle de design aujourd'hui j'aurai plutôt tendance à

-Utiliser une clef technique (auto ou algo selon le sgbd) pour toutes les données sur lesquels je n'ai pas le décision de la norme
-Utiliser une clef codifiée pour toutes les données sur lesquels je défini leur norme

Si je dois identifier par exemple une plaque d'immatriculation, je considérerai que la norme de définition peut changer (d'ailleurs cas réel finalement) et j'utiliserai un identifiant automatique, et probablement une structure relationnelle pour identifier une immatriculation française avant 2008 ou après, us, belge,etc...


Je suppose que par « design » vous voulez dire modélisation. Si vous vous situez au niveau de la modélisation des données, que vient faire le SGBD ? Quant à codifier les clés (en fait les identifiants), je répète pour la nième fois ce qu’à écrit Yves Tabourier (De l’autre côté de MERISE page 81) :
« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets...
»
Tabourier a tiré les leçons du passé et nous demande quelque part d’avoir en mémoire ce que Goethe, Winston Churchill, George Santayana, Thomas Mann, et d'autres ont écrit :
Ceux qui ont oublié le passé sont condamnés à le revivre.


Je répète pour ma part qu’au niveau MCD, la plaque d’immatriculation (qui correspond à une propriété naturelle) ne peut faire l’objet que d’un identifiant alternatif (donc d’une clé alternative lors du passage au niveau base de données) et que l’identifiant d’une entité-type (donc la clé primaire d’une table au niveau base de données) ne décrit rien. L’utilisateur ne doit connaître que les propriétés naturelles, l’identifiant lui est caché. La plaque d’immatriculation ne figure qu’une fois dans l’univers du discours, donc dans la base de données qui en sera inférée. En ce qui le concerne, une fois traduit sous forme de clé primaire, l’identifiant sera propagé autant de fois qu’il y aura de contraintes référentielles dans lesquelles il est impliqué. C’est une question de bon sens que de ne lui associer aucune signification quelconque. Sa mission sera de garantir l’intégrité de la base de données (intégrité d’entité, intégrité référentielle), pas de décrire.

Ensuite, au niveau de la base de données, qu’un attribut participant à une clé primaire soit du type entier (séquentiel ou haché), timestamp (séquentiel ou haché), CHAR, VARCHAR, INTERVAL, etc., ceci est parfaitement orthogonal (indépendant) par rapport à la modélisation. Le choix définitif de ce type relève de la compétence du DBA et certainement pas du concepteur ou du développeur, qui sont plus concernés par l’aspect fonctionnel des choses.

Voyez encore http://www.developpez.net/forums/d79...d/#post4635515

Citation Envoyé par B.AF  Voir le message
Si par exemple, j'ai besoin pour x raison d'avoir un registre applicatif dans la base, j'utilise généralement une codification alphanumérique sur char(n), mais avec une validation du contenu (pas de blanc, caractères spéciaux)..
D'autant qu'il s'agit généralement de données cachées ou de paramètres applicatifs, l'impact en performance est complétement négligeable.

Parfois sur des besoins très particulier des séries temporelles longues avec des grosses volumétrie, j'utilise aussi des clefs binaires, mais davantage pour des motifs de tris, donc je peux être amené à le faire en char(n), mais c'est un cas très spécifique


J’espère que vous ne vous ne traitez pas ici des identifiants du niveau conceptuel, mais de propriétés disons naturelles (quitte à ce qu’elles fassent l’objet d’identifiants alternatifs).

Citation Envoyé par hegros  Voir le message
En prenant un autre modèle que le relationnel avec des tables et colonnes si vous prenez comme représentation un graphe avec par exemple les mib il me semble que chaque noeud est identifié par un varchar...

Là encore, le choix du type des attributs est un problème de réalisation, pas de modélisation. Mais si, au niveau modélisation, vous avez malgré tout de très bonnes raisons de retenir le type VARCHAR plutôt que INTEGER, CHAR, ou ... NŒUD, vous aurez à convaincre le DBA (qui généralement n’est pas favorable à VARCHAR pour typer une clé).
Offres d'emploi IT
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique ALM