Normalizacin de bases de datos

El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones
obtenidas tras el paso del modelo entidad-relacin al modelo relacional.
Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea considerada
como una relacin tiene que cumplir con algunas restricciones:

Cada columna debe tener su nombre nico.

No puede haber dos filas iguales. No se permiten los duplicados.

Todos los datos en una columna deben ser del mismo tipo.

Terminologa relacional equivalente

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria.

Relacin = tabla o archivo

Tupla = registro, fila o rengln

Atributo = columna o campo

Clave = llave o cdigo de identificacin

Clave Candidata = superclave mnima

Clave Primaria = clave candidata elegida

Clave Ajena = clave externa o clave fornea

Clave Alternativa = clave secundaria

Dependencia Multivaluada = dependencia multivalor

RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases
de Datos Relacionales.

1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional, que constituyen la fuente
terica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede
tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre
los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analoga matemtica, ya
que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse
matemticamente como un elemento del producto cartesiano entre los dominio.
Dependencia
Dependencia funcional

B es funcionalmente dependiente de A.
Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si conocemos el valor de
FechaDeNacimiento podemos conocer el valor de Edad.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento

Edad

Aqu a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas

FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la
normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias
funcionales para lograr la eficiencia en las tablas.
Propiedades de la Dependencia funcional
Existen 3 axiomas de Armstrong:
Dependencia funcional Reflexiva
Si "y" est incluido en "x" entonces x

Si la direccin o el nombre de una persona estn incluidos en el DNI, entonces con el DNI podemos
determinar la direccin o su nombre.
Dependencia funcional Aumentativa
entonces
DNI

nombre

DNI,direccin

nombre,direccin

Si con el DNI se determina el nombre de una persona, entonces con el DNI ms la direccin tambin se
determina el nombre o su direccin.
Dependencia funcional transitiva

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z
de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X.
Simblicamente sera:
X

Z entonces X

FechaDeNacimiento
Edad

Z
Edad

Conducir

FechaDeNacimiento

Edad

Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir,

indirectamente podemos saber a travs de FechaDeNacimiento a Conducir (En muchos pases, una persona
necesita ser mayor de cierta edad para poder conducir un automvil, por eso se utiliza este ejemplo).
Propiedades deducidas
Unin
y

entonces

Pseudo-transitiva
y

entonces

Descomposicin
y z est incluido en y entonces
Claves
Una clave primaria es aquella columna (pueden ser tambin dos columnas o ms) que identifica nicamente
a esa fila. La clave primaria es un identificador que va a ser nico para cada fila. Se acostumbra a poner la
clave primaria como la primera columna de la tabla pero esto no tiene que ser necesario, si no es ms una
conveniencia. Muchas veces la clave primaria es autonumrica.
En una tabla puede que tengamos ms de una clave, en tal caso se puede escoger una para ser la clave
primaria, las dems claves son las claves candidatas. Adems es la posible clave primaria.

Una clave ajena (foreign key o clave fornea) es aquella columna que existiendo como dependiente en una
tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que
tambin puede identificar de forma nica a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes
definimos el nmero de documento (id_cliente) como clave primaria, el nmero de seguro social de ese cliente
podra ser una clave alternativa. En este caso no se us como clave primaria porque es posible que no se
conozca ese dato en todos los clientes.
Una clave compuesta es una clave que est compuesta por ms de una columna.
Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos est en la
forma normal N es decir que todas sus tablas estn en la forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de
las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1
Primera Forma Normal (1FN)
Artculo principal: Primera forma normal
Una tabla est en Primera Forma Normal si:

Todos los atributos son atmicos. Un atributo es atmico si los elementos del dominio son indivisibles,
mnimos.
La tabla contiene una clave primaria.

La clave primaria no contiene atributos nulos.

No debe de existir variacin en el nmero de columnas.

Una columna no puede tener mltiples valores. Los datos son atmicos. (Si a cada valor de X le pertenece un
valor de Y, entonces a cada valor de Y le pertenece un valor de X)
Esta forma normal elimina los valores repetidos dentro de una BD
Segunda Forma Normal (2FN)
Artculo principal: Segunda forma normal
Dependencia Funcional. Una relacin est en 2FN si est en 1FN y si los atributos que no forman parte de
ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias
parciales.
En otras palabras podramos decir que la segunda forma normal est basada en el concepto de dependencia
completamente funcional. Una dependencia funcional
es completamente funcional si al eliminar los
atributos A de X significa que la dependencia no es mantenida, esto es que A X, (X {A}) -x-> Y. Una
dependencia funcional
es una dependencia parcial si hay algunos atributos
que pueden ser
eliminados de X y la dependencia todava se mantiene, esto es A X, (X {A}) -> Y.
Por ejemplo {DNI, ID_PROYECTO}
HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto
sabemos cuntas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente
dependiente dado que ni DNI
HORAS_TRABAJO ni ID_PROYECTO
HORAS_TRABAJO mantienen la

dependencia. Sin embargo {DNI, ID_PROYECTO}

NOMBRE_EMPLEADO es parcialmente dependiente
dado que DNI
NOMBRE_EMPLEADO mantiene la dependencia.
Tercera Forma Normal (3FN)
Artculo principal: Tercera forma normal
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los
atributos que no son clave.
Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un esquema de relacin R es una
dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R,
donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente
figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva va DNUMBER porque
las dependencias SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es un
subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre
DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Forma normal de Boyce-Codd (FNBC)
Artculo principal: Forma normal de Boyce-Codd
La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave
candidata. Deber registrarse de forma anillada ante la presencia de un intervalo seguido de una
formalizacion perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya
planificadas, dejan de existir.
Cuarta Forma Normal (4FN)
Artculo principal: Cuarta forma normal
Una tabla se encuentra en 4FN si, y slo si, para cada una de sus dependencias mltiples no funcionales X->>Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.
Quinta Forma Normal (5FN)
Artculo principal: Quinta forma normal
Una tabla se encuentra en 5FN si:

La tabla est en 4FN

No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla
que se encuentra en la 4FN se dice que est en la 5FN si, y slo si, cada relacin de dependencia se
encuentra definida por las claves candidatas.

Reglas de Codd
Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo
nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas;
entonces ste public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de
ellas son difciles de realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.

Regla No. 1 - La Regla de la informacin

Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una
tabla.
Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de
tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en
tablas dentro de las bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de
Datos. Esto significa que todo tiene que estar almacenado en las tablas.
Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico
exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) se
representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para
acceder a los datos y a los metadatos (regla 4)
Regla No. 2 - La regla del acceso garantizado
Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la
tabla, su clave primaria, y el nombre de la columna.
Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la
columna requerida, deber encontrarse uno y solamente un valor. Por esta razn la definicin de claves
primarias para todas las tablas es prcticamente obligatoria.
Regla No. 3 - Tratamiento sistemtico de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de valores nulos
Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores
nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables
Regla No. 4 - La regla de la descripcin de la base de datos
La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en
tablas y columnas, y debe ser accesible a los usuarios autorizados.
La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada
exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a
travs de sentencias de SQL (o similar).
Regla No. 5 - La regla del sub-lenguaje Integral
Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de
datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones.
Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado
para administrar completamente la base de datos.
Regla No. 6 - La regla de la actualizacin de vistas
Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.
La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar
vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o
consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'.
Esto significa que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e
INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y
restricciones que haya entre las tablas.
Regla No. 8 - La regla de independencia fsica
El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer
consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los
mtodos de acceso a los datos.
El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser
predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer
inalterado, independientemente de los cambios en la definicin fsica de sta.
Regla No. 9 - La regla de independencia lgica
Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente
inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de
datos.
La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal
deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben
alterar o modificar estos programas de aplicacin.
Regla No. 10 - La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en
el programa de aplicacin.
Las reglas de integridad
1. Ningn componente de una clave primaria puede tener valores en blanco o nulos (sta es la norma
bsica de integridad).
2. Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La
combinacin de estas reglas aseguran que haya integridad referencial.
Regla No. 11 - La regla de la distribucin
El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida
fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin.
El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de
datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada por
una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos en
una sola mquina.
Regla No. 12 - Regla de la no-subversin
Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar
la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).

La normalizacin es un proceso que pretende conseguir tablas con una estructura ptima y eficaz. El proceso
de normalizacin est basado en lograr la independencia de los datos respecto a las aplicaciones que los
usan.
Antes de empezar el proceso, se han de conocer las tablas que intervendrn y las relaciones que las unen. Si
no se conocen a partir del anlisis previo, se buscan todos los nombres (sustantivos) que han sido empleados
en la definicin del problema. Algunos de esos nombres sern las entidades, otros dependern de ellas y
sern los atributos. Otros no formarn parte ni de las entidades ni de los atributos, son parte del lenguaje
necesario para describir el problema a solucionar mediante la creacin de una base de datos.
Ejemplo prctico.
<<...a cada cliente, al pasar por Caja... se marcan por la caja registradora
los artculos que ha comprado. Con los datos de los artculos se hace una
factura por el importe total de las mercancas adquiridas que se imprime y
se entrega al cliente. Los datos de la factura se almacenan para su
posterior tratamiento informtico que comprende...>>.
Las tablas son sustantivos, por lo que tenemos los siguientes: cliente, Caja, caja registradora, artculos, datos
de los artculos, factura, importe total, mercancas adquiridas, datos de la factura. De estos nombres, algunos
son atributos de otros: datos de los artculos y artculos, datos de la factura, importe total y factura. De cada
cliente no se piden datos, por lo que aunque sea una tabla, si no se necesitan sus datos, no se crear esa
entidad. Caja con mayscula se refiere a un objeto con el que se realizan procesos, por lo que no se necesita
almacenar informacin de ellos. De cada una de las cajas registradoras, tal vez se necesite para las facturas,
el nmero de caja, por lo que se considera una entidad ms. Mercancas adquiridas y artculos que ha
comprado son sinnimos, por lo que solo se tratar de artculos.
Las tablas encontradas tras el anlisis son: artculos, factura y caja registradora. Caja registradora se puede
considerar un atributo de factura, por lo que tenemos dos tablas.
Las relaciones se pueden encontrar conociendo todos los verbos que aparecen en la definicin del problema.
Se eliminan aquellos verbos que son necesarios para el lenguaje y se buscan aquellos que implican dos o
ms entidades (sustantivos) que ya se han encontrado.
En el ejemplo han aparecido los verbos: pasar, se marcan, ha comprado, se hace una factura, imprime,
entrega, almacena. De estos verbos, los que asocian entidades son: marcar, comprar. Los verbos pasar, hacer
factura, imprimir, entregar, almacenar, se refieren a procesos que se van a realizar, no a asociaciones entre
entidades.
Se han obtenido las siguientes entidades con sus relaciones: clientes, comprar artculos y marcar artculos en
factura. Como no se necesitan los datos de los clientes, queda la relacin marcada (en la caja registradora)
que une las tablas artculos, y factura. La operacin marcar en la caja registradora significa que los artculos
se incluyen en una factura que se entregar al cliente para su liquidacin, consiguindose obtener el modelo
entidad-relacin siguiente:

Hay cinco niveles de normalizacin, siendo cada vez ms complejo el proceso de obtencin de tablas
normalizadas. Para bases de datos relativamente sencillas se puede terminar la normalizacin en el tercer
nivel o tercera forma normal.
El proceso de normalizacin se basa en la descomposicin sin prdida de las tablas que estn en una forma
normal inferior, obtenindose una forma normal superior. El proceso de descomposicin sin prdida, significa
que se ha de dividir o descomponer la tabla en otras con menor cantidad de atributos sin que haya perdida de
informacin.
Formas normales y dependencias funcionales.
Primera Forma Normal o 1FN:
La Primera Forma Normal, o 1FN, es la ms elemental de todas. Una tabla est en 1FN si el valor que
contiene un atributo de un registro, un campo, es nico y elemental. En cada uno de los atributos slo se
puede incluir un dato, aunque sea compuesto, pero no se pueden incluir una lista de datos. Por ejemplo, no se
pueden incluir en el atributo Direccin el domicilio habitual y el de vacaciones; habra que crear dos registros
que se diferenciarn por el atributo Direccin:
NIF

Ape

Nom

Garca

Sanchez Luisa

Dir

Francisco C/Marn 16

CPost

Pobl

33698 Oviedo

Prov
Asturias

C/Teneras 34 85458 Cigales Valladolid

C/Ramorta 65 54585 Bueu
Pontevedra

Esta tabla no est en 1FN, ya que el cliente con Id 2 tiene dos direcciones. Para poder tener esta tabla en 1FN
se hace el siguiente cambio:
NIF

Ape

Nom

Dir

Francisco C/Marn 16

CPost

Pobl

Prov

Garca

33698 Oviedo Asturias

Sanchez Luisa

C/Teneras 34

85458 Cigales Valladolid

Sanchez Luisa

C/Ramorta 65

54585 Bueu

Pontevedra

Segunda Forma Normal o 2FN:

Se dice que un atributo o conjunto de atributos tiene dependencia funcional de otro u otros si a cada uno de
los primeros le corresponde slo uno de los segundos.
Por ejemplo, hay una dependencia funcional entre CIF y el atributo Razn Social, ya que a cada CIF le
corresponde una nica Razn Social.
Una tabla est en Segunda Forma Normal o 2FN cuando est en 1FN y todo atributo que no pertenece a la
clave primaria tiene una dependencia funcional de la clave completa y no de parte de ella. Luego, si la clave
principal est formada por un solo atributo y ya est en 1FN, ya estar en 2FN.
Para transformar una tabla con dependencias funcionales, cuya clave est formada por ms de un campo, en
una tabla en 2FN se necesitan crear tablas nuevas para eliminar las dependencias funcionales, las tablas
nuevas tendrn los atributos que dependen funcionalmente de la clave y los que forman la parte de la clave de

la que dependen. Una vez creadas las nuevas tablas, se eliminan de la tabla primera los atributos que tenan
dependencias funcionales.
En el ejemplo anterior, tanto el nombre como los apellidos dependen del NIF. Se crea una nueva tabla que
contiene los atributos: NIF, nombre y apellidos, eliminndose de la tabla cliente los atributos nombre y
apellidos, quedando las siguientes tablas:
NIF

Dir

CPost

Pobl

Prov

C/ Marn n16

33698

Oviedo

Asturias

C/ Teneras n34

85458

Cigales

Valladolid

C/ Ramorta n65

54585

Bueu

Pontevedra

NIF

Ape

Nom

Garca

Francisco

Sanchez

Luisa

Tercera Forma Normal o 3FN:

Se dice que hay dependencia funcional transitiva entre dos atributos cuando un atributo que no pertenece a la
clave primaria permite conocer el valor de otro atributo.
Por ejemplo: dada la tabla clientes, entre los atributos provincia y prefijo telefnico hay una dependencia
funcional transitiva, ya que el primero permite conocer el valor del segundo.
Una tabla est en Tercera Forma Normal o 3FN si est en 2FN y no existen atributos que no pertenezcan a la
clave primaria que puedan ser conocidos mediante otro atributo que no forma parte de la clave primaria, es
decir, no hay dependencias funcionales transitivas.
Siguiendo con el ejemplo anterior, cuando hay dependencias funcionales transitivas, se crea una nueva tabla
con los atributos que tienen dependencia funcional transitiva, eliminndose el atributo dependiente de la tabla
original.
Si nos fijamos en esta tabla:
NIF

Dir

CPost

Pobl

Prov

C/ Marn n16

33698

Oviedo

Asturias

C/ Teneras n34

85458

Cigales

Valladolid

C/ Ramorta n65

54585

Bueu

Pontevedra

La direccin, la poblacin y la provincia dependen del cdigo postal, que no forma parte de la clave primaria.
Descomponiendo sin perdida una vez ms, obtenemos estas dos tablas:

NIF

Dir

C/ Marn n16

C/ Teneras n34

C/ Ramorta n65

CPost

Dir

Pobl

Prov

33698

C/ Marn n16

Oviedo

Asturias

85458

C/ Teneras n34

Cigales

Valladolid

54585

C/ Ramorta n65

Bueu

Pontevedra

Para solucionar algunos problemas de dependencias funcionales, que no se podan resolver solo con la
normalizacin en 3FN, se han propuesto tres formas normales adicionales. La normalizacin ms all de 3FN
queda al juicio del diseador de la base de datos. A partir de esa forma normal, la eliminacin de
dependencias funcionales pasa por la creacin de tablas con multitud de informacin redundante, con un
posible aumento de tamao, por lo que se ha de optar entre una optimizacin del diseo y una optimizacin
del tamao. Llegndose a diversas soluciones de compromiso entre ambos parmetros. Salvo excepciones,
con la 3FN o a lo sumo, la FNBC (que veremos a continuacin) es ms que suficiente, y llevar la
normalizacin ms all ser ms perjudicial que beneficioso.
Forma Normal de Boyce-Codd o FNBC:
Una tabla est en Forma Normal de Boyce-Codd o FNBC si solo existen dependencias funcionales
elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria est
formada por un solo atributo y est en 3FN, ya est en FNBC.
Un ejemplo tpico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, sin
relacin con el ejemplo seguido hasta este momento, es una tabla que posee los atributos direccin, cdigo
postal y poblacin, suponiendo que a poblaciones diferentes le corresponden cdigos postales distintos.
CPost

Dir

Pobl

30009

C/ Pantano Camarillas n16

Murcia

48596

Av. Buenos Aires n12

Madrid

En este caso hay dependencia entre el cdigo postal y la poblacin, ya que, conocido el cdigo postal se
puede conocer la poblacin, y conocida la direccin y la poblacin, se conoce el cdigo postal. Para
transformar la tabla en una tabla en FNBC se crea una tabla de cdigos postales y poblaciones, eliminando de
la tabla original la poblacin, obtenindose dos tablas, una con los atributos direccin y cdigo postal y otra
con el cdigo postal y la poblacin:
CPost

Dir

30009

C/ Pantano Camarillas n16

48596

Av. Buenos Aires n12

CPost

Pobl

30009

Murcia

48596

Madrid

Cuarta Forma Normal o 4FN:

Existe dependencia funcional multivalorada o de mltiples valores si, dados tres atributos de una tabla, si para
cada valor del primer atributo existen mltiples valores en el segundo atributo y no hay ninguna relacin entre
el tercer atributo y el primero, a no ser a travs del segundo atributo.
Una tabla est en Cuarta Forma Normal o 4FN si est en FNBC y las nicas dependencias funcionales
multivaloradas que existen son las dependencias funcionales de la clave con los atributos que no forman parte
de la misma. Estas dependencias multievaluadas de la clave con los atributos que no forman parte de la
misma son dependencias triviales, por lo que algunos autores dicen que no existen dependencias
multievaluadas en 4FN.
Supongamos que los atributos de la tabla transporte son conductor, tipo de vehculo y tipo de carga, formando
los tres campos la clave primaria. A cada conductor se le puede asignar un vehculo u otro y cada vehculo
puede transportar varios tipos de carga.
Transporte
Conductor

Tipo Vehculo

Tipo Carga

Juan

Furgoneta

Perecederos

Marcos

Furgoneta

Perecederos

Juan

Furgoneta

Muebles

Marcos

Furgoneta

Muebles

Juan

Camin

Mudanza

Marcos

Camin

Mudanza

Con estas condiciones, los conductores son independientes de la carga; el tipo de vehculos depende del
conductor y el tipo de vehculo depende de la carga. En este caso hay dependencias funcionales
multivaloradas, ya que algunos atributos que forman la clave dependen de otro atributo que tambin la
forman.
Para conseguir que esta tabla est en 4FN se necesita crear dos nuevas tablas en lugar de la tabla actual,
manteniendose en cada una de ellas una dependencia mltiple. La primera tabla tendr los atributos

conductor y tipo de vehculo y la segunda, tipo de vehculo y tipo de carga. De este modo la tabla en 4FN
debido a que la clave primaria de ambas tablas son todos los campos que la forman. Resultado:
Tipo Vehculo

Tipo Carga

Furgoneta

Perecederos

Furgoneta

Perecederos

Furgoneta

Muebles

Furgoneta

Muebles

Camin

Mudanza

Camin

Mudanza

Conductor

Tipo Vehculo

Juan

Furgoneta

Marcos

Furgoneta

Juan

Furgoneta

Marcos

Furgoneta

Juan

Camin

Marcos

Camin

Quinta Forma Normal o 5FN:

Se dice que hay dependencia de JOIN, de unin o de producto si una tabla tiene dependencia de
*unin con varias de sus *proyecciones y se puede obtener la tabla por medio de la unin de dichas
proyecciones.
*Proyeccin:
Creacin de una tabla cuyos elementos forman un subconjunto de una
tabla dada. Se incluyen todas las filas y algunas columnas.

*Unin:
Formar, a partir de dos tablas, una nueva con todos los campos de una de
ellas y los registros de ambas, excepto los repetidos. Ambas tablas han de
tener el mismo grado y las mismas columnas.

Una tabla esta en Quinta Forma Normal (5FN) o Forma Normal de Proyeccin-Unin si est en 4FN y las
nicas dependencias que existen son las dependencias de unin de una tabla con sus proyecciones
relacionndose entre las distintas proyecciones mediante la clave primaria o cualquier clave alternativa. La
5FN se emplea cuando en una misma tabla tenemos mucha informacin redundante, con pocos atributos o
cuando una tabla posee una gran cantidad de atributos y se hace por ello inmanejable.
Para conseguir que una tabla 4FN con gran cantidad de atributos est en 5FN, se parte la tabla original en
tantas tablas como se desee, teniendo cada una de ellas en comn con las dems los campos que forman la
clave primaria en la tabla original.
Ejemplo para el caso de una tabla que posee una gran cantidad de atributos:
Datos
Familiares

Id

1 D1

D2

D3

Datos
Profesionales
D4

D5

D6

Datos
Personales
D7

D8

D9

Datos Clnicos
D10 D11 D12

En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y
clnicos de cada empleado en una nica tabla llamada Empleados. Si esta tabla est ya en 4FN, se puede
partir en las tablas empleados-personal, empleados-familia, empleados-profesional, empleados-clnicos; de
este modo, la velocidad de acceso y la gestin de datos por cada departamento de la empresa se simplifica, al
no tenerse que crear ningn tipo de restriccin sobre determinados atributos que no han de ser vistos por el
personal que no los necesite.
El resultado sera:
Id
1

Datos Familiares
D1

Id
1

Id

D5

D6

Datos Personales
D7

Id
1

D3

Datos Profesionales
D4

D2

D8

D9

Datos Clnicos
D10

D11

D12

Ejemplo para el caso de una tabla que posee mucha informacin redundante, con pocos atributos:
Biblioteca

Ttulo

Fecha

Socio

T1

FT

S1

T2

FU

S2

T3

FV

S1

T4

FG

S4

T1

FH

S3

T2

FT

S4

T3

FV

S3

Si se tiene una tabla de prstamo de libros de una biblioteca, con los atributos ttulo, fecha de prstamo y
nmero de socios que ha tomado prestado el libro, existen multitud de registros que se crean diariamente en
esa tabla, pero para cada libro o para cada socio habr pocos registros, con lo que una consulta para esa
tabla como: Cules son los libros ledos por un determinado socio?, puede tener una velocidad de respuesta
elevada. Si esta tabla se parte en las tablas ttulo-fecha, ttulo-socio y socio-fecha, cualquier consulta similar a
la anterior tendr un tiempo de respuesta tolerable, y cuando sea necesario, se podrn realizar consultas que
impliquen los datos de las tres tablas.
El resultado sera pues:
Ttulo-Fecha
Ttulo

Fecha

T1

FT

T2

FU

T3

FV

T4

FG

T1

FH

T2

FT

T3

FV

Ttulo-Socio
Ttulo

Socio

T1

S1

T2

S2

T3

S1

T4

S4

T1

S3

T2

S4

T3

S3

Fecha-Socio
Fecha

Socio

FT

S1

FU

S2

FV

S1

FG

S4

FH

S3

FT

S4

FV

S3