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


800

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?


11
les réponses à cette question sont tellement confuses que ce n'est pas drôle
Dennis

Bonne question, la roue n'est pas à réinventer: Peter Chen. Le modèle de relation d'entité, vers une vue unifiée des données, 1976 § 2.3.2: " Si les relations sont utilisées pour identifier les entités, nous l'appellerons une relation d'entité faible. Si les relations ne sont pas utilisées pour identifier les entités, nous appellerons c'est une relation d'entité régulière ". La question du PO se résume à: Qu'est-ce qu'une relation d'entité faible / régulière? .
minutes

Réponses:


1063
  • 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


9
+1: Bill, "il est courant de nos jours de créer un pseudokey pour une table enfant, mais pas de faire la clé étrangère de la partie parent de la clé primaire de l'enfant" - des liens expliquant pourquoi c'est? Google me fait défaut.
hobodave

17
Il semble que la construction «correcte» de relations d'identification conduirait à des clés primaires d'une odeur énorme. Par exemple, le bâtiment a l'étage a la chambre a un lit. Le PK pour Bed serait (bed_id, floor_id, room_id, building_id). Il semble étrange que je n'ai jamais vu cela dans la pratique, ni entendu que cela soit suggéré comme moyen de faire quoi que ce soit. Cela fait beaucoup de données redondantes dans le PK.
hobodave

24
@hobodave: J'ai vu des clés primaires multi-colonnes encore plus grandes. Mais je comprends votre point. Considérez que les clés primaires à plusieurs colonnes véhiculent plus d'informations; vous pouvez interroger la Bedstable pour tous les lits d'un bâtiment spécifique sans effectuer de jointures.
Bill Karwin

2
@Eugene, oui, je m'attendrais à ce que ce soit une relation non identificatrice. user_iddoit être la clé primaire en elle-même et updated_byne fait pas partie d'une clé primaire à plusieurs colonnes.
Bill Karwin

4
Je n'utiliserai jamais ceci pour modéliser cela. La meilleure réponse est de "aqsa rao" ci-dessous qui déclare ce qui suit: "Une relation d'identification signifie que la table enfant ne peut pas être identifiée de manière unique sans le parent." Parce que votre définition ajoute une sémantique inutile qui pourrait dérouter les gens. Ce n'est pas la dépendance entre les entités que vous créez une relation d'identification ou de non-identification.
Sebastian

888

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.


2
Une explication décente, mais je pense qu'il est également instructif d'étendre un peu l'exemple. Un livre comporte plusieurs pages. Il ne peut exister sans pages et nous pouvons donc conclure que la relation entre un livre et le nombre de pages qu'il contient est également une relation d'identification. Mais le nombre de pages attribuées fera-t-il partie d'un schéma d'identification (clé) pour le livre? Probablement pas. Le terme "relation d'identification" est normalement réservé aux relations impliquant des attributs d' identification - des attributs principaux en termes relationnels.
nvogel

13
Que se passe-t-il si le livre a été écrit par plus d'un auteur? Ce n'est plus une relation d'identification de type M: N, pourquoi?
NGix

2
Ces vrais exemples sont inutiles. Lorsque vous réalisez comment vous créez des tables dans ER et comment l'intégrité des données se tiendra, vous jetez ensuite ces exemples. Si vous créez une relation solide entre deux entités, vous forcez à créer une clé primaire dans la table d'entités combinée avec PK de l'autre entité. Si votre modèle vous permet que le même livre puisse avoir plusieurs auteurs, alors c'est bien d'être fort. Mais si votre modèle ne vous autorise qu'à 1 auteur 1 livre, vous ne pouvez pas avoir cette contrainte en utilisant une relation forte car PK(Book.id, Book.person_id).
Sebastian

2
mais l'usage réel est "le livre peut-il exister sans l'auteur?". La réponse est oui en réalité, car les gens chercheront directement le livre. Par conséquent, dans la pratique, dans ce cas, elles devraient toujours être une "relation non identificatrice".
windmaomao

3
ce qui se passe les gars !!, ce n'est pas un exemple valable pour the Identifying relationship !!! oui un livre ne peut pas être écrit sans auteur mais, le champ auteur dans la table des livres N'IDENTIFIE PAS la ligne du livre !!!
Accountant م

33

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 !!!


2
+1 pour "Il suffirait que la clé étrangère soit non nulle pour y parvenir." Cela devrait être suffisant, mais malheureusement, ce n'est pas quand il s'agit de quelque chose comme Entity Framework, qui ne fonctionne pas correctement à moins que vous n'utilisiez une relation d'identification, mais le champ "Id" d'une entité perd son unicité en raison d'être juste une partie d'une clé composite.
Triynko

25

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 ...


6
Cela ressemble plus à une description de la participation totale à une relation qu'à une relation d'identification.
Thomas Padron-McCarthy

1
Vous êtes littéralement en concurrence avec un gars qui a une réputation de 218k. Je lance ça parce que vous en savez certainement plus que moi.
Marc DiMillo

Je ne suis pas d'accord avec les définitions ci-dessus. Vous pouvez avoir un objet qui dépend de son parent et vous souhaitez que cet objet soit contraint à être lié uniquement avec 1 ligne parent. A Housea l' Wallart. Vous enlevez la maison et vous n'avez pas de murs. Mais un mur n'appartient qu'à une maison. Donc, faire des relations solides ne fonctionnera pas: PK(Wall.id, House.id)vous permettra d'insérer dans le modèle le même mur dans une autre maison.
Sebastian

15

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

1
Votre réponse est en conflit avec celle donnée par Bill Karwin, dans la différence entre si la clé étrangère "n'est pas" ou "ne doit pas" faire partie de la clé primaire de la ligne enfant.
Nicole

@Andy White Mais la clé primaire du parent dans une relation d'identification pourrait-elle être non obligatoire, c'est-à-dire nulle, lorsqu'elle fait partie d'une clé primaire composite à trois colonnes?
Frederik Krautwald

10

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! .


5
Vous avez raison, si vous n'avez que des livres de livres et des auteurs. Il n'y a pas de relation d'identification là-bas. Mais si vous utilisez une troisième table pour représenter la relation plusieurs-à-plusieurs, la clé primaire de cette troisième table se compose de deux clés étrangères, référençant la table des livres et la table des auteurs. Ce tableau a une relation d'identification avec les livres et les auteurs. Voir mon exemple dans stackoverflow.com/questions/2814469/…
Bill Karwin

8

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.


2
Comment la PERSONNE et le COMPTE ne s'identifient-ils pas? Comment le COMPTE peut-il exister sans PERSONNE?
MrRobot9

pourquoi il n'y a pas de réponse pour le commentaire précédent? @ MrRobot9
AAEM

4

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é.


3

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.


2

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


2

Les attributs migrés du parent vers l'enfant aident-ils à identifier 1 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é ...


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


1

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.


0

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.


0

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


5
Il pourrait être utile de définir ici ce que vous entendez par entité «forte» et «faible».
nullité
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.