¿Cuál es la diferencia entre relaciones identificativas y no identificativas?


800

No he podido comprender completamente las diferencias. ¿Puedes describir ambos conceptos y usar ejemplos del mundo real?


11
las respuestas a esta pregunta son tan confusas que no es divertido
Dennis

Buena pregunta, la rueda no se reinventa: Peter Chen. El modelo de relación de entidad, hacia una vista unificada de datos, 1976 § 2.3.2: " Si se usan relaciones para identificar las entidades, lo llamaremos una relación de entidad débil. Si las relaciones no se usan para identificar las entidades, llamaremos es una relación de entidad regular ". La pregunta OP se reduce a: ¿Qué son las relaciones entre entidades débiles / regulares? .
minutos

Respuestas:


1063
  • Una relación de identificación es cuando la existencia de una fila en una tabla secundaria depende de una fila en una tabla primaria. Esto puede ser confuso porque es una práctica común en estos días crear una pseudoclave para una tabla secundaria, pero no hacer que la clave externa de la parte principal de la clave primaria del niño. Formalmente, la forma "correcta" de hacer esto es hacer que la clave foránea forme parte de la clave primaria del niño. Pero la relación lógica es que el niño no puede existir sin el padre.

    Ejemplo: A Persontiene uno o más números de teléfono. Si solo tuvieran un número de teléfono, simplemente podríamos almacenarlo en una columna de Person. Como queremos admitir varios números de teléfono, creamos una segunda tabla PhoneNumbers, cuya clave principal incluye la person_idreferencia a la Persontabla.

    Podemos pensar en los números de teléfono como pertenecientes a una persona, aunque estén modelados como atributos de una tabla separada. Esta es una pista fuerte de que se trata de una relación de identificación (incluso si no la incluimos literalmente person_iden la clave principal de PhoneNumbers).

  • Una relación no identificativa es cuando los atributos de la clave primaria del padre no deben convertirse en los atributos de la clave primaria del hijo. Un buen ejemplo de esto es una tabla de búsqueda, como una clave externa para hacer Person.statereferencia a la clave primaria de States.state. Persones una tabla secundaria con respecto a States. Pero una fila Personno se identifica por su stateatributo. Es decir, stateno es parte de la clave principal de Person.

    Una relación no identificativa puede ser opcional u obligatoria , lo que significa que la columna de clave externa permite NULL o no permite NULL, respectivamente.


Vea también mi respuesta a Aún confundido acerca de las relaciones de identificación frente a las de no identificación


99
+1: Bill, "es una práctica común en estos días crear una pseudoclave para una tabla secundaria, pero no hacer que la clave foránea sea la parte principal de la clave primaria del elemento secundario". ¿Hay algún vínculo de por qué es esto? Google me está fallando.
hobodave

17
Parece que la construcción "adecuada" de relaciones de identificación conduciría a claves primarias desagradablemente grandes. Por ejemplo, el edificio tiene piso tiene habitación tiene cama. El PK para la cama sería (bed_id, floor_id, room_id, building_id). Parece extraño que nunca haya visto esto en la práctica, ni he oído que sugiera como una forma de hacer nada. Esa es una gran cantidad de datos redundantes en el PK.
hobodave

24
@hobodave: He visto claves primarias de varias columnas que son aún más grandes. Pero entiendo tu punto. Tenga en cuenta que las claves primarias de varias columnas transmiten más información; Puede consultar la Bedstabla para todas las camas en un edificio específico sin hacer ninguna unión.
Bill Karwin

2
@ Eugene, sí, esperaría que fuera una relación no identificable. user_iddebe ser la clave primaria por sí misma y updated_byno es parte de una clave primaria de varias columnas.
Bill Karwin

44
Nunca usaré esto para modelar eso. La mejor respuesta es de "aqsa rao" a continuación que establece lo siguiente: "Una relación de identificación significa que la tabla secundaria no puede identificarse de manera única sin el padre". Porque su definición es agregar semántica innecesaria que podría confundir a las personas. No es la dependencia entre entidades la razón por la que crea una relación identificativa o no identificativa.
Sebastian

888

Hay otra explicación del mundo real:

Un libro pertenece a un propietario, y un propietario puede tener varios libros. Pero, el libro puede existir también sin el propietario, y la propiedad del mismo puede cambiar de un propietario a otro. La relación entre un libro y un propietario es una relación no identificable.

Sin embargo, un libro está escrito por un autor, y el autor podría haber escrito varios libros. Pero, el libro debe ser escrito por un autor; no puede existir sin un autor. Por lo tanto, la relación entre el libro y el autor es una relación de identificación.


2
Una explicación decente, pero creo que también es instructivo extender un poco el ejemplo. Un libro tiene varias páginas. No puede existir sin páginas y, por lo tanto, podríamos concluir que la relación entre un libro y el número de páginas que tiene también es una relación de identificación. Pero, ¿será el atributo número de páginas parte de algún esquema de identificación (clave) para el libro? Probablemente no. El término "relación de identificación" se reserva normalmente para las relaciones que involucran atributos de identificación - atributos principales en términos relacionales.
nvogel

13
¿Qué sucede si el libro fue escrito por más de 1 autor? Ya no es identificar una relación como tipo M: N, ¿por qué?
NGix

2
Estos ejemplos reales son inútiles. Cuando se da cuenta de cómo crea tablas en ER y cómo se mantendrá la integridad de los datos, descarta estos ejemplos. Si crea una relación sólida entre dos entidades, está obligando a crear una clave primaria en la tabla de entidades combinada con PK de la otra entidad. Si su modelo le permite que el mismo libro pueda tener múltiples autores, entonces está bien ser fuerte. Pero si su modelo solo le permite 1 autor 1 libro, no puede tener esa restricción usando una relación fuerte porque PK(Book.id, Book.person_id).
Sebastian

2
pero el uso real es "¿puede existir un libro sin el autor?". La respuesta es sí en realidad, porque la gente buscará el libro directamente. Por lo tanto, en la práctica, para este caso, siempre deben ser "relaciones no identificables".
windmaomao

3
¡¡¡Qué está pasando muchachos !!, Este no es un ejemplo válido para the Identifying relationship !!! sí, un libro no se puede escribir sin un autor, pero el campo de autor en la tabla de libros NO IDENTIFICA la fila del libro.
Contador م

33

La respuesta de Bill es correcta, pero es sorprendente ver que, entre todas las otras respuestas, nadie señala el aspecto más significativo.

Se dice una y otra vez que, en una relación de identificación, el niño no puede existir sin el padre. (por ejemplo, usuario287724 ). Esto es cierto, pero pierde completamente el punto. Sería suficiente que la clave externa no sea nula para lograr esto. No necesita ser parte de la clave primaria.

Así que aquí está la verdadera razón:

El propósito de una relación de identificación es que la clave externa NUNCA PUEDE CAMBIAR , porque es parte de la clave primaria ... ¡ por lo tanto, la identificación!


2
+1 para "Sería suficiente para que la clave externa no sea nula, para lograr esto". Se debería ser suficiente, pero por desgracia no lo es cuando se trata de algo así como Entity Framework, que no funciona bien a menos que utilice una relación de identificación, pero entonces el campo "ID" de una entidad pierde su singularidad como resultado de estar solo Una parte de una clave compuesta.
Triynko

25

Una relación de identificación especifica que un objeto hijo no puede existir sin el objeto padre

Las relaciones no identificativas especifican una asociación regular entre objetos, cardinalidad 1: 1 o 1: n.

Las relaciones no identificables se pueden especificar como opcionales cuando no se requiere un padre o obligatorio cuando se requiere un padre configurando la cardinalidad de la tabla padre ...


66
Esto suena más como una descripción de la participación total en una relación, que como una relación de identificación.
Thomas Padron-McCarthy

1
Estás literalmente compitiendo con un tipo que tiene 218k reputación. Solo lancé eso porque los dos definitivamente saben más que yo.
Marc DiMillo

No estoy de acuerdo con las definiciones anteriores. Es posible que tenga un objeto que depende de su elemento primario y desea que ese objeto esté limitado para vincularse solo con 1 fila principal. A Housetiene Walls. Quitas la casa y no tienes paredes. Pero una pared pertenece solo a una casa. Por lo tanto, hacer una relación sólida no funcionará: PK(Wall.id, House.id)le permitirá insertar en el modelo la misma pared a otra casa.
Sebastian

15

Aquí hay una buena descripción:

Las relaciones entre dos entidades pueden clasificarse como "identificativas" o "no identificables". Las relaciones de identificación existen cuando la clave primaria de la entidad primaria se incluye en la clave primaria de la entidad secundaria. Por otro lado, existe una relación no identificable cuando la clave primaria de la entidad primaria se incluye en la entidad secundaria pero no como parte de la clave primaria de la entidad secundaria. Además, las relaciones no identificables pueden clasificarse como "obligatorias" o "no obligatorias". Existe una relación obligatoria de no identificación cuando el valor en la tabla secundaria no puede ser nulo. Por otro lado, existe una relación no obligatoria no identificable cuando el valor en la tabla secundaria puede ser nulo.

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

Aquí hay un ejemplo simple de una relación de identificación:

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

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

Aquí hay una relación no identificable correspondiente:

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

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

1
Su respuesta entra en conflicto con la dada por Bill Karwin, en la diferencia entre si la clave externa "no es" o "no debe" ser parte de la clave primaria en la fila secundaria.
Nicole

@Andy White Pero, ¿podría la clave primaria del padre en una relación de identificación ser no obligatoria, es decir, nula, cuando forma parte de una clave primaria compuesta de tres columnas?
Frederik Krautwald

10

La respuesta de user287724 da el siguiente ejemplo de la relación libro y autor:

Sin embargo, un libro está escrito por un autor, y el autor podría haber escrito varios libros. Pero el libro debe ser escrito por un autor, no puede existir sin un autor. Por lo tanto, la relación entre el libro y el autor es una relación de identificación.

Este es un ejemplo muy confuso y definitivamente no es un ejemplo válido para un identifying relationship.

Sí, un bookno se puede escribir sin al menos uno author, ¡pero la author(es clave externa) del NObook está IDENTIFICANDO el booken la bookstabla!

Se puede quitar el author(FK) de la bookfila y todavía se puede identificar la fila libro de algún otro campo ( ISBN, ID, etc ...), pero no es el autor del libro !!

Creo que un ejemplo válido de un identifying relationshipsería la relación entre (tabla de productos) y una (tabla de detalles específicos del producto)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

En este ejemplo, Product_IDen la printers_detailstabla se considera un FK que hace referencia a la products.idtabla y TAMBIÉN un PK en la printers_detailstabla, esta es una relación de identificación porque el Product_ID(FK) en la tabla de impresoras IDENTIFICA la fila dentro de la tabla secundaria, no podemos eliminar la product_idde la tabla secundaria porque ya no podemos identificar la fila porque perdimos su clave principal

Si quieres ponerlo en 2 líneas:

una relación de identificación es la relación cuando el FK en la tabla secundaria se considera un PK (o identificador) en la tabla secundaria mientras aún hace referencia a la tabla primaria

Otro ejemplo puede ser cuando tiene 3 tablas (importaciones - productos - países) en una base de datos de importaciones y exportaciones para algún país

La importtabla es el elemento secundario que tiene estos campos (el product_id(FK), el country_id(FK), la cantidad de las importaciones, el precio, las unidades importadas, la forma de transporte (aéreo, marítimo)) we may use the (product_id , thecountry_id`) para identificar cada fila de las importaciones "si todas en el mismo año" aquí las dos columnas pueden componer una clave principal en la tabla secundaria (importaciones) y también hacer referencia a las tablas principales.

Por favor, estoy feliz de que finalmente entiendo el concepto de identifying relationshipy non identifying relationship, así que no me digas que estoy equivocado con todos estos votos para un ejemplo completamente inválido

Sí, lógicamente, un libro no se puede escribir sin un autor, pero se puede identificar un libro sin el autor. ¡De hecho, no se puede identificar con el autor!

¡Puede eliminar al 100% al autor de la fila del libro y aún así puede identificar el libro! .


55
Tienes razón, si solo tienes tablas de libros y autores. No hay una relación de identificación allí. Pero si usa una tercera tabla para representar la relación de muchos a muchos, la clave principal de esa tercera tabla consta de dos claves externas, que hacen referencia a la tabla de libros y la tabla de autores. Esa tabla tiene una relación de identificación tanto con los libros como con los autores. Vea mi ejemplo en stackoverflow.com/questions/2814469/…
Bill Karwin

8

Relación no identificable

Una relación no identificable significa que un niño está relacionado con el padre pero puede identificarse por sí mismo.

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

La relación entre CUENTA y PERSONA no es identificable.

Relación de identificación

Una relación de identificación significa que el padre es necesario para dar identidad al niño. El niño existe únicamente por los padres.

Esto significa que la clave externa también es una clave primaria.

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

La relación entre ITEM_LANG y ITEM es identificativa. Y entre ITEM_LANG y LANGUAGE también.


2
¿Cómo no se identifica la PERSONA y la CUENTA? ¿Cómo puede existir una CUENTA sin PERSONA?
MrRobot9

¿Por qué no hay respuesta para el comentario anterior? @ MrRobot9
AAEM

4

Si considera que el elemento secundario debe eliminarse cuando se elimina el elemento primario, entonces es una relación de identificación.

Si el elemento secundario debe mantenerse aunque se elimine el elemento primario, se trata de una relación no identificable.

Como ejemplo, tengo una base de datos de capacitación con aprendices, capacitaciones, diplomas y sesiones de capacitación:

  • los alumnos tienen una relación de identificación con las sesiones de entrenamiento
  • los entrenamientos tienen una relación de identificación con las sesiones de entrenamiento
  • pero los alumnos tienen una relación no identificable con los diplomas

Solo se deben eliminar las sesiones de capacitación si se elimina uno de los aprendices, capacitación o diploma relacionado.


3

La relación de identificación significa que la entidad hija depende totalmente de la existencia de la entidad padre. Ejemplo de tabla de persona tabla de persona y personaccount. La tabla de cuenta de persona se identifica por la existencia de cuenta y tabla de persona solamente.

La relación no identificativa significa que la tabla secundaria no se identifica por la existencia de la tabla principal, por ejemplo, hay una tabla como tipo de cuenta y cuenta.


2

Como se explica bien en el siguiente enlace, una relación de identificación es algo así como una relación de tipo de entidad débil con su padre en el modelo conceptual de ER. Los CAD de estilo UML para el modelado de datos no usan símbolos o conceptos ER, y el tipo de relaciones son: identificativas, no identificativas y no específicas.

Los identificadores son relaciones padre / hijo donde el niño es una especie de entidad débil (incluso en el modelo ER tradicional se llama relación de identificación), que no tiene una clave primaria real por sus propios atributos y, por lo tanto, no puede identificarse de manera única por sí misma . Cada acceso a la tabla secundaria, en el modelo físico, dependerá (inclusive semánticamente) de la clave primaria del padre, que se convierte en parte o total de la clave primaria del niño (también es una clave externa), lo que generalmente resulta en una clave compuesta en el lado del niño. Las eventuales claves existentes del propio elemento secundario son solo claves seudo o parciales, no suficientes para identificar cualquier instancia de ese tipo de Entidad o Conjunto de Entidades, sin la PK del padre.

Las relaciones no identificativas son las relaciones ordinarias (parciales o totales), de conjuntos de entidades completamente independientes, cuyas instancias no dependen de las claves primarias de cada uno para identificarse de manera única, aunque pueden necesitar claves foráneas para relaciones parciales o totales, pero no como la clave principal del niño. El niño tiene su propia clave primaria. El idem de los padres. Ambos de forma independiente. Dependiendo de la cardinalidad de la relación, el PK de uno va como FK al otro (lado N) y, si es parcial, puede ser nulo, si es total, no debe ser nulo. Pero, en una relación como esta, el FK nunca será también el PK del niño, como cuando es el caso de una relación de identificación.

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


2

¿Los atributos migrados de padre a hijo ayudan a identificar 1 al hijo?

  • En caso afirmativo : existe la dependencia de identificación, la relación se identifica y la entidad secundaria es "débil".
  • Si no : la dependencia de identificación no existe, la relación no es identificable y la entidad hija es "fuerte".

Tenga en cuenta que la dependencia de identificación implica dependencia de existencia, pero no al revés. Cada FK no NULL significa que un niño no puede existir sin el padre, pero eso solo no hace que la relación sea identificable.

Para obtener más información sobre esto (y algunos ejemplos), eche un vistazo a la sección "Identificar relaciones" de la Guía de métodos de ERwin .

PD: Me doy cuenta de que llego (extremadamente) tarde a la fiesta, pero siento que otras respuestas no son del todo precisas (definiéndolas en términos de dependencia de la existencia en lugar de dependencia de la identificación), o algo serpenteantes. Esperemos que esta respuesta proporcione más claridad ...


1 El FK del niño es parte de la CLAVE PRIMARIA del niño o la restricción ÚNICA (no NULL).


1

Un buen ejemplo proviene del procesamiento de pedidos. Un pedido de un cliente generalmente tiene un Número de pedido que identifica el pedido, algunos datos que ocurren una vez por pedido, como la fecha del pedido y la ID del cliente, y una serie de líneas de pedido. Cada artículo de línea contiene un número de artículo que identifica un artículo de línea dentro de un pedido, un producto pedido, la cantidad de ese producto, el precio del producto y la cantidad del artículo de línea, que podría calcularse multiplicando la cantidad por precio.

El número que identifica una línea de pedido solo lo identifica en el contexto de un solo pedido. La primera línea de pedido en cada pedido es el número de artículo "1". La identidad completa de una línea de pedido es el número de artículo junto con el número de pedido del que forma parte.

La relación padre-hijo entre pedidos y líneas de pedido es, por lo tanto, una relación de identificación. Un concepto estrechamente relacionado en el modelado ER se conoce con el nombre de "subentidad", donde la línea de pedido es una subentidad de orden. Por lo general, una subentidad tiene una relación obligatoria de identificación entre padres e hijos con la entidad a la que está subordinada.

En el diseño clásico de bases de datos, la clave principal de la tabla LineItems sería (OrderNumber, ItemNumber). Algunos de los diseñadores de hoy en día le darían a un artículo un ItemID separado, que sirve como clave principal, y el DBMS lo autoincrementa. Recomiendo el diseño clásico en este caso.


0

Digamos que tenemos esas tablas:

user
--------
id
name


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

La relación entre esas dos tablas identificará la relación. Porque los comentarios solo pueden pertenecer a su propietario, no a otros usuarios. por ejemplo. Cada usuario tiene su propio comentario, y cuando se elimina el usuario, los comentarios de este usuario también deben eliminarse.


0

Una relación de identificación es entre dos entidades fuertes. Una relación no identificativa puede no ser siempre una relación entre una entidad fuerte y una entidad débil. Puede existir una situación en la que un niño mismo tenga una clave primaria, pero la existencia de su entidad puede depender de su entidad principal.

Por ejemplo: puede existir una relación entre un vendedor y un libro donde un vendedor está vendiendo un libro donde el vendedor puede tener su propia clave principal, pero su entidad se crea solo cuando se vende un libro

Referencia basada en Bill Karwin


55
Puede ser útil definir qué quiere decir con una entidad "fuerte" y "débil" aquí.
nulabilidad
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.