Diseño Conceptual: Modelo Entidad Relación¶

Propuesta didáctica¶

En esta unidad vamos a comenzar a trabajar el RA6: Diseña modelos relacionales normalizados interpretando diagramas entidad/relación.

Criterios de evaluación¶

CE6b: Se han identificado las tablas del diseño lógico.
CE6c: Se han identificado los campos que forman parte de las tablas del diseño lógico.
CE6d: Se han analizado las relaciones entre las tablas del diseño lógico.
CE6e: Se han identificado los campos clave.

Contenidos¶

Bases de datos relacionales:

Modelo de datos

Interpretación de Diagramas Entidad/Relación:

El modelo E/R. Entidades y relaciones. Cardinalidades. Debilidad.
El modelo E/R ampliado. Generalización y especialización. Agregación.

Cuestionario inicial

¿Conoces algún modelo conceptual?
¿Cuál es el propósito del modelo ER?
¿Qué tres elementos son los más importantes en un modelo ER?
¿Qué valores puede tomar la cardinalidad mínima? ¿Y la máxima?
¿Qué diferencia una entidad fuerte de una débil?
A partir de la cardinalidad máxima, ¿que tres tipos de relaciones binarias se pueden dar?
¿Qué tipos de atributos conoces?
¿Qué es una relación reflexiva?
¿Qué relación existe entre la generalización y la especialización?
¿Qué relación existe entre una superclase y una subclase?
¿Qué diferencia una restricción de identificación de una cardinalidad mínima a 1?
¿Cuándo se utiliza una agregación o entidad asociativa?

Programación de Aula (12h)¶

Esta unidad es la segunda, con lo que se imparte en la primera evaluación, con una duración estimada de 12 sesiones lectivas, durante la última semana de septiembre y la primera quincena de octubre:

Sesión	Contenidos	Actividades	Criterios trabajados
1	Modelo Entidad Relación.	AC201	CE6b, CE6c
2	Entidades. Relaciones - Cardinalidad	AC202	CE6d
3	Relaciones 1:1, 1:N, N:M
4	Atributos	AC203	CE6d
5	Modelados sencillos	AC204, AC205	CE6b, CE6c, CE6e
6	Completando modelos	AC208	CE6b, CE6c, CE6e
7	Restricciones
8	Modelado EER. Generalización. Tipos	AC209	CE6b, CE6c, CE6e
9	Modelados con generalizaciones	AC210	CE6b, CE6c, CE6e
10	Agregaciones	AC211	CE6b, CE6c, CE6e
11	Interpretando modelos	AC214	CE6b, CE6c, CE6d, CE6e
12	Reto - Diseñando una BD	PY215	CE6b, CE6c, CE6d, CE6e

Diseño de BD¶

En la unidad anterior hemos trabajado conceptos generales asociados a las bases de datos y los sistemas gestores de bases de datos. Estudiamos que existen diferentes modelos de datos que dan lugar a diferentes tipos de soluciones.

Sistema de información

En la unidad anterior estudiamos que un sistema de información define cómo funciona una empresa y el uso que hace de los datos. Veamos un ejemplo concreto sobre una empresa.

Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nombre, apellidos, dni, dirección y fecha de nacimiento). Cada producto tiene un nombre y un código, así como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes.

Los productos los suministran diferentes proveedores. Se debe tener en cuenta que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el NIF, nombre y dirección.

Pero antes de entrar en uno de los modelos, conviene saber cual es el proceso de diseño de una base de datos. Queda claro que un buen diseño sobre los datos va a facilitar el posterior desarrollo de las aplicaciones que explotan la base de datos.

Antes de comenzar el diseño, el primer paso y más crítico es determinar los requisitos de la base de datos mediante un sistema de información, describiendo el problema que la base de datos debe cubrir. Este paso está más asociado a la ingeniería del software y lo estudiarás en detalle en el módulo de Entornos de Desarrollo.

Las fases que se realizan a la hora de diseñar una base de datos son tres:

Diseño conceptual: a partir de los requisitos y entendido el problema (conocido como el mundo real), mediante un modelo conceptual de alto nivel (EER) crearemos el esquema conceptual.
Diseño lógico: transformación de un modelo conceptual a un modelo de datos concreto para poder representar el problema (relacional, jerárquico, ...). En este paso, ya nos tenemos que haber decidido por un modelo de datos, y en algunos casos, incluso por un SGBD concreto. El resultado del diseño lógico es el esquema lógico/canónico.
Diseño físico: sobre el modelo lógico de datos del punto anterior sobre un SGBD concreto, se define la representación física de las estructuras, obteniendo el esquema físico/interno.

Estas tres fases se resumen en el siguiente gráfico:

En las siguientes unidades vamos a ir pasando de una fase del diseño a la siguiente. En nuestro caso, en el modelo conceptual aprenderemos el modelo Entidad Relación, como modelo lógico veremos el Modelo Relacional, y como modelo físico, usaremos el sublenguaje DDL de SQL, ya centrándonos en un SGBD concreto.

Así pues, en esta unidad comenzamos con el diseño conceptual a través del modelo conceptual más extendido, el modelo entidad-relación.

Reto I - Diseñamos¶

A lo largo de las tres siguientes unidades vamos a desarrollar una base de datos desde cero. Para ello, en equipos de 3-4 personas, y siguiendo un enfoque metodológico de Aprendizaje Colaborativo basado en Retos, cada equipo va a definir:

Un sistema de información.
El modelo entidad relación (diseño conceptual)
El modelo relacional (diseño lógico)

Si no se os ocurre ningún sistema de información, algunas propuestas que podéis diseñar son la base de datos de un gimnasio, una academia de idiomas, una biblioteca, un liga amateur de fútbol/baloncesto o la base de datos de un festival de música.

Durante el desarrollo del reto estableceremos diferentes hitos que deberéis cumplir, a modo de entregables. En cada unidad dedicaremos una o más sesiones a trabajar el reto y compartir el resultado con la clase.

En la prueba escrita que realizaremos a finales de la unidad 4 aparecerán actividades sobre alguna de las soluciones creadas.

El modelo Entidad Relación¶

Entendemos como modelo conceptual el conjunto de conceptos y reglas que nos permiten aplicar una serie de abstracciones con el propósito de definir y manipular datos de la realidad, almacenándola en una base de datos.

Centrándonos en el modelo entidad/relación, cuyo nombre completo es modelo entidad/interrelación (entity/relationship en inglés), es un modelo de datos conceptual de alto nivel, propuesto por Peter Chen en 1976, y vigente a día de hoy por su simplicidad y legibilidad, ya que el resultado del análisis del problema se representa de forma visual mediante diagramas entidad/relación. Ha tenido numerosas extensiones y aportaciones de muchos otros autores, teniendo soporte por numerosas herramientas de software de diseño (CASE), lo que ha dado lugar a que no exista un único modelo ER, sino una familia de modelos.

El modelo ER describe el mundo real como un conjunto de entidades y de relaciones entre ellas.

Elementos¶

Una entidad es cualquier persona, concepto, suceso o evento (en definitiva, cualquier cosa) con existencia independiente sobre la cual se desea almacenar información. La entidad representa un tipo de objeto, el concepto que permite representar a un conjunto de objetos similares. Por ejemplo Persona, Cliente, Alumno, Asignatura, etc... serían entidades.

Por otro lado, una entidad define de forma genérica a un conjunto de objetos a través de propiedades (o atributos): cualquier información que interesa guardar sobre las entidades. Se obtienen mediante un proceso de abstracción que se conoce como clasificación. Ejemplos de atributos serían nombre, dirección, fecha de nacimiento, saldo, teléfono, etc...

Finalmente, una relación es una asociación entre entidades. Un tipo de relación en un modelo de datos permite representar un conjunto de relaciones de características similares. Igual que las entidades, las relaciones también pueden tener atributos, para representar información que no es propia de ninguno de los objetos participantes en la relación. Ejemplos de relaciones serían Matricular, Contratar, Reservar, etc...

El modelo conceptual también define una serie de propiedades sobre los elementos, como son las propiedades:

estáticas: restricciones sobre las entidades y relaciones. Por ejemplo, la restricción de integridad estática, limita las extensiones (ocurrencias) válidas (permitidas) para una propiedad. Existen varios tipos:
- Sobre atributos: valores posibles, valor no nulo.
- Sobre entidades: restricción de identificación.
- Sobre relaciones: restricciones de cardinalidad.
dinámicas: operaciones sobre los objetos o sus relaciones, relaciones entre operaciones (transacciones) y restricciones dinámicas sobre la evolución de los objetos y sus relaciones, como por ejemplo, "El número de alumnado matriculado en una asignatura debe ser menor o igual a 20".

Operación vs Transacción

Una operación es una acción elemental (indivisible) sobre un objeto o una relación. Las operaciones permiten crear, eliminar, modificar y consultar objetos y relaciones.

Una transacción es una secuencia de operaciones que se considera atómica en lo que se refiere a su ejecución. Es decir, se ejecutan todas sus operaciones o ninguna de ellas, como por ejemplo, al realizar una transferencia bancaria.

Las bases de datos soportan las transacciones gracias a las propiedades ACID (que estudiamos en la sesión anterior)

Entidades¶

Una entidad es cualquier objeto (real o abstracto) sobre el que queremos almacenar información en la base de datos.

Se representa mediante un rectángulo con el nombre de la entidad en singular y mayúsculas. Se suele identificar con un sustantivo y suelen estar asociados a objetos (coche, libro, vehículo, etc...), personas (cliente, empleado, proveedor, ...), lugares (ciudad, provincia, etc...), organizaciones (hospital, aula, empresa, ...), etc...

Control de redundancia

Cada entidad solo puede aparecer una única vez en el modelo, con lo que no podemos repetir el nombre de dos entidades en el mismo modelo.

Existe dos tipos de entidades:

Regulares o fuertes: existen por sí mismas, sin necesidad de otra entidad. Por ejemplo, los clientes de nuestra empresa. Se representan mediante un rectángulo simple.
Débiles: su existencia depende de otra entidad. Por ejemplo, los familiares de los clientes sería una entidad débil, ya que no tiene sentido almacenarlos si ya no tenemos a los clientes. Se representan mediante un rectángulo doble.

Una entidad débil se identifica por sus propiedades y por las propiedades de las entidades de las que depende. Además, al eliminar la entidad fuerte, también se elimina la entidad débil.

Finalmente, el término ocurrencia (o instancia de entidad) indica un elemento de la entidad, un objeto en concreto. Por ejemplo, en la entidad PRODUCTO, una ocurrencia sería Bolígrafo azul de gel cuyo código es BOLIAZUL01 y fecha de alta en el sistema el 1/1/24.

Relaciones¶

Una relación representa una asociación, relacionando los datos del modelo. Para ello, dibujaremos un rombo que unirá las entidades que participan en la relación, y la nombraremos mediante un verbo en mayúsculas:

Notación

Existen múltiples notaciones para representar las relaciones (las entidades se suelen representar igual en todas las notaciones). En los apuntes vamos a utilizar tanto la notación empleada por la herramienta ERDPlus (también conocida como de pata de gallo), la notación de Chen (con las cardinalidades mínima y máxima) así como diferentes notaciones empleadas de forma generalizada por las empresas.

Una vez dominada una notación es muy fácil entender y cambiar a cualquiera de las otras. Eso sí, debes ser constante y modelar siempre con la misma notación.

Grado¶

Se denomina grado de una relación a la cantidad de entidades involucradas en una relación, lo que nos permite clasificarlas las relaciones en:

binarias: son las más comunes, e implica la participación de dos entidades.
ternarias: participan tres entidades. A ser posible, es mejor simplificarlas mediante el uso de varias relaciones binarias y agregaciones. Por ejemplo, la relación existente entre un libro, su autor y la editorial donde se publica el libro. En este curso no vamos a trabajar las relaciones ternarias y en su caso, cuando sea posible, haremos uso de agregaciones o entidades asociativas.
n-arias: muy excepcionales, ya que involucran 4 o más entidades.
reflexivas (unarias): son relaciones binarias entre la misma entidad. Por ejemplo, una persona se casa con otra persona.

Cardinalidad¶

La cardinalidad define la cantidad de ocurrencias de una entidad que se relacionan con una relación (que a su vez se relaciona con otra entidad).

Para ello, definimos las cardinalidades:

mínima (también conocido como participación): indica el número mínimo de asociaciones en las que aparecerá cada ejemplar de la entidad. Los valores que puede tomar son cero (opcional) o uno (obligatorio)
máxima: indica el número máximo de relaciones en las que puede aparecer cada ejemplar de la entidad. Los valores pueden ser uno o N (muchos).

La cardinalidad entre una entidad y una relación se representa entre paréntesis indicando el valor mínimo a la izquierda y el mayor a la derecha mediante Card(E,R) = (min, max). Las posibles combinaciones son:

(0, 1) - Una ocurrencia de una entidad se puede relacionar con ninguna o una ocurrencia de otra/s entidad/es.
(1, 1) - Una ocurrencia de una entidad se relaciona siempre con una ocurrencia de otra/s entidad/es.
(0, N) - Una ocurrencia de una entidad se puede relacionar con ninguna o muchas ocurrencias de otra/s entidad/es.
(1, N) - Una ocurrencia de una entidad se puede relacionar con una o muchas ocurrencias de otra/s entidad/es.

Para averiguar la cardinalidad entre dos entidades vía una relación, cogemos una ocurrencia de una entidad y nos preguntamos con cuantas ocurrencias de la otra entidad se va a relacionar.

Pongamos un ejemplo. Si pensamos en la relación que existe un producto y la categoría la que pertenece, tendremos dos cardinalidades para cada lado de la relación.

Si tenemos un producto concreto ¿A cuántas categorías va a pertenecer como mínimo y como máximo?:

Card(PRODUCTO, PERTENECER) = (1, 1) - Un producto siempre pertenece a una categoría

Y en el otro sentido, dada una categoría concreta, ¿cuántos productos van a pertenecer a esta categoría?

Card(CATEGORIA, PERTENECER) = (0, N) - Una categoría puede no tener productos, pero si tiene, pertenecerán muchos.

Representación

Para representar la cardinalidad en el modelo ER, las cardinalidades se anotan en el extremo opuesto de la entidad, utilizándose la regla Entidad, Relación, Cardinalidad, Entidad:

Así pues, si aplicamos la regla de izquierda a derecha tenemos PRODUCTO, PERTENECER, (1,1), CATEGORIA, lo que significa que un producto pertenece siempre a una categoría y como mucho a una también. En cambio, si la aplicamos de derecha a izquierda tenemos CATEGORIA, PERTENECER, (0,N), PRODUCTO indica que a una categoría puede no pertenecer ningún producto pero también muchos.

Tipos¶

Si nos fijamos en las cardinalidades máximas, tenemos tres tipos de relaciones binarias:

1:1 (uno a uno) – Un elemento de la primera relación se corresponde con uno solo de la segunda y viceversa. Por ejemplo, una pantalla digital está en un aula y en un aula sólo hay una pantalla digital.
1:N (uno a muchos) – Un elemento de la primera relación se corresponde con uno o varios de la segunda y uno de la segunda se relaciona con uno solo de la primera. Por ejemplo, un trabajador solo puede trabajar en una empresa y en la empresa puede haber muchos trabajadores.
N:M (muchos a muchos) – Un elemento de la primera relación se corresponden con muchos de la segunda y viceversa. Por ejemplo, un alumno puede estar matriculado en varias asignaturas y en una asignatura puede haber muchos alumnos.

Para representar las relaciones, además de la notación de Chen (indicando las cardinalidades en el lado opuesto), utilizaremos la notación de pata de gallo:

Descripción	Símbolo
Un anillo representa "cero"
Un guión representa "uno"
El pie de gallo representa "muchos" (N)

Para ello, dibujaremos la cardinalidad máxima lo más cerca de cada entidad y la mínima lo más separada. En la siguiente tabla se supone que tenemos la relación a la izquierda y la entidad a la derecha:

Descripción	Cardinalidad	Símbolo
Anillo y guión	(0, 1)
Guión y guión	(1, 1)
Anillo y pata de gallo	(0, N)
Guion y pata de gallo	(1, N)

Relación 1:1¶

En las relaciones uno a uno, las dos cardinalidades máximas toman el valor 1, e indican que una ocurrencia de la entidad A se relaciona con sólo uno de la B, y viceversa.

Si nos fijamos en las ocurrencias de las entidades, vemos como cada departamento tiene asignado siempre un empleado y sólo uno. Por ello, Card(DPTO, DIRIGIR) = (1,1). En cambio, tenemos empleados que no tienen asignado ningún departamento, y en el caso de tenerlo, sólo tienen uno, lo que implica que Card(EMPLEADO, DIRIGIR) = (0,1).

Como las dos cardinalidades máximas son 1, decimos que la relación es uno a uno.

Autoevaluación

¿En qué cambiaría el gráfico de ocurrencias si las cardinalidades fueran Card(DPTO, DIRIGIR) = (0,1) y Card(EMPLEADO, DIRIGIR) = (1,1)?

Relación 1:N¶

En las relaciones uno a muchos, en un sentido hay una cardinalidad máxima de uno, y en la otra de muchos, es decir, una ocurrencia de la entidad A se relaciona con una de la entidad B, pero una ocurrencia de la entidad B lo hace con muchas de la entidad A.

En el siguiente ejemplo, tenemos que cada producto tendrá una categoría y en cambio, que de una categoría, tendremos muchos productos.

Si nos fijamos en las ocurrencias de las entidades, vemos como un producto pertenece a una categoría, y siempre a una. Por ello, Card(PRODUCTO, PERTENECER) = (1,1). En cambio, tenemos categorías a las que pertenecen muchos productos, e incluso categorías sin productos, lo que implica que Card(CATEGORIA, PERTENECER) = (0,N).

Autoevaluación

¿En qué cambiaría el gráfico de ocurrencias si las cardinalidades fueran Card(PRODUCTO, PERTENECER) = (0,1) y Card(CATEGORIA, PERTENECER) = (1,N)?

¿Y si les damos la vuelta siendo Card(PRODUCTO, PERTENECER) = (1,N) y Card(CATEGORIA, PERTENECER) = (0,1)?

Supuesto Empresa

Queremos gestionar la información sobre los empleados de una empresa, a partir de las siguientes condiciones: para cada empleado dispondremos de su DNI, nombre, fecha de nacimiento, salario y departamento en el que trabaja.

De cada departamento sabremos su nombre, el número del despacho en el que se ubica y conoceremos quien es el jefe de dicho departamento.

Solución

Primero localizamos las entidades y sus atributos:

Entidades: EMPLEADO, DEPARTAMENTO
Atributos de EMPLEADO: dni (atributo identificador), nombre, fecha de nacimiento, salario
Atributos de DEPARTAMENTO: nombre, número de despacho

Respecto a la nomenclatura, hemos recortado la palabra DPTO para reducir el tamaño del diagrama. Además, recuerda que las entidades y las relaciones se nombran en mayúsculas y los atributos en minúsculas. También es recomendable nombrar todos los elementos sin espacios en blanco, para facilitar su posterior transformación al modelo relacional.

Destacar que ni el departamento del empleado ni el jefe son atributos de las entidades, sino que se traducen en relaciones:

Relación 1:N nombrada como TRABAJAR entre DEPARTAMENTO Y EMPLEADO, de manera que en un departamento trabajan muchos empleados, pero un empleado sólo trabaja en un departamento.
Relación 1:1 nombrada como SER_JEFE entre DEPARTAMENTO y EMPLEADO. Un empleado es jefe de un departamento, y en un departamento, un empleado es el jefe.

Este modelo demuestra que dos entidades se pueden relacionar mediante más de una relación, incluso con diferentes cardinalidades.

Relación N:M¶

En las relaciones muchos a muchos, en los dos sentidos hay una cardinalidad máxima de muchos, es decir, una ocurrencia de la entidad A se relaciona con muchas de la entidad B, y una ocurrencia de la entidad B lo hace con muchas de la entidad A.

En el siguiente ejemplo, tenemos que cada empleado puede trabajar en muchos proyectos, y que en cada proyecto, pueden trabajar muchos empleados:

Si nos fijamos en las ocurrencias de las entidades, vemos como un empleado trabaja en uno o más proyectos (o en ninguno). Por ello, Card(EMPLEADO, TRABAJAR) = (0,N). En cambio, tenemos proyectos en los que trabajan varios empleados, o incluso proyectos sin empleados, lo que implica que Card(PROYECTO, TRABAJAR) = (0,N).

Nomenclatura

En todos los casos, es recomendable no utilizar espacios en blanco ni tildes, para facilitar la futura transformación al modelo físico.

Las entidades suelen ser sustantivos y se nombran en singular y mayúsculas.
Los atributos también en singular, pero en minúsculas.
Las relaciones son verbos en mayúsculas.

Respecto a la notación, por ejemplo, en la Universidad de Alicante emplean rombos coloreados para expresar las cardinalidades máximas a N:

Relaciones N:M con fechas¶

En algunos casos, las relaciones muchos a muchos pueden tener múltiples ocurrencias entre las mismas entidades en fechas distintas.

Por ejemplo, en el contexto de una biblioteca, si pensamos en la relación PRESTAR entre LIBRO y USUARIO, podemos deducir que un usuario puede llevarse prestados muchos libros y un libro lo pueden prestar muchos usuarios. Pero ¿cómo modelamos que un usuario se lleva el mismo libro en fechas diferentes?

Si ponemos un atributo fecha en la relación, estamos almacenando la fecha del préstamo, pero no indicamos de ninguna manera que podemos tener más de una fecha. Una solución factible es hacer el atributo fecha multivaluado, lo que cubriría el caso.

Otra posibilidad es crear una entidad débil, por ejemplo, PRESTAMO, con restricciones de ID con LIBRO y USUARIO.

Relaciones reflexivas¶

Las relaciones reflexivas (o unarias) son aquellas relaciones de grado uno donde la misma entidad cumple dos roles diferentes en la relación, los cuales se representan escribiéndolo en cada lado de la relación.

Algunos ejemplos comunes son cuando una persona se casa con otra persona, una pieza que se compone de otras piezas o un empleado es responsable de otro empleado.

Vamos a centrarnos en el caso de que un empleado sea el responsable de otro, donde podemos decir que todo empleado trabaja para otro pero que el empleado responsable (el jefe) lo es de varios empleados, lo que daría lugar a una relación 1:N. Así pues, creamos una relación TRABAJAR y la unimos con EMPLEADO por los dos sentidos de la misma, y anotamos el rol en cada una de las cardinalidades.

Atributos¶

Los atributos describen propiedades de las entidades y de las relaciones, y se representan mediante elipses u óvalos conectado a la entidad o la relación mediante una línea. Es importante destacar que en una misma entidad, el nombre de los atributos no se puede repetir, pero sí en entidades diferentes.

Existen diferentes tipos de atributos:

Identificador (clave): atributos únicos que identifican las ocurrencias de la entidad. Se subraya la palabra, como el dni que identifica a un cliente (no tendremos dos clientes con el mismo DNI)
Compuesto: agrupación de varios atributos, ya sean simples o compuestos. Por ejemplo, el campo direccion se compone de la calle, número, etc... Se representa mediante óvalos conectados entre sí, y pondremos el nombre compuesto entre paréntesis.
Multivaluado: el atributo puede tomar varios valores, como el telefono del cliente, que realmente puede almacenar el fijo, el móvil y el número del trabajo. Se representa mediante un doble óvalo. (en otras notaciones, se pone una n al lado del conector del atributo)
Derivado: Su valor se deduce a partir de otros atributos de la misma entidad, otras entidades con las que se relaciona o se calcula a partir de un dato. Por ejemplo, el campo edad se obtiene a partir de la fecha de nacimiento del cliente. Se representa mediante un óvalo con el borde punteado.
Opcional: el atributo puede contener valores nulos, como el email.
No nulo: opuesto al atributo opcional, marca el atributo como obligatorio. En alguna notaciones se indica con un pequeño circulo entre el conector y el óvalo.
En una relación: Su valor depende de la relación, no de ninguna entidad

Autoevaluación

Piensa en dos entidades que tengan una relación con la cardinalidad que consideres, e identifica al menos un atributo de cada tipo.

Identificadores¶

Recuerda esta frase: Toda entidad debe tener uno o más atributos identificadores. Más adelante veremos que en algún caso particular de entidad no es necesario, pero por lo general, al realizar el modelo conceptual siempre debemos comprobar si hemos identificado un atributo identificador para cada entidad.

Respecto a los atributos identificadores podemos tener:

Atributos identificadores sencillos. Un atributo identifica de forma unívoca a una ocurrencia de la entidad. Por ejemplo, el isbn de un libro.
Atributos identificadores compuestos, donde una entidad se identifica por dos o más atributos a la vez. Por ejemplo, una calle que se identifique por el tipo de via y por el nombre de la calle, de manera que no es lo mismo la "Avenida América" que la "Calle América".
Varios atributos candidatos que pueden identificar a la entidad. Por ejemplo, una persona que podemos identificar mediante su DNI, número de pasaporte, número de la seguridad social, etc.. Todos los atributos pueden identificar a la entidad PERSONA. Lo que haremos es elegir uno de ellos como identificador (el más común o importante dependiendo del contexto del problema), y el resto de atributos se consideran claves alternativas, y se marcan como que aceptan valores únicos subrayando el nombre de los atributos con una línea troceada.
¿Y si tenemos una entidad que no tiene aparentemente ningún atributo identificador? En ese caso, crearemos un nuevo atributo que lo haga, como codigo o id, y más adelante, el SGBD le dará un valor secuencial.
Atributos identificadores que se complementan con otra entidad (este tipo lo estudiaremos en esta unidad dentro de las Restricciones)

Supuesto Carreteras

Se desea diseñar una base de datos que contenga la información relativa a todas las carreteras de España. Se pide realizar el diseño del modelo ER sabiendo que:

Las carreteras se encuentran divididas en tramos.
Un tramo, del que nos interesa su longitud, siempre pertenece a una única carretera y no puede cambiar de carretera.
Un tramo puede pasar por varios términos municipales, siendo un dato de interés el km del tramo por el que entra en dicho término municipal y el km por el que sale.
Existen una serie de áreas en las que se agrupan los tramos, cada uno de los cuales no puede pertenecer a más de un área.

Solución

Primero localizamos las entidades y sus atributos:

Entidades: CARRETERA, TRAMO, MUNICIPIO, AREA
Atributos: cada entidad tendrá un atributo identificador, y cómo en el enunciado no se indica, en unos casos creamos un atributo codigo y en otros con el nombre es suficiente (como es el caso de MUNICIPIO). Como atributo propio, cada TRAMO tiene un atributo longitud.

Las relaciones son:

Relación 1:N nombrada como PERTENECER entre CARRETERA Y TRAMO, ya que "las carreteras se encuentran divididas en tramos" y "un tramo, del que nos interesa su longitud, siempre pertenece a una única carretera y no puede cambiar de carretera".
Relación N:M nombrada como PASAR entre TRAMO y MUNICIPIO, ya que "un tramo puede pasar por varios términos municipales", y aunque no lo indica de forma explícita, deducimos que por un municipio pueden pasar varios tramos. Además, añadimos dos atributos en la relación para almacenar "el km del tramo por el que entra en dicho término municipal y el km por el que sale". Si hubiéramos colocado los atributos en TRAMO o en MUNICIPIO no tendrían el mismo significado, ya que nos interesa el dato de la relación entre las dos entidades y no de una de ellas por separado.
Relación 1:N nombrada como AGRUPAR entre TRAMO Y AREA, ya que "existen una serie de áreas en las que se agrupan los tramos, cada uno de los cuales no puede pertenecer a más de un área.".

Restricciones¶

En el apartado de Entidades vimos que tenemos entidades fuertes y débiles, y en las débiles su existencia depende de otra entidad, de manera que se identifica por sus propiedades y por las propiedades de las entidades de las que depende.

Las entidades débiles, que representamos mediante un doble rectángulo, presentan dos tipos de dependencia:

Dependencia en existencia: la entidad débil no puede existir sin la entidad débil, lo que implica que, si desaparece una instancia de entidad fuerte desaparecerán las instancias de entidad débiles que dependan de la primera. La representación de este tipo de dependencia incluirá una E en el conector o en el interior de la relación débil. En todos casos las restricciones de existencia implican que la cardinalidad mínima es 1.
Dependencia en identificación: debe darse una dependencia en existencia y además, una ocurrencia de la entidad débil no puede identificarse por sí misma, debiendo hacerse mediante los atributos identificadores de la entidad fuerte asociada. La representación de este tipo de dependencia incluirá una ID en el conector o en el interior de la relación débil. También se puede representar con un rombo doble. Además de que la cardinalidad mínima será 1, es muy común que en estos casos, la relación tenga una cardinalidad de 1:N.

En el ejemplo del gráfico tenemos una relación que tiene una restricción de identificación entre una línea de pedido (entidad débil) respecto a un pedido (entidad fuerte). El pedido tendrá un código y un montante total que se calcula a partir de los valores de las líneas de pedido. La propia restricción de identificación implica que las líneas de pedido realmente se identifican por su número de línea y por el código del pedido, por ejemplo la línea 1 del pedido R2024A01, la línea 2 del mismo pedido, etc... o la línea 1 de otro pedido diferente.

En las restricciones de identificación es muy común que la entidad débil se identifique mediante un número o código secuencial, el cual se reinicia por cada cambio de la entidad fuerte. Por ejemplo, pensemos en que todos los apartamentos de un edificio empiezan desde el número 101, pudiendo tener el apartamento 102 del edificio E1 y el apartamento 102 del edificio E2, es decir, la entidad APARTAMENTO tiene una restricción de identificación con EDIFICIO.

Pongamos otro ejemplo, si identificamos al alumnado por su número de lista y por el grupo al que pertenecen, tendremos que no será el mismo estudiante el número 1 del grupo 1K que el estudiante 1 del grupo 2K, de manera que tendremos una restricción de identificación entre la entidad ESTUDIANTE y la entidad GRUPO.

Débil o fuerte

Hay casos en los que una entidad tiene relación con varias entidades, comportándose como débil en una, y como fuerte en otras. Es por ello, que además de marcar la entidad como débil, debemos marcar la relación con un doble rombo.

Veámoslo con un ejemplo. Si sobre la línea de pedido, añadimos una relación 1:N con observaciones sobre la misma, tendríamos el siguiente modelo, donde LINEA_PEDIDO es una entidad débil respecto a la relación CONTENER, pero hace de entidad fuerte respecto a la relación TENER.

Cardinalidades exactas

En ocasiones sabemos la cantidad exacta de ocurrencias con las que se puede relacionar una entidad. En dicho caso, seguirán siendo relaciones 1:N o N:M, pero en el modelo, indicaremos la cantidad de ocurrencias.

Por ejemplo, si en una clase se matriculan un mínimo de 5 estudiantes y un máximo de 24, y un estudiante se matricula en al menos 2 clases y 6 como máximo, tendremos:

Pérdida expresiva

En ocasiones, los modelos conceptuales no son capaces de expresar todas las restricciones, relaciones o propiedades el mundo real, ya sea por algunas relaciones muy complejas, dependencias temporales o reglas de negocio.

Para ello, en el pie de los modelos indicaremos con texto una frase del estilo "Pérdida expresiva: Todo cliente debe haber nacido en la misma provincia que la tienda donde realiza el pedido".

El modelo Entidad Relación Extendido¶

Con el paso de los años, y dadas ciertas carencias del modelo entidad relación, a mediados de los años 80 se extendió con la incorporación de los conceptos de clase y subclase, junto con los conceptos de generalización y especialización, así como la agregación de entidades, dando lugar al modelo Entidad Relación Extendido (EER).

Generalización¶

La descomposición de tipos de entidad en varios subtipos o subclases permite identificar jerarquías de entidades, entre una entidad general, que denominamos entidad superclase (o entidad padre), que se puede especializar en entidades subclase (o entidades hijas):

La entidad superclase modelan las características comunes de la entidad vista de una forma genérica.
Las entidades subclase modelan las características propias de sus especializaciones.

Es necesario que se cumpla que toda ocurrencia de una entidad subclase sea también una ocurrencia de su entidad superclase, propagando sus características de padres a hijos, lo que se denomina herencia de propiedades.

Generalización vs Especialización

Se dice que tenemos una generalización, cuando dos o más tipos de entidades van a compartir diferentes atributos. Para ello, la entidad superclase contendrá aquellos atributos comunes a las subclases. En cambio, se dice que realizamos una especialización cuando un tipo de entidad tiene algunos atributos que tienen sentido para algunas subclases, pero no para todas. Para ello, cada subclase contendrá sus atributos específicos, y los comunes se colocan en la superclase.

Así pues, se dice que la generalización va de abajo hacia arriba, subiendo los atributos comunes al padre, y en consecuencia, la especialización va de arriba a abajo, colocando en los hijos los atributos específicos que no comparten todas las subclases.

Con generalización y la especialización se establece una relación ES-UN (en inglés, IS-A), indicando que una entidad hijo ES-UN con la entidad padre. Por ejemplo, si la superclase es VEHICULO, ejemplos de subclases serían CAMION, AUTOBUS, MOTO, etc... ya que un CAMION es un VEHICULO.

En la generalización/especialización, las características (atributos o interrelaciones) de la entidad superclase se propagan hacia las entidades subclase. Es lo que se denomina herencia de propiedades.

Las generalizaciones siempre se representan en vertical, situando la entidad superclase arriba y las subclases debajo. Para conectarlas, se utiliza un círculo que puede contener la letra d o la letra o de forma similar al ejemplo que tenemos en el lateral, para indicar que la especialización es disjunta o solapada (overlap). Entre la clase padre y el círculo, si se utiliza una línea simple indicamos que es una especialización parcial y si es doble, que se trata de una generalización total.

Finalmente, el circulo conecta con los hijos mediante una línea que contiene un arco indicando el sentido del padre a los hijos.

Así pues, en el ejemplo tenemos que un LIBRO tiene un isbn y un título. Y que un EBOOK ES-UN LIBRO y que EN_PAPEL también ES-UN LIBRO. Un EBOOK en total tiene tres atributos, los dos que hereda del padre, más el formato del ebook. De forma similar, EN_PAPEL, también tiene tres atributos, los dos que hereda de LIBRO más el número de páginas de la copia impresa.

Tipos¶

Cuando definimos una especialización es muy importante definir cómo se relacionan las superclases con las subclases.

Vamos a centrarnos en un supuesto donde tenemos una superclase EMPLEADO y tenemos tres subclases: DIRECTIVO, TECNICO y COMERCIAL.

Si nos centramos en la cantidad de subtipos posibles tenemos:

Total: La superclase pertenece obligatoriamente a alguna de las subclases. No puede haber un EMPLEADO que no sea ni DIRECTIVO, ni TECNICO, ni COMERCIAL. Se representa uniendo mediante una línea doble (||) la superclase con el círculo.
Parcial: La superclase puede no pertenecer a alguna de las subclases. Podríamos tener un EMPLEADO que no sea ni DIRECTIVO, ni TECNICO, ni COMERCIAL. Se representa uniendo mediante una línea sencilla (|) la superclase con el círculo.

Y si ponemos en foco en la exclusividad de las subclases:

Disjunta / Exclusiva: La superclase sólo pertenece a una de las subclases. Si un EMPLEADO es un DIRECTIVO, no puede ser un TECNICO ni un COMERCIAL. Se representa poniendo una d dentro del círculo.
Solapada: La superclase puede pertenecer a varias de las subclases a la vez. Un EMPLEADO puede ser un DIRECTIVO y un COMERCIAL a la vez. Se representa poniendo una o dentro del círculo.

Con lo cual, se pueden dar las siguientes combinaciones:

	Total `\|\|`	Parcial `\|`
Disjunta `(d)`
Solapada `(o)`

Supuesto Tienda

Se pide diseñar la base de datos de una tienda, la cual está organizada por departamentos, que contenga información sobre los trabajadores y los artículos que se ofertan.

Se deben tener en cuenta las siguientes restricciones:

De todos los trabajadores nos interesa almacenar su DNI, nombre completo y número de teléfono, así como el departamento en el que trabajan.
Existen tres tipos de trabajadores: gerentes (del que guardaremos el bonus anual), jefes (nos interesa almacenar cuantos vendedores tiene a su cargo) y vendedores (de cada vendedor, guardaremos su sueldo base y la zona donde trabaja).
Cada departamento lo dirige un gerente, aunque se puede dar el caso que tengamos gerentes que no dirijan ningún departamento, pero nunca dirigirán más de uno.
Un gerente tiene a su cargo a un cierto número de jefes y éstos a su vez a un cierto número de vendedores.
En cuanto a los productos nos interesa su código, nombre y precio, y departamento en el que se encuentran.
Cada producto lo pueden vender muchos vendedores, y cada vendedor, a su vez, puede vender muchos productos. Además, cada vendedor le aplicará un determinado descuento a los productos con los que trabaja.

Solución

Primero localizamos las entidades y sus atributos:

Entidades: TRABAJADOR, DPTO, PRODUCTO. Los trabajadores a su vez, se descomponen en las subclases VENDEDOR, JEFE y GERENTE.
Atributos: los trabajadores se identifican por su dni, mientras que los departamentos y los productos por su codigo.

Las relaciones son:

Relación 1:N nombrada como PERTENECER entre TRABAJADOR Y DPTO, ya que de los trabajadores nos interesa "el departamento en el que trabajan" y se entiende que a un departamento pertenecerán varios trabajadores.
Generalización total y disjunta entre TRABAJADOR y sus hijos VENDEDOR, JEFE y GERENTE, cada uno con sus propios atributos. Destacar que el atributo de cantVendedores es derivado, ya que se obtiene de la cardinalidad de la relación SUPERVISAR.
Relación 1:1 nombrada como DIRIGIR entre DPTO Y GERENTE, ya que "Cada departamento lo dirige un gerente, aunque se puede dar el caso que tengamos gerentes que no dirijan ningún departamento, pero nunca dirigirán más de uno"
Relación 1:N nombrada como MANDAR entre GERENTE Y JEFE, ya que "Un gerente tiene a su cargo a un cierto número de jefes".
Relación 1:N nombrada como SUPERVISAR entre JEFE Y VENDEDOR, continuando "y éstos (los jefes) a su vez a un cierto número de vendedores".
Relación 1:N nombrada como ENCONTRAR entre DPTO Y PRODUCTO, ya que "En cuanto a los productos nos interesa ... departamento en el que se encuentran", y entendemos que en un departamento encontraremos varios productos.
Relación N:M nombrada como VENDER entre VENDEDOR y PRODUCTO, ya que "Cada producto lo pueden vender muchos vendedores, y cada vendedor, a su vez, puede vender muchos productos". Además, añadimos el atributo descuento en la relación para almacenar el descuento que cada vendedor aplica a los productos.

Agregación¶

La agregación surge de la limitación que existe en el modelo ER de no permitir expresar relaciones entre relaciones binarias, y en gran medida, haciendo uso de agregaciones podemos evitar hacer uso de relaciones ternarias.

Así pues, una agregación se comporta como una entidad más, con un nivel de abstracción mayor que la propia relación.

Por ejemplo, tengamos el caso de un docente que imparte clase en una determinada aula. El docente dará clase a varios grupos en el aula, y en el aula entran varios docentes. Queda claro que una relación N:M entre DOCENTE y AULA (por ejemplo, IMPARTIR) nos permite modelar este caso. Pero ¿y si queremos registrar las incidencias que se producen en el aula cuando un docente está dando clase? Si unimos la entidad INCIDENCIA con DOCENTE o con AULA, estaríamos perdiendo información.

Así pues, creamos una entidad asociativa que funciona como una agregación, y la nombramos, por ejemplo como SESION (una sesión lectiva la imparte un docente en un aula) y ésta es la que relacionamos con la entidad INCIDENCIA mediante la relación REGISTRAR. Es importante destacar que la entidad asociativa no tiene atributo identificador, porque realmente es como si tuviera una restricción de identificación respecto a las otras entidades, a modo de entidad débil que necesita de todas las entidades con las que se asocia para identificarse.

El mecanismo de agregación lo que hace es abstraer las entidades y la relación que las asocia para obtener una entidad compleja, conocida como entidad asociativa, que a su vez puede relacionarse como una entidad normal con el resto de entidades de nuestro sistema.

Aunque tiene muchos puntos de contacto con una relación ternaria, la agregación remarca la relación entre una determinada pareja de entidades, al mismo tiempo que no implica una necesaria asociación con la tercera entidad, como si ocurre en las ternarias.

Referencias¶

Herramienta gráfica ERDPlus para la realización de diagramas entidad relación.
Materiales sobre el módulo de BD:
- Conceptes del model Entitat-Relació. Entitats. Relacions i Diagrames Entitat-Relació - Institut Obert de Catalunya.
- Modelo Entidad Relación de Jorge Sánchez.
- Interpretación de Diagramas ER de Javier Gutiérrez.
- Diseño de modelo lógicos normalizados gestionbasesdatos.readthedocs.io
- Diseño conceptual de bases de datos, por Luis Valencia y David Orellana, de la Universidad de Sevilla.

Actividades¶

AC201. (RABD.6 // CE6b, CE6c // 3p) A partir del siguiente sistema de información, identifica las entidades, atributos y relaciones:

Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nombre, apellidos, dni, dirección y fecha de nacimiento). Cada producto tiene un nombre y un código, así como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes. Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el NIF, nombre y dirección

AC202. (RABD.6 // CE6d // 3p) A partir del ejercicio anterior, realiza el modelo ER únicamente con las entidades y las relaciones utilizando ambas notaciones (sin colocar los atributos) y define las cardinalidades de las relaciones. Para ello, dibuja en un folio el modelo y escanea o adjunta una foto del resultado y súbelo a Aules.

AC203. (RABD.6 // CE6b // 3p) A partir del siguiente modelo ER, indica las cardinalidades de las relaciones, y a continuación, redacta el texto que daría lugar como resultado este modelo:

Actividad 203

AC204. (RABD.6 // CE6b, CE6c, CE6e // 1,5p) Realiza el modelo ER del siguiente sistema de información:

Una empresa ubicada en distintos edificios de distintos polígonos industriales desea registrar la distribución de sus departamentos.
Un departamento puede estar distribuido en varios edificios. Del departamento tenemos su nombre y el número de empleados que lo integran.
De los edificios sabemos su nombre y el número de despachos que tienen. En cada edificio (que está localizado en un polígono industrial, y del que se conoce su nombre y la ciudad en la que está situado) pueden ubicarse distintos departamentos.
Debido a esto, se desea controlar el número de despachos que cada departamento tiene en cada edificio.

AC205. (RABD.6 // CE6b, CE6c // 1,5p) Realiza el modelo ER del siguiente sistema de información:

Una pequeña empresa telefónica desea crear una base de datos para el control de las llamadas efectuadas exclusivamente entre sus clientes.
Dispondrá de información sobre las terminales de su red (si se trata de teléfonos móviles o fijos, el no de teléfono y el nombre del cliente), y de cada llamada realizada entre ellos se almacenará: números de teléfono del emisor y el receptor de la llamada, la hora de comienzo de la misma y su duración.

AR206. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER de una base de datos que almacenará información sobre los ríos de España.

En esta base de datos vamos a almacenar el nombre y el número de habitantes de todas las comunidades autónomas, el nombre y el número de habitantes de algunas ciudades, así como la autonomía a la que pertenecen.
Se desea conocer el nombre, longitud y caudal de algunos ríos, registrando las ciudades (de entre las que tenemos almacenadas) por las que pasan, así como las comunidades que bañan. Además, se guardará el número de kilómetros que de cada río discurren por cada comunidad autónoma.

AP207. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER del siguiente sistema de información:

Una agencia de viajes pretende informatizar su gestión, que hasta ahora se venía haciendo de forma manual. De cada viaje se tiene la siguiente información: código del viaje, nombre del viaje y países visitados

Cada viaje se desarrolla en una serie de jornadas (días). De cada jornada se desea mantener la siguiente información: número de la jornada en el viaje, descripción, localidad de partida, localidad de destino y localidades intermedias que se visitan (se puede visitar 0,1 o más localidades intermedias), principal medio de transporte utilizado (0 ó 1), kilómetros recorridos y hotel de pernocta (puede ocurrir que una jornada no incluya ningún hotel de pernocta, por ejemplo, una jornada de vuelo).

En un viaje se visitan uno o más países. De cada país se cuenta con la siguiente información: nombre, pasaporte (si/no), localidad capital y descripción.

De cada localidad se desea conocer su nombre, país y descripción. Es posible que en una jornada se visiten localidades situadas en países distintos a los indicados como visitados en el viaje.

De cada medio de transporte se desea mantener su código y descripción. De cada hotel se desea conocer la siguiente información: código de hotel, nombre del hotel, categoría 1 a 6 estrellas, número de fax, número de teléfono, localidad en que se halla situado, país, descripción y hotel de reserva que lo sustituye en caso de que no haya plazas. En una localidad puede haber situados más de un hotel, pero sólo uno será titular para una jornada determinada.

AC208. (RABD.6 // CE6b, CE6c, CE6e // 3p) Completa el siguiente modelo ER a partir del siguiente sistema de información sobre una prueba ciclista, teniendo en cuenta que no están modeladas todas las entidades, relaciones y/o atributos:

A los ciclistas inscritos en la prueba se les asigna un dorsal único. De cada ciclista participante se desea conocer su edad, nombre y equipo al que pertenece. De cada equipo se desea conocer su director.

La prueba es por etapas. De cada etapa se registra el número de etapa, los kilómetros, la ciudad de salida y la de llegada (con unas breves reseñas geográficas, históricas y económicas) y los puertos por los que pasa la etapa (nombre, altura, categoría).

Se quiere conocer qué ciclista ha ganado en cada puerto y quién ha ganado cada etapa.

Actividad 208

AC209. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER del siguiente sistema de información sobre cine:

De cada película le interesará conocer el título, el año de producción, la nacionalidad, y los datos (nombre, fecha de nacimiento y nacionalidad) de los intérpretes (como mucho los 6 intérpretes principales), del director y los autores del guion en el que está basada la película. De este último -el guion- se sabrá además el título.

También desea conocer los posibles Oscars ganados por cada película en las modalidades de: mejor película, mejor guion, mejores intérpretes y mejor director.

Por último, se tendrán identificadas las películas que son remakes de otras, conociendo en ese caso, la película original y los distintos remakes.

AC210. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER del siguiente sistema de información sobre un campeonato de ajedrez que gestiona toda la información participantes, alojamientos y partidas:

En el campeonato participan jugadores y árbitros; de ambos se requiere conocer el número de asociado, nombre, dirección, teléfono de contacto y campeonatos en los que han participado (como jugador o como árbitro). De los jugadores se precisa además el nivel de juego en una escala de 1 a 10. Ningún árbitro puede participar como jugador.

Los países envían al campeonato un conjunto de jugadores y árbitros, aunque no todos los países envían participantes. Todo jugador y árbitro es enviado por un único país. Un país puede ser representado por otro país. Cada país se identifica por un número correlativo según su orden alfabético e interesa conocer además de su nombre, el número de clubes de ajedrez existentes en el mismo.

Cada partida se identifica por un numero correlativo (codigop), la juegan dos jugadores y la arbitra un árbitro. Interesa registrar las partidas que juegan cada jugador y el color (blancas o negras) con el que juega. Ha de tenerse en cuenta que un árbitro no puede arbitrar a jugadores enviados por el mismo país que le ha enviado a él. Todo participante participa en al menos una partida.

Tanto jugadores como árbitros se alojan en uno de los hoteles en los que se desarrollan las partidas, se desea conocer en qué hotel y en qué fechas se ha alojado cada uno de los participantes. Los participantes pueden no permanecer en el mismo hotel que se realiza el campeonato durante todo el campeonato, sino acudir cuando tienen que jugar alguna partida alojándose en el mismo o distinto hotel. De cada hotel, se desea conocer el nombre, la dirección y el número de teléfono.

El campeonato se desarrolla a lo largo de una serie de jornadas (año, mes, día) y cada partida tiene lugar en una de las jornadas aunque no tengan lugar partidas todas las jornadas.

Cada partida se celebra en una de las salas de las que pueden disponer los hoteles, se desea conocer el número de entradas vendidas en la sala para cada partida. De cada sala, se desea conocer la capacidad y medios de que dispone (radio, televisión, video...) para facilitar la retransmisión de los encuentros. Una sala puede disponer de varios medios distintos.

De cada partida se pretende registrar todos los movimientos que la componen. La identificación de movimiento se establece en base a un numero de orden dentro de cada partida: para cada movimiento se guardan la jugada (5 posiciones) y un breve comentario realizado por un experto.

AC211. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER del siguiente sistema de información sobre las cadenas de radio del panorama radiofónico:

De cada cadena conoceremos el nombre, el género (musical, de noticias, deportiva, ...) y además, el nombre de las provincias en las que emite, teniendo en cuenta que una cadena puede tener varias emisoras en una misma provincia, cada una de ellas emitiendo en su correspondiente dial.

Por otra parte, conoceremos el nombre y la antigüedad de todos los empleados de cada cadena de radio. De los técnicos conoceremos además su especialidad (de sonido, de archivo, de mantenimiento, ...) y de los locutores los programas que presentan.

Sabremos, para cada programa, su nombre, la hora de inicio, su duración en minutos y la cadena de radio que lo emite.

Hemos de tener en cuenta además que cada locutor puede presentar un máximo de tres programas distintos y que cada programa es presentado como mucho por cinco locutores.

Los programas pueden tener un patrocinador del que conoceremos el nombre y el aporte económico; distintos programas pueden tener el mismo patrocinador.

AR212. (RABD.6 // CE6b, CE6c, CE6e // 3p) Realiza el modelo ER del siguiente sistema de información sobre la Eurocopa:

Nos interesa conocer el nombre de cada selección y su indumentaria habitual (color de la camiseta, del pantalón y las calzas), el nombre del seleccionador y el número de años que éste lleva en el cargo, y los nombres, número de camiseta y posición (portero, defensa, centrocampista, ...) de los 22 jugadores de cada equipo.

Además, se desea almacenar información de todos los partidos jugados por cada equipo: la fecha, el lugar, el equipo local y el resultado (número de goles del equipo local y del visitante).

También, de cada gol marcado, el jugador que lo marca, el portero que lo encaja, el minuto de juego y el tipo de gol (de falta, de penalti, en jugada, etc...).

AP213. (RABD.6 // CE6b, CE6c, CE6e // 3p) Estudia cómo se representan las generalizaciones y las agregaciones mediante otras notaciones utilizando los recursos recomendados en el apartado de Referencias.

AC214. (RABD.6 // CE6b, CE6c, CE6d, CE6e // 3p) A partir del siguiente modelo EER sobre un concurso de cocina:

Modelo ER Cocina

Contesta las siguientes cuestiones justificando tu respuesta:
1. ¿Cuantos tipos de concursantes hay? ¿Podemos tener más? ¿Y están relacionados entre sí?
2. ¿Qué tipo de relación existe entre EDICION y PREMIO. ¿Se puede repetir el mismo premio en diferentes ediciones?
3. ¿Puede ganar el concurso un restaurante que lo dirige un concursante de un país diferente?
4. ¿Para qué sirve el atributo contrato de la relación TRABAJAR entre RESTAURANTE y PROFESIONAL
5. Respecto a las recetas, ¿por qué tiene una relación reflexiva?
6. Si eliminamos la entidad PAIS, ¿qué cambios habría que hacer en el modelo para que siguiera expresando lo mismo?

PY215. (RABD.6 // CE6b, CE6c, CE6d, CE6e // 10p) Una vez que ya tenemos unas nociones básicas sobre el modelado conceptual de datos, llega el momento de concretar el sistema de información y crear el modelo de datos del Reto I - Diseñamos de nuestro equipo.

Toda solución debe:
- Tener un mínimo de 6 entidades.
- Utilizar relaciones con diferentes cardinalidades.
- Emplear atributos de diferente tipo.
- (opcional) Utilizar una generalización o agregación.
Se debe entregar un informe con el sistema de información, el modelo EER y describir las decisiones tomadas en su elaboración.

Se utilizará una rúbrica para su evaluación en base a la siguiente lista de cotejo:
- Todas las entidades tienen un atributo que las identifica.
- La nomenclatura es homogénea en todo el modelo.
- Las entidades se nombran en singular y mayúsculas.
- Las relaciones se nombran con verbos en mayúsculas.
- Los atributos se nombran en minúsculas.
- Todas las relaciones indican la cardinalidad

AR216. (RABD.6 // CE6b, CE6c, CE6d, CE6e // 3p) Una vez finalizada la unidad, responde todas las preguntas del cuestionario inicial, con al menos un par de líneas para cada una de las cuestiones.