3 Normalización 3.

1 Ejemplo

➤ La teoría de la normalización, desarrollada por Codd en 1972, Facturas

permite mejorar el diseño lógico de una Base de datos relacional codfac fecha iva dto codcli nombre población

➤ Se fundamenta en las Formas Normales, que son un conjunto de

restricciones que deben de cumplir las relaciones

➤ Una relación está en primera forma normal, si satisface que sus Lineas
dominios simples sólo tienen valores atómicos codfac codart cant dto precio descrip precio almacen

Ventajas

➤ Evita anomalías de datos en inserciones, borrados y modificaciones.

➤ Mejora la independencia de los datos.

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 40 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 42

3.1 Ejemplo 3.1 Ejemplo

Se desea almacenar información sobre las facturas que realizan los clientes de Escribe en las dos tablas los siguientes datos:

una empresa así como los articulos que compran. Para ello se ha realizado el 1. La factura 3125 es del 23/09/2003, con un 16 % de IVA y del cliente 355 cuyo nombre es Juan
Diaz de Castellón. Se vendieron 3 tuercas de doble paso (cod. 345T) por un precio de 2.25
siguiente diseño:
Euros y 2 tornillos de rosca reforzada (cod. T554) por 1 Euro.
2. La factura 3126 es del 12/12/2003, con un 16 % de IVA y del cliente 354 cuyo nombre es
Rosa Fernández de Almazora. Se vendieron 3 tornillos de rosca reforzada (cod. T554) por 1.2
FACTURAS(codfac,fecha, iva, dto, codcli, nombre, población) Euros.
3. La factura 3127 es del 15/12/2003, con un 16 % de IVA y del cliente 355 cuyo nombre es Juan
LINEAS(codfac,codart,cant, dto, precio, descrip, precio_almacen) Diaz de Castellón. Se vendieron 2 tornillos de rosca reforzada (cod. T554) por 1.1 Euros.
4. Se ha comprado un nuevo artículo en el almacen con código 445A, arandelas cuadradas con
un precio de 0.87 Euros.
codfac Nulos Borrado Modif. 5. El cliente 355 devuelve las tres tuercas y solicita que se rectifique la factura 3125.
LINEAS ------------> FACTURAS No P P 6. El cliente 355 ha cambiado su domicilio a Villareal.
7. El cliente 354 realiza la devolución de la factura 3126.
8. Se ha hecho un nuevo cliente, Ferran Sabater de Castellón con código 337.

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 41 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 43
 3.1 Ejemplo 3.2 Dependencia funcional

¡¡¡ Existen dependencias entre los datos, no sólo de la clave primaria !!! Dada una relación (tabla) R, el atributo Y de R depende funcionalmente
del atributo X de R
Indica cuales són esas dependencias:
R.X ------------> R.Y
FACTURAS(codfac,fecha, iva, dto, codcli, nombre, población) si X determina el valor de Y, es decir, un valor Y en R está asociado a
cada valor X en R. Tanto X como Y puede ser atributos compuestos.
LINEAS(codfac,codart,cant, dto, precio, descrip, precio_almacen)
Ejemplo:
codfac Nulos Borrado Modif.
LINEAS ------------> FACTURAS No P P CLIENTE(codcli, nombre, codpostal, población)

codpostal ------------> población

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 44 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 46

3.1 Ejemplo 3.2 Dependencia funcional

Observaciones:
CLIENTES(codcli, nombre, población)

FACTURAS(codfac,fecha, iva, dto, codcli) ➤ Si el atributo X es una clave primaria (o alternativa) de R, entonces todos los
codcli Nulos Borrado Modif. atributos Y de la relación dependen funcionalmente de X, por la definición de clave
FACTURAS ----------> CLIENTES Sí A P primaria (o alternativa).

➤ La dependencia funcional es una noción semántica (depende del significado de los

ARTICULOS(codart, descrip, precio_almacen)
datos).

LINEAS(codfac,codart,cant, dto, precio) ➤ Cada dependencia funcional es una clase especial de regla de integridad.
codfac Nulos Borrado Modif.
➤ Cada dependencia funcional representa una relación de uno a muchos.
LINEAS ------------> FACTURAS No P P
codart Nulos Borrado Modif.
LINEAS ------------> ARTICULOS No R P

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 45 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 47
 3.3 Primera Forma Normal (1FN) 3.4 Segunda Forma Normal (2FN)

Una relación está en 1FN si, y sólo si, todos sus dominios contienen Una relación está en 2FN si, y sólo si, está en 1FN y, además, cada
valores atómicos. atributo no clave depende completamente de la clave primaria (no
depende de algún subconjunto).

¡No está en 2FN!

¡No está en 1FN!

Hay atributos que no son atómicos

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 48 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 50

3.3 Primera Forma Normal (1FN) 3.4 Segunda Forma Normal (2FN)

PRODUCTO (codprod, nombre, VERSIÓN (número, fecha, ventas)) INSCRIPCIÓN(estudiante, actividad, precio)

Se extrae la tabla anidada añadiendole la clave primaria de la tabla Se extraen los atributos dependientes en otra tabla. En la primera tabla
principal. La clave primaria de la nueva tabla será la unión de la que se deja el atributo del que dependian otros que sera clave ajena a la
tenía más la de la tabla principal. nueva tabla.
PRODUCTO (codprod, nombre, descripción)
INSCRIPCIÓN(estudiante, actividad)
VERSIÓN (codprod, número, fecha, ventas)
ACTIVIDAD(actividad, precio)
codprod Nulos Borrado Modificación
VERSIÓN ----------> PRODUCTO
actividad Nulos Borrado Modificación
INSCRIPCIÓN -----------> ACTIVIDAD

¡OJO! la nueva tabla hereda parte de la clave primaria

Ejercicio: Rellena los huecos que faltan en la clave ajena.
Ejercicio: Rellena los huecos que faltan en la clave ajena.
Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 49 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 51
 3.5 Tercera Forma Normal (3FN) 3.6 Ejercicio Normalización

Una relación está en 3FN si, y sólo si, está en 2FN y, además, cada Se desea almacenar información sobre las becas que han solicitado los
atributo no clave no depende transitivamente de la clave primaria. alumnos de la univeridad. Se ha realizado el siguiente diseño:
SOLICITUD(estudiante, codbeca, fecha, nombre, apellido, DNI, dirección, nombeca, requisito)

Utilizando el siguiente ejemplo comprueba si está en 3FN. Si no lo está,

corrígelo.
SOLICITUD
estudiante nombre apellido DNI dirección codbeca nombeca requisito fecha
¡No está en 3FN! 0123 Carlos Gil 159357 C/ Paz, 23 A223 EEUU Ing. Sup. 10/10/98
7636 Paula Tena 913752 C/ Río Po, 1 B567 ERASMUS Ing. Téc. 12/11/98
7636 Paula Tena 913752 C/ Río Po, 1 A223 EEUU Ing. Sup. 14/10/98
0123 Carlos Gil 159357 C/ Paz, 23 G654 DRAC Ing. Sup. 17/09/98
9516 Andrés Calpe 682432 Plz. Sol, 40 G654 DRAC Ing. Sup. 12/09/99

Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 52 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 54

3.5 Tercera Forma Normal (3FN) 3.6 Ejercicio Normalización (II)

INQUILINO (inquilino, edificio, alquiler) Se desea almacenar información sobre las becas concedidas a los alumnos de
la univeridad. Se ha realizado el siguiente diseño:
Se extraen los atributos dependientes en otra tabla. En la primera tabla CONCEDIDAS(codbeca, nplaza, nombre, apellido, DNI, dirección, fecha)

se deja el atributo del que dependian otros que sera clave ajena a la Utilizando el siguiente ejemplo comprueba si está en 3FN. Si no lo está,
nueva tabla. corrígelo.
CONCEDIDAS
INQUILINO(inquilino, edificio)

EDIFICIO(edificio, alquiler)
codbeca nplaza nombre apellido DNI dirección fecha

edificio Nulos Borrado Modificación A223 1 Carlos Gil 159357 C/ Paz, 23 10/10/98
INQUILINO -----------> EDIFICIO
A223 2 Paula Tena 913752 C/ Río Po, 1 14/10/98
G654 1 Carlos Gil 159357 C/ Paz, 23 17/09/98
G654 2 Andrés Calpe 682432 Plz. Sol, 40 12/09/99
Ejercicio: Rellena los huecos que faltan en la clave ajena.
Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 53 Tema 8: Diseño lógico de bases de datos relacionales (IG18) – 55