Références circulaires dans la conception de base de données - Devraient-elles être évitées?

Question

Je suis actuellement en train de développer une base de données via MS Access 2003 et je suis resté bloqué par un problème de référence circulaire. En gros, cela revient au triangle de relation suivante (il est une forme simplifiée de ma table de relation):

     Positions 
       oo   oo 
       /    \ 
      /    \ 
      /     \ 
      /     \ 
      /      \ 
     /      \ 
     /       \ 
     /       \ 
     /        \ 
    /        \ 
     oo         oo 
    Employees oo -------------------- oo Software, 

où les postes, les employés et les logiciels sont les tables et "oo-------...-------oo" affiche les nombreux à plusieurs relations entre leur. En résumé, tous les employés d'une entreprise sont affectés à des postes spécifiques (certains d'entre eux sont affectés à plusieurs postes) et sont autorisés à utiliser des logiciels spécifiques en fonction de leur (s) poste (s) . Cependant, il existe des exceptions, et certains des employés ont le droit d'utiliser un certain nombre d'autres progiciels, en plus de ce qui leur est permis en fonction de leur (s) poste (s).

La question est, est-il acceptable d'autoriser une relation circulaire dans ce type de base de données? Existe-t-il des solutions de contournement qui ne nécessitent pas de dénormalisation?

Merci d'avance, VS.

Answer 1

Vous pouvez l'éviter en générant une nouvelle position pour chacune des exceptions. Un indicateur booléen pourrait alors être ajouté à la position pour différencier les positions génératrices réelles et exceptions, si nécessaire.

Answer 2

Vous devez normaliser correctement le DB. IMHO - Je n'utiliserais pas une relation dans la table des postes. Voici ce que je ferais

Tables

• employé
• Software
• EmployeeSoftware
• Position

Le tableau "POSITIONS" dans votre cas, je suppose, est vos rôles. Notez que la base de données doit être utilisée comme stockage et que la logique métier minimale doit y être placée. Cela dit, permettez-moi de ... continuer

Il y aura une relation entre l'employé et EmployeeSoftware (empid présente comme clé étrangère dans EmployeeSoftware. Le même pour le logiciel et EmployeeSoftware (SoftID présente comme clé étrangère dans la EmployeeSoftware.

L'application vérifie d'abord si une personne est dans une bonne position (POSITIONS) avant d'insérer un enregistrement.Pour un contrôle DB supplémentaire, vous pouvez ajouter une contrainte de vérification sur le logiciel EmployeeSoftware pour vérifier le DB POSITIONS avant ... il faut alors être une relation entre le logiciel et les positions

Answer 3

Votre diagramme est elliptique en ce sens que vous avez omis les tables de jointure N: N entre al vos entités. Ceux-ci font une énorme différence en ce qui concerne les effets secondaires des relations circulaires. Les relations Direct 1: N avec CASCADE DELETE peuvent provoquer de vrais problèmes et des blocages potentiels. Mais avec les tables N: N intermédiaires, vous ne devriez pas avoir ce problème, car CASCADE DELETE exécutera seulement "downhill" de la table 1 vers le N, et ne sauvegardera pas la chaîne de la table N: N vers l'autre table parent.

Il me semble que c'est un problème commun, isomorphe au problème d'adresse, c'est-à-dire., une personne peut avoir une adresse personnelle et hériter d'une adresse de l'employeur, et la solution de @Saif Khan d'éliminer l'héritage logiciel du poste est une forme de dénormalisation, en ce sens que vous avez fusionné deux relations d'entité complexes en une seule. Je ne sais jamais comment modéliser cela, non pas à cause de potentielles relations circulaires, mais à cause des problèmes de performance (et de non-modifiabilité) qui résultent de l'assemblage d'un seul ensemble de résultats de tous les logiciels/adresses, ce qui nécessite UNION. Je serais tenté d'utiliser un déclencheur pour dupliquer le logiciel hérité de la position avec un enregistrement reliant la personne au logiciel. Avant A2010, ceci n'était pas possible au niveau du moteur dans Access/Jet/ACE, mais A2010 a ajouté des macros de données au niveau de la table qui peuvent être utilisées pour implémenter l'équivalent des triggers. Cela pourrait être un cas où cette nouvelle fonctionnalité pourrait vous permettre d'implémenter cette structure avec des déclencheurs. Mais je ne suis pas sûr d'être à l'aise avec la duplication de données, même si les triggers vous permettent de synchroniser les données dupliquées au niveau du moteur.

Answer 4

Je pense que cette conception de la base de données devient trop compliquée à cause de la façon de gérer l'exception,

« certains des employés sont accordés à utiliser un petit nombre d'autres paquets logiciels , en plus ce qu'ils sont autorisés à selon leur position (s).

ne pas essayer de lier directement un employé à un logiciel.

Je voudrais juste créer une autre position parce que le but principal de la position dans ce cas est de déterminer l'accès au logiciel. Même si une personne a une liste unique de logiciels, ils seront remplacés à l'avenir et cette personne peut simplement se voir attribuer le (s) même (s) poste (s).

L'interrogation sera plus facile. Comme l'a souligné David-W-Fenton, vous allez devoir utiliser beaucoup de syndicats pour savoir qui peut utiliser quel logiciel ou vice versa.