Bonsoir,
Envoyé par
gwadajm
Je ne comprend pas très bien la différence entre modèle conceptuel et relationnel.
Le modèle conceptuel de données (MCD) est essentiellement un diagramme représentant les données selon un certain formalisme (Merise dans votre cas) et qui à terme seront reprises dans des structures de tables au niveau dit logique, selon un modèle logique de données au sens de Merise (MLD).
Exemple de MCD réalisé avec l’AGL Power AMC :
Commandes_MCD.png)
Si on demande à Power AMC de traduire ce diagramme en diagramme logique (tabulaire), voici que l’on obtient :
Commandes_MLD_riche.png)
Ce qui se lit :
Un client peut avoir passé des commandes (le mickey «
Commandes_0,N.png)
» signifie 0,n) ;
Une commande fait référence à exactement un client (le mickey « | » signifie 1,1) ;
Une commande est composée d’au moins un article (le mickey «
Commandes_1,N.png)
» signifie 1,n) ;
Etc.
Commandes_MLD_austere.png)
Les entités-types CLIENT, COMMANDE, ARTICLE sont devenues des schémas de tables au niveau logique (tabulaire). Les identifiants de ces tables (attributs soulignés) sont devenus des clés dites primaires (symbolisées par le mickey <pk>, abréviation de primary key).
La patte merisienne connectant l’entité-type COMMANDE et l’association-type PasserCommande est porteuse d’une cardinalité 1,1 : elle a donné lieu à une contrainte référentielle symbolisée par le lien connectant des tables COMMANDE et CLIENT. Simultanément, l’attribut ClientId de la table CLIENT a été recopié dans la table COMMANDE. Le mickey <fk> qui l’accompagne signifie que l’attribut ClientId fait l’objet d’une clé étrangère (foreign key) : la contrainte ainsi exprimée signifie que les valeurs prises par l’attribut ClientId de la table COMMANDE ne peuvent être que des valeurs prises par l’attribut ClientId de la table CLIENT.
Contrairement à l’association-type PasserCommande, l’association-type Composer ne fait pas l’objet d’une clé étrangère mais d’une table, parce qu’une commande fait référence à plus d’un article et réciproquement. Par définition, la clé de la table Composer est constituée de l’ensemble des attributs qui composent les clés des tables connectées, en l’occurrence COMMANDE et ARTICLE. L’association-type Composer étant porteuse de la propriété (ou attribut) Quantite, à son tour la table Composer est aussi porteuse de cet attribut.
Cas de la généralisation/spécialisation (héritage)
Votre MCD comporte une généralisation des clients (entité-type CLIENT) et des employés (entité-type EMPLOYE) donnant lieu à une entité-type PERSONNE dont les attributs valent simultanément pour les clients et les employés CLIENT et EMPLOYE.
Commandes_Heritage_MCD.png)
Au niveau du MLD, les trois entités-types donnent chacune lieu à une table. La clé de la table PERSONNE est recopiée dans les tables CLIENT et EMPLOYE :
Commandes_Heritage_MLD.png)
Cas de la pseudo entité-type DATE :
Votre MCD comporte cette entité-type. Il faut bien savoir que sa présence est une conséquence de la règle merisienne selon laquelle l’identifiant d’une association-type est composé des identifiants des entités-types connectées : le seul moyen de faire participer la date à l’identifiant de l’association-type consiste en conséquence en une astuce vaseuse, à savoir mettre en œuvre cette prétendue entité-type DATE et la brancher sur l’association-type. La règle merisienne aurait pu être autre, mais en débattre nous entraînerait loin, du côté de l’aménagement du métamodèle...
En tout cas, une chose est sûre, au niveau logique il n’y a pas de table DATE (le type DATE suffit amplement !) Parmi ses attributs, votre table INTERVENIR comportera l’attribut DateIntervention, qui participe à la clé de la table, en compagnie des attributs Num_i (provenant de l’entité-type INTERVENTION) et Id_Personne (provenant transitivement de l’entité-type PERSONNE).
Certains n’utilisent pas de représentation graphique et usent de conventions pour traduire les objets sous forme de tables. Par exemple :
PERSONNE {PersonneId, PersonneTel, PersonneAdresse}
CLIENT {PersonneId, RaisonSociale, NoSiren}
Etc.
Ici, façon CinePhil, les clés primaires sont soulignées, les clés étrangères en italiques (la combinaison des deux est évidemment possible, comme dans le cas de la table CLIENT). Cette façon de procéder est courante. Il existe aussi pas mal de variantes. Par exemple :
VAR BASE RELATION PERSONNE {PersonneId, PersonneTel, PersonneAdresse}
Commandes_Tab.png)
KEY {PersonneId} ;
VAR BASE RELATION CLIENT {PersonneId, RaisonSociale, NoSiren}
KEY {PersonneId}
KEY {NoSiren}
FOREIGN KEY {PersonneId} REFERENCES PERSONNE ;
Etc.
Société de services
Répondre avec citation
) ... Et puis vérifiez la cohérence des cardinalités.
)
) et ajouter une propriété montant_facturation et une propriété date_facturation dans l'entité intervention. 
).
(je trouve juste que ça fait un peu trop pour faire des tests chez soi).
Partager