La Normalización.

Es bueno conocer la terminología de un modelo relacional de base de datos ¿pero, qué

puede hacer con este conocimiento? Imagine que tiene una mezcla de datos (nombres,
direcciones, clubes, adquisiciones, etc) en una sola tabla. ¿Cómo cambiar este desorden
en una estructura de base de datos bien diseñada? El proceso se llama Normalización.

Usted puede pensar en la normalización como “los datos, todos los datos y nada más que
datos”.

Aunque la normalización se basó en una gran cantidad de teoría matemática y en realidad

puede describirse en un conjunto de reglas concisas, es más fácil de entender con un
ejemplo.

Ejemplo de aplicación de bases de datos:

En el mundo hay clubes de autos para casi todas las fábricas y modelos. Puede encontrar
organizaciones para Ferrari, Rolls-Royce, Corvette, Mustang y MG de la preguerra y
posguerra. Algunos clubes presumen que tienen miles o cientos de miles de miembros.
Sin embargo, mientras más grande sea este número, menor será la cantidad de
información que pueda reunir sobre los socios del club y la estructura del auto. Con un
club más pequeño, dedicado sólo a una fábrica y un modelo que no se fabricó en grandes
cantidades, mayor será la información que pueda reunirse.

Los MG, en particular los modelos de la preguerra de 1937, 1938 y 1939, constituyen un
grupo muy pequeño con el que se puede reunir una gran cantidad de información sobre
algunos modelos. Sin embargo, normalmente esta información se guarda en páginas
escritas a mano, y se pasan de un presidente de un club a otro presidente de club.

Por consiguiente, tuvo sentido automatizar la recopilación y mantenimiento de estos datos

– un directorio de propietarios de MG será la aplicación utilizada para este ejemplo. El
diseño original era una lista de propietarios,

Primero, estaban los detalles comunes que acompañan a una base de datos de nombres
y direcciones. Algunos propietarios estaban casados y compartían un mismo apellido,
otros tenían apellidos distintos. Algunos tenían más de una dirección. Muchos propietarios
vivían fuera de Estados Unidos, así que sus direcciones no coincidían con el formato
“Ciudad, Estado y Código Postal” de Estados Unidos. Incluso con una sola dirección, los
propietarios tenían uno, dos o más números telefónicos. Y tenían uno o más automóviles.

Problemas:

La solución inicial, proporcionada por los clubes de manera individual, fue reunir
información acerca de cada uno de los propietarios en una tarjeta de 3 x 5 pulgadas, y
luego transferir esa información a una lista mecanografiada en hojas tamaño carta. Esto
es tan primitivo como la historia de la recolección de datos, así que surgieron muchos
problemas. El primero, surgió de la naturaleza manual de la recopilación de datos.
Después, no podía modificarse el orden de la información. Las listas mecanografiadas se
organizaban en orden alfabético por el propietario, así que era imposible, clasificar y
buscar de otra manera. Y de la misma forma, también era imposible generar otra salida,
por ejemplo, etiquetas de correo.

Debido a que los datos de cada uno de los automóviles estaban vinculados a un
propietario, cualquier tipo de informe o estadística de los artículos, como el número de
automóviles, precio o kilometraje también era imposible de producir, a menos que se
usaran los recursos más laboriosos.¿Cómo hacer una lista de automóviles actualmente
en venta, incluyendo el nombre del vendedor? Del mismo modo, poder buscar
rápidamente un automóvil al emplear distintos criterios como el kilometraje o la ubicación,
no era factible con la lista existente.

Ya que esta es una nueva aplicación, es probable que se le encuentren nuevos usos
como nuevos informes a partir de los datos existentes. Sin duda, se harían cambios
adicionales a los datos. Dadas estas limitaciones, usar una sola tabla no es la respuesta.

Por qué vale la pena el trabajo de la Normalización:

No habría sido más fácil ingresar los datos de manera redundante, en vez de tomarse
todo el trabajo de la normalización? Si la base de datos aumentara a 10000 registros, no
sería práctico. Existen cuatro razones específicas para normalizar una base de datos y
son válidas para las aplicaciones más triviales e insignificantes.

1.- Minimizar el espacio requerido para almacenamiento:

Imagine que su aplicación de base de datos fuera a rastrear los pedidos de un comercio.
Si la base de datos no estuviera normalizada, tendría que almacenar el nombre y la
dirección de todos los clientes en cada uno de los registros de pedido. Si la compañía
realizara varias operaciones repetitivas, se tendría que registrar la misma información una
y otra vez, lo que ocuparía demasiado espacio libre.

Además, ya que cada registro debe contar con un espacio para cada artículo que el
cliente ordene, puede que haya muchos campos sin usar, creados en caso de que alguien
ordenara varios artículos.

2.- Eliminar inconsistencia de los datos:

Si continuamos con el ejemplo anterior, imagine que debe introducir en efecto, el nombre
y la dirección del cliente una y otra vez en cada registro nuevo.

Eventualmente encontrará varias diferencias: un pedido tiene al cliente consignado en 100

East Main Street, otra lo tiene en 100 E. Main St., otra en 100 E. Main, una cuarta en 100
Main East Avenue y una quinta tiene la dirección de un apartado postal. Después, la
compañía se muda a una nueva localidad y entonces empiezan a aparecer los cambios
en la nueva dirección. Más tarde, cuando busque un par de pedidos, encontrará dos
direcciones diferentes. ¿cuál es la actual?
Al almacenar un elemento de datos en un solo lugar de manera precisa, jamás se
cuestionará cuál es la entrada correcta. Como dice un refrán en inglés, “Un hombre con
un reloj siempre sabe exactamente qué hora es. Un hombre con dos relojes nunca está
seguro de ello”.

3.- Minimizar problemas de actualización y eliminación:

Continuamos con el ejemplo anterior. Supongamos que tomamos en cuenta el hecho de

que un cliente se almacenaría en registros múltiples, y escribimos una rutina para
actualizar la dirección en cada registro cuando ésta se cambiara. En primer lugar, todo
esto es un trabajo innecesario. En segundo lugar, y más importante, ¿qué pasa si surge
un problema durante la ejecución de la rutina? ¿qué pasa si la energía se interrumpe, el
disco duro se detiene o algún otro evento interrumpe el programa?. Después de esto, los
datos están actualizados sólo en algunos de los registros ( y terminamos donde
estábamos: con inconsistencia en los datos). El mismo problema puede ocurrir durante las
eliminaciones si hay redundancias o posibles inconsistencias en los datos.,

4.- Maximizar la robustez de la estructura:

En el ejemplo anterior, se dio por hecho un lugar para el nombre y la dirección del cliente.
Supongamos que los requerimientos cambian. El espacio para el nombre y la dirección
del cliente también incluía un campo para el teléfono y un segundo campo para el fax, y
así había funcionado bien a la compañía por décadas. De repente, debían ser rastreados
más números telefónicos (celular, localizador, llamada de larga distancia gratuita, número
900, llamada por cobrar e incluso fax móvil). Y quizá esto continúe (con una o varias
direcciones de correo electrónico) Si se había normalizado la base de datos de manera
adecuada, habría una tabla separada con números telefónicos y una descripción de cada
tipo, con el fin de que pudiera almacenarse una cantidad ilimitada de números telefónicos
y otros números de contacto. Con esto, no tendría que cambiar la estructura de la base de
datos, lo que significa que la aplicación no cambia, y tampoco los formularios, informes,
consultas o programas que comprenda.

De nuevo, hay que recordar que la representación física de estos elementos (bases de
datos, tablas, índices, etc) no necesita tener una relación uno a uno con sus primos
lógicos. Por ejemplo, una base de datos podría almacenarse en más de un archivo, o un
grupo de tablas (lógicas) podría almacenarse en la misma estructura física. Sin embargo,
las representaciones lógicas y físicas a menudo se corresponden la una con la otra.

La Normalización es la solución:

A partir de una sola tabla, se crean una serie de tablas y campos con relaciones entre
ellas, con claves principales y externas colocadas en cada una de las tablas para manejar
estas relaciones, y con los datos estructurados de manera correcta.

La normalización consiste en alrededor de 20 reglas, o formas, cada una de las cuales

depende de la regla anterior y que estructura de manera más estrecha los datos.
En sentido práctico, la gran mayoría de las bases de datos normalizadas nunca van a
pasar de la tercera forma normal.

Estas formas normales son: (Según Ted y Cod).

Primera Forma Normal:

Eliminar los campos repetidos o sobrevaluados a una segunda tabla.

Estos son campos que almacenan los mismos tipos de información. Por ejemplo, el
listado de propietarios tenía varios campos duplicados, en primer lugar la lista de
automóviles por propietario; evidentemente, esos campos necesitaban ser trasladados a
una segunda tabla. Algunos propietarios tenían media docena de automóviles o más.
Además, al rastrear a los propietarios anteriores por automóvil se acababa creando una
tercera tabla, ya que un auto pudo tener varios propietarios anteriores.

En términos estrictos, la tercera tabla no debería crearse – sólo debería haber una tabla
de propietarios y otra para automóviles. Y luego, ¿cómo se relacionaban la tabla
Propietarios y Automóviles, puesto que un propietario podía estar vinculado a uno o más
automóviles, y un automóvil podía haber pertenecido a una o más personas?.
Obviamente, no se pueden colocar múltiples claves principales de automóvil en la tabla
Propietarios (una para cada uno de los autos que posee el propietario) ya que se violaría
la primera forma normal tanto como colocar toda la información de los automóviles de los
Automóviles en la tabla Propietarios. De igual manera, no se pueden colocar claves
principales para cada uno de los propietarios anteriores en la tabla Automóviles. Esto no
sólo violaría la primera forma normal, sino que tampoco sería práctico, puesto que un
automóvil podría tener docenas de propietarios a través del tiempo.

Como no podemos colocar varias claves principales dentro de una tabla con el mismo tipo
de datos, la solución es utilizar una tabla intermedia, llamada Tabla Unión, que contiene
las claves principales para cada combinación de los campos Automóviles y Propietarios.

Por ejemplo, supongamos que Alejandro tuvo dos automóviles, un TC y un TD. Él fue el
primer propietario del TC, pero el TD se lo compró a David, quien se lo había comprado a
Dora, la primera propietaria. Además, supongamos que David tiene actualmente un TA, y
que Dora no tiene ningún auto por ahora. De esta manera existirían tres registros en la
tabla Propietarios: Alejandro, David y Dora. Existirían tres registros en la tabla
Automóviles: TA, TC y TD.

Sin embargo, la tabla Unión sería más compleja. Tendría dos columnas, una para la clave
principal de la tabla Automóviles, y otra para la clave principal de la tabla Propietarios.
Tendría un solo registro para cada relación actual propietario – automóvil, y también
tendría un solo registro para cada relación automóvil – propietario anterior. De este modo,
la tabla se vería así:

Automóvil Propietario

TC Alejandro (primer y actual propietario)

TD Alejandro (propietario actual)

TA David (propietario actual)

TD David (segundo propietario)

TDDora (primera propietaria)

Cada una de estas claves sirve para alojar un registro completo tanto en la tabla
Automóvil como en la tabla Propietario. Cuando David se mude, su dirección se cambiará
en un solo lugar. Cuando el kilometraje del TD se actualice, también se cambiará en un
solo lugar.

Segunda Forma Normal:

Eliminar campos que no dependen de la clave principal completa.

En algunas tablas, la clave principal está compuesta por distintos campos. Esta regla
requiere que todos los campos que no son dependientes de la clave principal por
completo, deberán ubicarse en otra tabla donde sí dependan por completo. Por ejemplo,
usted podría diseñar una clave principal para la tabla Automóviles, que consista en el
número de identificación del vehículo, fábrica, modelo, año y color. Sin embargo, el
nombre de la fábrica (MG) es redundante (si el modelo es un TC o un TD, es un MG). No
puede ser Ford o Porshe.

Selección de una Clave Principal:

Es bueno crear un número para la clave principal, pues esto trae varios beneficios. En
primer lugar, garantiza que la clave principal es única. En segundo lugar, una clave
sencilla siempre tiene un mejor desempeño que una clave compuesta. Los clientes
siempre quieren aplicaciones que se ejecuten más rápido, nunca con más lentitud. En
tercer lugar, aún cuando puede localizar un campo o un grupo de campos en una tabla
que es única, nada garantiza que las reglas del ambiente o la empresa no cambiarán para
invalidar esa singularidad. Por ejemplo, mucha gente piensa de manera errónea que un
número de seguro social es único y que es un buen candidato para identificar de manera
exclusiva a un individuo. Pero, ¿qué pasa con la gente que no tiene número de seguro
social, como los bebés y los ciudadanos no naturalizados?. Ya ha habido casos
documentados de emisión de números duplicados.

Además, supongamos que algún día la administración de seguridad social resuelve que
reutilizará los números emitidos hace 150 años. Si rastrea a los empleados activos de una
compañía o a los inversionistas de un fondo común, quizás está bien. Pero si ejecuta una
aplicación de genealogía y emplea los números de seguro social con la creencia de que
siempre serán únicos, entonces su aplicación está condenada a fracasar.

Tercera Forma Normal:

Eliminar campos que dependen de otros campos sin clave:

Si un campo no depende de la clave principal de la tabla, pero puede ligarse a otro campo
de la tabla que no es la clave principal, muévalo de la tabla. El clásico ejemplo de esto es
la inclusión de ciudad y estado en una tabla que también incluye la zona o código postal.
Mientras el código postal de una dirección depende de la clave principal ( la persona o
compañía en el registro), los campos Ciudad y Estado no. Ellos dependen del Código
Postal. Por ello, pueden sacarse de la tabla y llevarse a una tabla de búsqueda por código
postal. Después de todo, una vez que se sepa el código postal, podrá usar la clave
principal en la tabla de búsqueda del código postal para encontrar la ciudad y el estado.

UN ejemplo de la tabla Propietarios presenta la misma situación, donde ciudad, estado y

código postal se incluyen en la dirección.

Cuarta Forma Normal:

Eliminar componentes sobrevaluados independientemente de la clave principal a nuevas

y múltiples entidades padre.

Esto suena complicado. Esencialmente, si utiliza claves principales compuestas por

campos múltiples, no querrá seleccionar aquellas claves compuestas por campos, donde
dichos campos pueden tener valores múltiples, independientes el uno del otro. En un
lenguaje más sencillo, no querrá crear una situación en donde para cambiar los datos en
un campo, también se requiera cambiarlos en otro campo.

Si utiliza claves principales de un solo campo, esto no es un problema, y una vez que su
tabla está en la tercera forma normal, también está en la cuarta forma normal.

Quinta Forma Normal:

Eliminar dependencias cíclicas pair – wise ( que aparecen dentro de las claves principales
compuestas con tres o más campos compuestos) a tres o más nuevas tablas padre.

En cierto modo, esta regla es una extensión de la cuarta forma normal. Esta forma
describe una situación en la que usted tiene una clave principal con tres o más campos, y
estos campos son interdependientes de sus valores. De nuevo, si utiliza claves principales
de un solo campo, su base de datos de cuarta forma normal también se encontrará en la
quinta forma normal.

LA NORMALIZACION: (Según Jonás Montilva)

La Normalización es un proceso empleado durante el diseño de base de datos

relacionales a fin de evitar anomalías e inconsistencia en la actualización de la base de
datos.

Está basada en el hecho de que ciertas relaciones (o tablas) tienen mejores propiedades,
durante la actualización, que otras que contienen los mismos datos.

Ejemplo de una relación no-normalizada:

MANUALTECNICO (CodMan, Título, (Préstamo), FechaIngreso)

Donde PRESTAMO es un atributo compuesto (CodUsuario, FechaPréstamo,
NumEjemplar) y multivaluado, pues se repite tantas veces como préstamos vigentes
tenga un manual.

PRIMERA FORMA NORMAL:

Una tabla o relación r está en Primera Forma Normal (1FN) si y sólo si cada elemento de r
es atómico (indivisible), es decir, no contiene atributos multivaluados.

¿Cómo normalizar una tabla con atributos multivaluados?

La relación MANUALTECNICO se normaliza en 1FN removiéndole el atributo

multivaluado y creando una nueva relación con este atributo, tal como se muestra a
continuación:

MANUALTECNICO (CodMan, Título, FechaIngreso)

PRESTAMO (CodMan, CodUsuario, FechaPréstamo, NumEjemplar)

DEPENDENCIAS FUNCIONALES:

Una dependencia funcional es un tipo de asociación entre los atributos de una relación.

Dependencia Funcional Simple:

Un atributo B de una relación r es funcionalmente dependiente de A, si, a cada instante,

cada valor de A tiene no más de un valor de B asociado.

Se dice entonces, que el atributo A identifica o es determinado por el atributo B.

A --------- B

Identifica

Siempre que dos tuplas tengan el mismo valor de A, entonces del valor de B debe
también coincidir.

Ejemplos:

En las relacione EMPLEADO (Nombre, Apellido, Cédula, Fnacimiento...) y

TRABAJAPARA (Cédula, PNum, Horas)

Cédula ----------- Nombre

Cédula ----------- Apellido

Cédula, PNum --------- Horas

Cédula ----------/------- Horas

Pnum ----------/-------- Horas

Dependencia Funcional Completa:

El atributo B depende en forma funcionalmente completa del atributo A, (A === > B) si y

sólo si:

1.- B e funcionalmente dependiente de A

A ---------- B

2.- Si A es un atributo compuesto, entonces B es funcionalmente dependiente de la

totalidad del conjunto A y no de un subconjunto de este.

Ejemplo:

Sea A = A1 + A2, entonces decimos que A ==== > B si:

A1 + A2 --------- > B, pero A1 -----/-----> y A2 -----------/------ > B

Ejemplo:

Cédula, Pnum ======= > Horas

CodMan, CodUsuario ======== > FechaPréstamo

Dependencia Transitiva:

Si el atributo A identifica a un atributo B y éste último a su vez, identifica a un atributo C,

entonces, C es transitivamente dependiente de A.

Si A ------- > B y B --------- > C, entonces A ----------- > C

SEGUNDA FORMA NORMAL:

Una relación r está en segunda forma normal (2FN), si y sólo si, está en 1FN y cada
atributo B no primario de R depende en forma funcionalmente completa de cada clave
candidata A de r.

Ejemplo:

La siguiente relación no está en 2FN:

PRESTAMO (CodMan, CodUsuario, NombUsuario, FechaPréstamo)

Pues CodUsuario ------- > NombreUsuario

¿Cómo convertir una relación a 2FN?

La relación PRESTAMO se divide en dos tablas:

PRESTAMO (CodMan, CodUsuario, FechaPréstamo)

USUARIO (CodUsuario, NombUsuario)

TERCERA FORMA NORMAL:

Una tabla r está en tercera forma normal (3FN), si y sólo si, está en 2FN y cada atributo
no primario de r no es transitivamente dependiente de cada clave candidata.

Ejemplo:

La siguiente relación r no está en 3FN:

DEPARTAMENTO (CodDpto, NombreD, CodJefe, NombreJefe)

Pues NombreJefe es transitivamente dependiente de CodDpto.

CodDpto --------- > CodJefe y CodJefe --------- > NombreJefe

¿Cómo convertir la relación DEPARTAMENTO a 3FN?

DEPARTAMENTO (CodDpto, NombreD, CodJefe)

JEFE (CodJefe, NombreJefe)