Difficulté à décider d'identifier ou non une relation

Question

J'ai lu cette question: quelle est la différence entre Identifier et non-identifier les relations?

Mais je ne suis toujours pas sûr… Ce que j’ai, c’est trois tables.

1. utilisateurs
2. Objets
3. photos

Un utilisateur peut posséder de nombreux objets et peut également publier plusieurs images par objet. Mon instinct me dit qu'il s'agit d'une relation d'identification, car j'aurai besoin de l'ID utilisateur dans la table d'objets et de l'ID objet dans les tables d'images ...

Ou est-ce que je me trompe? Les explications de l'autre sujet se limitent à l'explication théorique de la façon dont la base de données l'interprète après son codage, pas à la manière dont les objets sont connectés dans la vie réelle. Je suis un peu perplexe quant à la décision d’identifier ou non l’identification lorsque je réfléchis à la façon dont je vais construire la base de données.

Answer 1

Cela ressemble à l’identification de relations avec moi. Si vous avez déjà entendu les termes "un à un ou un à plusieurs" et plusieurs à plusieurs, les relations un à un sont des relations d'identification , et < les relations fortes sont des relations non identifiantes .

• Si l'enfant identifie son parent, il s'agit d'une relation d'identification. Dans le lien que vous avez indiqué, si vous avez un numéro de téléphone, vous savez à qui il appartient (il n’appartient qu’à un seul).

• Si l'enfant n'identifie pas son parent, il s'agit d'une relation non-identifiante. Dans le lien, il mentionne des états. Pensez à un état comme à une rangée dans un tableau représentant une humeur. "Heureux" n'identifie pas une personne en particulier, mais beaucoup de personnes.

Modifier : autres exemples concrets:

• Une adresse physique est une relation non identifiante, car de nombreuses personnes peuvent résider à une adresse. D'autre part, une adresse e-mail est (généralement considérée) une relation d'identification.
• Un numéro de sécurité sociale est une relation d'identification, car il n'appartient qu'à une seule personne
• Les commentaires sur les vidéos Youtube identifient des relations, car ils appartiennent à une seule vidéo.
• L'original d'un tableau n'a qu'un seul propriétaire (identifiant), alors que de nombreuses personnes peuvent posséder des réimpressions du tableau (non identifiantes).

Answer 2

Je pense qu'un moyen plus facile de visualiser cela consiste à vous demander si l'enregistrement enfant peut exister sans le parent. Par exemple, un élément de ligne de commande nécessite l'existence d'un en-tête de commande. Ainsi, un élément de ligne de commande doit avoir l'identifiant d'en-tête de commande dans sa clé. Il s'agit donc d'un exemple de relation d'identification.
D'autre part, des numéros de téléphone peuvent exister sans la propriété d'une personne, bien qu'une personne puisse avoir plusieurs numéros de téléphone. Dans ce cas, la personne à qui appartient le numéro de téléphone est une relation sans clé ni identification, car les numéros de téléphone peuvent exister indépendamment du propriétaire (le titulaire du numéro de téléphone peut donc être null alors que, dans l'exemple, , l'identifiant de l'en-tête de commande ne peut pas être nul.

Answer 3

  

NickC Said: les relations un à deux sont des relations identifiantes et les relations plusieurs à plusieurs sont des relations non identifiantes

L'explication me semble totalement fausse. Vous pouvez avoir:

• Relations non identifiantes entre deux personnes
• Relations un à plusieurs non identifiantes
• Relations d'identification un à un
• Relations d'identification un à plusieurs
• Relations d'identification de plusieurs à plusieurs

Imaginez que vous disposiez des tableaux suivants: client , produits et commentaires . Tous sont basés sur le customer_id existant dans la table cutomer . Par définition, par NickC , il ne devrait exister aucune relation d'identification de plusieurs à plusieurs. Toutefois, dans mon exemple, vous pouvez clairement voir que: Une rétroaction ne peut exister que si le Le produit pertinent existe et a été acheté par le client. Le client, les produits et le retour d'informations doivent donc être Identifier .

Vous pouvez consulter le manuel MySQL . , en expliquant comment ajouter des clés étrangères à MySQL Workbench.

Answer 4

Mahdi, ton instinct est correct. C'est une question en double et cette réponse surélevée n'est ni correcte ni complète. Regardez les deux premières réponses ici: différence entre les non-identifiants

Identifier ou non-identifier n’a rien à voir avec une identité. Demandez-vous simplement si le dossier enfant existe sans le parent. Si la réponse est oui, il ne s’identifie pas.

La question principale est de savoir si la clé primaire de l'enfant inclut la clé étrangère du parent. Dans la relation non identifiante, la clé primaire (PK) de l'enfant ne peut pas inclure la clé étrangère (FK).

Posez-vous cette question

• L'enregistrement enfant peut-il exister sans l'enregistrement parent?

Si l'enfant peut exister sans le parent, la relation n'est pas identifiante. (Merci à MontrealDevOne de l'avoir précisé plus clairement)

Relation d'identification un à un

Les numéros de sécurité sociale entrent bien dans cette catégorie. Imaginons par exemple que les numéros de sécurité sociale ne puissent exister sans personne (peut-être en réalité, mais pas dans notre base de données) Le person_id correspond au PK de la table personne , y compris des colonnes telles qu'un nom et une adresse . (restons simples). La table social_security_number inclurait la colonne ssn et la colonne id_personne en tant que clé étrangère. Étant donné que ce FK peut être utilisé comme PC pour la table social_security_number , il s'agit d'une relation d'identification.

Relation sans identification un à un

Dans un grand complexe de bureaux, il se peut que vous disposiez d'une table bureau comprenant les numéros de salle par étage et par numéro d'immeuble avec un PK, ainsi que d'une table employé distincte. La table des employés (enfant) a un FK qui est la colonne office_id de la table office . Bien que chaque employé n'ait qu'un seul bureau et (pour cet exemple) chaque bureau ne compte qu'un seul employé, il s'agit d'une relation non identifiante, car les bureaux peuvent exister sans employés et les employés peuvent changer de bureau ou travailler sur le terrain.

Relations un à plusieurs

Les relations un à plusieurs peuvent être classées facilement en posant la même question.

Relations plusieurs à plusieurs

Les relations plusieurs à plusieurs identifient toujours des relations. Cela peut sembler contre-intuitif, mais supportez-moi. Prenez deux tableaux libary et livres , chaque bibliothèque contient de nombreux livres. Un exemplaire de chaque livre existe dans de nombreuses bibliothèques.

Voici ce qui le rend et identifie la relation: Pour implémenter cela, vous avez besoin d'une table de liaison avec deux colonnes qui sont les clés primaires de chaque table. Appelez-les la colonne id_bibliothèque et la colonne ISBN . Cette nouvelle table de liaison n'a pas de clé primaire séparée, mais attendez! Les clés étrangères deviennent une clé primaire à plusieurs colonnes pour la table de liaison, car les enregistrements en double dans la table de liaison n'auraient aucune signification. Les liens ne peuvent exister sans les parents; par conséquent, il s'agit d'une relation d'identification. Je sais, beurk pas vrai?

La plupart du temps, le type de relation n'a pas d'importance.

Tout cela étant dit, vous n'avez généralement pas à vous soucier de ce que vous avez. Attribuez simplement les clés primaires et étrangères appropriées à chaque table et la relation se découvrira d'elle-même.

EDIT: NicoleC , j'ai lu le répondez à votre lien et il est en accord avec le mien. Je prends son point sur le SSN et conviens que c’est un mauvais exemple. Je vais essayer de trouver un autre exemple plus clair ici. Cependant, si nous commençons à utiliser des analogies du monde réel pour définir une relation de base de données, celles-ci sont toujours brisées. Peu importe qu’un SSN identifie une personne, qu’il soit utilisé ou non comme clé étrangère.