Salve omnes,
A propos des CIF complètes, dépliées et compactées.
Prenons le cas d’une association ternaire, pour la quelle existe la dépendance fonctionnelle au sens Merise (voir l’ouvrage de référence de D. Nanci (RIP) et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au paragraphe "Contraintes intra–relation", page 114) :
E1 X E2 → E3
Cette dépendance fonctionnelle fait l’objet d’une CIF dépliée(1):
Quant à la production du code SQL, je fais référence à ce qu’a écrit Paprick :
Envoyé par
Paprick
Looping se contente de retirer, dans la clé primaire de l'association, l'identifiant de la classe d'entités ciblée par la CIF.
A réfléchir donc pour les prochaines versions...
Ainsi, avec Looping, l’association A donne lieu en SQL à la table A :
Code SQL (1)
CREATE TABLE A
(
e1Id INT,
e2Id INT,
e3Id INT NOT NULL,
CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
Supposons maintenant qu’il existe une dépendance fonctionnelle supplémentaire :
E2 X E3 → E1
Le MCD devient :
Au stade SQL, tout va bien, la table A est enrichie d’une clé alternative {e2Id, e3Id} :
Code SQL (2)
CREATE TABLE A
(
e1Id INT,
e2Id INT,
e3Id INT NOT NULL,
CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
CONSTRAINT A_AK UNIQUE(e2Id, e3Id),
CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
Pour alléger le MCD, on peut se contenter d’une représentation compacte(2), en fléchant la cible de la CIF (cf. l’ouvrage cité, Figure 7.25, page 118, ainsi que le document Afcet de 1990, où figure l’article d’Yves Tabourier, à voir pages 45 et suivantes, et en particulier la représentation des CIF, page 49). Avec Looping, pour reprendre la 1re dépendance fonctionnelle :
E1 X E2 → E3
Le MCD devient :
Mais l’affaire se corse (chef-lieu Ajaccio) quand il s’agit de représenter la 2e dépendance fonctionnelle :
E2 X E3 → E1
En effet, le MCD suivant :
donne lieu au code SQL :
Code SQL (3)
CREATE TABLE A(
e2Id INT,
e1Id INT NOT NULL,
e3Id INT NOT NULL,
CONSTRAINT A_PK PRIMARY KEY(e2Id),
CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
Looping s’est contenté de retirer l’attribut e1Id dans la clé primaire {e1Id, e2Id} de la table (e1Id étant l'identifiant de la classe d'entités ciblée par la 2e CIF).
Cela dit, quelle que soit sa représentation, dépliée ou compacte, une CIF est une CIF, et le code SQL produit ne doit pas dépendre de sa représentation. A mon sens, dans tous les cas, seul le code SQL (2) est valide et justifié.
Autre observation :
Pour être complet, la 3e dépendance fonctionnelle
E1 X E3 → E2
est aussi exprimable au moyen d’une CIF :
Et donne lieu au code SQL irréprochable :
Code SQL (4)
CREATE TABLE A
(
e1Id INT,
e2Id INT,
e3Id INT NOT NULL,
CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
CONSTRAINT A_AK UNIQUE(e1Id, e3Id),
CONSTRAINT A_1_AK UNIQUE(e2Id, e3Id),
CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
D'avance, merci Paprick ! 
__________________
(1) Pour modéliser une CIF avec Looping, voir par exemple ici.
(2) Pour compacter la CIF avec Looping, cliquer sur la patte connectant l’entité-type E3 et l’association A, et une fois ouverte la fenêtre « Cardinalité », cocher la case « Entité ciblée par CIF ».
CIF dépliées et compactées
Répondre avec citation
.
), je remplace sans problème tel ou tel UNIQUE par PRIMARY KEY, car aujourd’hui le choix de la Miss relève plus de la psychologie que de la science...
). La mise sous cloche pourrait donc prendre des allures de mise aux oubliettes avec jet de la clé dans la Garonne (fleuve le plus proche de chez moi 
Partager