Modélisation de la 1-à-plusieurs
Si la relation est 1 parent à de nombreux enfants (le même enfant ne peut appartenir à un seul parent), l'approche standard de modélisation consiste à faire référence Table parent de la table enfant, via (l'une des) colonnes de la clé du parent, généralement la clé primaire du parent (PK). En même temps, il est aussi une bonne idée de contrainte de clé étrangère (FK) sur la colonne de référence (child.PARENT_ID) pour encourager les SGBDR à appliquer referential integrity à travers la relation:
parent
-------------
PARENT_ID PRIMARY KEY, // PK for the parent table
OTHER_COL
...
child
-------------
CHILD_ID PRIMARY KEY, // PK for the Child Table
PARENT_ID // <-- Should this column be here? = Yes
CONSTRAINT FK_ChildParent FOREIGN KEY(PARENT_ID) REFERENCES parent(PARENT_ID)
Le nombre supplémentaire: table n parent_has_children est redondant, car il aura exactement une ligne par child, et il deviendra bientôt un fardeau de garder cette table en synchronisation avec les lignes ajoutées/supprimées des autres tables (comme l'échec de garder cette synchronisation entraînera une confusion/contradiction dans le l'intégrité de la relation).
Re: Comment les parents connaissent-ils leurs enfants?
dossiers d'enfants pour un parent donné peuvent être trouvés à l'aide d'une simple requête sur la table d'enfant filtrée sur la colonne de clé étrangère mère:
SELECT ...
FROM child
WHERE PARENT_ID = myParentId;
Comme cela est généralement une requête commune, il est toujours une bonne L'idée est de s'assurer que la clé étrangère child.PARENT_ID est indexée - certaines versions du SGBDR le font pour toutes les clés étrangères par défaut.
CREATE INDEX IXFoo on child(PARENT_ID);
Si vous avez un modèle d'entité (par ex.pour un ORM) dans une application représentant ces tables, l'entité parente aura généralement une collection contenant ses instances child, et sur l'entité enfant, la clé étrangère scalaire child.PARENT_ID 'column' est soit complètement supprimée, soit remplacée par une référence à un par exemple du parent:
class Parent
{
ParentId,
Child[] Children,
// ...
}
class Child
{
ChildId,
Parent Parent, // Optional, allows bidirectional navigation
// ...
}