Modelo entidad-relación

Este artículo necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Modelo entidad-relación» – noticias  · periódicos  · libros  · académico  · JSTOR ( noviembre de 2016 ) ( Aprenda cómo y cuándo eliminar este mensaje )

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 .

Modelo de datos conceptual

Este es el modelo ER de más alto nivel, ya que contiene el menor nivel de detalle granular, pero establece el alcance general de lo que se incluirá en el conjunto de modelos. El modelo ER conceptual normalmente define entidades de datos de referencia maestras que la organización utiliza habitualmente. El desarrollo de un modelo ER conceptual para toda la empresa es útil para respaldar la documentación de la arquitectura de datos de una organización.

Un modelo ER conceptual puede utilizarse como base para uno o más modelos de datos lógicos (véase más adelante). El objetivo del modelo ER conceptual es establecer una similitud de metadatos estructurales para las entidades de datos maestros entre el conjunto de modelos ER lógicos. El modelo de datos conceptual puede utilizarse para formar relaciones de similitud entre los modelos ER como base para la integración de modelos de datos.

Modelo de datos lógicos

Un modelo ER lógico no requiere un modelo ER conceptual, especialmente si el alcance del modelo ER lógico incluye únicamente el desarrollo de un sistema de información específico. El modelo ER lógico contiene más detalles que el modelo ER conceptual. Además de las entidades de datos maestros, ahora se definen las entidades de datos operacionales y transaccionales. Se desarrollan los detalles de cada entidad de datos y se establecen las relaciones entre estas entidades de datos. Sin embargo, el modelo ER lógico se desarrolla independientemente del sistema de gestión de bases de datos específico en el que se puede implementar.

Modelo de datos físicos

Se pueden desarrollar uno o más modelos ER físicos a partir de cada modelo ER lógico. El modelo ER físico normalmente se desarrolla para ser instanciado como una base de datos. Por lo tanto, cada modelo ER físico debe contener suficiente detalle para producir una base de datos y cada modelo ER físico depende de la tecnología ya que cada sistema de gestión de bases de datos es algo diferente.

El modelo físico normalmente se instancia en los metadatos estructurales de un sistema de gestión de bases de datos como objetos de bases de datos relacionales, como tablas de bases de datos , índices de bases de datos como índices de clave única y restricciones de bases de datos como una restricción de clave externa o una restricción de características comunes. El modelo ER también se utiliza normalmente para diseñar modificaciones a los objetos de bases de datos relacionales y para mantener los metadatos estructurales de la base de datos.

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:

• una línea doble indica una restricción de participación , totalidad o sobreyectividad : todas las entidades en el conjunto de entidades deben participar en al menos una relación en el conjunto de relaciones;
• una flecha desde un conjunto de entidades a un conjunto de relaciones indica una restricción clave , es decir, inyectividad : cada entidad del conjunto de entidades puede participar como máximo en una relación en el conjunto de relaciones;
• una línea gruesa indica ambas, es decir, biyectividad : cada entidad en el conjunto de entidades está involucrada en exactamente una relación.
• Un nombre subrayado de un atributo indica que es una clave : dos entidades o relaciones diferentes con este atributo siempre tienen valores diferentes para este atributo.

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.

• Notación de Bachman
• Notación de Barker
• EXPRESAR
• IDEF1X
• § Notación de pata de gallo (también notación Martin )
• (min, max)-notación de Jean-Raymond Abrial en 1974
• Diagramas de clases UML
• Merise
• Modelado de roles de objetos

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:

• El anillo representa el "cero"
• El guión representa "uno"
• La pata de gallo representa "muchos" o "infinito"

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.

• anillo y guión → mínimo cero, máximo uno (opcional)
• guión y guión → mínimo uno, máximo uno (obligatorio)
• anillo y pata de gallo → mínimo cero, máximo muchos (opcional)
• guión y pata de gallo → mínimo uno, máximo muchos (obligatorio)

Esta sección necesita ser ampliada con: causas de las trampas de ventilador. Puedes ayudar agregando más información. ( Febrero de 2018 )

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]

"...el significado pleno de un concepto está constituido por dos aspectos, su intención y su extensión. La primera parte comprende la inserción de un concepto en el mundo de los conceptos en su conjunto, es decir, la totalidad de todas las relaciones con otros conceptos. La segunda parte establece el significado referencial del concepto, es decir, su contraparte en el mundo real o en un mundo posible".

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:

" El modelo entidad-relación adopta la visión más natural de que el mundo real está formado por entidades y relaciones. Incorpora parte de la información semántica importante sobre el mundo real " . ^[2]

En su artículo original de 1976, Chen contrasta explícitamente los diagramas entidad-relación con las técnicas de modelado de registros:

" El diagrama de estructura de datos es una representación de la organización de registros y no es una representación exacta de entidades y relaciones " .

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í.

• Un modelo ER es principalmente conceptual, una ontología que expresa predicados en un dominio de conocimiento.
• Los modelos ER se utilizan con frecuencia para representar estructuras de bases de datos relacionales (después de Codd y Date), pero no tan a menudo para representar otros tipos de estructuras de datos (como almacenes de datos y almacenes de documentos).
• Algunas notaciones del modelo ER incluyen símbolos para mostrar relaciones de supersubtipos y exclusión mutua entre relaciones; otras no.
• Un modelo ER no muestra la historia de vida de una entidad (cómo sus atributos y/o relaciones cambian con el tiempo en respuesta a eventos). Para muchos sistemas, esos cambios de estado no son triviales y son lo suficientemente importantes como para justificar una especificación explícita.
• Algunos ^{[¿ quiénes? ]} han ampliado el modelado ER con construcciones para representar cambios de estado, un enfoque apoyado por el autor original; ^[25] un ejemplo es Anchor Modeling .
• Otros modelan los cambios de estado por separado, utilizando diagramas de transición de estados o alguna otra técnica de modelado de procesos .
• Se dibujan muchos otros tipos de diagramas para modelar otros aspectos de los sistemas, incluidos los 14 tipos de diagramas que ofrece UML . ^[26]
• Hoy en día, incluso cuando el modelado ER podría ser útil, es poco común porque muchos utilizan herramientas que admiten tipos similares de modelos, en particular diagramas de clases para programación orientada a objetos y modelos de datos para sistemas de gestión de bases de datos relacionales . Algunas de estas herramientas pueden generar código a partir de diagramas y realizar ingeniería inversa de diagramas a partir del código.
• En una encuesta, Brodie y Liu ^[27] no pudieron encontrar ni un solo ejemplo de modelado de relación entre entidades dentro de una muestra de diez empresas de Fortune 100. Badia y Lemire ^[28] atribuyen esta falta de uso a la falta de orientación, pero también a la falta de beneficios, como la falta de apoyo para la integración de datos.
• El modelo entidad-relación mejorado (modelado EER) introduce varios conceptos que no están presentes en el modelado ER, pero que están estrechamente relacionados con el diseño orientado a objetos , como las relaciones es-un .
• Para modelar bases de datos temporales , se han considerado numerosas extensiones ER. ^[29] De manera similar, se encontró que el modelo ER no era adecuado para bases de datos multidimensionales (utilizadas en aplicaciones OLAP ); todavía no ha surgido un modelo conceptual dominante en este campo, aunque generalmente giran en torno al concepto de cubo OLAP (también conocido como cubo de datos dentro del campo). ^[30]

• Entidad asociativa  : término de la teoría relacional y de entidad-relación
• Mapa conceptual  : diagrama que muestra las relaciones entre conceptos
• Diseño de bases de datos  : diseño de cómo se almacenan los datos en una base de datos
• Diagrama de estructura de datos  : representación visual de un determinado tipo de modelo de datos que contiene entidades, sus relaciones y las restricciones que se les imponen.Páginas que muestran descripciones de wikidata como alternativa
• Modelo entidad-relación mejorado  – Modelo de datos
• Marco de arquitectura empresarial  – Marco en el que se define la arquitectura de una empresa
• Modelo de datos de entidad  : marco de mapeo relacional de objetos de código abiertoPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• Diagramas de estructura de rango de valores
• Comparación de herramientas de modelado de datos  – Comparación de herramientas de modelado de datos destacadas
• Ontología  – Especificación de una conceptualización
• Modelado de objetos y roles  : técnica de programaciónPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• Enfoque de tres esquemas  : enfoque para la construcción de sistemas de informaciónPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• Modelo de relación entre entidades estructuradas
• Bases de datos independientes del esquema  : tipo de banco de datosPáginas que muestran descripciones de wikidata como alternativa

• Chen, Peter (2002). "Modelado de relaciones entre entidades: eventos históricos, tendencias futuras y lecciones aprendidas" (PDF) . Pioneros del software . Springer-Verlag. pp. 296–310. ISBN 978-3-540-43081-0.
• Barker, Richard (1990). Método CASE: modelado de relaciones entre entidades. Addison-Wesley. ISBN 978-0201416961.
• Barker, Richard (1990). Método CASE: Tareas y resultados. Addison-Wesley. ISBN 978-0201416978.
• Mannila, Heikki ; Räihä, Kari-Jouko (1992). El diseño de bases de datos relacionales . Addison-Wesley. ISBN 978-0201565232.
• Thalheim, Bernhard (2000). Modelado de relaciones entre entidades: fundamentos de la tecnología de bases de datos . Springer. ISBN 978-3-540-65470-4.
• Bagui, Sikha; Earp, Richard Walsh (2022). Diseño de bases de datos mediante diagramas de entidad-relación . Auerbach Publications . ISBN 978-1-032-01718-1.

Wikimedia Commons tiene medios relacionados con Modelos entidad-relación .

• "El modelo entidad-relación: hacia una visión unificada de los datos"
• Modelado de relación entre entidades
• Estructuras de datos lógicas (LDS): Introducción por Tony Drewry.
• Notación de pata de gallo
• Tipos de modelos de datos y cómo nombrarlos, presentación de David Hay