Bonjour Hugo,
Envoyé par
Hugo_Loup
Il m'est demandé de justifier mes choix de traduction
On peut supposer qu’il s’agit des règles de passage du MCD au schéma relationnel.
En l’occurrence, conformément à l’usage (cf. l’ouvrage de référence de D. Nanci et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 243), je cite :
R1. « Toute entité-type est transformée en table. Ses propriétés deviennent les attributs de la table. L’identifiant devient la clé primaire de la table »
Nanci fait aussi la remarque suivante :
« l’entité ne comportant que l’identité comme propriété présente un cas particulier. Il devient provisoirement une table avec sa clé primaire comme seul attribut. Il est fort probable que les optimisations ultérieures fassent disparaître cette table. »
Oh que oui ! Il s’agit surtout de la sempiternelle entité-type DATE. JPhi33 en a très bien parlé ici ou là, en évoquant les travaux de Flory et Morejon. Voir aussi dans mon blog Merise et MCD : à propos de l’entité-type DATE.
Nanci continue à propos des règles de transformation, à savoir la transformation des associations binaires dont une cardinalité est 1,1 et l’autre est 0,N ou 1,N :
R2. « On duplique la clé de la table issue de l’entité-type à cardinalité (0,N) ou (1,N) dans la table issue de l’entité-type à cardinalité (1,1) où elle devient une clé étrangère »
Nanci traite aussi de l’identification relative (cf. pages 255 et 256) auquel cas
R3. la clé de la table issue de l’entité-type à cardinalité (0,N) ou (1,N) vient compléter la clé de la table issue de l’entité-type à cardinalité (1,1).
Et bien entendu, Nanci traite des sous-types (LIVRE et REVUE chez vous), je vous renvoie aux pages 251 et suivantes).
Bref, je vous engage à lire crayon en main les règles de transformation décrites par Nanci.
A propos de votre représentation « relationnelle » :
Vos identifiants reprennent exactement ceux qui vous ont été fournis, mais ce sont des identifiants naturels aussi je rappelle à nouveau que dans les projets professionnels on risque le bouillon si on ne met pas en oeuvre la règle d’or de Tabourier (identifiants artificiels, dépourvus de signification, donc invariants, donc garantissant la stabilité des liens entre tables au stade opérationnel). Non seulement on risque le bouillon, mais on en arrive à repartir à zéro, j’ai souvent assisté à ça au cours de mes décennies d’intervention ès matière !
Il y a un couac quant à la numérotation des revues. Vous écrivez en effet :
NUMEROTER (REF_OUV#, NUM#, TITRE_NUM, DATE_PARU) ;
NUM_REVUE (NUM, TITRE_NUM, DATE_PARU) ;
Je rappelle que la modélisation correcte au niveau du MCD est la suivante (cf. le post #2) :
[REVUE]----1,N----(Numeroter)----1,1(R)----[NUM_REVUE]
Dans ces conditions, conséquence de la cardinalité 1,1 portée par la patte connectant l’entité-type NUM_REVUE et l’association Numeroter, cette dernière n’a pas à faire l’objet d’une table. La modélisation correcte au niveau « relationnel » est la suivante, conformément au point R3 ci-dessus :
NUM_REVUE (REF_OUV#, NUM, TITRE_NUM, DATE_PARU) ;
Entité-type DIVERS
Envoyé par
fsmrel
Si vous prenez en compte les ouvrages autres que les livres et les revues, et qu’il soit en l’occurrence imposé de tenir compte de la date d’édition, vous pouvez définir à cet effet une entité-type ad-hoc, appelons-la par exemple DIVERS. C’est un sous-type d’OUVRAGE, au même titre que LIVRE et REVUE.
Vous avez fait l’impasse sur cette entité-type DIVERS. Selon l’énoncé proposé, vous pouvez « éventuellement envisager qu’il existe d’autres ouvrages », autrement dit on ne vous interdit pas de faire cette impasse, soit. Mais signalez que le jour où cela s’imposera, il ne sera pas compliqué de mettre en oeuvre une telle entité-type.
Je signale que votre schéma « relationnel » est inexploitable...
Ça n’est pas de votre faute, mais vous êtes victime de merisiens qui, il y a au moins 30 ans, inventèrent cette façon de représenter les tables et les relations qu’elles entretiennent. Par exemple, après avoir codé légalement et légitimement :
OUVRAGE (REF_OUV, TITRE_OUV) ;
par voie de conséquence vous êtes astreint à coder ainsi les tables REVUE et LIVRE :
REVUE (#REF_OUV, PERIODICITE) ;
LIVRE (#REF_OUV, NOM_EDIT, AN_EDIT) ;
Et le piège s’est refermé, pour chacune de ces tables, « #REF_OUV » symbolise la clé primaire et la clé étrangère faisant référence à la clé primaire de la table OUVRAGE, et comme vous êtes obligé d’en faire autant pour la table NUM_REVUE :
NUM_REVUE (REF_OUV#, NUM#, TITRE_NUM, DATE_PARU) ;
Une ambiguïté apparaît : il n’y a aucun moyen de savoir si la table NUM_REVUE fait référence à la table OUVRAGE ou à la table REVUE ou à la table LIVRE, car ces 3 tables ont la même clé primaire, symbolisée par REF_OUV# ! Le système imaginé il y a 3 décennies est inexploitable...
Cette ambiguïté affecte évidemment les tables ECRIRE, PRET, ASSOCIER.
L’AGL Looping est lui aussi victime de la faiblesse du mode représentation des schémas relationnels. Je lui ai soumis un MCD proche du vôtre, et voici ce qu’il produit :
OUVRAGE (REF_OUV, TITRE_OUV) ;
REVUE (#REF_OUV, PERIODICITE) ;
LIVRE (#REF_OUV, NOM_EDIT, AN_EDIT) ;
NUM_REVUE (#(#REF_OUV),NUM, TITRE_NUM, DATE_PARU) ;
Manifestement NUM_REVUE ne fait pas référence à OUVRAGE (deux symboles « # » au lieu d’un seul), Mais il reste une ambiguïté, car on ne peut pas savoir si c’est REVUE ou LIVRE qui est référencé...
Cela dit, je vous engage à utiliser Looping, car au moins le code SQL qu’il produit est sans ambiguïté.
Envoyé par
Hugo_Loup
Comment représenter la composition du mot clé et le parent et le fils ?
Je laisse le soin à Looping de vous montrer ce qu’il produit, mais on en reparlera.
Envoyé par
Hugo_Loup
Est-ce que je dois rajouter des clés dans certaines entités ?
Là encore, Looping vous montrera. Mais je reviendrai sur ce point.
On reviendra sur l’historisation, car selon votre table PRET, l’abonné A ne peut emprunter le livre L qu’une seule fois, or cette contrainte n’est pas mentionnée dans votre énoncé.
Partager