1.

Normalización de bases de datos

La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto
de estructuras de datos más pequeñas, que además de ser más simples y más estables, son
más fáciles de mantener. También se puede entender la normalización como una serie de
reglas que sirven para ayudar a los diseñadores de bases de datos 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 trataban de manipular los datos.
La normalizació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 más simple
agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de
referencia para simplificar una estructura de datos compleja.
Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de
datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos
repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.
El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede
parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como
las razones para hacerlo de esta manera.

1.1. Grados de normalización

Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda
Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas tiene sus
propias reglas. Cuando una base de datos se conforma a un nivel, se considera normalizada a
esa forma de normalización. No siempre es una buena idea tener una base de datos
conformada en el nivel más alto de normalización, puede llevar a un nivel de complejidad que
pudiera ser evitado si estuviera en un nivel más bajo de normalización.
En la tabla siguiente se describe brevemente en qué consiste cada una de las reglas, y
posteriormente se explican con más detalle.

Regla Descripción

Primera Forma Normal (1FN) Incluye la eliminación de todos los grupos repetidos.

Asegura que todas las columnas que no son llave sean

Segunda Forma Normal (2FN)
completamente dependientes de la llave primaria (PK).

Elimina cualquier dependencia transitiva. Una dependencia transitiva

Tercera Forma Normal (3FN) es aquella en la cual las columnas que no son llave son
dependientes de otras columnas que tampoco son llave.

Página 4 de 88
1.1.1. Primera Forma Normal
La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y
colocarse en tablas separadas. 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. La normalización ayuda a clarificar la base de
datos y a 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, sólo tenemos
que entender los objetos pequeños y más tangibles, así como las relaciones que guardan con
otros objetos también pequeños.

1.1.2. 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 dependencia parcial es un término
que describe a aquellos datos que no dependen de la llave primaria de la tabla para
identificarlos. Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayoría
de los problemas de lógica. Podemos insertar un registro sin un exceso de datos en la mayoría
de las tablas.

1.1.3. Tercera Forma Normal

Una tabla está normalizada en esta forma si todas las columnas que no son llave son
funcionalmente dependientes por completo de la llave primaria y no hay dependencias
transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual
existen columnas que no son llave que dependen de otras columnas que tampoco son llave.
Cuando las tablas están en la Tercera Forma Normal se previenen errores de lógica cuando se
insertan o borran registros. Cada columna en una tabla está identificada de manera única por la
llave primaria, y no debe haber datos repetidos. Esto provee un esquema limpio y elegante, que
es fácil de trabajar y expandir.
Un dato sin normalizar no cumple con ninguna regla de normalización. Para explicar con un
ejemplo en qué consiste cada una de las reglas, vamos a considerar los datos de la siguiente
tabla.

Al examinar estos registros, podemos darnos cuenta que contienen un grupo repetido para
NUM_ITEM, DESC_ITEM, CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto
tenemos que convertir a la primera forma normal.

Página 5 de 88
Los pasos a seguir son:
1. Eliminar los grupos repetidos.
2. Crear una nueva tabla con la PK de la tabla base y el grupo repetido.
Los registros quedan ahora conformados en dos tablas que llamaremos ORDENES y
ARTICULOS_ORDENES

Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar
cualquier columna no llave que no dependa de la llave primaria de la tabla. Los pasos a seguir
son:
1. Determinar cuáles columnas que no son llave no dependen de la llave primaria de la
tabla.
2. Eliminar esas columnas de la tabla base.
3. Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual
dependen.
La tabla ORDENES está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor
para cada columna. Por lo tanto, todas las columnas son dependientes de la llave primaria
ID_ORDEN.
Por su parte, la tabla ARTICULOS_ORDENES no se encuentra en 2FN ya que las columnas
PRECIO y DESC_ITEM son dependientes de NUM_ITEM, pero no son dependientes de
ID_ORDEN. Lo que haremos a continuación es eliminar estas columnas de la tabla
ARTICULOS_ORDENES y crear una tabla ARTICULOS con dichas columnas y la llave primaria
de la que dependen.
Las tablas quedan ahora de la siguiente manera.

Página 6 de 88
La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que
sea dependiente de otra columna no llave. Los pasos a seguir son:
1. Determinar las columnas que son dependientes de otra columna no llave.
2. Eliminar esas columnas de la tabla base.
3. Crear una segunda tabla con esas columnas y con la columna no llave de la cual son
dependientes.
Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTICULOS,
como la tabla ARTICULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ORDENES
no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta
columna no es la llave primaria.
Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual
dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ORDENES se
muestran a continuación.

1.2. ¿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 nosotros. Si
nuestra base de datos va a proveer información a un solo usuario para un propósito simple y
existen pocas posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo
exagerado. 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 los datos
hasta el nivel más alto no tenga sentido.
¿Se están dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad
prácticas?

Página 7 de 88
Éstas son el tipo de cosas que nosotros como diseñadores de la base de datos, necesitamos
decidir, y la experiencia y el sentido común nos pueden auxiliar para tomar la decisión correcta.
La normalización no es una ciencia exacta, más bien 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 necesitamos. É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.
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 ayudarnos a decidir cuándo
normalizar.

Página 8 de 88
2. Las 12 Reglas de CODD
En la década de los 80 comenzaron a aparecer numerosos SABD que se anunciaban como
"relacionales". Sin embargo estos sistemas carecían de muchas características que se
consideran importantes en un sistema relacional, perdiendo muchas ventajas del modelo
relacional. Como ejemplo extremo de esto "sistemas relacionales" eran simplemente sistemas
que utilizaban tablas para almacenar la información, no disponiendo de elementos como claves
primarias, etc.
En 1984 Codd publicó 12 reglas que un verdadero sistema relacional debería de cumplir. En la
práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más
relacional" cuanto más siga estas reglas.
Regla 0: Para que un sistema se denomine sistema de gestión de bases de datos
relacionales, este sistema debe usar (exclusivamente) sus capacidades relacionales para
gestionar la base de datos.
Regla 1: Regla de la Información: Toda la información en una base de datos
relacional se representa explícitamente en el nivel lógico exactamente de una manera: con
valores en tablas.
 Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los
datos de usuario.
 Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos
(regla 4)
 Un valor posible es el valor nulo, con sus dos interpretaciones:
 Valor desconocido (ej. dirección desconocida)
 Valor no aplicable (ej. empleado soltero no tiene esposa).
Regla 2: Regla del acceso garantizado: Para todos y cada uno de los datos
(valores atómicos) de una BDR se garantiza que son accesibles a nivel lógico utilizando una
combinación de nombre de tabla, valor de clave primaria y nombre de columna.
 Cualquier dato almacenado en una BDR tiene que poder ser direccionado
unívocamente.
 Para ello hay que indicar en qué tabla está, cuál es la columna y cuál es la fila (mediante
la clave primaria).
 Por tanto se necesita el concepto de clave primaria, que no es soportado en muchas
implementaciones. En estos casos, para lograr un efecto similar se puede hacer lo
siguiente:
 Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).
 Crear un índice único sobre la clave primaria.
 No eliminar nunca el índice.

Página 9 de 88
Regla 3: Tratamiento sistemático de valores nulos: Los valores nulos (que
son distintos de la cadena vacía, blancos, 0,...) se soportan en los SABD totalmente
relacionales para representar información desconocida o no aplicable de manera sistemática,
independientemente del tipo de datos.
 Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento
sistemático de los mismos.
 Hay problemas para soportar los valores nulos en las operaciones relacionales,
especialmente en las operaciones lógicas.
Lógica trivaluada. Es una posible solución. Existen tres (no dos) valores de verdad:
Verdadero, Falso y Desconocido (null). Se crean tablas de verdad para las operaciones
lógicas:
 null Y null = null
 Verdadero Y null = null
 Falso Y null = Falso
 Verdadero O null = Verdadero
Un inconveniente es que de cara al usuario el manejo de los lenguajes relacionales se complica
pues es más difícil de entender.
Regla 4: Catálogo dinámico en línea basado en el Modelo Relacional:
La descripción de la base de datos se representa a nivel lógico de la misma manera que los
datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje
relacional a su consulta, igual que lo aplican a los datos normales.
 Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos se
almacenan usando el modelo relacional, con todas las consecuencias.
Regla 5: Regla del sublenguaje de datos completo: Un sistema relacional
debe soportar varios lenguajes y varios modos de uso de terminal (ej: rellenar formularios, etc.).
Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante
una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando:
 Definición de datos
 Definición de vistas
 Manipulación de datos (interactiva y por programa)
 Limitantes de integridad
 Limitantes de transacción (iniciar, realizar, deshacer) (Begin, commit, rollback).
 Además de poder tener interfaces más amigables para hacer consultas, etc. siempre
debe de haber una manera de hacerlo todo de manera textual, que es tanto como decir
que pueda ser incorporada en un programa tradicional.
 Un lenguaje que cumple esto en gran medida es SQL.
Regla 6: Regla de actualización de vistas: Todas las vistas que son teóricamente
actualizables se pueden actualizar por el sistema.
 El problema es determinar cuáles son las vistas teóricamente actualizables, ya que no
está muy claro.
 Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son
actualizables.

Página 10 de 88
Regla 7: Inserción, actualización y borrado de alto nivel: La capacidad de
manejar una relación base o derivada como un solo operando se aplica no sólo a la
recuperación de los datos (consultas), sino también a la inserción, actualización y borrado de
datos.
 Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de conjuntos).
Algunas bases de datos inicialmente sólo podían modificar las tuplas de la base de
datos de una en una (un registro de cada vez).
Regla 8: Independencia física de datos: Los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen
cambios en las representaciones de almacenamiento o métodos de acceso.
 El modelo relacional es un modelo lógico de datos, y oculta las características de su
representación física.
Regla 9: Independencia lógica de datos: Los programas de aplicación y
actividades del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen
cambios a las tablas base que preserven la información
 Cuando se modifica el esquema lógico preservando información (no valdría p.ej. eliminar
un atributo) no es necesario modificar nada en niveles superiores.
 Ejemplos de cambios que preservan la información:
 Añadir un atributo a una tabla base.
 Sustituir dos tablas base por la unión de las mismas. Usando vistas de la unión puedo
recrear las tablas anteriores...
Regla 10: Independencia de integridad: Los limitantes de integridad específicos
para una determinada base de datos relacional deben poder ser definidos en el sublenguaje de
datos relacional, y almacenables en el catálogo, no en los programas de aplicación.
 El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus
relaciones y evitar que estas (limitantes) se codifiquen en los programas. Por tanto en
una BDR se deben poder definir limitantes de integridad.
 Cada vez se van ampliando más los tipos de limitantes de integridad que se pueden
utilizar en los SABDR, aunque hasta hace poco eran muy escasos.
 Como parte de los limitantes inherentes al modelo relacional (forman parte de
sudefinición) están:
 Una BDR tiene integridad de entidad. Es decir, toda tabla debe tener una clave primaria.
 Una BDR tiene integridad referencial. Es decir, toda clave externa no nula debe existir en
la relación donde es primaria.
Regla 11: Independencia de distribución: Una BDR tiene independencia de
distribución.
 Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en una
distribuida.
 Las BDR son fácilmente distribuibles:
 Se parten las tablas en fragmentos que se distribuyen.
 Cuando se necesitan las tablas completas se recombinan usando operaciones
relacionales con los fragmentos.

Página 11 de 88
  Sin embargo se complica más la gestión interna de la integridad, etc.
 Esta regla es responsable de tres tipos de transparencia de distribución:
 Transparencia de localización. El usuario tiene la impresión de que trabaja con una BD
local. (aspecto de la regla de independencia física)
 Transparencia de fragmentación. El usuario no se da cuenta de que la relación con que
trabaja está fragmentada. (aspecto de la regla de independencia lógica de datos).
 Transparencia de replicación. El usuario no se da cuenta de que pueden existir copias
(réplicas) de una misma relación en diferentes lugares.
Regla 12: Regla de la no subversión: Si un sistema relacional tiene un lenguaje de
bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir)
las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto
nivel (una relación (conjunto de registros) de cada vez).
 Algunos problemas no se pueden solucionar directamente con el lenguaje de alto nivel.
 Normalmente se usa SQL inmerso en un lenguaje anfitrión para solucionar estos
problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas de una
relación. En cualquier caso no debe ser posible saltarse los limitantes de integridad
impuestos al tratar las tuplas a ese nivel.

Página 12 de 88