Modélisation - Référence circulaire

Bonjour,

J'ai une réflexion concernant les références circulaires lors de modélisation d'une base de données et je souhaiterais un regard externe nouveau.

Admettons le cas de figure suivant avec deux entités : une entité équipe et une entité membre. J'aimerais représenter le fait qu'une équipe possède des membres dont un membre principal. Un membre est unique et peut être assignée à une seule équipe à la fois.

Une possibilité est de créer deux associations : une première, une équipe possède un ou plusieurs membres (1..N) et une deuxième, une équipe possède un et un seul membre principal (1..1). En traduisant ce modèle au niveau logique, je me retrouve avec deux tables correspondant aux deux entités : équipe et membre. La première association va se traduire en un clé étrangère non-null dans la table membre référençant la table équipe. La seconde, en une clé étrangère non-null dans la table équipe référençant la table membre. Je me retrouve donc avec une référence circulaire qui est d'autant plus problématique que les deux clés étrangères sont obligatoires. L'ajout de données est donc impossible.

Une autre possibilité est de conserver toujours les deux entités précédemment mentionnées, mais uniquement la première association, une équipe possède un ou plusieurs membres (1..N). Afin de représenter le membre principal, j'ajoute un attribut principal à mon entité membre. Afin de garantir qu'une équipe possède un et un seul membre principal, je mets en place une contrainte CHECK au niveau du MLD. La transformation vers le modèle logique ne pose pas de problème (deux tables, une clé étrangère et la contrainte CHECK) et l'insertion non plus également vu qu'il n'y a plus de référence circulaire.

La possibilité n°2 me plaît moins : la représentation de la règle du membre principal unique et obligatoire par équipe n'y est plus bien représentée dans le modèle conceptuel et l'insertion de données induit une opération de contrôle supplémentaire. De plus, la récupération du membre principal est légèrement plus compliquée.

Un regard externe est le bienvenu, je prends peut-être le problème du mauvais côté.

À titre annexe, les technologies utilisées sont SQL Server comme SGBD et EntityFramework 6.X au niveau applicatif pour la persistence.

Par avance merci pour vos réponses !

Les deux sont valable, et ont toutes un inconvénient.

• Dans la première il faut veiller que le lien de la seconde association se fasse pour un membre déjà dans la première ce qui suppose une contrainte d'inclusion à faire par déclencheur.
• Dans la seconde vous avez remarqué qu'il fallait aussi une contrainte. Mais il est impossible de la faire par CHECK. Il faut soit un index UNIQUE filtré soit un déclencheur.

Dans les deux cas se modèle ne présente aucun référence circulaire.

Personnellement je préfère toujours séparer les fonctions. Donc 2 associations. Comme cela elles pourront évoluer différemment (deux règles de gestion distincte => 2 objets de gestion...)

A +

C'est quasi le même problème que j'ai posé il y a quelques jours :

https://www.developpez.net/forums/d1...cheval-tables/

Une contrainte sur une vue m'a permis de répondre au problème de manière élégante.

Merci à vous deux pour vos réponses.

@SQLPro, j'ai également une préférence pour la première. En revanche, comment cela se passe-t-il avec les contraintes non-nulles ?

https://image.prntscr.com/image/9xru...bJe78iu0uA.png

La contrainte d'inclusion est en place garantissant ainsi qu'un membre principal est forcément un membre de l'équipe. Maintenant, mes deux clés étrangères (MembrePrincipalID et EquipeID) sont obligatoires car un membre doit avoir une équipe et une équipe doit avoir un membre principal. Ces contraintes non-nulles bloquent totalement l'insertion. Qui doit être créé en premier, l'équipe ou le membre ?

@StringBuilder, le sujet est intéressant, mais je n'arrive pas à comprendre comment celui-ci peut résoudre ma situation.

Citation:

---

Envoyé par DcNe49

La contrainte d'inclusion est en place garantissant ainsi qu'un membre principal est forcément un membre de l'équipe. Maintenant, mes deux clés étrangères (MembrePrincipalID et EquipeID) sont obligatoires car un membre doit avoir une équipe et une équipe doit avoir un membre principal. Ces contraintes non-nulles bloquent totalement l'insertion. Qui doit être créé en premier, l'équipe ou le membre ?

---

posez-vous la question à l'envers :

• une équipe peut elle exister sans membre ? (non)
• Un membre existe t-il sans équipe ? (oui)

Conclusion : saisir en premier les membres et en second les équipes formés de membre.

N'oubliez pas qu'une base de données s'attaque par les vues, pas par les table. Votre application doit donc lire et mettre à jour à travers les vues


A +

Alors effectivement, je m'étais posé la question à l'envers. Vu sous cet angle, cela résout le problème.

Citation:

---

N'oubliez pas qu'une base de données s'attaque par les vues, pas par les table. Votre application doit donc lire et mettre à jour à travers les vues

---

Ce que vous dites m'interpelle. J'ai toujours utilisé directement les tables que ce soit dans des DAO "standards" ou avec un ORM (EntityFramework actuellement, mais JPA et implémentations par le passé). Si vous avez encore un peu de temps à consacrer, je suis volontiers intéressé pour en savoir plus !

Encore merci

La remarque au sujet des vues est essentiellement justifiée par l'indépendance physique des données : quand vous utilisez des vues, vous libérez les traitements des contingences liées aux modifications faites sur les structures.
il existe d'autres intérêts possibles à l'accès via des vues : mise à disposition de colonnes calculées, simplification d'accès, restriction sur des colonnes sensibles...

Au niveau des droits, ça permet aussi par exemple de gérer des droits au niveau des lignes à l'aide de "CURRENT_USER"
=> Si la vue filtre les lignes pour lesquelles CURRENT_USER est autorisé (via une table d'affectation par exemple) alors on peut gérer des droits à la ligne. C'est impossible avec des droits "standard".

Pour les vues, si vous voulez ne pas montrer la liste des équipes qui ne contiennent pas encore un membre il suffit d'écrire :

Code:

---

1 2 3 4 5

CREATE VIEW V_EQUIPE AS SELECT * FROM EQUIPE AS E WHERE EXISTS(SELECT * FROM MEMBRE WHERE MEMBRE_ID = E.EMBRE_ID)

---

N'oubliez pas que vous pouvez faire des INSERT, UPDATE et DELETE sur les vues....

A +