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?
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?
Réponses:
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 Person
a 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_id
référencement de la Person
table.
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_id
dans 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.state
référencer la clé primaire de States.state
. Person
est une table enfant par rapport à States
. Mais une ligne Person
n'est pas identifiée par son state
attribut. Ie state
ne 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
Beds
table pour tous les lits d'un bâtiment spécifique sans effectuer de jointures.
user_id
doit être la clé primaire en elle-même et updated_by
ne fait pas partie d'une clé primaire à plusieurs colonnes.
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.
PK(Book.id, Book.person_id)
.
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 !!!
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 ...
House
a l' Wall
art. 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.
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 book
ne peut pas être écrit sans au moins un author
, mais la author
(c'est la clé étrangère) du book
n'est PAS IDENTIFIER le book
dans le books
tableau!
Vous pouvez supprimer le author
(FK) de la book
ligne 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 relationship
serait 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_ID
dans la printers_details
table est considéré comme un FK fait référence à la products.id
table et AUSSI un PK dans la printers_details
table, 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_id
de 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 import
tableau 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 , the
country_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 relationship
et 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:
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 1 l'enfant?
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.
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