la conception de base de données SQL

Question

Je fais une base de données pour un programme où je suis censé modéliser des relations dans la famille. ex: X est le père à Y, Y est fils X

Alors, j'ai un Membres table avec toutes les informations sur chaque membre donc je pensé à faire un plusieurs à plusieurs entre les balises Membres table et lui-même afin que le < strong> Member_Member table de bridge sera d'avoir les colonnes "FK_FromID, FK_ToID" comme la clé composite (est-ce correct?) et "FK_RelationType" en tant que clé étrangère RelationTypes la table qui aura le type de relation « Père, mère, fils, fille », et deux relations vont comme un à plusieurs de la table des membres à ces deux clés étrangères

Mon problème est : lors de la suppression si je décide en cascade alors je vais faire des cycles parce que si je supprime un membre alors il y aura deux passes de suppression aux documents relatifs à Member_Member pont, sachant que dans le programme chaque fois que j'insérer une relation père je vais insérer une relation fils aussi bien dans la table Member_Member, est-il un moyen ou une solution de contournement possible d'activer en cascade de sorte que chaque fois que je supprimer un membre, je vais supprimer les enregistrements connexes Member_member quel que soit d'être enregistré soit dans un ou une colonne de clé étrangère

Alors, je ne sais pas quoi faire, est-ce une conception correcte en premier lieu ou quoi? Que dois-je faire du vélo, aussi que pensez-vous une meilleure conception pour le même problème devrait être de savoir que j'ai besoin de préciser quel type de relation entre les deux parties

Merci beaucoup pour toute aide, et désolé pour le mauvais anglais Bishoy

Answer 1

SQL ne gère pas « réseau » des problèmes comme très bien.

Le tableau de pont-membre de l'ANRF est un nom terrible. Il est un « membre-parent » (ou « parent-enfant ») pont. tables de bridge ne devraient pas avoir une « clé composite ». tables de bridge ont une clé de substitution (juste un numéro séquentiel) et une paire de références FK à d'autres tables. Les deux FK de devrait avoir des noms comme « membre » et « parent » pour le rendre parfaitement clair ce que la relation est dans ce tableau.

Tout le monde a un parent. Pas tout le monde a des enfants. Certains parents ne seront pas avoir des parents dans cette base de données; ils sont les "top parents".

Il est plus facile si les premiers parents ont des lignes dans le pont parent-enfant avec un parent FK NULL. De cette façon, vous évitez extérieur-joint super-complexe - chaque membre a au moins une rangée parent membre; idéalement deux.

Vous trouverez de nombreuses questions « cyclistes » car les relations sont transitive.

Notez que vous ne pouvez pas - dans une seule requête SQL standard - trouver tous les membres de la famille, ou tous les parents de retour au sommet de la famille, ou tous les enfants et petits-enfants. Il existe des extensions SQL qui rendent cela possible, mais la norme ne gère pas bien.

La suppression en cascade ne fonctionne pas bien parce que les relations dans une famille sont dirigées de deux façons (parents aux enfants, aux parents des enfants), mais SQL n'a qu'un seul type de direction (référence FK).

Vous pouvez essayer d'assurer que chaque membre doit avoir au moins un (et au plus deux) lignes « membre-parent » et la suppression d'un membre supprime les deux lignes dans « Membre- parent » et les touches ont les noms propres, vous pourriez faire partie de ce travail.

Notez que lorsque vous supprimez un membre, ce qui va ramollir leurs relations parents. Vous supprimez la ligne parent-membre. C'est bon. Qu'en est-il de leurs enfants? Les autres lignes qui ont-parent membre faisant référence à ce parent supprimé sont maintenant rompus. Qu'est-ce que ça veut dire? Qu'est-ce qui devrait être fait?

  

Il n'y a pas standard réponse. Suppression de lignes à partir d'un graphe connexe laisse éléments   sans rapport. Vous devez élaborer des règles sensées pour cela.

Depuis SQL ne fait pas bien, tous les modèles seront semblent avoir des problèmes.

Answer 2

1. En supposant que chaque membre ne peut avoir une mère et un père, vous seriez en mesure de tirer toutes les relations en gardant simplement un champ de mother_id et father_id dans la table members.

   Cependant, cela ne fonctionne que si votre base de données pas ont des informations manquantes. Par exemple, si X est membre le frère de membre Y, il n'y aurait aucun moyen de savoir ce à moins que les parents de X et Y sont stockés dans la base de données.

   Si votre base de données ne sera pas d'avoir des informations manquantes, ce qui précède peut-être plus facile à gérer l'intégrité des données. Les requêtes peuvent obtenir un peu complexe cependant.

2. Le pont member_member vous suggérez a un problème grave car il implique une direction de la relation, de sorte que si X est le père de Y, Y est aussi le fils de X. Vous avez suggéré de définir la relation à deux reprises les deux sens, mais en général ce n'est pas recommandé. Ceci est une forme de duplication de données, et vous pouvez lutter pour faire respecter l'intégrité référentielle avec la duplication des données. Rappelez-vous que le SGBD ne sait pas que X est père de Y est le même que Y est le fils de X.

Je suis conscient que ce n'est pas une réponse complète, mais seulement quelques observations. Je suis totalement d'accord avec réponse de S. Lott comme il n'y a aucun moyen standard de « résoudre "cela avec bases de données relationnelles.