Unidad 3: Normalizacin:

Concepto:
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.

Disminuir 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 tabla 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.

Dependencia Funcional:
Una dependencia funcional es una conexin entre uno o ms atributos. Por ejemplo si se conoce el valor de
DNI tiene una conexin con Apellido o Nombre . (DNI (Documento Nacional de Identidad)
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento

Edad

De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias
funcionales para lograr la eficiencia en las tablas.
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

A partir de cualquier atributo o conjunto de atributos siempre puede deducirse l mismo. 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 y 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).
"C ser un dato simple (dato no primario), B,ser un otro dato simple (dato no primario), A, es la llave
primaria (PK). Decimos que C dependera de B y B dependera funcionalmente de A."

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
En la teora de bases de datos relacionales, las formas normales (NF) proporcionan los criterios para
determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalas lgicas. Cuanto ms alta sea
la forma normal aplicable a una tabla, menos vulnerable ser a inconsistencias y anomalas. Cada tabla tiene
una "forma normal ms alta" (HNF): por definicin, una tabla siempre satisface los requisitos de su HNF y
de todas las formas normales ms bajas que su HNF; tambin por definicin, una tabla no puede satisfacer
los requisitos de ninguna forma normal ms arriba que su HNF.
Los recin llegados al diseo de bases de datos a veces suponen que la normalizacin procede de una manera
iterativa, es decir un diseo 1NF primero se normaliza a 2NF, entonces a 3NF, etctera. sta no es una
descripcin exacta de cmo la normalizacin trabaja tpicamente. Una tabla sensiblemente diseada es
probable que est en 3NF en la primera tentativa; adems, si est en 3NF, tambin es extremadamente
probable que tenga una forma HNF de 5NF. Conseguir formas normales "ms altas" (sobre 3NF) usualmente
no requiere un gasto adicional de esfuerzo por parte del diseador, porque las tablas 3NF usualmente no
necesitan ninguna modificacin para satisfacer los requisitos de estas formas normales ms altas.
Edgar F. Codd originalmente defini las tres primeras formas normales (1NF, 2NF, y 3NF). Estas formas
normales se han resumido como requiriendo que todos los atributos no-clave sean dependientes en "la clave,
la clave completa, y nada excepto la clave". Las cuarta y quinta formas normales ( 4NF y 5NF) se ocupan
especficamente de la representacin de las relaciones muchos a muchos y uno muchos entre los atributos.
La sexta forma normal (6NF), en pocas palabras, se basa en el principio de que si se tiene ms de dos claves
candidatas en una tabla, se tendrn que crear otras tablas con estas.

Por ejemplo si tenemos "tem" con un id cdigo de producto y con los atributos descripcin y precio que son
claves candidatas se tendra que crear otras tablas separando la tabla tem: ItemDesc {cdigo_producto*,
Descripcin} ItemPrecio {cdigo_producto*, Precio}.
La sexta forma normal no es muy utilizada porque genera ms tablas cuando tenemos pequeas bases de
datos.

Primera Forma Normal (1FN)

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 nica.

La clave primaria no contiene atributos nulos.

No debe existir variacin en el nmero de columnas.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los
datos cambian de orden no deben cambiar sus significados

Una tabla no puede tener mltiples valores en cada columna.

Los datos son atmicos (a cada valor de X le pertenece un valor de Y y viceversa).

No hay filas duplicadas.

4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada
ms).

Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs de
objeto, o timestamps ocultos

Esta forma normal elimina los valores repetidos dentro de una BD

La primera forma normal (1FN o forma mnima) es una forma normal usada en normalizacin de bases
de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto
mnimo de criterios. Estos criterios se refieren bsicamente a asegurarse que la tabla es una representacin
fiel de una relacin y est libre de "grupos repetitivos".
La violacin de cualesquiera de estas condiciones significara que la tabla no es estrictamente relacional, y
por lo tanto no est en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definicin de
1FN son:

Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas duplicadas, en violacin de la
condicin 3.
Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estara en violacin de la

condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna
Grupos repetidos
. El siguiente ejemplo ilustra cmo un diseo de base de datos puede incorporar la repeticin de grupos, en
violacin de la 1FN.
Ejemplo 1: Dominios y valores
ID Cliente
123
456
789

Nombre
Rachel
James
Cesar

Cliente
Apellido
Ingram
Wright
Dure

Telfono
555-861-2025
555-403-1659
555-808-9633

En este punto, el diseador se da cuenta de un requisito para guardar mltiples nmeros telfonicos para
algunos clientes. Razona que la manera ms simple de hacer esto es permitir que el campo "Telfono"
contenga ms de un valor en cualquier registro dado:

123

Nombre
Rachel

Cliente
Apellido
Ingram

456

James

Wright

789

Cesar

Dure

ID Cliente

Telfono
555-861-2025
555-403-1659
555-776-4100
555-808-9633

Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio de nmero
telefnico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representacin de arriba no
est en 1FN. La 1FN (y, para esa materia, el RDBMS) prohbe a un campo contener ms de un valor de su
dominio de columna.
Ejemplo 2: Grupos repetidos a travs de columnas
El diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico:

ID Cliente
123
456
789

Nombre
Rachel
James
Cesar

Apellido
Ingram
Wright
Dure

Cliente
Telfono 1
555-861-2025
555-403-1659
555-808-9633

Telfono 2

Telfono 3

555-776-4100

Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por lo tanto no se
conforman con la definicin de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con
valores nulos, el diseo no est en armona con el espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3,
comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del nmero de
telfono en tres encabezados es artificial y causa problemas lgicos. Estos problemas incluyen:

Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como "Qu clientes
tienen el telfono X?" y "Qu pares de clientes comparten un nmero de telfono?".

La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono por medio del
RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Telfono 2 que es
exactamente igual que el valor de su Telfono 1.

La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente con cuatro nmeros
de telfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa
que el diseo de la base de datos est imponiendo restricciones al proceso del negocio, en vez de
(como idealmente debe ser el caso) al revs.

Ejemplo 3: Repeticin de grupos dentro de columnas

El diseador puede, alternativamente, conservar una sola columna de nmero de telfono, pero
alterando su dominio, haciendo una cadena de suficiente longitud para acomodar mltiples nmeros
telefnicos:

Cliente
ID Cliente
123
456
789

Nombre
Rachel
James
Cesar

Apellido
Ingram
Wright
Dure

Telfono
555-861-2025
555-403-1659, 555-776-4100
555-808-9633

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu de la 1NF. El
encabezado "Telfono" llega a ser semnticamente difuso, ya que ahora puede representar, o un
nmero de telfono, o una lista de nmeros de telfono, o de hecho cualquier cosa. Una consulta
como "Qu pares de clientes comparten un nmero telefnico?" es virtualmente imposible de
formular, dada la necesidad de proveerse de listas de nmeros telefnicos as como nmeros
telefnicos individuales. Con este diseo en la RDBMS, son tambin imposibles de definir
significativas restricciones en nmeros telefnicos.

Un diseo conforme con 1FN

Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla
de telfono del cliente.
Cliente
ID Cliente

123
456
789

Nombre
Rachel
James
Cesar

Apellido
Ingram
Wright
Dure

123
456
456
789

Telfono del cliente

ID Cliente
Telfono
555-861-2025
555-403-1659
555-776-4100
555-808-9633

En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso, cada enlace Cliente-aTelfono aparece en su propio registro. Es valioso notar que este diseo cumple los requerimientos
adicionales para la segunda (2NF) y la tercera forma normal (3FN).

segunda Forma Normal (2FN)

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. (Todos los atributos que no son clave principal deben depender nicamente de la clave principal).
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.
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 funcional 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.
La segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de datos. La 2NF
fue definida originalmente por E.F. Codd1 en 1971. Una tabla que est en la primera forma normal (1NF)
debe satisfacer criterios adicionales para calificar para la segunda forma normal. Especficamente: una tabla
1NF est en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente de la
clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de una parte de ella.
En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus atributos noprincipales son funcionalmente dependientes en una parte (subconjunto propio) de una clave primaria (Un
atributo no-principal es uno que no pertenece a ninguna clave primaria).
Ejemplo
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
Empleado
Jones
Jones
Jones
Bravo
Ellis
Ellis
Harrison

Habilidad
Mecanografa
Taquigrafa
Tallado
Limpieza ligera
Alquimia
Malabarismo
Limpieza ligera

Lugar actual de trabajo

114 Main Street
114 Main Street
114 Main Street
73 Industrial Way
73 Industrial Way
73 Industrial Way
73 Industrial Way

La nica clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada
Empleado. Por lo tanto la tabla no est en 2NF. Observe la redundancia de la manera en que son
representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y
dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalas de
actualizacin: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografa"
y "Taquigrafa" y no actualizar su registro "Tallado". Los datos resultantes implicaran respuestas
contradictorias a la pregunta "Cul es el lugar actual de trabajo de Jones?".
Un alternativa 2NF a este diseo representara la misma informacin en dos tablas:
Empleados
Empleado
Jones
Bravo
Ellis
Harrison

Lugar actual de trabajo

114 Main Street
73 Industrial Way
73 Industrial Way
73 Industrial Way

Habilidades de los empleados

Empleado
Habilidad
Jones
Mecanografa
Jones
Taquigrafa
Jones
Tallado
Bravo
Limpieza ligera
Ellis
Alquimia
Ellis
Malabarismo
Harrison
Limpieza ligera
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF.
Tercera Forma Normal (3FN)
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..
La tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos. La 3NF
fue definida originalmente por E.F. Codd1 en 1971. La definicin de Codd indica que una tabla est en 3NF
si y solo si las dos condiciones siguientes se cumplen:

La tabla est en la segunda forma normal (2NF)

Ningn atributo no-primario de la tabla es dependiente transitivamente de una clave primaria

Es una relacion que no incluye ningun atributo clave

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Una dependencia
transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente dependiente de X, pero s
de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X Z por virtud de X Y e Y
Z.
Nada excepto la clave"
Un memorable resumen de la definicin de Codd de la 3NF, siendo paralelo al compromiso tradicional de
dar evidencia verdadera en un tribunal de justicia, fue dado por Bill Kent: cada atributo no-clave "debe
proporcionar un hecho sobre la clave, la clave entera, y nada ms excepto la clave". 3 Una variacin comn
complementa esta definicin con el juramento: "con la ayuda de Codd". 4
Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla est en
2NF; un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave"
asegura que la tabla est en 3NF.

Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
Ganadores del torneo
Torneo
Ao
Ganador
Indiana Invitational
1998 Al Fredrickson
Cleveland Open
1999 Bob Albertson
Des Moines Masters
1999 Al Fredrickson
Indiana Invitational
1999 Chip Masterson
La nica clave candidata es {Torneo, Ao}.

Fecha de nacimiento del ganador

21 de julio de 1975
28 de septiembre de 1968
21 de julio de 1975
14 de marzo de 1977

La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es
dependiente transitivamente de {Torneo, Ao} va el atributo no primario Ganador. El hecho de que la
Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a
inconsistencias lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas
de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:

Torneo
Indiana Invitational
Cleveland Open
Des Moines Masters
Indiana Invitational

Ganadores del torneo

Ao
1998
1999
1999
1999

Ganador
Al Fredrickson
Bob Albertson
Al Fredrickson
Chip Masterson

Fecha de nacimiento del jugador

Ganador
Chip Masterson
Al Fredrickson
Bob Albertson

Fecha de nacimiento
14 de marzo de 1977
21 de julio de 1975
28 de septiembre de 1968

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.

Forma normal de Boyce-Codd (FNBC) (BCNF)

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
formalizacin perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya
planificadas, dejan de existir.
Formalmente, un esquema de relacin
vlida en , se cumple que
1.

est en FNBC, si y slo si, para toda dependencia funcional

es superllave o clave.

De esta forma, todo esquema que cumple FNBC, est adems en 3FN; sin embargo, no todo esquema
que cumple con 3FN, est en FNBC.
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin de bases
de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN). La forma normal de
Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un
conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave
completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como
).
Se dice que una tabla est en FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una
clave candidata como determinante. En trminos menos formales, una tabla est en FNBC si est en 3FN y
los nicos determinantes son claves candidatas.
Ejemplo
Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada
departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos una tabla
con las columnas:

IDTrabajador, IDDepartamento, IDResponsable

La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).
Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle produce
una dependencia funcional ya que: Responsable Departamento

Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave candidata. Por
ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala seleccin de clave. La
repeticin del par [IDDepartamento + IDResponsable] es innecesaria y evitable.
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo de tal
tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor)

El propsito de la
tutores estn asignados a qu estudiantes. Las claves candidatas de la tabla son:

{ID Tutor, ID Estudiante}

{Nmero de seguro social del tutor, ID Estudiante}

tabla es mostrar qu

Otra formulacin
Una forma sencilla de comprobar si una relacin se encuentra en FNBC consiste en comprobar, adems de
que est en 3FN, lo siguiente:

(1) Si no existen claves candidatas compuestas (con varios atributos), est en FNBC.

(2) Si existen varias claves candidatas compuestas y stas tienen un elemento comn, puede no estar
en FNBC. Slo si, para cada dependencia funcional en la relacin, el determinante es una clave
candidata, estar en FNBC.

Cuarta Forma Normal (4FN)

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.
La cuarta forma normal (4NF) es una forma normal usada en la normalizacin de bases de datos. La 4NF
se asegura de que las dependencias multivaluadas independientes estn correctas y eficientemente
representadas en un diseo de base de datos. La 4NF es el siguiente nivel de normalizacin despus de la
forma normal de Boyce-Codd (BCNF).
Caractersticas
Una tabla est en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera de ambas) y no
posee dependencias multivaluadas no triviales. La definicin de la 4NF confa en la nocin de una
dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o

ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es

suprimida por la cuarta forma normal
Considere el siguiente ejemplo:

Restaurante
Vincenzo's Pizza
Vincenzo's Pizza
Vincenzo's Pizza
Vincenzo's Pizza
Elite Pizza
Elite Pizza
A1 Pizza
A1 Pizza
A1 Pizza
A1 Pizza
A1 Pizza
A1 Pizza

Permutaciones de envos de pizzas

Variedad de Pizza
Corteza gruesa
Corteza gruesa
Corteza fina
Corteza fina
Corteza fina
Corteza rellena
Corteza gruesa
Corteza gruesa
Corteza gruesa
Corteza rellena
Corteza rellena
Corteza rellena

rea de envo
Springfield
Shelbyville
Springfield
Shelbyville
Capital City
Capital City
Springfield
Shelbyville
Capital City
Springfield
Shelbyville
Capital City

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un rea dada.
Note que debido a que la tabla tiene una clave nica y ningn atributo no-clave, no viola ninguna forma
normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son
independientes de las reas a las cuales el restaurante enva, hay redundancia en la tabla: por ejemplo, nos
dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza
de queso entonces necesitaremos agregar mltiples registros, uno para cada una de las reas de envo de A1
Pizza. En trminos formales, esto se describe como que Variedad de pizza est teniendo una dependencia
multivalor en Restaurante.
Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla
diferente de los hechos sobre reas de envo:

Variedades por restaurante

Restaurante
Variedad de pizza
Vincenzo's Pizza Corteza gruesa
Vincenzo's Pizza Corteza fina
Elite Pizza
Corteza fina
Elite Pizza
Corteza rellena
A1 Pizza
Corteza gruesa
A1 Pizza
Corteza rellena

reas de envo por restaurante

Restaurante
rea de envo
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
Elite Pizza
Capital City
A1 Pizza
Springfield
A1 Pizza
Shelbyville
A1 Pizza
Capital City

En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un rea de envo a
otra, la tabla original de la tres columnas satisfara la 4NF.
Ronald Fagin demostr que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de
Rissanen es tambin aplicable en dependencias multivalor.

4NF en la prctica
Un artculo de 1992 de Margaret S. Wu observa que la enseanza de la normalizacin de la base de datos se
detiene tpicamente justo antes de la 4NF, quizs debido a una creencia que las tablas que violan la 4NF
(pero que hacen frente a todas las formas normales ms bajas) son raramente encontradas en aplicaciones
empresariales. Sin embargo, esta creencia puede no ser exacta. Wu reporta que en un estudio de cuarenta
bases de datos de organizaciones, ms del 20% contena una o ms tablas que violaban la 4NF mientras que
satisfacen todas las formas normales ms bajas. 1

Quinta Forma Normal (5FN)

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 claves candidatas.

La quinta forma normal (5FN), tambin conocida como monda (PJ/NF), es un nivel de normalizacin de
bases de datos diseado para reducir redundancia en las bases de datos relacionales que guardan hechos
multi-valores aislando semnticamente relaciones mltiples relacionadas. Una tabla se dice que est en 5NF
si y slo si est en 4NF y cada dependencia de unin (join) en ella es implicada por las claves candidatas.
Ejemplo
Considere el siguiente ejemplo:

Psiquiatra
Dr. James
Dr. James
Dr. Kendrick
Dr. Kendrick
Dr. Kendrick
Dr. Lowenstein
Dr. Lowenstein
Dr. Lowenstein
Dr. Lowenstein

Psiquiatra-para-Asegurador-para-Condicin
Asegurador
Condicin
Healthco
Ansiedad
Healthco
Depresin
FriendlyCare
OCD
FriendlyCare
Ansiedad
FriendlyCare
Depresin
FriendlyCare
Esquizofrenia
Healthco
Ansiedad
Healthco
Demencia
Victorian Life
Trastorno de conversin

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condicin dada y que
son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja las combinaciones
vlidas posibles de psiquiatra, asegurador, y condicin, la tabla de tres atributos Psiquiatra-para-Aseguradorpara-Condicin es necesaria para modelar la situacin correctamente.

Sin embargo, suponga que la regla siguiente se aplica:

Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados
por el asegurador P, y el psiquiatra puede tratar la condicin C, entonces - en caso que el asegurador
P cubra la condicin C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a
los pacientes que sufren de la condicin C y estn asegurados por el asegurador P.

Con estas restricciones es posible dividir la relacin en tres partes.

Note como esta disposicin ayuda a quitar redundancia. Suponga que el Dr. James se convierte en un
proveedor de tratamientos para FriendlyCare. En la disposicin anterior tendramos que agregar dos nuevas
entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por FriendlyCare: ansiedad y
depresin. Con la nueva disposicin necesitamos agregar una sola entrada (en la tabla Psiquiatra-paraAsegurador).