Quelle est la différence entre les relations d'identification et de non-identification?

Je n'ai pas pu saisir pleinement les différences. Pouvez-vous décrire les deux concepts et utiliser des exemples du monde réel?

• Une 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 courant de nos jours de créer un pseudokey pour une table enfant, mais pas de créer la clé étrangère de la partie parent de la clé primaire de l'enfant. Officiellement, la «bonne» façon de procéder consiste à intégrer la clé étrangère à la clé primaire de l'enfant. Mais la relation logique est que l'enfant ne peut pas exister sans le parent.

  Exemple: A Persona un ou plusieurs numéros de téléphone. S'ils n'avaient qu'un seul 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 créons une deuxième table PhoneNumbers, dont la clé primaire inclut le person_idréférencement de la Persontable.

  Nous pouvons penser que le ou les numéros de téléphone appartiennent à une personne, même s'ils sont modélisés comme des attributs d'une table distincte. Ceci est un indice fort qu'il s'agit d'une relation d'identification (même si nous n'incluons pas littéralement person_iddans la clé primaire de PhoneNumbers).

• Une relation non identifiable se produit lorsque les attributs de clé primaire du parent ne doivent pas devenir des attributs de clé primaire de l'enfant. Un bon exemple de ceci est une table de recherche, telle qu'une clé étrangère pour Person.stateréférencer la clé primaire de States.state. Personest une table enfant par rapport à States. Mais une ligne Personn'est pas identifiée par son stateattribut. Ie statene fait pas partie de la clé primaire de Person.

  Une relation non identificatrice peut être facultative ou obligatoire , ce qui signifie que la colonne de clé étrangère autorise NULL ou interdit NULL, respectivement.

Voir aussi ma réponse à Toujours confus à propos des relations d'identification et de non-identification

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 également exister 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 identificatrice.

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 exister sans un auteur. Par conséquent, la relation entre le livre et l'auteur est une relation d'identification.

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

On répète encore et encore que, dans une relation d'identification, l'enfant ne peut exister sans le parent. (par exemple user287724 ). C'est vrai, mais il manque complètement le point. Il suffirait que la clé étrangère soit non nulle pour y parvenir. Il n'a pas besoin de faire partie de la clé primaire.

Voici donc la vraie raison:

Le but d'une relation d'identification est que la clé étrangère ne puisse JAMAIS CHANGER , car elle fait partie de la clé primaire ... donc d' identification !!!

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 les objets, la cardinalité 1: 1 ou 1: n.

Les relations non identifiantes peuvent être spécifiées comme facultatives lorsqu'un parent n'est pas requis ou obligatoires lorsqu'un parent est requis en définissant la cardinalité de la table parent ...

Voici une bonne description:

Les relations entre deux entités peuvent être classées comme "identifiantes" ou "non identifiantes". Les relations d'identification existent lorsque la clé primaire de l'entité parent est incluse dans la clé primaire de l'entité enfant. En revanche, une relation non identificatrice existe lorsque la clé primaire de l'entité parent est incluse dans l'entité enfant mais pas en tant que partie de la clé primaire de l'entité enfant. En outre, les relations non identifiantes peuvent être classées comme étant "obligatoires" ou "non obligatoires". Une relation non identificatrice obligatoire existe lorsque la valeur de la table enfant ne peut pas être nulle. En revanche, une relation non identificatrice non obligatoire existe lorsque la valeur dans la table enfant peut être nulle.

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

Voici un exemple simple d'une relation d'identification:

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

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

Voici une relation non identificatrice correspondante:

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

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

La réponse de user287724 donne l'exemple suivant de la relation livre / auteur:

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 exister sans un auteur. La relation entre le livre et l'auteur est donc une relation identificatrice.

Ceci est un exemple très déroutant et n'est certainement pas un exemple valable pour un identifying relationship.

Oui, un bookne peut pas être écrit sans au moins un author, mais la author(c'est la clé étrangère) du bookn'est PAS IDENTIFIER le bookdans le bookstableau!

Vous pouvez supprimer le author(FK) de la bookligne et peut encore identifier la ligne de livre par un autre domaine ( ISBN, ID, ... etc), mais pas l'auteur du livre !!

Je pense qu'un exemple valable d'un identifying relationshipserait la relation entre (tableau des produits) et un (tableau des détails du 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_IDdans la printers_detailstable est considéré comme un FK fait référence à la products.idtable et AUSSI un PK dans la printers_detailstable, il s'agit d'une relation d'identification car le Product_ID(FK) dans la table des imprimantes IDENTIFIE la ligne à l'intérieur de la table enfant, nous ne pouvons pas supprimer la product_idde la table des enfants parce que nous ne pouvons pas identifier la ligne plus parce que nous avons perdu la clé primaire est

Si vous voulez le mettre en 2 lignes:

une relation d'identification est la relation lorsque le FK dans la table enfant est considéré comme un PK (ou identifiant) dans la table enfant tout en faisant référence à la table parent

Un autre exemple peut être lorsque vous avez 3 tableaux (importations - produits - pays) dans une base de données d'importations et d'exportations pour certains pays

Le importtableau est l'enfant qui possède ces champs (le product_id(FK), le country_id(FK), le montant des importations, le prix, les unités importées, le mode de transport (aérien, maritime)) we may use the (product_id , thecountry_id`) pour identifier chaque ligne des importations "si elles sont toutes dans la même année" ici les deux colonnes peuvent composer ensemble une clé primaire dans la table enfant (importations) et y référencer également les tables parentes.

S'il vous plaît, je suis heureux d'avoir enfin compris le concept du identifying relationshipet non identifying relationship, alors ne me dites pas que je me trompe avec tous ces votes pour un exemple complètement invalide

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

Vous pouvez supprimer à 100% l'auteur de la ligne du livre et toujours identifier le livre! .

Relation non identificatrice

Une relation non identifiable signifie qu'un enfant est apparenté à un parent, mais il peut être identifié par lui-même.

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

La relation entre ACCOUNT et PERSON n'est pas identifiable.

Identifier la relation

Une relation d'identification signifie que le parent est nécessaire pour donner une identité à l'enfant. L'enfant existe uniquement grâce à ses parents.

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 en cours d'identification. Et entre ITEM_LANG et LANGUAGE aussi.

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é, il s'agit alors d'une relation non identificatrice.

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

• 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 identifiable avec les diplômes

Seules les sessions de formation doivent être supprimées si l'un des stagiaires, formations ou diplômes concernés est supprimé.

La relation identifiante signifie que l'entité enfant dépend totalement de l'existence de l'entité parent. Exemple de table de compte et de compte de personne La table de compte de personne est identifiée uniquement par l'existence de la table de compte et de personne.

La relation non identifiante signifie que la table enfant n'est pas identifiée par l'existence de l'exemple de table parent, il existe une table comme type de compte et la table account.accounttype n'est pas identifiée avec la table d'existence de compte.

Comme bien expliqué dans le lien ci-dessous, une relation d'identification est un peu comme une relation de type entité faible avec son parent dans le modèle conceptuel de RE. Les CAD de style UML pour la modélisation de données n'utilisent pas de symboles ou de concepts ER, et les types de relations sont: identifiants, non identifiants et non spécifiques.

Les identifiants sont des relations parent / enfant où l'enfant est une sorte d'entité faible (même dans le modèle ER traditionnel, sa relation identifiée), qui n'a pas de véritable clé primaire par ses propres attributs et ne peut donc pas être identifiée de manière unique par ses propres . Chaque accès à la table enfant, sur le modèle physique, dépendra (sémantiquement inclus) de la clé primaire du parent, qui se transforme en partie ou en total de la clé primaire de l'enfant (étant également une clé étrangère), résultant généralement en une clé composite du côté enfant. Les clés existantes éventuelles de l'enfant lui-même ne sont que des pseudo-clés ou des clés partielles, pas suffisantes pour identifier une instance de ce type d'entité ou d'ensemble d'entités, sans PK du parent.

Les relations non identifiantes sont les relations ordinaires (partielles ou totales), d'ensembles d'entités complètement indépendants, dont les instances ne dépendent pas des clés primaires des uns et des autres pour être identifiées de manière unique, bien qu'elles puissent avoir besoin de clés étrangères pour les relations partielles ou totales, mais pas comme clé primaire de l'enfant. L'enfant a sa propre clé primaire. L'idem parent. Les deux indépendamment. Selon la cardinalité de la relation, le PK de l'un va comme un FK à l'autre (côté N), et s'il est partiel, peut être nul, s'il est total, ne doit pas être nul. Mais, dans une relation comme celle-ci, le FK ne sera jamais aussi le PK de l'enfant, comme lorsqu'une relation d'identification est le cas.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Les attributs migrés du parent vers l'enfant aident-ils à identifier ¹ l'enfant?

• Si oui : la dépendance d'identification existe, la relation s'identifie et l'entité enfant est "faible".
• Si non : l'identification dépendance n'existe pas, la relation est non identificatoires et l'entité enfant « forte ».

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

Pour en savoir plus à ce sujet (et quelques exemples), consultez la section «Identification des relations» du Guide des méthodes ERwin .

PS Je me rends compte que je suis (extrêmement) en retard à la fête, mais je pense que les autres réponses ne sont pas tout à fait exactes (le définissant 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é ...

¹ Le FK de l'enfant fait partie de la clé PRIMARY KEY ou UNIQUE (non NULL) de l'enfant.

Un bon exemple vient du traitement des commandes. Une commande d'un client a généralement un numéro de commande qui identifie la commande, certaines données qui se produisent une fois par commande, telles que la date de la commande et l'ID client, et une série d'éléments de ligne. Chaque élément de ligne contient un numéro d'article qui identifie un élément de ligne dans une commande, un produit commandé, la quantité de ce produit, le prix du produit et le montant de l'élément de ligne, qui peut être calculé en multipliant la quantité par le prix.

Le numéro qui identifie un élément de campagne ne l'identifie que dans le contexte d'une seule commande. Le premier élément de campagne de chaque commande est le numéro d'article "1". L'identité complète d'un élément de ligne est le numéro de l'article ainsi que le numéro de commande dont il fait partie.

La relation parent-enfant entre les commandes et les éléments de campagne est donc une relation d'identification. Un concept étroitement lié à la modélisation des ER porte le nom de "sous-entité", où l'élément de campagne est une sous-entité d'ordre. En règle générale, une sous-entité a une relation d'identité parent-enfant obligatoire avec l'entité à laquelle elle est subordonnée.

Dans la conception de base de données classique, la clé primaire de la table LineItems serait (OrderNumber, ItemNumber). Certains concepteurs d'aujourd'hui attribueraient à un élément un ID d'article distinct, qui sert de clé primaire et est auto-incrémenté par le SGBD. Je recommande un design classique dans ce cas.

Disons que nous avons ces tables:

user
--------
id
name


comments
------------
comment_id
user_id
text

la relation entre ces deux tables permettra d'identifier la relation. Car, seuls les commentaires peuvent appartenir à son propriétaire, pas aux autres utilisateurs. par exemple. Chaque utilisateur a son propre commentaire, et lorsque l'utilisateur est supprimé, les commentaires de cet utilisateur doivent également être supprimés.

Une relation d'identification est entre deux entités fortes. Une relation non identificatrice peut ne pas toujours être une relation entre une entité forte et une entité faible. Il peut exister une situation dans laquelle un enfant possède lui-même une clé primaire, mais l'existence de son entité peut dépendre de son entité parent.

Par exemple: une relation entre un vendeur et un livre où un livre est vendu par un vendeur peut exister lorsque le vendeur peut avoir sa propre clé primaire mais son entité n'est créée que lorsqu'un livre est vendu

Référence basée sur Bill Karwin