Normalización de datos

Visual Studio .NET 2003

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 normalización no sólo es aplicable a archivos relacionales; también es una actividad de diseño común para archivos indizados.

Es un proceso complejo formado por muchas reglas específicas y distintos niveles de intensidad. La definición completa de normalización es el proceso de descartar la repetición de grupos, minimizar la redundancia, eliminar claves compuestas para la dependencia parcial y separar los atributos que no sean de la clave. En términos generales, las reglas de normalización se pueden resumir en una sola frase: "Cada atributo (columna) debe ser una realidad de la clave, toda la clave y nada más que la clave". Cada tabla debe describir sólo un tipo de entidad (como una persona, un lugar, un pedido de cliente o un producto).

A continuación se enumeran algunas de las ventajas de la normalización:

  • Integridad de datos (porque no hay datos redundantes ni omitidos).
  • Consultas optimizadas (porque las tablas normalizadas generan combinaciones eficaces y rápidas).
  • Creación y ordenación de índices más rápidas (porque las tablas tienen menos columnas).
  • Ejecución más rápida de la instrucción UPDATE (porque hay menos índices por tabla).
  • Resolución de concurrencias mejorada (porque los bloqueos de tabla afectarán a menos datos).

La mayoría de las bases de datos simples se puede normalizar siguiendo una simple regla empírica: las tablas que contienen información repetida deben dividirse en tablas independientes para eliminar la duplicación.

Por ejemplo, puede crear una nueva aplicación para un librero que realice un seguimiento de cada libro, e incluya los datos siguientes.

  • Nombre del autor.
  • Dirección del autor.
  • Número de teléfono del autor.
  • Título.
  • Número ISBN.
  • Año de publicación.
  • Nombre de la editorial.
  • Dirección de la editorial.
  • Número de teléfono de la editorial.

Es posible crear una única tabla con un campo para cada uno de los elementos de información enumerados anteriormente. No obstante, si se examinan los datos detenidamente, es evidente que una tabla con estas características contendría numerosas redundancias. Por ejemplo, como lo normal es que muchos autores hayan escrito más de un libro, la información correspondiente al autor y a la editorial de cada libro se repetiría muchas veces. Si todos estos campos se colocan en una única tabla habrá muchas entradas duplicadas y confusas.

Sin embargo, de acuerdo con los principios de la normalización, los datos se podrían dividir en cuatro grupos: Authors, AuthorsTitles, Titles y Publishers, tal y como se muestra en la siguiente tabla.

Tabla Authors Tabla AuthorsTitles Tabla Titles Tabla Publishers
id_au (clave) id_au (clave externa) isbn_ti (clave) id_edit (clave)
nombre_au isbn_ti (clave externa) título_ti nombre_edit
dirección_au   añopublic_ti dir_edit
teléfono_au   id_edit (clave externa) teléfono_edit

Las claves proporcionan una forma de establecer relaciones entre tablas. Por ejemplo, la tabla AuthorsTitles crea una relación varios a varios entre las tablas Authors y Titles (un autor puede haber escrito muchos libros y un libro puede haber sido escrito por varios autores). Con la tabla AuthorsTitles, se pueden realizar consultas de los números de libros escritos por un autor (utilizando id_au), así como determinar qué autor o autores han escrito un libro determinado (utilizando isbn_ti).

Conviene señalar que, en lugar de crear la tabla AuthorsTitles, otra alternativa sería agregar el atributo id_au en la tabla Titles, pero esta opción sólo es viable en el supuesto de que cada libro tenga un único autor. Observemos con más detenimiento otra interpretación: la colocación del atributo id_edit en la tabla Titles sugiere que cada título pertenece a una sola editorial. Si varias editoriales publican el mismo título, la inserción de más filas Título en la tabla Titles para cada editorial daría lugar a una duplicación de datos y, por lo tanto, la tabla no estaría normalizada. Estas alternativas de diseño requieren una evaluación minuciosa de los puntos siguientes: significado de los datos de empresa, tipos de consultas previstos en la aplicación, posibles conflictos durante el uso simultáneo de varios usuarios y posibles problemas de rendimiento derivados de la existencia de muchos índices en una tabla.

Si se evalúa la normalización de otras alternativas de diseño, es conveniente conocer la existencia de diversas técnicas que se pueden utilizar para desnormalizar una base de datos de forma intencionada. ¿Cuándo se puede dar este caso?. Podría desnormalizar los datos intencionadamente en el caso de que se detectasen problemas de rendimiento o, simplemente, desease simplificar el proceso de generación de informes apropiados. Los problemas de rendimiento se derivan de las consultas de producción que requieren combinaciones con un uso intensivo del disco y de gran lentitud. El proceso de generación de informes con fines específicos consiste en la realización de consultas no estructuradas por parte de los usuarios finales; puede que estos usuarios no tengan la formación adecuada y tengan inseguridad a la hora de obtener información de varias tablas relacionadas.

Las técnicas de desnormalización existentes consisten en duplicar datos, proporcionar información de resumen, dividir tablas en particiones horizontales o verticales y crear vistas sin normalizar para simplificar el proceso de generación de informes; una alternativa inteligente que permite dejar intacta la base de datos normalizada.

Un ejemplo de desnormalización sería el caso de las direcciones de los clientes. Una tabla de clientes suele incluir estos atributos: nombre, calle, ciudad, estado y código postal. Bien es cierto que la ciudad y el estado se pueden deducir a partir del código postal, por lo tanto, se podría normalizar la tabla de clientes eliminando la ciudad y el estado de los datos de cada cliente; sin embargo, es una práctica común dejar la dirección sin normalizar.

Hay varias razones que justifican esta acción:

  • Las direcciones se utilizan en muchos lugares (consultas, informes, sobres, pantallas de servicio al cliente), y la desnormalización evita que se tenga que agregar en la aplicación una gran cantidad de código para reconstruir las direcciones.
  • Las consultas basadas en la dirección utilizan una sintaxis SQL mucho más sencilla.
  • Los errores en las direcciones se limitan a clientes individuales.

Para obtener más información sobre la normalización de datos, vea la documentación del servidor de base de datos. Si utiliza Microsoft SQL Server, vea "Normalization" en Libros en pantalla de SQL Server.

Vea también

Integridad de datos | Diseño de bases de datos lógicas |

Mostrar: