Une table enfant (A.K.A. entité faible ) est une table dont les attributs de clé primaire dépendent sur une autre table, donc la table enfant est identifiée ou partiellement identifié par lignes dans la table dont il dépend (parent). Les lignes d'une table enfant ne peuvent pas exister sans une ligne correspondante dans sa table parent.
Pour illustrer cela, prenons un exemple simple et tout à fait pertinent que nous connaissons tous :Parents et enfants dans le contexte de la famille . Nous pouvons modéliser cette relation avec des tables comme suit :
Dans le modèle ci-dessus, chaque ligne du Parents la table est identifiée de manière unique par un SSN . Le SSN est un attribut intrinsèque et unique à chaque parent, c'est donc une entité autonome ou "forte" car elle ne s'appuie pas sur une autre table pour définir son identité.
Cependant, les enfants exigent un parent pour exister (Parent_SSN doit référence à un SSN existant dans les Parents table).
Notez la clé primaire composite (Parent_SSN, Name ) dans les Children table. Cela signifie que les enfants sont identifiés de manière unique par la combinaison de Parent_SSN et Name . Vous ne pouvez pas interroger un enfant individuel en vous basant uniquement sur le Name car plusieurs parents peuvent avoir des enfants portant le même nom. De même, vous ne pouvez pas interroger un enfant individuel en vous basant uniquement sur le Parent_SSN car un parent peut avoir plusieurs enfants. Compte tenu de cela, les enfants sont partiellement identifiés par leur parent, donc identifiant relation.
Mais les enfants ne peuvent-ils pas également être identifiés de manière unique par un SSN ? Pourquoi oui, certainement. Allons-y et ajustons notre modèle pour inclure cela :
Dans cette version du modèle, notez que nous avons introduit le SSN champ pour Children . L'identité unique des enfants est désormais défini par leur propre SSN intrinsèque et unique . Leur identité ne dépend plus sur les Parents table. Bien que le Parent_SSN le champ fait toujours référence au SSN des Parents table, il n'a aucune part dans l'identité unique de l'enfant, les parents ont donc un non identifiant relation avec leurs enfants, et les deux tables peuvent désormais être considérées comme des entités autonomes "fortes".
Soit dit en passant, cette version du modèle présente quelques avantages par rapport à la première :
- Un parent peut désormais avoir deux enfants ou plus portant le même nom, alors que l'l'intégrité de l'entité contrainte dans le modèle précédent ne le permettait pas.
- Vous pouvez autoriser le
Parent_SSNle champ doit contenirNULLpour expliquer l'événement que vous avez des données sur l'enfant, mais ne savez pas qui est son parent.
Dans les deux modèles ci-dessus, les Parents table est considérée comme la table parente des Children table. Cependant, en non identifiant relations comme dans le deuxième modèle, Parents n'est qu'une table parent dans le contexte de la clé étrangère Parent_SSN parce que Parent_SSN références/dépend sur SSN dans les Parents table, mais ne le fait pas participer à la définition de l'identité réelle des enfants.
Pour illustrer pourquoi le contexte est important lorsqu'il s'agit de décider quelles tables sont des tables parent/enfant, considérons l'exemple suivant impliquant une dépendance circulaire :
Dans cet exemple, les employés et les services sont identifiés de manière unique par leurs propres attributs et ne tirent aucune partie de leur identité d'autres tables.
Ici, nous avons deux relations non identifiantes :un employé travaille pour un service (DeptNo dans le Employee table), et un département est géré par un employé (ManagerSSN dans le Department table). Laquelle est la table parent ? ...Table enfant ?
Cela dépend du contexte — de quelle relation de clé étrangère parlez-vous ? La table Department serait considérée comme la table parent dans le contexte de DeptNo dans le Employee table car DeptNo est référençant/dépendant sur le Department table.
Cependant, la table Employee serait considérée comme la table parent dans le contexte de ManagerSSN dans le Department table car ManagerSSN est référençant/dépendant sur le Employee tableau.
