81 votes

Toujours Confus au Sujet de l'Identification ou Non, l'Identification des Relations

Donc, j'ai lu sur l'identification ou la non-identification des relations dans ma conception de base de données, et un certain nombre de réponses sur DONC sembler contradictoire pour moi. Voici les deux questions que je suis en train de regarder:

  1. Quelle est la Différence Entre l'Identification et la Non-Identification des Relations
  2. Difficulté à prendre une décision sur l'Identification ou la Non-Identification de la Relation

En regardant les principales réponses de chaque question, il semble que je reçois deux idées différentes de ce que l'identification de la relation.

La première question, la réponse dit que l'identifiant de la relation "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 ce qui est donné est, "Un auteur peut écrire de nombreux livres (1 à n), mais un livre ne peut exister sans un auteur." Qui fait sens pour moi.

Cependant, quand j'ai lu la réponse à la question deux, je m'embrouille comme il le dit, "si un enfant s'identifie à ses parents, c'est un identifiant de la relation." La réponse va ensuite à donner des exemples comme le SSN (est l'identification d'une Personne), mais l'adresse n'est pas (parce que beaucoup de gens peuvent vivre à une adresse). Pour moi, cela sonne plus comme un cas de la décision entre la clé primaire et de clé non primaire.

Ma propre intuition (et d'autres recherches sur d'autres sites) points à la première question et sa réponse est correcte. Cependant, je voulais vérifier avant que je continue d'avancer comme je ne veux pas apprendre quelque chose de mal, comme je suis en train de travailler pour comprendre la conception de base de données. Merci à l'avance.

163voto

Bill Karwin Points 204877

La définition technique de l'identification de la relation est un enfant de la clé étrangère est une partie de la 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 dispose d'un identifiant de la relation avec la table référencée Books. De même, il a une identification relation avec Authors.

Un commentaire sur une vidéo YouTube a un rapport avec la vidéo correspondante. L' video_id devrait être une partie de la clé primaire de la Comments table.

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 ce parce que c'est pratique courante de nos jours d'utiliser seulement une série de clé de substitution à la place d'un composé clé primaire:

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 identification de la relation.

Je voudrais pas envisager SSN pour représenter un identifiant de la relation. Certaines personnes existent, mais n'ont pas un numéro de sécurité sociale. D'autres personnes peuvent déposer pour obtenir un nouveau numéro de sécurité sociale. Ainsi, le SSN est vraiment juste un attribut, ne fait pas partie de la clé primaire.


Re commentaire de @Niels:

Donc si l'on utilise une clé de substitution à la place d'un composé de la clé primaire, il n'y a pas de différence notable entre l'utilisation de l'identification ou de la non-identification de la relation ?

Je suppose donc. J'hésite à dire oui, parce que nous n'avons pas changé la logique de la relation entre les tables à l'aide d'une clé de substitution. Qui est, vous ne pouvez toujours pas faire un Commentaire sans faire référence à une Vidéo existante. Mais cela signifie simplement video_id doit PAS être NULL. Et la logique aspect est vraiment, pour moi, le point sur l'identification des relations.

Mais il y a un aspect physique de l'identification de relations. Et c'est le fait que la colonne de clé étrangère est une partie de la clé primaire (clé primaire n'est pas nécessairement une clé composite, il pourrait être une seule colonne qui est à la fois la clé primaire de Commentaires ainsi que la clé étrangère de la table de Videos, mais cela voudrait dire que vous pouvez stocker qu'un seul commentaire par vidéo).

Identifier les liens semblent être important uniquement pour le bien de l'entité-relation de création de diagrammes, et cela vient en GUI outils de modélisation de données.

20voto

Erwin Smout Points 7499

"comme je ne veux pas apprendre quelque chose de mal".

Enfin, si vous avez vraiment dire que, ensuite, vous pouvez cesser de s'inquiéter ER le jargon et la terminologie. Il est imprécis, confus, déroutant, pas du tout consensus général, et pour la plupart sans importance.

ER est un tas de rectangles et les lignes droites tracées sur une feuille de papier. ER est délibérément destiné à être un moyen informel de modélisation. En tant que tel, il est un précieux première étape dans la conception de base de données, mais il est aussi juste que : une première étape.

Jamais un ER diagramme obtenir n'importe où près de la précision, de l'exactitude et de l'exhaustivité de la base de données de conception officiellement écrit à D.

11voto

sqlvogel Points 12567

L'identification et la non-identification des relations sont des concepts dans ER la modélisation - une relation d'identification s'il est représenté par une clé étrangère qui fait partie de la table de référence de la clé primaire. C'est généralement de très peu d'importance dans la modélisation relationnelle, parce que les clés primaires dans le modèle relationnel et SQL les bases de données n'ont aucune signification spéciale ou de la fonction comme ils le font dans une salle d'urgence modèle.

Par exemple, supposons que votre table, applique les deux candidats les touches A et B. Supposons que A est aussi une clé étrangère dans la table. La relation ainsi représenté est réputé être "l'identification" si l'Un est désigné pour être le "principal", mais c'est la non-identification si B est la clé primaire. Pourtant, la forme, la fonction et la signification de la table est identique dans tous les cas! C'est pourquoi, à mon avis, je ne pense pas que l'identification / la non-identification concept est vraiment très important.

9voto

Pankaj Jha Points 41

Je crois que la seule différence entre un identifiant et non de l'identification de la relation est au sujet de la possibilité de valeur null de la clé étrangère. Si un FK ne peut pas être NULLE, la relation qu'il représente est l'identification (l'enfant ne peut pas exister sans parent) sinon c'est la non identification des.

7voto

user1335419 Points 152

une partie de la question ici, c'est la confusion de la terminologie. identifier les liens sont utiles pour éviter de longs chemins de jointure.

La meilleure définition que j'ai vu est "une identification relation comprend le PK de la mère à l'enfant PK. En d'autres termes, le PK de l'enfant comprend la FK à la société mère ainsi que le "réel" PK de l'enfant.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X