Qué es la normalización

Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a

desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la
que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos
en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía
a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de
datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se
muestra a continuación:

Clientes

ID_ Cliente
Nombre
Apellidos

Nombre_Producto1
Costo_Producto1
Imagen_Producto1

Nombre_Producto2
Costo_Producto2
Imagen_Producto2

Fecha_Pedido
Cantidad_Pedido
Nombre_Cia_Envios

La tabla se ha descrito de manera abreviada pero aun así representa la idea general.

¿Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un
pedido también. ¿Qué tal si quisiera emitir un informe de todos los productos que vende? No
podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo
bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto
fácilmente.

La nomlalización también hace las cosas fáciles de entender. Los seres humanos tenemos la
tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales
hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos
compleja agrupando cosas similares juntas. Las guías que la nomlalización provee crean el
marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil
detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las
guías de la nomlalización, podría crear las tablas basándose en estos grupos.

El proceso de nomlalización tiene un nombre y una serie de reglas para cada fase. Esto
puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así
como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las
hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve
reconfigurar su esquema para ajustarlo al proceso de nomlalización, siempre será bien
Iinvertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para
cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe.

Otra ventaja de la nomlalización de su base de datos es el consumo de espacio. Una base

de datos nomlalizada puede ocupar menos espacio en disco que una no nomlalizada. Hay
menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio
en disco.

Grados de normalización

Existen básicamente tres niveles de normalización: Primera Fomla Normal (1NF), Segunda
Fomla Normal (2NF) y Tercera Fomla Normal (3NF). Cada una de estas formas tiene sus
propias reglas. Cuando una base de datos se conforma a un nivel, se considera nomlalizada
a esa forma de nomlalización. Por ejemplo, supongamos que su

base de datos cumple con todas las reglas del segundo nivel de nomlalización. Se considera
que está en la Segunda Fomla Normal. No siempre es una buena idea tener una base de
datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de
complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

Primera Forma Normal

La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas. Ésta es una regla muy fácil de seguir. Observe
el esquema de la tabla Clientes de la base de datos.

Clientes

ID Cliente

Nombre

Apellidos

Nombre_Producto1

Costo_Producto1

Imagen_Producto1

Nombre_Producto2

Costo_Producto2

Imagen_Producto2

Fecha_Pedido

Cantidad_Pedido
Nombre Cia Envios

--

La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos.
De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla.

Eliminación de datos repetidos en una base de datos

Clientes Pedidos

ID_Clientes Nombre_Productos

Nombre Costo_Producto

Apellidos Imagen_Producto

Direccion

Numero_Pedido

Fecha_Pedido

Cantidad_Pedido

Clave_Cia_Envios

Nombre_Ci_ Envios

--

Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos
de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la
segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave
primaria que se llame ID_Producto y añada una clave a la tabla Clientes que la relacione con
la tabla Productos. El campo ID_Producto es el candidato ideal.

Primera Forma Normal

Clientes Pedidos

ID_Productos ID_Productos

ID_Clientes Nombre_Productos

Nombre Costo_Producto

Apellidos Imagen_Producto
Direccion

Numero_Pedido

Fecha_Pedido

Cantidad_Pedido

Clave_Cia_Envios

--

Así, se ha establecido una relación uno a varios. Ésta representa lo que la base de datos
estará haciendo en la vida real. El cliente tendrá muchos productos que podrá comprar,

sin importar cuántos otros clientes quieran comprarlos también. Además, el cliente
necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir

un cliente cada vez que añade un nuevo producto a su inventario.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los

encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos
inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas
que representen los mismos datos. En una empresa de servicios de electricidad, había una
base de datos para el control de refacciones de una planta nuclear. La tabla de su base de
datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida
más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una
nueva columna para almacenar la información. Obviamente, el diseño de la base de datos
era bastante pobre y, por lo mismo, resultaba una pesadilla para sus
programadores/administradores.

La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas

y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica
que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y
más tangibles, así como las relaciones que guardan con otros objetos también pequeños. No
es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos
conducirá aun mejor aprovechamiento de sus activos.

Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se
deben eliminar y separar dentro de sus propias tablas. Una depen dencia parcial es un
término que describe a aquellos datos que no dependen de la clave de la tabla para
identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno
de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto
de la información podría residir en su propia tabla. Una vez que haya organizado la
información de pedidos.

Eliminación de las dependencias parciales -Segunda Forma Normal

Clientes Pedidos Productos

ID_Productos ID_Productos ID_Producto

ID_Clientes Nombre_Productos Fecha_Compra

Nombre Cantidad_Pedido Costos_Productos

Apellidos Imagen_Producto

Direccion

Numero_Pedido

Nombre_Cia_Envios

De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de
datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera
aplicable, pero para ilustrar la normalización, así está bien.

Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La

mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus
datos están normalizados cuando todo funciona más o menos bien, parece ser un
desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una
base de datos no normalizada que el que emplearía en una normalizada.

Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las
ventajas de las bases de datos relacionales. Por ejemplo, puede añadir nuevas columnas a
la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras
tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una
manera natural dentro de los límites esperados.

Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la
mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la
mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la
columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de
normalización explicará cómo solucionar esto.

Tercera Forma Normal

La regla de la Tercera Forma Normal señala 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. En la base de datos de muestra, la tabla
Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la
clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte.

Eliminación de los datos que no son claves para la Tercera Forma Normal

Clientes Productos PedidoMaestro PedidoDetallado Cias_Envios

ID_cliente ID_Producto ID_Pedido ID_PedidoDetallado ID_Cia_Envios

ID_Producto Nombre_Producto Fecha_Pedido ID_Pedido Nombre_Cia_Envios.

Numero_Pedido Costos_Productos Cantidad_Pedidos Fecha_Pedido

ID_Cia_Envios Foto_Producto Cantidad_Pedido

Nombre

Apellidos

Direccion

Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y
previene errores de lógica cuando inserta o borra registros. Cada columna en la tabla está
identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema
limpio y elegante, que es fácil de trabajar y expandir.

Qué tan lejos debe llevar la normalización

La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es

una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su
base de datos va a proveer información aun solo usuario para un propósito simple y existen
pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo
extremoso. Las reglas de normalización existen como guías para crear tablas que sean
fáciles de manejar, así como flexibles y eficientes.

A veces puede ocurrir que normalizar sus datos hasta el nivel más alto no tenga sentido. Por
ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es
muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se
muestra a continuación:

ID_Cliente

Nombre

Apellidos

Direccion1

Direccion2

De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección
debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado
de este esquema se muestra a continuación:

ID_Ciente ID_Direccion

Nombre ID_Cliente

Apellidos Direccion

La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener
más de una dirección. El problema aquí es que usted ha complicado demasiado una idea
simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda
dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera
utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar
las reglas de la normalización. En esta instancia, el exceso de normalización frustra el
propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de
complejidad. Una buena forma de determinar si está llevando demasiado lejos su
normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera
indicar que está normalizando demasiado. Observe su esquema.

¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad
prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita
decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta.
La normalización no es una ciencia exacta. Es subjetiva.

Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma
Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o

Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma

Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas
formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen
para hacer una base de datos realmente relacional. Tienen que ver principalmente con
dependencias múltiples y claves relacionales.

En resumen

La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas entre
tablas de una base de datos.

Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita

también agregar nuevas columnas sin romper el esquema actual ni las relaciones.

Existen varios niveles de normalización: Primera Forma Normal, Segunda Forma Normal,
Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma
Normal o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte,
Forma Normal de Proyección-Unión Extra Fuerte y Forma

Normal de Clave de Dominio. Cada nuevo nivel o forma lo acerca más a hacer su base de
datos verdaderamente relacional.

Se discutieron las primeras tres formas. Éstas proveen suficiente nivel de normalización para
cumplir con las necesidades de la mayoría de las bases de datos.

Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su
esquema demasiado complejo para trabajar. Un balance apropiado de sentido común y

práctico puede ayudarle a decidir cuándo normalizar.

Xxxxxxxxxxxxxxxxxxxxxxxxxx

http://foros.softonic.com/a/ayuda-base-datos-normalizacion-83942

vvvvvvvvvvvvvvv

Digamos que queremos crear una tabla con la información de usuarios, y los datos a guardar
son el nombre, la empresa, la dirección de la empresa y algun e-mail, o bien URL si las
tienen. En principio comenzarias definiendo la estructura de una tabla como esta:
 Formalización CERO

usuarios

nombre empresa direccion_empresa url1 url2

Joe ABC 1 Work Lane abc.com xyz.com

Jill XYZ 1 Job Street abc.com xyz.com

Diríamos que la anterior tabla esta en nivel de Formalizacion Cero porque ninguna de
nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y url2 -- ¿Qué
haremos cuando en nuestra aplicación necesitemos una tercera url ? ¿ Quieres tener que
añadir otro campo/columna a tu tabla y tener que reprogramar toda la entrada de datos de tu
código PHP ? Obviamente no, tu quieres crear un sistema funcional que pueda crecer y
adaptarse fácilmente a los nuevos requisitos. Hechemos un vistazo a las reglas del Primer
Nivel de Formalización-Normalización, y las aplicaremos a nuestra tabla.

Primer nivel de Formalización/Normalización. (F/N)

1. Eliminar los grupos repetitivos de la tablas individuales.

2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.

¿ Ves que estamos rompiendo la primera regla cuando repetimos los campos url1 y
url2 ? ¿ Y que pasa con la tercera regla, la clave primaria ? La regla tres
básicamente significa que tenemos que poner una campo tipo contador
autoincrementable para cada registro. De otra forma, ¿ Qué pasaria si tuvieramos
dos usuarios llamados Joe y queremos diferenciarlos. Una vez que aplicaramos el
primer nivel de F/N nos encontrariamos con la siguiente tabla:

usuarios

userId nombre empresa direccion_empresa url

1 Joe ABC 1 Work Lane abc.com

1 Joe ABC 1 Work Lane xyz.com

2 Jill XYZ 1 Job Street abc.com

2 Jill XYZ 1 Job Street xyz.com

Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos solucionado
el problema de la limitación del campo url. Pero sin embargo vemos otros
problemas....Cada vez que introducimos un nuevo registro en la tabla usuarios,
tenemos que duplicar el nombre de la empresa y del usuario. No sólo nuestra BD
crecerá muchísimo, sino que será muy facil que la BD se corrompa si escribimos
mal alguno de los datos redundantes. Aplicaremos pues el segundo nivel de F/N:
 Segundo nivel de F/N

4. Crear tablas separadas para aquellos grupos de datos que se aplican a varios
registros.
5. Relacionar estas tablas mediante una clave externa.

Hemos separado el campo url en otra tabla, de forma que podemos añadir más en el
futuro sin tener que duplicar los demás datos. También vamos a usar nuestra clave
primaria para relacionar estos campos:

usuarios

userId nombre empresa direccion_empresa

1 Joe ABC 1 Work Lane

2 Jill XYZ 1 Job Street

urls

urlId relUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Vale, hemos creado tablas separadas y la clave primaria en la tabla usuarios,

userId, esta relacionada ahora con la clave externa en la tabla urls, relUserId. Esto
esta mejor. ¿ Pero que ocurre cuando queremos añadir otro empleado a la
empresa ABC ? ¿ o 200 empleados ? Ahora tenemos el nombre de la empresa y su
dirección duplicandose, otra situación que puede inducirnos a introducir errores en
nuestros datos. Así que tendrémos que aplicar el tercer nivel de F/N:

Tercer nivel de F/N.

6. Eliminar aquellos campos que no dependan de la clave.

Nuestro nombre de empresa y su dirección no tienen nada que ver con el campo
userId, asi que tienen que tener su propio empresaId:

usuarios

userId nombre relEmpresaId

1 Joe 1

2 Jill 2

empresas

emprId empresa direccion_empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

urls

urlId RelUserId url

1 1 abc.com

2 1 xyz.com

3 2 abc.com

4 2 xyz.com
Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con la
clave externa recEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios
mientras que sólo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de
usuarios y urls pueden crecer todo lo que quieran sin duplicación ni corrupción de
datos. La mayoria de los desarrolladores dicen que el tercer nivel de F/N es
suficiente, que nuestro esquema de datos puede manejar facilmente los datos
obtenidos de una cualquier empresa en su totalidad, y en la mayoria de los casos
esto será cierto.

Pero hechemos un vistazo a nuestro campo urls - ¿ Ves duplicación de datos ? Esto
es perfectamente aceptable si la entrada de datos de este campo es solicitada al
usuario en nuestra apliación para que teclee libremente su url, y por lo tanto es sólo
una coincidencia que Joe y Jill teclearon la misma url. ¿ Pero que pasa si en lugar
de entrada libre de texto usáramos un menú desplegable con 20 o incluso más urls
predefinidas ? Entonces tendríamos que llevar nuestro diseño de BD al siguiente
nivel de F/N, el cuarto, muchos desarrolladores lo pasan por alto porque depende
mucho de un tipo muy específico de relación, la relación 'varios-con-varios', la cual
aún no hemos encontrado en nuestra aplicación.

Relaciones entre los Datos

Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los
datos: uno-a-uno, uno-con-varios y varios-con-varios. Mira la tabla usuarios en el
Primer Nivel de F/N del ejemplo de arriba. Por un momento imaginámos que
ponemos el campo url en una tabla separada, y cada vez que introducimos un
registro en la tabla usuarios tambien introducimos una sola fila en la tabla urls.
Entonces tendríamos una relacion uno-a-uno: cada fila en la tabla usuarios tendría
exactamente una fila correspondiente en la tabla urls. Para los propósitos de
nuestra aplicación no sería útil la normalización.
Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas
permiten a un sólo usuario tener asociadas varias urls. Esta es una relación uno-
con-varios, el tipo de relación más común, y hasta que se nos presentó el dilema del
Tercer Nivel de F/N. la única clase de relación que necesitamos.
La relación varios-con-varios, sin embargo, es ligeramente más compleja. Observa
en nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado
con varias urls. Como dijímos, vamos a cambiar la estructura para permitir que
varios usuarios esten relacionados con varias urls y así tendremos una relación
varios-con-varios. Veamos como quedarían nuestras tablas antes de seguir con este
planteamiento:

usuarios

userId nombre relEmpresaId

1 Joe 1

2 Jill 2
 empresas

emprId empresa direccion_empresa

1 ABC 1 Work Lane

2 XYZ 1 Job Street

urls

urlId url

1 abc.com

2 xyz.com

url_relations

relationId relatedUrlId relatedUserId

1 1 1

2 1 2

3 2 1

4 2 2
Para disminuir la duplicación de los datos ( este proceso nos llevará al Cuarto Nivel
de F/N), hemos creado una tabla que sólo tiene claves externas y primarias
url_relations. Hemos sido capaces de remover la entradas duplicadas en la tabla urls
creando la tabla url_relations. Ahora podemos expresar fielmente la relación que
ambos Joe and Jill tienen entre cada uno de ellos, y entre ambos, las urls. Así que
veamos exáctamente que es lo que el Cuarto Nivel de F/N. supone:
Cuarto Nivel de F/N.

7. En las relaciones varios-con-varios, entidades independientes no pueden ser

almacenadas en la misma tabla.

Ya que sólo se aplica a las relaciones varios-con-varios, la mayoria de los desarrolladores

pueden ignorar esta regla de forma correcta. Pero es muy útil en ciertas situaciones, tal
como esta. Hemos optimizado nuestra tabla urls eliminado duplicados y hemos puesto las
relaciones en su propia tabla.
Os voy a poner un ejemplo prático, ahora podemos seleccionar todas las urls de Joe
realizando la siguiente instrucción SQL:
SELECT nombre, url FROM usuarios, urls, url_relations WHERE
url_relations.relatedUserId = 1 AND usuarios.userId = 1 AND urls.urlId =
url_relations.relatedUrlId
Y si queremos recorrer todas las urls de cada uno de los usuarios, hariamos algo así:
SELECT nombre, url FROM usuarios, urls, url_relations WHERE usuarios.userId =
url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId
Quinto Nivel de F/N.
Existe otro nivel de normalización que se aplica a veces, pero es de hecho algo esotérico y
en la mayoria de los casos no es necesario para obtener la mejor funcionalidad de nuestra
estructura de datos o aplicación. Su principio sugiere:

1. La tabla original debe ser reconstruida desde las tablas resultantes en las cuales a
sido troceada.

Los beneficios de aplicar esta regla aseguran que no has creado ninguna columna extraña
en tus tablas y que la estructura de las tablas que has creado sea del tamaño justo que tiene
que ser. Es una buena práctica aplicar este regla, pero a no ser que estes tratando con una
extensa estructura de datos probablemente no la necesitarás.
Espero que hayas encontrado este artículo útil, y que seas capaz de aplicar estas reglas de
normalización a todos tus proyectos de bases de datos. Y en el caso que te estes
preguntando de donde viene todo esto, las tres primeras reglas de normalización fueron
perfiladas por el Dr. E.F.Codd en su escrito de 1972, "Further Normalization of the Data Base
Relational Model" ( Referente a la normalización de las Bases de Datos Relacionales). La
otras regla han sido teorizadas por posteriores matemáticos/Algebristas.
--Barry

vvvvvvvvvvvvvvvv

A través del siguiente ejercicio se intenta afirmar los conocimientos de

normalización con un ejemplo simplificado de una base de datos para una
pequeña biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev

Pérez Gómez,
1001 Variable compleja Murray Spiegel McGraw Hill 15/04/2005
Juan

1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán, Ana 17/04/2005

1005 Estadística Murray Spiegel McGraw Hill Roca, René 16/04/2005

Nancy
García Roque,
1006 Oracle University Greenberg y Oracle Corp. 20/04/2005
Luis
Priya Nathan

Pérez Gómez,
1007 Clipper 5.01 Ramalho McGraw Hill 18/04/2005
Juan

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de sólo

tener campos atómicos, pues el nombre del lector es un campo que puede (y
conviene) descomponerse en apellido paterno, apellido materno y nombres.
Tal como se muestra en la siguiente tabla.

1NF
CodLibro Titulo Autor Editorial Paterno Materno Nombres FechaDev

Variable McGraw
1001 Murray Spiegel Pérez Gómez Juan 15/04/2005
compleja Hill

1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán Ana 17/04/2005

McGraw
1005 Estadística Murray Spiegel Roca René 16/04/2005
Hill

Oracle Nancy Oracle

1006 García Roque Luis 20/04/2005
University Greenberg Corp.

Oracle Oracle
1006 Priya Nathan García Roque Luis 20/04/2005
University Corp.

McGraw
1007 Clipper 5.01 Ramalho Pérez Gómez Juan 18/04/2005
Hill

Como se puede ver, hay cierta redundancia característica de 1NF.

La Segunda Forma Normal (2NF) pide que no existan dependencias

parciales o dicho de otra manera, todos los atributos no clave deben
depender por completo de la clave primaria. Actualmente en nuestra tabla
tenemos varias dependencias parciales si consideramos como atributo clave
el código del libro.

Por ejemplo, el título es completamente identificado por el código del libro,

pero el nombre del lector en realidad no tiene dependencia de este código,
por tanto estos datos deben ser trasladados a otra tabla.

2NF
CodLibro Titulo Autor Editorial

McGraw
1001 Variable compleja Murray Spiegel
Hill

1004 Visual Basic 5 E. Petroustsos Anaya

McGraw
1005 Estadística Murray Spiegel
Hill

Nancy Oracle
1006 Oracle University
Greenberg Corp.

Oracle
1006 Oracle University Priya Nathan
Corp.

McGraw
1007 Clipper 5.01 Ramalho
Hill

La nueva tabla sólo contendrá datos del lector.

CodLector Paterno Materno Nombres

501 Pérez Gómez Juan

502 Ríos Terán Ana

503 Roca René

504 García Roque Luis

Hemos creado una tabla para contener los datos del lector y también tuvimos
que crear la columna CodLector para identificar unívocamente a cada uno.
Sin embargo, esta nueva disposición de la base de datos necesita que exista
otra tabla para mantener la información de qué libros están prestados a qué
lectores. Esta tabla se muestra a continuación:

CodLibro CodLector FechaDev

1001 501 15/04/2005

1004 502 17/04/2005

1005 503 16/04/2005

1006 504 20/04/2005

1007 501 18/04/2005

Para la Tercera Forma Normal (3NF) la relación debe estar en 2NF y además
los atributos no clave deben ser mutuamente independientes y dependientes
por completo de la clave primaria. También recordemos que dijimos que esto
significa que las columnas en la tabla deben contener solamente información
sobre la entidad definida por la clave primaria y, por tanto, las columnas en la
tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva información acerca del

libro, los autores y editoriales, por lo que debemos crear nuevas tablas para
satisfacer los requisitos de 3NF.

3NF
CodLibro Titulo

1001 Variable compleja

1004 Visual Basic 5

1005 Estadística

1006 Oracle University

1007 Clipper 5.01

CodAutor Autor

801 Murray Spiegel

802 E. Petroustsos

Nancy
803 Greenberg

804 Priya Nathan

806 Ramalho

CodEditorial Editorial

901 McGraw Hill

902 Anaya

903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga sólo
información acerca de una entidad, también hemos perdido la información
acerca de qué autor ha escrito qué libro y las editoriales correspondientes,
por lo que debemos crear otras tablas que relacionen cada libro con sus
autores y editoriales.

CodLibro codAutor

1001 801

1004 802

1005 801

1006 803

1006 804

1007 806

CodLibro codEditorial

1001 901

1004 902

1005 901

1006 903
CodLibro codEditorial

1007 901

Y el resto de las tablas no necesitan modificación.

CodLector Paterno Materno Nombres

501 Pérez Gómez Juan

502 Ríos Terán Ana

503 Roca René

504 García Roque Luis

CodLibro CodLector FechaDev

1001 501 15/04/2005

1004 502 17/04/2005

1005 503 16/04/2005

1006 504 20/04/2005

1007 501 18/04/2005

Vvvvvvvvvvvvvvvvvvv

Un ejemplo completo

Tenemos una empresa pública donde los puestos de trabajo están regulados
por el Estado, de modo que las condiciones salariales están determinadas
por el puesto. Se ha creado el siguiente esquema relacional
EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

nss nombre puesto salarioemails

111 Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es
222 José SánchezAdministrativo1500 jsanchez@ecn.es
333 Ana Díaz Administrativo1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...
Table 1

Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el

ejemplo, podemos ver que el atributo emails puede contener más de un valor,
por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M
viola la condición de 1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación
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 teníamos en
R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n
valores duplicados en M, en la nueva relación habrá n tuplas, que sólo
varían en que cada una de ellas guarda uno de los valores que había
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, tendríamos el siguiente esquema para la nueva tabla

EMPLEADOS'(a) con clave primaria (nss, email):
nss nombre puesto salarioemail
111 Juan Pérez Jefe de Área 3000 juanp@ecn.es
111 Juan Pérez Jefe de Área 3000 jefe2@ecn.es
222José SánchezAdministrativo1500 jsanchez@ecn.es
333Ana Díaz Administrativo1500 adiaz@ecn.es
333Ana Díaz Administrativo1500 ana32@gmail.com
... ... ... ... ...
Table 2

Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:

sustituir R por una nueva relación modificada R' que no contiene el atributo M.
Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena
K referenciando R', junto al atributo M', que es la variante mono-valuada del
atributo M.
La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla
EMPLEADOS'(b)
nss nombre puesto salario
111 Juan Pérez Jefe de Área 3000
222José SánchezAdministrativo1500
333Ana Díaz Administrativo1500
... ... ... ...
Table 3
Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):
 nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222jsanchez@ecn.es
333adiaz@ecn.es
333ana32@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 más atributos. Si una relación está en 1FN y su clave primaria es
simple (tiene un solo atributo), entonces también 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 relación 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 relación 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 relación será K'.
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los
atributos que tienen dependencia incompleta:
salari
nss nombre puesto
o
111 Juan Pérez Jefe de Área 3000
222José SánchezAdministrativo1500
333Ana Díaz Administrativo1500
... ... ... ...
Table 5
Y al eliminar de la tabla original estos atributos nos quedaría:
nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222jsanchez@ecn.es
333adiaz@ecn.es
333ana32@gmail.com
... ...
Table 6
Como vemos, la solución a la que llegamos es la misma que en la otra
opción de solución para el problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN
y, además, 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 estén 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 solución 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 descomposición sería la siguiente:
nss nombre puesto
111 Juan Pérez Jefe de Área
222José SánchezAdministrativo
333Ana Díaz Administrativo
... ... ...
Table 7
En la nueva tabla PUESTOS, la clave sería el puesto, que también queda
como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas
quedan como estaban.

EJERCICIO NORMALIZACION – 16 Junio 2009.

Digamos que queremos crear una tabla con la información de usuarios, y los datos a guardar
son: el nombre, la empresa, la dirección de la empresa y algún e-mail, o bien URL si las
tienen. En principio comenzarías definiendo la estructura de una tabla como ésta:

Formalización CERO

usuarios

nombre empresa direccion_empresa url1 url2

Joe ABC 1 Work Lane abc.com xyz.com

Jill XYZ 1 Job Street abc.com xyz.com

Diríamos que la anterior tabla está en nivel de Normalización Cero porque ninguna de
nuestras reglas de normalización ha sido aplicada. Observa los campos url1 y url2 -- ¿Qué
haremos cuando en nuestra aplicación necesitemos una tercera url? ¿Quieres tener que
añadir otro campo/columna a tu tabla? Obviamente no, tú quieres crear un sistema funcional
que pueda crecer y adaptarse fácilmente a los nuevos requisitos. Realicemos un vistazo a
las reglas del Primer Nivel de Formalización-Normalización, y las aplicaremos a nuestra
tabla.

Primer nivel de Formalización/Normalización. (F/N)

1. Eliminar los grupos repetitivos de las tablas individuales.

2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.

¿Ves que estamos rompiendo la primera regla cuando repetimos los campos url1 y url2? ¿Y
que pasa con la tercera regla, la clave primaria? La regla tres básicamente significa que
tenemos que poner un campo tipo contador autoincrementable para cada registro. De otra
forma, ¿Qué pasaría si tuviéramos dos usuarios llamados Joe y queremos diferenciarlos.
Una vez que aplicaremos el primer nivel de F/N nos encontraríamos con la siguiente tabla:

usuarios

userId nombre empresa direccion_empresa url

1 Joe ABC 1 Work Lane abc.com

1 Joe ABC 1 Work Lane xyz.com

2 Jill XYZ 1 Job Street abc.com

2 Jill XYZ 1 Job Street xyz.com

Ahora diremos que nuestra tabla está en el primer nivel de F/N. Hemos solucionado el
problema de la limitación del campo url. Pero sin embargo vemos otros problemas....Cada
vez que introducimos un nuevo registro en la tabla usuarios, tenemos que duplicar el
nombre de la empresa y del usuario. No sólo nuestra BD crecerá muchísimo, sino que será
muy fácil que la BD se corrompa si escribimos mal alguno de los datos redundantes.
Aplicaremos pues el segundo nivel de F/N:

Segundo nivel de F/N

4. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros.
5. Relacionar estas tablas mediante una clave externa.

Hemos separado el campo url en otra tabla, de forma que podemos añadir más en el futuro
si tener que duplicar los demás datos. También vamos a usar nuestra clave primaria para
relacionar estos campos:

usuarios urls
userId nombre empresa direccion_empresa urlId relUserId url
1 Joe ABC 1 Work Lane 1 1 abc.com
2 Jill XYZ 1 Job Street 2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Hemos creado tablas separadas y la clave primaria en la tabla usuarios, userId, esta
relacionada ahora con la clave externa en la tabla urls, relUserId. Esto está mejor. ¿Pero
qué ocurre cuando queremos añadir otro empleado a la empresa ABC? ¿O 200 empleados?
Ahora tenemos el nombre de la empresa y su dirección duplicándose, otra situación que
puede inducirnos a introducir errores en nuestros datos. Así que tendremos que aplicar el
tercer nivel de F/N:

Tercer nivel de F/N.

Eliminar aquellos campos que no dependan de la clave.

Nuestro nombre de empresa y su dirección no tienen nada que ver con el campo userId, así
que tienen que tener su propio empresaId:

usuarios empresas urls

userId nombre relEmpresaId emprId empresa direccion_empresa urlId RelUserId url
1 Joe 1 1 ABC 1 Work Lane 1 1 abc.com
2 Jill 2 2 XYZ 1 Job Street 2 1 xyz.com

3 2 abc.com

4 2 xyz.com

Ahora tenemos la clave primaria emprId en la tabla empresas relacionadas con la clave
externa relEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios mientras que
sólo tenemos que insertar el nombre 'ABC' una vez. Nuestras tablas de usuarios y urls
pueden crecer todo lo que quieran sin duplicación ni corrupción de datos. La mayoría de los
desarrolladores dicen que el tercer nivel de F/N es suficiente, que nuestro esquema de datos
puede manejar fácilmente los datos obtenidos de una cualquier empresa en su totalidad, y
en la mayoría de los casos esto será cierto.
 Pero echemos un vistazo a nuestro campo urls - ¿ Ves duplicación de datos ? Esto es
perfectamente aceptable si la entrada de datos de este campo es solicitada al usuario en
nuestra aplicación para que teclee libremente su url, y por lo tanto es sólo una coincidencia
que Joe y Jill teclearon la misma url. ¿Pero que pasa si en lugar de entrada libre de texto
usáramos un menú desplegable con 20 o incluso más urls predefinidas? Entonces
tendríamos que llevar nuestro diseño de BD al siguiente nivel de F/N, el cuarto, muchos
desarrolladores lo pasan por alto porque depende mucho de un tipo muy específico de
relación, la relación 'varios-con-varios', la cual aún no hemos encontrado en nuestra
aplicación.

Relaciones entre los Datos

Antes de definir el cuarto nivel de F/N, veremos tres tipos de relaciones entre los datos: uno-
a-uno, uno-con-varios y varios-con-varios. Mira la tabla usuarios en el Primer Nivel de F/N
del ejemplo de arriba. Por un momento imaginamos que ponemos el campo url en una tabla
separada, y cada vez que introducimos un registro en la tabla usuarios también
introducimos una sola fila en la tabla urls. Entonces tendríamos una relación uno-a-uno:
cada fila en la tabla usuarios tendría exactamente una fila correspondiente en la tabla urls.
Para los propósitos de nuestra aplicación no sería útil la normalización.
Ahora mira las tablas en el ejemplo del Segundo Nivel de F/N. Nuestras tablas permiten a un
sólo usuario tener asociadas varias urls. Esta es una relación uno-con-varios, el tipo de
relación más común, y hasta que se nos presentó el dilema del Tercer Nivel de F/N. la única
clase de relación que necesitamos.
La relación varios-con-varios, sin embargo, es ligeramente más compleja. Observa en
nuestro ejemplo del Tercer Nivel de F/N que tenemos a un usuario relacionado con varias
urls. Como dijimos, vamos a cambiar la estructura para permitir que varios usuarios estén
relacionados con varias urls y así tendremos una relación varios-con-varios. Veamos como
quedarían nuestras tablas antes de seguir con este planteamiento:
usuarios empresas urls url_relations
userId nombre relEmpresaId emprId empresa direccion_empresa urlId url relationId relatedUrlId relatedUserId

1 Joe 1 1 ABC 1 Work Lane 1 1 1

1 abc.com
2 Jill 2 2 XYZ 1 Job Street 2 1 2
2 xyz.com

Para disminuir la duplicación de los datos (éste proceso nos llevará 3 2 1

al Cuarto Nivel de F/N), hemos creado una tabla que sólo tiene
4 2 2
claves externas y primarias url_relations. Hemos sido capaces de
remover las entradas duplicadas en la tabla urls creando la tabla url_relations. Ahora
podemos expresar fielmente la relación que ambos Joe and Jill tienen entre cada uno de
ellos, y entre ambos, las urls. Así que veamos exactamente que es lo que el Cuarto Nivel de
F/N. supone: