TERCERA FORMA NORMAL La regla de la Tercera Forma Normal seala que hay que eliminar y separar cualquier dato

que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse nicamente por la clave. EJEMPLO 1: Normalizar una tabla de ejemplo Estos pasos demuestran el proceso de normalizacin de una tabla de alumnos ficticia. 1. Tabla sin normalizar: N alumno Tutor 1022 4123 Despacho-Tut Clase1 Clase2 Clase3 101-07 143-01 159-02 201-01 211-02 214-01

Garca 412 Daz 216

2. Primera forma normal: no hay grupos repetidos. Las tablas slo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseo.

Las hojas de clculo suelen usar la tercera dimensin, pero las tablas no deberan hacerlo. Otra forma de considerar ese problema es con una relacin de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (N clase), segn se muestra a continuacin: N alumno Tutor 1022 1022 1022 4123 4123 4123 Despacho-Tut N clase 101-07 143-01 159-02 201-01 211-02 214-01

Garca 412 Garca 412 Garca 412 Daz Daz Daz 216 216 216

3. Segunda forma normal: eliminar los datos redundantes.

Observe los diversos valores de N clase para cada valor de N alumno en la tabla anterior. N clase no depende funcionalmente de N alumno (la clave principal), de modo Las que dos la tablas relacin siguientes no cumple demuestran la la segunda segunda forma forma normal. normal:

Alumnos: N alumno Tutor 1022 4123 Registro: N alumno N clase 1022 1022 1022 4123 4123 4123 4. Tercera 101-07 143-01 159-02 201-01 211-02 214-01 forma normal: eliminar los datos no dependientes de la clave Despacho-Tut

Garca 412 Daz 216

En el ltimo ejemplo, Despacho-Tut (el nmero de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solucin es pasar ese atributo de la tabla Alumnos a la tabla Personal, segn se muestra a continuacin: Alumnos: N alumno Tutor 1022 4123 Garca Daz

Personal: Nombre Habitacin Dept Garca Daz 412 216 42 42

**************************************************************************************************** EJEMPLO 2:

**************************************************************************************************** EJEMPLO 3: El proceso de normalizacin de bases de datos relacionales La normalizacin de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de tcnicas para producir un nuevo esquema que representa la misma

informacin pero contiene menos redundancias y evita posibles anomalas en las inserciones, actualizaciones y borrados. Breve recordatorio del modelo (formal) relacional El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teora de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relacin, que se define por una serie de atributos Ai. Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restriccin que nos indica que cada entidad representada por una tupla tiene que ser diferente de las dems en su relacin, es decir, debe haber algunos atributos cuyos valores identifiquen unvocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relacin referenciada por la clave ajena. El proceso de normalizacin El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso. Un ejemplo completo Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado, de modo que las condiciones salariales estn determinadas por el puesto. Se ha creado el siguiente esquema relacional EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria. nss Nombre 111 Juan Prez puesto Jefe de rea salario Emails 3000 juanp@ecn.es; jefe2@ecn.es

222 Jos Snchez Administrativo 1500 jsanchez@ecn.es 333 Ana Daz ... ... TABLE 1 Administrativo 1500 adiaz@ecn.es; ana32@gmail.com ... ... ...

Primera forma normal (1FN) Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos ver que el atributo emails puede contener ms de un valor, por lo que viola 1FN. En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la condicin de 1FN, tenemos dos opciones. Solucin 1: duplicar los registros con valores repetidos En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la cual: El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que tenamos en R[M], entoncesR'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relacin habr n tuplas, que slo varan en que cada una de ellas guarda uno de los valores que haba en M. La clave primaria de R' es (K, M'), dado que podr haber valores de K repetidos, para los valores multivaluados en M. Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria (nss, email): nss Nombre 111 Juan Prez 111 Juan Prez puesto Jefe de rea Jefe de rea salario email 3000 juanp@ecn.es 3000 jefe2@ecn.es

222 Jos Snchez Administrativo 1500 jsanchez@ecn.es 333 Ana Daz 333 Ana Daz ... ... TABLE 2 Administrativo 1500 adiaz@ecn.es Administrativo 1500 ana32@gmail.com ... ... ...

Solucin 2: separar el atributo que viola 1FN en una tabla En general, esta solucin pasa por: sustituir R por una nueva relacin modificada R' que no contiene el atributo M. Crear una nueva relacin N(K, M'), es decir, una relacin con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M. La nueva relacin N tiene como clave (K, M'). Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b) Nss Nombre 111 Juan Prez Puesto Jefe de rea salario 3000

222 Jos Snchez Administrativo 1500 333 Ana Daz ... ... TABLE 3 Administrativo 1500 ... ...

Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email): nss Email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ... TABLE 4

Segunda forma normal (2FN) Un esquema est en 2FN si: Est en 1FN. Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) est en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema est en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes: nss->nombre, salario, email puesto->salario Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relacin no est en 2FN. En general, tendremos que observar los atributos no clave que dependan de parte de la clave. Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M: Eliminar de R el atributo M. Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'. La clave primaria de la nueva relacin ser K'.

Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen dependencia incompleta: Nss Nombre 111 Juan Prez Puesto Jefe de rea salario 3000

222 Jos Snchez Administrativo 1500 333 Ana Daz ... ... TABLE 5 Administrativo 1500 ... ...

Y al eliminar de la tabla original estos atributos nos quedara: nss Email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ... TABLE 6

Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin para el problema de 1FN. Tercera forma normal (3FN) Una relacin est en tercera forma normal si, y slo si: est en 2FN y, adems, cada atributo que no est incluido en la clave primaria no depende transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estn en la clave. En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solucin a este tipo de dependencias est en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A. Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad: nss->puesto puesto->salario Por lo tanto la descomposicin sera la siguiente: Nss nombre 111 Juan Prez Puesto Jefe de rea

222 Jos Snchez Administrativo 333 Ana Daz ... ... TABLE 7 Administrativo ...

En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.

**************************************************************************************************** FORMA NORMAL BOYCE CODD La Forma Normal Boyce-Codd (Denominada por sus siglas en ingles como BCNF or FNBC) es una forma normal utilizada en la normalizacin de bases de datos. Es una adaptacin vagamente ms segura de lo establecido en la Tercera Forma Normal (3FN). Es una etapa en que se deben agrupar los datos por afinidad, formando tablas las cuales se relacionan entre si mediante campos comunes; una tabla se considera en esta forma si y slo s cada determinante o atributo es una llave candidata.

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 base de datos un atributo determinante es un atributo del que depende funcionalmente de manera completa algn otro atributo. Todo determinante es una clave candidata. Como una tabla est en Forma Normal de Boyce-Codd si solo existen dependencias funcionales elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria est formada por un solo atributo y est en 3FN, sta a su vez est en FNBC. Cmo 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). 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 3FN y los nicos determinantes son claves candidata La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la clave primaria. Pero este tipo de dependencias todava pueden existir sobre otras claves candidatas, si stas existen. La BCFN es ms fuerte que la 3FN, por lo tanto, toda relacin en BCFN est en 3FN. La violacin de la BCFN es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relacin viola la BCFN si tiene dos o ms claves candidatas compuestas que tienen al menos un atributo en comn. Un ejemplo tpico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, puede ser una tabla que posee los atributos Direccin, Cdigo Postal y Ciudad, deduciendo que a Ciudades diferentes le corresponden cdigos postales distintos. Tabla en tercera forma normal CPost Dir 3000 C/ Las Flores N17 Ciud Merida

4858 Av. Bolvar este N72 Maracay

En este caso hay dependencia entre el Cdigo Postal y la Ciudad, ya que, conocido el Cdigo Postal se puede conocer la Ciudad, y conocida la Direccin y la Ciudad, se conoce el Cdigo Postal.

Para transformar la tabla en una tabla en FNBC se crea una tabla de Cdigos Postales y Ciudades, eliminando de la tabla original la Ciudad, obtenindose dos tablas, una con los atributos Direccin y Cdigo Postal y otra con el Cdigo Postal y la Ciudad Tabla en forma normal de Boyce-Codd CPost 3000 4858 Dir C/ Las Flores N17 Av. Bolvar este N72

Tabla en forma normal de Boyce-Codd CPost 3000 4858 Ciud Merida Maracay

En la mayora de los casos, las relaciones en 3FN estarn en FNBC. Para Validar esto se deben ubicar todos los determinantes existentes en la relacin as como todas las claves candidatas, se comparan ambos conjuntos y si encuentra que hay algn determinante que no resulta ser clave candidata se demuestra que no esta en FNBC. Se comprueba que la relacin est en 1FN, todos los atributos son atmicos. Tambin est en 2FN ya que no hay dependencias funcionalmente completas entre atributos que no sean clave (formen parte de la clave). Y finalmente se verifica que no hay ningn atributo que dependa de forma transitiva de la clave Primaria, luego est en 3FN. Usualmente se considera aceptable tener relaciones que lleguen slo hasta la FNBC. La definicin de la 3FN no produce diseos satisfactorios cuando se dan las siguientes condiciones, o lo que es lo mismo, cuando una relacin NO ESTE EN FNBC concurrirn las siguientes circunstancias: Existen varias claves candidatas. Las claves candidatas son compuestas.

Las claves candidatas se encubren, tienen al menos un atributo en comn.

No hay un teorema sobre la divisin de la relacin, el motivo es que no se puede asegurar que al descomponer una relacin en dos para conseguir la FNBC el significado de las relaciones obtenidas se corresponda semnticamente a lo que representa la relacin inicial. En otras palabras, se puede tomar una decisin equivocada al descomponer ya que puede que perdamos parte de la semntica de la relacin anterior. **************************************************************************************************** CUARTA FORMA NORMAL EJEMPLO 1: Una tabla est en cuarta forma normal si y slo si para cualquier combinacin clave campo no existen valores duplicados. Vemoslo con un ejemplo: Geometra Figura Cuadrado Cuadrado Cuadrado Crculo Crculo Crculo Color Rojo Azul Azul Blanco Azul Azul Tamao Grande Grande Mediano Mediano Pequeo Mediano

Comparemos ahora la clave (Figura) con el atributo Tamao, podemos observar que Cuadrado Grande est repetido; igual pasa con Crculo Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF. La solucin en este caso sera la siguiente: Tamao Figura Cuadrado Cuadrado Crculo Crculo Tamao Grande Pequeo Mediano Pequeo Figura Cuadrado Cuadrado Crculo Crculo Color Color Rojo Azul Blanco Azul

Ahora si tenemos nuestra base de datos en 4NF.

EJERCICIO 2: CUARTA FORMA NORMAL (4FN) Se dice que una tabla que est en forma normal de Boyce-Codd y de la cual se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos; es una tabla en 4 forma Normal Al hablar de dependencia funcional multivaluadas o de mltiples valores, se refiere a la existencia a la relacin que pudiera darse por ejemplo dados tres atributos de una tabla, si para cada valor del primer atributo existen mltiples valores en el segundo atributo y no hay ninguna relacin entre el tercer atributo y el primero, a no ser a travs del segundo atributo. Una tabla est en Cuarta Forma Normal o 4FN si est en FNBC y las nicas dependencias funcionales multivaluadas que existen son las dependencias funcionales de la clave con los atributos que no forman parte de la misma. Estas dependencias multivaluadas de la clave con los atributos que no forman parte de la misma son dependencias triviales, por lo que algunos autores dicen que no existen dependencias multivaluadas en 4FN. En base de datos se entiende por dependencia Multivaluada el caso en que en una tupla (X,Y,Z). se dice que Y es multidependiente de X (X ---> Y) si y slo si el conjunto de valores de Y correspondiente a un par (X,Z) depende slo del valor de X y es independiente del valor de Z. Las dependencias multivaluadas slo se presentan si existen tres atributos y cuando lo hacen es a pares, es decir ocurre que Y es multidependiente de X y Z es tambin multidependiente de X. Consideremos que los atributos de una tabla Transporte son Conductor, Tipo de Vehculo y Tipo de Carga, formando los tres campos la clave primaria. A cada Conductor se le puede asignar un Vehculo u otro y cada Vehculo puede transportar varios Tipos de Carga. Tabla que no esta en cuarta forma normal Transporte Conductor Tipo Vehculo Tipo Carga Juan Camioneta Perecederos

Marcos Juan Marcos Juan Marcos

Camioneta Camioneta Camioneta Camin Camin

Perecederos Muebles Muebles Mudanza Mudanza

Bajo estas condiciones, los Conductores son independientes de la carga; el Tipo de Vehculos depende del Conductor y el Tipo de Vehculo depende de la Carga. En este caso hay dependencias funcionales multivaluadas, ya que algunos atributos que forman la clave dependen de otro atributo que tambin la forman. Para conseguir que esta tabla est en 4FN se necesita crear dos nuevas tablas en lugar de la tabla actual, manteniendo en cada una de ellas una dependencia mltiple. La primera tabla tendr los atributos conductor y tipo de vehculo y la segunda, tipo de vehculo y tipo de carga. De este modo la tabla en 4FN debido a que la clave primaria de ambas tablas son todos los campos que la forman. Resultado: Tabla en cuarta forma normal Tipo Vehculo Camioneta Camioneta Camioneta Camioneta Camin Camin Tipo Carga Perecederos Perecederos Muebles Muebles Mudanza Mudanza

Tabla en cuarta forma normal Conductor Juan Marcos Juan Marcos Juan Marcos Tipo Vehculo Camioneta Camioneta Camioneta Camioneta Camin Camin

En las relaciones varios-con-varios, entidades independientes no pueden ser almacenadas en la misma tabla. La 4FN es en cierto modo bastante compleja de identificar, hay que tener muy claro sobre todo el significado de lo que representa la relacin analizada. Para verlo de forma prctica procederemos a definir una nueva relacin para comprobar despus si est en 4FN. Algo que vital y que se aplica para cualquier estado de la normalizacin es que se debe tener siempre en cuenta el significado semntico de las relaciones de lo contrario se puede caer en el error de descomponer o disear una base de datos que, aunque est perfectamente Una relacin est en cuarta forma normal (4FN) si est en FNBC y todas las dependencias multivaluadas en ella son de hecho dependencias funcionales.

**************************************************************************************************** QUINTA FORMA NORMAL Se dice que hay dependencia de JOIN, de unin o de producto si una tabla tiene dependencia de *unin con varias de sus *proyecciones y se puede obtener la tabla por medio de la unin de dichas proyecciones. *Proyeccin:

Creacin de una tabla cuyos elementos forman un subconjunto de una tabla dada. Se incluyen todas las filas y algunas columnas. *Unin: Formar, a partir de dos tablas, una nueva con todos los campos de una de ellas y los registros de ambas, excepto los repetidos. Ambas tablas han de tener el mismo grado y las mismas columnas. Una tabla esta en Quinta Forma Normal (5FN) o Forma Normal de Proyeccin-Unin si est en 4FN y las nicas dependencias que existen son las dependencias de unin de una tabla con sus proyecciones relacionndose entre las distintas proyecciones mediante la clave primaria o cualquier clave alternativa. La 5FN se emplea cuando en una misma tabla tenemos mucha informacin redundante, con pocos atributos o cuando una tabla posee una gran cantidad de atributos y se hace por ello inmanejable. Para conseguir que una tabla 4FN con gran cantidad de atributos est en 5FN, se parte la tabla original en tantas tablas como se desee, teniendo cada una de ellas en comn con las dems los campos que forman la clave primaria en la tabla original.

EJEMPLO 1:

EJEMPLO 1: Para el caso de una tabla que posee una gran cantidad de atributos: Id 1 Datos Familiares D1 D2 D3 Datos Profesionales D4 D5 D6 Datos Personales D7 D8 D9 Datos Clnicos D10 D11 D12

En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y clnicos de cada empleado en una nica tabla llamada Empleados. Si esta tabla est ya en 4FN, se puede partir en las tablas empleados-personal, empleadosfamilia, empleados-profesional, empleados-clnicos; de este modo, la velocidad de acceso y la gestin de datos por cada departamento de la empresa se simplifica, al no tenerse que crear ningn tipo de restriccin sobre determinados atributos que no han de ser vistos por el personal que no los necesite. El resultado sera: Id 1 Id 1 Id 1 Id 1 D10 D7 D4 D1 Datos Familiares D2 Datos Profesionales D5 Datos Personales D8 Datos Clnicos D11 D12 D9 D6 D3

************************************************************************************************ EJEMPLO 2:

Ejemplo 2: para el caso de una tabla que posee mucha informacin redundante, con pocos atributos Biblioteca Ttulo T1 T2 T3 T4 T1 T2 T3 FT FU FV FG FH FT FV Fecha S1 S2 S1 S4 S3 S4 S3 Socio

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

Ttulo-Socio Ttulo T1 T2 T3 T4 T1 T2 T3 S1 S2 S1 S4 S3 S4 S3 Fecha-Socio Fecha FT FU FV FG FH FT FV S1 S2 S1 S4 S3 S4 S3 Socio Socio

**************************************************************************************************** EJEMPLO 3: La Quinta Forma Normal (5FN) trata con casos donde la informacin puede ser reconstruida de muchas piezas de informacin las cuales pueden ser mantenidas con poca redundancia. Entidades: AGENTES, COMPANIAS y PRODUCTOS.

Si los AGENTES representan COMPAIAS, las COMPAAS fabrican PRODUCTOS, y los AGENTES venden PRODUCTOS, entonces nosotros querramos tener guardado un registro de cules agentes venden cules productos para cul compaa. Esta informacin puede ser guardada en un registro con tres campos:

Esta forma es necesaria en el caso general. Ahora bien, aunque el agente PARRA vende autos hechos por FORD y camiones hechos por GENERAL MOTORS; l no vende camiones FORD ni autos GM. Esto es, necesitamos la combinacin de los tres campos para saber cules combinaciones son vlidas y cules no.

En este caso, resulta que podemos reconstruir todos los datos reales de una forma normalizada consistente de tres tipos de registros separados, cada uno conteniendo dos campos

Estos tres registros estn en la Quinta Forma Normal. Si un registro puede ser descompuesto solamente en registros pequeos, teniendo todos la misma clave, entonces el registro es considerado como en la Quinta Forma Normal, sin descomposicin. Un registro en la Quinta Forma Normal est tambin en la Cuarta, Tercera, Segunda y Primera Formas normales. Una ventaja de la Quinta Forma Normal es que ciertas redundancias pueden ser eliminadas. En la forma normalizada, el hecho de que PARRA venda AUTOS es registrado solamente una vez; en la forma no normalizada esto puede ser repetido muchas veces. Debemos advertir entonces que aun cuando las formas normalizadas involucran un nmero mayor de registros tipo comparado con el original, las ocurrencias de algunos hechos se reducen considerablemente. Lo importante es comprender que cuanto ms hechos son registrados, el tamao del archivo normalizado crece en forma aditiva, mientras que el tamao del archivo no normalizado crece en forma multiplicativa. Por ejemplo, si agregamos un nuevo AGENTE que vende 'X' PRODUCTOS para 'Y' COMPANIAS, donde cada una de estas compaas fabrica cada uno de estos productos, tendremos X + Y nuevos registros para la forma normalizado, pero tendremos X . Y nuevos registros para la forma no normalizada La 5FN es la ms compleja y polmica de todas. Polmica pues no est claro en muchas ocasiones que sea una solucin mejor sacar las proyecciones de la tabla. Es raro encontrarse este tipo de problemas cuando la normalizacin llega a 4FN y se debe a restricciones muy concretas.