Laprimera forma normal(1FNoforma mnima) es unaforma normalusada ennormalizacin 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 unarelacin1y est libre de "grupos repetitivos".2Sin 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 defineChris Date).ndice[ocultar] 1Las tablas 1FN como representaciones de relaciones 2Grupos repetidos 2.1Ejemplo 1: Dominios y valores 2.2Ejemplo 2: Grupos repetidos a travs de columnas 2.3Ejemplo 3: Repeticin de grupos dentro de columnas 2.4Un diseo con 1FN 3Atomicidad 4Normalizacin ms all de la 1NF 5Notas y referencias 6Vase tambin 7Lectura adicional 8Enlaces externosLas tablas 1FN como representaciones de relaciones[editar]Segn la definicin de Date de la 1FN, una tabla est en 1FNsi y solo sies "isomorfaa 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-84La 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 devistas) que no satisfacen esta definicin de 1FN son: Una tabla que carece de unaclave 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.5Esto viola la condicin 1. Lastuplasen relaciones verdaderas no estn ordenadas una con respecto de la otra. Una tabla con por lo menos un atributo que pueda sernulo. 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 elmodelo relacional, el cual hizo disposicin explcita para los nulos.6Grupos repetidos[editar]La cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa comolacaracterstica que define la 1FN",7concierne 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 ClienteNombreApellidoTelfono

123RachelIngram555-861-2025

456JamesWright555-403-1659

789CesarDure555-808-9633

En este punto, el diseador se da cuenta de un requisito para guardarmltiplesnmeros 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 ClienteNombreApellidoTelfono

123RachelIngram555-861-2025

456JamesWright555-403-1659555-776-4100

789CesarDure555-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, elRDBMS) 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 ClienteNombreApellidoTelfono 1Telfono 2Telfono 3

123RachelIngram555-861-2025

456JamesWright555-403-1659555-776-4100

789CesarDure555-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; 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 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[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 ClienteNombreApellidoTelfono

123RachelIngram555-861-2025

456JamesWright555-403-1659, 555-776-4100

789CesarDure555-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 sersemnticamentedifuso, 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 ClienteNombreApellido

123RachelIngram

456JamesWright

789CesarDure

Telfono del cliente

ID ClienteTelfono

123555-861-2025

456555-403-1659

456555-776-4100

789555-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".8Codd 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.1011En 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 atomicidadno tiene ningn significado absoluto":12un 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.13Normalizacin ms all de la 1NF[editar]Cualquier tabla que est en lasegunda 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 en3NF, 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 laintegridadde 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 subscriptorDireccin de correoPrimer nombre del subscriptorApellido del subscriptor

108steve@aardvarkmail.netSteveWallace

252carol@mongoosemail.orgCarolRobertson

252crobertson@aardvarkmail.netCarolRobertson

360hclark@antelopemail.comHarrietClark

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.

Lasegunda forma normal(2NF) es unaforma normalusada ennormalizacin de bases de datos. La 2NF fue definida originalmente porE.F. Codd1en 1971. Una tabla que est en laprimera forma normal(1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Especficamente: una tabla 1NF est en 2NFsi y solo si, dada unaclave primariay cualquier atributo que no sea un constituyente de laclave primaria, el atributo no clave depende de toda laclave primariaen 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 sonfuncionalmente dependientesen una parte (subconjunto propio) de unaclave primaria(Un atributo no-principal es uno que no pertenece a ningunaclave 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] 1Ejemplo 22NF y las claves candidatas 3Referencias 4Lectura adicional 5Vase tambin 6Enlaces externosEjemplo[editar]Considere una tabla describiendo las habilidades de los empleados:Habilidades de los empleados

EmpleadoHabilidadLugar actual de trabajo

JonesMecanografa114 Main Street

JonesTaquigrafa114 Main Street

JonesTallado114 Main Street

BravoLimpieza ligera73 Industrial Way

EllisAlquimia73 Industrial Way

EllisMalabarismo73 Industrial Way

HarrisonLimpieza ligera73 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, llamadaEmpleado. 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

EmpleadoLugar actual de trabajo

Jones114 Main Street

Bravo73 Industrial Way

Ellis73 Industrial Way

Harrison73 Industrial Way

Habilidades de los empleados

EmpleadoHabilidad

JonesMecanografa

JonesTaquigrafa

JonesTallado

BravoLimpieza ligera

EllisAlquimia

EllisMalabarismo

HarrisonLimpieza 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

TorneoAoGanadorFecha de nacimiento del ganador

Des Moines Masters1998Chip Masterson14 de marzo de 1977

Indiana Invitational1998Al Fredrickson21 de julio de 1975

Cleveland Open1999Bob Albertson28 de septiembre de 1968

Des Moines Masters1999Al Fredrickson21 de julio de 1975

Indiana Invitational1999Chip Masterson14 de marzo de 1977

Aunque elGanadory laFecha de nacimiento del ganadorestn determinadas por una clave completa {Torneo, Ao} y no son partes de ella, particularmente las combinacionesGanador/Fecha de nacimiento del ganadorson mostradas redundantemente en mltiples registros. Este problema es tratado por latercera 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

FabricanteModeloNombre completo del modeloPas del fabricante

ForteX-PrimeForte X-PrimeItalia

ForteUltracleanForte UltracleanItalia

Dent-o-FreshEZBrushDent-o-Fresh EZBrushUSA

KobayashiST-60Kobayashi ST-60Japn

HochToothmasterHoch ToothmasterAlemania

HochContenderHoch ContenderAlemania

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, yPas del fabricantees dependiente en un subconjunto apropiado de l:Fabricante.

Latercera forma normal(3NF) es unaforma normalusada en lanormalizacin de bases de datos. La 3NF fue definida originalmente porE.F. Codd1en 1971. La definicin de Codd indica que una tabla est en 3NFsi y solo silas tres condiciones siguientes se cumplen: La tabla est en lasegunda forma normal(2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente de unaclave primaria Es una relacin que no incluye ningn atributo claveUn atributo no-primario es un atributo que no pertenece a ninguna clave candidata. Unadependencia transitivaes unadependencia funcionalXZen la cualZno es inmediatamente dependiente deX, pero s de un tercer conjunto de atributosY, que a su vez depende deX. Es decir,XZpor virtud deXYeYZ.Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo2en 1982, es sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionalesXA, por lo menos una de las condiciones siguientes se mantiene: XcontieneA, Xes unasuperclave, Aes un atributo primario (es decir,Aest 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 rigurosaforma normal de Boyce-Codd(BCNF). La BCNF simplemente elimina la tercera alternativa ("Aes un atributo primario").ndice[ocultar] 1"Nada excepto la clave" 2Ejemplo 3Derivacin de las condiciones de Zaniolo 4Normalizacin ms all de la 3NF 5Referencias 6Lectura adicional 7Vase tambin 8Enlaces 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 porBill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada ms excepto la clave".3Una variacin comn complementa esta definicin con el juramento: "con la ayuda de Codd".4Requerir 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 Daterefiere 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 laforma normal de Boyce-Codd: "Cada atributo debe representar un hecho acerca de la clave, la clave entera, y nada excepto la clave".5La 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

TorneoAoGanadorFecha de nacimiento del ganador

Indiana Invitational1998Al Fredrickson21 de julio de 1975

Cleveland Open1999Bob Albertson28 de septiembre de 1968

Des Moines Masters1999Al Fredrickson25 de junio de 1985

Indiana Invitational1999Chip Masterson14 de marzo de 1977

La nica clave candidata es {Torneo, Ao}.La violacin de la 3NF ocurre porque el atributo no primarioFecha de nacimiento del ganadores dependiente transitivamente de {Torneo, Ao} va el atributo no primarioGanador. El hecho de que laFecha de nacimiento del ganadores funcionalmente dependiente en elGanadorhace 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

TorneoAoGanador

Indiana Invitational1998Al Fredrickson

Cleveland Open1999Bob Albertson

Des Moines Masters1999Al Fredrickson

Indiana Invitational1999Chip Masterson

Fecha de nacimiento del jugador

GanadorFecha de nacimiento

Chip Masterson14 de marzo de 1977

Al Fredrickson21 de julio de 1975

Bob Albertson28 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.6Normalizacin 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 laforma normal de Boyce-Codd(BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales ms altas4NFo5NF.

Lacuarta forma normal(4NF) es unaforma normalusada en lanormalizacin 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 laforma normal de Boyce-Codd(BCNF).ndice[ocultar] 1Caractersticas 2Dependencia multivaluada 3Ejemplo 44NF en la prctica 5Referencias 6Vase tambinCaractersticas[editar]Una tabla est en 4NF si y solo si esta enTercera forma normalo enBCNF(Cualquiera de ambas) y no posee dependencias multivaluadas no triviales. La definicin de la 4NF confa en la nocin de unadependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o ms relaciones independientesmuchos a muchoscausa 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

RestauranteVariedad de Pizzarea de envo

Vincenzo's PizzaCorteza gruesaSpringfield

Vincenzo's PizzaCorteza gruesaShelbyville

Vincenzo's PizzaCorteza finaSpringfield

Vincenzo's PizzaCorteza finaShelbyville

Elite PizzaCorteza finaCapital City

Elite PizzaCorteza rellenaCapital City

A1 PizzaCorteza gruesaSpringfield

A1 PizzaCorteza gruesaShelbyville

A1 PizzaCorteza gruesaCapital City

A1 PizzaCorteza rellenaSpringfield

A1 PizzaCorteza rellenaShelbyville

A1 PizzaCorteza rellenaCapital 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 queA1 Pizzaofrece laCorteza rellena, y siA1 Pizzacomienza a producir pizzas deCorteza de quesoentonces necesitaremos agregar mltiples registros, uno para cada una de lasreas de envodeA1 Pizza. En trminos formales, esto se describe como queVariedad de pizzaest teniendo una dependencia multivalor enRestaurante.Para satisfacer la 4NF, debemos poner los hechos sobre lasvariedades de pizzaofrecidas en una tabla diferente de los hechos sobrereas de envo:Variedades por restaurante

RestauranteVariedad de pizza

Vincenzo's PizzaCorteza gruesa

Vincenzo's PizzaCorteza fina

Elite PizzaCorteza fina

Elite PizzaCorteza rellena

A1 PizzaCorteza gruesa

A1 PizzaCorteza rellena

reas de envo por restaurante

Restauranterea de envo

Vincenzo's PizzaSpringfield

Vincenzo's PizzaShelbyville

Elite PizzaCapital City

A1 PizzaSpringfield

A1 PizzaShelbyville

A1 PizzaCapital City

En contraste, si lasvariedades de pizzaofrecidas por un restaurante a veces variaran de unrea de envoa otra, la tabla original de la tres columnas satisfara la 4NF.Ronald Fagindemostr que es siempre posible alcanzar la 4NF (pero no siempre deseable). Elteorema de Rissanenes tambin aplicable endependencias 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