Passage d'un MCD avec ternaire vers un MRD

Bonjour,

j'ai un problème avec le passage d'un mcd avec ternaire vers un mrd.
J'ai deux solution proposée mais je ne sais pas quelle solution est plus approprié et pourquoi.

Considérez le mcd suivant:
(Il n'y a pas d'énoncé, il faut juste transformer le mcd en mrd)
(1)
Pièce jointe 497192
Pour la première solution je me suis orienté à la première réponse de fsmrel https://www.developpez.net/forums/d6...tion-ternaire/
Ca devient donc
Pièce jointe 497195
Et le passage en MRD
Pièce jointe 497198
Dans la deuxième solution la relation2 dans (1) devient une table en MRD
Pièce jointe 497199

P.S.
Vous connaissez une site internet avec des énoncés et éventuellement des réponse pour le pratiquer ?

Bonsoir StrongKobayashi,

Citation:

---

Envoyé par StrongKobayashi

J'ai deux solution proposée mais je ne sais pas quelle solution est plus approprié et pourquoi.

---

Rappel de quelques notions de base du modèle relationnel de données (défini par E. F. Codd il y a 50 ans), traduites ici en SQL :

Une notion essentielle est celle de clé candidate (en abrégé clé s’il n’y a pas de confusion possible).

Une clé candidate K (sous-ensemble de colonnes) d’une table T doit vérifier les contraintes suivantes :

Unicité : Deux lignes distinctes de T ne peuvent pas avoir simultanément la même valeur pour K.
Irréductibilité : Il n’existe pas de sous-ensemble strict de K garantissant la contrainte d’unicité.

Parmi ces clés l’une sera choisie pour être clé primaire, auquel cas les autres seront reléguées au rang de clés alternatives ⁽¹⁾.

Examinons votre diagramme :

Pièce jointe 497199

Le triplet I1 = {ID0, ID1, ID2} ne peut pas être clé primaire de la table relation2 car la contrainte d’irréductibilité des clés candidates n’est pas respectée.

En effet, selon vos MCD, la patte d’association connectant l’entité-type entite1 et l’association relation2 est porteuse d’une cardinalité max 1, ce qui se traduit au stade MLD par la dépendance fonctionnelle :

{ID1} → {ID2}

La colonne ID2 doit donc être sortie du triplet I1, lequel est réduit à la paire I2 = {ID0, ID1}.

Par ailleurs, la patte d’association connectant l’entité-type entite2 et l’association relation0 est porteuse d’une cardinalité max 1, ce qui se traduit au stade MLD par la dépendance fonctionnelle :

{ID2} → {ID0}

Par application de l’axiome de transitivité des axiomes et règles d’Armstrong, il existe la dépendance fonctionnelle :

{ID1} → {ID0}

La colonne ID0 doit donc être sortie de la paire I2, laquelle est à réduire au singleton {ID1} qui respecte les contraintes d’unicité et d’irréductibilité : {ID1} est clé candidate.

A ton tour, {ID2} est clé candidate. En effet on a montré qu’il existe {ID2} → {ID0}, et par ailleurs la patte d’association connectant l’entité-type entite2 et l’association relation2 est porteuse d’une cardinalité max 1, ce qui se traduit au stade MLD par la dépendance fonctionnelle :

{ID2} → {ID1}

La table relation2 possède deux clés candidates, {ID1} et {ID2} : l’une sera clé primaire et l’autre clé alternative (clause UNIQUE en SQL).


_________________________________________
⁽¹⁾ Le distinguo clé primaire/alternative est en fait parfaitement inutile, mais il existait jadis dans la théorie relationnelle (année 1970), et depuis a subi un coup de rasoir d’Ockham en 1993. En SQL il serait plus difficile d’en faire autant (pensez au nombre de tables en production dans le monde dans lesquelles figurent la clause « Primary Key »...)