Tema3 Disenio Logico BBDD Modelo Relacional

Diseño Lógico de Bases de
Datos – Modelo Relacional

Índice
1. El modelo relacional.
2. Transformación E/R al modelo relacional.
3. Normalización.
Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 2

Objetivos
Aplicar reglas de integridad.
Identificar reglas de normalización.
Identificar y documentar reglas que no se pueden plasmar
en el diseño lógico

1. El Modelo Relacional
1. Las relaciones en el modelo relacional
2. Otros conceptos del modelo relacional
El objetivo principal del modelo relacional es proteger al
usuario de la obligación de conocer las estructuras de
datos físicas con las que se representa la información de
una BBDD, así se permite que la BBDD pueda
implementarse en cualquier gestor de BBDD relacional
(SQL). Las características de este modelo son:
La relación es el elemento fundamental del modelo. Estas
relaciones se pueden operar mediante el Álgebra
Relacional.
El modelo relacional es independiente de la forma en que se
almacenan los datos y de la forma de representarlos, por
tanto la BBDD se puede representar en cualquier SGBD .

Al estar fundamentado en una fuerte base matemática, se
puede demostrar la eficacia del modelo a la hora de operar
conjuntos de datos.

1.1. Las Relaciones en Mod. Relacional
Se define una relación como un conjunto de atributos,
cada uno de los cuales pertenece a un dominio, y que
posee un nombre que identifica la relación. Se representa
gráficamente por una tabla con columnas (atributos) y
filas (tuplas). El conjunto de tuplas de una relación
representa el cuerpo de la relación y el conjunto de
atributos y el nombre representan el esquema.
Actualmente los modelos lógicos más extendidos con
diferencia son el modelo relacional y los diagramas de
clases que utiliza UML para modelar las BBDD orientadas a
objetos. El modelo relacional de Codd se ajusta a la
perfección al modelo E/R de Chen.

1.1. Las Relaciones en Mod. Relacional
RELACIÓN ALUMNOS Nombre
Esquema
MATRÍCULA NOMBRE APELLIDOS CURSO NOTA Atributos
3256 José Pérez de Lastra 1 5,25

0101 María Anúnez Sastre 2 7,80 Tuplas
8743 Lourdes Sánchez Argote 1 4,50
1234 Antonio Soria Madrid 3 6,35

Estado
5674 Luis González Silos 1 3,25 Cuerpo
0678 Pilar Alcántara Badajoz 2 5,50
0346 Dolores Almiz Márquez 3 7,30
2985 Manuel Rivas Fuentes 3 3,50

1.2. Otros conceptos
Vamos a definir los conceptos necesarios para transformar
el modelo conceptual (diagrama E/R) en el modelo lógico
(modelo relacional).
Atributos: características que describen a una entidad o
relación.
Dominio: conjunto de valores permitidos para un atributo.
Por ejemplo, cadena de caracteres, número enteros, los
valores Sí o No, etc.
Restricciones de semántica: condiciones que deben
cumplir los datos para su correcto almacenamiento. Hay
varios tipos:
Restricciones de clave: es el conjunto de atributos que
identifican de forma única a una entidad.

Restricciones de valor único (UNIQUE): impiden que un atributo
tenga un valor repetido. Todos los atributos clave cumplen esta
restricción. Puede ser que para algún atributo que no sea clave
sea necesaria esta restricción, por ejemplo, el número de
bastidor de un coche, que no es clave principal, lo es matrícula,
no se puede repetir.
Restricciones de integridad referencial: se da cuando una tabla
tiene una referencia a algún valor de otra tabla. En este caso la
restricción exige que exista el valor referenciado a la otra tabla.
Por ejemplo, no se puede poner una nota a un alumno que no
exista.
Restricciones de dominio: exige que el valor que puede tomar
un campo esté dentro del dominio definido. Por ejemplo, si se
establece que un campo DNI pertenece al dominio de los
números de 9 dígitos + 1 letra no es posible insertar un DNI sin
letra.

Restricciones de verificación (CHECK): permiten
comprobar si un valor de un atributo es válido conforme a
una expresión.
Restricción de valor NULO (NULL o NOT NULL): un
atributo puede ser obligatorio si no admite el valor NULO
o NULL. Si admite como valor el valor NULL el atributo es
opcional.
Disparadores o triggers: son procedimientos que se
ejecutan para hacer una tarea concreta en el momento
de insertar, modificar o eliminar información de un tabla.
Restricciones genéricas adicionales o aserciones
(ASSERT): permite validar cualquiera de los atributos de
una o varias tablas.

Clave: una clave es un atributo o conjunto de atributos que
identifican de forma única una ocurrencia de entidad. Las
claves pueden ser simples (atómicas) o compuestas. Hay
varios tipos de claves:
Superclave: identifican a una entidad. Por ejemplo, para un
empleado, las superclaves posibles son el DNI, o el
DNI+Nombre o el DNI+Nombre+Número de la Seguridad
Social, etc.
Clave Candidata: La clave candidata de una relación es el
conjunto de uno o más atributos que determinan unívoca y
mínimamente cada tupla. Siempre hay una clave candidata pues
por definición no puede haber dos tuplas iguales En una
relación pueden existir varias claves candidatas.

EMPLEADOS (CÓDIGO, DNI, DIRECCIÓN, TFNO, SUELDO,
COMISIÓN)
En esta relación podrían ser claves candidatas tanto código
como DNI. Ambas son claves candidatas.
Clave Primaria: es la clave candidata elegida por el diseñador
como clave definitiva, en el ejemplo anterior se elegiría Código
y se representa subrayada. A la clave candidata no elegida
como clave primaria se le llama clave alternativa.
Clave Ajena o Foránea: es un atributo de una entidad, que es
clave en otra entidad.
Por ejemplo,
EMPLEADOS (COD-EMP, DNI, NOMBRE, TFNO, COD-DEP)
DEPARTAMENTOS (COD-DEP, NOMBRE, LOCALIDAD)
COD-DEP: clave ajena que referencia a COD-DEP

Ejemplo
EDITORIAL (cod_edit, nombre, dirección, ciudad)
LIBRO (código, título, idioma, cod_edit)
ESCRIBE (cod_autor, cod_libro)
AUTOR (cod_autor, nombre, nacionalidad)
Cod_edit: clave ajena que referencia a cod_edit de la
tabla EDITORIAL.
Cod_libro: clave ajena que referencia a código de la
tabla LIBRO.
Cod_autor: clave ajena (ESCRIBE) que referencia a
cod_autor de la tabla AUTOR.

Para las claves ajenas existe la regla de Integridad referencial
que establece que los valores de la clave ajena o bien coinciden
con los de la clave primaria a la que referencian o bien son
nulos. Por tanto, para cada clave ajena se debe especificar si
puede o no tomar valores nulos. Además, es necesario
determinar las consecuencias de ciertas operaciones (borrado y
modificación) realizadas sobre tuplas de la relación referenciada.
Se puede distinguir entre:

Operación restringida (RESTRICT): el borrado o modificación
de tuplas de la relación que contiene la clave primaria referenciada
solo se permite si no existen tuplas con dicha clave en la relación
que contiene la clave ajena. Ejemplo: en el caso anterior esto
implicaría que solo podemos borrar una editorial que no tenga
ningún libro , de haberlo, el sistema impediría el borrado.
Operación con transmisión en cascada (CASCADE): el
borrado o modificación de tuplas de la relación que contienen la
clave primaria referenciada lleva consigo el borrado o modificación
en cascada de las tuplas de la relación que contienen la clave ajena.
Ejemplo: en el caso anterior al modificar el código de una editorial,
se debe modificar también dicho código en todos los libros de
nuestra Base de Datos que sean de dicha editorial.

Operación con puesta a nulos (SET NULL): el borrado o
modificación de tuplas que contienen la clave primaria referenciada
lleva consigo “poner a nulos” los valores de las claves ajenas de la
relación que referencia. Ejemplo: en el caso anterior cuando se
borra una editorial, a todos aquellos libros que sean de esa editorial
y que se encuentran en la relación LIBROS se les colocaría el
atributo cod_edit a nulo. Esta opción solo es posible cuando el
atributo que es clave ajena admite el valor nulo.
Operación con puesta a valor por defecto (SET DEFAULT): el
borrado o modificación de tuplas que contienen la clave primaria
referenciada lleva consigo “poner al valor por defecto a la clave
ajena de la relación que referencia” valor por defecto que habrá
sido definido al crear la tabla correspondiente.

Operación que desencadena un procedimiento de usuario: el
borrado o modificación de tuplas que contienen la clave primaria
referenciada lleva consigo la puesta en marcha de un procedimiento
definido por el usuario.
Las opciones seleccionadas para el borrado y modificación son
independientes.

2. Transformación de un diagrama
E/R al modelo relacional
2. Transformación del modelo E/R al
modelo relacional
La transformación del modelo conceptual (E/R) al modelo lógico
(relacional) se basa en las siguientes reglas:
Toda entidad se transforma en una relación.
Todo atributo se transforma en columna dentro de una
relación.
Los atributos AIP (atributo identificador principal), se
convierten en Clave Primaria y los AIA (atributos identificador
alternativo) en Clave alternativa.
Toda relación N:M se transforma en una relación que
tendrá como clave primaria la concatenación de los atributos
clave de las entidades que asocia.

modelo relacional
Cod_articulo
Cod_cliente Dirección N:M Precio
(0,n) (1,n)
COMPRA
CLIENTE ARTÍCULO
Fecha_venta
Uni_vend Stock Denominación
Nombre
Para el diagrama E/R, las relaciones generadas son:

CLIENTES (Cod_cliente, Nombre, Dirección)
ARTÍCULOS (Cod_articulo, Precio, Stock, Denominación)
COMPRAS (Cod_cliente, Cod_articulo, Uni_vend,
Fecha_venta)

modelo relacional
Transformación de entidades fuertes (no débiles):
Para cada entidad A, entidad fuerte, con atributos (a1,
a2,...,an) se crea una relación A (con el nombre en plural)
con n columnas correspondientes a los atributos de A, donde
cada fila de la relación A corresponde a una ocurrencia de la
entidad A. La clave primaria de la relación A la forman los
atributos clave de la entidad A.

modelo relacional
código nombre
descripción 1:N código
(1,1) (0,n)
pertenece
CATEGORÍA PRODUCTO
precio
En el diagrama E/R, las relaciones generadas son (sin

tener en cuenta relaciones nuevas o claves ajenas):
CATEGORÍAS (código, descripción)
PRODUCTOS (código, nombre, precio)

modelo relacional
Relaciones con cardinalidad 1:N. Existen dos soluciones:
Transformar la interrelación en una relación: se hace
como si se tratara de una relación N:M. Esta solución se
puede elegir cuando se prevé que en un futuro la relación se
convertirá en N:M y cuando la interrelación tiene
atributos propios que no interesa que se propaguen.
También se crea una nueva relación cuando la
cardinalidad es opcional en el lado del 1, es decir
(0,1) . La clave de esta relación es la de la entidad del lado
N.

modelo relacional
Num_factura Fecha_venta
Fecha_emisión 1:N Num_albarán
(0,1)
(0,n)
asocia
FACTURA ALBARÁN
Total_factura descuento
Total_albarán
FACTURAS (Num_factura, Fecha-emisión, Total-factura)

ALBARANES (Num_albarán, Fecha-venta, Total-albarán)
FACTURA-ALBARÁN (Num_albarán, Num_factura, Descuento)
Donde Num-albarán es la Clave Principal, y tanto
Num_albarán como Num-factura son claves ajenas que
referencian a sus respectivas relaciones.

modelo relacional
Relaciones con cardinalidad 1:N, otra solución :
Propagar la clave: este caso se aplica siempre cuando la

cardinalidad es obligatoria en el lado del 1, es decir, cuando
tenemos cardinalidad (1,1). Se propaga el atributo principal
de la entidad que tiene cardinalidad máxima 1 a la relación
que genera la entidad que tiene cardinalidad máxima N. Si
existen atributos propios en la relación, estos también se
propagarán. El caso anterior también se podría hacer así si
no hubiera restricciones de atributos a nulo (NOT NULL).

modelo relacional
Título Director
Editor 1:N Nombre
({0/1},N)
(1,1)
edita
REVISTA EDITORIAL
Ejemplares
Dirección
EDITORIALES (Nombre, Director, Dirección)

REVISTAS (Título, Editor, Ejemplares, Nombre_edit)
Donde Nombre_edit es una clave ajena que referencia a la
relación EDITORIALES

modelo relacional
Cod_tema Num_ejemplares
Descripcion 1:N Cod_libro
(1,1)
(0,n)
clasifica
TEMA LIBRO ISBN
Autor Título
TEMAS (Cod_tema, Descripción)

LIBROS (Cod_libro, Autor, ISBN, Título,
Num_ejemplares, Cod_tema)
Se propaga la clave, de la entidad TEMA a la entidad LIBRO.

modelo relacional
En la transformación de relaciones 1:1 se tiene en cuenta las
cardinalidades de las entidades que participan. Existen dos soluciones:
Transformar la interrelación en una relación: si ambas
entidades poseen cardinalidades (0,1).
Propagar la clave: si una de las entidades posee cardinalidad
(0,1) y la otra (1,1), conviene propagar la clave de la entidad con
cardinalidad (1,1) a la relación resultante de la entidad de
cardinalidad (0,1). Si ambas entidades poseen cardinalidades (1,1),
se puede propagar la clave de cualquiera de ellas a la tabla
resultante de la otra. En este caso (1,1), también se pueden
añadir los atributos de una entidad a otra, resultando una única
tabla con todos los atributos de las entidades y de la relación, si los
hubiera, eligiendo como clave primaria una de las dos.

modelo relacional
Nombre 1:1 Num_historial
Cod_paciente
(1,1)
(1,1)
tiene
PACIENTE H. MEDICO
Teléfono Dirección Localización

o
PACIENTES (Cod_paciente, Nombre, Teléfono,

Dirección, Num_historial, Localización)
Donde Cod_paciente será la Clave Principal.

modelo relacional
1:1
Marca
NIF Nombre Codigo
(1,1) (0,1)
mantiene
EMPLEADO ELECTRODOM
Nombre
ÉSTICO
Nivel Ocupación Modelo
EMPLEADOS (NIF, Nombre, Ocupación, Nivel)

ELECTRODOMÉSTICOS (Código, Nombre, Marca,
Modelo, NIF)
Donde NIF será la C. Ajena que referencia a EMPLEADO

modelo relacional
Ejercicios 1
Un empleado ocupa un solo puesto de trabajo, y ese
puesto de trabajo es ocupado por un solo empleado o
por ninguno. De los empleados queremos guardar su
código, nombre, dirección y teléfono. Del puesto de
trabajo el código, descripción, oficina, despacho y
mesa. Realiza el Modelo E/R y transfórmalo al Modelo
Relacional.

modelo relacional
Ejercicios 2
Se desea mecanizar la biblioteca de un centro educativo. En la
biblioteca existen fichas de autores y libros. Un autor puede escribir
varios libros, y un libro puede ser escrito por varios autores. Un
libro está formado por ejemplares que son los que se prestan a los
usuarios. Así un libro tiene muchos ejemplares y un ejemplar
pertenece solo a un libro. De los ejemplares nos interesa saber la
localización dentro de la biblioteca y el número del ejemplar. Los
ejemplares son prestados a los usuarios, un usuario puede tomar
prestados varios ejemplares y un ejemplar puede ser prestado a
varios usuarios. Del préstamo nos interesa saber la fecha de
préstamo y la de devolución.

modelo relacional
Relaciones Reflexivas o recursivas: son relaciones
binarias en las que participa un tipo de entidad. En el
proceso de convertir una relación reflexiva a tabla hay que
tener en cuenta sobre todo la cardinalidad. Lo normal es
que toda relación reflexiva se convierta en dos tablas, una
para la entidad y otra para la relación. Se puede presentar
los siguientes pasos:
Si la relación es 1:1, la clave de la entidad se repite, con lo
que la tabla resultante tendrá dos veces ese atributo, una
como clave primaria y otra como clave ajena de ella misma.
No se crea la segunda tabla.

modelo relacional
Si la relación es 1:N, podemos tener dos casos:
Caso de que la entidad 1 sea siempre obligatoria se procede
como en el caso 1:1
Si no es obligatoria, caso 0,1, se puede crear una nueva
tabla cuya clave será la de la entidad del lado muchos, y
además se propaga la clave a la nueva tabla con un nuevo
nombre como clave ajena.
Si es N:M se trata igual que en las relaciones binarias. La
tabla resultante de la relación contendrá dos veces la clave
primaria de la entidad del lado muchos, más los atributos
de las relaciones si los hubiera. La clave de esta nueva
tabla será la combinación de las dos.
modelo relacional
Ejemplo1:
Consideramos la relación Empleado-dirige-empleado. Un
empleado puede dirigir a muchos empleados o a ninguno. Y
un empleado es dirigido por un director o por ninguno si él
es el que dirige. En este caso no hay obligatoriedad en la
entidad muchos. El Modelo E/R es:
Tlf (0,N) 1:N
EMPLEADO Dirige
(0,1)
Nombre
Cod_emple Dirección

modelo relacional
La relación DIRIGE tiene como clave primaria el código de
empleado, que a su vez será clave ajena. Además, se le
añade el código de empleado pero, en este caso, tendrá el
papel de director, que a su vez será clave ajena a la tabla
EMPLEADO. El resultado será:
EMPLEADO (cod_emple, dirección, teléfono, nombre)
DIRIGE (cod_emple(FK), cod_direc(FK))
Si fuese (1,1) o en caso de haber pocos empleados sin director
haríamos la solución de propagar la clave. Hacemos ese caso.

modelo relacional
Ejemplo2:
Consideramos la relación una pieza se compone de muchas
piezas, que a su vez están compuestas de otras piezas, es
decir Pieza_Compone_Pieza. El Modelo E/R es:
color (0,N) N:M
PIEZA (0,N) COMPONE
tamaño
Cod_pieza Descripción

modelo relacional
PIEZA (cod_pieza, descripción, tamaño, color)
COMPONE_PIEZA (cod_pieza_comp(FK), cod_pieza(FK))
Cod_pieza_comp y cod_pieza son clave ajenas y representan cada

código de pieza que esté compuesto por otras piezas
(Cod_pieza_comp) y cada pieza que lo compone (cod_pieza).
Ambas concatenadas constituyen la clave de la relación.

modelo relacional
Transformación de otros elementos del modelo E-R
Jerarquías al modelo relacional
El modelo relacional no dispone de mecanismos fáciles de usar
que permitan la representación de relaciones jerárquicas, por lo
tanto se tienen que eliminar. Para pasar estas relaciones al
modelo relacional se aplicará una de las siguientes reglas:
ANIMAL código
tipo
color GATO ÁGUILA DELFÍN comida
alas

modelo relacional
Integrar todas las entidades en una única eliminando los
subtipos. Esta nueva entidad contendrá todos los atributos del
supertipo, todos los de los subtipos, y los atributos discriminativos
para distinguir a qué subentidad pertenece cada atributo. Todas las
relaciones se mantiene con la nueva entidad. Para exclusivas:
ANIMALES (código, tipo, color, alas, comida)
Eliminación del supertipo, transfiriendo los atributos del
supertipo a cada uno de los subtipos. Las relaciones del supertipo
se consideran para cada uno de los subtipos. Solo puede ser
aplicada para jerarquías totales y exclusivas.
GATOS (código, color)
AGUILAS (código, alas)
DELFINES (código, comida)

modelo relacional
Insertar una relación 1:1 entre el supertipo y cada uno de los
subtipos. Los atributos se mantienen y cada subtipo se identificará
con la clave ajena del supertipo. El supertipo mantendrá una
relación 1:1 con cada subtipo. Los subtipos mantendrán, si la
relación es exclusiva, la cardinalidad mínima 0, y si es inclusiva 0 ó
1.
ANIMALES (código)
GATOS (código (FK), color)
AGUILAS (código(FK), alas)
DELFINES (código(FK), comida)

modelo relacional
Transformación de otros elementos del modelo E/R
Relaciones N-arias
En este tipo de relaciones se agrupan 3 o más entidades y para
pasar al modelo de datos relacional cada entidad se convierte
en una relación, así como la interrelación, que va a contener los
atributos propios de ella más las claves de todas las entidades.
La clave de la tabla resultante será la concatenación de las
claves de las entidades. Hay que tener en cuenta que:
Si la relación es N:N:N, es decir, si todas las entidades participan
con cardinalidad N, la clave de la tabla resultante es la unión de las
claves de las entidades que relaciona. Esa tabla incluirá los
atributos de la relación si lo hubiera.

modelo relacional
Ejemplo Descripción
N:M:P Cod_curso
Cod_profesor Nombre
(1,N) (1,N)
Imparte
PROFESOR CURSO
(1,N)
Turno
Dirección Nivel
Tlf ASIGNATURA
Especialidad
Nombre
Cod_asignatura
PROFESORES (cod_profesor, dirección, nombre, tlf, especialidad)

CURSOS (cod_curso, descripción, nivel, turno)
ASIGNATURAS(Cod_asignatura, nombre)
IMPARTE (cod_profesor(FK), cod_curso(FK), cod_asignatura(FK))

modelo relacional
Ejemplo Fecha_venta
Forma_pago
1:N:M Cod_coche
Cod_empleado Nombre modelo
(1,1) (1,N)
Venta
EMPLEADO COCHE
(1,N)
precio
Salario Matrícula
CLIENTE
Tlf Fecha_alta
Nombre
Cod_cliente
CLIENTES (cod_cliente, nombre),

EMPLEADO (cod_empleado, tlf, salario, fecha_alta)
COCHES(Cod_coche, modelo, matrícula, precio)
VENTA (cod_coche(FK), cod_cliente(FK), cod_empleado(FK),
forma_pago, fecha_venta)

modelo relacional
Resumen
MODELO ENTIDAD RELACIÓN MODELO RELACIONAL

ENTIDAD TABLA
1:N Propagar la clave: clave ajena (tabla con N), o bien otra tabla
1:1 Propagar la clave: clave ajena, o bien otra tabla o bien uniendo las dos entidades en una tabla
BINARIAS
N:M Otra tabla nueva, con clave primaria igual a la suma de las claves primarias de las dos tablas
Relaciones
1:N Clave ajena o bien otra tabla

REFLEXIVA 1:1 Clave ajena o bien otra tabla
S
N:M Otra tabla nueva, relación con clave principal igual a la clave principal de la entidad duplicada
Se crea una tabla nueva y a la hora de elegir la clave se tendrá en cuenta:
TERNARIAS 1.- Concatenación de claves primarias de las entidades, con grado diferente a 1 (N,M,P...)
2.- Si alguna tiene cardinalidad máxima 1, al menos ha de haber (N-1) claves primarias de otras (N-
1) entidades, y han de participar en la relación las claves primarias de las entidades con cardinalidad
máxima 1.

3. Normalización
1. Teoría de la Normalización.
2. Noción intuitiva de las Formas Normales.
3. Primera Forma Normal.
4. Segunda Forma Normal.
5. Tercera Forma Normal.
6. Forma Normal de Boyce-Cood.
7. Otras Formas Normales.
3.1. Teoría de la Normalización
La Teoría de la normalización define una serie de reglas que
debe cumplir un modelo relacional para garantizar:
Que no existen redundancias en la base de datos, con lo que se
disminuye el espacio requerido para el almacenamiento de la
información y se reducen los problemas de integridad de la
información almacenada en la base de datos.
Que se representa de forma coherente los objetos y relaciones
existentes en el sistema.
Que el rendimiento de las operaciones de actualización es el
máximo posible.
Que las operaciones de consulta son fiables y su rendimiento es el
máximo posible

3.1. Teoría de la Normalización
A este conjunto de reglas se les denomina Reglas de
normalización de relaciones. Se dice que una relación está en
una determinada forma normal si satisface un cierto conjunto
específico de restricciones impuestas por la regla de
normalización correspondiente.
La sucesiva aplicación de las reglas de normalización,
empezando por la Primera Forma Normal, da lugar a un mayor
número de relaciones en el esquema que satisfacen dichas
reglas.

3.2. Noción intuitiva de las F.N.
La primera forma normal 1FN prohíbe que en un registro
haya grupos repetitivos, es decir, “todos los campos
deben ser atómicos”. Por ejemplo, dado el siguiente
registro que no se encuentra en 1FN existen tres
opciones en 1FN, a, b y c (más adelante veremos cuál
es la mejor en cada ocasión):
COD_EMP NOMBRE IDIOMA
5050 M. DORADO ITALIANO

ESPAÑOL
6969 P. SUAREZ ESPAÑOL
… … …

a) COD_EMP NOMBRE IDIOMA
5050 M. DORADO ITALIANO
5050 M. DORADO ESPAÑOL
b)
COD_EMP NOMBRE COD_EMP IDIOMA
5050 M. DORADO 5050 ITALIANO
6969 P. SUAREZ 5050 ESPAÑOL
6969 ESPAÑOL
… … … …

c) COD_EMP NOMBRE IDIOMA1 IDIOMA2
5050 M. DORADO ITALIANO ESPAÑOL
… … … …

Decimos que un registro está en Segunda Forma Normal (2FN)
si, además de estar en 1FN, todos los campos que no forman
parte de ninguna clave suministran información acerca de la
clave completa. Por ejemplo, en el registro:
VENTAS(COD_PIEZA, COD_ALMACEN, CANTIDAD,
DIRECCION_ALMACEN)
donde la clave está formada por los campos COD_PIEZA y
COD_ALMACEN, la dirección del almacén DIRECCION_ALMACEN es
un hecho acerca sólo del almacén no de la pieza, por lo que el
registro no está en 2FN. Para conseguirlo tendríamos que
descomponer en:
N_VENTAS(COD_PIEZA, COD_ALMACEN, CANTIDAD)
ALMACENES(COD_ALMACEN, DIRECCION_ALMACEN)

Decimos que un registro está en Tercera Forma Normal (3FN) si,
además de estar en 2FN, todos los campos que no forman parte
de ninguna clave deben facilitar información sólo acerca de la(s)
clave(s), y no acerca de otros campos. En otras palabras, sus
campos deben ser mutuamente independientes y completamente
dependientes de la(s) clave(s). Por ejemplo, el registro
siguiente, cuya clave es COD_EMPLEADO no esta en 3FN puesto
que el nombre del departamento es un hecho acerca del código
del departamento que no es clave.
EMPLEADOS(COD_EMPLEADO, COD_DEPARTAMENTO,
NOMBRE_DEPARTAMENTO)

Para conseguir la 3FN realizamos la siguiente
descomposición:
N_EMPLEADOS(COD_EMPLEADO, COD_DEPARTAMENTO)
DEPARTAMENTOS (COD_DEPARTAMENTO,
NOMBRE_DEPARTAMENTO)

Dependencias funcionales
Son de primordial importancia a la hora de encontrar y
eliminar la redundancia de los datos almacenados en las
tablas de una base de datos relacional, se centran en el
estudio de las dependencias que presenta cada atributo de
una relación con respecto al resto de atributos de la misma.
Dada una relación R que contiene los atributos X e Y se dice
que Y depende funcionalmente de X (X Y) si y sólo si en
todo momento cada valor de X tiene asociado un solo valor
de Y. Esto es lo mismo que decir que si dos tuplas de R
tienen el mismo valor para su atributo X forzosamente han
de tener el mismo valor para el atributo Y.

Tipos de dependencias:
Dependencias completa y parcial: Dado un atributo
compuesto X formado por los atributos X1 y X2, se dice
que el atributo Y tiene una dependencia funcional
completa con respecto a X si : X1 -/→ Y; X2 -/→ Y;
Y-/ → X (Y no implica X) pero X → Y
Por el contrario dado un atributo compuesto X formado
por los atributos X1 y X2, se dice que el atributo Y tiene
una dependencia funcional parcial con respecto a X si
X1 → Y ó X2 → Y y X → Y

Tipos de dependencias:
Dependencia Transitiva: dados los atributos X, Y y Z
de la relación R en la que existen las siguientes
dependencias funcionales X Y; Y Z; se dice que Z
tiene una dependencia transitiva respecto a X a través de
Y:X Z. Por ejemplo:
Nombre de alumno Dirección
Dirección Ciudad
Nombre de alumno Ciudad.

Existen seis niveles de normalización de una relación, que se
muestran en la figura. Una relación se encuentra en un grado u
otro de normalización si cumple una serie de propiedades
(restricciones) que se explican a continuación.
1FN
2FN
3FN
FNBC
4FN
5FN

Las tres primeras formas normales las definió Codd y se basan
en las dependencias funcionales que existen entre los atributos
de la relación. Más tarde, y debido a que todavía existían
anomalías, redefinió la 3FN y la llamó FNBC. Posteriormente se
definieron dos niveles más de normalización, la 4FN y la 5FN.
De esta forma, las relaciones en 1FN tienen más redundancia de
datos que los niveles superiores, y por lo tanto más anomalías
de actualización de datos. Y la 5FN es el grado de normalización
máximo que puede alcanzar una relación.

3.3. Primera Forma Normal.
Se dice que una relación está en 1FN si y sólo si los valores que
componen cada atributo de una tupla son atómicos, es decir,
cada atributo de la relación toma un único valor del dominio
correspondiente, o lo que es lo mismo, no existen grupos
repetitivos.
La tabla estará en 1FN si tiene un solo valor en la intersección de
cada fila con cada columna. Un conjunto de relaciones se
encuentra en 1FN si ninguna de ellas tiene grupos repetitivos.
Si una relación no está en 1FN, hay que eliminar de ellas los
grupos repetitivos. Un grupo repetitivo será el atributo o grupo
de atributos que tiene múltiplos valores para cada tupla de la
relación. Hay dos formas de eliminar los grupos repetitivos:

Repetir los atributos con un solo valor para cada valor del grupo
repetitivo. De este modo se introducen redundancias ya que se
duplican valores, pero estas redundancias se eliminarán después
mediante las restantes formas normales.
La segunda forma de eliminar los grupos repetitivos consiste en
poner cada uno de ellos en una relación a parte, heredando la clave
primaria de la relación en al que se encontraban.

Ejemplo. Consideramos la tabla Alumno, con clave primaria
Cod_Alumno, en la que el atributo Tlf puede tomar varios
valores: el móvil, el de casa, el del padre, el de la madre, etc.
COD_ALUMNO NOMBRE APELLIDO TLF DIRECCIÓN

1111 PEPE GARCÍA 678-900600 C/ Las Cañas, 45
91-2233441
91-1231232
2222 MARÍA SUÁREZ 91-7008001 C/Mayor, 12
3333 JUAN GIL 91-7562324 C/La plaza
660-111222
4444 FRANCISCO MONTOYA 678-556443 C/La arboleda
Esta tabla no está en 1FN, ya que hay dos alumnos con varios
tlfs

Definir como clave primaria de la tabla Cod_Alumno y el Tlf, con
el fin de que cada atributo tomo un único valor en la tupla
correspondiente
COD_ALUMNO TLF NOMBRE APELLIDO DIRECCIÓN
1111 678-900600 PEPE GARCÍA C/ Las Cañas, 45
2222 91-7008001 MARÍA SUÁREZ C/Mayor, 12
3333 91-7562324 JUAN GIL C/La plaza
3333 660-111222 JUAN GIL C/La plaza
4444 678-556443 FRANCISCO MONTOYA C/La arboleda
Tabla alumno primera transformación a 1FN

O también se eliminan los grupos repetitivos (TLF) y
se crea una relación (tabla) junto con la clave inicial.
COD_ALUMNO NOMBRE APELLIDO DIRECCIÓN COD_ALUMNO (FK) TLF
1111 PEPE GARCÍA C/ Las Cañas, 45 1111 678-900600
2222 MARÍA SUÁREZ C/Mayor, 12 1111 91-2233441
3333 JUAN GIL C/La plaza 1111 91-1231232
4444 FRANCISCO MONTOYA C/La arboleda 2222 91-7008001
3333 91-7562324
3333 660-111222
4444 678-556443
Tabla alumno segunda transformación a 1FN

La aplicación de esta regla es muy sencilla, simplemente consiste
en descomponer los atributos multivaluados. Estos atributos dan
lugar a una nueva relación cuya clave primaria es la
concatenación de la clave primaria de la entidad en la que se
sitúa el atributo multivaluado más el nombre del atributo
multivaluado.
Supongamos un modelo E/R con la siguiente entidad:
Cod_recambio descripcion
Recambio
proveedor

Aplicando la regla 1 obtenemos la relación:
RECAMBIO(cod_recambio[p],descripción, proveedor)
donde proveedor es un atributo multivaluado (para un mismo recambio
puedo tener varios proveedores).
Para cumplir la 1FN realizaríamos la siguiente descomposición:
RECAMBIO(cod_recambio[p],descripción)
PROVEEDOR(cod_recambio (e), proveedor)[p])

3.4. Segunda Forma Normal.
Se dice que una relación se encuentra en 2FN si y sólo si
satisface la 1FN, y cada atributo de la relación que no está
en la clave depende funcionalmente de forma completa de
la clave primaria de la relación. La 2FN se aplica a las
relaciones que tienen claves primarias compuestas por dos
o más atributos.
Si una relación está en 1FN y su clave primaria es simple
(tiene un solo atributo), entonces también está en 2FN.
Las relaciones que no están en 2FN pueden sufrir
anomalías cuando se realizan actualizaciones.

Para pasar una relación en 1FN a 2FN hay que eliminar las
dependencias parciales de la clave primaria. Para ello se
eliminan los atributos, que son funcionalmente
dependientes, y se ponen en una nueva relación con una
copia de su determinante (los atributos de la clave
primaria de los que dependen).
Se crearán dos tablas para eliminar las dependencias
funcionales, una de ellas tendrá los atributos que
dependen funcionalmente de la clave, y la otra los
atributos que forman parte de la clave de la que dependen

Ejemplo: supongamos que tenemos una relación ALUMNO en la
que representamos los datos de los alumnos y las notas en cada
una de las asignaturas en que está matriculado. La clave es el
número de matrícula Cod_Alumno y la asignatura Asignatura.
COD_ALUMNO NOMBRE APELLIDO ASIGNATURA NOTA CURSO AULA
1111 PEPE GARCÍA LENGUA I 5 1 15
1111 PEPE GARCÍA IDIOMAS 5 2 16
2222 MARÍA SUÁREZ IDIOMAS 7 2 16
2222 MARÍA SUÁREZ CIENCIAS 7 2 14
3333 JUAN GIL PLÁSTICA 6 1 18
3333 JUAN GIL MATEMÁTICAS I 6 1 12
4444 FRANCISCO MONTOYA LENGUA II 4 2 11
4444 FRANCISCO MONTOYA MATEMÁTICAS I 6 1 12
4444 FRANCISCO MONTOYA CIENCIAS 8 1 14
Tabla ALUMNO para transformarla en 2FN

Es obvio que todos los atributos no dependen de la clave completa
(COD_ALUMNO, ASIGNATURA). En primer lugar, hay que ver las
dependencias funcionales de cada uno de los atributos con respecto a
los atributos de la clave y el resto de atributos:
Nombre y Apellidos, sólo dependen de Cod_Alumno
Los atributos Curso y Aula están relacionados con Asignatura, es
decir, existe una dependencia entre Asignatura Curso,
Asignatura Aula. Una asignatura pertenece a un único curso y se
imparte en un aula (esto me lo dirían en el enunciado).
El atributo Nota depende funcionalmente de la clave, pues para que
haya una nota tienen que haber una asignatura y un alumno

Vista las dependencias funcionales llegamos a la siguiente
conclusión para que la relación Alumno esté en 2FN necesitamos
crear tres relaciones: ALUMNO, ASIGNATURAS Y NOTAS
COD_ALUMNO NOMBRE APELLIDO ASIGNATURA CURSO AULA
1111 PEPE GARCÍA LENGUA I 1 15
2222 MARÍA SUÁREZ IDIOMAS 2 16
3333 JUAN GIL CIENCIAS 2 14
444 FRANCISCO MONTOYA PLÁSTICA 1 18
MATEMÁTICAS I 1 12
Tabla ALUMNO, en 2FN LENGUA II 2 11
Tabla ASIGNATURA, en 2FN

COD_ALUMNO(FK) ASIGNATURA(FK) NOTA
1111 LENGUA I 5
1111 IDIOMAS 5
2222 IDIOMAS 7
2222 CIENCIAS 7
3333 PLÁSTICA 6
3333 MATEMÁTICAS I 6
4444 LENGUA II 4
4444 MATEMÁTICAS I 6
444 CIENCIAS 8
Tabla NOTA, en 2FN

3.5. Tercera Forma Normal.
Se dice que una relación se encuentra en 3FN si y sólo está en
2FN, y cada atributo que no está en la clave primaria no
depende transitivamente de la clave primaria. Es decir, los
atributos de la relación no dependen unos de otros, dependen
únicamente de la clave, esté formado por uno o más atributos.
La dependencia X Z es transitiva si existen las dependencias
X Y Y Z, siendo X, Y, atributos o conjuntos de atributos de
una misma relación.
Para pasar una relación de 2FN a 3FN hay que eliminar las
dependencias transitivas. Para ello se eliminan los atributos que
dependen transitivamente y se ponen en una nueva relación con
una copia de su determinante (el atributo o atributos no clave de
los que dependen).

Ejemplo: supongamos que tenemos una relación LIBROS en la que
representamos los datos de las editoriales de los mismos
COD_LIBRO TÍTULO EDITORIAL PAÍS

12345 DISEÑO DE BD RELACIONALES RAMA ESPAÑA
34562 INSTALACIÓN Y MANTENIMIENTO DE EQUIPOS MCGRAW-HILL ESPAÑA
72224 FUNDAMENTOS DE PROGRAMACIÓN SANTILLANA ESPAÑA
34522 BASE DE DATOS OO ADDISON EEUU
Tabla LIBROS, para transformar a 3FN

Veamos las dependencias con respecto a la clave:
TÍTULO Y EDITORIAL dependen directamente del código del libro
El PAÍS, aunque es parte, también depende del libro, está más
ligado a la Editorial a la que pertenece el libro. Por esta razón, la
relación libros no está en 3FN. La solución sería:

COD_LIBRO TÍTULO EDITORIAL (FK) EDITORIAL PAÍS
12345 DISEÑO DE BD RELACIONALES RAMA RAMA ESPAÑA
34562 INSTALACIÓN Y MANTENIMIENTO DE MCGRAW-HILL MCGRAW-HILL ESPAÑA
EQUIPOS
72224 FUNDAMENTOS DE PROGRAMACIÓN SANTILLANA SANTILLANA ESPAÑA
34522 BASE DE DATOS OO ADDISON ADDISON EEUU
Tabla Libros, en 3FN Tabla Editorial en 3FN

Ejercicio: Normalizar hasta la 3FN
DNI NOMBRE APELLIDOS DIRECCIÓN CP POBLACIÓN PROVINCIA

413246-B JUAN RAMOS C/Las Cañas, 59 19005 Guadalajara Guadalajara
C/Pilón 12 45589 Caleruela Toledo
23456-J PEDRO PÉREZ C/Victoria, 3 28804 Alcalá de Henares Madrid
C/El altozano 10392 Berrocalejo Cáceres
34561-B MARÍA RODRÍGUEZ C/Sanz Vázquez,2 19004 Guadalajara Guadalajara
222346-J JUAN CABELLO C/El ensanche, 3 28802 Alcalá de Henares Madrid

C/ Los abedules10 10300 Navalmoral Cáceres

3.6. Forma Normal de Boyce-Codd (FNBC)
La forma normal de Boyce-Codd (FNBC) es conceptualmente
distinta, y mucho más sencilla, a la 2FN y 3FN. Las relaciones que
satisfacen la FNBC satisfacen la 2FN y 3FN. La FNBC se basa en el
concepto de determinante funcional, y está soportada en las
características de las claves candidatas de las relaciones.
Se denomina determinante funcional a uno o a un conjunto de
atributos de una relación R del cual depende funcionalmente de
forma completa algún otro atributo de la misma relación.
La FNBC se puede expresar de la siguiente manera:
Una relación R satisface la FNBC si, y sólo si, se encuentra en 1FN, y
cada determinante funcional es una clave candidata de la relación R.

Del análisis de las últimas relaciones obtenidas se puede deducir
que todas las relaciones se encuentran en FNBC, puesto que:
Los únicos determinantes funcionales son las claves para cada una de
las relaciones, puesto que en ninguna relación existen claves
alternativas.
En todas las relaciones, las únicas dependencias funcionales son las
existentes entre los atributos no primos de cada relación y la clave de
la misma.
Pero se pueden dar casos en los que una relación se encuentre en
3FN pero no satisfaga la FNBC.

Ejemplo: supongamos que tenemos una relación EMPLEADOS en
la que representamos los datos de los empleados de una fábrica.
DNI N_SS NOMBRE APELLIDOS DEPARTAMENTO PUESTO SALARIO
413245-B 28-11111 JUAN RAMOS COMPRAS GERENTE 2.300
23456-J 28-22222 PEDRO PÉREZ NÓMINAS AUXILIAR 1.200
123123-C 28-33333 MARÍA GIL ALMACÉN CONSERJE 1.530
435613-H 28-44444 ANTONIO SANZ COMPRAS GESTIÓN 2.200
Tabla EMPLEADOS, para transformar a FNBC

Observando los atributos de esta relación podemos ver que N_SS
y el grupo Nombre-Apellidos son claves candidatas
(determinantes). Esta relación se transforma en dos tablas: una
contendrá la clave junto con las claves candidatas (EMPLEADOS) y
la otra la clave con el resto de campo (EMPL_TRABAJO)

DNI N_SS NOMBRE APELLIDOS
413245-B 28-11111 JUAN RAMOS
23456-J 28-22222 PEDRO PÉREZ
123123-C 28-33333 MARÍA GIL
435613-H 28-44444 ANTONIO SANZ
Tabla EMPLEADOS EN FNBC
DNI(FK) DEPARTAMENTO PUESTO SALARIO

413245-B COMPRAS GERENTE 2.300
23456-J NÓMINAS AUXILIAR 1.200
123123-C ALMACÉN CONSERJE 1.530
435613-H COMPRAS GESTIÓN 2.200
Tabla EMPLE_TRABAJO EN FNBC

3.7. Otras Formas Normales
Existen más formas normales (4FN, 5FN, 6FN, etc), cuyo alcance
excede de este curso y cuya aplicación en el mundo real es
únicamente teórica.

Tema3 Disenio Logico BBDD Modelo Relacional

Cargado por

Copyright:

Formatos disponibles

Tema3 Disenio Logico BBDD Modelo Relacional

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

Tema3 Disenio Logico BBDD Modelo Relacional

Cargado por

Copyright:

Formatos disponibles

Diseño Lógico de Bases de

Datos – Modelo Relacional

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 2

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 3

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 5

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 6

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 7

3256 José Pérez de Lastra 1 5,25

1234 Antonio Soria Madrid 3 6,35

0678 Pilar Alcántara Badajoz 2 5,50

0346 Dolores Almiz Márquez 3 7,30

2985 Manuel Rivas Fuentes 3 3,50

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 8

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 9

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 10

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 11

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 12

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 13

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 14

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 15

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 16

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 17

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 18

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 20

Para el diagrama E/R, las relaciones generadas son:

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 21

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 22

En el diagrama E/R, las relaciones generadas son (sin

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 23

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 24

FACTURAS (Num_factura, Fecha-emisión, Total-factura)

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 25

Propagar la clave: este caso se aplica siempre cuando la

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 26

EDITORIALES (Nombre, Director, Dirección)

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 27

TEMAS (Cod_tema, Descripción)

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 28

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 29

Teléfono Dirección Localización

PACIENTES (Cod_paciente, Nombre, Teléfono,

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 30

Nivel Ocupación Modelo

EMPLEADOS (NIF, Nombre, Ocupación, Nivel)

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 31

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 32

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 33

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 34

Tlf (0,N) 1:N

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 36

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 37

color (0,N) N:M

PIEZA (0,N) COMPONE

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 38

Cod_pieza_comp y cod_pieza son clave ajenas y representan cada

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 39

color GATO ÁGUILA DELFÍN comida

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 40

Tema3: Diseño Lógico de Bases de Datos - Modelo Relacional 41