UT3. Interpretación de Diagramas Entidad/Relación

Los diagramas Entidad/Relación (ER) son una herramienta visual utilizada para representar la estructura lógica de una base de datos. Estos diagramas ayudan a identificar las entidades, sus atributos y las relaciones entre ellas. Es un tipo de representación del modelo conceptual de datos que es una abstracción de alto nivel que describe la organización de los datos sin entrar en detalles técnicos.

Nomenclatura Básica

A la nombrar los diferentes componentes de un diagrama ER, se utilizan ciertas convenciones:

Las entidades se nombran con sustantivos plurales (por ejemplo, Empleados, Departamentos).
Los atributos se nombran con adjetivos o sustantivos que describen la entidad (por ejemplo, Nombre, Apellido, Edad).
Las relaciones se nombran con verbos que indican la acción entre las entidades (por ejemplo, Trabaja, Supervisa, Compra).
Para la palabra compuesta, se utilizan guiones bajos para separar las palabras (por ejemplo, Fecha_de_contratación).

Elementos

Entidades: Representan objetos o conceptos del mundo real que tienen existencia independiente. Es cualquiera que pueda ser identificado de manera única. Por ejemplo, Empleados o Productos. Se representan con rectángulos.
Atributos: Son las propiedades o características de una entidad. Por ejemplo, un Empleado puede tener atributos como Nombre, Apellido y Fecha_de_nacimiento. Se representan con óvalos conectados a la entidad correspondiente.
Relaciones: Representan la asociación entre dos o más entidades. Por ejemplo, un Empleado puede Trabajar_en un Departamento. Se representan con rombos conectados a las entidades involucradas.

En este modelo describe también que reglas deben cumplir (propiedades o restricciones). Estas reglas se dividen en dos tipos:

Propiedades estáticas

Son las restricciones que siempre deben cumplirse en el estado actual de la base de datos. Es decir, qué datos son válidos o no válidos en un momento dado. Por ejemplo:

"No puede haber un alumno sin número de matrícula".
"Una relación 'matricula' solo puede existir entre un alumno y una asignatura existentes".

Estas propiedades se pueden sobre los atributos, las entidades o las relaciones.

Sobre atributos: Restringen los valores que puede tener un atributo.
- Valores posibles: Por ejemplo, el atributo nota debe estar entre 0 y 10. (No se permite 12 o -3)
- Valor no nulo: Por ejemplo, el atributo DNI de un alumno no puede ser nulo. (Todos deben tener uno)
Sobre entidades: Afectan a la identificación de las entidades (cómo las distinguimos).
- Restricción de identificación: Por ejemplo, dos alumnos no pueden tener el mismo número de matrícula. (Es la clave primaria en términos de base de datos)
Sobre relaciones: Controlan cómo se vinculan las entidades entre sí.
- Restricciones de cardinalidad: Indican cuántas veces puede participar una entidad en una relación. Por ejemplo, un alumno puede estar matriculado en varias asignaturas. Cada asignatura puede tener varios alumnos (Relación muchos a muchos).

Propiedades dinámicas

Estas tienen que ver con cómo cambian los datos con el tiempo, es decir, con las operaciones (inserciones, actualizaciones, borrados) y transacciones que se realizan.

Se usan para expresar reglas de negocio que afectan a la evolución del sistema. Por ejemplo:

"El número de alumnado matriculado en una asignatura debe ser menor o igual a 20"

Esto significa que no es una restricción fija sobre un solo dato, sino sobre cómo evoluciona la relación “matrícula”. Si ya hay 20 alumnos matriculados, no se permite añadir otro.

Otros ejemplos:

"Un pedido solo puede pasar al estado enviado si tiene al menos un producto."
"Si se borra un cliente, deben borrarse también sus pedidos." (restricción dinámica de tipo en cascada)

Elaboración.

Una vez conocidos los elementos y las propiedades del modelo conceptual, es común preguntarse cómo deducimos estos elementos a partir de una descripción de un cliente.

Normalmente, después de tener diversas entrevistas con el cliente, se obtiene un sistema de información que debe ser modelado. Con esta información, el primer paso es identificar las entidades principales y las relaciones entre ellas, sin entrar en detalles de atributos o restricciones.

Por ejemplo, supongamos que un cliente requiere un sistema para gestionar el alquiler de coches con la siguiente descripción:

"El sistema debe permitir a los usuarios alquilar coches. Cada usuario puede reservar múltiples coches para diferentes periodos de tiempo."

A partir de esta descripción, cuando encontramos sustantivos conectados con un verbo, es frecuente que esos sustantivos representen entidades y el verbo la relación entre ellas. En este caso, podemos identificar las siguientes entidades y relaciones:

Usuario: Representa a la persona que utiliza el sistema para alquilar coches.
Coche: Representa el vehículo que está disponible para alquiler.
Alquilar: Representa la acción de reservar un coche para un periodo determinado.

En este diagrama, hemos representado las entidades Usuario y Coche, así como la relación Alquilar entre ellas. A partir de aquí, se pueden añadir atributos y restricciones adicionales según sea necesario.

Una vez realizada esta primera identificación de los elementos principales, vamos a ver con más detalle cada uno de ellos.

Entidades

Las entidades son los elementos fundamentales del modelo ER. Representan objetos o conceptos del mundo real que tienen existencia independiente y pueden ser identificados de manera única.

Cada entidad solo puede aparecer una vez en el diagrama ER. Si una entidad se repite, se debe unificar en una sola entidad.

Además, existen dos tipos de entidades:

Entidades fuertes: Son aquellas que existen por si mismas independientemente de otras entidades y pueden ser identificadas de manera única por sus propios atributos. Por ejemplo, una Cliente que puede ser identificado por su Número de cliente.
Entidades débiles: Son aquellas que dependen de otra entidad para su existencia y no pueden ser identificadas de manera única por sus propios atributos. Por ejemplo, un Familiar que depende de un Cliente y no puede ser identificado sin la referencia al Cliente.

Otro ejemplo podría ser un edificio y sus apartamentos.

Entidad fuerte: Edificio
- Edificio (CodEdificio, Dirección, Ciudad)
- Cada edificio tiene un código único (CodEdificio) que lo identifica.
- Puede existir por sí mismo → es una entidad fuerte.
Entidad débil: Apartamento
- Apartamento (NumApartamento, Superficie, Precio)
- El número de apartamento (NumApartamento) no identifica de forma única al apartamento dentro de toda la base de datos, porque puede haber un "Apartamento 1" en cada edificio.

Por eso, para identificar un apartamento concreto, necesitas saber a qué edificio pertenece, (CodEdificio, NumApartamento). Si se elimina un edificio, sus apartamentos también desaparecen (dependencia existencial).

Relaciones

Las relaciones representan la asociación entre dos o más entidades. Indican cómo las entidades están vinculadas entre sí en el contexto del sistema de información. Para dibujar una relación, se utiliza un rombo que conecta las entidades involucradas y la relación se nombra con un verbo que describe la acción o asociación entre las entidades.

La relación se establece en los dos sentidos:

Un Cliente Alquila uno o varios Coches de forma que la relación va de Cliente a Coche.
Un Coche es Alquilado por uno o varios Clientes, de forma que la relación va de Coche a Cliente.

Grados de relación

El grado de una relación se refiere al número de entidades que participan en esa relación. Existen 4 tipos principales de grados de relación:

Relación binaria: Involucra a dos entidades. Es el tipo más común de relación. Por ejemplo, la relación Alquila entre Cliente y Coche.
Relación ternaria: Involucra a tres entidades. Por ejemplo, una relación Asignar entre Empleado, Proyecto y Rol.
Relación n-aria: Involucra a n entidades, donde n es mayor que tres. Por ejemplo, una relación Participar entre Estudiante, Curso, Profesor y Semestre.
Relación recursiva: Involucra a una sola entidad que se relaciona consigo misma. Por ejemplo, una relación Supervisa donde un Empleado puede supervisar a otros Empleados.

Cardinalidad

La cardinalidad de una relación indica el número de instancias de una entidad que pueden estar asociadas con una instancia de otra entidad en una relación. Para esto, especificamos las cardinalidades mínimas y máximas.

Cardinalidad mínima: Indica el número mínimo de instancias de una entidad que deben participar en una relación. Puede ser 0 (opcional) o 1 (obligatorio). Por ejemplo, ¿Cuántos coches puede alquilar un cliente como mínimo?
Cardinalidad máxima: Indica el número máximo de instancias de una entidad que pueden participar en una relación. Puede ser 1 (obligatorio) o n (opcional), donde n es un número entero positivo. Por ejemplo, ¿Cuántos coches puede alquilar un cliente como máximo?

La cardinalidad se representa mediante pares (mínima, máxima) junto a las entidades en el diagrama ER. Las posibles combinaciones son:

(0,1): Una entidad puede estar asociada con cero o una instancia de otra entidad. Por ejemplo, un Empleado puede tener cero o un Supervisor.
(1,1): Una entidad debe estar asociada con exactamente una instancia de otra entidad. Por ejemplo, cada Empleado debe tener un Contrato único.
(0,n): Una entidad puede estar asociada con cero o más instancias de otra entidad. Por ejemplo, un Cliente puede tener cero o más Pedidos.
(1,n): Una entidad debe estar asociada con al menos una instancia de otra entidad. Por ejemplo, un Profesor debe impartir al menos un Materia.

Para identificar la cardinalidad podemos coger una instancia de una entidad y preguntarnos cuántas instancias de la otra entidad pueden estar relacionadas con ella.

Por ejemplo, en la relación Alquila entre Cliente y Coche:

Para un Cliente específico, ¿cuántos Coches puede alquilar? La respuesta es (0,n) porque un cliente puede no alquilar ningún coche o puede alquilar varios coches.
Para un Coche específico, ¿cuántos Clientes pueden alquilarlo? La respuesta es (0,1) porque un coche puede no estar alquilado por ningún cliente o puede estar alquilado por un solo cliente a la vez.

Para representar la cardinalidad en el diagrama ER, se colocan los pares (mínima, máxima) junto en la entidad con la que nos estamos realizando la pregunta.

Tipos

Existen tres tipos principales de relaciones basadas en la cardinalidad. Para determinar el tipo de relación, se analizan las cardinalidades máximas de ambas entidades involucradas en la relación:

Uno a uno (1:1): Cada instancia de una entidad está asociada con exactamente una instancia de otra entidad, y viceversa. Por ejemplo, cada Empleado tiene un Contrato único, y cada Contrato está asociado con un solo Empleado.
Uno a muchos (1:N): Una instancia de una entidad puede estar asociada con múltiples instancias de otra entidad, pero cada instancia de la segunda entidad está asociada con solo una instancia de la primera entidad. Por ejemplo, un Cliente puede tener múltiples Pedidos, pero cada Pedido está asociado con un solo Cliente.
Muchos a muchos (N:M): Múltiples instancias de una entidad pueden estar asociadas con múltiples instancias de otra entidad. Por ejemplo, un Estudiante puede estar inscrito en múltiples Cursos, y cada Curso puede tener múltiples Estudiantes inscritos.

Relación 1:1

En una relación uno a uno (1:1), cada instancia de una entidad A está asociada con exactamente una instancia de una entidad B, y viceversa. Esto significa que no puede haber más de una instancia de A relacionada con una instancia de B y no puede haber más de una instancia de B relacionada con una instancia de A.

Empleado - Dirige - Departamento.. — Empleado - Dirige - Departamento.

Si una relación 1:1 tiene una cardinalidad mínima de 1 en ambos lados, se dice que es una relación obligatoria. Esto significa que cada instancia de ambas entidades debe estar asociada con una instancia de la otra entidad. Por ejemplo, en la relación Dirige entre Empleado y Departamento, si cada empleado debe dirigir un departamento y cada departamento debe ser dirigido por un empleado, entonces la relación es obligatoria. Para evitar este tipo de problemas, es común permitir que la cardinalidad mínima sea 0 en al menos uno de los lados.

Relación 1:N

En una relación uno a muchos (1:n), una instancia de una entidad A puede estar asociada con múltiples instancias de una entidad B, pero cada instancia de la entidad B está asociada con solo una instancia de la entidad A.

Del mismo modo que ocurre con la relación 1:1, si una relación 1:n tiene una cardinalidad mínima de 1 en ambos lados, se dice que es una relación obligatoria. En este ejemplo, cada cliente debe realizar al menos un pedido, y cada pedido debe ser realizado por un cliente. Para evitar este tipo de problemas, es común permitir que la cardinalidad mínima sea 0 en al menos uno de los lados, es este caso, normalmente en el lado del cliente.

Relación N:M

En una relación muchos a muchos N:M, múltiples instancias de una entidad A pueden estar asociadas con múltiples instancias de una entidad B, y viceversa.

Al igual que en los casos anteriores, si una relación m:n tiene una cardinalidad mínima de 1 en ambos lados, se dice que es una relación obligatoria. En este ejemplo, cada estudiante debe matricularse en al menos una asignatura, y cada asignatura debe tener al menos un estudiante matriculado. Para evitar este tipo de problemas, es común permitir que la cardinalidad mínima sea 0 en al menos uno de los lados.

Relaciones N:M con fechas

En ocasiones, las relaciones N:M pueden incluir atributos adicionales que proporcionan información específica sobre la relación entre las entidades. Un ejemplo común es cuando se necesita registrar fechas asociadas a la relación.

Por ejemplo, el alquiler de coches puede implicar fechas de inicio y fin del alquiler. En este caso, la relación Alquila entre Clientes y Coches puede tener atributos adicionales como Fecha_inicio y Fecha_fin.

Relaciones reflexivas

Una relación reflexiva es aquella en la que una entidad se relaciona consigo misma. Esto significa que una instancia de la entidad puede estar asociada con otra instancia de la misma entidad. Por ejemplo, en una empresa, un empleado puede supervisar a otros empleados. En este caso, la entidad Empleados tiene una relación reflexiva llamada Supervisa.

El rol de la relación ayuda a clarificar cómo se relacionan las instancias de la entidad entre sí. En este caso, un empleado puede ser tanto un supervisor como un subordinado. Normalmente, se utilizan nombres de rol para distinguir entre las diferentes funciones que una instancia puede tener en la relación. En este ejemplo, los roles son Trabajador y Jefe. Debido a que se puede deducir las relaciones no es necesario especificar el rol en el diagrama, pero puede ser útil para la comprensión.

Atributos

Los atributos son las propiedades o características de una entidad o relación. Proporcionan información adicional sobre las entidades y relaciones en el modelo ER. Los atributos se representan con óvalos conectados a la entidad o relación correspondiente.

Existen diferentes tipos de atributos:

Identificadores: Son aquellos que permiten identificar de manera única una instancia de una entidad. Se representan con un óvalo simple y el nombre subrayado. Por ejemplo, el DNI de un Cliente.
Compuestos: Son aquellos que se pueden descomponer en subatributos más simples. Se representan con un óvalo simple y el nombre entre paréntesis. Los subatributos se representan con óvalos simples conectados al óvalo del atributo compuesto. Por ejemplo, la dirección de un Cliente puede tener subatributos como Calle, Ciudad y Código Postal.
Multivaluados: Son aquellos que pueden tener múltiples valores para una sola instancia de una entidad. Se representan con un óvalo doble. Por ejemplo, un Cliente puede tener múltiples Números de teléfono.
Derivados: Son aquellos que se pueden calcular a partir de otros atributos. Se representan con un óvalo punteado. Por ejemplo, la Edad de un Cliente puede derivarse de su Fecha de nacimiento.
Opcionales: Son aquellos que no son obligatorios para todas las instancias de una entidad. Se representan con un óvalo simple y el nombre en cursiva junto a (O). Por ejemplo, el Email de un Cliente puede ser opcional.
Obligatorios: Son aquellos que deben tener un valor para todas las instancias de una entidad. Se puede representar con un óvalo simple y el nombre en negrita junto a (R). Por ejemplo, el Nombre de un Cliente es obligatorio.
Atributos de relación: Son aquellos que pertenecen a una relación en lugar de a una entidad. Se representan con un óvalo conectado al rombo de la relación. Por ejemplo, en la relación Alquila entre Cliente y Coche, el atributo Fecha de alquiler pertenece a la relación.

Identificadores

Aunque en algunos casos particulares no es necesario, toda entidad debe tener un identificador que permita distinguir de forma única cada una de sus instancias. Este identificador puede estar compuesto por uno o varios atributos.

Podemos tener los siguientes tipos de identificadores:

Identificador simple: Está compuesto por un solo atributo. Por ejemplo, el DNI de un Empleado.
Identificador compuesto: Está compuesto por varios atributos. Por ejemplo, en una entidad Curso, el identificador puede estar compuesto por Código del curso y Año académico.
Atributos candidatos: Son aquellos atributos que pueden servir como identificadores, pero no se utilizan como tal. Por ejemplo, en una entidad Empleado, tanto el DNI como el Número de empleado pueden ser candidatos a identificadores, pero solo uno se utiliza como identificador principal. Elegiremos el más adecuado según el contexto. Se representan con un óvalo simple y el nombre subrayado con una linea discontinua.
Identificador artificiales: En el caso de que no exista un identificador, crearemos un nuevo atributo que sirva como tal, por ejemplo, un codigo o id.
Atributos complementados con otra entidad: En algunos casos, una entidad puede no tener un identificador propio y depender de otra entidad para su identificación. En este caso, el identificador de la entidad dependiente se complementa con el identificador de la entidad de la que depende. Por ejemplo, en una entidad Familiar que depende de un Cliente, el identificador puede estar compuesto por el id_cliente del Cliente y un id_familiar. Son atributos que crean una relación de dependencia entre entidades.

Los identificadores son fundamentales para garantizar la integridad de los datos en una base de datos, ya que permiten distinguir entre diferentes instancias de una entidad y facilitan la búsqueda y recuperación de información. Son únicos, no nulos y estables a lo largo del tiempo.

Por ejemplo, en una entidad Usuarios, tenemos los siguientes atributos:

Usuarios (usuario, nombre, email, fecha_registro, telefono)

El atributo usuario es el identificador único de la entidad, ya que cada usuario tiene un nombre de usuario distinto. Los demás atributos (nombre, email, fecha_registro, telefono) proporcionan información adicional sobre cada usuario, pero no son necesarios para identificarlo de manera única. El atributo email podría ser un atributo candidato, ya que también podría servir como identificador único, pero podemos permitir que un usuario cambie su email, por lo que no es tan estable como el nombre de usuario.

Cuándo NO es necesario añadir un identificador artificial

Cuando ya existe una clave natural, simple y estable.
Cuando la tabla es pequeña y no se relaciona con otras.

Cuándo es recomendable añadir un identificador artificial

Cuando no hay un atributo natural que garantice unicidad fácilmente. Por ejemplo, el nombre o el teléfono pueden repetirse, y aunque el email suele ser único, podrían cambiarlo con el tiempo.
Cuando otras tablas van a referenciar a Usuario (por ejemplo, Pedidos, Mensajes, etc.). Tener un id_usuario simplifica las claves foráneas y mejora el rendimiento de joins.
Cuando quieres flexibilidad futura. Por ejemplo, si algún día cambias la política de emails o nombres, tu clave primaria artificial (id_usuario) no se ve afectada.
Cuando la clave natural es larga o sensible. Usar un email como clave primaria puede ralentizar joins y exponer datos sensibles en logs.

Restricciones

Las restricciones son reglas que se aplican a las entidades y relaciones en un modelo ER para garantizar la integridad y coherencia de los datos. Estas restricciones pueden afectar a los atributos, entidades o relaciones.

Existencia e Identificación

En el apartado de entidades hemos visto que tenemos entidades fuertes y débiles, y que las entidades débiles tienen una restricción de identificación que las vincula a una entidad fuerte. Además, las entidades débiles tienen una restricción de existencia que también las vincula a una entidad fuerte:

En las entidades débiles, la existencia de una instancia de la entidad depende de la existencia de una instancia de otra entidad. Esto significa que una entidad débil no puede existir sin estar asociada a una entidad fuerte. En esta caso, la cardinalidad mínima de la relación entre la entidad débil y la entidad fuerte es 1. Por ejemplo, una instancia de Familiar no puede existir sin estar asociada a una instancia de Cliente.
En las entidades débiles, la identificación de una instancia de la entidad depende de la identificación de una instancia de otra entidad. Esto significa que una entidad débil no puede ser identificada de manera única sin la referencia a la entidad fuerte. En este caso, el identificador de la entidad débil se complementa con el identificador de la entidad fuerte. Por ejemplo, para identificar un Familiar concreto, necesitas saber a qué Cliente pertenece. Es muy común que la relación entre la entidad débil y la entidad fuerte sea de tipo 1:n, donde una instancia de la entidad fuerte puede estar asociada con múltiples instancias de la entidad débil.

Perdida expresiva

En algunos casos, los modelos conceptuales pueden tener limitaciones que dificultan la representación precisa de ciertas restricciones o reglas de negocio. Esto se conoce como pérdida expresiva.

Algunos ejemplos comunes de pérdida expresiva incluyen: "Todo cliente debe tener al menos un pedido activo", "Un empleado solo puede supervisar a empleados de su mismo departamento" o "El número de alumnos matriculados en una asignatura debe ser menor o igual a 30".

Este tipo de restricciones no se pueden representar directamente en un diagrama ER, ya que requieren lógica adicional o reglas de negocio que van más allá de la estructura básica del modelo. Para evitar la pérdida expresiva, es posible utilizar técnicas adicionales como anotaciones al pie del diagrama.

Modelo Entidad/Relación extendido

El modelo Entidad/Relación extendido (EER) es una ampliación del modelo Entidad/Relación (ER) que introduce conceptos adicionales para representar de manera más precisa y detallada la estructura de una base de datos. El modelo EER incluye características como la generalización, especialización y agregación.

Generalización

La generalización es el proceso de identificar atributos y relaciones comunes entre varias entidades y agruparlas en una entidad más general. Esto permite reducir la redundancia y simplificar el modelo. Por ejemplo, si tenemos las entidades Empleado y Cliente, ambas pueden tener atributos comunes como Nombre, Dirección y Teléfono. Podemos generalizar estas entidades en una entidad más general llamada Persona. Derivado de esto, aparecen los conceptos de superclase y subclase.

Superclase: Es la entidad más general que agrupa atributos y relaciones comunes. En el ejemplo anterior, Persona sería la superclase.
Subclase: Son las entidades más específicas que heredan atributos y relaciones de la superclase. En el ejemplo anterior, Empleado y Cliente serían subclases de Persona.

Evidentemente, una instancia de una subclase debe tener asociada una instancia de la superclase.

Generalización vs Especialización

La generalización y la especialización son procesos opuestos pero complementarios en el modelado de datos. La generalización agrupa entidades específicas en una entidad más general, mientras que la especialización divide una entidad general en entidades más específicas. Ambos procesos ayudan a organizar y estructurar los datos de manera eficiente, pero desde perspectivas diferentes.

En la generalización/especialización, las características de la entidad superclase se propagan hacia las entidades subclase. Esto se denomina herencia de propiedades.

Tipos de especialización

Existen dos tipos principales de especialización:

Total: Cada instancia de la superclase debe pertenecer a al menos una subclase. Esto significa que no puede haber instancias de la superclase que no estén asociadas con ninguna subclase. Se representa con un círculo entre la superclase y el triángulo de especialización.
Parcial: Algunas instancias de la superclase pueden no pertenecer a ninguna subclase. Esto significa que puede haber instancias de la superclase que no estén asociadas con ninguna subclase. Se representa sin un círculo entre la superclase y el triángulo de especialización.

Además, la especialización puede ser de dos tipos según la pertenencia a las subclases:

Exclusiva: Una instancia de la superclase solo puede pertenecer a una subclase. Esto significa que no puede haber instancias de la superclase que estén asociadas con múltiples subclases. Se representa con un arco que corta las líneas que conectan la superclase con el triángulo de especialización.
No exclusiva o solapada: Una instancia de la superclase puede pertenecer a múltiples subclases. Esto significa que puede haber instancias de la superclase que estén asociadas con múltiples subclases. Se representa sin un arco que corte las líneas que conectan la superclase con el triángulo de especialización.

Diseño lógico

El diseño lógico es el proceso de transformar el modelo conceptual (Entidad/Relación) en un modelo lógico que pueda ser implementado en un sistema de gestión de bases de datos (SGBD). Este proceso implica la conversión de entidades, relaciones y atributos en tablas, columnas y claves primarias/foráneas. El diseño lógico también incluye la normalización de la base de datos para eliminar redundancias y mejorar la integridad de los datos.

Para llevar a cabo el diseño lógico se emplea por excelencia el modelo relacional, que representa los datos en forma de tablas (relaciones) con filas (tuplas) y columnas (atributos). Cada tabla tiene una clave primaria que identifica de manera única cada fila, y las claves foráneas se utilizan para establecer relaciones entre tablas.

Notación del modelo relacional

Para representar el modelo relacional, utilizaremos una notación textual que facilita la comprensión y el diseño. A esta representación se le conoce como esquema relacional.

Para representar una tabla en el esquema relacional ponemos el nombre de la tabla seguido de los atributos entre paréntesis. El identificador único (clave primaria) se subraya.

Tras el listado de atributos:

Se indica la clave primaria (PK) con los atributos que la componen.
Se indican las claves foráneas (FK) con los atributos que las componen y la tabla a la que hacen referencia.
Se indican otras propiedades relevantes, como restricciones de unicidad, no nulos, etc.

La sintaxis general es la siguiente:

Tabla_Nombre(codigo, Atributo1, Atributo2, ...)

PK: (Atributo1, Atributo2, ...)
FK: (AtributoX) -> Tabla_OtraTabla(AtributoY)
Otras propiedades: (Únicas, No Nulos, etc.)

Por ejemplo, para una tabla Empleado con los atributos DNI, Nombre, Fecha_Nacimiento, Salario y Departamento, donde DNI es la clave primaria y Departamento es una clave foránea que hace referencia a la tabla Departamento, donde el tipo de relación es 1:N, el esquema relacional sería:

Empleado(DNI, Nombre, Fecha_Nacimiento, Salario, Departamento)

PK: (DNI)
FK: (Departamento) -> Departamento(Nombre)

Departamento(Nombre, Numero_Despacho)

PK: (Nombre)

Diagrama relacional

La notación textual mediante un esquema relacional es sencilla para nuestro propósito, pero existen otras notaciones gráficas para representar el modelo relacional. Por ejemplo, se esta popularizando https://dbdiagram.io/ que permite crear diagramas relacionales de forma visual e intuitiva. Mediante un lenguaje de definición de datos (DDL) sencillo, se pueden definir tablas, atributos, claves primarias y foráneas, y relaciones entre tablas. La herramienta genera automáticamente un diagrama visual que representa la estructura de la base de datos.

Por ejemplo, el esquema relacional anterior se representaría en dbdiagram.io de la siguiente manera:

Table Empleado {
  DNI varchar [pk]
  Nombre varchar
  Fecha_Nacimiento date
  Salario decimal
  Departamento varchar [ref: > Departamento.Nombre]
}
Table Departamento {
  Nombre varchar [pk]
  Numero_Despacho int
}

Donde su representación gráfica sería:

Normalización

La normalización es un proceso utilizado en el diseño de bases de datos para organizar los datos de manera eficiente y reducir la redundancia. El objetivo principal de la normalización es garantizar que cada tabla en la base de datos cumpla con ciertas reglas o formas normales (normal forms) que mejoran la integridad y consistencia de los datos.

La normalización se lleva a cabo mediante una serie de pasos que implican la descomposición de tablas en tablas más pequeñas y la eliminación de dependencias funcionales no deseadas. Las formas normales más comunes son:

Primera forma normal (1NF): Una tabla está en 1NF si todos sus atributos contienen valores atómicos (indivisibles) y no hay grupos repetitivos. Esto significa que cada celda de la tabla debe contener un solo valor y cada fila debe ser única.
Segunda forma normal (2NF): Una tabla está en 2NF si está en 1NF y todos sus atributos no clave dependen completamente de la clave primaria. Esto significa que no debe haber dependencias parciales, donde un atributo no clave depende solo de una parte de la clave primaria.
Ejemplos

student_id course_id student_name course_name grade

1 101 Ana Pérez Matemáticas 9

1 102 Ana Pérez Física 8

2 101 Luis Gómez Matemáticas 7

En este ejemplo, la tabla no está en 2NF porque el atributo student_name depende solo de student_id, que es una parte de la clave primaria compuesta (student_id, course_id). Para normalizar esta tabla a 2NF, podemos descomponerla en dos tablas: Students y Enrollments.

Students(student_id, student_name)
- PK: (student_id)
Course(course_id, course_name)
- PK: (course_id)
Enrollments(student_id, course_id, grade)
- PK: (student_id, course_id)
- FK: (student_id) -> Students(student_id)
- FK: (course_id) -> Course(course_id)
Otro ejemplo que si está en 2NF:

order_id product_id quantity price_per_unit

1 101 2 10.00

1 102 1 20.00

2 101 3 10.00

En este caso, la tabla está en 2NF porque todos los atributos no clave (quantity, price_per_unit) dependen completamente de la clave primaria compuesta (order_id, product_id). No hay dependencias parciales.
Tercera forma normal (3NF): Una tabla está en 3NF si está en 2NF y no tiene dependencias transitivas. Esto significa que ningún atributo no clave debe depender de otro atributo no clave.
Ejemplos

employee_id department_id department_name employee_name

1 10 Ventas Carlos López

2 20 Marketing Ana García

3 10 Ventas Luis Martínez

En este ejemplo, la tabla no está en 3NF porque el atributo department_name depende de department_id, que es un atributo no clave. Para normalizar esta tabla a 3NF, podemos descomponerla en dos tablas: Departments y Employees.

Departments(department_id, department_name)
- PK: (department_id)
Employees(employee_id, department_id, employee_name)
- PK: (employee_id)
- FK: (department_id) -> Departments(department_id)
Otro ejemplo que si está en 3NF:

student_id course_id grade

1 101 9

1 102 8

2 101 7

En este caso, la tabla está en 3NF porque no hay dependencias transitivas entre los atributos no clave. El atributo grade depende directamente de la clave primaria compuesta (student_id, course_id).

La normalización es un proceso iterativo que puede continuar más allá de la 3NF, pero en la práctica, la mayoría de las bases de datos se normalizan hasta la 3NF para lograr un equilibrio entre la eficiencia y la complejidad del diseño.

Ejemplo de normalización

Analicemos un ejemplo sencillo para ilustrar el proceso de normalización:

Supongamos que tenemos una tabla Pedidos con los siguientes atributos y valores de ejemplo:

PedidoID	ClienteNombre	ClienteDireccion	Producto	Cantidad
1	Juan Pérez	Calle Falsa 123	Manzanas	10
2	María López	Avenida Siempreviva 456	Naranjas	5
3	Juan Pérez	Calle Falsa 123	Plátanos	7
4	Carlos Ruiz	Calle Luna 789	Manzanas	3

1FN En este caso, la tabla Pedidos no está en 1NF porque el atributo ClienteDireccion contiene valores repetitivos para el mismo cliente. Para normalizar esta tabla, podemos descomponerla en dos tablas: Clientes y Pedidos.

Clientes(ClienteID, Nombre, Direccion)

PK: (ClienteID)
UK: (Nombre)
NOT NULL: (Nombre, Direccion)

Pedidos(PedidoID, ClienteID, Producto, Cantidad)

PK: (PedidoID)
FK: (ClienteID) -> Clientes(ClienteID)
NOT NULL: (Producto, Cantidad)

En este ejemplo, hemos eliminado la redundancia al separar la información del cliente en una tabla independiente. Ahora, cada cliente tiene un identificador único (ClienteID), y la tabla Pedidos hace referencia a los clientes mediante una clave foránea. Esto mejora la integridad de los datos y facilita la gestión de la información.

2FN Verificamos ahora si las tablas cumplen con la 2NF. En este caso, ambas tablas ya están en 2NF porque todos los atributos no clave dependen completamente de la clave primaria.

3FN Verificamos ahora si las tablas cumplen con la 3NF. En este caso, ambas tablas ya están en 3NF porque no hay dependencias transitivas entre los atributos no clave.

Transformación de un modelo ER a un modelo relacional

La transformación de un modelo Entidad/Relación (ER) a un modelo relacional implica convertir las entidades, relaciones y atributos del modelo ER en tablas, columnas y claves primarias/foráneas en el modelo relacional. A continuación, se describen los pasos generales para llevar a cabo esta transformación.

Entidades y atributos

Cada entidad en el modelo ER se convierte en una tabla en el modelo relacional. Los atributos de la entidad se convierten en columnas de la tabla. El identificador único de la entidad se convierte en la clave primaria de la tabla.

Relaciones

Las relaciones entre entidades se pueden transformar de diferentes maneras según el tipo de relación. Ademas, los atributos de la relación se convierten en columnas de la tabla correspondiente.

Relación 1:N

En una relación uno a muchos (1:N), la clave primaria de la entidad del lado "uno" se convierte en una clave foránea en la tabla de la entidad del lado "muchos".

Por ejemplo, en una relación entre las entidades A y B, donde A está en el lado "muchos" y B en el lado "uno", la transformación sería la siguiente:

A (a0, a1, b0*)

PK: (a0)
FK: (b0) → B(b0)

B (b0, b1)

PK: (b0)

Relación 1:1

En una relación uno a uno (1:1), la clave primaria de una de las entidades se convierte en una clave foránea en la tabla de la otra entidad. La elección de qué entidad utilizar depende del contexto y las reglas de negocio, pero normalmente se elige la entidad que tiene una dependencia más fuerte o que es más lógica desde el punto de vista del diseño. En cualquier caso, la clave ajena se debe definir con una restricción de unicidad (UK) para asegurar que la relación siga siendo 1:1.

Una posbile solucion seria llevar la clave ajena a A:

A (a0, a1, b0*)

PK: (a0)
FK: (b0) → B(b0)
UK: (b0)

B (b0, b1)

PK: (b0)

La otra posible solución seria llevar la clave ajena a B:

A (a0, a1)

PK: (a0)

B (b0, b1, a0*)

PK: (b0)
FK: (a0) → A(a0)
UK: (a0)

Relación N:M

En una relación muchos a muchos (N:M), se crea una tabla intermedia que contiene las claves primarias de ambas entidades como claves foráneas. Esta tabla intermedia puede tener su propia clave primaria compuesta por las claves foráneas, y puede incluir atributos adicionales que pertenezcan a la relación(fechas, ordenes u otros códigos) que permitan describir mejor la relación entre las entidades.

Por ejemplo, en una relación entre las entidades A y B, la transformación sería la siguiente:

A (a0, a1) * PK: (a0)

B (b0, b1)

PK: (b0)

R (a0, b0)

PK: (a0, b0)
FK: (a0) → A(a0)
FK: (b0) → B(b0)

En la situación de que la relación N:M tenga atributos adicionales temporales, se debe incluir como clave primaria algo de ellos para evitar duplicados. Este tipo de situaciones son comunes en relaciones de alquiler, reservas u órdenes.

R (a0, b0, fecha_inicio, fecha_fin)

PK: (a0, b0, fecha_inicio)
FK: (a0) → A(a0)
FK: (b0) → B(b0)

Relación reflexiva

En una relación reflexiva, donde una entidad se relaciona consigo misma, se crea una tabla que contiene la clave primaria de la entidad como clave foránea dos veces, una para cada rol en la relación. Es importante definir los roles para clarificar la relación entre las instancias de la entidad.

Por ejemplo, en una relación reflexiva de la entidad A, la transformación sería la siguiente:

A (a0, a1, a0r*, r0)

PK: (a0)
FK: (a0r) → A(a0)

En el caso de que la entidad tenga una clave primaria compuesta, se debe incluir toda la clave primaria en la clave foránea:

A (a0, a1, a2, a0r, a1r, r0)

PK: (a0, a1)
FK: (a0r, a1r) → A(a0, a1)

Generalización y especialización

En la transformación de una generalización o especialización, se pueden seguir diferentes enfoques según el contexto y las reglas de negocio. A continuación, se describen dos enfoques comunes:

Tabla por superclase y subclase

En este enfoque, se crea una tabla para la superclase que contiene los atributos comunes, y una tabla para cada subclase que contiene los atributos específicos de cada subclase. La tabla de la superclase incluye una clave primaria que se utiliza como clave foránea en las tablas de las subclases.

A (a0, a1)

PK: (a0)

B (a0*, b1, b2)

PK: (a0)
FK: (a0) → A(a0)

C (a0*, c1, c2)

PK: (a0)
FK: (a0) → A(a0)

Tabla por subclase

En este enfoque, se crea una tabla para cada subclase que contiene tanto los atributos comunes como los específicos de cada subclase. Cada tabla de subclase tiene su propia clave primaria.

B (a0, a1, b1, b2)

PK: (a0)

C (a0, a1, c1, c2)

PK: (a0)

Actividades

A3.1. Identificación de entidades, relaciones y cardinalidades

Dada la siguiente descripción, identifica las entidades, relaciones y cardinalidades involucradas:

"Una biblioteca gestiona libros y socios. Cada socio puede tomar prestados varios libros, pero cada libro solo puede ser prestado a un socio a la vez."
"Una empresa tiene empleados y proyectos. Cada empleado puede trabajar en varios proyectos, y cada proyecto puede tener varios empleados asignados."
"Un hospital tiene pacientes y médicos. Cada paciente puede ser atendido por varios médicos, pero cada médico solo puede atender a un paciente a la vez."
"Una universidad tiene estudiantes y cursos. Cada estudiante puede inscribirse en varios cursos, y cada curso puede tener varios estudiantes inscritos."
"Una tienda tiene productos y proveedores. Cada producto puede ser suministrado por varios proveedores, pero cada proveedor solo puede suministrar un producto a la vez."
"Una agencia de viajes tiene clientes y destinos. Cada cliente puede reservar varios destinos, y cada destino puede ser reservado por varios clientes."
"Un gimnasio tiene miembros y clases. Cada miembro puede asistir a varias clases, pero cada clase solo puede tener un miembro a la vez."
"Una empresa de transporte tiene conductores y vehículos. Cada conductor puede manejar varios vehículos, y cada vehículo puede ser manejado por varios conductores."
"Un restaurante tiene mesas y camareros. Cada mesa puede ser atendida por varios camareros, pero cada camarero solo puede atender a una mesa a la vez."
"Una escuela tiene profesores y asignaturas. Cada profesor puede enseñar varias asignaturas, y cada asignatura puede ser enseñada por varios profesores."

A3.2. Empresa I

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.

Ademas, un empleado es jefe de un único departamento.

Realiza un diagrama Entidad/Relación que represente esta información, indicando las entidades, atributos, relaciones y cardinalidades correspondientes.

A3.3. 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.

A3.4. Empresa II

Vamos a ampliar el sistema de información de Empresa I del apartado A3.2 para almacenar más información. El nuevo sistema es:

La empresa está organizada en departamentos. Cada uno tiene un nombre único, el número del despacho en el que se ubica y un empleado que lo dirige. Nos interesa la fecha que empezó a dirigirlo.

Cada departamento controla una serie de proyectos, los cuales tienen nombre y número únicos.

De cada empleado nos interesa el DNI, nombre, fecha de nacimiento, salario y departamento en el que trabaja. Cada empleado puede trabajar en más de un proyecto, dedicándole un determinado número de horas a la semana en cada proyecto.

Finalmente, queremos guardar también los familiares de cada empleado, para administrar información relativa a las pólizas de seguros. De los familiares, queremos saber el nombre, fecha de nacimiento y parentesco con el empleado.

A3.5. 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.

A3.6. Notatic I

Notatic es una aplicación para la gestión y el seguimiento de sesiones de formación académica. La aplicación tiene muchas funcionalidades, entre ellas, la gestión de cursos, materias y estudiantes. Se pide diseñar el modelo Entidad/Relación para gestionar toda esta información, teniendo en cuenta las siguientes condiciones:

Los cursos académicos tienen un nombre, por ejemplo, "Curso 2023-2024".
Las materias son las asignaturas que se imparten en los cursos. Cada materia solo puede puede pertenecer a un curso académico. De cada materia nos interesa almacenar su nombre, abreviatura y número de horas totales.
Los estudiantes pueden matricularse en varias materias, y cada materia puede tener varios estudiantes matriculados. De cada estudiante nos interesa almacenar su nombre completo, DNI y dirección de correo electrónico.
Las materias están compuestas por Unidades de Trabajo (UT). Cada UT tiene un nombre, y número de horas (sesiones). Una unidad de trabajo solo puede pertenecer a una materia, aunque una materia puede no tener unidades de trabajo definidas.
Para hacer un seguimiento, los profesores poseen una agenda para cada materia. En esta agenda pueden anotar una descripción de cada sesión. Cada sesión puede estar asociada o no a una única unidad de trabajo. Además, cada sesión tiene una fecha y hora programada, asi como el orden en el que se imparte dentro de la materia.

A3.7. Normalización

Realiza la normalización, paso a paso hasta la 3FN, indicando en cada uno de ellos las tablas resultantes y sus datos, de los siguientes supuestos:

Un tabla que contiene la información de estudiantes y los cursos en los que se matricula, la cual tiene la siguiente información:

idEstudiante nomEstudiante cursos

134 Javier Hernández Matemáticas, Biología, Física

178 Sonia Tovar Biología, Informática

249 Juani Moya Informática, Matemáticas

Una tabla que contiene información de productos y sus proveedores

idProducto	nomProducto	nomProveedor	telefProveedor	categoría
1234	Tela de araña	Spiderman	666000000	Consumible
3378	Máquina del Tiempo	Dr Who	777000000	Vehículo
2549	Varita Mágica	Harry Potter	888000000	Herramienta

A3.8. Transformación ER a MR

Dado los siguientes modelos Entidad/Relación, realiza la transformación a un modelo relacional, indicando las tablas resultantes, sus atributos y claves primarias/foráneas.

Contenido

student_id	course_id	student_name	course_name	grade
1	101	Ana Pérez	Matemáticas	9
1	102	Ana Pérez	Física	8
2	101	Luis Gómez	Matemáticas	7

employee_id	department_id	department_name	employee_name
1	10	Ventas	Carlos López
2	20	Marketing	Ana García
3	10	Ventas	Luis Martínez

idEstudiante	nomEstudiante	cursos
134	Javier Hernández	Matemáticas, Biología, Física
178	Sonia Tovar	Biología, Informática
249	Juani Moya	Informática, Matemáticas

order_id	product_id	quantity	price_per_unit
1	101	2	10.00
1	102	1	20.00
2	101	3	10.00