Une entité faible peut-elle avoir une clé primaire?
Désolé pour une question probablement très basique, mais dans la littérature et en ligne, j'ai rencontré deux définitions différentes d'entités faibles, qui peuvent parfois être contradictoires.
1) Une entité faible est une entité qui ne peut exister sans une autre entité (propriétaire).
2) L'entité faible n'a pas de clé primaire, mais plutôt une clé partielle, et ne peut être identifiée de manière unique qu'en combinant cette clé partielle avec une clé étrangère de l'entité propriétaire.
Laquelle de ces affirmations est vraie? Prenons l'exemple de la relation Clients-> Commandes, où les commandes ont un ID de commande unique. Ici, une Commande ne peut pas exister sans un Client, mais elle a toujours sa propre clé primaire. Serait-ce alors une entité forte ou faible?
La clé primaire est un moyen de distinguer une ligne d'une même table de toutes les autres lignes de cette même table. Ce n'est pas un moyen de distinguer une ligne dans le contexte de ses lignes associées des autres tables.
Parfois, la clé primaire d'une table se compose d'une seule colonne. L'identifiant utilisateur d'une personne en serait un exemple.
Parfois, il est composé de plusieurs colonnes. Un emplacement est à la fois la latitude et la longitude. C'est ce qu'on appelle une clé composée. Parfois, une ou plusieurs de ces colonnes peuvent également être une clé étrangère. C'est ce qu'on appelle un type d'entité faible.
Pour prendre votre exemple, une seule ligne du tableau des commandes peut-elle être distinguée de toutes les autres lignes par le seul numéro de commande? En règle générale, oui. Le numéro de commande est unique sur l'ensemble du système. Donc, étant donné le numéro de commande 8765, nous savons que c'est pour le client A. Cela fait de Order un type d'entité solide.
Que diriez-vous de la table OrderLine? Étant donné un numéro de ligne de commande unique, disons "1", pourrions-nous trouver sans ambiguïté à quel ordre se rapporte? Généralement non, car les numéros de ligne de commande recommencent pour chaque commande. OrderLine est donc une entité faible car sa clé primaire (numéro de commande, numéro de ligne de commande) nécessite la clé primaire d'une autre table associée, à savoir Order.
Ainsi, selon les règles entreprise, il est insensé qu'une commande existe sans le client, mais selon les règles base de données, c'est OK. Un OrderLine ne peut pas exister sans l'Ordre selon l'un ou l'autre ensemble de règles.
Ce sont deux définitions correctes. Les commandes sont une entité solide. Il existe par lui-même. OrderItems, cependant, serait faible. Il a un numéro de commande (clé étrangère) et un numéro de ligne (clé partielle). Il est uniquement identifié de manière unique avec les deux.
Les entités faibles ont des clés primaires composites.
http://www.ques10.com/p/3828/we-can-convert-any-entity-set-to-a-strong-entity-s/
Considérons un ensemble d'entités Payment qui a trois attributs: payment_no, payment_date et payment_amount. Bien que chaque entité de paiement soit distincte, le paiement de prêts différents peut partager le même numéro de paiement. Ainsi, cet ensemble d'entités n'a pas de clé primaire et c'est un ensemble d'entités. Chaque ensemble faible doit faire partie d'un ensemble de relations un-à-plusieurs. Un ensemble d'entités faible est requis pour les raisons suivantes:
- Pour éviter les incohérences causées par la duplication de la clé de l'entité forte.
je. Bien qu'un ensemble d'entités faible puisse être converti en un ensemble d'entités fort en ajoutant simplement des attributs appropriés, cette approche entraîne le stockage redondant de la clé primaire.
ii. La clé primaire d'un ensemble d'entités faibles peut être déduite de sa relation avec l'ensemble d'entités fortes. Si nous ajoutons des attributs de clé primaire à l'ensemble d'entités faibles, ils seront présents à la fois dans l'ensemble d'entités et dans l'ensemble de relations et ils doivent être identiques.
iii. Par conséquent, il y aura redondance dans le diagramme ER et nous perdons le concept de dépendance.
iv. Dans l'exemple mentionné ci-dessus, l'ajout d'un attribut de clé primaire à l'ensemble d'entités faibles Payment entraîne un stockage redondant de la clé primaire.