01 Tema1 DisenoBDRelacionales

Diseño de bases de datos relacionales
Tema 1
1. Introducción .................................................................................................................. 2
2. Modelo Entidad-Relación.............................................................................................. 2
2.1. Diagrama E-R ......................................................................................................... 3
2.2 Relaciones binarias ................................................................................................ 4
2.2.1 Relación 1:1 ..................................................................................................... 4
2.2.2 Relación 1:M .................................................................................................... 4
2.2.3 Relación M:M ................................................................................................... 5
2.3 Representación del modelo E-R en tablas ............................................................. 6
2.4 Clave primaria o principal ....................................................................................... 7
2.5 Clave ajena ............................................................................................................. 8
3. Transformación del diagrama ER al modelo relacional .............................................. 12
3.1 Relación 1:1 .......................................................................................................... 12
3.2 Relación 1:M ......................................................................................................... 12
3.3 Relación M:M ........................................................................................................ 13
3.4 Restricción de existencia ...................................................................................... 14
3.5 Restricción de identidad ....................................................................................... 16
3.6 Generalización y especialización .......................................................................... 17
4. Agregación ................................................................................................................. 20
5. Relaciones ternarias ................................................................................................... 21
5.1 Relación 1:1:1 ....................................................................................................... 21
5.2 Relación 1:1:M ...................................................................................................... 22
5.3 Relación 1:M:M ..................................................................................................... 23
5.4 Relación M:M:M .................................................................................................... 24
©Yolanda Marhuenda 1 / 25
1. Introducción
Un sistema de gestor de bases de datos (SGBD) consiste en un conjunto de datos
relacionados entre sí y un grupo de herramientas para acceder a esos datos mediante las
cuales se puede modificar, borrar, añadir, consultar, obtener información, … El conjunto de
datos del sistema se llama base de datos.
El proceso de diseño de una base de datos consiste en representar una parte del mundo
real mediante los objetos que proporciona un modelo de datos.
Para realizar este proceso en primer lugar se debe realizar una abstracción del mundo real
y acotar la parcela del mundo exterior que nos interesa representar, es decir, identificar los
objetos, las propiedades de cada uno de ellos que sean relevantes dentro del contexto en
el que se sitúe el problema y las relaciones entre los objetos. En este primer paso se debe
aprender, comprender y conceptualizar dicho mundo transformándolo en un conjunto de
ideas y definiciones que supongan una imagen fiel del comportamiento. Esta imagen recibe
el nombre de “modelo conceptual”.
El modelo conceptual se representa por medio de un modelo de datos. Un modelo de datos

es una herramienta conceptual (objetos y reglas) que se utiliza para representar la realidad
y para describir los datos, sus relaciones, su semántica y sus limitaciones. En este tema se
tratará el modelo entidad-relación por ser uno de los más extendidos.
A partir del modelo conceptual, se realiza la descripción de datos, atributos y relaciones que
recibe el nombre de “esquema conceptual de datos” y es la forma mediante la que se define
el modelo conceptual.
Finalmente, se debe transformar el esquema conceptual de datos a estructuras

almacenables en soportes físicos.
Mundo
Mundo de
real las ideas Mundo
físico
Figura 1: Proceso de abstracción de la información.
2. Modelo Entidad-Relación
Cuando se diseña una base de datos mediante un modelo relacional, al igual que ocurre
con otros modelos de datos, se tienen distintas alternativas, es decir, se pueden obtener
diferentes esquemas relacionales y no todos ellos son equivalentes, ya que unos van a
representar la realidad mejor que otros. El proceso de diseño es creativo y la habilidad para
diseñar bases de datos se adquiere con un largo entrenamiento y sintetizando los
resultados de experiencias anteriores en situaciones nuevas.
En el modelo de datos Entidad-Relación se utilizan los siguientes conceptos:
• Entidad: objeto distinguible del mundo real (alumno, asignatura)

• Relación: asociación entre entidades (los alumnos se matriculan de asignaturas)
• Atributo: propiedad de una entidad o de una relación (dni, nombre, número de
créditos)
2.1. Diagrama E-R

Para representar gráficamente la estructura lógica de una base de datos según el modelo
Entidad-Relación se utiliza el diagrama E-R, que ofrece una manera sencilla y comprensible
de comunicar los rasgos más destacados del diseño de cualquier base de datos. Las
representaciones gráficas de cada uno de los conceptos de este modelo para construir un
diagrama E-R son las siguientes:
Concepto Representación
Entidad Rectángulo etiquetado

con el nombre de la
NOMBRE ENTIDAD ALUMNO
entidad.
Atributo Elipse etiquetada con

el nombre del atributo. nombre atributo dni
Cada atributo va unido
por una línea a la
entidad o relación a la
que pertenezca. ALUMNO
Relación Rombo o triángulo

(dependiendo del NOMBRE RELACIÓN
número de entidades
participantes, dos o ENTIDAD 1 ENTIDAD 2
tres respectivamente)
etiquetado con el
nombre de la relación
y sombreado según el
tipo de relación ENTIDAD 1
existente entre las
entidades. Cada
entidad participante en
la relación se une por NOMBRE
una línea al rombo o RELACIÓN
al triángulo.
ENTIDAD 2 ENTIDAD 3
En nuestro caso los nombres de las entidades y relaciones los escribiremos en mayúsculas
y los de los atributos en minúsculas.
2.2 Relaciones binarias

Las relaciones se pueden clasificar según el número de entidades que participan en la
misma, así se distinguen relaciones unarias, binarias, ternarias, cuaternarias, etc. en las
que participan una, dos, tres y cuatro entidades, respectivamente. Normalmente no suele
haber más de dos o tres entidades involucradas en una relación.
Cada tipo de relación se representa con un icono. En el caso de las relaciones unarias y
binarias se utiliza un rombo, para las ternarias un triángulo y para las cuaternarias un
cuadrado.
Con respecto a las relaciones binarias se puede diferenciar tres tipos atendiendo al número
de ocurrencias/registros de cada entidad que se encuentren relacionadas con la otra
entidad. En las siguientes secciones se especifican cada uno de los tipos.
2.2.1 Relación 1:1
• 1 tupla 1 de la entidad A está relacionada con 1 sola tupla de la entidad B y

• 1 tupla de la entidad B está relacionada con 1 sola tupla de la entidad A.
Representación:
Ejemplo:
• 1 profesor solamente puede impartir una asignatura.
• 1 asignatura solamente puede ser impartida por un profesor.
2.2.2 Relación 1:M
• 1 tupla de la entidad A está relacionada con muchas tuplas de la entidad B y

• 1 tupla de la entidad B está relacionada con 1 tupla de la entidad A.
1
ocurrencia de una entidad, fila, registro de la tabla.
Representación:
Ejemplo:
• 1 profesor puede impartir muchas asignaturas.
• 1 asignatura solamente puede ser impartida por un profesor.
Ejemplo:
• 1 profesor solamente puede impartir una asignatura.
• 1 asignatura puede ser impartida por muchos profesores.
2.2.3 Relación M:M
• 1 tupla de la entidad A está relacionada con muchas de la entidad B y

• 1 tupla de la entidad B está relacionada con muchas de la entidad A
Representación:
Ejemplo:
• 1 profesor puede impartir muchas asignaturas.
• 1 asignatura puede ser impartida por muchos profesores.
2.3 Representación del modelo E-R en tablas

En el modelo relacional, el SGBD estructura la información por medio de tablas con
columnas. Cada entidad y en algunos casos las relaciones se representan mediante una
tabla. Los atributos de la entidad serán las columnas de la tabla. Cada una de las columnas
o atributos también recibe el nombre de campo. Por otro lado, cada tabla tendrá tantas filas
o registros como número de ocurrencias (tuplas) de la entidad o la relación a la que
representa.
Ejemplo:
Se quiere guardar información sobre los actores que actúan en las películas, de manera
que un actor puede actuar en muchas películas y en una película pueden actuar muchos
actores. De cada actor se quiere guardar el dni, nombre, fecha de nacimiento, primer y
segundo apellidos, nacionalidad y cuál es el sueldo que cobra en cada película en la que
ha actuado. De las películas se guarda un código identificativo, el título, duración, tipo de
película y fecha de estreno.
El siguiente diagrama E-R representa el comportamiento del sistema de información

descrito.
dni nombre código título
fecha ACTUAR
nacimiento
duración
ACTOR PELICULA
apellido1
sueldo tipo
apellido2
nacionalidad fecha
La representación de la entidad ACTOR en forma de tabla es la siguiente:
ACTOR
dni nombre apellido1 apellido2 fecha nacimiento nacionalidad
11222333A Antonio González Pérez 20/01/1940 España
22000111B Sofía Huertas Martínez 30/10/1970 España
33444555C John Smith 25/07/1965 Gran Bretaña
22666777D Philippe Rauer 27/06/1978 Francia
2.4 Clave primaria o principal

Es un identificador único para la entidad, de forma que conocida la clave primaria se podrá
acceder unívocamente a la ocurrencia asociada o fila de la tabla. La clave primaria puede
estar formada por un solo atributo o, en caso de que sea insuficiente para identificar a la
fila, se irán añadiendo más atributos hasta conseguir identificarla unívocamente, de forma
que nunca existan dos filas de la tabla con el mismo valor en el atributo o combinación de
atributos que constituyen la clave primaria.
Para representar la clave primaria en el diagrama E-R utilizaremos el formato negrita y

subrayado en los atributos que forman parte de la misma.
Ejemplo:
En el sistema de información anterior en el que se especifica la relación actuar entre actores

y películas, la clave primaria de la entidad ACTOR es el atributo dni porque identifica
unívocamente a cada actor (es único), ya que a partir de un dni se obtienen los datos de un
único actor. Para la entidad PELICULA se ha asignado un campo código que será único
para cada película y por ejemplo no se ha elegido como clave primaria el atributo título
porque puede ocurrir que existan películas con el mismo título.
¿Cómo elegir la clave primaria?
En una entidad/relación es posible que haya diferentes atributos que puedan actuar como
clave primaria. Por ejemplo, para una persona podría ser clave primaria el dni o el número
de la seguridad social. En este caso la entidad tiene varias claves candidatas y hay que
escoger una de ellas como clave primaria. Las claves candidatas que no son primarias se
denominan claves alternativas.
Para una entidad/relación A con un conjunto de atributos, diremos que C, subconjunto de

los atributos de A, es clave candidata si cumple:
• unicidad: no existen dos tuplas (filas o registros) con los mismos valores para cada uno
de los atributos que pertenecen a la clave candidata C.
• minimalidad: si C es compuesta, es decir, está formada por más de un atributo, no

existe ningún atributo de C que pueda ser eliminado sin destruir la propiedad de
unicidad.
Se elige como clave primaria aquella clave candidata formada por el menor número de
atributos.
Los atributos de la clave primaria deben cumplir la regla de integridad, que exige que ningún
componente de la clave pueda aceptar nulos. Esto es debido a que no se registrará
información sobre algo que no se puede identificar.
2.5 Clave ajena

Las claves ajenas se utilizan para relacionar las tablas de la base de datos. Si una entidad
B tiene una clave ajena a una entidad A, indica que B está relacionada con A y B contendrá
uno o varios atributos cuyos valores deben concordar con los atributos que constituyen la
clave primaria de A (donde A y B no son necesariamente distintos).
Una base de datos no debe contener valores de clave ajena sin concordancia, es decir, un
valor no nulo de clave ajena para el que no exista concordancia con la clave primaria de la
tabla a la que hace referencia. Si B referencia a A, entonces A debe existir. Esto se conoce
con el nombre de integridad referencial y se refiere al hecho de que hay que asegurar que
la base de datos no incluya valores no válidos de una clave ajena.
Ejemplo:
Supongamos la siguiente relación en la que un empleado pertenece a un departamento y

un departamento puede contener muchos empleados.
dni nombre código nombre
apellido1 EMPLEADO DEPARTAMENTO
PERTENECER
apellido2
Las tablas correspondientes a las entidades EMPLEADO y DEPARTAMENTO antes de

establecer la relación PERTENECER son:
EMPLEADO DEPARTAMENTO
dni nombre apellido1 apellido2 código nombre
11111111X Juan Fernández Vivó ADM Administración
22222222D Patricia Torres Rocamora INF Informática
33333333F Alberto Guillén Navas COM Comercial
44444444H Pablo López García
55555555F José Valdés Lozano
66666666B Sandra García García
77777777L Nuria Molina Martínez
Supongamos que la distribución de empleados por departamentos es la siguiente:
• Administración: Patricia Torres y Nuria Molina.

• Informática: Juan Fernández, Pablo López y Sandra García.
• Comercial: Alberto Guillén y José Valdés.
En este caso para reflejar la relación PERTENECER hay que añadir a la tabla EMPLEADO
un nuevo atributo, que llamaremos por ejemplo “depto”, para indicar a qué departamento
pertenece cada empleado. El atributo “depto” es una clave ajena a la tabla
DEPARTAMENTO y los valores que se incluyan en este campo deben referenciar a algún
departamento existente y concretamente a valores de la clave principal de algún registro de
la entidad DEPARTAMENTO.
Así, los datos contenidos en la tabla EMPLEADO serán:
EMPLEADO
dni nombre apellido1 apellido2 depto
11111111X Juan Fernández Vivó INF
22222222D Patricia Torres Rocamora ADM
33333333F Alberto Guillén Navas COM
44444444H Pablo López García INF
55555555F José Valdés Lozano COM
66666666B Sandra García García INF
77777777L Nuria Molina Martínez ADM
¿Cómo definir las claves ajenas?
Cuando se definen las claves ajenas, pueden establecerse una serie de restricciones según
el modo en que queramos reflejar el comportamiento del modelo de datos del mundo real.
Supongamos dos tablas A y B, de forma que la tabla B referencia a la tabla A. A

continuación se especifican varias posibilidades para definir una clave ajena.
1.- Clave ajena acepta nulos.

Consiste en permitir que el campo que es clave ajena pueda estar vacío o contener valores
nulos.
Ejemplo:
Puede existir algún empleado que no se encuentre asignado a ningún departamento. Por
ejemplo, podemos dar de alta a una empleada llamada Sonia González en espera de
asignarla a un departamento. En este caso, el campo “depto” de dicha empleada no tendrá
valor.
EMPLEADO
dni nombre apellido1 apellido2 depto
11111111X Juan Fernández Vivó INF
22222222D Patricia Torres Rocamora ADM
44444444H Pablo López García INF

88888888S Sonia González Martínez
2.- Al eliminar una tupla de la tabla A, si existen tuplas de la tabla B relacionadas con
dicha tupla de A, podemos elegir una de las siguientes posibilidades:
a) No permitir eliminar la tupla de A.

b) Eliminar la tupla de A y las relacionadas en B.
c) Eliminar la tupla de A y poner a nulo la clave ajena de las tuplas de B que
referencian a la tupla de A.
Ejemplo:
Se desea eliminar el departamento de Informática porque se va a contratar los servicios de

una empresa externa para realizar las tareas informáticas. ¿Cómo queremos que se
comporte la base de datos?
a) No permitir eliminar el departamento, porque hay empleados que pertenecen a ese

departamento.
b) Eliminar el departamento y los empleados asociados a dicho departamento. En este

caso, las tablas de la base de datos quedarán:
dni nombre apellido1 apellido2 depto codigo nombre
22222222D Patricia Torres Rocamora ADM ADM Administración
33333333F Alberto Guillén Navas COM COM Comercial
c) Eliminar el departamento y poner a nulo el campo “depto” (clave ajena) de los

empleados que pertenecían a dicho departamento. Los datos de las tablas quedarán:
dni nombre apellido1 apellido2 depto código nombre
11111111X Juan Fernández Vivó ADM Administración
22222222D Patricia Torres Rocamora ADM COM Comercial
44444444H Pablo López García
66666666B Sandra García García
3.- Al modificar la clave primaria de una tupla de la tabla A, si existen tuplas de la

tabla B relacionadas con dicha tupla de A, podemos elegir una de las siguientes
posibilidades:
a) No permitir la modificación.
b) Modificar la tupla de A y las relacionadas en B.
c) Modificar la tupla de A y poner a nulo la clave ajena de la tuplas de B
relacionadas con la tupla de A.
Ejemplo:
Se ha ampliado la empresa con un nuevo departamento: el departamento de compras. Con

la nueva reestructuración se quiere que el actual departamento Comercial (cuyo código es
COM) pase a llamarse Marketing y su código sea MAR y que el nuevo departamento de
Compras tenga como código COM. Como hay empleados asignados al departamento
Comercial, tendremos que ver cómo queremos que se comporte la base de datos
a) No permitir el cambio de nombre.

En este caso, habrá que asignar otro código al departamento de Compras para darlo de
alta.
b) Permitir la modificación del código y actualizar el atributo “depto” de los empleados

asignados a dicho departamento con el nuevo código MAR.
11111111X Juan Fernández Vivó INF ADM Administración
22222222D Patricia Torres Rocamora ADM INF Informática
33333333F Alberto Guillén Navas MAR MAR Marketing
44444444H Pablo López García INF COM Compras
55555555F José Valdés Lozano MAR
c) Permitir la modificación del código, dejando el campo “depto” de los empleados del
antiguo departamento Comercial sin ningún valor.
11111111X Juan Fernández Vivó INF ADM Administración
22222222D Patricia Torres Rocamora ADM INF Informática
33333333F Alberto Guillén Navas MAR Marketing
44444444H Pablo López García INF COM Compras
55555555F José Valdés Lozano
3. Transformación del diagrama ER al modelo relacional

En las secciones anteriores se ha visto cómo realizar el diagrama ER de relaciones binarias
y se han introducido los conceptos de claves primarias y ajenas. En este apartado se
incluyen las reglas para obtener la estructura de las tablas de una base de datos a partir
del diagrama E-R.
Las claves principales las indicaremos con el texto C.P., las alternativas con C.Alternativa
y las ajenas con C.Ajena. A continuación de dicho texto se indicará el nombre de los campos
que configuran cada clave. En el caso de las claves ajenas se especifica además a qué
tabla hace referencia. Los nombres de las tablas se escribirán en mayúsculas y los de los
atributos en minúsculas.
3.1 Relación 1:1
A(a1, a2, ...)

a1 a2 ... b1 b2 ... C.P.: a1
C
B(b1, b2, ....)
A B C.P.: b1
C(c1, c2, c3, ...)

C.P.: c1
c3 ...
C.Alternativa: c2
C.Ajena: c1 → A
C.Ajena: c2 → B
Ejemplo:
PROFESOR(dni, nombre, ...)

dni nombre código nombre C.P.: dni
DIRIGIR
DEPTO(código, nombre, ...)
PROFESOR DEPTO
C.P.: código
DIRIGIR(dni, coddepto, años)

C.P.: dni
... años ... C.Alternativa: coddepto
C.Ajena: dni → PROFESOR
C.Ajena: coddepto → DEPTO
3.2 Relación 1:M
a1 a2 ... b1 b2 ... A(a1, a2 , ...)

C.P.: a1
C
B(b1, b2, ... ,ba1)

A B
C.P.: b1
C.Ajena: ba1 → A
Ejemplo:
código nombre dni nombre ... DEPTO(código, nombre, ...)

...
C.P.: código
DEPTO PROFESOR PROFESOR(dni, nombre, ...,

coddepto)
PERTENECER C.P.: dni
C.Ajena: coddepto → DEPTO
3.3 Relación M:M
Caso 1)
a1 a2 b1 b2
A(a1, a2, ...)
C C.P.: a1
A B B(b1, b2, ...)

C.P.: b1
c3 ... C(c1, c2, c3, ...)

... ... C.P.: c1, c2
C.Ajena: c1 → A
C.Ajena: c2 → B
Ejemplo:
AUTOR(dni, nombre, ...)

dni nombre isbn título
C.P.: dni
LIBRO(isbn, título, ...)

AUTOR LIBRO C.P.: isbn
ESCRIBIR ESCRIBIR(dni, isbn)

C.P.: dni, isbn
... ... C.Ajena: dni → AUTOR
C.Ajena: isbn → LIBRO
Caso 2)
Ocurre cuando una ocurrencia de A puede relacionarse más de una vez con una de B. En
estos casos hay que añadir algún atributo más de la tabla C para formar la clave primaria
(normalmente es una fecha).
a1 a2 b1 b2 A(a1, a2, ...)

C C.P.: a1
A B
B(b1, b2, ...)
C.P.: b1
C(c1, c2, c3, ...)

... c3 ... ... C.P.: c1, c2, c3
C.Ajena: c1 → A
C.Ajena: c2 → B
Ejemplo:
dni nombre código ncreditos ALUMNO(dni, nombre, ...)

C.P.: dni
EXAMINAR
ASIGNATURA(código, ncreditos, ...)
ALUMNO ASIGNATURA C.P.: código
EXAMINAR(dni, codasig, fecha, nota)

C.P.: dni, codasig, fecha
fecha nota C.Ajena: dni → ALUMNO
... ...
C.Ajena: codasig → ASIGNATURA
En este ejemplo es necesario incluir en la clave principal de EXAMINAR el atributo fecha,

para reflejar situaciones en las que un alumno se examina más de una vez de una
asignatura, como por ejemplo en el siguiente caso.
EXAMINAR
dni codasig fecha nota
11222333H AIB 02/06/2020 7.5
11222333H AIA 05/06/2020 3.8
11222333H AIA 07/09/2020 7.3
El alumno 11222333H se examina de AIA dos veces, en Junio y Septiembre. Si la clave

principal únicamente estuviera formada por los atributos dni y codasig, el último registro de
la tabla no se podría introducir pues al repetirse los valores de la clave principal
(11222333H, AIA) con los contenidos en segundo registro, el SGBD daría un error.
Añadiendo la fecha como un atributo más de la clave principal sí se permite que el alumno
pueda examinarse de la misma asignatura en Septiembre.
3.4 Restricción de existencia

Una entidad B tiene una restricción de existencia respecto a una entidad A cuando existe
una relación entre ellas de forma que una ocurrencia de B necesariamente tiene que estar
relacionada con una de A, es decir, un registro de B no existe si no está relacionado con

uno de A.
Para representar la restricción de existencia en el diagrama E-R se enmarca la entidad que

tiene la restricción de existencia en un rectángulo con un borde doble y se añade la letra
“E” respecto a la relación con la entidad de la que depende.
Ejemplo:
Un departamento tiene muchos profesores y un profesor siempre debe pertenecer a un

único departamento.
dni código
PROFESOR DEPARTAMENTO
PERTENECER
Al indicar la letra E en PROFESOR, se indica que todos los registros de la tabla PROFESOR
obligatoriamente deben tener asignado el departamento al que pertenecen.
En las relaciones 1:M que tienen la restricción de existencia en la entidad de la parte del
muchos (PROFESOR), la restricción se refleja en el diseño añadiendo a la clave ajena
correspondiente a la relación las siglas VNN (Valores No Nulos). De esta forma, obligamos
a que la clave ajena siempre contenga un valor y además, por ser clave ajena, estos valores
deben hacer referencia a DEPARTAMENTO.
DEPARTAMENTO(código, …)
C.P.: código
PROFESOR(dni, … , coddepto)
C.P.: dni
C.Ajena: coddepto → DEPARTAMENTO VNN
No todas las restricciones de existencia se pueden reflejar a nivel de diseño, depende de

dónde se encuentre la restricción y del tipo de relación que se trate (1:1, 1:M, M:M).
Ejemplo:
claveA claveB
A B
PERTENECER
En este caso el sistema gestor de bases de datos no puede controlar directamente la

restricción de existencia de A respecto a B. Para solucionarlo se pueden utilizar
procedimientos de programación que controlen que siempre que se produzca un
alta/modificación en un registro de A, se relacione con un registro de B.
Por último, indicar que solamente incluiremos las restricciones de existencia si en la

descripción del sistema de información se especifica que sea obligatorio el dato.
3.5 Restricción de identidad

Se dice que una entidad B tiene una restricción de identidad respecto a una entidad A si es
necesario incluir en la clave principal de B el atributo/s que actúa como clave ajena a A
debido a que no es suficiente con los atributos de la entidad B para establecer una clave
principal.
En el diagrama E-R la restricción de identidad se representa, enmarcando a la entidad débil

(B) en un rectángulo con un borde doble y añadiendo las letras “ID” respecto a la entidad
de la que depende (A).
Ejemplo:
Una factura tiene muchas líneas y una línea sólo pertenece a una factura. Cada línea
viene numerada respecto a la factura con números 1,2,3.
Podríamos pensar realizar el siguiente diagrama E-R:
FACTURA(número, fecha) LINEA(nlinea, cantidad, artículo, nfactura)

C.P.: número C.P.: nlinea
C.Ajena: nfactura → FACTURA
Supongamos dos facturas con números 100 y 200, con 2 y 3 líneas de detalle,
respectivamente, que contienen los siguientes datos:
FACTURA LINEA
número fecha nlinea cantidad artículo nfactura
100 25/06/2020 1 20 ART1 100
200 30/06/2020 2 5 ART2 100
1 2 ART1 200
2 5 ART2 200
3 3 ART3 200
En la tabla LINEA el atributo “nlinea” por sí solo no puede ser clave principal porque no se
puede distinguir a qué factura pertenece una línea de detalle y se repiten valores en la clave
principal. Por ejemplo, tenemos la línea 1 de la factura 100 y la línea 1 de la factura 200.
Podríamos pensar en añadir más atributos para formar la clave principal. Si añadimos el
atributo “articulo” ocurrirá lo mismo: la línea 1 con el artículo “ART1” no puede determinarse
a qué factura pertenece. Podemos incluso añadir todos los atributos de la tabla LINEA para
formar la clave principal (nlinea, cantidad, articulo) y también ocurrirá que existe más de
una fila con los mismos valores, concretamente la correspondiente a los valores (2, 5,
ART2) con lo cual, esta combinación tampoco identifica unívocamente a las filas de la tabla.
Así, se deduce que la entidad LINEA no tiene identidad por sí misma si no se conoce con
qué entidad está relacionada (FACTURA). Para resolver estos casos de ambigüedad, es
necesario añadir un nuevo atributo a la clave primaria procedente de la entidad de la que
depende. En el caso de las facturas y líneas de factura el diagrama E-R será:
FACTURA(número, fecha) LINEA(nlinea, cantidad, artículo, nfactura)

C.P.: número C.P.: nfactura,nlinea
C.Ajena: nfactura → FACTURA
3.6 Generalización y especialización

Supongamos una empresa de mantenimiento y consultoría de ordenadores en la que
trabajan administrativos, comerciales y programadores. De cada empleado se guarda dni,
nombre, apellidos, dirección, teléfono y salario. Según el tipo de empleado se tienen los
atributos:
• administrativo: pulsaciones por minuto
• comercial: comisión
• programador: especialidad
y se realizan actividades diferentes:

• el comercial realiza visitas a empresas queriendo guardar cuándo hace la visita.
• el programador programa aplicaciones.
Para realizar el diseño de la base de datos en estos casos podemos utilizar la

generalización/especialización definiendo una entidad general A, que contiene los atributos
comunes y unas entidades especializadas B, C, D con sus atributos propios y/o relaciones
a otras entidades.
Representación:
a1
TIPO_GENERALIZACIÓN
b1 d1
B C D
...
... ...
c1
A(a1, …)
C.P.: a1
B(b1, … , a1) C(c1, … , a1) D(d1, … , a1)

C.P.: a1 C.P.: a1 C.P.: a1
C.Ajena: a1 → A C.Ajena: a1 → A C.Ajena: a1 → A
La generalización puede ser de varios tipos según su cobertura y lo especificaremos dentro

del hexágono que representa la generalización:
• Total (T) o Parcial (P): En el caso de que sea total todos los objetos de la entidad
general (A) pertenecen a alguna de las entidades especializadas (B,C,D). Si existen
objetos en la entidad general que no estén en las especializadas la generalización
será Parcial.
• Disjunta (D) o Solapada (S): Si las entidades especializadas (B,C,D) no tienen

objetos comunes se trata de una especialización disjunta y en caso contrario será
solapada.
En el ejemplo que introduce este apartado, la entidad EMPLEADO es una generalización

de las entidades ADMINISTRATIVO, COMERCIAL y TÉCNICO y éstas son una
especialización de la primera y se trata de una generalización total y disjunta. El diagrama
E-R correspondiente es:
La modelización en tablas correspondiente a la generalización/especialización es
EMPLEADO(dni, nombre, apellido1, apellido2, dirección, teléfono, salario)

C.P.: dni
COMERCIAL(dni, comisión)ADMINISTRATIVO(dni, PROGRAMADOR(dni,

pulsaciones) especialidad)
C.P.: dni C.P.: dni C.P.: dni
C.Ajena: dni → EMPLEADO C.Ajena: dni → EMPLEADO C.Ajena: dni → EMPLEADO
4. Agregación
Una agregación representa la creación de un objeto formado a partir de una relación entre
entidades, de tal forma que este objeto se comporta como una entidad más, aunque a un
nivel de abstracción mayor. La relación contenida en una agregación puede ser de cualquier
tipo (1:1, 1:M, M:M). Las agregaciones se utilizan como un elemento más del diagrama ER.
Cuando se establece una relación con una agregación, se indica que en dichas relaciones
con la nueva entidad deben participar todas las entidades que forman parte de la
agregación.
Para representar la agregación en el diagrama ER, dibujamos un rectángulo que engloba a

las entidades y a la relación que forman parte de la agregación. Posteriormente dicha
agregación se puede enlazar con otras entidades del sistema de información.
En el siguiente ejemplo, se presenta la relación ASIGNAR que representa la relación de

asignación de docencia de PROFESOR y ASIGNATURA. Si posteriormente queremos
reflejar la relación IMPARTIR docencia para cada grupo podemos definir una relación M:M,
denominada IMPARTIR sobre la agregación con la entidad GRUPO.
Para la transformación a tablas, se siguen las mismas reglas que en las relaciones binarias.
En este caso, tenemos las entidades PROFESOR, ASIGNATURA Y GRUPO, la relación
M:M ASIGNAR y la relación M:M IMPARTIR .
PROFESOR(dni, nombre) ASIGNAR(dniprof, codasig, codgrupo)

C.P..: dni C.P: dniprof, codasig
C.Ajena: dniprof → PROFESOR
ASIGNATURA(código, ncreditos) C.Ajena: codasig → ASIGNATURA
C.P.: dni
IMPARTIR(dniprof,codasig,codgrupo)
GRUPO(código, aula) C.P: dniprof, codasig, codgrupo
C.P.: código C.Ajena: dniprof, codasig → ASIGNAR
C.Ajena: codgrupo → GRUPO
5. Relaciones ternarias
Las relaciones ternarias asocian tres entidades. La forma de interpretar el significado de
estas relaciones consiste en coger cada par de entidades y relacionarla con la otra según
la cardinalidad de la relación, que puede ser 1:1:1, 1:1:M, 1:M:M o M:M:M.
Las relaciones ternarias siempre generan una nueva tabla en el modelo. Esta tabla tendrá
siempre claves ajenas a las tres tablas que une y obligatoriamente estas claves ajenas
deben contener valores. Dependiendo del tipo de cardinalidad se definen las claves
principales y alternativas. Además, las relaciones ternarias pueden contener atributos
propios que pueden formar parte o no de la clave principal y las alternativas.
5.1 Relación 1:1:1
A(a1, a2, ...) B(b1, b2 ,...) C(c1, c2, ...)

C.P.: a1 C.P.: b1 C.P.: c1
D(d1, d2, d3, ...)

C.P.: d1, d2
C.Alternativa: d1, d3
C.Ajena: d1 → A
C.Ajena: d2 → B
C.Ajena: d3 → C
Ejemplo:
• 1 profesor en 1 grupo puede impartir como mucho 1 asignatura.

• 1 profesor con 1 asignatura puede impartirla en 1 único grupo.
• 1 asignatura en 1 grupo puede ser impartida por 1 único profesor.
PROFESOR(dni, nombre)
C.P.: dni
GRUPO(código, aula)
C.P.: código
ASIGNATURA(código, ncreditos)
C.P.: código
IMPARTIR(dniprof, codgrupo, codasig)

C.P.: dniprof, codgrupo
C.Alternativa: dniprof, codasig
C.Alternativa: codgrupo, codasig
5.2 Relación 1:1:M
A(a1, a2, ...) B(b1, b2, ...) C(c1, c2, ...)

C.P.: a1 C.P.: b1 C.P.: c1
D(d1, d2, d3, ...)

C.P.: d2, d1
C.Ajena: d1 → A
C.Ajena: d2 → B
C.Ajena: d3 → C
Ejemplo:
• 1 profesor en 1 grupo puede impartir como mucho 1 asignatura.

• 1 profesor con 1 asignatura puede impartirla en muchos grupos.
• 1 asignatura en 1 grupo puede ser impartida por 1 único profesor.
C.P.: dni
C.P.: código
C.P.: código

C.P.: codgrupo, dniprof
C.Alternativa: codgrupo, codasig
5.3 Relación 1:M:M
A(a1, a2, ...) B(b1, b2, ...) C(c1, c2, ...)

C.P.: a1 C.P.: b1 C.P.: c1
D(d1, d2, d3, ...)

C.P.: d2, d3
C.Ajena: d1 → A VNN
C.Ajena: d2 → B
C.Ajena: d3 → C
Ejemplo:
• 1 profesor en 1 grupo puede impartir muchas asignaturas.

• 1 asignatura en 1 grupo y puede ser impartida por 1 único profesor.
C.P.: dni
C.P.: código
C.P.: código

C.P.: codgrupo, codasig
C.Ajena: dniprof → PROFESOR VNN
5.4 Relación M:M:M
A(a1, a2, ...) B(b1, b2, ...) C(c1, c2, ...)

C.P.: a1 C.P.: b1 C.P.: c1
D(d1, d2, d3, ...)

C.P.: d1, d2, d3
C.Ajena: d1 → A
C.Ajena: d2 → B
C.Ajena: d3 → C
Ejemplo:
• 1 profesor en 1 grupo puede impartir muchas asignaturas.

• 1 asignatura en 1 grupo puede ser impartida por muchos profesores.
C.P.: dni
C.P.: código
C.P.: código

C.P.: dniprof, codgrupo, codasig
En todos los tipos de relaciones ternarias si hay atributos propios que forman parte de la
clave principal también hay que añadirlos a las claves alternativas
Por otro lado, las relaciones ternarias pueden relacionarse con otras entidades (o
relaciones) del diagrama y tener restricciones de existencia o de identidad. Para la
modelización en tablas se siguen las reglas de transformación generales.
Ejemplo:
d4
La modelización en tablas de D es:
D(d1, d2, d3, d4, d5)

C.P.: d2, d1, d4
C.Alternativa: d2, d3, d4
C.Ajena: d1 → A
C.Ajena: d2 → B
C.Ajena: d3 → C
C.Ajena: d5 → E

01 Tema1 DisenoBDRelacionales

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01 Tema1 DisenoBDRelacionales

Cargado por

Copyright:

Formatos disponibles

Diseño de bases de datos relacionales

El modelo conceptual se representa por medio de un modelo de datos. Un modelo de datos

Finalmente, se debe transformar el esquema conceptual de datos a estructuras

Figura 1: Proceso de abstracción de la información.

En el modelo de datos Entidad-Relación se utilizan los siguientes conceptos:

• Entidad: objeto distinguible del mundo real (alumno, asignatura)

2.1. Diagrama E-R

Entidad Rectángulo etiquetado

Atributo Elipse etiquetada con

Relación Rombo o triángulo

2.2 Relaciones binarias

2.2.1 Relación 1:1

• 1 tupla 1 de la entidad A está relacionada con 1 sola tupla de la entidad B y

2.2.2 Relación 1:M

• 1 tupla de la entidad A está relacionada con muchas tuplas de la entidad B y

2.2.3 Relación M:M

• 1 tupla de la entidad A está relacionada con muchas de la entidad B y

2.3 Representación del modelo E-R en tablas

El siguiente diagrama E-R representa el comportamiento del sistema de información

dni nombre código título

La representación de la entidad ACTOR en forma de tabla es la siguiente:

2.4 Clave primaria o principal

Para representar la clave primaria en el diagrama E-R utilizaremos el formato negrita y

En el sistema de información anterior en el que se especifica la relación actuar entre actores

¿Cómo elegir la clave primaria?

Para una entidad/relación A con un conjunto de atributos, diremos que C, subconjunto de

• minimalidad: si C es compuesta, es decir, está formada por más de un atributo, no

2.5 Clave ajena

Supongamos la siguiente relación en la que un empleado pertenece a un departamento y

dni nombre código nombre

apellido1 EMPLEADO DEPARTAMENTO

Las tablas correspondientes a las entidades EMPLEADO y DEPARTAMENTO antes de

Supongamos que la distribución de empleados por departamentos es la siguiente:

• Administración: Patricia Torres y Nuria Molina.

Así, los datos contenidos en la tabla EMPLEADO serán:

¿Cómo definir las claves ajenas?

Supongamos dos tablas A y B, de forma que la tabla B referencia a la tabla A. A

1.- Clave ajena acepta nulos.

55555555F José Valdés Lozano COM

a) No permitir eliminar la tupla de A.

Se desea eliminar el departamento de Informática porque se va a contratar los servicios de

a) No permitir eliminar el departamento, porque hay empleados que pertenecen a ese

b) Eliminar el departamento y los empleados asociados a dicho departamento. En este

c) Eliminar el departamento y poner a nulo el campo “depto” (clave ajena) de los

3.- Al modificar la clave primaria de una tupla de la tabla A, si existen tuplas de la

Se ha ampliado la empresa con un nuevo departamento: el departamento de compras. Con

a) No permitir el cambio de nombre.

b) Permitir la modificación del código y actualizar el atributo “depto” de los empleados

3. Transformación del diagrama ER al modelo relacional

3.1 Relación 1:1

A(a1, a2, ...)

C(c1, c2, c3, ...)

PROFESOR(dni, nombre, ...)

DIRIGIR(dni, coddepto, años)

3.2 Relación 1:M

a1 a2 ... b1 b2 ... A(a1, a2 , ...)

B(b1, b2, ... ,ba1)

código nombre dni nombre ... DEPTO(código, nombre, ...)

DEPTO PROFESOR PROFESOR(dni, nombre, ...,

3.3 Relación M:M

A B B(b1, b2, ...)

c3 ... C(c1, c2, c3, ...)

AUTOR(dni, nombre, ...)