Toujours confus à propos de l'identification par opposition à la non-identification des relations
J'ai donc beaucoup lu sur les relations d'identification et de non-identification dans la conception de ma base de données, et un certain nombre de réponses sur SO semblent me contredire. Voici les deux questions que je regarde:
- Quelle est la différence entre des relations identifiantes et non identifiantes
- Difficulté à choisir une relation d'identification ou de non-identification
En regardant les principales réponses de chaque question, il me semble que je vois deux idées différentes de ce qu'est une relation d'identification.
La réponse à la première question indique qu'une relation d'identification "décrit une situation dans laquelle l'existence d'une ligne dans la table enfant dépend d'une ligne dans la table parent". Voici un exemple: "Un auteur peut écrire plusieurs livres (relation 1 à n), mais un livre ne peut exister sans un auteur". Cela a du sens pour moi.
Cependant, lorsque je lis la réponse à la question deux, je ne comprends pas ce qui est écrit: "Si un enfant identifie son parent, il s'agit d'une relation d'identification." La réponse continue ensuite en donnant des exemples tels que Numéro de sécurité sociale (identifiant une personne), mais une adresse n’est pas (car beaucoup de personnes peuvent vivre à une adresse). Pour moi, cela ressemble plus à un cas de décision entre une clé primaire et une clé non primaire.
Mon propre instinct (et des recherches supplémentaires sur d'autres sites) suggère que la première question et sa réponse sont correctes. Cependant, je voulais vérifier avant de continuer car je ne voulais pas apprendre quelque chose qui n'allait pas car je travaillais à comprendre la conception de la base de données. Merci d'avance.
La définition technique d'une relation d'identification est que la clé étrangère d'un enfant fait partie de sa clé primaire.
CREATE TABLE AuthoredBook (
author_id INT NOT NULL,
book_id INT NOT NULL,
PRIMARY KEY (author_id, book_id),
FOREIGN KEY (author_id) REFERENCES Authors(author_id),
FOREIGN KEY (book_id) REFERENCES Books(book_id)
);
Voir? book_id est une clé étrangère, mais c'est aussi l'une des colonnes de la clé primaire. Donc, cette table a une relation d'identification avec la table référencée Books. De même, il existe une relation d'identification avec Authors.
Un commentaire sur une vidéo YouTube a une relation d'identification avec la vidéo respective. Le video_iddevrait faire partie de la clé primaire de la table Comments.
CREATE TABLE Comments (
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
PRIMARY KEY (video_id, user_id, comment_dt),
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
Cela peut sembler difficile à comprendre car il est de pratique courante de n’utiliser qu’une clé de substitution en série au lieu d’une clé primaire composée:
CREATE TABLE Comments (
comment_id SERIAL PRIMARY KEY,
video_id INT NOT NULL,
user_id INT NOT NULL,
comment_dt DATETIME NOT NULL,
FOREIGN KEY (video_id) REFERENCES Videos(video_id),
FOREIGN KEY (user_id) REFERENCES Users(user_id)
);
Cela peut occulter des cas où les tables ont une relation d'identification.
Je considérerais pas que le SSN représente une relation d'identification. Certaines personnes existent mais n'ont pas de SSN. D'autres personnes peuvent déposer pour obtenir un nouveau SSN. Le SSN n'est donc en réalité qu'un attribut et ne fait pas partie de la clé primaire de la personne.
Commentaire de @Niels:
Ainsi, si nous utilisons une clé de substitution au lieu d'une clé primaire composée, il n'y a pas de différence notable entre une relation d'identification ou non d'identification?
Je suppose. J'hésite à dire oui, car nous n'avons pas changé la relation logique entre les tables en utilisant une clé de substitution. Autrement dit, vous ne pouvez toujours pas faire de commentaire sans faire référence à une vidéo existante. Mais cela signifie simplement que video_id doit être NOT NULL. Et l’aspect logique est, à mes yeux, vraiment l’objet de l’identification des relations.
Mais il y a aussi un aspect physique à identifier des relations. Et c'est le fait que la colonne de clé étrangère fait partie de la clé primaire (la clé primaire n'est pas nécessairement une clé composite, il peut s'agir d'une colonne unique qui est à la fois la clé primaire de Comments et la clé étrangère du tableau Vidéos. , mais cela signifierait que vous ne pouvez stocker qu'un commentaire par vidéo).
L'identification des relations semble n'être importante que pour les diagrammes entité-relation, ce qui se produit dans les outils de modélisation de données à interface graphique.
"comme je ne veux pas apprendre quelque chose de mal".
Eh bien, si vous le pensez vraiment, vous pouvez cesser de vous préoccuper du jargon et de la terminologie des urgences. C'est imprécis, confus, déroutant, pas du tout convenu, et pour la plupart non pertinent.
ER est un groupe de rectangles et de lignes droites dessinés sur un morceau de papier. ER est délibérément conçu pour être un moyen de modélisation informel. En tant que tel, il s’agit d’une première étape intéressante dans la conception de la base de données, mais c’est aussi cela: une première étape.
Jamais un diagramme ER ne doit s'approcher de la précision, de l'exactitude et de l'exhaustivité d'une conception de base de données formellement écrite en D.
Les relations d'identification/non-identification sont des concepts de la modélisation ER - une relation est une identification si elle est représentée par une clé étrangère faisant partie de la clé primaire de la table de référence. Cela est généralement très peu important dans les termes de modélisation relationnelle car les clés primaires du modèle relationnel et des bases de données SQL n’ont aucune signification ou fonction particulière comme dans un modèle ER.
Par exemple, supposons que votre table applique deux clés candidates, A et B. Supposons que A soit également une clé étrangère dans cette table. La relation ainsi représentée est considérée comme "identifiant" si A est désignée comme étant la clé "primaire", mais n'est pas identifiante si B est la clé primaire. Pourtant, la forme, la fonction et la signification du tableau sont identiques dans chaque cas! C'est pourquoi, à mon avis, je ne pense pas que le concept d'identification/non d'identification soit vraiment très important.
Je crois que la seule différence entre une relation identificatrice et non identifiante concerne la nullité de la clé étrangère. Si un FK ne peut pas être NULL, la relation qu'il représente est identifiante (l'enfant ne peut exister sans parent), sinon il ne l'identifie pas.
une partie de la question ici est la confusion de la terminologie. l'identification des relations est utile pour éviter les longs chemins de jointure.
La meilleure définition que j’ai vue est «une relation d’identification inclut la PC en tant que parent dans la PK de l’enfant. En d’autres termes, la PK de l’enfant comprend la FK du parent ainsi que la« réelle »PK de l’enfant.
Oui, allez avec le premier, mais je ne pense pas que le second contredit le premier. C'est juste formulé un peu déroutant ..
METTRE À JOUR:
Je viens de cocher - la réponse à la deuxième question est fausse dans certaines hypothèses, .. l'auteur du livre n'est pas nécessairement une relation 1: n, comme cela pourrait être m: n. Dans les bases de données relationnelles, une table d'intersection est créée pour cette relation m: n. Vous obtenez ainsi des relations d'identification entre la table d'intersection et ces 2 autres tables.
identification de la relation donne une relation optionnelle à plusieurs lorsque nous devons définir une relation parent-enfant. instance d'entité enfant identifiera l'entité parent instance.it est représenté par une ligne continue dans le diagramme.
où l'existence d'une instance d'entité enfant doit être une instance d'entité mère, mais chaque instance d'entité d'une entité enfant peut être liée à plusieurs instances d'entité d'entité mère L'entité mère est bien la clé étrangère de l'entité enfant, mais l'entité enfant ne prendra pas la clé primaire de l'entité mère en tant que clé primaire. . il faut donc le résoudre
Une relation d'identification est en effet un concept de DRE puisqu'il s'agit du domaine de la modélisation conceptuelle, modélisant notre compréhension de «l'univers du discours». Il s'agit d'une relation parent-enfant dans laquelle nous modélisons le fait que l'identité de chaque objet enfant est (au moins en partie) établie/déterminée par l'identité de l'objet parent. Il est donc obligatoire et immuable.
Un exemple concret est le défi constant d'identifier les personnes. L'identité unique d'une personne peut être (en partie) définie par sa relation avec son père et sa mère biologique. Lorsque connus, ce sont des faits immuables. Par conséquent, la relation entre parent de naissance et enfant est une relation d'identification en ce sens qu'elle contribue (immuablement) à définir l'identité de l'enfant.
Ce sont ces qualités et l'utilisation de constructions dbms relationnelles qui font que la PK de l'enfant est une clé composite qui inclut, via FK, la PK du parent. En tant que PK, l'identité de l'enfant est obligatoire et immuable (elle ne peut pas changer). Un 'changement' dans une PK instancie en fait un nouvel objet. Par conséquent, la PK ne doit pas pouvoir être modifiée. L’immuabilité d’une PC doit également être limitée. Les contraintes de base de données peuvent être utilisées pour implémenter cette qualité de PC.