Primera forma normal

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
1
y est libre de "grupos repetitivos".
2

Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por
diferentes tericos. Como consecuencia, no hay un acuerdo universal en cuanto a qu
caractersticas descalificaran a una tabla de estar en 1FN. Muy notablemente, la 1FN,
tal y como es definida por algunos autores excluye "atributos relacin-valor" (tablas
dentro de tablas) siguiendo el precedente establecido por (E.F. Codd) (algunos de esos
autores son: Ramez Elmasri y Shamkant B. Navathe
3
). Por otro lado, segn lo definido
por otros autores, la 1FN s los permite (por ejemplo como la define Chris Date).
ndice
1 Las tablas 1FN como representaciones de relaciones
2 Grupos repetidos
o 2.1 Ejemplo 1: Dominios y valores
o 2.2 Ejemplo 2: Grupos repetidos a travs de columnas
o 2.3 Ejemplo 3: Repeticin de grupos dentro de columnas
o 2.4 Un diseo conforme con 1FN
3 Atomicidad
4 Normalizacin ms all de la 1NF
5 Notas y referencias
6 Vase tambin
7 Lectura adicional
8 Enlaces externos
Las tablas 1FN como representaciones de relaciones
Segn la definicin de Date de la 1FN, una tabla est en 1FN si y solo si es "isomorfa a
alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco
condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila-y-columna contiene exactamente un valor
del dominio aplicable (y nada ms).
5. Todas las columnas son regulares [es decir, las filas no tienen
componentes como IDs de fila, IDs de objeto, o timestamps ocultos].
Chris Date, "What First Normal Form Really Means", pp. 127-8
4

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 vista cuya definicin exige que los resultados sean retornados en un orden
particular, de modo que el orden de la fila sea un aspecto intrnseco y
significativo de la vista.
5
Esto viola la condicin 1. Las tuplas en relaciones
verdaderas no estn ordenadas una con respecto de la otra.
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. Sin embargo, debe
observarse que este aspecto de la condicin 4 es controvertido. Muchos autores
consideran que una tabla est en 1FN si ninguna clave candidata puede contener
valores nulos, pero se aceptan stos para atributos (campos) que no sean clave,
segn el modelo original de Codd sobre el modelo relacional, el cual hizo
disposicin explcita para los nulos.
6

Grupos repetidos
La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la
caracterstica que define la 1FN",
7
concierne a 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
Suponga que un diseador principiante desea guardar los nombres y los nmeros
telefnicos de los clientes. Procede a definir una tabla de cliente como la que sigue:
Cliente
ID Cliente Nombre Apellido Telfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
789 Cesar Dure 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:
Cliente
ID Cliente Nombre Apellido Telfono
123 Rachel Ingram 555-861-2025
456 James Wright
555-403-1659
555-776-4100
789 Cesar Dure 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:
Cliente
ID Cliente Nombre Apellido Telfono 1 Telfono 2 Telfono 3
123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100

789 Cesar Dure 555-808-9633

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 Nombre Apellido Telfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659, 555-776-4100
789 Cesar Dure 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 Nombre Apellido
123 Rachel Ingram
456 James Wright
789 Cesar Dure
Telfono del cliente
ID Cliente Telfono
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633
En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso,
cada enlace Cliente-a-Telfono 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).
Atomicidad
Algunas definiciones de 1NF, ms notablemente la de E.F. Codd, hacen referencia al
concepto de atomicidad. Codd indica que "se requiere que los valores sean atmicos con
respecto al DBMS en los dominios en los que cada relacin es definida".
8
Codd define
un valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos
por el DBMS (excepto ciertas funciones especiales)".
9

[Hugh Darwen] y [Chris Date] han sugerido que el concepto de Codd de un "valor
atmico" es ambiguo, y que esta ambigedad ha conducido a una extensa confusin
sobre cmo debe ser entendida la 1NF.
10

11
En particular, la nocin de un "valor que no
puede ser descompuesto" es problemtica, pues parecera implicar que pocos, si algn,
tipos de datos son atmicos:
Una cadena de caracteres parecera no ser atmica, ya que el RDBMS
tpicamente proporciona operadores para descomponerla en subcadenas.
Una fecha parecera no ser atmica, ya que el RDBMS proporciona tpicamente
operadores para descomponerla los componentes de da, mes, y ao.
Un nmero de punto fijo parecera no ser atmico, ya que el RDBMS
proporciona tpicamente operadores para descomponerlo en componentes de
nmeros enteros y fraccionarios.
Date sugiere que "la nocin de atomicidad no tiene ningn significado absoluto":
12
un
valor puede ser considerado atmico para algunos propsitos, pero puede ser
considerado un ensamblaje de elementos ms bsicos para otros propsitos. Si esta
posicin es aceptada, la 1NF no puede ser definida con referencia a la atomicidad. Las
columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos
numricos hasta tipos de arreglos y tipos de tabla) son entonces aceptables en un tabla
1NF - aunque quizs no siempre deseable. Date discute que los atributos relacin-valor,
por medio de los cuales un campo dentro de una tabla puede contener una tabla, son
tiles en casos raros.
13

Normalizacin ms all de la 1NF
Cualquier tabla que est en la segunda forma normal (2NF) o ms arriba, tambin est,
por definicin, en 1NF (cada forma normal tiene criterios ms rigurosos que su
precursor). Por una parte, una tabla que est en 1NF puede o no puede estar en 2NF; si
est en 2NF, puede o no puede estar en 3NF, y as sucesivamente.
Las formas normales ms arriba que la 1NF son pensadas para ocuparse de las
situaciones en las que una tabla sufre de problemas de diseo que pueden comprometer
la integridad de los datos dentro de ella. Por ejemplo, la tabla siguiente est en 1NF,
pero no est en 2NF y por lo tanto es vulnerable a inconsistencias lgicas:
Direccin de correo del subscriptor
ID del
subscriptor
Direccin de correo
Primer nombre del
subscriptor
Apellido del
subscriptor
108 steve@aardvarkmail.net Steve Wallace
252 carol@mongoosemail.org Carol Robertson
252 crobertson@aardvarkmail.net Carol Robertson
360 hclark@antelopemail.com Harriet Clark
La clave de la tabla es {ID del subscriptor, Direccin de correo}.
Si Carol Robertson cambia su apellido por el de matrimonio, el cambio debe ser
aplicado a dos filas. Si el cambio es aplicado solamente a una fila, resulta en una
contradiccin: la pregunta "cul es nombre del cliente 252?" tiene dos respuestas que
estn en conflicto. La 2NF aborda este problema.



Segunda forma normal
La segunda forma normal (2NF) es una forma normal usada en normalizacin de
bases de datos. La 2NF fue definida originalmente por E.F. Codd
1
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 no-principales 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).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves
candidatas consistiendo en ms de un atributo), la tabla est automticamente en 2NF.
ndice
1 Ejemplo
2 2NF y las claves candidatas
3 Referencias
4 Lectura adicional
5 Vase tambin
6 Enlaces externos
Ejemplo
Considere una tabla describiendo las habilidades de los empleados:
Habilidades de los empleados
Empleado Habilidad Lugar actual de trabajo
Jones Mecanografa 114 Main Street
Jones Taquigrafa 114 Main Street
Jones Tallado 114 Main Street
Bravo Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 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 Lugar actual de trabajo
Jones 114 Main Street
Bravo 73 Industrial Way
Ellis 73 Industrial Way
Harrison 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.
Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un
ejemplo de una tabla 2NF que sufre de anomalas de actualizacin es:
Ganadores del torneo
Torneo Ao Ganador Fecha de nacimiento del ganador
Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas por una
clave completa {Torneo, Ao} y no son partes de ella, particularmente las
combinaciones Ganador / Fecha de nacimiento del ganador son mostradas
redundantemente en mltiples registros. Este problema es tratado por la tercera forma
normal (3NF).
2NF y las claves candidatas
Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria
est tpicamente, pero no siempre, en 2NF. Adems de la clave principal, la tabla puede
contener otras claves candidatas; es necesario establecer que ningn atributo no-
principal tienen dependencias de clave parciales en cualesquiera de estas claves
candidatas.
Las mltiples claves candidatas ocurren en la siguiente tabla:
Modelos elctricos de cepillo de dientes
Fabricante Modelo Nombre completo del modelo Pas del fabricante
Forte X-Prime Forte X-Prime Italia
Forte Ultraclean Forte Ultraclean Italia
Dent-o-Fresh EZBrush Dent-o-Fresh EZBrush USA
Kobayashi ST-60 Kobayashi ST-60 Japn
Hoch Toothmaster Hoch Toothmaster Alemania
Hoch Contender Hoch Contender Alemania
Aun si el diseador ha especificado la clave principal como {Nombre completo del
modelo}, la tabla no est en 2NF. {Fabricante, Modelo} es tambin una clave candidata,
y Pas del fabricante es dependiente en un subconjunto apropiado de l: Fabricante.














Tercera forma normal
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. Codd
1
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.
Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo
2
en 1982,
es sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias
funcionales X A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A,
X es una superclave,
A es un atributo primario (es decir, A est contenido dentro de una clave
candidata)
La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la
3NF y la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente
elimina la tercera alternativa ("A es un atributo primario").
ndice
1 "Nada excepto la clave"
2 Ejemplo
3 Derivacin de las condiciones de Zambruno
4 Normalizacin ms all de la 3NF
5 Referencias
6 Lectura adicional
7 Vase tambin
8 Enlaces externos
"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.
Chris Date refiere al resumen de Kent como "una intuitiva atractiva caracterizacin" de
la 3NF, y observa que con una ligera adaptacin puede servir como definicin
ligeramente ms fuerte de la forma normal de Boyce-Codd: "Cada atributo debe
representar un hecho acerca de la clave, la clave entera, y nada excepto la clave".
5
La
versin 3NF de la definicin es ms dbil que la variacin de BCNF de Date, pues el
anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes
en las claves. Los atributos primarios (que son claves o partes de claves) no deben ser
funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre
la clave en el sentido de proporcionar parte o toda la clave en s misma. Debe ser
observado que esta regla se aplica solamente a los atributos funcionalmente
dependientes, ya que aplicndola a todos los atributos prohibira implcitamente claves
de candidato compuestas, puesto que cada parte de cualquiera de tales claves violara la
clusula de "clave completa"..
Ejemplo
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
Ganadores del torneo
Torneo Ao Ganador Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977
La nica clave candidata es {Torneo, Ao}.
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:
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
Fecha de nacimiento del jugador
Ganador Fecha de nacimiento
Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 de julio de 1975
Bob Albertson 28 de septiembre de 1968
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en
3NF.
Derivacin de las condiciones de Zambruno
La definicin de 3NF ofrecida por Carlo Zaniolo en 1982, y dada arriba, es probada as:
Sea X A un FD no trivial (es decir, uno donde X no contiene a A) y sea A un atributo
no clave. Tambin sea Y una clave de R. Entonces Y X. Por lo tanto A no es
dependiente transitivo de Y, si y solo si el X Y, es decir, si y solo si X es una
superclave.
6

Normalizacin ms all de la 3NF
La mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin, y
borrado. Ciertos tipos de tablas 3NF, que en la prctica raramente se encuentran, son
afectadas por tales anomalas; stas son tablas que no satisfacen la forma normal de
Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las
formas normales ms altas 4NF o 5NF.













Cuarta forma normal
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).
ndice
1 Caractersticas
2 Dependencia multivaluada
3 Ejemplo
4 4NF en la prctica
5 Referencias
6 Vase tambin
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.
Dependencia multivaluada
Sea R un esquema de relacin. La dependencia multivaluada X ->> Y vale en R si los
pares de tuplas t1 y t2 en R, tal que t1[X] = t2[X] existen las tuplas t3 y t4 en R tales
que:
t1[X] = t2[X] = t3[X] = t4[X]
t3[Y] = t1[Y]
t3[R-X-Y] = t2[R-X-Y]
t4[Y] = t2[Y]
t4[R-X-Y] = t1[R-X-Y]
En otras palabras se puede decir que: X ->> Y si dado un valor de X, hay un conjunto
de valores de Y asociados y este conjunto de valores de Y NO est relacionado (ni
funcional ni multifuncionalmente) con los valores de R - X -Y (donde R es el esquema),
es decir Y es independiente de los atributos de R-X-Y. (Ctedra de Base de Datos 1,
2009) Una dependencia multivaluada de la forma X->> Y, es trivial cuando el conjunto
de atributos {X,Y} conforma el total de los atributos del esquema.
Ejemplo
Considere el siguiente ejemplo:
Permutaciones de envos de pizzas
Restaurante Variedad de Pizza rea de envo
Vincenzo's Pizza Corteza gruesa Springfield
Vincenzo's Pizza Corteza gruesa Shelbyville
Vincenzo's Pizza Corteza fina Springfield
Vincenzo's Pizza Corteza fina Shelbyville
Elite Pizza Corteza fina Capital City
Elite Pizza Corteza rellena Capital City
A1 Pizza Corteza gruesa Springfield
A1 Pizza Corteza gruesa Shelbyville
A1 Pizza Corteza gruesa Capital City
A1 Pizza Corteza rellena Springfield
A1 Pizza Corteza rellena Shelbyville
A1 Pizza Corteza rellena 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
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 Corteza gruesa
A1 Pizza Corteza rellena
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
La quinta forma normal (5FN), tambin conocida como forma normal de
proyeccin-unin (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.
ndice
1 Ejemplo:
2 Uso
3 Referencias
4 Vase tambin
Ejemplo:
Considere el siguiente ejemplo:
Psiquiatra-para-Asegurador-para-Condicin
Psiquiatra Asegurador Condicin
Dr. James Healthco Ansiedad
Dr. James Healthco Depresin
Dr. Kendrick FriendlyCare OCD
Dr. Kendrick FriendlyCare Ansiedad
Dr. Kendrick FriendlyCare Depresin
Dr. Lowenstein FriendlyCare Esquizofrenia
Dr. Lowenstein Healthco Ansiedad
Dr. Lowenstein Healthco Demencia
Dr. Lowenstein 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-Asegurador-para-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.
Psiquiatra-para-Condicin
Psiquiatra Condicin
Dr. James Ansiedad
Dr. James Depresin
Dr.
Kendrick
OCD
Dr.
Kendrick
Ansiedad
Dr.
Kendrick
Depresin
Dr.
Lowenstein
Esquizofrenia
Dr.
Lowenstein
Ansiedad
Dr.
Lowenstein
Demencia
Dr.
Lowenstein
Trastorno de
conversin
Psiquiatra-para-
Asegurador
Psiquiatra Asegurador
Dr. James Healthco
Dr.
Kendrick
FriendlyCare
Dr.
Lowenstein
FriendlyCare
Dr.
Lowenstein
Healthco
Dr.
Lowenstein
Victorian
Life
Asegurador-para-Condicin
Asegurador Condicin
Healthco Ansiedad
Healthco Depresin
Healthco Demencia
FriendlyCare OCD
FriendlyCare Ansiedad
FriendlyCare Depresin
FriendlyCare
Trastorno
emocional
FriendlyCare Esquizofrenia
Victorian
Life
Trastorno de
conversin
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-para-Asegurador).
Uso
Solamente en contadas ocasiones una tabla 4NF no se corresponde con una 5NF. stas
son situaciones en las cuales una restriccin compleja del mundo real, que limita las
combinaciones vlidas de los valores de atributos en la tabla 4NF, no est implcita en
la estructura de esa tabla. Si esa tabla no se normaliza a 5NF, la tarea de mantener la
consistencia lgica de los datos dentro de la tabla debe ser llevada en parte por la
aplicacin responsable de inserciones, borrados, y actualizaciones a ella; y hay un riesgo
elevado de que los datos dentro de la tabla se vuelvan inconsistentes. Por el contrario, el
diseo 5NF excluye la posibilidad de tales inconsistencias.