database - semejanzas - ¿Cuál es la diferencia entre un modelo de relación de entidad y un modelo relacional?

modelo relacional vs modelo fisico

Question

Solo pude encontrar las siguientes dos diferencias:

1. Las relaciones en un modelo ER se definen explícitamente, mientras que están implícitas en un modelo relacional.
2. Los modelos relacionales requieren una tabla intermedia (a menudo llamada "tabla de unión") para contener dos claves externas que implementan la relación de muchos a muchos.

¿Y por qué usamos el modelo relacional, cuando tenemos un diagrama ER?

Answer 1

Son dos cosas diferentes per se. Un modelo relacional representa la información como tuplas, directamente mapeadas a un esquema relacional. Las pautas provienen del álgebra relacional.

Mientras tanto, un diagrama ER modela las relaciones entre los usuarios y sus datos subyacentes en un sistema que utiliza entidades. Un diagrama ER se puede asignar a un modelo relacional y, finalmente, a un esquema de trabajo.

Answer 2

Lo tienes al revés.

1. Las relaciones en un modelo ER se definen explícitamente, mientras que están implícitas en un modelo relacional.

No. Cada tabla base de la base de datos del Modelo Relacional (RM) y el resultado de la consulta representan una relación de aplicación. Los esquemas de modelado de entidad-relación (E-RM) son solo una forma de organizar (pero subutilizando y subespecificando) (pero con malentendidos) tablas y restricciones relacionales.

2. Los modelos relacionales requieren una tabla intermedia (a menudo llamada "tabla de unión") para contener dos claves externas que implementan la relación de muchos a muchos.

No. Son los enfoques de Mapeo Relacional de Objetos (ORM) los que oscurecen sus relaciones, tablas y restricciones de aplicaciones relacionales directas subyacentes. La noción de "tabla de unión" surgió de los malentendidos de ORM de las presentaciones confusas del E-RM, que en sí mismo no comprende el RM.

Como CJ Date lo puso Una Introducción a los Sistemas de Base de Datos, 8ª ed:

una lectura caritativa del [artículo original de Chen] sugeriría que el modelo E / R es de hecho un modelo de datos, pero que es esencialmente una capa delgada sobre el modelo relacional básico [p 426]

Es un comentario triste sobre el estado del campo de TI que las soluciones simples son populares incluso cuando son demasiado simples. [p 427]

El modelo relacional

Cada tabla relacional representa una relación de aplicación.

-- employee EID has name NAME and ...
E(EID,NAME,...)

El término matemático para tal cosa, y también para un conjunto matemático de tuplas ordenadas que representa uno, es una "relación". De ahí el "Modelo Relacional " (y el "Modelo Entidad- Relación "). En matemáticas, las relaciones se describen con frecuencia mediante plantillas de enunciados parametrizados para los cuales un término matemático es "predicado característico". Los parámetros del predicado son columnas de la tabla. En el RM, un DBA proporciona un predicado para cada tabla base y los usuarios colocan las filas que hacen una declaración verdadera de los valores de columna y el predicado en la tabla y dejan las filas que hacen una declaración falsa.

/* now also employee 717 has name ''Smith'' and ...
AND employee 202 has name ''Doodle'' and ...
*/
INSERT INTO E VALUES (EID,NAME,...)
(717,''Smith'',...),(202,''Doodle'',...)

Una expresión de consulta también tiene un predicado construido a partir de los operadores de relación y los operadores lógicos (en condiciones). Su valor también contiene las filas que hacen que su predicado sea verdadero y deja de lado las que lo hacen falso.

/* rows where
FOR SOME E.*, M.*,
EID = E.EID AND ... AND MID = M.MID
AND employee E.EID has name E.NAME and ...
AND manager M.MID has
AND E.DEPT = M.DEPT AND E.NAME = ''Smith''
/*
SELECT E.*, M.MID
FROM E JOIN M ON E.DEPT = M.DEPT
WHERE E.NAME = ''Smith''

Las filas actuales de tablas que hacen declaraciones verdaderas y las filas ausentes que hacen declaraciones falsas es cómo registramos sobre la situación de la aplicación en la base de datos y cómo interpretamos lo que la base de datos dice sobre la situación de la aplicación. No se puede usar o interpretar la base de datos sin tener y comprender los predicados, es decir, las relaciones de aplicación.

Modelado de entidad-relación

E-RM (que realmente no entiende el RM) es esencialmente una notación de diagramación (n innecesaria, restringida y restrictiva) para describir (algunas partes de) (formas limitadas de) bases de datos relacionales. Originalmente había iconos / relaciones de "entidad (clase)" donde los valores de la clave candidata (CK) eran 1: 1 con entidades de aplicación más otras columnas ("propiedades" de la "entidad") y había iconos de "relación (clase)" / tablas que tenían claves foráneas (FK) para tablas de entidades que representan relaciones de aplicación en múltiples entidades más otras cosas ("propiedades" de la "asociación"). Una relación de aplicación estaba representada por un ícono con líneas a los diversos íconos de entidad que participaron en ella. (Es decir, las líneas representaban FK. No son relaciones sino afirmaciones sobre restricciones en las tablas).

E-RM no entiende el modelo relacional. Hace una distinción inútil y engañosa entre entidades de aplicación y relaciones. Después de todo, cada superclave (conjunto de columnas único) de cada tabla base o resultado de consulta está en correspondencia 1: 1 con alguna entidad de aplicación, no solo las que tienen tablas de entidad. Por ejemplo, las personas pueden asociarse al casarse; pero cada una de esas asociaciones es 1: 1 con una entidad llamada matrimonio. Esto conduce a una normalización y restricciones inadecuadas, por lo tanto, redundancia y pérdida de integridad. O cuando esos pasos se realizan adecuadamente, conduce al diagrama ER que no describe realmente la aplicación, que en realidad se describe por los predicados, tablas y restricciones de la base de datos relacional. Entonces el diagrama ER es a la vez vago, redundante e incorrecto.

Taquigrafía E-RM y ORM

Muchas presentaciones y productos que afirman ser E-RM deforman el E-RM, y mucho menos el RM. Usan la palabra "relación" para referirse a una restricción FK. Esto surge de la siguiente manera. Cuando una relación E-RM es binaria, es un símbolo con dos líneas a sus FK. Entonces esas tres cosas pueden ser reemplazadas por una línea entre FKs. Este tipo de línea representa esa relación binaria particular y sus FK, pero ahora la relación ER no es explícita en el diagrama, aunque la relación ER es explícita en la versión larga y se refleja en una tabla de lo que los diagramas son imágenes , a saber, el base de datos relacional que están describiendo . Esto se llama una "tabla de unión". Y la gente habla de que esa línea / tabla es / representa "una relación X: Y" entre entidades y / o asociaciones sin darse cuenta de que se trata de una relación de aplicación particular . Y puede haber muchas relaciones de aplicación entre las mismas dos entidades y / o asociaciones.

Los ORM también hacen esto, pero también reemplazan las asociaciones n-arias solo por sus FK para que la relación de aplicación asociada y la tabla se oscurezcan aún más. Active Records va aún más lejos al definir varias relaciones abreviadas y sus tablas a la vez, lo que equivale a una cadena de líneas FK e iconos de asociación en el diagrama E-RM. Esto se ve exacerbado por muchas técnicas de modelado, incluidas las versiones de E-RM y ORM, que también piensan que las relaciones de aplicación solo pueden ser binarias. Nuevamente, esto surgió históricamente de la falta de comprensión de la RM.