Un modelo entidad-relación (o modelo ER ) describe cosas interrelacionadas de interés en un dominio específico de conocimiento. Un modelo ER básico se compone de tipos de entidades (que clasifican las cosas de interés) y especifica las relaciones que pueden existir entre entidades (instancias de esos tipos de entidades).
En ingeniería de software , un modelo ER se forma comúnmente para representar cosas que una empresa necesita recordar para realizar procesos comerciales . En consecuencia, el modelo ER se convierte en un modelo de datos abstracto , [1] que define una estructura de datos o información que se puede implementar en una base de datos , generalmente una base de datos relacional .
El modelado de entidad-relación fue desarrollado para bases de datos y diseño por Peter Chen y publicado en un artículo de 1976, [2] con variantes de la idea que existían previamente. [3] Hoy en día se utiliza comúnmente para enseñar a los estudiantes los conceptos básicos de la estructura de bases de datos. Algunos modelos ER muestran entidades super y subtipos conectadas por relaciones de generalización-especialización, [4] y un modelo ER también se puede utilizar para especificar ontologías específicas del dominio .
Un modelo ER suele ser el resultado de un análisis sistemático para definir y describir los datos creados y necesarios por los procesos de un área de negocio. Normalmente, representa registros de entidades y eventos supervisados y dirigidos por procesos de negocio, en lugar de los procesos en sí. Suele dibujarse en forma gráfica como cuadros ( entidades ) que están conectados por líneas ( relaciones ) que expresan las asociaciones y dependencias entre entidades. También se puede expresar en forma verbal, por ejemplo: un edificio puede estar dividido en cero o más apartamentos, pero un apartamento solo puede estar ubicado en un edificio.
Las entidades pueden definirse no sólo por relaciones, sino también por propiedades adicionales ( atributos ), que incluyen identificadores llamados "claves primarias". Los diagramas creados para representar atributos, así como entidades y relaciones, pueden llamarse diagramas entidad-atributo-relación, en lugar de modelos entidad-relación.
Un modelo ER se implementa típicamente como una base de datos . En una implementación de base de datos relacional simple, cada fila de una tabla representa una instancia de un tipo de entidad y cada campo de una tabla representa un tipo de atributo. En una base de datos relacional, una relación entre entidades se implementa almacenando la clave principal de una entidad como un puntero o "clave externa" en la tabla de otra entidad.
Existe una tradición de construir modelos ER/datos en dos o tres niveles de abstracción. La jerarquía conceptual-lógica-física que se muestra a continuación se utiliza en otros tipos de especificaciones y es diferente del enfoque de tres esquemas para la ingeniería de software .
La primera etapa del diseño de un sistema de información utiliza estos modelos durante el análisis de requisitos para describir las necesidades de información o el tipo de información que se va a almacenar en una base de datos . La técnica de modelado de datos se puede utilizar para describir cualquier ontología (es decir, una descripción general y clasificaciones de los términos utilizados y sus relaciones) para un área de interés determinada . En el caso del diseño de un sistema de información que se basa en una base de datos, el modelo de datos conceptual se asigna, en una etapa posterior (generalmente llamada diseño lógico), a un modelo de datos lógico , como el modelo relacional . Este, a su vez, se asigna a un modelo físico durante el diseño físico. A veces, ambas fases se denominan "diseño físico".
Una entidad puede definirse como una cosa que es capaz de tener una existencia independiente, que puede ser identificada de manera única y que es capaz de almacenar datos. [5] Una entidad es una abstracción de las complejidades de un dominio. Cuando hablamos de una entidad, normalmente nos referimos a algún aspecto del mundo real que puede distinguirse de otros aspectos del mundo real. [6]
Una entidad es una cosa que existe física o lógicamente. Una entidad puede ser un objeto físico como una casa o un coche (existen físicamente), un acontecimiento como la venta de una casa o un servicio de reparación de un coche, o un concepto como una transacción o un pedido de un cliente (existen lógicamente, como un concepto). Aunque el término entidad es el que se utiliza con más frecuencia, siguiendo a Chen, se debe distinguir entre entidades y tipos de entidad. Un tipo de entidad es una categoría. Una entidad, en sentido estricto, es una instancia de un tipo de entidad determinado. Normalmente hay muchas instancias de un tipo de entidad. Como el término tipo de entidad es algo engorroso, la mayoría de la gente tiende a utilizar el término entidad como sinónimo.
Las entidades pueden considerarse como sustantivos . [7] Algunos ejemplos incluyen una computadora, un empleado, una canción o un teorema matemático.
Una relación captura cómo se relacionan las entidades entre sí. Las relaciones pueden considerarse como verbos que unen dos o más sustantivos. [7] Algunos ejemplos incluyen una relación de posee entre una empresa y una computadora, una relación de supervisa entre un empleado y un departamento, una relación de realiza entre un artista y una canción y una relación de prueba entre un matemático y una conjetura.
El aspecto lingüístico del modelo descrito anteriormente se utiliza en el lenguaje de consulta de bases de datos declarativo ERROL, que imita las construcciones del lenguaje natural . La semántica y la implementación de ERROL se basan en el álgebra relacional reformada (RRA), un álgebra relacional que se adapta al modelo entidad-relación y captura su aspecto lingüístico.
Tanto las entidades como las relaciones pueden tener atributos. Por ejemplo, una entidad de empleado puede tener un atributo de número de seguro social (SSN), mientras que una relación comprobada puede tener un atributo de fecha .
Todas las entidades, excepto las débiles, deben tener un conjunto mínimo de atributos de identificación única que puedan usarse como clave única / principal .
Los diagramas de entidad-relación (ERD) no muestran entidades individuales o instancias individuales de relaciones. En cambio, muestran conjuntos de entidades (todas las entidades del mismo tipo de entidad) y conjuntos de relaciones (todas las relaciones del mismo tipo de relación). Por ejemplo, una canción en particular es una entidad, la colección de todas las canciones en una base de datos es un conjunto de entidades, la relación de comida entre un niño y su almuerzo es una relación única, y el conjunto de todas esas relaciones de niño-almuerzo en una base de datos es un conjunto de relaciones. En otras palabras, un conjunto de relaciones corresponde a una relación en matemáticas , mientras que una relación corresponde a un miembro de la relación.
También se pueden indicar ciertas restricciones de cardinalidad en conjuntos de relaciones.
Las vistas físicas muestran cómo se almacenan realmente los datos.
El artículo original de Chen ofrece un ejemplo de relación y sus roles. Describe una relación llamada "matrimonio" y sus dos roles, "marido" y "esposa".
Una persona desempeña el papel de marido en un matrimonio (relación) y otra persona desempeña el papel de esposa en el (mismo) matrimonio. Estas palabras son sustantivos.
La terminología de Chen también se ha aplicado a ideas anteriores. Las líneas, flechas y patas de gallo de algunos diagramas deben más a los diagramas de Bachman anteriores que a los diagramas de relaciones de Chen.
Otra extensión común del modelo de Chen es “nombrar” relaciones y roles como verbos o frases.
También se ha vuelto común nombrar roles con frases como es el dueño de y es propiedad de . Los sustantivos correctos en este caso son propietario y posesión . Por lo tanto, persona desempeña el papel de propietario y coche desempeña el papel de posesión en lugar de persona desempeña el papel de , es el dueño de , etc.
El uso de sustantivos tiene un beneficio directo a la hora de generar implementaciones físicas a partir de modelos semánticos. Cuando una persona tiene dos relaciones con un coche, es posible generar nombres como owner_person y driver_person , que tienen un significado inmediato. [9]
Las modificaciones a la especificación original pueden resultar beneficiosas. Chen describió las cardinalidades transversales. Como acotación al margen, la notación Barker-Ellis , utilizada en Oracle Designer, utiliza el mismo lado para la cardinalidad mínima (análoga a la opcionalidad) y el rol, pero la cardinalidad transversal para la cardinalidad máxima (la pata de gallo). [ Aclaración necesaria ]
Las investigaciones de Merise , Elmasri y Navathe y otros han demostrado que existe una preferencia por el mismo lado para los roles y las cardinalidades mínimas y máximas, [10] [11] [12] y los investigadores (Feinerer, Dullea et al.) han demostrado que esto es más coherente cuando se aplica a relaciones n-arias de orden mayor que 2. [13] [14]
Dullea et al. afirman: "Una notación de 'mirada transversal' como la utilizada en UML no representa eficazmente la semántica de las restricciones de participación impuestas en las relaciones donde el grado es mayor que el binario".
Feinerer dice: "Los problemas surgen si operamos bajo la semántica de look-across que se utiliza para las asociaciones UML. Hartmann [15] investiga esta situación y muestra cómo y por qué fallan diferentes transformaciones". (Aunque la "reducción" mencionada es espuria ya que los dos diagramas 3.4 y 3.5 son de hecho el mismo) y también "Como veremos en las próximas páginas, la interpretación de look-across introduce varias dificultades que impiden la extensión de mecanismos simples de asociaciones binarias a n-arias".
La notación de Chen para el modelado de entidades y relaciones utiliza rectángulos para representar conjuntos de entidades y rombos para representar relaciones apropiadas para objetos de primera clase : pueden tener atributos y relaciones propios. Si un conjunto de entidades participa en un conjunto de relaciones, se conectan con una línea.
Los atributos se dibujan como óvalos y se conectan con una línea a exactamente una entidad o conjunto de relaciones.
Las restricciones de cardinalidad se expresan de la siguiente manera:
Los atributos suelen omitirse porque pueden saturar el diagrama. Otras técnicas de diagramación suelen incluir atributos de entidad dentro de los rectángulos dibujados para los conjuntos de entidades.
La notación de pata de gallo, cuyo comienzo se remonta a un artículo de Gordon Everest (1976), [16] se utiliza en la notación de Barker , el método de análisis y diseño de sistemas estructurados (SSADM) y la ingeniería de tecnologías de la información . Los diagramas de pata de gallo representan las entidades como cajas y las relaciones como líneas entre las cajas. Diferentes formas en los extremos de estas líneas representan la cardinalidad relativa de la relación.
La notación de pata de gallo se utilizaba en ICL en 1978, [17] y se utilizaba en la práctica de consultoría CACI . Muchos de los consultores de CACI (incluido Richard Barker) provenían de ICL y posteriormente se trasladaron a Oracle UK, donde desarrollaron las primeras versiones de las herramientas CASE de Oracle , presentando la notación a un público más amplio.
Con esta notación, las relaciones no pueden tener atributos. Cuando es necesario, las relaciones se convierten en entidades por derecho propio: por ejemplo, si es necesario capturar dónde y cuándo un artista interpretó una canción, se introduce una nueva entidad, "interpretación" (con atributos que reflejan el tiempo y el lugar), y la relación de un artista con una canción se convierte en una relación indirecta a través de la interpretación (artista-interpreta-interpretación, interpretación-presenta-canción).
Se utilizan tres símbolos para representar la cardinalidad:
Estos símbolos se utilizan en pares para representar los cuatro tipos de cardinalidad que puede tener una entidad en una relación. El componente interno de la notación representa el mínimo y el componente externo representa el máximo.
Los usuarios de una base de datos modelada pueden encontrarse con dos problemas bien conocidos en los que los resultados devueltos difieren de lo que supuso el autor de la consulta. Estos problemas se conocen como trampa del abanico y trampa del abismo, y pueden generar resultados de consulta inexactos si no se manejan adecuadamente durante el diseño del modelo de entidad-relación (modelo ER).
El primer problema es la trampa del abanico. Se produce cuando una tabla (principal) se vincula a varias tablas en una relación de uno a muchos. El problema deriva su nombre de la apariencia visual del modelo cuando se dibuja en un diagrama de entidad-relación, ya que las tablas vinculadas se "despliegan" a partir de la tabla principal. Este tipo de modelo se asemeja a un esquema en estrella , que es un diseño común en los almacenes de datos. Al intentar calcular sumas sobre agregados utilizando consultas SQL estándar basadas en la tabla principal, los resultados pueden ser inesperados y, a menudo, incorrectos debido a la forma en que se estructuran las relaciones. El error de cálculo ocurre porque SQL trata cada relación individualmente, lo que puede dar lugar a un doble conteo u otras imprecisiones. Este problema es particularmente común en los sistemas de soporte de decisiones. Para mitigarlo, se debe ajustar el modelo de datos o la propia consulta SQL . Algunos programas de consulta de bases de datos diseñados para el soporte de decisiones incluyen métodos integrados para detectar y abordar las trampas del abanico.
El segundo problema es la trampa del abismo, que se produce cuando un modelo sugiere la existencia de una relación entre tipos de entidades, pero la vía entre estas entidades está incompleta o no existe en ciertos casos.
Por ejemplo, imagine una base de datos donde un edificio tiene una o más salas, y estas salas contienen cero o más computadoras. Se podría esperar consultar el modelo para enumerar todas las computadoras en un edificio. Sin embargo, si una computadora no está asignada temporalmente a una sala (tal vez en reparación o almacenada en otro lugar), no se incluirá en los resultados de la consulta. La consulta solo devolvería las computadoras actualmente asignadas a las salas, no todas las computadoras en el edificio. Esto refleja una falla en el modelo, ya que no tiene en cuenta las computadoras que están en el edificio pero no en una sala. Para resolver esto, se requeriría una relación adicional que vincule directamente el edificio y las computadoras. La trampa del abismo, como la trampa del abanico, a menudo es el resultado de no representar completamente las relaciones del mundo real en el modelo de la base de datos.
Tanto la trampa del abanico como la trampa del abismo subrayan la importancia de garantizar que los modelos ER no solo sean técnicamente correctos, sino que también reflejen con precisión las relaciones del mundo real que están diseñados para representar. Identificar y resolver estas trampas en las primeras etapas del proceso de diseño ayuda a evitar problemas importantes más adelante, especialmente en bases de datos complejas destinadas a inteligencia empresarial o soporte de decisiones.
Un modelo semántico es un modelo de conceptos y a veces se lo denomina "modelo independiente de la plataforma". Es un modelo intensional. Al menos desde Carnap , es bien sabido que: [18]
Un modelo extensional es aquel que se asigna a los elementos de una metodología o tecnología en particular y, por lo tanto, es un "modelo específico de la plataforma". La especificación UML establece explícitamente que las asociaciones en los modelos de clases son extensionales y esto es, de hecho, evidente si se considera la amplia gama de "adornos" adicionales que proporciona la especificación además de los que proporciona cualquiera de los "lenguajes de modelado semántico" candidatos anteriores. "UML como notación de modelado de datos, parte 2"
Peter Chen, el padre del modelado ER, dijo en su artículo fundamental:
En su artículo original de 1976, Chen contrasta explícitamente los diagramas entidad-relación con las técnicas de modelado de registros:
Varios otros autores también apoyan el programa de Chen: [19] [20] [21] [22] [23]
Chen está de acuerdo con las tradiciones filosóficas de la época de los filósofos griegos antiguos: Platón y Aristóteles . [24] El propio Platón asocia el conocimiento con la aprehensión de Formas inmutables (es decir, arquetipos o representaciones abstractas de los muchos tipos de cosas y propiedades) y sus relaciones entre sí.
