Encore confus à propos de l’identification et des relations non identifiables

Donc, j’ai lu sur l’identification des relations non-identifiantes dans ma conception de firebase database, et un certain nombre de réponses sur SO me semblent contradictoires. Voici les deux questions que je regarde:

  1. Quelle est la différence entre les relations d’identification et de non-identification
  2. Problème lors de la détermination de la relation d’identification ou de non-identification

En regardant les principales réponses à chaque question, je semble avoir deux idées différentes sur 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”. Un exemple de ceci est donné, “Un auteur peut écrire beaucoup de livres (relation de 1 à n), mais un livre ne peut pas exister sans un auteur.” Cela a du sens pour moi.

Cependant, quand je lis la réponse à la deuxième question, je m’embrouille car elle dit: «si un enfant identifie son parent, il s’agit d’une relation d’identification». La réponse continue en donnant des exemples tels que le numéro de sécurité sociale (identifie une personne), mais une adresse ne l’est pas (car de nombreuses personnes peuvent vivre à une adresse). Pour moi, cela ressemble plus à un cas de décision entre clé primaire et clé non primaire.

Mon propre instinct (et des recherches supplémentaires sur d’autres sites) indique la première question et sa réponse est correcte. Cependant, je voulais vérifier avant de continuer, car je ne veux pas apprendre quelque chose de mal alors que je travaille à comprendre la conception de la firebase database. 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 a une relation d’identification avec les Authors .

Un commentaire sur une vidéo YouTube a une relation d’identification avec la vidéo correspondante. Le video_id doit 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) ); 

Il peut être difficile de comprendre cela car c’est une pratique courante de nos jours d’utiliser uniquement une clé de substitution 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 masquer les cas où les tables ont une relation d’identification.

Je ne 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. Ainsi, le SSN n’est en réalité qu’un atsortingbut qui ne fait pas partie de la clé primaire de la personne.


Re commentaire de @Niels:

Donc, 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 l’utilisation identifiant ou la relation non identifiante?

Je suppose. J’hésite à dire oui, car nous n’avons pas modifié la relation logique entre les tables en utilisant une clé de substitution. En d’autres termes, vous ne pouvez toujours pas faire de commentaire sans référencer une vidéo existante. Mais cela signifie simplement que video_id doit être NOT NULL. Et l’aspect logique est, à mes yeux, l’idée d’identifier les relations.

Mais il y a aussi un aspect physique de l’identification 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 seule colonne qui est à la fois la clé primaire de Comments et la clé étrangère du tableau Videos). , mais cela signifie que vous ne pouvez stocker qu’un seul commentaire par vidéo.

L’identification des relations ne semble être importante que dans l’intérêt de la création de diagrammes d’entités et de relations, et cela se produit dans les outils de modélisation des données de l’interface graphique.

“comme je ne veux pas apprendre quelque chose de mal”.

Welll, si vous voulez vraiment dire ça, alors vous pouvez cesser de vous soucier du jargon et de la terminologie des ER. C’est imprécis, confus, déroutant, pas du tout généralement accepté, 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 destiné à être un moyen de modélisation informelle . En tant que tel, il s’agit d’une première étape utile dans la conception de bases de données, mais c’est aussi cela: une première étape.

Jamais un diagramme ER n’atteindra la précision, l’exactitude et l’exhaustivité d’une conception de firebase database formellement écrite en D.

Les relations d’identification / non-identification sont des concepts de la modélisation ER – une relation étant une relation d’identification si elle est représentée par une clé étrangère faisant partie de la clé primaire de la table de référencement. Cela a généralement peu d’importance en termes de modélisation relationnelle, car les clés primaires dans le modèle relationnel et dans les 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 étant “identifiant” si A est désigné comme étant la clé “primaire”, mais elle est non identifiante si B est la clé primaire. Pourtant, la forme, la fonction et la signification de la table sont identiques dans chaque cas! C’est pourquoi, à mon avis, le concept d’identification / non-identification est vraiment très important.

Je crois que seule la différence entre une relation d’identification et une relation non identifiante concerne la nullité de la clé étrangère. Si un FK ne peut pas être NULL, la relation qu’il représente s’identifie (l’enfant ne peut exister sans parent), sinon il n’est pas identifiable.

La confusion de la terminologie est une partie du problème. 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 PK comme du parent dans la PK de l’enfant. En d’autres termes, la PK de l’enfant inclut le FK au parent ainsi que la PK” réelle “de l’enfant.

Oui, allez avec le premier, mais je ne pense pas que le second contredit le premier. C’est juste un peu déroutant.

METTRE À JOUR:

Il suffit de vérifier – 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, car il pourrait être m: n. Dans les bases de données relationnelles qui créent une table d’intersection pour cette relation m: n, vous obtenez des relations d’identification entre la table d’intersection et les 2 autres tables.

identifier la relation donne une à plusieurs relations optionnelles quand il faut définir parent à enfant relationship.in plus il donne une à une seule relation entre enfant et parent. Depuis la clé primaire de l’entité parent sera la partie de la clé primaire de l’entité enfant, L’instance d’entité enfant identifie l’entité parente instance.it est représentée par un trait continu dans le diagramme.

où une relation non identifiante aura une relation entre plusieurs entités.L’existence d’une instance d’entité enfant doit avoir une instance d’entité parent mais chaque entité d’entité enfant peut être liée à plusieurs entités d’entité parentale. l’entité parent est bien la clé étrangère de l’entité enfant, mais l’entité enfant ne prend pas la clé primaire de l’entité parent comme clé primaire. Elle aura sa propre clé primaire. la relation plusieurs à plusieurs n’existe pas dans le diagramme du monde réel. il doit donc être résolu