Normalización de bases de datos

Fundamentos de la normalización

La normalización es el proceso de organizar los datos de una base de datos. Se incluye la creación de
tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos
como para hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias
incoherentes.

Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que
cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en
todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los
datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.

Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal".
Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se
cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal".
Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel
necesario para la mayor parte de las aplicaciones.

Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se
cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y
algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas
de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer,
como la existencia de datos redundantes y de dependencias incoherentes.

En las descripciones siguientes se incluyen ejemplos.

Primera forma normal

• Elimine los grupos repetidos de las tablas individuales.

• Cree una tabla independiente para cada conjunto de datos relacionados.
• Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el
seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del
inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.

¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere
modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores.
En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada
Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o
los proveedores al inventario con el código de proveedor como clave.
Segunda forma normal

• Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.
• Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave
compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de
contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos,
Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como una
entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla Clientes o
en una tabla Direcciones independiente.

Tercera forma normal

• Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En
general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único registro de
la tabla, considere colocar estos campos en una tabla independiente.

Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la
dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de
correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos,
no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla
Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.

EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si
tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear
tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y
cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el
trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la
capacidad de memoria o de archivos abiertos.

Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si
quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe
todos los campos relacionados cuando cambie alguno.

Normalización de una tabla de ejemplo

Estos pasos demuestran el proceso de normalización de una tabla de alumnos ficticia.

1. Tabla sin normalizar:

Nº alumno Tutor Despacho-Tut Clase1 Clase2 Clase3

1022 García 412 101-07 143-01 159-02
4123 Díaz 216 201-01 211-02 214-01
2. Primera forma normal: no hay grupos repetidos

Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas
clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los
registros anteriores son indicativos de un problema de diseño.

Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra
forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el
lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando
el grupo repetido (Nº clase), según se muestra a continuación:

Nº alumno Tutor Despacho-Tut Nº clase

1022 García 412 101-07
1022 García 412 143-01
1022 García 412 159-02
4123 Díaz 216 201-01
4123 Díaz 216 211-02
4123 Díaz 216 214-01

3. Segunda forma normal: eliminar los datos redundantes

Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase
no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la
segunda forma normal.

Las dos tablas siguientes demuestran la segunda forma normal:

Alumnos:

Nº alumno Tutor Despacho-Tut

1022 García 412
4123 Díaz 216

4.

Registro:

Nº alumno Nº clase
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01
 5. Tercera forma normal: eliminar los datos no dependientes de la clave

En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente

dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla
Personal, según se muestra a continuación:

Alumnos:

Nº alumno Tutor
1022 García
4123 Díaz

6.

Personal:

Nombre Habitación Dept

García 412 42
Díaz 216

Tema: Ciclo de Vida de un Sistema de Base de Datos Abstract This presentation shows all the service life to us
that is due to realise for the design of a basic application of data. Keywords: Data base, Conceptual design,
Logical design, Physical design

CICLO DE VIDA DE UN SISTEMA DE BASE DE DATOS

Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes: 1.Planificación del proyecto.
2.Definición del sistema. 3.Recolección y análisis de los requisitos. 4.Diseño de la base de datos. 5.Selección
del SGBD. 6.Diseño de la aplicación. 7.Prototipado. 8.Implementación. 9.Conversión y carga de datos.
10.Prueba. 11.Mantenimiento.

1. Planificación del proyecto

Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera
más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a
cabo y el dinero para pagar por todo ello. Normalmente, este modelo de datos se representa mediante un
diagrama Entidad - Relación. La planificación de la base de datos también incluye el desarrollo de estándares
que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será
necesaria y cómo se va a llevar a cabo el diseño y la implementación.

2. Definición del sistema

En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros
sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación.

3. Recolección y análisis de los requisitos

En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta
información se puede recoger de varias formas: •Entrevistando al personal de la empresa. •Observando el
funcionamiento de la empresa. •Examinando documentos, sobre todo aquellos que se utilizan para recoger o
visualizar información. •Utilizando cuestionarios para recoger información de grandes grupos de usuarios. La
información recogida debe incluir las principales áreas de aplicación y de usuarios, la documentación utilizada o
generada por estas áreas, las transacciones requeridas.

4. Diseño de la base de datos

Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera
fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones
físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden
representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el
esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las
estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la
base de datos en memoria secundaria.

5. Selección del SGBD

Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado
para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico.
Ejemplo de SGBD: •Apache Derby •FoxPro •Access •SQL Server •Firebird

6. Diseño de la aplicación
En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el
diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las
aplicaciones hasta que se ha terminado con el diseño de la base de datos. En esta etapa hay que asegurarse de
que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación.
Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema
debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene estas
características, el sistema dará problemas, sin lugar a dudas.

7. Prototipado Un prototipo es un modelo de trabajo de las aplicaciones del sistema.

El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan
utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir
mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema
sepan si han interpretado correctamente los requisitos de los usuarios. Esta etapa es imprescindible cuando el
sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías..

8. Implementación
La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos
(LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros
en donde se almacenarán los datos y las vistas de los usuarios. Partes de estas aplicaciones son transacciones
sobre la base de datos, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD.
También se implementan los menús, los formularios para la introducción de datos y los informes de
visualización de datos mediante lenguajes de consultas no procedurales, generadores de informes, generadores
de formularios, generadores de aplicaciones. También se implementan todos los controles de seguridad e
integridad.

9. Conversión y carga de datos

Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan
desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo
SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten
para que se puedan utilizar en el sistema nuevo

10. Prueba
En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe
diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es
importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para
encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de
aplicación y en la estructura de la base de datos. Por último, en las pruebas se podrá hacer una medida de la
fiabilidad y la calidad del software desarrollado.

11. Mantenimiento
Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora
en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas: •Monitorización de las prestaciones
del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la
base de datos. •Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que
vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de
presentar.

Referencias Bibliográficas “Fundamentos de Sistemas de Bases de Datos”. Ramez A. Elmasri & Shamkant B.
Navathe. Tercera edición. AddisonWesley. 2002