Question Quelle est la différence entre une relation d'identification et une relation non-identifiante?


Je n'ai pas été capable de saisir complètement les différences. Pouvez-vous décrire les deux concepts et utiliser des exemples concrets?


702
2018-04-18 05:04


origine


Réponses:


  • Un relation d'identification est lorsque l'existence d'une ligne dans une table enfant dépend d'une ligne dans une table parent. Cela peut être déroutant, car il est de nos jours coutume de créer une pseudokey pour une table enfant, mais ne pas rendre la clé étrangère à la partie parent de la clé primaire de l'enfant. Formellement, la "bonne" façon de le faire est de faire de la clé étrangère une partie de la clé primaire de l'enfant. Mais la relation logique est que l'enfant ne peut pas exister sans le parent.

    Exemple: A Person a un ou plusieurs numéros de téléphone. Si ils avaient juste un numéro de téléphone, nous pourrions simplement le stocker dans une colonne de Person. Puisque nous voulons prendre en charge plusieurs numéros de téléphone, nous faisons une deuxième table PhoneNumbers, dont la clé primaire comprend le person_id référencer le Person table.

    Nous pouvons penser au (x) numéro (s) de téléphone comme appartenant à une personne, même s'ils sont modélisés comme des attributs d'une table distincte. Ceci est un indice fort que c'est une relation d'identification (même si nous n'incluons pas littéralement person_id dans la clé primaire de PhoneNumbers).

  • UNE relation non-identifiante est quand les principaux attributs clés du parent ne doit pas deviennent les principaux attributs clés de l'enfant. Un bon exemple de ceci est une table de recherche, comme une clé étrangère sur Person.state référençant la clé primaire de States.state. Person est une table d'enfant par rapport à States. Mais une rangée de Person n'est pas identifié par son state attribut. C'est à dire. state ne fait pas partie de la clé primaire de Person.

    Une relation non identifiante peut être optionnel ou obligatoire, ce qui signifie que la colonne de clé étrangère autorise NULL ou n'autorise pas NULL, respectivement.


Voir aussi ma réponse à Toujours confus au sujet des relations d'identification par opposition aux relations non identifiantes


944
2018-04-18 05:59



Il y a une autre explication du monde réel:

Un livre appartient à un propriétaire, et un propriétaire peut posséder plusieurs livres. Mais, le livre peut exister aussi sans le propriétaire, et la propriété de celui-ci peut changer d'un propriétaire à l'autre. La relation entre un livre et un propriétaire est une relation non-identifiante.

Un livre, cependant, est écrit par un auteur, et l'auteur aurait pu écrire plusieurs livres. Mais, le livre doit être écrit par un auteur - il ne peut pas exister sans un auteur. Par conséquent, la relation entre le livre et l'auteur est une relation d'identification.


818
2018-03-06 12:54



Une relation d'identification spécifie qu'un objet enfant ne peut pas exister sans l'objet parent

Les relations non identifiantes spécifient une association régulière entre objets, cardinalité 1: 1 ou 1: n.

Les relations non identifiantes peuvent être spécifiées comme optionnelles lorsqu'un parent n'est pas obligatoire ou obligatoire lorsqu'un parent est requis en réglant le cardinalité de la table parent ...


20
2018-04-18 05:45



Voici une bonne description:

Les relations entre deux entités peuvent être classées comme étant «identificatrices» ou «non identificatoires». Les relations d'identification existent lorsque la clé primaire de l'entité parente est incluse dans la clé primaire de l'entité enfant. D'un autre côté, une relation non-identifiée existe lorsque la clé primaire de l'entité parente est incluse dans l'entité enfant mais pas dans la clé primaire de l'entité enfant. De plus, les relations non identifiantes peuvent être classées comme étant «obligatoires» ou «non obligatoires». Une relation obligatoire non identifiante existe lorsque la valeur de la table enfant ne peut pas être nulle. D'un autre côté, une relation non-obligatoire non-identifiable existe lorsque la valeur de la table enfant peut être nulle.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Voici un exemple simple de relation d'identification:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Voici une relation non-identifiante correspondante:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

13
2018-04-18 05:51



La réponse de Bill est correct, mais il est choquant de voir que parmi toutes les autres réponses, personne ne pointe l'aspect le plus significatif.

On dit à maintes reprises que, dans l'identification et la relation, l'enfant ne peut pas exister sans le parent. (par exemple. user287724). C'est vrai, mais manque complètement le point. Il suffirait que la clé étrangère soit non-null, pour y parvenir. Il n'a pas besoin de faire partie de la clé primaire.

Alors voici la vraie raison:

Le but d'une relation d'identification est que la clé étrangère ne peut jamais changer, parce que cela fait partie de la clé primaire ... donc identifier !!!


13
2017-07-04 12:39



comment user287724 deuxième exemple de réponse de la relation entre le livre et l'auteur a 576 vote ups? !!! , comme il dit:

Un livre est cependant écrit par un auteur, et l'auteur aurait pu écrire plusieurs livres. Mais le livre doit être écrit par un auteur, il ne peut pas exister sans un auteur. Par conséquent, la relation entre le livre et l'auteur est une relation d'identification.

c'est un exemple très confus et est définitivement pas un exemple valide pour un identifying relationship.

Je comprends enfin la différence entre les deux relations: ((alors, s'il vous plaît ne me confondez pas avec ce nombre de votes!


oui, un livre ne peut pas être écrit sans au moins un auteur, mais l'auteur (c'est la clé étrangère) du livre est PAS D'IDENTIFICATION le livre dans la table des livres!

vous pouvez retirer l'auteur (FK) de la rangée du livre et vous pouvez toujours identifier la rangée du livre par un autre champ (ISBN, ID, ... etc), MAIS PAS l'auteur du livre !! 

Je pense qu'un exemple valide d'un identifying relationship serait la relation entre (table de produits) et un (tableau de détails de produit spécifique) 1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

dans cet exemple, le Product_ID dans le printers_details table est considérée comme un FK fait référence à la products.id table et AUSSI un PK dans le printers_details table, il s'agit d'une relation d'identification car le Product_ID (FK) dans la table des imprimantes EST IDENTIFIER la ligne à l'intérieur de la table enfant, nous ne pouvons pas supprimer le product_id de la table enfant car nous ne pouvons plus identifier la ligne car nous avons perdu sa clé primaire

si vous voulez le mettre en 2 lignes:

une relation d'identification est la relation lorsque le FK dans le   table enfant est considérée comme PK (ou identifiant) dans la table enfant tout en   fait toujours référence à la table parente

un autre exemple peut être lorsque vous avez 3 tables (importations - produits - pays) dans un import et export pour une base de données de pays

la import la table est l'enfant qui a ces champs(the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) nous pouvons utiliser le (product_id, country_id) pour identifier chaque ligne des imports "s'ils sont tous dans la même année" ici les deux colonnes peuvent composer ensemble une clé primaire dans la table enfant (imports) et référençant également des tables parent.

s'il vous plaît je suis heureux, je comprends enfin le concept de la identifying relationship et non identifying relationship  : ((( , alors s'il vous plaît ne me dites pas que je me trompe avec tous ces votes pour un exemple complètement invalide

oui logiquement un livre ne peut être écrit sans un auteur mais un livre peut être identifié sans l'auteur, en fait il ne peut être identifié à l'auteur!

vous pouvez 100% retirer l'auteur de la rangée de livres et encore identifier le livre !!! , s'il vous plaît ne me dites pas que j'ai mal compris le concept :(


8
2018-06-01 20:07



Relation non-identifiante

Une relation non-identifiante signifie qu'un enfant est apparenté au parent mais peut être identifié par le sien.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

La relation entre ACCOUNT et PERSON est non-identifiante.

Relation d'identification

Une relation d'identification signifie que le parent est nécessaire pour donner une identité à l'enfant. L'enfant existe uniquement à cause du parent.

Cela signifie que la clé étrangère est également une clé primaire.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

La relation entre ITEM_LANG et ITEM est identifiable. Et entre ITEM_LANG et LANGUAGE aussi.


7
2018-05-22 14:31



La relation d'identification signifie que l'entité enfant dépend totalement de l'existence de l'entité mère. Exemple de table de personnes de table de comptes et de table de personnes. La table de comptes de personnes est identifiée par l'existence de la table de comptes et de personnes seulement.

La relation de non-identification signifie que la table enfant n'est pas identifiée par l'existence de la table parente Par exemple, il existe une table en tant que accounttype et la table account.accounttype n'est pas identifiée avec l'existence de la table de comptes.


3
2018-04-01 18:47



Si vous considérez que l'élément enfant doit être supprimé lorsque le parent est supprimé, il s'agit d'une relation d'identification.

Si l'élément enfant doit être conservé même si le parent est supprimé, alors il s'agit d'une relation non identifiante.

À titre d'exemple, j'ai une base de données de formation avec des stagiaires, des formations, des diplômes et des sessions de formation:

  • les stagiaires ont une relation d'identification avec les sessions de formation
  • les formations ont une relation d'identification avec les sessions de formation
  • mais les stagiaires ont une relation non-identifiante avec les diplômes

Seules les sessions de formation devraient être supprimées si l'un des stagiaires, de la formation ou du diplôme est supprimé.


3
2018-01-09 15:40



Les attributs migrés d'un parent à l'autre aident-ils? identifier1 l'enfant?

  • Si Oui: la dépendance d'identification existe, la relation s'identifie et l'entité enfant est "faible".
  • Si ne pas: la dépendance d'identification n'existe pas, la relation est non-identifiante et l'entité enfant "forte".

Notez que la dépendance à l'identification implique la dépendance à l'existence, mais pas l'inverse. Chaque FK non NULL signifie qu'un enfant ne peut pas exister sans parent, mais cela ne suffit pas à l'identifier.

Pour en savoir plus (et quelques exemples), jetez un coup d'œil à la section «Identification des relations» du Guide des méthodes ERwin.

P.S. Je me rends compte que je suis (extrêmement) en retard à la fête, mais je pense que d'autres réponses ne sont pas tout à fait exactes (en termes de dépendance à l'existence plutôt que de dépendance à l'identification) ou quelque peu sinueuses. Espérons que cette réponse apporte plus de clarté ...


1 Le FK de l'enfant fait partie de la contrainte PRIMARY KEY ou (non-NULL) UNIQUE de l'enfant.


2
2018-01-21 07:25