Discussion :

[BLeguillou]

Bonjour,

Comment modéliser ceci :
Relation d’Entité1 vers Entité2 : Entité1 a 0-n Entité2
Relation d’Entité2 vers Entité1 : Entité2 a 1-1 Entité1
Et
Relation d’Entité1 vers Entité3 : Entité1 a 0-n Entité3
Relation d’Entité3 vers Entité1 : Entité3 a 0-1 Entité1
Et
Relation d’Entité2 vers Entité3 : Entité2 a 1-n Entité3
Relation d’Entité3 vers Entité2 : Entité3 a 0-1 Entité2

Cordialement.

[fsmrel]

Bonjour,


Brut de décoffrage (réalisé avec DB-MAIN, gratuit) :

[BLeguillou]

Merci fsmrel pour ta promptitude à répondre aux discussions. Et ou est donc passé SQLPRO ?

J'ai modélisé la même solution (voir ci-dessous).

En fait mon problème était de savoir si c'était le meilleur modèle. Est-ce qu'on pouvait l'améliorer ou pas. Une subtilité que je n'aurai pas identifié ?

les cardinalités ont quelques peu évoluées par rapport à mon message:

Relation d’Entité1 vers Entité2 : Entité1 a 0-n Entité2
Relation d’Entité2 vers Entité1 : Entité2 a 1-1 Entité1
Et
Relation d’Entité1 vers Entité3 : Entité1 a 1-n Entité3
Relation d’Entité3 vers Entité1 : Entité3 a 1-1 Entité1
Et
Relation d’Entité2 vers Entité3 : Entité2 a 1-n Entité3
Relation d’Entité3 vers Entité2 : Entité3 a 0-1 Entité2

voici mon résultat réalisé avec VS2013 :

[fsmrel]

Puisque les clés étrangères sont mises en oeuvre (présence par exemple de l’attribut IdE1 dans la table (et non plus entité-type) Entity3), cela veut dire qu’on a quitté le niveau Entité-Relation (ou Entité-Association) pour le niveau relationnel : pas de problème.

Cela dit, le loup s’introduit dans la bergerie : la patte d’association connectant Entity3 à Entity2 est porteuse d’une cardinalité 0,1, c’est-à-dire que le bonhomme NULL sera présent dans la déclaration de la table Entity3. Pour éviter cela, on met en œuvre une table Entity4 de la façon suivante (n’ayant pas VS, j’utilise MySQL Workbench) :





Les clés primaires sont symbolisées par des clés en jaune. La couleur jaune est remplacée par la couleur rouge pour les clés primaires qui sont aussi des clés étrangères.

Les losanges en rouge symbolisent les clés étrangères (non clés primaires) et les losanges bleus les attributs non clés (et non nulls...)
la table Entity4 est dotée d’une clé étrangère {IdE2} branchée sur Entity2, et {IdE2} est aussi clé alternative de Entity4 (cette clé alternative est symbolisée par le mickey que j’ai ajouté à la main, car si MySQL Workbench permet de définir des clés alternatives, il ne les représente pas dans les diagrammes).

La patte d’association entre Entity3 et Entity4 est de type 1,1/1,1. Le trait est plein, ce qui entraîne que la clé étrangère {IdE3} branchée sur Entity3 est aussi clé primaire de Entity4 (où la clé en jaune est donc remplacée par une clé en rouge).


Maintenant, la mise en oeuvre de la table Entity4 fait qu’il existe une bijection entre Entity3 et Entity4 : la clé primaire {Ide3} de Entity3 doit logiquement être aussi clé étrangère par rapport à Entity4, d’où, là aussi, changement de couleur imposé, de jaune à rouge... :



Mais attention aux bijections !


A propos des contraintes de chemin : L’ensemble L1 de lignes de la table Entity4 récupérées par le chemin Entity1 > Entity2 > Entity4 n’est pas forcément égal à l’ensemble L2 de lignes récupérées par le chemin Entity1 > Entity3 > Entity4 : peut-être y a-t-il des contraintes d’égalité, d’inclusion, voire d’exclusion à prévoir, en fonction des règles de gestion des données associées à la base de données, car le moteur de votre SGBD (quel est-il ?) peut très bien avoir la fantaisie de changer souvent de chemin au fil du temps, d’où des résultats pouvant se révéler fâcheusement variables (il en va de même dans le cas de votre diagramme)...