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

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

• 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

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.

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!

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

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

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

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.

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.

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.

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

¿Los atributos migrados de padre a hijo ayudan a identificar ¹ 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 ...

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

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.

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.

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