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

Solo pude encontrar las siguientes dos diferencias:

  1. Las relaciones en un modelo ER están explícitamente definidas, 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 diagtwig ER?

    Lo tienes al revés

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

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

    1. 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. Los enfoques de Asignación relacional de objetos (ORM) oscurecen sus relaciones, tablas y restricciones de aplicaciones relacionales directas subyacentes. La noción de “mesa de reunión” surgió de los malentendidos de ORM sobre las presentaciones confusas del E-RM que a su vez malinterpreta el RM.

    Como lo citó CJ Date, Introducción a los sistemas de bases de datos, octava edición:

    una lectura benéfica del [artículo original de Chen] sugeriría que el modelo E / R es de hecho un modelo de datos, pero que es esencialmente solo 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 ordenado-tupla que representa a uno, es una “relación”. De ahí el “Modelo Relacional ” (y el “Modelo de Relación de Entidad”). En matemáticas, las relaciones se describen con frecuencia mediante plantillas de statement parametrizadas para las 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 da un predicado para cada tabla base y los usuarios colocan las filas que hacen una statement verdadera de los valores de columna y el predicado en la tabla y dejan las filas que hacen una statement 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 creado a partir de la relación operadores y operadores lógicos (en condiciones) en él. Su valor también contiene las filas que hacen que su predicado sea verdadero y deja fuera los 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 son cómo registramos sobre la situación de la aplicación en la base de datos y cómo interpretamos lo que dice la base de datos sobre la situación de la aplicación. Uno no puede usar o interpretar la base de datos sin tener y entender los predicados, es decir, las relaciones de aplicación.

    Modelado de relación de entidad

    E-RM (que realmente no entiende el RM) es esencialmente una notación de diagtwigción (n innecesaria, restringida y restrictiva) para describir (algunas partes de) (formas limitadas de) bases de datos relacionales. Originalmente había icons / 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 icons de “relación (clase)” / tablas que tenían claves foráneas (FK) a tablas de entidades que representan relaciones de aplicación en entidades múltiples más otras cosas (“propiedades” de la “asociación”). Una relación de aplicación se representó mediante un ícono con líneas a los diversos icons de entidad que participaron en él. (Es decir, las líneas representan FK. Que no son relaciones, sino declaraciones 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 estando casadas; pero cada asociación 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 bien, cuando esos pasos se llevan a cabo adecuadamente, el diagtwig ER no describe realmente la aplicación, que en realidad se describe mediante los predicados, tablas y restricciones de la base de datos relacional. Entonces, el diagtwig ER es ambiguo, redundante e incorrecto.

    Taquigrafía E-RM y ORMs

    Muchas presentaciones y productos que pretenden ser E-RM deforman el E-RM, y mucho menos el RM. Usan la palabra “relación” para significar 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 para sus FK. Entonces esas tres cosas pueden ser reemplazadas por una línea entre FK. 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 diagtwig, aunque la relación ER es explícita en la versión a mano y se refleja en una tabla en la que los diagtwigs son imágenes , es decir, base de datos relacional que están describiendo . Esto recibe el nombre de “mesa 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 lo hacen, pero también reemplazan las asociaciones n-arias por solo sus FK, de modo que la relación y la tabla de aplicación asociadas se oscurecen aún más. Active Records va más allá al definir varias relaciones de taquigrafía y sus tablas a la vez, equivalentes a una cadena de líneas FK e íconos de asociación en el diagtwig E-RM de mano larga. Esto se ve agravado por muchas técnicas de modelado, incluidas versiones de E-RM y ORM, que también piensan que las relaciones de aplicación solo pueden ser binarias. Una vez más, esto surgió históricamente por la falta de comprensión de la RM.

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

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