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

Question

Je n'ai pas été en mesure de bien saisir les différences. Pouvez-vous décrire les deux concepts et utiliser des exemples concrets?

Bill Karwin · Accepted Answer

Une relation d'identification se produit lorsque l'existence d'une ligne dans une table enfant dépend d'une ligne dans une table parent. Cela peut prêter à confusion car il est de pratique courante de créer un pseudokey pour une table enfant, mais et non ne crée la clé étrangère que pour la partie parent de la clé primaire de l'enfant. Formellement, 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 exister sans le parent.

Exemple: Un Person a un ou plusieurs numéros de téléphone. S'ils n'avaient qu'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 créons une deuxième table PhoneNumbers, dont la clé primaire comprend le person_id faisant référence à la table Person.

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 les attributs d'un tableau séparé. 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 identifiante correspond au moment où 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 consultation, telle qu'une clé étrangère sur Person.state référençant la clé primaire de States.state. Person est une table enfant en ce qui concerne States. Mais une ligne dans Person n'est pas identifiée par son attribut state. C'est à dire. state ne fait pas partie de la clé primaire de Person.

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

Voir aussi ma réponse à toujours confus au sujet des relations d’identification et non identifiantes

user287724 · Answer

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é peut changer d'un propriétaire à l'autre. La relation entre un livre et un propriétaire est une relation non identifiante.

Cependant, un livre 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.

Daniel Dinnyes · Answer

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

On répète sans cesse que, dans l'identification d'une relation, l'enfant ne peut exister sans le parent. (par exemple, ser287724 ). C'est vrai, mais passe complètement à côté de l'essentiel. Il suffirait que la clé étrangère soit non nulle pour y parvenir. Il n'est pas nécessaire qu'il fasse partie de la clé primaire.

Voici donc la vraie raison:

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

CMS · Answer

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

Andy White · Answer

Voici une bonne description:

Les relations entre deux entités peuvent être classées comme "identifiantes" ou "non identifiantes". Des relations d'identification existent lorsque la clé primaire de l'entité parent est incluse dans la clé primaire de l'entité enfant. D'autre part, une relation non identifiante existe lorsque la clé primaire de l'entité mère est incluse dans l'entité enfant mais ne fait pas partie de la clé primaire de l'entité enfant. En outre, les relations non identifiantes peuvent en outre être classées comme étant "obligatoires" ou "non obligatoires". Une relation non identitaire obligatoire existe lorsque la valeur de la table enfant ne peut pas être null. D'autre part, une relation non obligatoire non identifiante existe lorsque la valeur de la table enfant peut être null.

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-identifiante correspondante:

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

Accountant م · Answer

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

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

Oui, une book ne peut être écrite sans au moins une author, mais la author (c'est la clé étrangère) de la book est NON IDENTIFIANT la book dans la table books!

Vous pouvez supprimer la author (FK) de la ligne book et vous pouvez toujours identifier la ligne du livre par un autre champ (ISBN, ID, ... etc), MAIS PAS l'auteur du livre !!

Je pense qu'un exemple valide de identifying relationship serait la relation entre (table de produits) et une (table 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 de la table printers_details est considéré comme un FK faisant référence à la table products.id et AUSSI une PK dans la table printers_details, il s'agit d'une relation d'identification car le Product_ID (FK) dans la table des imprimantes EST IDENTIFIANT le 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 de la table enfant est considéré comme une clé publique (ou identificateur) 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 importations et exportations pour certains pays.

La table import est l’enfant qui a ces champs (le product_id (FK), le country_id (FK), le montant des importations, le prix, les unités importées, le chemin de transport (air, mer)) we may use the (product_id, thecountry_id`) pour identifier chaque ligne des importations "si elles sont toutes de la même année", les deux colonnes peuvent composer ensemble une clé primaire dans la table enfant ( importations) et en y référençant les tables mères.

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

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

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

Skarllot · Answer

relation non identifiante

Une relation non identifiante signifie qu'un enfant est lié au parent, mais elle peut être identifiée par le sien.

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

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

Identifier la relation

Une relation d'identification signifie que le parent est nécessaire pour donner une identité à l'enfant. L'enfant existe uniquement à cause de 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 en cours d'identification. Et entre ITEM_LANG et LANGUAGE aussi.

Daishi · Answer

Si vous considérez que l'élément enfant doit être supprimé lorsque le parent est supprimé, il s'agit alors 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'un rapport non-identifiant.

Par 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 des 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 doivent être supprimées si l’un des stagiaires, formations ou diplômes correspondants est supprimé.

chanchal dixit · Answer

La relation identifiante signifie que l'entité enfant est totalement dépendante de l'existence de l'entité mère. Exemple de table de personnes et de compte de personnes dans la table de comptes. La table de comptes de personnes est identifiée par l’existence de tables de compte et de personnes uniquement.

La relation non identifiante signifie que la table enfant n'est pas identifiée par l'exemple de la table parent. Il existe une table en tant que type de compte et la table account.accounttype n'est pas identifiée à l'existence de la table de compte.

Branko Dimitrijevic · Answer

Les attributs migrés de l’aide parent à l’aide enfant identifient-ils¹ l'enfant?

Si yes : la dépendance entre identifications existe, la relation s'identifie et l'entité enfant est "faible".
Si not : la dépendance-identification n'existe pas, la relation n'est pas identifiante et l'entité enfant est "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 exister sans parent, mais cela ne permet pas à lui seul d'identifier la relation.

Pour plus d'informations à ce sujet (et à quelques exemples), reportez-vous à la section "Identification des relations" du Guide des méthodes ERwin .

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

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

Daniel Pinheiro · Answer

Comme bien expliqué dans le lien ci-dessous, une relation d'identification ressemble un peu à une relation de type entité faible avec son parent dans le modèle conceptuel ER. Les CADs 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 les suivants: identification, non-identification et non-spécifique.

Les identifiants sont des relations parent/enfant où l’enfant est une sorte d’entité faible (même dans le modèle ER traditionnel, appelé relation identifiante), qui n’a pas de clé primaire réelle 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 (y compris sémantiquement) de la clé primaire du parent, qui se transforme en une partie ou la totalité de la clé primaire de l'enfant (également une clé étrangère), ce qui aboutit généralement à une clé composite. du côté des enfants. Les éventuelles clés existantes de l'enfant lui-même ne sont que des pseudo-clés ou des clés partielles, non suffisantes pour identifier une instance de ce type d'entité ou d'entité définie, sans la 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 de la clé primaire de chacun pour être identifiées de manière unique, bien qu'elles puissent avoir besoin de clés étrangères pour des relations partielles ou totales, mais pas en tant que clé primaire de l'enfant. L'enfant a sa propre clé primaire. Le parent idem. Les deux indépendamment. En fonction de la cardinalité de la relation, la PK de l'une va comme une FK à l'autre (côté N), et si elle est partielle, elle peut être nulle, si elle est totale, elle doit l'être non. Mais dans une relation comme celle-ci, le FK ne sera jamais aussi la PK de l'enfant, comme dans le cas d'une relation d'identification.

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

Walter Mitty · Answer

Un bon exemple vient du traitement des commandes. Une commande émanant d'un client comporte généralement un numéro de commande qui identifie la commande, certaines données ne se produisant qu'une fois par commande, telles que la date de la commande et le numéro de client, ainsi qu'une série de postes. Chaque article contient un numéro d’article qui identifie un article dans une commande, un produit commandé, la quantité de ce produit, son prix et le montant de l’article, 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 article de chaque commande est le numéro d’article "1". L'identité complète d'un élément de campagne est le numéro de poste avec 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 ER se nomme "sous-entité", où l'élément de campagne est une sous-unité 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 des concepteurs actuels attribueraient à un élément un IDID distinct, qui sert de clé primaire et qui est auto-incrémenté par le SGBD. Je recommande le design classique dans ce cas.

Sarvar Nishonboev · Answer

Disons que nous avons ces tables:

user -------- id name comments ------------ comment_id user_id text

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

sp1rs · Answer

Une relation d'identification est entre deux entités fortes. Une relation non identifiante 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é mère.

Par exemple: une relation entre un vendeur et un livre dans lequel un livre est vendu par un vendeur peut exister où le vendeur peut avoir sa propre clé primaire mais son entité est créée uniquement lors de la vente d'un livre.

Référence basée sur Bill Karwin