Une entité n'est pas faible parce qu'elle ne peut pas exister indépendamment, mais parce qu'elle ne peut pas être identifiée indépendamment. Par conséquent, une relation qui "conduit" à une entité faible est appelée relation "identifiante". En pratique, cela signifie que la clé primaire du parent est migrée vers (généralement proper ) sous-ensemble de la PK de l'enfant (le terme "entité faible" est généralement défini par rapport aux clés primaires, bien qu'il puisse en théorie s'appliquer à n'importe quelle clé).
Il est parfaitement légitime d'avoir une entité qui ne peut pas exister indépendamment, mais qui peut être identifiée indépendamment - en d'autres termes, c'est-à-dire dans une relation non identifiante avec un non-NULL.
Vous devez demander :peut historyLineID être unique seul , ou en combinaison avec orderID ? Je soupçonne que ce dernier est le cas, ce qui en ferait une entité faible.
Ce que vous nous avez montré n'est pas une entité faible - la PK du parent n'est pas migrée vers la PK de l'enfant.
Vous avez essentiellement deux options :
-
orderHistorya un PK composé :{orderID, historyLineID}, oùorderIDest FK. BTW, ce PK pourrait être considéré comme "naturel":
-
orderHistorya un PK de substitution :{orderHistoryID}, tandis queorderIDest en dehors du PK. Vous aurez toujours besoin d'une clé alternative{orderID, historyLineID}cependant :
Oui, c'est la première option décrite ci-dessus. Sauf si vous avez des relations enfant sur orderHistory lui-même, c'est aussi la meilleure solution. Si orderHistory a des enfants, cela peut ou non être la meilleure solution, en fonction de plusieurs facteurs.
Ce n'est pas l'un ou l'autre. Un champ peut être à la fois FK et une partie d'une clé (primaire ou alternative), comme indiqué ci-dessus.
Vous ne pourrez pas atteindre 3NF à moins de spécifier correctement vos clés, et vous ne pourrez pas le faire sans considérer quelle entité peut être identifiée indépendamment et laquelle ne le peut pas.
