República Bolivariana de Venezuela

Ministerio del Poder Popular para la Defensa

Universidad Experimental Politécnica de la Fuerza Armada Nacional
Núcleo Pto-Cabello, Edo-Carabobo.

NORMALIZACIÓN

Profesor: Bachilleres:
Ing. Laur Vanegas Adrian Betancourt. C.I: 27102779.
Robert Sánchez. C.I: 27307525
  Definición
La tarea de un diseñador de bases de datos consiste en estructurar los datos de forma que se
eliminen duplicaciones innecesarias y se proporcione una ruta de búsqueda rápida para toda la
información necesaria. El proceso de perfeccionar tablas, claves, columnas y relaciones para crear
una base de datos eficaz se denomina normalización. La definición completa de normalización es el
proceso de descartar la repetición de grupos, minimizar la redundancia, y separar los atributos que
no sean de la clave.

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las

relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea
considerada como una relación tiene que cumplir con algunas restricciones:

 Cada columna debe tener su nombre único.

 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.

Las consecuencias de la falta de normalización de base de datos son:

 Inexactitud de los sistemas de bases de datos.
 Ralentización de los procesos.
 Ineficiencia en las operaciones.

La normalización de base de datos ayuda a evitar estos efectos negativos ya desde el diseño de

nuevas bases de datos y permite también comprobar si las existentes garantizan la integridad de
datos o referencial necesaria. Lo más recomendable es proceder a normalizar los datos antes de
crear las tablas de la base de datos, aunque siempre es preferible asegurar su integridad y, aunque
ya se cuente con las bases de datos y no sean de nueva creación, utilizar estas técnicas para
ponerlas a prueba, teniendo claros los objetivos a alcanzar en el proceso.
Se trata de un proceso de organización de las bases de datos en el que se aplica una serie de reglas
para tener una estructura de datos saneada. En otras palabras, el objetivo es eliminar duplicidades o
dependencias innecesarias en las tablas de datos y entre las relaciones que estas unen - o bien
aportarlas, si la necesidad es la contraria-. 
Por ejemplo, la normalización de los datos fiscales en curso de una empresa permitiría eliminar de
ese registro otros indicadores temporales, relativos a su histórico, o que dependan de terceras
tablas. 
La correcta asignación del valor de los datos es tan importante porque será la única manera de
garantizar que se eliminan redundancias y que, por ende, los cambios en la data se implementen y
cruzan correctamente.

 Para que se usa

La normalización de base de datos ayuda a evitar estos efectos negativos ya desde el diseño de
nuevas bases de datos y permite también comprobar si las existentes garantizan la integridad de
datos o referencial necesaria. Lo más recomendable es proceder a normalizar los datos antes de
crear las tablas de la base de datos, aunque siempre es preferible asegurar su integridad y, aunque
ya se cuente con las bases de datos y no sean de nueva creación, utilizar estas técnicas para
ponerlas a prueba, teniendo claros los objetivos a alcanzar en el proceso.
La normalización de base de datos es especialmente importante en el entorno del procesamiento
transaccional, sobre todo en el que se lleva a cabo en línea. Esto es debido a la agilidad con que se
llevan a cabo las modificaciones de datos que, además, suelen darse de forma aleatoria.
Inserciones, eliminaciones o actualizaciones afectan a los datos almacenados pudiendo disminuir el
rendimiento de la base de datos si ésta no se ha normalizado.
No obstante, antes de poder empezar a normalizar una base de datos es preciso realizar un análisis
de requisitos, que servirá para determinar las políticas y procedimientos a aplicar. De esta
investigación resultará un compendio de reglas de negocio.
Estas reglas han de ser obtenidas por consenso y, este acuerdo entre los usuarios de la base de
datos, tanto en materia de uso de los distintos elementos de cada tabla, como en cuanto a sus
definiciones, es fundamental para lograr los objetivos de la normalización de base de datos. Para
llegar al consenso pueden emplearse esquemas o metodologías, que faciliten la transición a lo largo
de la fase de requisitos, análisis y esquema de base de datos. Lo importante es que las reglas estén
claras y que el significado de cada término y la forma de utilizarlo quede confirmado antes de
empezar a normalizar.

 Formas Normales
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos
está en la forma normal N es decir que todas sus tablas están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la
mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar
F. Codd.
  Primera Forma Normal (1FN) 

Una tabla está en Primera Forma Normal

 Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son
indivisibles, mínimos.
 La tabla contiene una clave primaria.
 La llave primaria no contiene atributos nulos.
 No posee ciclos repetitivos.
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le
pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)

Esta forma normal elimina los valores repetidos dentro de una BD.

 Segunda Forma Normal (2FN)

Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman
parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen
dependencias parciales.
En otras palabras, podríamos decir que la segunda forma normal está basada en el concepto de
dependencia completamente funcional. Una dependencia funcional x -> y es completamente
funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es
que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos
atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A Є X, (X –
{A}) -> Y.
Por ejemplo {DNI, ID_PROYECTO} -> HORAS_TRABAJO (con el DNI de un empleado y el ID de un
proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es
completamente dependiente dado que ni DNI -> HORAS_TRABAJO ni ID_PROYECTO ->
HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} ->
NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI -> NOMBRE_EMPLEADO
mantiene la dependencia.

 Tercera Forma Normal (3FN) 

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre
los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación
R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de
alguna clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la
siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía
DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son
mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente,
podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT
dado que DNUMBER no es una clave de EMP_DEPT.
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

1001 Variable compleja Murray Spiegel McGraw Hill Pérez Gómez, 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
1006 Oracle University Nancy Oracle Corp. García Roque, 20/04/2005
Greenberg y Luis
Priya Nathan
1007 Clipper 5.01 Ramalho McGraw Hill Pérez Gómez, 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
1001 Variable Murray Spiegel McGraw Hill Pérez Gómez Juan 15/04/200
compleja 5
1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán Ana 17/04/200
5
1005 Estadística Murray Spiegel McGraw Hill Roca   René 16/04/200
5
1006 Oracle Universit Nancy Greenber Oracle Corp García Roque Luis 20/04/200
y g . 5
1006 Oracle Universit Priya Nathan Oracle Corp García Roque Luis 20/04/200
y . 5
 CodLibro Titulo Autor Editorial Paterno Materno Nombres FechaDev
1007 Clipper 5.01 Ramalho McGraw Hill Pérez Gómez Juan 18/04/200
5

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
1001 Variable compleja Murray Spiegel McGraw Hill
1004 Visual Basic 5 E. Petroustsos Anaya
1005 Estadística Murray Spiegel McGraw Hill
1006 Oracle University Nancy Greenberg Oracle Corp.
1006 Oracle University Priya Nathan Oracle Corp.
1007 Clipper 5.01 Ramalho McGraw 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 CodLecto FechaDev

r
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
 CodAutor Autor
803 Nancy 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
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

CodLibr CodLecto FechaDev

o r
1001 501 15/04/200
5
1004 502 17/04/200
5
1005 503 16/04/200
5
1006 504 20/04/200
5
1007 501 18/04/200
5