database - teoria - Todavía está confundido acerca de las relaciones de identificación frente a las relaciones de no identificación

teoria de las migraciones (7)

"como no quiero aprender algo mal".

Bueno, si de verdad quieres decir eso, entonces puedes dejar de preocuparte por la jerga y la terminología de ER. Es impreciso, confuso, confuso, para nada acordado en general, y en su mayor parte irrelevante.

ER es un grupo de rectángulos y líneas rectas dibujadas en un pedazo de papel. ER tiene la intención de ser un medio para el modelado informal . Como tal, es un primer paso valioso en el diseño de bases de datos, pero también es eso: un primer paso.

Nunca un diagrama ER se acercará a la precisión, precisión e integridad de un diseño de base de datos escrito formalmente en D.

Por lo tanto, he estado leyendo acerca de las relaciones de identificación frente a las no identificables en el diseño de mi base de datos, y algunas de las respuestas de SO me parecen contradictorias. Aquí están las dos preguntas que estoy viendo:

Mirando las respuestas principales de cada pregunta, parece que tengo dos ideas diferentes de lo que es una relación de identificación.

La respuesta de la primera pregunta dice que una relación de identificación "describe una situación en la que la existencia de una fila en la tabla secundaria depende de una fila en la tabla principal". Un ejemplo de esto que se da es, "Un autor puede escribir muchos libros (relación 1-a-n), pero un libro no puede existir sin un autor". Eso tiene sentido para mí.

Sin embargo, cuando leí la respuesta a la pregunta dos, me confundí porque decía: "si un niño identifica a su padre, se trata de una relación de identificación". La respuesta pasa luego a dar ejemplos como el Número de Seguridad Social (es la identificación de una Persona), pero una dirección no lo es (porque muchas personas pueden vivir en una dirección). Para mí, esto suena más como un caso de decisión entre la clave principal y la clave no primaria.

Mi propia corazonada (y la investigación adicional en otros sitios) apunta a la primera pregunta y su respuesta es correcta. Sin embargo, quería verificar antes de seguir adelante ya que no quiero aprender algo incorrecto ya que estoy trabajando para comprender el diseño de la base de datos. Gracias por adelantado.

Creo que solo la diferencia entre una relación de identificación y una de no identificación es sobre la Nulidad de la clave externa. Si un FK no puede ser NULL, la relación que representa es la identificación (el niño no puede existir sin el padre) sino que es no identificable.

La definición técnica de una relación de identificación es que la clave externa de un niño es parte de su clave principal.

CREATE TABLE AuthoredBook ( author_id INT NOT NULL, book_id INT NOT NULL, PRIMARY KEY (author_id, book_id), FOREIGN KEY (author_id) REFERENCES Authors(author_id), FOREIGN KEY (book_id) REFERENCES Books(book_id) );

¿Ver? book_id es una clave externa, pero también es una de las columnas de la clave principal. Entonces esta tabla tiene una relación de identificación con los Books tabla referenciados. Asimismo, tiene una relación de identificación con los Authors .

Un comentario en un video de YouTube tiene una relación de identificación con el video respectivo. El video_id debe ser parte de la clave principal de la tabla de Comments .

CREATE TABLE Comments ( video_id INT NOT NULL, user_id INT NOT NULL, comment_dt DATETIME NOT NULL, PRIMARY KEY (video_id, user_id, comment_dt), FOREIGN KEY (video_id) REFERENCES Videos(video_id), FOREIGN KEY (user_id) REFERENCES Users(user_id) );

Puede ser difícil de entender porque es una práctica común en estos días usar solo una clave sustituta en serie en lugar de una clave primaria compuesta:

CREATE TABLE Comments ( comment_id SERIAL PRIMARY KEY, video_id INT NOT NULL, user_id INT NOT NULL, comment_dt DATETIME NOT NULL, FOREIGN KEY (video_id) REFERENCES Videos(video_id), FOREIGN KEY (user_id) REFERENCES Users(user_id) );

Esto puede oscurecer los casos donde las tablas tienen una relación de identificación.

No consideraría el SSN como una relación de identificación. Algunas personas existen, pero no tienen un SSN. Otras personas pueden presentar una solicitud para obtener un nuevo SSN. Entonces, el SSN es realmente solo un atributo, no parte de la clave principal de la persona.

Comentario de @Niels:

Entonces, si usamos una clave sustituta en lugar de una clave primaria compuesta, ¿no hay una diferencia notable entre la relación de identificación de uso o la relación de no identificación?

Supongo que sí. Dudo en decir que sí, porque no hemos cambiado la relación lógica entre las tablas mediante el uso de una clave sustituta. Es decir, aún no puede hacer un comentario sin hacer referencia a un video existente. Pero eso solo significa que video_id no debe ser NULO. Y el aspecto lógico es, para mí, realmente el objetivo de identificar las relaciones.

Pero también hay un aspecto físico de identificar relaciones. Y ese es el hecho de que la columna de clave externa es parte de la clave primaria (la clave primaria no es necesariamente una clave compuesta, podría ser una sola columna que es tanto la clave principal de Comentarios como la clave externa de la tabla Videos , pero eso significa que puedes almacenar solo un comentario por video).

Identificar las relaciones parece ser importante solo por el diagrama de relaciones entre entidades, y esto aparece en las herramientas de modelado de datos de GUI.

Las relaciones de identificación / no identificación son conceptos en el modelado de ER. Una relación es identificable si está representada por una clave externa que es parte de la clave principal de la tabla de referencia. Esto suele ser de muy poca importancia en términos de modelado relacional porque las claves primarias en el modelo relacional y en las bases de datos SQL no tienen ningún significado o función especial como lo hacen en un modelo ER.

Por ejemplo, suponga que su tabla impone dos claves candidatas, A y B. Suponga que A también es una clave externa en esa tabla. La relación así representada se considera que es "identificativa" si A se designa como la clave "primaria", pero no identifica si B es la clave primaria. ¡Sin embargo, la forma, la función y el significado de la tabla son idénticos en cada caso! Por eso, en mi opinión, no creo que el concepto de identificación / no identificación sea realmente muy importante.

Parte del problema aquí es la confusión de la terminología. las relaciones de identificación son útiles para evitar rutas largas de unión.

La mejor definición que he visto es que "una relación de identificación incluye el PK como del padre en el PK del niño. En otras palabras, el PK del niño incluye el FK al padre así como el PK" real "del niño.

Sí, ve con el primero, pero no creo que el segundo contradiga al primero. Está formulado un poco confuso ...

ACTUALIZAR:

Acabo de comprobar: la respuesta a la segunda pregunta es incorrecta en algunas suposiciones, el libro-autor no es necesariamente una relación 1: n, ya que podría ser m: n. En bases de datos relacionales que crean una tabla de intersección para esta relación m: n, y se obtienen relaciones de identificación entre la tabla de intersección y esas otras 2 tablas.

la relación de identificación da una relación opcional de uno a muchos cuando tenemos que definir la relación de padre a hijo. Además, proporciona una relación de uno a uno solo desde el flujo primario a secundario. La clave principal de la entidad principal será la parte de la clave primaria de la entidad hijo. la instancia de la entidad hijo identificará la instancia de la entidad padre. se representa mediante una línea continua en el diagrama ER.

donde la relación no identificable tendrá una relación de muchos a muchos.Para la existencia de instancia de entidad hijo, debe haber instancia de entidad padre pero cada instancia de entidad en entidad hijo puede estar relacionada con muchas instancias de entidad padre. Esta es la razón por la cual la clave primaria de la entidad padre será la clave foránea de la entidad hijo, pero la entidad hijo no tomará la clave primaria de la entidad padre como su clave primaria. Tendrá su propia clave primaria. la relación de muchos a muchos no existe en el diagrama del mundo real. entonces necesita ser resuelto