Problemas para decidir sobre una relación de identificación o no de identificación

Question

He leído esta pregunta: ¿Cuál es la diferencia entre relaciones de identificación y no identificación?

Pero todavía no estoy muy seguro ... Lo que tengo son tres tablas.

1. Usuarios
2. Objetos
3. Imágenes

Un usuario puede poseer muchos objetos y también puede publicar muchas imágenes por objeto individual. Mi instinto me dice que esta es una relación de identificación, porque necesitaré el ID de usuario en la tabla de objetos y necesitaré el ID de objeto en las tablas de imágenes ...

¿O me equivoco? Las explicaciones en el otro tema se limitan a la explicación teórica de la forma en que la base de datos la interpreta después de que ya ha sido codificada, no cómo se conectan los objetos en la vida real. Estoy un poco confundido sobre cómo tomar la decisión de identificar versus no identificar cuando pienso en cómo voy a construir la base de datos.

Answer 1

Ambos me suenan a identificar relaciones. Si ha escuchado los términos uno a uno o uno a muchos, y muchos a muchos, relaciones uno a uno son relaciones de identificación , y < fuertes> relaciones de muchos a muchos son relaciones no identificables .

• Si el niño identifica a su padre, es una relación de identificación. En el enlace que ha proporcionado, si tiene un número de teléfono, sabe a quién pertenece (solo pertenece a uno).

• Si el niño no identifica a su padre, es una relación no identificable. En el enlace, menciona estados. Piense en un estado como una fila en una tabla que representa el estado de ánimo. "Feliz" no identifica a una persona en particular, sino a muchas personas.

Editar : Otros ejemplos de la vida real:

• Una dirección física es una relación no identificable, porque muchas personas pueden residir en una dirección. Por otro lado, una dirección de correo electrónico es (generalmente considerada) una relación de identificación.
• Un Número de Seguro Social es una relación de identificación, porque solo pertenece a una persona
• Los comentarios en los videos de Youtube son relaciones identificativas, porque solo pertenecen a un video.
• El original de una pintura solo tiene un propietario (identificativo), mientras que muchas personas pueden tener reimpresiones de la pintura (no identificable).

Answer 2

Creo que una forma más fácil de visualizarlo es preguntarse si el registro secundario puede existir sin el padre. Por ejemplo, una línea de pedido requiere un encabezado de pedido para existir. Por lo tanto, una línea de pedido debe tener el identificador del encabezado del pedido como parte de su clave y, por lo tanto, este es un ejemplo de una relación de identificación.
Por otro lado, los números de teléfono pueden existir sin la propiedad de una persona, aunque una persona puede tener varios números de teléfono. En este caso, la persona que posee el número de teléfono es una relación que no es clave o no identificable, ya que los números de teléfono pueden existir independientemente de la persona propietaria (por lo tanto, la persona propietaria del número de teléfono puede ser nula, mientras que en el ejemplo de la línea de pedido , el identificador del encabezado del pedido no puede ser nulo.

Answer 3

  

NickC dijo: las relaciones uno a uno son relaciones de identificación, y las relaciones muchos a muchos son relaciones no identificables

La explicación me parece totalmente errónea. Puedes tener:

• Relaciones personales no identificables
• Relaciones no identificables de uno a muchos
• Relaciones de identificación uno a uno
• Relaciones de identificación uno a muchos
• Relaciones de identificación de muchos a muchos

Imagine que tiene las siguientes tablas: customer , products y feedback . Todos ellos se basan en el customer_id que existe en la tabla cutomer . Entonces, según la definición de NickC no debería existir ningún tipo de relación de identificación de muchos a muchos, sin embargo, en mi ejemplo, puede ver claramente que: Una retroalimentación solo puede existir si el El Producto relevante existe y ha sido comprado por el Cliente, por lo que el Cliente, los Productos y los Comentarios deben Identificarse .

Puede consultar Manual de MySQL , explicando cómo agregar claves externas en MySQL Workbench también.

Answer 4

Mahdi, tus instintos son correctos. Esta es una pregunta duplicada y esta respuesta votada no es correcta o completa. Mira las dos respuestas principales aquí: diferencia entre identificar no identificar

Identificar vs no identificar no tiene nada que ver con la identidad. Simplemente pregúntese ¿puede existir el registro secundario sin el padre? Si la respuesta es sí, no es identificable.

El problema central es si la clave primaria del elemento secundario incluye la clave externa del elemento primario. En la relación no identificativa, la clave primaria (PK) del niño no puede incluir la clave externa (FK).

Hágase esta pregunta

• ¿Puede existir el registro secundario sin el registro primario?

Si el niño puede existir sin el padre, entonces la relación no es identificable. (Gracias MontrealDevOne por indicarlo más claramente)

Relación de identificación uno a uno

Los números de seguridad social encajan perfectamente en esta categoría. Imaginemos, por ejemplo, que los números de seguridad social no pueden existir sin una persona (tal vez sí pueden, en realidad, pero no en nuestra base de datos). > person_id sería el PK para la tabla persona , incluidas columnas como nombre y dirección . (hagámoslo simple). La tabla social_security_number incluiría la columna ssn y la columna person_id como clave externa. Dado que este FK se puede usar como PK para la tabla social_security_number , es una relación de identificación.

Relación uno a uno no identificable

En un complejo de oficinas grande, es posible que tenga una tabla de oficina que incluya los números de habitación por piso y número de edificio con un PK, y una tabla separada de empleados . La tabla de empleados (secundario) tiene un FK que es la columna office_id de la tabla PK de office . Si bien cada empleado tiene solo una oficina y (para este ejemplo) cada oficina solo tiene un empleado, esta es una relación no identificable ya que las oficinas pueden existir sin empleados, y los empleados pueden cambiar de oficina o trabajar en el campo.

Relaciones uno a muchos

Las relaciones uno a muchos se pueden clasificar fácilmente haciendo la misma pregunta.

Relaciones de muchos a muchos

Las relaciones de muchos a muchos siempre son relaciones de identificación. Esto puede parecer contrario a la intuición, pero ten paciencia conmigo. Tome dos tablas libary y books , cada biblioteca tiene muchos libros y existe una copia de cada libro en muchas bibliotecas.

Esto es lo que lo hace y la relación de identificación: Para implementar esto, necesita una tabla de enlace con dos columnas que son las claves principales de cada tabla. Llámalos columna library_id y columna ISBN . Esta nueva tabla de enlace no tiene una clave primaria separada, ¡pero espera! Las claves foráneas se convierten en una clave primaria de varias columnas para la tabla de enlace, ya que los registros duplicados en la tabla de enlace no tendrían sentido. Los enlaces no pueden existir sin los padres; por lo tanto, esta es una relación de identificación. Lo sé, ¿verdad?

La mayoría de las veces el tipo de relación no importa.

Todo lo dicho, generalmente no tienes que preocuparte por lo que tienes. Simplemente asigne las claves primarias y externas adecuadas a cada tabla y la relación se descubrirá sola.

EDITAR: NicoleC , leí el contesta que vinculaste y está de acuerdo con la mía. Tomo su punto sobre el SSN, y estoy de acuerdo en que es un mal ejemplo. Trataré de pensar en otro ejemplo más claro allí. Sin embargo, si comenzamos a usar analogías del mundo real para definir una relación de base de datos, las analogías siempre se rompen. No importa, si un SSN identifica a una persona, importa si lo usó como clave externa.