Reglasparalanormalizacin1FN,2FNy3FN.

El diseo de base de datos

El diseo de la base de datos se realiza tomando en cuenta el anlisis de requisitos con todas las
personas que van a hacer uso de los datos y revisando nuestro estudio de factibilidad, aunque
tambin se toma en cuenta segn los requisitos de la aplicacin se realiza el diseo de la base de
datos.
Es importante realizar una buena normalizacin a la base de datos para que no halla probabilidad
de fallos en el programa cuando se este desarrollando o ya este realizado.
El proceso de Normalizacin, tal y como fue propuesto en un principio por Codd (1972) hace pasar
un esquema de relacin por una serie de comprobaciones para certificar que satisface una
determinada forma normal.
La normalizacin de datos puede considerarse como un proceso de anlisis de un esquema de
relacin, para conseguir una BD relacional, basado en sus DF. Y sus claves principales, para
obtener las propiedades deseables, de (1) minimizar la redundancia y (2) minimizar las anomalas
de insercin, borrado y actualizacin.
Se divide en formas normales, 1FN, 2FN, 3FN, 4FN, 5FN etc. en la mayora de los casos realizar
hasta la 3FN es suficiente para que la base de datos este normalizada.
Se realiza analizando el conjunto de campos (atributos) y en base a eso designar una clave inicial
que identifique a un grupo de datos. Por ejemplo si estamos normalizando todo un esquema de
facturacin podemos partir de los datos del cliente aadiendo la clave del cliente, y segn vayamos
normalizando nos saldrn todas las tablas y les iremos dando claves primarias nuevas. Si lo que
normalizamos es una tabla, el procedimiento es el mismo y ya irn saliendo otras tablas
subordinadas.

Implicaciones
Hay ocasiones en las que los diseadores de las BD confeccionan la BD para satisfacer
necesidades lgicas y funcionales de una aplicacin, por ejemplo almacenando los datos en un
formato que luego la aplicacin se encarga de transformar. Esto es bastante tpico cuando el
diseador es el programador de la aplicacin, y lo hace por comodidad o falta de conocimiento.

La moraleja es que una BD debe ser independiente de la aplicacin, es mejor as. Segn las reglas
de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (tpicamente
SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada
desde la aplicacin). Con esto conseguiremos que mediante el SQL no se puedan realizar
operaciones que hagan que la aplicacin no funcione (introduciendo datos en un formato
inesperado para la aplicacin, por ejemplo), y entre otras cosas, que si tenemos que realizar
informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que
parsear (desfrizar una sintaxis en el cdigo) ni realizar consultas sobre consultas.

1FN:
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas.
Afirma que el dominio de un atributo solo debe incluir valores atmicos (simples o indivisibles) y
que el valor de cualquier atributo en una tupla debe ser una valor simple del dominio de ese
atributo
Como por ejemplo tres nmeros de telfono, o dos direcciones e-mail. Lo tpico en estos casos es
separar los datos por comas, espacios u otro carcter y despus procesarlo mediante la aplicacin.
Para evitar esto hay que definir una nueva tabla que tendr el identificador de la tabla de la que
parte y el campo multivaluado, haciendo juntos de clave nica compuesta (se puede definir otra
incremental si se desea "recomendado", pero el conjunto de los otros dos campos tiene que ser
nico). Adems en esta tabla se puede agregar campos que ayuden a describir el tipo de registro.
No
se
permiten
grupos
repetidos
en
varias
columnas
Esto es una variante de lo anterior: separamos los campos de un mismo dominio en varias
columnas, haciendo un grupo difcilmente procesable a la hora de consultarlo. En el ejemplo
anterior sera tener el campo teleClien1, telClien2 y as. Es evidente que este fallo del diseo es
incluso peor que el anterior pues habr muchos campos nulos, y en caso de necesitar ms
tendramos que redimensionar la tabla con un nuevo campo (telClien3). Pero la solucin es
sencilla.
Ejemplo:

No
se
permiten
campos
nulos
Esta regla es algo discutible, pero tiene su lgica. Para empezar, si un campo va a tener valores
nulos, qu proporcin de registros tendrn ese campo con valor nulo? En mi opinin esta regla
nos ayuda a separar unas relaciones de otras, porque si una cantidad de registros tienen unos
atributos que otros no, no ser que pertenecen a otra clase? Por ejemplo, si en una tabla de
TBPRODUCTOS definimos los campos TallaProd, KilatesProd y potenciaProd se ve que los
productos tendrn clases diversas y entonces habr que crear una relacin para cada clase (ropas,
joya y elctricos, por ejemplo) construyendo lo que se llama una generalizacin.
Ejemplo:

2FN:

La relacin est en 1NF.

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben
eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un trmino que
describe a aquellos datos que no dependen de la clave primaria de la tabla para identificarlos.
Cada atributo no principal tiene dependencia funcional completa respecto a la clave primaria.
Si un campo de la tabla no depende totalmente de una clave nica (que pueden ser compuestas),
debe sacarse fuera con la parte de la clave principal de la que es dependiente.
Ejemplo:

Como vemos en la tabla TBLINEASPEDIDO del ejemplo incorrecto, la nica clave candidata es
PK_TBLINEASPEDIDO + IDProducto, ya que en conjunto son nicas en la tabla (podramos tener
un IDLinea_pedido nico tambin, pero an as esos dos campos seguiran siendo una clave
candidata). El campo CantidadPed es dependiente de la clave candidata, pues el cliente ha pedido
de ese producto una cantidad determinada de artculos, pero el nombre en cambio es dependiente
slo del producto, no del cliente. Si dejaremos esa tabla como est, tendramos por una parte una
redundancia de datos innecesaria pues el nombre del producto lo podemos sacar uniendo la tabla
de productos, y adems podran darse inconsistencias de datos si cambiamos el nombre del
producto en un registro cul sera el nombre real del producto 1 si en varios registros tiene un
nombre distinto?

Conclusiones

2FN:

Por lo tanto los pasos para aplicar la segunda forma normal son muy sencillos: encontrar las claves
candidatas (compuestas), que identifican de manera nica el registro; comprobar que los campos
que no forman parte de la clave candidata y no son parte de ella (en el ejemplo de antes ni
IDCliente ni IDProducto deben ser analizados) dependen totalmente de la clave candidata. Para el
segundo
paso
puede
ayudar
preguntarse
lo
siguiente:
puedo saber el valor del campo X sabiendo el valor del campo Y (siendo Y parte de la clave

candidata y X no siendo parte de ella)? Pero como todo lo relacionado con el anlisis esto requiere
un mnimo de agudeza, pues puede que casualmente el valor de un campo se repita para una
parte de la clave (por casualidad todos los que compran unas pelotas de tenis lo hacen en
cantidades
de
5)
pero
sabemos
que
no
es
dependiente
de
ella.
Por ltimo, aclarar que hay ocasiones en las que el anlisis no tiene que ser tan cerrado, ya que a
veces las apariencias engaan. Un ejemplo de ello es una tabla de facturas que tiene el nombre,
direccin, NIF, y dems datos del cliente: a simple vista esos datos estn duplicados y dependen
del cliente y no de la factura, pero resulta que esos datos deben permanecer ah pues fisicalmente
debemos saber a qu datos se emiti una factura; esos datos son realmente dependientes de la
factura, no del cliente. Si no los incluyramos en la tabla de facturas, al modificar el registro del
cliente en la tabla de clientes no sabramos a qu datos fiscales se emiti la factura. As que hay
que tomar como referencia el estudio de factibilidad, necesidades de cliente y el minimundo, y no
solo
aplicar
normas.

3FN:
La relacin est en 2NF.
Una tabla est normalizada en esta forma si todas las columnas que no son llave son
funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas.
Una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen
de otras columnas que tampoco son llave.
Todos sus campos no primarios (campos que no forman parte de una clave candidata) dependen
nicamente de la clave candidata. Suena como la segunda forma normal, pero es muy distinta:
ningn campo que no sea parte de la clave candidata puede depender
de
otro
campo
que
no
sea
la
clave
candidata.
Por ejemplo:
pedido(pedido_id, fecha, cliente_id, cliente_nombre)
- satisface 1FN y 2FN con clave primaria pedido_id
- pero cliente_nombre cambia si cambia cliente_id
- As que debemos dividir la tabla en:
- pedido(pedido_id, fecha, cliente_id)
- cliente(cliente_id,cliente_nombre)
Otro

ejemplo:

Imagina que una tabla se encarga de registrar el primer servicio que ms carga los servidores cada
da. Del ejemplo incorrecto deducimos que el IDServidor y la Fecha, PK_TBCARGADIARIA son la
clave candidata, pues identifican de manera nica los registros. Analizando vemos que el
IDServicio, que no es un campo primario, depende nicamente de la clave candidata, y que la
carga tambin. Pero resulta que el Nombre_servicio depende de esa clave candidata pero tambin
depende del IDServicio, pues con el IDServicio podemos averiguar qu Nombre_servicio tiene el
registro. Para solucionar esto sacamos el campo Nombre_servicio de la tabla, y nos llevamos el
IDServicio para que sea la clave principal pues es el campo del que depende.
Y con este ejemplo vemos qu fcil es librarnos de las inconsistencias de no cumplir la tercera
forma normal, y de la redundancia de datos. Si no hubiramos normalizado tendramos que en un
registro el IDServicio 3 es Apache y nadie nos asegura que en otro el IDServicio 3 tambin lo sea
pues puede haberse modificado el campo Nombre_servicio. Y si resulta que la tabla fuese un
histrico de 500 servidores durante 1000 das, tendramos 500 mil registros con un campo
innecesario que estara duplicado muchsimas veces

Ejercicios, PASO A 1FN, 2FN y 3FN (BASES DE DATOS)

Ejercicios: Pasar a 3FN los esquemas relacionales:

1.
.

A (a0, b0, c1, c2) siendo c2 c1

C (c1, c2)
A (a0, b0, c1)
Cajena: {c1} C

2.

ALUMNO (num_exp, curso, localidad, provincia) siendo provincia localidad

Provincia (localidad, provincia)
Alumno (num_exp, curso, localidad)
Cajena: {Localidad} Provincia

3.

NOTA (cod_asig, num_exp, nom_asig, nom_alumno, dir_alumno,

nota) siendo nom_alumno, dir_alumno num_exp y siendo nom_asig cod_asig
FN2:
Nota (cod_asig, num_exp, nota)
Cajena: {cod_asig} Asignatura
Cajena: {num_exp} Alumno
Alumno (num_exp, nom_alumno, dir_alumno)
Asignatura (cod_asig, nom_asig)

4.

A (a0, a1, a2, {a3}, a4, a5) siendo a2 a1 y siendo a5a4

FN1

A'(a0, a1,a3)
Cajena: {a0, a1} A
A (a0, a1, a4, a5)

FN2
A (a0, a1, a4, a5)
Cajena: {a1} A2
A2 (a1, a2)

FN3
A' (a4, a5)
A (a0, a1, a4)
Cajena: {a4} A'

5.

A (a0, {a1}, a2) siendo a2 a0

FN1
A' (a0, a1)
Cajena: {a0} A'
A (a0, a2)

FN2

A(a0,a2)

Realiza el proceso de normalizacin de las siguientes

relaciones y para cada uno de los enunciados, crea un
excel con tablas de datos de ejemplo.
Enunciado 1.
FCT (num_expediente, cod_empresa, nom_alumno,
nom_empresa, fecha_inicio, fecha_fin)
FCT (num_expediente, cod_empresa, fecha_inicio, fecha_fin)
Cajena: {num_expediente} ALUMNO
Cajena: {cod_empresa} EMPRESA
ALUMNO (num_expediente, nom_alumno)
EMPRESA (cod_empresa, nom_empresa)

Enunciado 2.
CAMPAMENTO (cod_nio, cod_monitor, {fecha_inicio},
num_dias, nom_nio, nom_monitor, edad_nio,
titulo_monitor)
FN1
CAMPAMENTO' (cod_nio, cod_monitor, fecha_inicio)
Cajena: {cod_nio, cod_monitor} Campamento.
CAMPAMENTO(cod_nio, cod_monitor, num_dias, nom_nio, nom_monitor, edad_nio,
titulo_monitor)
FN2:
CAMPAMENTO(cod_nio, cod_monitor, num_dias)
Cajena: {cod_nio} Nio
Cajena: {cod_monitor} Monitor
NIO (cod_nio, nom_nio, edad_nio)
MONITOR (cod_monitor, nom_monitor, titulo_monitor)

Enunciado 3.
ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edicin},
nom_autor, especialidad_autor, editorial)
ESCRIBIR_LIBRO (isbn, dni, num_pag, {tipo_edicin}, nom_autor, especialidad_autor, editorial)
FN1
ESCRIBIR_LIBRO' (isbn, dni, tipo, edicion)
Cajena: {isbn, dni} ESCRIBIR_LIBRO
ESCRIBIR_LIBRO (isbn, dni, num_pag, nom_autor, especialidad_autor, editorial)
FN2:
ESCRIBIR_LIBRO(isbn, dni)
Cajena: {isbn} Libro
Cajena: {dni} Autor
LIBRO (isbn, num_pag, editorial)AUTOR(dni, nom_autor, especialidad_autor)
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, {aux_vuelo}, hora_salida)

Enunciado 4.
VUELO (num_vuelo, dni, cod_avion, nom_piloto,
num_asientos, {aux_vuelo}, hora_salida)
FN1
VUELO' (num_vuelo, dni, cod_avion, aux_vuelo)
Cajena: {num_vuelo, dni, cod_avion} VUELO
VUELO (num_vuelo, dni, cod_avion, nom_piloto, num_asientos, hora_salida)
FN2
VUELO (num_vuelo, dni, cod_avion)
VIAJE(num_vuelo, hora_salida)
AVION(cod_avion, num_asientos)
PILOTO (dni, nom_piloto)

El proceso de normalizacin de bases de datos relacionales

La normalizacin de bases de datos relacionales toma un esquema relacional y le aplica un
conjunto de tcnicas para producir un nuevo esquema que representa la misma informacin
pero contiene menos redundancias y evita posibles anomalas en las inserciones,
actualizaciones y borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de
acuerdo a la teora de conjuntos. Una base de datos relacional puede considerarse como un
conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la
relacin, que se define por una serie de atributos Ai.
Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de
entidad es una restriccin que nos indica que cada entidad representada por una tupla tiene
que ser diferente de las dems en su relacin, es decir, debe haber algunos atributos cuyos
valores identifiquen unvocamente las tuplas. La integridad referencial indica que una clave
ajena solo debe contener valores que o bien sean nulos, o bien existan en la relacin
referenciada por la clave ajena.

El proceso de normalizacin
El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est
en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo
Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado,
de modo que las condiciones salariales estn determinadas por el puesto. Se ha creado el
siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails)

nss

nombre

puesto

con nss como clave primaria.

salario

emails

111

Juan Prez

Jefe de rea

3000

juanp@ecn.es; jefe2@ecn.es

222

Jos Snchez

Administrativo

1500

jsanchez@ecn.es

333

Ana Daz

Administrativo

1500

adiaz@ecn.es; ana32@gmail.

...

...

...

...

...

Primera forma normal (1FN)

Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos
ver que el atributo emails puede contener ms de un valor, por lo que viola 1FN.
En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la
condicin de 1FN, tenemos dos opciones.
Solucin 1: duplicar los registros con valores repetidos

En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la
cual:

El atributo M que violaba 1FN se elimina.

Se incluye un nuevo atributo M' que solo puede contener valores simples,
de modo que si R'[M'] es uno de los valores que tenamos en R[M],
entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores
duplicados en M, en la nueva relacin habr n tuplas, que slo varan en
que cada una de ellas guarda uno de los valores que haba en M.

La clave primaria de R' es (K, M'), dado que podr haber valores
de K repetidos, para los valores multivaluados en M.

Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva

tabla EMPLEADOS'(a) con clave primaria (nss, email):

nss

nombre

puesto

salario

email

111

Juan Prez

Jefe de rea

3000

juanp@ecn.es

111

Juan Prez

Jefe de rea

3000

jefe2@ecn.es

222

Jos Snchez

Administrativo

1500

jsanchez@ecn.e

333

Ana Daz

Administrativo

1500

adiaz@ecn.es

333

Ana Daz

Administrativo

1500

ana32@gmail.c

...

...

...

...

...

Solucin 2: separar el atributo que viola 1FN en una tabla

En general, esta solucin pasa por:

sustituir R por una nueva relacin modificada R' que no contiene el atributo M.
Crear una nueva relacin N(K, M'), es decir, una relacin con una clave
ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del
atributo M.
La nueva relacin N tiene como clave (K, M').
Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss

nombre

puesto

sa

111

Juan Prez

Jefe de rea

30

222

Jos Snchez

Administrativo

15

333

Ana Daz

Administrativo

15

...

...

...

Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email):

nss

email

111

juanp@ecn.es

111

jefe2@ecn.es

222

jsanchez@ecn.es

333

adiaz@ecn.es

...

333

ana32@gmail.com

...

...

Segunda forma normal (2FN)

Un esquema est en 2FN si:
Est en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa
respecto de todas las claves existentes en el esquema. En otras palabras, para determinar
cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms
atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces tambin est en 2FN. Por tanto, de las soluciones anteriores, la
tablaEMPLEADOS'(b) est en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo
que el esquema est en 2FN. Sin embargo, tenemos que examinar las dependencias
funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que
tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email

son incompletas, por lo que la relacin no est en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la
clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos
con dependencia incompleta M:

Eliminar de R el atributo M.
Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que
depende, que llamaremos K'.
La clave primaria de la nueva relacin ser K'.
Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen
dependencia incompleta:

nss

nombre

puesto

sa

111

Juan Prez

Jefe de rea

30

222

Jos Snchez

Administrativo

15

333

Ana Daz

Administrativo

15

...

...

...

...

Y al eliminar de la tabla original estos atributos nos quedara:

nss

email

111

juanp@ecn.es

111

jefe2@ecn.es

222

jsanchez@ecn.es

333

adiaz@ecn.es

333

ana32@gmail.com

...

...

Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin
para el problema de 1FN.

Tercera forma normal (3FN)

Una relacin est en tercera forma normal si, y slo si:
est en 2FN
y, adems, cada atributo que no est incluido en la clave primaria no depende
transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales
entre atributos que no estn en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de
dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La
solucin a este tipo de dependencias est en separar en una tabla adicionalN el/los
atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario

Por lo tanto la descomposicin sera la siguiente:

nss

nombre

puesto

111

Juan Prez

Jefe de rea

222

Jos Snchez

Administrativo

333

Ana Daz

Administrativo

...

...

...

En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.