Modélisation d'une base de données pour une entité faible

Question

J'ai 2 tables dans ma base de données orders y orderHistory .

 -----------------                    -----------------------
 |  orders       |                    |  orderHistory       |
 -----------------                    -----------------------
 | orderID  (PK) |                    | historyLineID  (PK) |
 | orderDate     |                    | status              |
 | price         |                    | quantity            |
 -----------------                    -----------------------

Aujourd'hui, un order peut avoir plusieurs history lines . Toutefois, un history line ne peut exister seule. J'ai entendu dire qu'il s'agissait d'une entité faible et que, par conséquent, la PK de orders doit faire partie de la PK de la table orderHistory .

Questions

1. S'agit-il vraiment d'une entité faible relation ? Existe-t-il d'autres moyens de les identifier ?
2. Dois-je ajouter le PK de la table order à la table orderHistory et en faire une clé primaire composite ?
3. Au cas où je déciderais d'ajouter un nouvel enregistrement à orderHistory Comment ajouter une nouvelle clé composite ? ( orderID est disponible dans le tableau orders pero historyLineID doit être incrémenté automatiquement).
4. Que se passe-t-il si je décide de modéliser cela comme une activité normale ? D'un à plusieurs relation où orderID est ajouté en tant que clé étrangère seulement Quels sont les inconvénients d'une telle démarche ?
5. Le fait d'ignorer les entités faibles posera-t-il des problèmes plus tard dans la conception, à condition que toutes les tables soient dans la troisième forme normale ?

Note

Les deux orderID & historyLineID sont des clés de substitution. Merci d'avance.

Answer 1

Une entité n'est pas faible parce qu'elle ne peut pas exister de manière indépendante, mais parce qu'elle ne peut être identifiée indépendamment. Par conséquent, une relation qui "mène" à une entité faible est appelée relation "d'identification". Dans la pratique, cela signifie que la clé primaire du parent est migrée vers (généralement) la clé d'identification de l'entité. approprié ) du PK de l'enfant (le terme "entité faible" est généralement défini en relation avec les clés primaires, bien qu'il puisse en théorie s'appliquer à n'importe quelle clé).

Il est tout à fait 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, qui est dans une relation de non-identification avec un non-NULL.

Il faut se poser la question : est-ce que historyLineID être unique seul ou en combinaison avec orderID ? Je soupçonne que c'est le cas, ce qui en ferait une entité faible.

S'agit-il vraiment d'une relation d'entité faible correcte ?

Ce que vous nous avez montré n'est pas une entité faible - le PK du parent n'est pas transféré dans le PK de l'enfant.

Existe-t-il d'autres moyens de les identifier ?

Vous avez essentiellement deux options :

• orderHistory a un PK composite : {orderID, historyLineID} donde orderID est FK. BTW, ce PK pourrait être considéré comme "naturel" :

  

• orderHistory a un PK de substitution : {orderHistoryID} , tandis que orderID est en dehors du PK. Vous devrez toujours disposer d'une autre clé. {orderID, historyLineID} mais.. :

  

Dois-je ajouter la clé primaire de la table order à la table orderHistory et en faire une clé primaire composite ?

Oui, il s'agit de la première option décrite ci-dessus. À moins que vous n'ayez des relations enfantines sur orderHistory En soi, c'est aussi la meilleure solution. Si la orderHistory a des enfants, cette solution peut être ou ne pas être la meilleure, en fonction de plusieurs facteurs.

Que se passe-t-il si je décide de modéliser cette relation comme une relation normale de type One-To-Many où orderID est ajouté en tant que clé étrangère à la place ? quels sont les inconvénients de ce choix ?

Il ne s'agit pas de choisir entre l'un ou l'autre. Un champ peut être à la fois FK et faire partie d'une clé (primaire ou secondaire), comme indiqué ci-dessus.

Le fait d'ignorer les entités faibles posera-t-il des problèmes plus tard dans la conception, à condition que toutes les tables soient dans la troisième forme normale ?

Vous ne pourrez pas atteindre la 3NF si vous ne spécifiez pas correctement vos clés, et vous ne pourrez pas le faire sans tenir compte des entités qui peuvent être identifiées indépendamment et de celles qui ne peuvent pas l'être.

Answer 2

1. Il s'agit d'une relation d'entité faible en raison de la dépendance, mais il s'agit essentiellement d'un cas d'indécision. Une commande peut avoir une ou plusieurs lignes d'historique, mais chaque ligne d'historique doit avoir un identifiant de commande, n'est-ce pas ?

Cela ressemble à une relation facultative-obligatoire. Donc votre orderId a des attributs "optionnels" dans orderHistory... 2. Vous pouvez résoudre partiellement le problème en faisant de la clé primaire une composition de orderID et de historyLineID. 3. Vous devrez créer une relation involuée sur la table orderID. Vous devrez donc effectuer une jointure sur order.orderID, puis créer le nouveau historyLineID, sinon vous ne pouvez pas créer une relation sur quelque chose qui n'existe pas encore. 4. C'est ainsi qu'il faut procéder. C'est beaucoup plus facile à comprendre pour les personnes qui travailleront sur le script, et probablement pour vous-même. Utilisez la clé étrangère pour créer un orderID (parent) avec plusieurs historyLineID (enfants), parce que l'ordre peut avoir plusieurs lignes d'ordre, cette méthode serait probablement la meilleure.

LIEN : entrer la description du lien ici