9Equipo-5Práctica - Jorge González

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
FACULTAD DE INGENIERÍA
Lab. de Bases de Datos
Grupo: 07 - Semestre: 2022-1
Práctica 5:
Diseño conceptual extendido
FECHA DE ENTREGA: 06/10/2021
Profesora:
López Pelcastre Martha M.I.
Alumno:
N.L: 26 Téllez González Jorge Luis
N.L: 23 Solano González Felipe de Jesús
Facultad de Ingenierı́a Lab. de Bases de Datos
Índice
1. Objetivo 2
2. Introducción 2
2.1. Especialización y Generalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Agregación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Desarrollo 5
3.1. Ejercicio 1 - Instrumentos musicales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Diagramas e Identificaciones realizadas en clase . . . . . . . . . . . . . . . . . . 6
3.1.2. Identificación de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Identificación de atributos y llave primaria . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4. Identificación de relaciones entre entidades . . . . . . . . . . . . . . . . . . . . . 7
3.1.5. Consideraciones semánticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.6. Diagrama Entidad Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Ejercicio 2 - Compañı́a aérea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Diagramas e Identificaciones realizadas en clase . . . . . . . . . . . . . . . . . . 10
3.2.2. Identificación de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Identificación de atributos y llave primaria . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Identificación de relaciones entre entidades . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Consideraciones semánticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.6. Diagrama Entidad Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.7. Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Conclusiones 15
LATEX
1
Facultad de Ingenierı́a Lab. de Bases de Datos
1. Objetivo
El alumno reafirmará los conocimientos adquiridos para realizar la elaboración de diagramas Entidad-
Relación empleando notación CHEN y herramientas CASE para construir modelos de datos de mayor
complejidad (modelo extendido).
2. Introducción
Un modelo entidad relación extendido (EERD) es un diagrama entidad relación especializado, es decir:
toma en cuenta más factores que un diagrama básico no toma en cuenta. Los EERD utilizan conceptos muy
relacionados con el diseño y la programación orientada a objetos.
Los EERD también son conocidos como modelos entidad-relación mejorados. Son modelos de alto
nivel, que se utilizan para representar de mejor manera los requerimientos y complejidades de un diseño de
base de datos complejo.
Entre los conceptos nuevos que abarca un EERD son:
Supertipo: Una entidad que se relaciona con otras entidades a partir de los atributos únicos.
Subtipo: Un grupo de entidades con atributos únicos relacionados a un supertipo.
Generalización: Es un proceso para definir a una entidad general a partir de un grupo de entidades.
Especialización: A diferencia de la generalización, se define una entidad supertipo para asociarla con
un grupo de entidades.
Figura 1: Ejemplo de un modelo entidad relación avanzado.
Las grandes ventajas del modelo entidad relación extendido es que bien diseñado, te permite desa-
rrollar sistemas duraderos, funcionales y bastante útiles. Permite sumar caracterı́sticas a tu diseño como:
LATEX
2
Facultad de Ingenierı́a Lab. de Bases de Datos
estabilidad, flexibilidad, eficiencia, accesibilidad y adaptabilidad. En otras palabras, permite que el diseño
se adapte ante un cambio de reglas de negocio y que este no sufra en gran manera respecto de su eficiencia
y flexibilidad.
Los conjuntos de entidades pueden incluir subgrupos de entidades que se diferencian de alguna
formade las demás entidades del conjunto. Por ejemplo, un subconjunto de entidades de un conjunto de enti-
dades puede tener atributos que no sean compartidos por todas las entidades del conjunto de entidades.El
modelo E-R ofrece un medio de representar estos grupos de entidades diferentes.
2.1. Especialización y Generalización
Como ejemplo de una especialización, considérese el conjunto de entidades persona con los atributos idPer-
sona, nombre, calle y ciudad. Cada persona puede clasificarse además en una de las categorı́as siguientes:
Cliente
Empleado
Cada uno de estos tipos de persona se describen mediante un conjunto de atributos que incluye to-
doslos atributos del conjunto de entidades persona, más otros posibles atributos adicionales. Por ejemplo,las
entidades cliente se pueden describir además mediante el atributo calificaciónCrediticia, mientras que las
entidades empleado se pueden describir además mediante el atributo sueldo.
La especialización de persona permite distinguir entre las personas basándose en si son empleados
o clientes. De hecho, cada persona puede ser empleado, cliente, las dos cosas o ninguna de ellas según lo
indique el caso de estudio. Nótese que este análisis de realiza de forma descendente.
El refinamiento a partir del conjunto de entidades inicial en sucesivos niveles de subgrupos de en-
tidades representa un proceso de diseño descendente en el que las distinciones se hacen explı́citas. El
proceso de diseño también puede proceder de forma ascendente, en la que varios conjuntos de entidades se
sintetizan en un conjunto de entidades de nivel superior basado en caracterı́sticas comunes.
Por ejemplo, hay analogı́as entre el conjunto de entidades cliente y el conjunto de entidades emplea-
do en el sentido de que tienen varios atributos que, conceptualmente, son iguales en los dos conjuntos de
entidades: los atributos para el identificador, el nombre, la calle y la ciudad. Esta similitud se puede expresar
mediante la generalización, que es una relación de contención que existe entre el conjunto de entidades de
nivel superior y uno o varios conjuntos de entidades de nivel inferior. En este caso, persona es el conjunto
de nivel superior y cliente y empleado son conjuntos de nivel inferior.
A todos los efectos prácticos, la generalización es una inversión simple de la especialización; las
diferencias entre los dos enfoques se pueden caracterizar mediante su punto de partida y su objetivo global.
De lo anterior, se puede sintetizar la diferencia fundamental entre ambos enfoques:
LATEX
3
Facultad de Ingenierı́a Lab. de Bases de Datos
La especialización parte de un único conjunto de entidades;destaca las diferencias entre las entidades
del conjunto mediante la creación de diferentes conjuntos de entidades de nivel inferior.
La generalización parte del reconocimiento de que varios conjuntos de entidades comparten algunas
caracterı́sticas comunes. Con base en esas similitudes, la generalización sintetiza esos conjuntos de
entidades en un solo conjunto de nivel superior.
Figura 2: Supertipo persona y subtipos empleado y cliente.
2.2. Agregación
La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de nivel superior,
que nace a partir de la limitación que tiene el modelo ER para expresar relaciones entre las relaciones.
Por ejemplo, supongamos que se tiene una relación ternaria trabaja en entre las entidades empleado,
sucursal y trabajo. Ahora, se quiere registrar al director responsable de las tareas realizadas por cada em-
pleado de cada sucursal; es decir, se desea registrar al director responsable de las combinaciones empleado,
sucursal y trabajo. Supóngase además que existe un conjunto de entidades director.
Si se quisiera modelar esto con un diagrama ER tradicional, se podrı́a crear una relación cuaternaria
llamada dirige entre empleado, sucursal, trabajo y director. El resultado es un diagramaredundante que
dificulta notablemente su análisis y modelado posterior.
Figura 3: Relaciones redundantes.
LATEX
4
Facultad de Ingenierı́a Lab. de Bases de Datos
En cambio, si se utiliza el concepto de agregación, es posible modelar la situación anterior como
lo siguiente: un conjunto de relaciones trabaja en (la cuál relaciona internamente a empleado, sucursal y
trabajo) como entidades de nivel superior. Ese conjunto de entidades, entonces, se trata de la misma forma
que cualquier otro conjunto de entidades, brindando la posibilidad de crear una relación binaria entre trabaja
en y director haciendo uso de dirige para representar al responsable de cada tarea.
Figura 4: Agregación modelada.
3. Desarrollo
La actividad de la práctica es la siguiente: Para los siguientes ejercicios, realizar el modelo Entidad –
Relación de ambos textos en la herramienta CASE seleccionada.
3.1. Ejercicio 1 - Instrumentos musicales
El caso de estudio a analizar es el siguiente:
Se desea modelar una base de datos para un almacén de instrumentos musicales que recibe, pero también
entrega instrumentos a diversas tiendas musicales, de acuerdo a lo siguiente:
Las tiendas tienen un identificador, un nombre (único) y una dirección (Calle, número, colonia,
alcaldı́a y CP).
Los instrumentos tienen un identificador, descripción, precio sugerido para venta (opcional), costo
y stock (cantidad en existencia). Los instrumentos pueden ser de varios tipos; cuerdas, de estos se desea
conocer el número de cuerdas y tipo (Acústica, Eléctrico, Electro-acústico). Viento, se desea conocer el
material con el que están hechos (madera, metal), el soplo (mecánico o humano). Percusión se desea
conocer su sonido (determinado, indeterminado), tomar en cuenta que no todos los instrumentos son de
cuerdas, viento o de percusión.
Las tiendas solicitan pedidos, cada pedido tiene un identificador, una fecha de pedido, fecha de
vencimiento (no mayor a 10 dı́as), estatus (Pendiente, Cancelado, Surtido, Surtido Parcial), Importe (cal-
culado) y observaciones (que pueden no capturarse).
LATEX
5
Facultad de Ingenierı́a Lab. de Bases de Datos
Existen proveedores que atienden los pedidos de quienes se desea conocer su identificador, Razón
Social, Paı́s, RFC, teléfonos de contacto y emails, un pedido es atendido por un solo proveedor y un pro-
veedor puede atender múltiples pedidos.
En un pedido pueden solicitarse varios instrumentos y un instrumento puede estar asociado a mu-
chos pedidos, se debe indicar la cantidad de productos solicitados, el costo del instrumento, la cantidad
surtida y el precio de venta sugerido por el proveedor (opcional).
La recepción del almacén recibe los pedidos para ser enviados a las tiendas, cada recepción está
asociada a un solo pedido, un pedido tiene una recepción. La recepción tiene un número que la identifica,
fecha de recepción de los productos, nombre de la persona que recibe en almacén, Importe (calculado) y
Estatus (completo, incompleto, devuelto).
3.1.1. Diagramas e Identificaciones realizadas en clase
Durante la sesión del laboratorio, en un inició se habı́a considerado que se trataba de una generalización,
sin embargo, fue posible percatarse de que la afirmación anterior era erronea debido a que, en realidad, se
estaba partiendo de un caso general (el instrumento musical) hacia uno particular, además, se menciona
que un instrumento si bien puede pertenecer a los subtipos cuerda, viento o percusión, no necesariamente
será parte de ellos; lo que implica que existen ejemplares en el supertipo que no corresponden a uno de los
subtipos mencionados.
Figura 5: Detección inicial de entidades.
3.1.2. Identificación de entidades
Para la realización del modelo entidad relación avanzado, se analizó detenidamente cada párrafo del enun-
ciado del ejercicio.
Instrumento
Cuerda
LATEX
6
Facultad de Ingenierı́a Lab. de Bases de Datos
Viento
Percusión
Recepción
Pedidos
Proveedor
Tienda
3.1.3. Identificación de atributos y llave primaria
Se comprendió las especificaciones para cada atributo de cada entidad, analizando si el atributo es multiva-
lorado, opcional o derivado. La identificación de las llaves primarias resultó ser bastante sencilla porque en
la mayorı́a de las reglas de negocio se solicitaba un identificador, es decir, una llave primaria artificial.
Instrumento: instrumentoID, descripción, precioSugerido (opcional), costo y stock.
Cuerda: númCuerdas y tipo (multivalorado).
Viento: material (multivalorado) y soplo (multivalorado).
Percusión: sonido (multivalorado).
Recepción: recepciónID, fechaRecepción, nombreRecibe, importe (derivado) y estatus (multivalora-
do).
Pedidos: pedidoID, fechaPedido, importe (derivado), observaciones, fechaVencimiento y estatus (de-
rivado).
Proveedor: proveedorID, razónSocial, pais, RFC, teléfono (multivalorado) y email (multivalorado).
Tienda: tiendaID, CP, número, nombre, colonia, alcaldı́a y calle.
3.1.4. Identificación de relaciones entre entidades
Establecer las relaciones también resultó ser una tarea sencilla debido a que son muy bien explicadas en
el enunciado del ejercicio, se analizó cuidadosamente cada relación para establecer de manera correcta las
cardinalidades:
Un instrumento es solicitado en 1 o más pedidos. (1:M)
LATEX
7
Facultad de Ingenierı́a Lab. de Bases de Datos
Un pedido solicita uno o más intrumentos. (1:M)
Cardinalidad: (M:N)
Un proveedor atiende uno o más pedidos. (1:M)
Un pedido es atendido por un proveedor. (1:1)
Cardinalidad: (1:M)
Una tienda solicita uno o más pedidos. (1:M)
Un pedido es solicitado por una tienda. (1:1)
Cardinalidad: (1:M)
Una recepción recibe un pedido. (1:1)
Un pedido es recibido por una recepción. (1:1)
Cardinalidad: (1:1)
3.1.5. Consideraciones semánticas
1. La fecha de vencimiento no mayor a 10 dı́as.
2. El precio sugerido de venta de los instrumentos es opcional.
3. El importe de cada pedido es calculado.
4. Las observaciones de cada pedido son opcionales y pueden no capturarse.
3.1.6. Diagrama Entidad Relación
Establecer la jerarquı́a no resulto ser complicado porque es bastante intuitivo la forma en que debe formarse
y con que restricciones. A continuación se muestra el diagrama E/R realizado:
LATEX
8
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 6: Diagrama E/R del primer ejercicio.
3.2. Ejercicio 2 - Compañı́a aérea
El caso de estudio a analizar es el siguiente:
Se desea almacenar la información de una compañı́a aérea en una base de datos. La compañı́a aérea tiene
tres recursos principales: aviones, pilotos y miembros de tripulación. De cada piloto se lleva el registro
de su código, nombre completo, correo, teléfono, domicilio de residencia y el de su familia, ası́ como las
horas de vuelo. De los miembros de tripulación solo agregan su profesión y no registran la escuela donde
estudiaron como los pilotos.
Todos ellos (pilotos y miembros) tienen una base a la que regresan después de los vuelos de una
jornada la cual se identifica por el nombre, ciudad, estado y teléfonos.
Un vuelo que va desde un origen a un destino y a una hora determinada, tiene un número de vuelo
(por ejemplo, el vuelo de CDMX a Cancún de las 13:50 es el vuelo IB-8830). De cada vuelo que se va a
realizar durante los próximos tres meses, ası́ como de los vuelos que ya se han realizado, se desea saber el
avión en que se va a hacer o en el que se ha hecho, el piloto y cada uno de los miembros de la tripulación.
Cada avión tiene un código que incluye su tipo (por ejemplo, BOEING-747) y tiene una base donde
es sometido a las revisiones periódicas de mantenimiento, de las que se registra su fecha y motivo.
LATEX
9
Martha López Pelcastre
faltan cardinalidades máximas en las relaciones
Facultad de Ingenierı́a Lab. de Bases de Datos
3.2.1. Diagramas e Identificaciones realizadas en clase
Jorge: El primer paso para la identificación consistió en revisar el caso de estudio y observar parecidosentre
entidades que puedan hacer referencia a un papel en común. En este caso particular, fue posible observar
que tanto los pilotos como los miembros de la tripulación de un avión pueden englobarse dentro de una
misma entidad Empleado, ya que tanto pilotos como miembros hacen referencia a una entidad de más alto
nivel, es decir, una generalización.
Figura 7: Identificación inicial de entidades y si es generalización o especialización.
Posteriormente, los esfuerzos estuvieron enfocados en analizar a detalle la presencia de agregacio-
nes dentro del caso de estudio y en qué apartados podrı́a considerarse su aparición. Dentro del trabajo
desarrollado en este aspecto, en primer lugar se consideró la presencia de una agregación entre la entidad
Avión y Empleado con una relación hacia la entidad Base; considerando en un principio que la relación
entre Avión y Empleado implicaba una acción que posteriormente proseguı́a con otra (el regreso a la base).
Sin embargo, durante la clase se discutió la inviabilidad de tal modelado debido a que la acción se encuentra
mayormente ligada a un avión que a los empleados y que, además, no consideraba el mantenimiento como
otra acción posible.
De lo anterior, se terminó optando por modelar una agregación entre las entidades Avión y Base,
considerando como primer acción el que un avión regrese a su base correspondiente, y como segunda acción
la realización de su mantenimiento. De lo anterior, la agregación identificada quedó enmarcada dentro de
lo siguiente: Un avión regresa a su base, y posteriormente, se le realiza un mantenimiento.
LATEX
10
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 8: Diagrama E/R de la guarderı́a.
Felipe: En el diagrama realizado en laboratorio, se tomaron en cuenta las diferentes relaciones entre entida-
des, se toma en cuenta la generalización entre las entidades piloto y tripulación excluyente y total, es decir
para cada instancia del supertipo se asocia por lo menos con una instancia de sus subtipos y a su vez solo se
puede asociar a una de ellas. Establecer las relaciones no fue complicado debido a que las reglas de negocio
son explicitas.
LATEX
11
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 9: Diagrama E/R de la guarderı́a.
3.2.2. Identificación de entidades
Se identificaron las siguientes entidades en el caso de estudio, con una entidad supertipo en un caso de ge-
neralización excluyente, ya que un piloto no puede tomar el papel de miembro de la tripulación y viceversa:
Avión
Piloto
Miembro
Empleado
Base
Mantenimiento
LATEX
12
Martha López Pelcastre
faltan cardinalidades máximas en las relaciones
Facultad de Ingenierı́a Lab. de Bases de Datos
3.2.3. Identificación de atributos y llave primaria
Se identificaron los siguientes atributos. Para las llaves primarias, se emplean los códigos de identificación
como lo solicita el caso de estudio:
Avión: códigoAvión y tipoAvión.
Piloto: escuela.
Miembro: profesión.
Empleado: códigoRegistro, nombreCompleto [Compuesto: apPat, apMat y nombre], correo, teléfono,
domicilio [Multivalorado y Compuesto: tipoDomicilio, calle, número, colonia, cp] y horasVuelo.
Base: baseID, nombre, ciudad, estado y teléfono (multivalorado).
Mantenimiento: mantenimientoID, fecha y motivo.
3.2.4. Identificación de relaciones entre entidades
Con los atributos definidos, se establecen las relaciones entre entidades:
Un empleado vuela en un avión. (1:1)
En un avión vuelan uno o más empleados. (1:M)
Cardinalidad: (1:M)
Un empleado vuelve a una base. (1:1)
A una base regresan uno o más empleados. (1:M)
Cardinalidad: (1:M)
Un avión regresa a una base. (1:1)
A una base regresa uno o más aviones. (1:M)
Cardinalidad: (1:M)
3.2.5. Consideraciones semánticas
1. Los empleados pueden tener dos domicilios, uno de residencia y otro de familia.
2. Una base tiene varios teléfonos.
LATEX
13
Facultad de Ingenierı́a Lab. de Bases de Datos
3.2.6. Diagrama Entidad Relación
El diagrama E/R generado para el caso de estudio es el siguiente:
Figura 10: Diagrama E/R del ejercicio.
3.2.7. Análisis de resultados
Uno de los puntos importantes a destacar de por qué se optó por modelar avión y base como una agregación,
lo cuál es debido a que se visualizaron las acciones Avión regresa a la base y, como consecuente de esta
acción, Al avión se le realiza mantenimiento. De esta forma, se cumple el principio de agregación y el
modelado resulta correcto.
Por otra parte, si bien la relación vuela es candidata a volverse una entidad por existencia propia
(debido a la cantidad de atributos que posee), finalmente se decidió dejarla como relación ya que permite
identificar de esa forma la relación existente entre un avión y un empleado de forma efectiva.
LATEX
14
Facultad de Ingenierı́a Lab. de Bases de Datos
4. Conclusiones
Solano González Felipe de Jesús: En la realización de la práctica, se repasó las herramientas y técni-
cas para un buen diseño de un modelo entidad relación básico. En esta práctica se añaden los con-
ceptos nuevos para poder desarrollar un modelo más avanzado como: supertipo, subtipo, jerarquı́as,
restricciones y agregación. Para cada ejercicio realizado en la práctica se repasó los temas vistos en
prácticas anteriores y se añaden los conceptos para obtener un modelo entidad relación avanzado.
La práctica resultó bastante clara y se comprendió la manera correcta de agregar una jerarquı́a con
sus restricciones o una agregación, además, cuando o en qué circunstancias se debe agregar.
En conclusión, los objetivos de la práctica se cumplen porque se reafirmaron los conocimientos adqui-
ridos para el desarrollo de un diagrama entidad relación utilizando notación CHEN y una herramienta
CASE con el fin de desarrollar un modelo entidad relación avanzado.
Téllez González Jorge Luis: El ejercicio realizado durante la clase permitió abordar por primera vez
las caracterı́sticas del modelo E/R extendido, lo cual también fue un poco complicado debido a que
este tema todavı́a no ha sido mencionado durante mis clases teóricas de la asignatura.
Una de las partes que más complicaciones me generó fue la identificación de las agregaciones, ya
que la identificación de acciones consecuentes puede ser un poco confusa y difı́cil de visualizar;
espero mejorar en ese aspecto durante ejercicios posteriores. Por otra parte, fue notable observar que,
aunque estos conceptos partan de una misma base, al realizar el modelado de un caso de estudio los
modelos siguen teniendo distintas divergencias; cada uno con sus propias ventajas como desventajas
inherentes.
Por otra parte, la parte de las jerarquı́as fue mucho más sencilla de entender (aunque en un inicio me
fue difı́cil diferenciar generalización y especialización) una vez que se revisó tomando como ejemplo
los casos de estudio propuestos comentándolos durante la sesión de laboratorio.
Considerando que se han obtenido modelos ER que permitan comprender de mejor forma estos nue-
vos conceptos y que una vez más se reafirma el uso de herramientas como Dı́a y la notación Chen, el
objetivo de esta práctica puede considerarse cumplido. Espero que en próximas prácticas se tenga la
oportunidad de revisar nuevamente el concepto de agregación en especı́fico con el fin de tener mejor
visualización de los casos donde sea factible modelarla.
Referencias
[1] Modelo Entidad-Relación ampliado. — GBD02.- Diseño lógico de Bases de Datos. Recuperado de:
https://ikastaroak.birt.eus/edu/argitalpen/backupa/20200331/1920k/es/ASIR/GBD/
GBD02/es_ASIR_GBD02_Contenidos/website_23_modelo_entidadrelacin_ampliado.html.
Fecha de consulta: 04/10/2021.
LATEX
15
https://ikastaroak.birt.eus/edu/argitalpen/backupa/20200331/1920k/es/ASIR/GBD/GBD02/es_ASIR_GBD02_Contenidos/website_23_modelo_entidadrelacin_ampliado.html
https://ikastaroak.birt.eus/edu/argitalpen/backupa/20200331/1920k/es/ASIR/GBD/GBD02/es_ASIR_GBD02_Contenidos/website_23_modelo_entidadrelacin_ampliado.htmlFacultad de Ingenierı́a Lab. de Bases de Datos
[2] ¿Qué es una base de datos relacional? Recuperado de: https://www.lucidchart.com/pages/es/
diagrama-entidad-relacion-extendido. Fecha de consulta: 04/10/2021.
[3] Silberschatz, A., Korth, H. F., and Sudarshan, S. (2002). Fundamentos de Bases de Datos. McGrawHill,
4th edition.
Los créditos de las fotografı́as pertenecen a sus respectivos autores. ©
LATEX
16
https://www.lucidchart.com/pages/es/diagrama-entidad-relacion-extendido
https://www.lucidchart.com/pages/es/diagrama-entidad-relacion-extendido