Tecnologías de la Información y la Comunicación

Guía bases de datos Artículo2 Uso de Acces Normalizacion,interrelaciones y algebra relacional

Artículo Técnico

Sugerencias para la normalización de bases de datos

Este artículo se aplica a: Microsoft® Access

Resumen: en este artículo se ofrecen sugerencias para ayudar a los desarrolladores a evitar algunas de las dificultades que surgen al diseñar tablas de Access. Este artículo se refiere a bases de datos de Microsoft Access (.mdb) y proyectos de Microsoft Access (.adp).

Introducción

Uno de los pasos más importantes en el diseño de una base de datos consiste en asegurarse de que los datos se distribuyan correctamente entre las tablas. Si las estructuras de datos son correctas, el resto de la aplicación (las consultas, los formularios, los informes, el código, etc.) se verá simplificada en gran medida. El nombre formal que recibe el diseño apropiado de una tabla es del de normalización de bases de datos.

Este artículo constituye una descripción general de los conceptos básicos sobre la normalización de bases de datos, así como de las dificultades más comunes que se han de tener en cuenta y evitar.

Comprensión de los datos

Antes de avanzar con el diseño de la tabla, es importante que sepa exactamente qué pretende hacer con los datos y cómo cambiarán en el transcurso del tiempo. Las decisiones que tome afectarán al futuro diseño.

¿Qué datos se necesitan?

Al diseñar una aplicación, resulta de vital importancia ser consciente de los resultados finales, para asegurarse de que dispone de todos los datos necesarios y de que conoce su procedencia. Por ejemplo, ¿cuál es la apariencia de los informes?, ¿de dónde viene cada dato? y ¿dispongo de todos los datos? No hay nada más perjudicial para un proyecto que darse cuenta, después de haberlo empezado, que faltan datos relativos a un informe importante.

Una vez que sepa qué datos necesita, debe determinar su procedencia. ¿Se han importado de otro origen? ¿Hay que limpiarlos o comprobarlos? ¿El usuario escribe datos?

El primer paso en el diseño de la base de datos consiste en tener una idea clara de qué datos se necesitan y de cuál es su procedencia.

¿Qué va a hacer con los datos?

¿Los usuarios tendrán que editar los datos? En tal caso, ¿cómo se deben mostrar los datos para que los usuarios puedan comprenderlos y editarlos? ¿Hay reglas de validación y tablas de búsqueda relacionada? ¿Hay cuestiones de auditoría asociadas a la entrada de datos que hagan necesario el mantenimiento de copias de seguridad de las ediciones y eliminaciones? ¿Qué tipo de resumen se debe mostrar al usuario? ¿Debe generar archivos de exportación? Con esta información, podrá hacerse una idea de la relación entre unos campos y otros.

¿De qué modo se relacionan unos datos con otros?

Agrupe los datos en campos relacionados (como la información relacionada con el cliente, la información relacionada con las facturas, etc.). Cada grupo de campos representa futuras tablas. A continuación, debe considerar el modo en que se relacionarán unos con otros. Por ejemplo, ¿qué tablas están relacionadas en una relación de uno a varios (por ejemplo, un cliente puede tener varias facturas)? ¿Qué tablas tienen una relación de uno a uno (a menudo, una consideración para combinar en una tabla)?

¿Qué ocurrirá con los datos al pasar el tiempo?

Con frecuencia, después de diseñar las tablas, el impacto de tiempo deja de tenerse en cuenta, lo que posteriormente puede provocar serios problemas. Muchos diseños de tabla funcionan perfectamente para utilizarlos de forma inmediata. No obstante, muchos se estropean cuando los usuarios modifican los datos, cuando se agregan datos nuevos y conforme va pasando el tiempo. A menudo, los desarrolladores se dan cuenta de que deben reestructurar las tablas para hacer frente a estos cambios. Cuando las estructuras de las tablas cambian, también deben actualizarse todas sus dependencias (consultas, formularios, informes, código, etc.). Si se comprenden y prevén los cambios en el tiempo, se podrá implementar un mejor diseño para minimizar los problemas.

Cómo utilizar las consultas

También es muy importante saber cómo va a analizar y manipular los datos. Debe tener una idea clara de cómo funcionan las consultas, cómo usarlas para vincular datos entre varias tablas, cómo usarlas para agrupar y resumir datos y cómo usar consultas de tabla de referencia cruzada cuando deba mostrar datos en un formato que no esté normalizado.

El fin último de un buen diseño de datos consiste en sopesar las necesidades de almacenar los datos de forma eficaz en el tiempo frente a su fácil recuperación y análisis. Si es consciente del potencial de las consultas, le resultará mucho más fácil diseñar las tablas correctamente.

Conceptos de normalización de bases de datos

Más que una discusión teórica sobre la normalización de bases de datos, este apartado constituye una explicación de conceptos básicos relacionados con la normalización de bases de datos. El modo en que dichos conceptos se apliquen en una situación dada puede variar en función de las necesidades de la aplicación. El objetivo es comprender estos conceptos básicos, aplicarlos cuando sea factible y comprender los problemas que surgen si no se tienen en cuenta.

Almacenamiento de información exclusiva en un lugar

La mayoría de los desarrolladores de bases de datos entienden el concepto básico de la normalización de datos. La situación ideal sería almacenar los mismos datos en un lugar y hacer referencia a ellos con un Id. cuando lo necesite. Por lo tanto, si hay cambios en la información, tendrá que cambiarla sólo en un sitio, ya que el cambio se reflejará por toda la aplicación.

Por ejemplo, una tabla de clientes, podría almacenar un registro por cada cliente, en el que se incluirían su nombre, dirección, números de teléfono, dirección de correo electrónico y otros datos. Esta tabla tendría un campo CustomerID exclusivo (normalmente, un campo Autonumérico) que actúa de campo de clave y que otras tablas utilizan para hacer referencia al cliente. Por lo tanto, una tabla de facturas, en lugar de almacenar toda la información del cliente con cada factura (ya que un mismo cliente pude tener varias facturas), haría referencia simplemente al valor del Id. del cliente, que se podría utilizar para buscar los detalles del cliente en la tabla de clientes. Access facilita en gran medida este proceso, gracias a sus completos formularios, que utilizan subformularios y cuadros combinados. Si necesita realizar un cambio en la información del cliente (como, por ejemplo, el número de teléfono), puede cambiarla en la tabla de clientes y estar seguro de que todas las partes de la aplicación en las que se haga referencia a esa información se actualizarán automáticamente.

Con una base de datos bien normalizada, un simple clic sirve para administrar los cambios efectuados en los datos a lo largo del tiempo. A menudo, las bases de datos que no están bien normalizadas incluyen programación o consultas para realizar cambios en varios registros o tablas. Esto no sólo requiere más trabajo, sino que también aumenta las posibilidades de que los datos sean incoherentes, si el código o las consultas no se ejecutan correctamente.

Los registros son gratis, los campos nuevos son caros

Las bases de datos se deben diseñar de forma que lo único que haya que hacer conforme pasa el tiempo sea agregar nuevos registros. Las tablas de las bases de datos están diseñadas para alojar números ingentes de registros. No obstante, si se da cuenta de que debe agregar más campos, puede que tenga un problema de diseño.

Esto suele suceder con expertos en hojas de cálculo, que suelen diseñar bases de datos del mismo modo en que acostumbran a diseñar hojas de cálculo. El diseño de campos sujetos a limitaciones temporales (como, por ejemplo, Año, Trimestre, Producto y Vendedor) hace que sea necesario agregar nuevos campos en el futuro. Pero el diseño correcto consiste en transponer la información y tener los datos sujetos a limitaciones temporales en un solo campo, de forma que se puedan agregar más registros. Por ejemplo, en lugar de crear un campo distinto para cada año, cree un campo Año y escriba el valor de año de cada registro en ese campo.

La razón por la que resulta problemático agregar campos adicionales es el impacto que tiene realizar cambios estructurales en las tablas sobre otras partes de la aplicación. Cuando se agregan campos a una tabla, los objetos y el código que dependen de la tabla también deben actualizarse. Por ejemplo, las consultas deben abarcar los campos extra, los formularios deben mostrarlos, los informes deben incluirlos, etc. Sin embargo, si los datos estuvieran normalizados, los objetos existentes recuperarían automáticamente los nuevos datos y los calcularían o mostrarían correctamente. Las consultas son especialmente eficaces, ya que permiten centrarse en el campo Año para mostrar resúmenes por año, independientemente de qué años haya en la tabla.

No obstante, la normalización de datos no significa que no se puedan mostrar o utilizar datos con campos sujetos o dependientes de limitaciones temporales. Los desarrolladores que deban mostrar tal información pueden hacerlo mediante consultas de tabla de referencias cruzadas. Si desconoce el uso de estas consultas, es recomendable que aprenda a utilizarlas. No son lo mismo que las tablas (en concreto, los resultados de una consulta de tabla de referencias cruzadas no se pueden editar), pero sí pueden usarse para mostrar información en una hoja de datos (de hasta 255 campos). Si desea utilizarla en informes, resulta más complicado, ya que el informe tendrá que ajustarse a los nombres de campo adicionales o que cambien. Esa es la razón de que, en la mayoría de los informes, los datos se muestren como agrupaciones aparte dentro del informe, en lugar de como columnas aparte. En los casos en los que no tenga otra elección, tendrá que invertir tiempo para poder hacer esto, pero seguramente todas las partes implicadas entenderán la implicación que estas decisiones tienen sobre los recursos adicionales con el transcurso del tiempo.

En definitiva, este es el motivo de que los registros adicionales sean gratis (la gran ventaja de las bases de datos) y los campos adicionales sean tan caros. Las bases de datos se pueden ajustar a enormes cantidades de cambios, si están diseñadas correctamente.

Cuándo deben duplicarse los datos

A veces, es necesario deshacer la normalización de los datos para conservar información que puede cambiar con el paso del tiempo.

En el sencillo ejemplo anterior de una factura vinculada a un cliente mediante un número de Id. de cliente, puede que deseemos conservar la dirección del cliente en el momento en que se emitió la factura (no en el momento de su creación, ya que la información del cliente puede cambiar entre los dos eventos). Si no conservamos la dirección en el momento en que se emitió la factura y tuvimos que actualizar la información del cliente después de dicha emisión, tal vez no podamos confirmar la dirección exacta a la que se envió la factura. Esto podría causar un enorme problema empresarial. Por supuesto, hay ciertos tipos de información, como el número de teléfono del cliente, que no es imprescindible conservar. Por lo tanto, se debe determinar de forma selectiva qué datos hay que duplicar.

Otro ejemplo en el que los datos deben duplicarse es al rellenar los artículos de línea de una factura. A menudo, se utiliza una lista de precios para elegir los artículos que ha pedido el cliente. Se podría simplemente almacenar el Id. de la lista de precios para que apunte a la lista de precios con la descripción, el precio y otros detalles del producto. Sin embargo, las descripciones y precios de los productos cambian al paso del tiempo. Si no copia los datos de la lista de precios en la tabla de artículos de línea, no podrá volver a imprimir con precisión la factura original en el futuro, lo que puede constituir un enorme problema si aún no ha recibido el importe de la factura.

Por lo tanto, aunque la normalización resulta apropiada para guardar los mismos datos en un sitio y, además, simplifica la edición, hay situaciones en las que no se desea disponer de esas ventajas. Si necesita una instantánea de los datos por motivos de historial, es muy importante que lo implemente en el diseño de la base de datos desde el principio. Si no es así, una vez que los datos se sobrescriban, no se podrán recuperar.

Uso de un campo sin significado en el campo de clave

Por motivos de eficacia, cada tabla debe tener un campo de clave. El campo de clave define la exclusividad en la tabla; los índices lo utilizan en los otros campos para mejorar el rendimiento de las búsquedas. Por ejemplo, la tabla de clientes podría tener un campo CustomerID que definiera un número exclusivo para cada cliente. En esta discusión, se habla de tablas que tienen varios campos y no de simples consultas en tablas sencillas, como, por ejemplo, una lista de países.

En general, un campo de clave debe tener las siguientes características:

§                     Debe ser un solo campo
Se pueden definir varios campos como campos de clave de una tabla, pero es preferible que sólo haya un único campo. En primer lugar, si son necesarios varios campos para definir la exclusividad, se precisa de más espacio para almacenar la clave. En segundo lugar, los índices adicionales de la tabla también tienen que usar la combinación de los campos de clave, lo que ocupa más espacio que si se tratara de un único campo. Por último, la identificación de registros en la tabla requiere abarcar una combinación de campos. Es mucho mejor tener un campo CustomerID que una combinación de otros campos para definir un cliente. 

§                     Debe ser numérico
Access ofrece un tipo de campo Autonumérico que es un Entero largo, lo que resulta ideal para los campos de clave. Estos valores se convierten automáticamente en exclusivos para cada campo y, además, admiten la entrada de datos por parte de varios usuarios. 

§                     No debe cambiar con el tiempo
Los campos de clave no deben cambiar con el tiempo. Al igual que un número de la seguridad social, una vez identificados, nunca deben cambiar. Un campo de clave que cambie dificulta en gran medida el uso de datos históricos, ya que los vínculos se rompen. 

§                     Debe ser sin significado
Para garantizar que un campo de clave no cambie con el tiempo, éste no debe tener ningún significado. Los valores de clave sin significado también resultan útiles en situaciones en las que el resto de datos están incompletos. Por ejemplo, puede asignar un número de cliente sin disponer de la dirección completa de esa persona. El resto de la aplicación puede funcionar perfectamente, y podrá agregar la información cuando la reciba. Si, como parte de la clave, la tabla ha utilizado el país o cualquier otro campo de identificación del que no disponía, correrá el riesgo de no poder utilizar la aplicación.

Así pues, por todas las razones expuestas, es recomendable utilizar un campo Autonumérico como campo de clave para la mayoría de las tablas. Mediante el uso de cuadros combinados y columnas ocultas, puede vincular campos al campo Autonumérico y ocultarlo de la vista del usuario.

Uso de la integridad referencial

Una vez que las tablas estén definidas y sepa el modo en que se relacionan unas con otras, asegúrese de agregar integridad referencial para reforzar la relación. Esto evita que los campos vinculados se modifiquen incorrectamente y que se dejen registros "huérfanos". El motor de bases de datos Microsoft Jet admite una sofisticada integridad referencial, que permite disponer de actualizaciones y eliminaciones en cascada. En general, el campo Id. no se debe cambiar. Por lo tanto, las actualizaciones en cascada carecen de importancia, pero las eliminaciones en cascada pueden resultar muy útiles.

Por ejemplo, si tiene una tabla de facturas relacionada con una tabla de pedidos en la que una factura puede tener un número ilimitado de pedidos (artículos de línea) y cada registro contiene el número de factura al que está vinculado, las eliminaciones en cascada permitirán eliminar el registro de factura y, automáticamente, eliminar todos los registros de pedido correspondientes. Así se asegura de no tener nunca un registro de pedido sin su correspondiente registro de factura.

Conclusión

Esperamos que pueda aplicar estos conceptos de diseño de bases de datos en una fase temprana del diseño de la aplicación, con el fin de minimizar los problemas y las soluciones necesarias cuando no se implementa este tipo de diseño. ¡Suerte!