Bases de Datos

TEMA 3: DISEÑO DE BBDD RELACIONALES II

1. Modelo Lógico: Pautas para convertir el modelo

conceptual en tablas
2. Normalización: Técnicas para comprobar la calidad final
del diseño
3. Creación de tablas con SQL-DDL (Data Definition
Language). Restricciones. Inserción de datos
 Bases de Datos

Paso 1. Por cada conjunto de

entidades, se crea una tabla

Tema 3 – Modelo Lógico - 1

 Bases de Datos

Paso 1. Por cada conjunto de entidades se crea una tabla

Cada tupla representa una entidad

No existen tuplas duplicadas

Cada tabla tiene un nombre único en la base de datos

Cada atributo tiene un nombre único en la tabla

La clave primaria del conjunto de entidades pasa a ser la

clave primaria de la tabla
Tema 3 – Modelo Lógico - 2
 Bases de Datos

Paso 1. Por cada conjunto de entidades se crea una tabla

Entidades débiles son entidades que no tienen

una clave primaria propia, sino que dependen de la
clave primaria de una entidad con la que se
relacionan

En este caso, se añade como atributo la clave

primaria de la entidad con la que se relaciona que
pasa a ser clave externa en la tabla de la entidad
débil
Tema 3 – Modelo Lógico - 3
Bases de Datos

Paso 2. Las
relaciones

Tema 3 – Modelo Lógico - 4

 Bases de Datos

NOTACIÓN

Notación: Ei es un conjunto de entidades

Ri es un conjunto de relaciones

Ti es la tabla del conjunto de entidades Ei

TRi es la tabla del conjunto de relaciones Ri

PK(Ti) es la clave primaria (Primary Key) de la tabla Ti

FK es una clave externa (Foreing Key)

Tema 3 – Modelo Lógico - 5

 Bases de Datos

NOTACIÓN

El nombre de tabla es una única palabra en mayúsculas. El único carácter

Notación: especial que se puede usar es _

El nombre de atributo es una única palabra en minúsculas. El único carácter

especial que se puede usar es _

TABLA(atrib1, atrib2, …) define una tabla y sus atributos

TABLA.atrib1 hace referencia a atrib1 en TABLA

Los atributos que forman parte de la clave primaria se subrayan

Las restricciones clave candidata (CK), not null (NN), único (U), clave externa
(FK) y de dominio se indican justo debajo de la definición de la tabla

Para indicar que un atributo es clave externa se escribe

atributo es FK -> PK(TABLA_A_LA_QUE_HACA_REFERENCIA)

Tema 3 – Modelo Lógico - 6

 Bases de Datos

Paso 2. Representar las relaciones

Dependiendo de la cardinalidad máxima de

la relación, se distinguen tres casos:

• Uno a uno (1:1)

• Uno a muchos (1:N) o (N:1)
• Muchos a muchos (N:M)

Tema 3 – Modelo Lógico - 7

 Bases de Datos

Paso 2. Representar las relaciones

Relaciones 1:1

• Tenemos dos tablas correspondientes a los dos conjuntos

de entidades que participan en la relación.
• Se propaga la clave primaria. Esto significa que la clave
primaria de una de las tablas pasa a ser un atributo de la
otra, donde será una clave externa.
• Para decidir en cuál de las dos tablas se incluye, se
considera el criterio de evitar la aparición de NULL
(o atributos desconocidos o que no existen).
Tema 3 – Modelo Lógico - 8
 Bases de Datos

Paso 2. Representar las relaciones

Cuando la cardinalidad mínima

es 1:1 o 0:0. Esto quiere decir
• Es indiferente en cuál se las dos se añade
que las dos entidades
como atributo la clave primaria de la otra tabla.
participan totalmente, o
parcialmente, en la relación:

Cuando la cardinalidad mínima

es 0:1 o 1:0. Una de las
• Se añade el atributo en la tabla de la entidad
entidades tiene participación
que participa totalmente.
parcial y la otra tiene
participación total:

• Se añaden en la tabla en la que se ha

Atributos de la relación:
propagado la clave.

Tema 3 – Modelo Lógico - 9

 Bases de Datos

Paso 2. Representar las relaciones

Relaciones 1:N o N:1, opción 1

• Se propaga la clave primaria de la entidad que contribuye
con 1 a la entidad que contribuye con N.
• Si la relación tiene atributos se añaden a la tabla de la
entidad que contribuye con N.

Tema 3 – Modelo Lógico - 10

 Bases de Datos

Paso 2. Representar las relaciones

Relaciones 1:N o N:1, opción 2

• Se genera una nueva tabla que tiene como atributos la clave
primaria de T1, la clave primaria de T2 y los atributos de la
relación.
• Esta opción se prefiere si la entidad que contribuye con
muchos tiene participación parcial.

Tema 3 – Modelo Lógico - 11

 Bases de Datos

Paso 2. Representar las relaciones

Relaciones N:M
• Se crea una tabla de relación TR formada por las claves primarias de
las tablas de las entidades PK(T1), PK(T2), más los atributos
asociados a la relación, si existen.
• La clave primaria de esta tabla será la unión de las claves primarias
de las entidades si la relación entre ellas sólo se produce una vez.
• La clave primaria de esta tabla será la unión de las claves primarias
de las entidades y algún atributo de la relación si la relación puede
darse varias veces.

Tema 3 – Modelo Lógico - 12

 Bases de Datos

Paso 2. Representar las relaciones

Relaciones de generalización
• Se crea una tabla para la entidad de nivel superior.
• Se crea una tabla para cada entidad de nivel inferior,
añadiendo la clave primaria de la entidad de nivel superior.
• Los atributos que forman la clave primaria de la entidad de
nivel superior pasan a ser atributos de la clave primaria de
todas las entidades de nivel inferior.

Tema 3 – Modelo Lógico - 13

 Ejemplo 1

§ Obtener el modelo lógico del siguiente esquema conceptual

Alumno Titulacion

+nombre: varchar(50) 0,n estudia 0,1 +codigo: char(6)

+descripcion: varchar(250)
+dni: varchar(9)
+dirección: varchar(100)

0, n

Escuela
1,1 pertenece a
+nombre: varchar(50)
+dirección: varchar(100)

Tema 3 – Modelo Lógico - 14

 Ejemplo 1

§ Paso 1: Entidades
• ALUMNO { dni, nombre, direccion }
• TITULACION { codigo, descripcion }
• ESCUELA { nombre, direccion }

§ Paso 2: Relaciones
• estudia
v Opción 1: ALUMNO ( dni, nombre, direccion, codigoTitulacion )
´ codigoTitulacion es FK -> PK(TITULACION)
v Opción 2: ALUM_ESTUDIA_TIT ( dniAlumno, codigoTitulacion )
´ dniAlumno es FK -> PK(ALUMNO)
´ codigoTitulacion es FK -> PK(TITULACION)

• pertenece a
v Opción 1: TITULACION ( codigo, descripcion, nombreEscuela )
´nombreEscuela es FK -> PK(ESCUELA)

Tema 3 – Modelo Lógico - 15

 Ejemplo 2

§ Obtener el modelo lógico del siguiente esquema conceptual

Muchos

§ Tenemos dos entidades y una relación de muchos a muchos

§ PASO 1: Para cada entidad una tabla:
• EDICION { idEdicion, fechaInicio, fechaFin }
• TENISTA { idTenista, nombre, nacionalidad }
§ En una relación muchos a muchos se define la tabla de la relación:
• JUGAR { idEdicion, idTenista }
´ idEdicion es FK -> PK(EDICION)
´ idTenista es FK -> PK(TENISTA)

Tema 3 – Ejemplos para pasar del modelo conceptual al modelo lógico - 16

 Ejemplo 3

§ Obtener el modelo lógico del siguiente esquema conceptual

1:1

§ Tenemos dos entidades y una relación de uno a uno. Además, las dos entidades
participan parcialmente
§ Para cada entidad una tabla y propagamos la clave:
• ESTADIO { nombre, aforoMaximo }
• EQUIPO { nombre, fechaFundacion, numSocios, ciudad, nombreEstadio }
´ nombreEstadio es FK -> PK(ESTADIO)

Tema 3 – Ejemplos para pasar del modelo conceptual al modelo lógico - 17

 Ejemplo 4

§ Obtener el modelo lógico del siguiente esquema conceptual

Uno a muchos

§ Tenemos dos entidades y una relación de agregación de uno a muchos.

Además, las dos entidades participan totalmente.
§ Para cada entidad una tabla y propagamos la clave al conjunto de entidades que
contribuye con n elementos a la relación:
• LINEA { numero, fechaInauguracion }
• TRAMO { numero, longitud, numeroLinea }
´ numLinea es FK -> PK(LINEA)

Tema 3 – Ejemplos para pasar del modelo conceptual al modelo lógico - 18

 Ejemplo 5

§ Obtener el modelo lógico del siguiente esquema conceptual

§ Tenemos dos entidades y una relación de muchos a muchos con atributos

§ Para cada entidad una tabla:
• ARTICULO { codigo }
• USUARIO { dni, nombre }
§ Una tabla para la relación que contenga las claves primarias de las dos
entidades y los atributos de la relación:
• PRESTAMO { codigoArticulo, dniUsuario, fechaPrestamo, fechaDevolucion }
• codigoArticulo es FK -> PK(ARTICULO)
• dniUsuario es FK -> PK(USUARIO)

Tema 3 – Ejemplos para pasar del modelo conceptual al modelo lógico - 19

 Ejemplo 6

§ Obtener el modelo lógico del siguiente esquema conceptual

§ Tenemos una relación de

generalización/especialización
§ Una tabla para la super-entidad:
§ PERSONAL { dni, nombre,
apellidos,email }
§ Una tabla para cada sub-entidad:
§ PROFESOR { departamento,
numeroSexenios, categoría,
dniPersonal}
•dniPersonal es FK -> PK(PERSONAL)
§ COLABORADOR { tipo,
duración, dniPersonal}
•dniPersonal es FK -> PK(PERSONAL)

§ INVESTIGADOR { titulación,
dniPersonal }
•dniPersonal es FK -> PK(PERSONAL)

Tema 3 – Ejemplos para pasar del modelo conceptual al modelo lógico - 20

 Ejercicio 1

§ Obtener el modelo lógico del siguiente esquema conceptual

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 21

 Ejercicio 1: Solución

§ Una tabla por entidad

§ Además, una tabla para la relación “tramo pertenece a línea” que es de muchos a muchos N:M
§ El resto de las relaciones es de 1 a muchos, 1:N. Se propaga la clave de la entidad que contribuye con
uno a la que contribuye con N

LINEA { nombre, anyoInauguracion, numPasajeros }

TRAMO { codigo, longitud, tipoVia, nombreEstacionInicial, nombreEstacionFinal }
nombreEstacionInicial es FK -> PK(ESTACION)
nombreEstacionFinal es FK -> PK(ESTACION)
ESTACION { nombre, accesible, idMunicipio, denominacionZona }
denominacionZona es FK -> PK(ZONA)
idMunicipio es FK -> PK(MUNICIPIO)
MUNICIPIO { identificador, nombre, numeroHabitantes }
ZONA { denominacion, tarifa }
TRAMO_PERTENECE_LINEA { nombreLinea, codigoTramo }
nombreLinea es FK -> PK(LINEA)
codigoTramo es FK -> PK(TRAMO)

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 22

 Ejercicio 2

§ Obtener el modelo lógico del siguiente esquema conceptual

 Ejercicio 2: Solución

§ Una tabla por entidad

§ Una tabla para la relación “participa” que es N:M incluyendo los atributos de la relación
§ Una tabla para la relación “se proyecta” que es N:M incluyendo los atributos de la relación
§ Para la relación “cine tiene sala” que es 1:N se propaga la clave de cine a sala

PARTICIPANTE { nombre, nacionalidad, fecha }

PELICULA { tituloOriginal, tituloTraducido, nacionalidad, anioEstreno, anyoOscar }
CINE { nombre, calle, numero, distrito }
SALA { nombre, aforo, nombreCine }
nombreCine es FK -> PK(CINE)
PARTICIPA_PELI { nombreParticipante, tituloOriginalPelicula, actua, dirige, oscarActor, oscarDirector }
nombreParticipante es FK -> PK(PARTICIPANTE)
tituloOriginalPelicula es FK -> PK(PELICULA)
CINE_PROYECTA_PELI { tituloOriginalPelicula, nombreCine, fechaInicio, fechaFin, espectadores }
tituloOriginalPelicula es FK -> PK(PELICULA)
nombreCine es FK -> PK(CINE)

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 24

 Ejercicio 3

§ Obtener el modelo lógico del siguiente esquema conceptual

 Ejercicio 3: Solución

§ Una tabla para proyecto.

§ Una tabla para la superentidad y una tabla por subentidad que incluya la clave primaria de la superentidad.
§ Una tabla para la relación “participa” que es N:M
§ Una tabla para la relación “contrata” que es N:M incluyendo los atributos de la relación
§ Para la relación “es responsable” la clave de profesor, que contribuye con 1, se propaga a proyecto que
contribuye con N

PROYECTO { codigo, esEuropeo, fechaInicio, fechaFin, importe, dniResponsable }

dniResponsable es FK -> PK(PROFESOR)
PERSONAL {nombre, apellidos, dni, email }
PROFESOR { dniProfesor, departamento, numeroSexenios, categoría }
dniProfesor es FK -> PK(PERSONAL)
INVESTIGADOR { dniInvestigador, titulacion }
dniInvestigador es FK -> PK(PERSONAL)
COLABORADOR { dniColaborador, tipo, duración }
dniColaborador es FK -> PK(PERSONAL)
PARTICIPA { dniPersonal, codigoProyecto }
dniPersonal es FK -> PK(PERSONAL)
codigoProyecto es FK -> PK(PROYECTO)
CONTRATA { codigoProyecto, dniInvestigador, tipo, fechaInicio, fechaFin }
dniInvestigador es FK -> PK(INVESTIGADOR)
codigoProyecto es FK -> PK(PROYECTO)

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 26

 Ejercicio 4

§ Obtener el modelo lógico del siguiente esquema conceptual

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 27

 Ejercicio 4: Solución

§ Una tabla para hotel y una para cliente

§ Una tabla para habitación y una tabla para individual, doble y suite que contenga la clave
primaria de “habitación”
§ Para la relación “tiene””, que es 1:N, se propaga la clave de “hotel” a “habitación”
§ Una tabla para la relación “se aloja” que es N:M incluyendo sus atributos

CLIENTE { dni, nombre, apellido1, apellido2, nacionalidad, telefono, email, fechaNacimiento }

HOTEL { id, nombre, categoria, cadenaHotelera }
HABITACION { numero, edificio, planta, superficie, idHotel }
idHotel es FK -> PK(HOTEL)
INDIVIDUAL { numeroHabitacion, banyoCompleto }
numeroHabitacion es FK-> PK(HABITACION)
DOBLE { numeroHabitacion, camaMatrimonio, banyoCompleto }
numeroHabitacion es FK -> PK(HABITACION)
SUITE { numeroHabitacion, numeroDormitorios, numeroSalones, numeroBanyos, cocina }
numeroHabitacion es FK -> PK(HABITACION)
ALOJA { dniCliente, numeroHabitacion, fechaEntrada, fechaSalida, tarifa }
dniCliente FK(CLIENTE)
numeroHabitacion es FK -> PK(HABITACION)

Tema 3 – Ejercicios para pasar del modelo conceptual al modelo lógico - 28

 Bases de Datos

RESUMEN

• 1. Entidades: Para cada entidad -> una tabla

• 2. Relaciones
– 1,1
• cardinalidades mínimas 1,1 o 0,0 – es indiferente a cuál de las dos entidades se
propaga la PK de la otra.
• cardinalidades mínimas 0,1 – la clave primaria de la entidad del lado “1” se propaga a
la entidad con “0”. P.ej., Usuario (1,1) tiene (0,1) Cuenta => PK(Usuario) se almacena
en la tabla de ”Cuenta” como FK.
• atributos de la relación: en la tabla donde se ha propagado la clave.
– 1,N (o N,1):
• La clave primaria de la entidad con “1” a la entidad se propaga a la entidad con N.
• atributos de la relación: en la tabla donde se ha propagado la clave.
– N, M:
• Nueva tabla formada por las claves primarias de las entidades participantes (FK), más
los atributos asociados a la relación, si existen.
• Clave primaria = como mínimo, unión de las dos FKs
DIAPOSITIVA 29
 Bases de Datos

RESUMEN
– Relación especial (1): agregación. Se modela como una relación 1, N
• La clave primaria de la entidad del lado 1 se propaga a la entidad con N.
• Atributos de la relación: van a la tabla donde se ha propagado la clave.
– Relación especial (2): generalización
• 1) Una tabla para la entidad de nivel superior.
• 2) Una crea una tabla para cada entidad de nivel inferior
• 3) La clave primaria de las especializaciones es la PK de la
generalización (la PK de la clase madre se propaga a las clases hijas
como FK, donde actúa como PK de las clases hijas también).
– Observaciones:
• Atributo(s) de la clave primaria se subraya(n).
• Adnotación FK (Ejemplo): ESTACION (0,N) estáEn MUNICIPIO (1,1)
ESTACION { id, accesible, denominacionZona, idMunicipio}
idMunicipio es FK -> PK(MUNICIPIO)
MUNICIPIO {idMunicipio, nombre, numHabitantes }
DIAPOSITIVA 30
 Bases de Datos

TEMA 3: DISEÑO DE BBDD RELACIONALES II

1. Modelo Lógico: Pautas para convertir el modelo

conceptual en tablas
2. Normalización: Técnicas para comprobar la calidad
final del diseño
3. Creación de tablas con SQL-DDL (Data Definition
Language). Restricciones. Inserción de datos
 Bases de Datos

T3.2 - Normalización de modelos de datos

relacionales

a) Introducción
b) Dependencias funcionales
c) Reglas de inferencia lógica
d) Normalización
 Bases de Datos

4.2 Normalización: a) Introducción

§ Supongamos que, en el diseño de nuestra base de datos, y con objeto de

simplificar el diseño, hemos optado por modelar la relación EstudianteTitulación
para satisfacer las siguientes funcionalidades :
§ Almacenar y gestionar las titulaciones ofertadas por la UPM.
§ Almacenar y gestionar los estudiantes matriculados en la UPM.
§ Almacenar y gestionar las titulaciones de la UPM en las que un estudiante ha
estado matriculado.
§ Y hemos definido que la PK de la relación es {DNI, IdTitulación}, supuesto que el
atributo año indica el año en el que el estudiante inició sus estudios en la
titulación.

Tema 3 – Normalización - 33
 Bases de Datos

Introducción

§ A la hora de analizar la calidad del diseño de un esquema relacional, se pueden

evaluar los siguientes aspectos:
• ¿los atributos de la relación están semánticamente relacionados?
v Cuanto más fácil se pueda explicar la semántica entre los atributos,
mejor será el diseño.
¿Existe una fuerte relación semántica entre un estudiante y el año en el que se aprobó
la memoria de verificación de una titulación (supuesto que es uno de los atributos)?

• ¿existe redundancia en la información?

v Uno de los objetivos perseguidos en el diseño es minimizar el espacio
consumido en el almacenamiento de la información. Para ello, la
información que caracteriza a cada elemento de información
(estudiante, titulación,…) debe almacenarse una única vez.
¿Es necesario almacenar un duplicado de toda la información de un estudiante cada
vez que es admitido en un grado?
¿Es necesario almacenar un duplicado de toda la información asociada a cada
titulación cada vez que es admitido un nuevo estudiante?

Tema 3 – Normalización - 34
 Bases de Datos

Introducción
§ Un problema derivado de la redundancia de información es que se pueden
producir anomalías:
Anomalías de inserción: ¿cómo podemos dar de alta una nueva titulación si todavía
no hay alumnos admitidos?
Anomalías de eliminación: si eliminamos al único alumno que ha sido admitido en una
nueva titulación porque ha anulado matrícula. ¿qué pasa con la información de la
titulación?
Anomalías de inconsistencia : si en el momento de dar de alta una nueva admisión de
un estudiante en una titulación, se introducen datos que difieren de los que hubiera
en registros anteriores (por ejemplo, la fecha de nacimiento) ¿qué información es la
correcta?

§ ¿existen muchos valores nulos?

• Los valores nulos pueden tener múltiples interpretaciones:
v El atributo no se aplica a esa tupla
v El atributo aplica, pero se registrará más tarde
v Se desconoce el valor del atributo
Tema 3 – Normalización - 35
 Bases de Datos

Introducción

§ Las dependencias funcionales, junto con las reglas de inferencia lógica,

proporcionan un mecanismo riguroso y formal para la identificación de
estos problemas.

§ Una vez identificados, el proceso de normalización proporciona un

conjunto de métodos formales para descomponer una relación que
presenta deficiencias en un conjunto de relaciones más pequeñas.

Tema 3 – Normalización - 36
 Bases de Datos

Tema 3.2 Normalización de modelos de datos

relacionales

a) Introducción
b) Dependencias funcionales
c) Reglas de inferencia lógica
d) Normalización
 Bases de Datos

Definición de Dependencia Funcional

§ Una dependencia funcional (DF) es una restricción inherente a la semántica

existente entre dos conjuntos de atributos de una base de datos, que se expresa
de la forma X ª Y, y se lee “X implica Y “ o “X determina Y”.
Ejemplo: del conocimiento del contexto, sabemos que el nombre, apellidos y DNI de una
Por no son datos inconexos, sino que existe la siguiente relación semántica entre ellos:
§persona
DNI ª {nombre, apellidos}; es decir, conocido el valor de un DNI, siempre le corresponde el
mismo valor para nombre y apellidos.

Definición formal

§ Dado una relación R formada por un conjunto de atributos {A1, A2, … , An}, se
dice que un conjunto de atributos X de R determina funcionalmente a un
conjunto de atributos Y de R si:

tupla t1, t2 Î R si t1[X] = t2[X] entonces t1[Y] = t2[Y]

§ es decir, todas las tuplas de R en las que X toma un determinado valor tienen
asociado el mismo conjunto de valores para Y.

Tema 3 – Normalización - 38
 Bases de Datos

Definición de Dependencia Funcional - DF

§ La relación EstudianteTitulación almacena información sobre las titulaciones de

la UPM en las que ha estado matriculado un estudiante.

§ A partir del conocimiento semántico que tenemos del contexto, podemos

identificar las siguientes dependencias funcionales:
• (df1) DNI ª {Nombre, Apellidos}: siempre que DNI toma un valor (1593575) le
corresponde el mismo valor de Nombre y Apellidos.
• (df2) idTitulación ª Titulación: siempre que IdTitulación toma un valor (12TG)
le corresponde el mismo valor de Titulación.

Tema 3 – Normalización - 39
 Bases de Datos

Nomenclatura

§ Nomenclatura: X ª Y
• ª : símbolo de dependencia funcional. X implica Y
• X determina funcionalmente a Y
• Y depende funcionalmente de X
• X : atributo o conjunto de atributos determinante
• Y : atributo o conjunto de atributos dependiente
El siguiente esquema representa el esquema relacional de la tabla
EstudianteTitulación y las DF identificadas:

§ DNI determina funcionalmente a Nombre y Apellidos

§ Nombre y Apellidos dependen funcionalmente de DNI
§ IdTitulación determina funcionalmente a Titulación
§ Titulación depende funcionalmente de IdTitulación
Tema 3 – Normalización - 40
 Bases de Datos

Atributos extraños en dependencias funcionales

§ Dada una dependencia funcional X ª Y, un subconjunto de atributos A de X es

extraño cuando, al eliminarlo de la dependencia funcional, la dependencia
resultante sigue siendo válida.
sea X ª Y , A Ì X es extraño si {X - A}ª Y

En EstudianteTitulación se puede identificar la siguiente dependencia funcional:

df1: {DNI, Año} ª {Nombre, Apellidos}

Sin embargo, por la semántica de los atributos se sabe que

{DNI} ª {Nombre, Apellidos}

Por tanto, se puede inferir que en la df1 Año es un atributo extraño.

Tema 3 – Normalización - 41
 Bases de Datos

Dependencias funcionales totales y parciales

Dependencia funcional total
§ Una dependencia funcional X ª Y es total si el conjunto de atributos
determinante X no contiene atributos extraños, es decir, Y depende totalmente
de X.

Dependencia funcional parcial

§ Una dependencia funcional X ª Y es parcial si el conjunto de atributos
determinante X contiene atributos extraños, es decir, Y depende parcialmente de
X si existe un subconjunto Z de X (Z Ì X) que también determina a Y.

En EstudianteTitulación se puede identificar la siguiente dependencia funcional:

{DNI, Año} ª {Nombre, Apellidos} (df1)

Al ser Año un atributo extraño, se puede decir que

{Nombre, Apellidos} dependen parcialmente de {DNI, Año}
{Nombre, Apellidos} dependen totalmente de DNI

Tema 3 – Normalización - 42
 Bases de Datos

T3.2 - Normalización de modelos de datos

relacionales

a) Introducción
b) Dependencias funcionales
c) Reglas de inferencia lógica
d) Normalización
 Bases de Datos

Reglas de inferencia: Definición

§ Conjunto de reglas deductivas que permiten inferir todas las dependencias

funcionales existentes entre un conjunto de atributos, partiendo de dependencias
funcionales que se asumen como ciertas a partir del conocimiento del contexto.
§ A cada una de las dependencias funcionales de partida se les denomina: df dato
o df trivial
§ Reglas de inferencia básicas o Axiomas de Armstrong. Constituyen un conjunto
completo de reglas, es decir, dado un conjunto Á de DF, todas las DF implicadas
por Á pueden ser inferidas aplicando estas reglas.
1. Reflexiva
2. Aumentación
3. Transitiva
§ Otras reglas de inferencia
4. Proyección
5. Unión
6. Composición
 Bases de Datos

Reglas de inferencia (1): Reflexiva

§ Un conjunto de atributos se determina a sí mismo y a un subconjunto propio.

Si X Ê Y entonces X ª Y

Premisa: X = {Nombre, Apellidos} en un conjunto de atributos

Regla: reflexiva
Consecuente: dependencias funcionales inferidas
df1: {Nombre, Apellidos} ª {Nombre, Apellidos}
df2: {Nombre, Apellidos} ª {Nombre}
df3: {Nombre, Apellidos} ª {Apellidos}

En una regla de inferencia existen una o varias premisas (también llamadas ‘hechos’ o
‘antecedentes’) que se asumen verdaderas, y uno o varios consecuentes que serían la
conclusión o conocimiento inferido una vez aplicada la regla sobre las premisas.

Tema 3 – Normalización - 45
 Bases de Datos

Reglas de inferencia (2): Aumentación

§ Al añadir el mismo conjunto de atributos a ambos lados de una dependencia

funcional válida, se obtiene una dependencia funcional igualmente válida.

Si X ª Y entonces XZ ª YZ

Premisa: {DNI} ª {Nombre, Apellidos}

Regla: aumentación
Consecuente: ejemplo de dependencias funcionales válidas
df1: {DNI, IdTitulación} ª {Nombre, Apellidos , IdTitulación}
df2: {DNI, Año} ª {Nombre, Apellidos , Año}
df3: {DNI, IdTitulación, Año} ª {Nombre, Apellidos , IdTitulación , Año}

Con objeto de abreviar la sintaxis utilizada en las definiciones, las dependencias

funcionales del tipo {X, A} ª Y se abreviarán como XA ª Y; las del tipo {X, Y, Z} ª {A, B}
como XYZ ª AB

Tema 3 – Normalización - 46
 Bases de Datos

Reglas de inferencia (3): Transitiva

Si (X ª Y) Ù (Y ª Z) entonces X ª Z

§ La relación “Equipo” agrupa los atributos asociados a un equipo de fútbol (en un

contexto en el que cada equipo tiene asociado un campo de juego y sólo uno)
entre los que se han identificado las dependencias funcionales df1 y df2.

Premisa: df1: {IdEquipo} ª {IdEstadio} Ù

df2: {IdEstadio} ª {NombEstadio, Aforo}
Regla: transitiva
Consecuente: dependencia funcional inferida
df3: { IdEquipo} ª {NombEstadio, Aforo}

Tema 3 – Normalización - 47
 Bases de Datos

Reglas de inferencia (4): Proyección

§ Esta regla también recibe el nombre de descomposición.

Si (X ª YZ) entonces (X ª Y) Ù (X ª Z)

Premisa: df2: {IdEstadio} ª {NombEstadio, Aforo}

Regla: proyección
Consecuente: dependencias funcionales inferidas
df3: { IdEstadio} ª {NombEstadio}
df4: { IdEstadio} ª {Aforo}

Tema 3 – Normalización - 48
 Bases de Datos

Reglas de inferencia (5) y (6): Unión y Composición

Unión o aditiva

Si (X ª Y) Ù (X ª Z) entonces (X ª YZ)

Premisa:df1: { IdEstadio} ª {NombEstadio} Ù

df2: { IdEstadio} ª {Aforo}
Regla: unión
Consecuente: dependencia funcional inferida
df3: {IdEstadio} ª {NombEstadio, Aforo}

Composición

Si (X ª Y) Ù (A ª B) entonces (XA ª YB)

Premisa:df1: { DNI } ª {Nombre, Apellidos}

df2: { IdTitulacion} ª {Titulacion}
Regla: composición
Consecuente: dependencia funcional inferida
df3: {DNI, IdTitulacion} ª {Nombre, Apellidos, Titulacion}
Tema 3 – Normalización - 49
 Bases de Datos

Cierre de un conjunto de atributos

§ Sea R un conjunto de atributos {A1, A2,… An } y Á un conjunto de dependencias

funcionales {df1, df2,… dfn } en las que X aparece en calidad de determinante.
Se denomina cierre de X bajo Á al conjunto de atributos X+ funcionalmente
dependientes de X, más las dependencias inferidas de Á.
§ Para calcular el cierre de X bajo Á (X+), se deberá seguir el siguiente algoritmo:
1 Aplicando las reglas de inferencia reflexiva y unión, se inferirá el conjunto Y
directamente dependiente de X .
X+ = Y
2 Iterar: Para cada dependencia funcional A ª B de Á en la que A se encuentre
en el conjunto de atributos dependientes de X (es decir A Ì Y), aplicando
transitividad, se infiere que X ª B.

X+actual = X+anterior È B
X+actual = Y È B

Repetir el paso (2) hasta que no se produzca ninguna modificación de X+ en

una iteración completa, o hasta que X+ sea igual a {A1, A2,… An }.
Tema 3 – Normalización - 50
 Bases de Datos

Cierre de un conjunto de atributos

Ejemplo
§ La relación Préstamo agrupa los atributos asociados a los préstamos realizados
en una biblioteca en la que un usuario puede tener varios préstamos activos
simultáneamente.

§ El conjunto Á está formado por:

df1: {DNI} ª {Nombre, Apellidos}
df2: {CodReCurso} ª {Recurso}
df3: {CodRecurso, FechaPréstamo} ª {DNI, FechaEntrega}
df4: {CodRecurso, FechaEntrega} ª {DNI, FechaPréstamo}
Suponiendo que las fechas de préstamos y de entrega son marcas/instantes de tiempo
(día-hora-minutos-segundos), las dependencias funcionales df3 y df4 indican que:
(df3) en un instante de tiempo un determinado recurso sólo puede prestarse una vez
(df4) en un instante de tiempo un determinado recurso sólo puede entregarse una vez
Tema 3 – Normalización - 51
 Bases de Datos

Cierre de un conjunto de atributos

§ Cálculo del cierre {CodRecurso, FechaPréstamo}+ (lo abreviamos como X+ para

simplificar).
1
Aplicando reflexiva a df3:
{X}+ = {DNI, CodCurso, FechaPréstamo, FechaEntrega}

2
Iteración 1: evaluamos cada df de Á
df1: el atributo determinante DNI forma parte de {X}+ por lo que podemos calcular
una nueva {X}+ = {X}+antigua È {Nombre, Apellidos}
{X}+ = {DNI, Nombre, Apellidos, CodCurso, FechaPréstamo, FechaEntrega}
df2: el atributo determinante CodCurso forma parte de {X}+ por lo que podemos
calcular una nueva {X}+ = {X}+antigua È {Recurso}
{X}+ = {DNI, Nombre, Apellidos, CodCurso, Recurso, FechaPréstamo, FechaEntrega}
df3 y df4 no aportan más atributos
2
Iteración 2: no es necesario volver a evaluar todas las dependencias funcionales
porque ya hemos obtenido que el cierre {CodRecurso, FechaPréstamo}+ es igual a
todos los atributos de Préstamo.
Tema 3 – Normalización - 52
 Bases de Datos

Cierre de un conjunto de atributos

§ Aplicando el mismo procedimiento para el resto de los conjuntos de atributos

determinantes, obtenemos los siguientes cierres:

{DNI}+ = {DNI, Nombre, Apellidos}

{CodRecurso}+ = {CodRecurso, Recurso}

{CodRecurso, FechaPréstamo}+ =
{DNI, Nombre, Apellidos, CodRecurso, Recurso, FechaPréstamo, FechaEntrega}

{CodRecurso, FechaEntrega}+ =
{DNI, Nombre, Apellidos, CodRecurso, Recurso, FechaPréstamo, FechaEntrega}

Tema 3 – Normalización - 53
 Bases de Datos

Cierre de X bajo Á: inferencia de claves

§ Ya es conocido la importancia de la identificación de claves candidatas y claves

primarias y superclaves en el diseño de un modelo de datos relacional.
§ Una superclave de una relación de esquema 𝑅(𝐴! , 𝐴" , … , 𝐴# ) es un
subconjunto de los atributos del esquema tal que no puede haber dos tuplas
en la extensión de la relación que tengan la misma combinación de valores
para los atributos del subconjunto.
§ Habitualmente, una de las claves candidatas de una relación se designa
clave primaria de la relación. La clave primaria es la clave candidata cuyos
valores se utilizarán para identificar las tuplas de la relación.
§ Ejemplo: 𝑅(𝐷𝑁𝐼, 𝑁_𝑠𝑒𝑔_𝑠𝑜𝑐𝑖𝑎𝑙, 𝑁𝑜𝑚𝑏𝑟𝑒, 𝐴𝑝𝑒𝑙𝑙𝑖𝑑𝑜𝑠). ¿Claves candidatas?
§ Hasta ahora, la forma de identificación de dichas claves se ha realizado a partir
del conocimiento de la semántica del contexto y mediante la aplicación de las
reglas generales de transformación del modelo conceptual al modelo lógico.
§ La aplicación de las reglas de inferencia lógica para analizar el conjunto de
dependencias funcionales inicialmente definidas en una relación constituye una
herramienta robusta para la validación de las claves propuestas y para el
descubrimiento de otras.
Tema 3 – Normalización - 54
 Bases de Datos

Cierre de X bajo Á: inferencia de claves

§ Dado un conjunto de dependencias funcionales Á definida sobre una relación
R = {A1, A2,… An }:
• Todo conjunto de atributos determinante X Ì R cuyo cierre X+ sea igual a
{A1, A2,… An }, será superclave.
• Todo conjunto de atributos Y Ì R que no forme parte de ningún cierre (es
decir, no actué en calidad de determinante ni de dependiente en Á), deberá
formar parte de toda superclave.
• Una superclave que no contenga atributos extraños, será una superclave
mínima. (se busca inferir superclaves mínimas)
• Nota. Atributo extraño = atributo que se puede quitar de una DF sin afectar su
validez. ¡Un atributo aislado debe formar parte de una superclave mínima
(¡aplicando la regla reflexiva y la composición) y no es un atributo extraño!;
Recomendación: repasar el Ejercicio 3 del documento de ejercicios para el examen)
§ Cualquier atributo Ai que forme parte de una superclave mínima, se denomina
atributo primario.
§ Teniendo en cuenta que se pueden identificar varias superclaves mínimas (de las
cuales, una de convierte en PK(R)), los atributos que forman parte de las claves
candidatas, pero no de la PK(R), también son atributos primarios.
Tema 3 – Normalización - 55
 Bases de Datos

Cierre de X bajo Á: inferencia de claves

§ En la relación Préstamos, a partir de las dependencias funcionales definidas y

de los cierres inferidos, identificamos las siguientes claves candidatas
(superclaves mínimas)

{DNI}+ = {DNI, Nombre, Apellidos}

{CodRecurso}+ = {CodRecurso, Recurso}

{CodRecurso, FechaPréstamo}+ =
{DNI, Nombre, Apellidos, CodRecurso, Recurso, FechaPréstamo, FechaEntrega}

{CodRecurso, FechaEntrega}+ =
{DNI, Nombre, Apellidos, CodRecurso, Recurso, FechaPréstamo, FechaEntrega}

{CodRecurso, FechaPréstamo}
{CodRecurso, FechaEntrega}

Tema 3 – Normalización - 56
 Bases de Datos

RESUMEN
• 1. Cierre de Conjunto de Atributos (adnotación: X+)
– PASO 1: Aplicar las reglas de inferencia reflexiva y unión para inferir el conjunto
de atributos dependientes Y (directamente dependiente de X)
– PASO 2: ITERAR: Para cada DF donde los atributo(s) determinante(s) Ì Y,
aplicar transitividad.
• Observación: La iteración para cuando (1) ya no se encuentran una DF donde
atributo(s) determinante(s) Ì Y, o (2) X+ incluye todos los atributos de R.
• 2. Superclave: Una superclave incluye todos los atributos.
– Caso 1: Si el cierre de un conjunto de atributos determinante X+ contiene todos
los atributos de R, X será superclave.
– Caso 2: Si el cierre de un conjunto de atributos no contiene todos los atributos, es
necesario aplicar la composición con otras DFs del conjunto Á. El(los) atributo(s)
que no forme(n) parte de ningún cierre (es decir, que no actué en calidad de
determinante, ni de dependiente en las DFs), deberá formar parte de toda
superclave. Notas:
• Se busca determinar la(s) superclave(s) mínima(s) (que no contenga(n) atributos
extraños).
• Muchas veces, se obtienen varias superclaves mínimas. Una de ellas (generalmente,
con el menor número de atributos de convierte en PK(R)), y el resto se consideran
claves candidatas. DIAPOSITIVA 57
 Bases de Datos

T3.2 - Normalización de modelos de datos

relacionales

a) Introducción
b) Dependencias funcionales
c) Reglas de inferencia lógica
d) Normalización
 Bases de Datos

Normalización: definición

§ La normalización es un proceso reversible mediante el cual se efectúa una

descomposición progresiva de una relación R en varias relaciones {R1, R2,… Rn}
de menos grado que la original.
§ Para su aplicación, la relación debe estar perfectamente definida mediante un
conjunto de atributos R={A1, A2,… An } y el conjunto de dependencias funcionales
Á={df1, df2,… dfn } con las relaciones semánticas existentes entre ellos.
§ Suelen ser frecuentes en escenarios y aplicaciones donde no se han
seguido las pautas de modelo conceptual, o de transformación de
conceptual a modelo lógico.

§ Requisitos de la descomposición:
• Preservar el contenido de la relación: la unión de los atributos de las
nuevas relaciones debe ser igual a los atributos de R.
• Preservar el conjunto de dependencias funcionales: las relaciones
semánticas definidas en Á deben estar presentes en el nuevo conjunto de
relaciones.
 Bases de Datos

Formas normales

§ Una forma normal establece una serie de requisitos de calidad

deseables para una relación.
§ Las formas normales que se aplican sobre una relación son las
siguientes:
• 1FN: primera forma normal.
• 2FN: segunda forma normal.
• 3FN: tercera forma normal.
• FNBC: Forma normal de Boyce-Codd

§ Estas formas deben ser evaluadas y satisfechas en el orden

enumerado, cada una de ella es más restrictiva que la anterior y
asegura el cumplimiento de las anteriores.
 Bases de Datos

1FN: Primera forma normal

§ Una relación R está en primera forma normal si los dominios de todos

sus atributos son atómicos:
• Dominio: conjunto de valores válidos para un atributo.
• Un dominio es atómico si sus elementos son unidades indivisibles.
• Son dominios no atómicos:
v Los dominios de atributos multivaluados (p.ej., el atributo
“telefonos” de un modelo conceptual)
v Los dominios de atributos compuestos (p. ej., el atributo
“dirección” puede descomponerse en los atributos
“calle”, “numero”, “ciudad”, “pais”, “codigo_postal”, etc.)

Tema 3 – Normalización - 61
 Bases de Datos

1FN: Primera forma normal

§ Si se han seguido las pautas de transformación de modelo conceptual a modelo

lógico, podemos asegurar que todas las relaciones se encuentran en 1FN.
§ Sin embargo, si se abordara el diseño aplicando la ‘fuerza bruta’ y se detectara
atributos no atómicos en una relación R, se debería aplicar el siguiente
procedimiento para la normalización:
v Eliminación de atributos compuestos:
Generalmente, crear un atributo en R por cada uno de los componentes del
atributo compuesto. A veces (cuando el atributo se compone por muchos
valores), será necesario crear una nueva tabla.

v Eliminación de atributos multivaluados:

Descomponer R en varias relaciones
(1) R1: formada por la PK(R) más los atributos simples de R.
(2) Por cada atributo multievaluado:
Ri: formada por la PK(R) más el atributo multievaluado
PK(Ri) = PK(R) + atributo multievaluado
PK(Ri) será un FK que referencie a PK(R)

Tema 3 – Normalización - 62
 Bases de Datos

1FN: Primera forma normal

§ Supongamos que tenemos una relación Estudiante que tiene los

siguientes atributos: ID_Estudiante, Nombre, Apellidos y Dirección

§ La nueva relación (tabla) Estudiante sería:

id_estudiante nombre apellido_1 apellido2 id_direccion

1 Juan Pérez Garcia 1
2 Maria Jimenez Lopéz 2

§ La nueva relación Dirección construida sería:

id_direccion calle numero ciudad pais codigo_postal

1 Gran Vía 214 Madrid España 28001
2 Passeig de Gràcia 30 Barcelona España 08001

Tema 3 – Normalización - 63
 Bases de Datos

2FN: Segunda forma normal

§ Una relación R está en segunda forma normal si:

• está en primera forma normal, y
• no existen dependencias funcionales parciales con respecto de la clave
primaria de R.
§ Consideración: una relación cuya PK(R) contiene un único atributo, cumple la
automáticamente la 2FN. Cuando la PK(R) contiene varios atributos, es posible
que existan dependencias parciales. En este caso, hay que verificar si algún
subconjunto de atributos de la clave primaria actúa como determinante en alguna
dependencia funcional (DF) por su cuenta. Si es así, entonces la relación no está
en 2FN y se debe descomponer para eliminar las dependencias parciales.
§ Normalización: dada una relación R en la que se ha identificado una
dependencia funcional parcial X ª Y con respecto de la clave primaria PK(R):

Descomponer R en varias relaciones

(1) R1: formada por PK(R) más los atributos que dependan totalmente de ella.
(2) Por cada dependencia funcional parcial X ª Y / X Ì PK(R):
crear una tabla Ri formada por el conjunto de atributos determinante X y el
conjunto de atributos funcionalmente dependiente Y
PK(Ri) = X Tema 3 – Normalización - 64
 Bases de Datos

2FN: Segunda forma normal

§ En la relación Préstamo, habíamos inferido que había dos superclaves mínimas:

{CodRecurso, FechaPréstamo} y {CodRecurso, FechaEntrega}.
• Dado que FechaEntrega puede tomar un valor nulo (su valor es desconocido
hasta que no se haya completado la entrega), no puede formar parte de una
PK, por lo que la PK es {CodRecurso, FechaPréstamo}.

§ Esta relación no satisface los criterios establecidos por la 2FN, al ser df2 una
dependencia funcional parcial con respecto de la clave primaria.

Tema 3 – Normalización - 65
 Bases de Datos

2FN: Segunda forma normal

§ Normalización de Préstamo:
• Crear una tabla formada por PK(R) más los atributos que dependan totalmente de
ella.

• Para la df2 CodRecurso ª Recurso / CodRecurso Ì PK(Préstamo): crear la tabla

Recurso formada por el determinante CodRecurso y el atributo dependiente
Recurso.

Tema 3 – Normalización - 66
 Bases de Datos

3FN: Tercera forma normal

§ Una relación R está en tercera forma normal si:

• está en segunda forma normal, y
• no existen dependencias transitivas con respecto de la clave primaria de R.
§ Sea X la clave primaria de R, la dependencia funcional X ª Y, es una
dependencia transitiva con respecto de X, si existe un conjunto de atributos no
primario Z tal que X ª Z y Z ª Y.
§ Normalización: dada una relación R en la que se ha identificado una
dependencia funcional transitiva X ª Y con respecto de la clave primaria PK(R)

Descomponer R en varias relaciones

(1) R1: formada por PK(R) más los atributos que no dependan transitivamente
de ella.
(2) Por cada dependencia funcional transitiva Z ª Y:
crear una tabla Ri formada por el conjunto de atributos determinante Z y el
conjunto de atributos funcionalmente dependiente Y
PK(Ri) = Z

Tema 3 – Normalización - 67
 Bases de Datos

3FN: Tercera forma normal

§ La relación Préstamo, resultante de la normalización a 2FN, no satisface los

criterios establecidos por la 3FN, al ser df1 una dependencia funcional transitiva
con respecto de la clave primaria.

§ Cabe recordar, que en el proceso de determinar el cierre de {CodRecurso,

FechaPréstamo}, se aplicó la siguiente inferencia:
Premisa: df3: {CodRecurso , FechaPréstamo} ª {DNI} Ù
df1: {DNI} ª {Nombre, Apellidos}
Regla: transitiva
Consecuente: dependencia funcional inferida
{CodRecurso , FechaPréstamo} ª {Nombre, Apellidos}

§ por lo que, {Nombre, Apellidos} dependen transitivamente de la PK(Préstamo)

Tema 3 – Normalización - 68
 Bases de Datos

3FN: Tercera forma normal

§ Normalización de Préstamo:
• Crear una tabla formada por PK(R) más los atributos que no dependan
transitivamente de ella.

• Para la dependencia funcional transitiva df1 DNI ª {Nombre, Apelidos}: crear la

tabla Socio formada por el determinante DNI y los atributos dependientes
Nombre, Apellidos.

§ Tras el proceso de normalizar hasta 3FN, de la tabla inicial “Préstamos” se ha

descompuesto en tres tablas: “Préstamo”, “Recurso” y “Socio”, preservando el
conjunto de atributos y dependencias iniciales.

Tema 3 – Normalización - 69
 Bases de Datos

Metodología de diseño

§ Es momento de hacer una reflexión sobre la importancia que tiene seguir las
pautas de diseño vistas a lo largo de la asignatura.
§ Se ha presentado un procedimiento de diseño en el que la definición del
esquema relacional de la base de datos no se hace a ‘fuerza bruta’ y
después se normaliza, sino que, tras (1) un análisis del contexto, (2) una
fase de diseño conceptual y (3) una fase de transformación a diseño lógico
se llega a un diseño que en todos los casos cumple la 1FN y la 2FN, y
según la validad del modelo conceptual de partida hasta la 3FN.
§ Si en el ejemplo planteado, en el que un socio de una biblioteca puede tener
en préstamo varios recursos simultáneamente, hubiéramos efectuado un
diseño conceptual y, aplicando las pautas de transformación, se hubiera
creado (1) una relación asociada al conjunto entidad Recurso, (2) otra al
conjunto entidad Socio y (3) una relación Préstamo como resultado de la
transformación de un conjunto relación prestar entre Recurso(0,N) y
Socio(0,N), con los atributos asociado {FechaPréstamo, FechaEntrega}, se
hubiera llegado al mismo diseño relacional, sin necesidad de normalizar.

Tema 3 – Normalización - 70
Bases de Datos

Metodología de diseño

Tema 3 – Normalización - 71
 Bases de Datos

FNBC: Forma normal de Boyce-Codd

§ Una relación R está en forma normal de Boyce-Codd si todo conjunto de

atributos determinantes es clave candidata.
§ Por lo tanto, busca descomponer relaciones donde el determinante de alguna
df (el que tiene atributos dependientes) no es atributo primario, es decir
cuando no forma parte de la clave primaria de una relación o de la clave
candidata).
§ Normalización: dada una relación R en la que se ha identificado una
dependencia funcional X ª Y, donde X que no es una clave primaria (y tampoco
forma parte de una clave candidata):

Descomponer R en varias relaciones

(1) R1: formada por PK(R) más los atributos que dependan directamente de ella.
(2) Por cada dependencia funcional X ª Y, donde X es atributo no primario:
crear una tabla Ri formada por el conjunto de atributos determinante X y el
conjunto de atributos funcionalmente dependiente Y
PK(Ri) = X

Tema 3 – Normalización - 72
 Bases de Datos

FNBC: Forma normal de Boyce-Codd

§ La FNBC elimina todas las redundancias que se pueden descubrir

estudiando las dependencias funcionales dentro de cada relación, o
tabla (fuera de las claves candidatas - revisar el ejercicio 2 del
documento de los ejercicios para el examen).
§ El problema de las tablas que no cumplen FNBC suele ser que se incluyen
datos de varias entidades en una sola tabla.
§ La solución general es eliminar los campos funcionalmente
dependientes del campo determinante y crear una nueva tabla cuya
clave primaria sea el campo determinante y contenga los campos
funcionalmente dependientes (siempre que no sea un atributo primario).
§ Verificación de la FNBC en la nueva tabla: La nueva tabla creada debe
comprobarse que cumple la FNBC; si no fuera así, debe continuarse el
proceso (¡recordar que se aplica dentro de cada relación existente!).
§ Esto se hará para cada grupo de campos determinantes (fuera de las claves
candidatas) y campos funcionalmente dependientes.

Tema 3 – Normalización - 73
 Bases de Datos

FNBC: Forma normal de Boyce-Codd

Localizacion
Direccion Ciudad CodigoPostal
df1

df2

§ Al hacer el cierre de los atributos determinantes, se ha obtenido la siguiente

superclave mínima (el cierre de “CodigoPostal” no incluye todos los atributos):
SK1: {Direccion, Ciudad}

§ La relación Localizacion satisface los criterios establecidos por la 3FN, ya que no

hay dependencias transitivas de la clave primaria (el determinante de la df2 no
es dependiente de la PK(R)).
§ Sin embargo, la segunda dependencia dependencia funcional
CodigoPostal → Ciudad no satisface la FNCB, ya que CodigoPostal no es un
atributo primario (parte de una superclave mínima).
Tema 3 – Normalización - 74
 Bases de Datos

FNBC: Forma normal de Boyce-Codd

§ Normalización de Localizacion:
• Crear una tabla formada por PK(R) más los atributos que no dependan
directamente de ella.
Localizacion
Direccion Ciudad CodigoPostal
df1

• Para la dependencia funcional df2 y crear la tabla CodigoPostal-Ciudad formada

CodigoPostal y Ciudad, siendo CodigoPostal la superclave mínima (PK).

CodigoPostal-Ciudad
Ciudad CodigoPostal
df2

Tema 3 – Normalización - 75
 Bases de Datos

RESUMEN
• 3. Procedimiento de normalización (descomposición progresiva de
una relación R en varias relaciones, preservando el contenido de la
relación, incluyendo las DFs)
– 1FN = estudiar los atributos para ver si son atómicos (tabla a tabla).
• Atributos compuestos: Generalmente, un atributo para cada componente
• Atributos multievaluados => crear nuevas tablas. ¿CÓMO?
– R1: formada por la PK(R) más los atributos simples de R.
– Por cada atributo multievaluado: una tabla formada por la PK(R) más el atributo
multievaluado. La PK de esta tabla será la unión del PK(R) + atributo multievaluado.
En la Tabla formada, la PK será un FK que referencia a PK(R).
– 2FN = (R cumple 1FN); estudiar si existen DFs que son dependencia
funcional parcial con respecto de la PK(R) (relación a relación). Por lo tanto:
• Si la PK(R) contiene 1 atributo => CUMPLE
• Si la PK(R) está formada por un conjunto de atributos => mirar si alguno de los
atributos que forma parte de la PK(R) es ATRIBUTO DETERMINANTE en otras DFs.
SI EXISTEN => crear nuevas tablas. ¿CÓMO?
– R1: formada por PK(R) más los atributos que dependan totalmente de ella.
– Para cada DF parcial, crear una tabla el conjunto de atributos determinante y el
conjunto de atributos funcionalmente dependiente.
DIAPOSITIVA 76
 Bases de Datos

RESUMEN
– 3FN= (R cumple 2FN); estudiar las dependencias transitivas con
respeto al PK(R). SI EXISTEN => crear nuevas tablas. ¿CÓMO?
– R1: formada por la PK(R) más los atributos que no dependan
transitivamente de ella.
– Por cada DF transitiva: una tabla formada por el conjunto de atributos
determinante de la DF transitiva más los atributos dependientes del
determinante.
– FNBC = (R cumple 3FN) y todo conjunto de atributos determinantes es
clave candidata. En cada relación, ver si existen relaciones que
contienen varias DFs donde uno de los atributos no primarios (el que no
parte de la PK(R) o de la clave candidata) actúa como determinante en
alguna DF. Si existen, crear nuevas tablas: ¿CÓMO?
– R1: formada por la PK(R) más los atributos que dependan directamente
de ella
– (2) Por cada dependencia funcional X ª Y en la que X no es atributo
primario: crear una tabla Ri formada por el conjunto de atributos
determinante X y el conjunto de atributos funcionalmente dependiente Y.
• OBSERVACIÓN: Se debe respetar siempre la semántica definida en las
DFs (no se pueden dividir los atributos determinantes y dependientes
DIAPOSITIVA 77
definidos en las DFs).
Estudiar el recurso Moodle
"T3.2 Normalización - Ejercicios
resueltos (PARA EL EXAMEN)"

DIAPOSITIVA 78
 Repasar los recursos Moodle:
• "T3.2 - Apuntes adicionales y
ejemplos 1FN y FNBC” y
• "T3.2 Ampliación sobre
Normalización resueltos (Ejercicios
resueltos)"

DIAPOSITIVA 79
 Bases de Datos

TEMA 3: DISEÑO DE BBDD RELACIONALES II

1. Modelo Lógico: Pautas para convertir el modelo

conceptual en tablas
2. Normalización: Técnicas para comprobar la calidad final
del diseño
3. Creación de tablas con SQL-DDL (Data Definition
Language). Restricciones. Inserción de datos
 Bases de Datos

T3.3 - Creación de tablas con SQL-DDL.

Restricciones. Inserción de datos

a) Introducción
b) Elementos del lenguaje
c) Lenguaje de Definición de Datos (DDL)

https://www.postgresql.org/docs/current/index.html
 Bases de Datos

Objetos y conceptos

§ Database: conjunto de estructuras, procedimientos y datos, definidos y

organizados para servir un propósito específico.
§ Una conexión cliente sólo puede acceder a la base de datos especificada en
la cadena de conexión.
§ Schema: agrupación de objetos (tablas, tipos de datos, funciones,…) de una
base de datos bajo un espacio de nombre. Permite hacer agrupaciones
funcionales o lógicas de los objetos.
§ Una conexión cliente puede acceder a todos los objetos de la base de datos a
la que está conectada, si tiene privilegios para ello.
§ Table: objeto bidimensional formado por un conjunto de filas (rows) y de
columnas (atributes) utilizado para almacenar datos.
§ Data Type /Domain (tipo de datos o dominio): propiedad que determina el tipo de
información que puede almacenar una columna, un parámetro o una variable.
§ Sequence: objeto utilizado para generar identificadores únicos.
§ View (vista): consulta (SELECT) pre-compilada bajo un nombre, que puede ser
referenciada del mismo modo que una tabla ordinaria.

Tema 3 – SQL-DDL - 82
 Bases de Datos

Objetos y conceptos

§ Index (índice): objeto que proporciona un camino de acceso rápido a las tuplas
de una tabla.
§ Trigger (disparador): función que se ejecuta de forma automática cuando se
produce un evento (INSERT, UPDATE o DELETE) en una tabla o vista.
§ Per-row trigger: la función es invocada automáticamente para cada una de las
tuplas a las que afecta el evento.
§ Per-statement trigger: la función es invocada una única vez cuando se produce
el evento.
§ Function: conjunto de sentencias pre-compiladas bajo un nombre que se
ejecutan como una única unidad. Admite paso de argumentos y devuelve uno o
varios valores de resultado.
§ Stored Proceduce: conjunto de sentencias pre-compiladas bajo un nombre que
se ejecuta como una única unidad. Admite paso de argumentos de entrada y de
salida. No puede formar parte de una sentencia del DML, se debe invocar
explícitamente mediante la sentencia CALL.

Tema 3 – SQL-DDL - 83
 Bases de Datos

SQL: Structured Query Language

§ SQL (Lenguaje de consultas estructurado): lenguaje declarativo de acceso a

Sistemas Gestores de Bases de Datos Relacionales (RDBMS)

§ Lenguaje declarativo: lenguaje de programación que permite especificar qué se

desea hacer o conocer, no cómo hacerlo.

Tema 3 – SQL-DDL - 84
 Bases de Datos

SQL: Structured Query Language

DDL – Lenguaje de definición de datos

§ Objetivo: definir la estructura estática de una base de datos => Esquema

intensional
§ Elemento de operación: estructuras

§ Operaciones de creación, alteración y eliminación de elementos estructurales.

§ CREATE
§ ALTER
§ DROP

Tema 3 – SQL-DDL - 85
 Bases de Datos

SQL: Structured Query Language

DML – Lenguaje de manipulación de datos

§ Objetivo: Manipular la información soportada por una base de datos =>

Esquema extensional
§ Elemento de operación: datos

§ Consultas de selección: permiten recuperar información de registros que

satisfacen los criterios especificados:
§ SELECT
§ Consultas de Acción: permiten realizar operaciones de actualización (inserción,
modificación o borrado) sobre aquellos registros que satisfacen los criterios
especificados.
§ INSERT
§ UPDATE
§ DELETE

Tema 3 – SQL-DDL - 86
 Bases de Datos

SQL: Structured Query Language

OPERACIONES SOBRE OPERACIONES SOBRE

ESTRUCTURAS (DDL) DATOS (DML)

MODIFICACIÓN
CREACIÓN (CREATE) INSERCIÓN (INSERT)
ACTUALIZACIÓN (UPDATE)
ALTERACIÓN (ALTER)
BORRADO (DELETE)
ELIMINACIÓN (DROP)

CONSULTA
SELECCIÓN (SELECT)

Tema 3 – SQL-DDL - 87
 Bases de Datos

PostgreSQL
§ Estándar: ISO/IEC 9075 "Database Language SQL“
§ Versión más reciente: 2011
§ Versión en revisión: 2016
§ El estándar se encuentra estructurado en las siguientes partes:
§ ISO/IEC 9075-1 Framework (SQL/Framework)
§ ISO/IEC 9075-2 Foundation (SQL/Foundation)
§ ISO/IEC 9075-3 Call Level Interface (SQL/CLI)
§ ISO/IEC 9075-4 Persistent Stored Modules (SQL/PSM)
§ ISO/IEC 9075-9 Management of External Data (SQL/MED)
§ ISO/IEC 9075-10 Object Language Bindings (SQL/OLB)
§ ISO/IEC 9075-11 Information and Definition Schemas (SQL/Schemata)
§ ISO/IEC 9075-13 Routines and Types using the Java Language (SQL/JRT)
§ ISO/IEC 9075-14 XML-related specifications (SQL/XML)
§ PostgreSQL cubre las partes 1, 2, 9, 11 y 14.
§ La parte 3 se encuentra cubierta por el driver ODBC.
§ La parte 13 se encuentra cubierta por el plugin PL/Java plug-in

Tema 3 – SQL-DDL - 88
 Bases de Datos

T3.3 - Creación de tablas con SQL-DDL.

Restricciones. Inserción de datos

a) Introducción
b) Elementos del lenguaje
c) Lenguaje de Definición de Datos (DDL)

https://www.postgresql.org/docs/current/index.html
 Bases de Datos

Elementos del lenguaje

§ Una sentencia SQL se encuentra formada por una secuencia de:

§ Palabras reservadas (key words)
§ Identificadores (identifier)
§ Identificadores delimitados (quoted identifier)
§ Literales (literal o constant)
§ Operadores y símbolos especiales.

SELECT * FROM Pelicula;

UPDATE Pelicula SET Presupuesto = 100000 WHERE Id = 122;
INSERT INTO Banda_Sonora VALUES (116, ‘Jaws’, ’original’, 124,’CDROM’);

Tema 3 – SQL-DDL - 90
 Bases de Datos

Identificadores

§ Definición: nombre de un objeto de base de datos

§ Determina de forma única a un objeto dentro de su contexto de aplicación.
§ Solo en algunos objetos (como las restricciones) el identificador es opcional.
§ Longitud máxima: 63 caracteres.
§ Tipos de identificadores en SQL: ordinarios y delimitados

§ Reglas de identificadores
§ Primer carácter: letra ([a-z]) o guion bajo (_).
§ Resto de caracteres: letras ([a-z]), dígitos ([0-9]), guion bajo (_), signo de
dólar ($) (no estándar).
§ No se pueden utilizar palabras reservadas.
§ Todo identificador que no satisfaga estas reglas debe referenciarse delimitado.
§ Los identificadores que satisfacen estas reglas pueden estar o no delimitados.

Tema 3 – SQL-DDL - 91
 Bases de Datos

Identificadores

§ Identificadores ordinarios
§ Siguen las reglas de formato de los identificadores.
§ Insensibles a minúsculas y mayúsculas (case insensitive). Son convertidos a
minúsculas.
§ Ejemplos: Socio, Banda_Sonora

§ Identificadores delimitados
§ Identificadores encerrados entre dobles comillas (“).
§ Pueden estar formados por cualquier secuencia de caracteres.
§ Si el carácter ‘”’ forma parte de la secuencia, deberá escaparse con dos
dobles comillas’””’.
§ Sensible a minúsculas y mayúsculas.
§ Ejemplos: “Nombre y apellidos”, “Número de películas en préstamo”

Tema 3 – SQL-DDL - 92
 Bases de Datos

Nombres de Objetos

§ El nombre completo (o calificado) de un objeto de base de datos se compone de

cuatro identificadores separados por ‘.’:
§ Nombre del servidor
§ Nombre de la base de datos
§ Nombre del esquema
§ Nombre del objeto

<servidor>.<base_datos>.<esquema>.<objeto>

§ El nombre del servidor, base de datos y esquema se denominan calificadores del

nombre del objeto.
§ Los calificadores se pueden omitir, tomando los valores del contexto:
§ <servidor> : servidor local.
§ <base_datos>: base de datos actual, referenciada en la cadena de conexión.
§ <esquema>: determinado por la variable search_path (lista ordenada de
nombres de esquema en la que buscar los objetos no calificados)
Tema 3 – SQL-DDL - 93
 Bases de Datos

Literales

§ Cadena de caracteres (String literal)

§ Secuencia de caracteres encerrada entre comillas simples (‘).
§ Carácter de escape: ‘
§ Literales numéricos (numeric literal)
Literales numéricos ::= digitos |
digitos.[digitos][e[+-]digitos] |
[digitos].digitos[e[+-]digitos] |
digitose[+-]digitos
digitos ::= [0-9]+
-- secuencia de uno o más dígitos decimales (0 a 9)

Tema 3 – SQL-DDL - 94
 Bases de Datos

Literales

§ Fecha (date literal)

§ Formatos no ambiguos soportados: (ISO 8601)
§ YYYYMMDD: date ‘20190424’
§ YYYY-MM-DD: date ‘2019-04-24’
§ Para interpretar otros formatos (YMD; DMY; DMY) configurar el parámetro
DateStyle.
§ Tiempo (time literal)
§ hh:mm:ss: time ‘08:35:44'
§ hhmmss: time '083544’
§ Marca de tiempo (timestamp literal)
§ <date literal> <time literal>
§ timestamp '20190403 083544’
§ timestamp '2019-04-18 08:35:44’
§ timestamp '2019-04-18 083544'
https://www.postgresql.org/docs/current/datatype-datetime.html
Tema 3 – SQL-DDL - 95
 Bases de Datos

T3.3 - Creación de tablas con SQL-DDL.

Restricciones. Inserción de datos

§ Introducción
§ Elementos del lenguaje
§ Lenguaje de Definición de Datos (DDL)

https://www.postgresql.org/docs/current/index.html
 Bases de Datos

DDL - CREATE TABLE

Definición de tabla

CREATE TABLE [ IF NOT EXISTS ] nombre_tabla (

Def_columna [opciones_tabla ]
[ CONSTRAINT nombre_restriccion ] Rest_tabla
,
)

Definición de columna

Def_columna ::= nombre_columna { tipo_dato | nombre_dominio }

[ DEFAULT expresión ]
[ CONSTRAINT nombre_restriccion ] Rest_columna

Tema 3 – SQL-DDL - 97
 Bases de Datos

DDL - CREATE TABLE

Rest_columna ::=
PRIMARY KEY
UNIQUE
NOT NULL | NULL
CHECK expresión
REFERENCES nombre_tabla ( nombre_columna )
[ ON DELETE {NO ACTION | CASCADE | RESTRICT | SET NULL | SET DEFAULT}]
[ ON UPDATE {NO ACTION | CASCADE | RESTRICT | SET NULL | SET DEFAULT}]

Tema 3 – SQL-DDL - 98
 Bases de Datos

DDL - CREATE TABLE

Rest_tabla ::=
PRIMARY KEY ( nombre_columna )
,
UNIQUE
CHECK expresión
FOREIGN KEY ( nombre_columna )
,
REFERENCES nombre_tabla ( nombre_columna )
,
[ ON DELETE {NO ACTION | CASCADE | RESTRICT | SET NULL | SET DEFAULT}]
[ ON UPDATE {NO ACTION | CASCADE | RESTRICT | SET NULL | SET DEFAULT}]

Tema 3 – SQL-DDL - 99
 Bases de Datos

DDL - Tipos de Datos

Tipos Numéricos
§ Smallint: 2 bytes; valores de -32768 a +32767
§ Integer: 4 bytes; valores de -2147483648 a +2147483647
§ Bigint: 8 bytes ; valores de -9223372036854775808 a +9223372036854775807
§ Numeric: longitud variable; valores exactos, hasta 131072 dígitos antes del
delimitador decimal y hasta 16383 dígitos tras el delimitador decimal.
§ Real: 4 bytes; valores inexactos, 6 dígitos decimales
§ Double precision: 8 bytes; valores inexactos, 15 dígitos decimales
§ Smallserial: 2 bytes; valores de 1 a 32767 (autoincrement)
§ Serial: 4 bytes; valores de 1 a 2147483647 (autoincrement)
§ Bigserial: 8 bytes; valores de 1 a 9223372036854775807 (autoincrement)
https://www.postgresql.org/docs/current/datatype-numeric.html

Tipos Lógicos
§ boolean: TRUE, FALSE
https://www.postgresql.org/docs/current/datatype-boolean.html
Tema 3 – SQL-DDL - 100
 Bases de Datos

DDL - Tipos de Datos

Tipos Cadenas Caracteres
§ Character(n), char (n): cadena de longitud fija de hasta n caracteres, n <1GB.
§ Character varying (n), varchar (n): cadena de longitud variable de hasta n
caracteres, n <1GB.
§ Text: cadena de longitud variable ilimitada.
https://www.postgresql.org/docs/current/datatype-character.html

Tipos Fechas y marcas de tiempo

§ Interval: 16 bytes; resolución 1 µs.
§ Time: 8 |12 bytes; resolución 1 µs.
§ Date: 4 bytes; resolución 1 día.
§ Timestamp: 8 bytes; resolución 1 µs.
https://www.postgresql.org/docs/current/datatype-datetime.html

Tema 3 – SQL-DDL - 101

 Bases de Datos

DDL - CREATE TYPE

§ Registra un nuevo tipo de datos para ser usado en la base de datos

§ Tipo enumerado: lista de literales que definen el conjunto de valores posibles.

CREATE TYPE nombre_tipo_enum AS ENUM ( ‘literal’ )

,

Tema 3 – SQL-DDL - 102

 Bases de Datos

DDL - CREATE DOMAIN

§ Dominio: tipo de datos con restricciones

CREATE DOMAIN nombre_dominio AS tipo_dato

[ DEFAULT expresión ]
[ CONSTRAINT nombre_restriccion ] NOT NULL | NULL | CHECK expresión

Tema 3 – SQL-DDL - 103

 Bases de Datos

DDL - CREATE TABLE

RC
RC

RC
RC
RC
RC
RC
RT

RC

RC
RC

RC
RC
RT

Tema 3 – SQL-DDL - 104

 Bases de Datos

Restricciones de Integridad

Inherentes:
• No existen dos o más tuplas iguales
• Los atributos son atómicos
• Ser clave
• De Entidad
• De Dominio

De usuario:
• De referencia
• Entre atributos de una relación
• Entre tuplas de una relación
• Entre atributos de distintas relaciones

Tema 3 – SQL-DDL - 105

 Bases de Datos

Restricciones de Integridad

§ Restricción de Ser Clave

§ Aplicable a todas la Claves Candidatas (CK).
§ El valor que tome cada clave debe ser único para cada tupla de la relación.
§ Restricción SQL: UNIQUE

§ Restricción de Entidad
§ Aplicable a la Clave Primaria (PK).
§ El valor que tome la clave primaria nunca puede ser nulo (NOT NULL).
§ Restricción SQL: PRIMARY KEY (UNIQUE + NOT NULL)

Tema 3 – SQL-DDL - 106

 Bases de Datos

Restricciones de Integridad
§ Restricción de Referencia
Un conjunto de atributos FK de T1 es una Clave Extranjera de T, si verifica:
§ Los atributos de FK tienen el mismo dominio que la Clave Primaria de T –
T(PK) -.
§ Para toda tupla t1 de T1 existe una tupla t de T tal que se verifica que el valor
que toma FK en t1 es igual al valor que toma PK en t.
§ Restricción SQL: FOREIGN KEY(…,….) REFERENCES T(PK)

§ Problemas con las operaciones de actualización (ON UPDATE) o eliminación

(ON DELETE) de tuplas referenciadas.
§ No realizar operación (NO ACTION)
§ Operación Restringida (RESTRICT)
§ Operaciones con transmisión en Cascada (CASCADE)
§ Operaciones que desencadenan un procedimiento automático
§ Operaciones con puesta a NULL (SET NULL)
§ Operaciones con puesta a un valor por defecto (SET DEFAULT)

Tema 3 – SQL-DDL - 107

 Bases de Datos

Restricciones de Integridad
§ Restricción entre atributos de una relación
§ Establece una condición sobre dos atributos de la relación
§ Restricción SQL: CHECK

CREATE TABLE productos (

numProducto serial PRIMARY KEY,
nombre text NOT NULL,
precio numeric CONSTRAIN precioPosiftivo CHECK (precio > 0),
descuento numeric CONSTRAIN descuentoPositivo CHECK (descuento > 0),
CONSTRAIN precioMayorDescuento CHECK (precio > descuento)
);

Tema 3 – SQL-DDL - 108

 Bases de Datos

DML - INSERT INTO

Insertar valores dentro de una tabla existente:

INSERT INTO nombre_tabla | [(nombre_columna [, …])]

VALUES ({expression | DEFAULT} [,…]) [,…] | query } )

INSERT INTO nombre_tabla (nombre_col1, nombre_col2, …, nombre_colN)

VALUES (valor1, valor2, …, valorN)

Los atributos de tipos smallserial, serial y bigserial se omiten en las sentencias INSERT

https://www.postgresql.org/docs/14/sql-insert.html
Tema 3 – SQL-DDL - 109
1. Acceder a la carpeta Moodle
“T3.3 Ejercicios SQL-DDL resueltos”

2. Hacer los ejercicios propuestos en

el fichero “T3.3-ejercicios-SQL-DDL-
resueltos.pdf”

DIAPOSITIVA 110