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 relacin1 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. Navathe3 ). Por otro lado, segn lo definido por otros autores, la
1FN s los permite (por ejemplo como la define Chris Date).
ndice
[ocultar]

1 Las tablas 1FN como representaciones de relaciones

2 Grupos repetidos
o

2.1 Ejemplo 1: Dominios y valores

2.2 Ejemplo 2: Grupos repetidos a travs de columnas

2.3 Ejemplo 3: Repeticin de grupos dentro de columnas

2.4 Un diseo 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[editar]
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[editar]
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[editar]

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

123

Rachel

Ingram

456

James

Wright

789

Cesar

Dure

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[editar]
El diseador puede evitar esta restriccin definiendo mltiples
columnas del nmero telefnico:

Cliente

ID Cliente

Nombre

Apellido

Telfono 1

123

Rachel

Ingram

555-861-2025

456

James

Wright

555-403-1659

789

Cesar

Dure

555-808-9633

Telfono 2

555-776-4100

Telfon

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;
dividir los nmeros 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 Clientea-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[editar]
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

Nombre

Rachel

Apellido

Ingram

Telfono

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 con 1FN[editar]

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[editar]
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[editar]

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 laintegridad 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

Apell

del subscriptor

subs

108

steve@aardvarkmail.net

Steve

Wallace

252

carol@mongoosemail.org

Carol

Roberts

252

crobertson@aardvarkmail.net

Carol

Roberts

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.

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 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
[ocultar]

1 Ejemplo

2 2NF y las claves candidatas

3 Referencias

4 Lectura adicional

5 Vase tambin

6 Enlaces externos

Ejemplo[editar]
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
combinacionesGanador / 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[editar]

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.

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 tres 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 relacin que no incluye ningn 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
[ocultar]

1 "Nada excepto la clave"

2 Ejemplo

3 Derivacin de las condiciones de Zaniolo

4 Normalizacin ms all de la 3NF

5 Referencias

6 Lectura adicional

7 Vase tambin

8 Enlaces externos

"Nada excepto la clave"[editar]

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[editar]
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

25 de junio de 1985

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 primarioGanador.
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 Zaniolo[editar]

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[editar]

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.

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
[ocultar]

1 Caractersticas

2 Dependencia multivaluada

3 Ejemplo

4 4NF en la prctica

5 Referencias

6 Vase tambin

Caractersticas[editar]
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[editar]
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[editar]
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 laCorteza
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 deA1
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

reas de envo por restaurante

Restaurante

Variedad de
pizza

rea de
envo

Corteza gruesa

Vincenzo's
Pizza

Springfield

Vincenzo's
Pizza

Corteza fina

Vincenzo's
Pizza

Shelbyville

Elite Pizza

Corteza fina

Elite Pizza

Capital City

Elite Pizza

Corteza rellena

A1 Pizza

Springfield

A1 Pizza

Corteza gruesa

A1 Pizza

Shelbyville

A1 Pizza

Corteza rellena

A1 Pizza

Capital City

Vincenzo's
Pizza

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[editar]
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