Discussion :

[wafiwafi]

Une question 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 mais non réfléchie.
Des règles à respecter existent, elles ne sont pas d'or mais imposées pour respecter la construction.
À travers vos diverses expériences, vous pouvez agir. Qui sait peut être des règles d'or existent réellement à ce stade.

[JPhi33]

Bonjour,

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...

Le MCD (Modèle Conceptuel de Données) a pour objet la représentation (l'abstraction) d'une réalité. Son invariant est le métier : le "QUOI".

Par conséquent le reste est variable : organisations, fonctions, technologies, etc. Ce qui signifie que le MCD doit être indépendant de ces variables : il ne doit pas tenir compte de l'organisation de l'entreprise, ni des applications qui vont utiliser la ou les bases de données résultantes, encore moins des technologies d'implémentation.

Donc, s'il devait y avoir une règle d'or (ou règle de base ou règle essentielle) pour la modélisation conceptuelle, ce serait, à mon avis : Un bon MCD est celui qui modélise correctement 100% des règles de gestion du cahier des charges (ce qui transparait dans la citation de wafiwafi ci-dessous).

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.

[fsmrel]

Bonjour,

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 confirmer ce que dit JPHi33, on ne traite pas des accès au disque quand on est sur la dunette (c'est-à-dire au niveau conceptuel) : « minimiser les lectures et écritures sur disques » fait l’objet d’une étude distincte de la modélisation conceptuelle des données. Descendons dans la soute, pour que vous compreniez bien pourquoi.

Cette étude suppose en effet que l’on ait connaissance du SGBD qui sera utilisé. Elle pourra être appelée « prototypage des performances » et devra être menée par un spécialiste, un DBA (administrateur des bases de données) qui construira son prototype suite aux entretiens qu’il aura eus avec le chef de projets, afin d’identifier les traitements les plus sensibles (disons le top 10). Dans ce genre d’exercice, il ne s’agit pas de programmer, mais de façon pragmatique — à partir d’un jeu de tables ayant à peu de choses près la structure de celles qui seront dérivées du MCD, avec une volumétrie suffisante pour les mesures —, construire un ensemble de requêtes (disons SQL) qui ne sont jamais que des brouillons, mais qui suffisent pour connaître la performance globale, bien avant que ne démarrent les véritables développements, lesquels tiendront évidemment compte du verdict du prototype.

Maintenant, il est vrai que les résultats fournis par le prototype, peuvent avoir quelques retombées sur le MCD lui-même, telles que l’utilisation de l’identification relative — plutôt qu’absolue —, qui normalement est une conséquence de la sémantique des données (par exemple, une ligne de facture est à identifier relativement à une facture). Mais normalement, cela ne remet pas en cause le MCD lui-même (ou alors c’est que le concepteur n’a pas fait vraiment son travail).

De même que lorsque vous bâtissez un MCD vous ne vous focalisez pas sur les accès au disque, de même vous ne vous mêlez pas d’autres problèmes sensibles qui ne sont pas de votre ressort et auxquels vous n’aurez pas songé (heureusement, sinon vous ne dormiriez pas), par exemple : les étreintes fatales et autres verrous mortels, dus à une trop forte concurrence des utilisateurs lors des opérations de mises à jour. Là encore, c’est le prototype qui devra permettre de mettre en évidence ces phénomènes, d’anticiper quant à l’organisation de la structure physique des tables afin d’éliminer ce genre de problèmes.

Ou encore, vous ne vous préoccupez pas des droits des utilisateurs sur les données, sauf à élaborer un MCD annexe à cet effet. Là encore, chaque chose en son temps, comme dit l’autre « the right man in the right place, at the right time ».

Ce qui signifie encore : indé-pen-dan-ce.

Bref, pendant que le DBA construit son prototype, assurez-vous déjà auprès du chef de projets que le cahier des charges est à peu près complet, sinon vous-même, le chef de projets — et finalement tout le monde, y compris la Maîtrise d’ouvrage — connaîtriez bien de bien cruelles désillusions.

[benwit]

Maintenant, il est vrai que les résultats fournis par le prototype, peuvent avoir quelques retombées sur le MCD lui-même, telles que l’utilisation de l’identification relative — plutôt qu’absolue —, qui normalement est une conséquence de la sémantique des données (par exemple, une ligne de facture est à identifier relativement à une facture).

Ok pour la sémantique.
Mais la clé relative nécessite une clé composé n'est-ce pas ?

Perso, j'ajoute systématiquement une clé "technique" qui est ma clé primaire. Cela évite à la fois le passage des x attributs composants la clé fonctionnelle et les lourdeurs lors d'évolution du schéma.
Cela n'empêche pas que les attributs de la clé "fonctionnelle" soient présents et de poser une contrainte d'unicité dessus.

[CinePhil]

Effectivement, l'identification relative entraîne en principe une clé composée.

Exemple pour une chaîne d'hôtels et leurs chambres. Dans chaque hôtel, les chambres sont numérotées de 1 à n.

Il y a deux possibilités :
1) La "normalisée" :
Chambre -(1,1)----Situer----1,n- Hôtel

Hotel (H_Id, H_Nom...)
Chambre (Ch_IdHotel, Ch_Numero, ...)

Identification relative de la chambre par rapport à son hôtel, la chambre est identifiée par la clé composée (Ch_IdHotel, Ch_Numero).

2) La vôtre :
Chambre -1,1----Situer----1,n- Hôtel

Hotel (H_Id, H_Nom...)
Chambre (Ch_Id, Ch_IdHotel, Ch_Numero, ...)

Identifiant artificiel pour la chambre et obligation de mettre une contrainte UNIQUE sur le couple (Ch_IdHotel, Ch_Numero).

Dans un cas comme celui-ci où les chambres sont numérotées par des entiers, je préfère la solution normalisée.

Si par contre les hôtels ont donné un joli nom à leurs chambres à la place de numéros, je préfère l'identifiant artificiel car une colonne de type textuel dans une clé primaire, je n'aime pas car le nom de la chambre peut changer et bonjour les mises à jour dans toutes les tables dérivées, le modèle n'est alors pas solide.

[benwit]

Si on pouvait se passer de données "superflues" (id artificiel), ça serait mieux en effet.

En prenant votre exemple, ma solution me met à l'abri de certaines difficultés trop souvent rencontrées !

Par analogie, dans votre exemple, cela donne :

Au début du projet, les chambres sont identifiés comme vous le dites par un numéro. On choisit donc la solution de la clé composée.

Puis avec l'évolution, il y a :
- une table de jointure où la chambre apparaît (2 attributs) avec une autre clé composé (3 attributs) et une troisième (3 attributs). Pour ce triplet (si id technique), on doit se trimballer du coup avec 8 attributs !
(je ne parle même pas d'une table ou la clé composé avait 7 attributs !)

- la nouvelle directrice de l'hotel décide de renuméroter les chambres en tenant compte de l'étage et ... du coté pair/impaire du couloir !

[Luc Orient]

...
Perso, j'ajoute systématiquement une clé "technique" qui est ma clé primaire. Cela évite à la fois le passage des x attributs composants la clé fonctionnelle et les lourdeurs lors d'évolution du schéma.
Cela n'empêche pas que les attributs de la clé "fonctionnelle" soient présents et de poser une contrainte d'unicité dessus.

Et on a déjà "claqué" deux index au lieu d'un seul ... ça va pas accélérer les insertions dans la table tout ça ...

[benwit]

Reprenons l’exemple des deux tables Commande et LigneCommande et suivons votre recommandation : utilisons une clé primaire singleton {LigneCommandeIdAbs} pour la table LigneCommande. Si vous relisez avec attention ce que j’ai écrit dans mon message précédent, l’objet du prototype est, entre autres, de vérifier que la performance concernant les accès à cette table est acceptable. En fonction de son verdict, on pourra être amené à remplacer la clé primaire singleton {LigneCommandeIdAbs} par la paire {CommandeId, LigneCommandeIdRel}. Pour ma part, à chaque fois que j’ai prototypé, j’ai constaté que dans ce genre de scénario (relation entre une entité-type et ses propriétés multivaluées) c’était un bienfait pour les accès (réduction du nombre de pages à charger en mémoire donc des temps d'attente de fin de chargement). En conséquence, je suis amené à utiliser l’identification relative au niveau du MCD.

Si je vous comprend bien, utiliser la paire {CommandeId, LigneCommandeIdRel} est un bienfait par rapport au singleton {LigneCommandeIdAbs} ?
Je suis un peu étonné.
Si je conçois bien que l'utilisation du singleton {LigneCommandeIdAbs} est plus coûteux en espace (et donc en temps par rapport à ce que vous avez dit), j'avais initialement pensé que si le sgbd n'avait à travailler que sur un attribut unique (pour la clé) au lieu d'un n-uplets d'attributs entrant dans la composition de la clé, ça serait "moins couteux" en temps ?
J'avoue que c'était un a priori étayé par aucune compétence en ce domaine.
Si vous me confirmez que l'utilisation des identifiants relatifs est "meilleur" pour les perfs (suivant votre expérience bien entendu car on peut certainement trouver des exceptions et c'est le prototypage qui tranchera), c'est tant mieux car je trouve votre solution plus propre que l'ajout superflu d'une clé technique.

Quant « aux lourdeurs lors d'évolution du schéma » (conceptuel ? logique ?) je ne vois rien qui puisse confirmer votre affirmation. Merci de fournir un exemple.

En préférant l'ajout d'une clé singleton purement "technique", je ne pensai pas particulièrement aux performances (d'ailleurs, mon "à priori" semble se révéler faux) mais plutôt à un aspect pratique de développeur (utilisateur de sgbd ayant donc un point de vue moins technique que le vôtre)

Je vais essayé de trouver des arguments :

La simplicité des requêtes :

J'ai toujours trouvé plus simple de faire des requêtes avec ou sans jointures lorsque la clé d'une table n'est pas composée. Je reconnais que c'est du détail mais quand il faut se trimballer pour une simple recherche, une clé composé de 7 attributs (mappé avec leur équivalent objet), c'est un peu pénible.

Une clé technique unique moins contraignante pour l'évolution du schéma ?

En revanche, la clé technique singleton me semble meilleur vis à vis de l'évolution du schéma. Je parle d'une évolution conceptuelle ayant forcément une conséquence sur le modèle logique.

A priori, oui ...
La clé singleton ayant été introduite pour des raisons purement technique (et je ne parle pas de perf), elle est donc indépendante de l'évolution fonctionnelle. J'ai le sentiment qu'une clé métier est plus "contraignante" (composée de plusieurs attributs avec des contraintes) pour moi développeur qu'une unique clé technique.

... mais à la réflexion non à iso-cohérence ...
J'avoue que j'avais initialement pensé que le contrôle de l'unicité de ma clé technique était plus "rapide" que le contrôle de l'unicité d'une clé fonctionnelle composée d'un n-uplet d'attributs.
Je me rend compte du biais introduit car si pour être égaux face au problème d'intégrité, je doit ajouter une contrainte d'unicité sur ces mêmes attributs (ceux entrant dans votre clé fonctionnelle), je ne dois plus rien "gagné".

... mais peut être un peu mieux pour les tables de jointures ?
Supposons deux entités A et B avec une relation n/n et donc une table de jointure TJ_AB dans le modèle logique. Si une des entités "évolue" et nécessite des attributs supplémentaires dans TA, avec la clé fonctionnelle, je devrai également modifier ma table TJ_AB alors puisque tous les attributs entrant dans la composition de la clé TA devront aller dans TJ_AB.
La clé unique technique nous met à l'abri de cela et si on a beaucoup de relations, ça peut quand même simplifier les modifications nécessaires non ?

Conclusion :
Ceci dit et c'est ce qui a de bon dans ces discussions, en rédigeant mon point de vue, je me rend compte qu'il est discutable.

• Côté performance, pas mieux (et d'après Luc Orient, même pire avec un index supplémentaire ).
• Côté facilité développement, du détail et sûrement de la gnognotte pour un dba.
• Côté évolution du schéma, même impact pour la table concernée (l'impact est identique à cohérence des données identiques) et un impact moindre sur les tables de relations.

J'espère avoir été plus clair et j'attends vos remarques.

Question aux DBA : l'utilisation d'une clé technique est donc un anti pattern ?

[fsmrel]

Bonsoir,

La seule vraie règle d'or c'est :
De comprendre et de connaitre exhaustivement le métier; c'est une condition nécessaire à l'abstraction et à tout travail de modélisation

S’il s’agit de connaître le métier de la conduite de projets ou de celui de la modélisation, c’est la moindre des choses quand on entreprend les travaux de modélisation.
S’il s’agit de comprendre le métier de l’utilisateur, oui, c’est une condition nécessaire mais non suffisante. Par contre, connaître exhaustivement ce métier, est généralement utopique. Il est de loin préférable que le concepteur sache renifler, s’assurer de la complétude et de la pertinence des règles de gestion des données établies en relation avec la Maîtrise d’œuvre. Au final, produire un dossier de conception détaillée digne de nom (Verba volant, scripta manent). Je parle en connaissance de cause.

C'est "con comme la lune", mais je n'ai jamais vu un modéle intelligent sortir d'une vision technologique.

Qu’entendez-vous par « modèle intelligent » ? « vision technologique » ?
Par exemple, l’utilisation de l’identification relative est-elle visée ? La normalisation des données ? L’agrégation des données ? L’héritage des données ? Les contraintes entre les données ? (Liste non exhaustive).

La seule vraie règle d'or c'est :
- De chercher le niveau de dépendance minimal entre les différents éléments

Obscur. Merci de définir avec précision les concepts de « dépendance minimale » et d’ « élément », puis d'établir la relation entre ces concepts.

- De maitriser les récursivités

Je suppose que vous voulez dire que le concepteur doit savoir ce qu’est une association-type réflexive : un point parmi bien d’autres. Si vous parlez d’autre chose merci de préciser ce dont il s'agit. Par ailleurs, puisque vous en parlez au pluriel, veuillez décliner les différentes « récursivités » auxquelles vous faites allusion, ça pourrait intéresser pas mal de monde.

- De toujours s'appuyer sur un expert technique pour vérifier sa qualité technique

Vague. Un expert « technique » en quoi ? Que signifie « qualité technique » ?

- De gérer dès le commencement les problèmatiques...
De versioning des données (audit, log)

Au niveau du MCD ? Justifiez.

[...] D'audit des événements sur les données.

Au niveau du MCD ? Justifiez.

De visualisation (reconstruction des données)

Plaît-il ?

Il est surtout inutile de commencer par des considérations techniques.

Considérations techniques de quel ordre ? Comment représenter les entités-types et leurs relations ? Merci de donner des exemples.

Combien de développeur on voit encore aujourd'hui créer des tables TBL_PERSONNE, TBL_CLIENT , TBL_CONTACT,etc,etc...Ce qui est d'une débilité absolue !

Le rôle des développeurs est de développer, pas de modéliser les données, chacun son métier. Est-ce bien le message que vous voulez faire passer ?

Je ne veux vexer personne, mais les MCD mis en exemples dans ce post sont d'une naïveté effarante et loin du niveau de ce qui fait une application d'entreprise.

Apprenez que sur ce forum il ne s'agit pas d'expertiser des modèles d’entreprise complets et compliqués à souhait, mais de répondre avec des exemples simples aux interrogations de ceux qui cherchent à comprendre ou approfondir tel ou tel aspect de la modélisation des données.

Cela dit, considérons mon exemple des livraisons : il est peut-être d'une naïveté effarante, mais il est extrait d’un cas réel, développé en France pour un leader mondial dans sa partie. La modélisation a été expertisée à tous les étages (MCD, MLD, MPD). L’application a été mise en production (il y a vingt ans), puis avoir fait ses preuves, a été promue comme référentiel européen de l’entreprise, puis comme référentiel mondial. Et ça tourne comme une horloge.

Le MCD c'est pareil. Le sql c'est un finalité, mais absolument pas une fin. C'est une hypothése technologique qui ne garanti pas l'adéquation du modèle avec le business concerné.

Qui a dit le contraire ?

Veuillez noter en passant que l’expression « Le sql c'est un finalité mais absolument pas une fin » est ambiguë, voire contradictoire et nécessite donc des explications. Quoi qu'il en soit, SQL est un langage de description des structures des données (le Quoi), des contraintes d’intégrité (encore le Quoi) et de manipulation des données (le Comment), selon une approche ensembliste et non pas procédurale. Ce langage (normalisé ISO) est un moyen de concrétiser par le truchement d’une base de données (qui se situe dans le temps et dans l’espace) l’abstraction exprimée par le MCD (le Quoi à nouveau), abstraction qui ne se situe ni dans le temps ni dans l’espace.

Conclusion : Je vous conseille de lire de l'ouvrage de D. Nanci et B. Espinasse Ingénierie des systèmes d'information Merise, ou celui de Michel Diviné, Parlez-vous Merise ?, ouvrages épatants pour apprendre à réaliser des modèles conceptuels de données.


De grâce, justifiez et commentez vos propos qui sont le plus souvent bien flous.

[hegros]

Voilà quelques règles d'or pour moi


-Ne jamais fournir un MCD sans les règles de gestion et un dictionnaire de données
-Modélisez en couvrant l'aspect offre, tarification et tiers
-Ne pas mettre de clé primaire auto-incrémenté comme #id_voiture pour une entité voiture
-Évitez les relations ternaires et plus, ramenez toujours à une relation binaire
-Prendre en compte uniquement la partie maximum pour les cardinalités
-Respectez les formes normales
-Nommez toujours les associations entre entité




Par rapport au lien entre la conception et l'implémentation il y a un risque de prendre en considération trop tôt la technique dans le modèle. Je préférerais dans ce cas avoir 2 modèles bien distincts car ces considérations pour moi interviennent plus tard dans le MPD ou MLD

-Modèle conceptuel épuré de toute considération technique, c'est à dire juste le métiers
-Modèle conceptuel qui prends en considération la technique pour l'optimisation


Pourquoi ? Tout simplement parce que vous ne savez pas qui va le lire. Un modèle qui prends en compte la technique va forcément être plus difficilement lisible par un fonctionnel et un modèle l'ignorant risque de ne pas être pertinent pour un technicien. Tandis que le modèle épuré de la technique fonctionnel et technicien y trouve leur compte aussi ils peuvent plus facilement communiquer

[f-leb]

bonsoir,

je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"

-Ne pas mettre de clé primaire auto-incrémenté comme #id_voiture pour une entité voiture

Déjà je ne suis pas sûr que parler de "clé primaire auto-incrémenté" soit pertinent au niveau conceptuel où on parle plutôt d'identifiant (à confirmer).
Sinon, vous préconisez quoi comme identifiant pour une voiture ? N° immatriculation? N° de châssis? autre chose ?

-Évitez les relations ternaires et plus, ramenez toujours à une relation binaire

j'évite les ternaires si les règles de gestion le permettent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CONTACT----0,n----exercer----0,n-----FONCTION
                     |
                    0,n
                     |
                 ORGANISME

si un contact peut exercer la même fonction dans plusieurs organismes
si une fonction dans un organisme peut être exercée par plusieurs contacts
si un contact peut avoir plusieurs fonctions dans un même organisme,

je ne vois pas comment je pourrais renoncer à la ternaire.

-Prendre en compte uniquement la partie maximum pour les cardinalités

EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE

règle de gestion: un employé peut travailler "au black"

[hegros]

je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"

Cela ressemble à ce que l'on appelle plus couramment les bonnes pratiques que cela existe pour un MCD n'a rien d'étonnant.

Déjà je ne suis pas sûr que parler de "clé primaire auto-incrémenté" soit pertinent au niveau conceptuel où on parle plutôt d'identifiant (à confirmer).
Sinon, vous préconisez quoi comme identifiant pour une voiture ? N° immatriculation? N° de châssis? autre chose ?

On voit beaucoup de MCD avec dedans un attribut "numéro auto-incrémenté" ou identifiant automatique peu importe comment on l'appelle, c'est courant, ce que je dis c'est que c'est inutile dans le MCD en plus d'être complètement superficiel. Il faut soit avoir une véritable clefs primaire soit ne pas en mettre du tout. Rajoutez des #id_machin superficiel n'a rien de pertinent dans le modèle.

Pour ta question, s'il n'y en a pas pour voiture alors dans le mcd je n'en mets pas tout simplement par contre je rajoute la clef automatique dans le MLD ou le MPD.

j'évite les ternaires si les règles de gestion le permettent:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CONTACT----0,n----exercer----0,n-----FONCTION
                     |
                    0,n
                     |
                 ORGANISME

si un contact peut exercer la même fonction dans plusieurs organismes
si une fonction dans un organisme peut être exercée par plusieurs contacts
si un contact peut avoir plusieurs fonctions dans un même organisme,
je ne vois pas comment je pourrais renoncer à la ternaire.

Il y a toujours quelques cas exceptionnel qui font qu'il n'y a pas d'autres choix cependant c'est une question de conception en passant par des entités de gestion on devrait pouvoir éviter les ternaires et le plus souvent on arrive à les remplacer en binaire, ton cas n'est donc pas non plus une généralité et ce qu'on retrouve le plus.

EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE

règle de gestion: un employé peut travailler "au black"

[/QUOTE]

Je ne vois pas où tu veux en venir.

[CinePhil]

On voit beaucoup de MCD avec dedans un attribut "numéro auto-incrémenté" ou identifiant automatique peu importe comment on l'appelle, c'est courant, ce que je dis c'est que c'est inutile dans le MCD en plus d'être complètement superficiel. Il faut soit avoir une véritable clefs primaire soit ne pas en mettre du tout. Rajoutez des #id_machin superficiel n'a rien de pertinent dans le modèle.

Pour ta question, s'il n'y en a pas pour voiture alors dans le mcd je n'en mets pas tout simplement par contre je rajoute la clef automatique dans le MLD ou le MPD.

Comme il a été dit plus haut je crois dans la discussion, si on fait le MCD à l'aide d'un logiciel de modélisation, et si, comme tu le préconises, il vaut mieux ne pas mettre de clé à une entité plutôt qu'une mauvaise clé (numéro d'immatriculation d'une voiture), alors quand on va demander au logiciel de modélisation de générer le MLD, il va sans doute hurler.

Donc moi je mets systématiquement des identifiants anonymes du genre 'id' aux entités dès le MCD.
Et je vais même plus loin puisque, toujours dans le cas de l'utilisation du logiciel de modélisation, celui-ci générera aussi les requêtes SQL pour fabriquer physiquement la base de données alors autant régler au plus vite le typage des attributs qui deviendront des colonnes de tables.
Ce qui est fait n'est plus à faire.
Ceci n'empèche pas bien sûr de vérifier la qualité du MCD puis du MLD généré avant d'implémenter la BDD.

[f-leb]

je suis un peu étonné de voir ces "règles d'or pour concevoir un bon MCD"

Cela ressemble à ce que l'on appelle plus couramment les bonnes pratiques que cela existe pour un MCD n'a rien d'étonnant.

Pardon, en effet j'aurais dû écrire:
"@hegros: je suis un peu étonné de voir tes "règles d'or pour concevoir un bon MCD"

On voit beaucoup de MCD avec dedans un attribut "numéro auto-incrémenté" ou identifiant automatique peu importe comment on l'appelle, c'est courant, ce que je dis c'est que c'est inutile dans le MCD en plus d'être complètement superficiel. Il faut soit avoir une véritable clefs primaire soit ne pas en mettre du tout. Rajoutez des #id_machin superficiel n'a rien de pertinent dans le modèle.

Pour ta question, s'il n'y en a pas pour voiture alors dans le mcd je n'en mets pas tout simplement par contre je rajoute la clef automatique dans le MLD ou le MPD.

l'entité VOITURE sans identifiant ?????!!!!! Cette pratique ne me semble pas à mettre parmi les "règles d'or".

-Prendre en compte uniquement la partie maximum pour les cardinalités

EMPLOYE---0,n---rémunérer---1,1---ELEMENTPAYE

règle de gestion: un employé peut travailler "au black"

Je ne vois pas où tu veux en venir.

Dans ce cas, qu'entends-tu par "prendre en compte uniquement la partie maximum pour les cardinalités" ? que 0,n et 1,n c'est kifkif pareil ? que 0,1 et 1,1 c'est blanc bonnet et bonnet blanc ?