CONSIDERACIONES DEL DISEÑO DE UNA BASE DE DATOS

El diseñador de base de datos es responsable de definir el diseño detallado de la base de datos, incluyendo tablas, índices, vistas, restricciones, desencadenantes, procedimientos almacenados y otras construcciones específicas de la base de datos necesarias para almacenar, recuperar y suprimir objetos persistentes

Un buen diseño de base de datos es, por tanto, aquel que:

• Divide la información en tablas basadas en temas para reducir los datos redundantes.

• Proporciona a Access la información necesaria para unir la información en las tablas según sea necesario.

• Ayuda a respaldar y garantizar la precisión y la integridad de la información.

• Se ajusta a sus necesidades de informes y procesamiento de datos.

El proceso de diseño

El proceso de diseño consta de los siguientes pasos:

• Determinar el propósito de la base de datos    

  Esto le ayudará a prepararse para los pasos restantes.

• Buscar y organizar la información necesaria   

  Recopile todos los tipos de información que podría querer registrar en la base de datos, como los nombres de producto y los números de pedido.

• Dividir la información en tablas    

  Divida los elementos de información en entidades principales o temas, como Productos o Clientes. Después, cada tema se convierte en una tabla.

• Convertir los elementos de información en columnas    

  Decida qué información quiere almacenar en cada tabla. Cada elemento se convierte en un campo y se muestra como una columna en la tabla. Por ejemplo, una tabla de empleados podría incluir campos como Apellidos y Fecha de contratación.

• Especificar las claves principales    

  Elija la clave principal de cada tabla. La clave principal es una columna que se usa para identificar cada fila. Un ejemplo podría ser Id. de producto o Id. de pedido.

• Establecer las relaciones de tablas    

  Busque en cada tabla y decida cómo se relacionan los datos en una tabla con los datos de otras tablas. Agregue campos a las tablas o cree tablas para aclarar las relaciones, según sea necesario.

• Perfeccionar el diseño    

  Analice el diseño en busca de errores. Cree las tablas y agregue unos cuantos registros de datos de ejemplo. Compruebe si puede obtener los resultados que quiere de las tablas. Haga algunos ajustes en el diseño, si es necesario.

• Aplicar las reglas de normalización    

  Aplique las reglas de normalización de datos para ver si las tablas están estructuradas correctamente. Haga algunos ajustes en las tablas, si es necesario.

Determinar el propósito de la base de datos

Es una buena idea anotar el propósito de la base de datos en un papel: su propósito, cómo espera usarla y quién la usará. Por ejemplo, para una base de datos pequeña para un negocio familiar, escriba algo como: "La base de datos de clientes es una lista con información de los clientes cuya finalidad es el envío de correo y la creación de informes". Si la base de datos es más compleja o la usan muchas personas, como ocurre normalmente en un entorno corporativo, el propósito podría constar fácilmente de uno o varios párrafos, y debería incluir cuándo y cómo cada persona usará la base de datos. La idea es tener una declaración de objetivos bien desarrollada a la que se pueda hacer referencia en todo el proceso de diseño. Tener ese resumen le ayuda a centrarse en sus objetivos cuando tome decisiones.

Buscar y organizar la información necesaria

Para buscar y organizar la información necesaria, empiece con la información existente. Por ejemplo, podría registrar los pedidos de compra en un libro de contabilidad o guardar la información de los clientes en formularios de papel en un archivo. Recopile dichos documentos y enumere cada tipo de información que se muestra (por ejemplo, cada cuadro que rellene en un formulario). Si no tiene ningún formulario existente, imagine en su lugar que tiene que diseñar un formulario para registrar la información del cliente. ¿Qué información incluiría en el formulario? ¿Qué cuadros de relleno crearía? Identifique y enumere cada uno de estos elementos. Por ejemplo, suponga que actualmente guarda la lista de clientes en las tarjetas de índice. Al examinar dichas tarjetas podría revelar que cada una contiene un nombre de cliente, dirección, ciudad, estado, código postal y número de teléfono. Cada uno de estos elementos representa una posible columna en una tabla.

Después, tenga en cuenta los tipos de informes o correspondencia que podría querer crear a partir de la base de datos. Por ejemplo, puede que quiera un informe de ventas de un producto para mostrar las ventas por región o un informe de resumen de inventario que muestre los niveles de inventario del producto. También es posible que quiera generar cartas modelo para enviar a los clientes que anuncien un evento de venta u ofrezcan una mejora. Diseñe el informe en su mente y luego imagine su aspecto. ¿Qué información incluiría en el informe? Enumere todos los elementos. Haga lo mismo para la carta modelo y para cualquier otro informe que tenga previsto crear.

Pararse a pensar en los informes y correspondencia que podría querer crear le ayudará a identificar los elementos que necesitará en la base de datos. Por ejemplo, suponga que los clientes tienen la posibilidad de darse de alta (o de baja) de las novedades enviadas periódicamente por correo electrónico, y que quiere imprimir una lista de los usuarios que se han dado de alta. Para registrar esa información, agrega una columna "Enviar correo electrónico" a la tabla de clientes. Para cada cliente, puede establecer el campo en Sí o No.

El requisito de enviar mensajes de correo a los clientes sugiere otro elemento del registro. Una vez que sepa que un cliente quiere recibir mensajes de correo, también deberá saber la dirección de correo electrónico a la que enviárselos. Por tanto, necesita registrar una dirección de correo electrónico para cada cliente.

Dividir la información en tablas

Para dividir la información en tablas, elija las entidades principales, o asuntos. Por ejemplo, después de encontrar y organizar la información para una base de datos de ventas de un producto, la lista preliminar podría ser similar a la siguiente:

Las principales entidades que se muestran aquí son los productos, los proveedores, los clientes y los pedidos. Por tanto, tiene sentido comenzar con estas cuatro tablas: una para los datos sobre productos, otra para datos sobre proveedores, otra para los datos sobre clientes y otra para los datos sobre pedidos. Aunque la lista no está completa con ellas, es un buen punto de partida. Puede seguir ajustando la lista hasta que tenga un diseño que funcione bien.

Cuando revise por primera vez la lista preliminar de elementos, es posible que esté tentado a incluirlos en una sola tabla, en lugar de las cuatro que se muestran en la ilustración anterior. A continuación obtendrá información sobre por qué es una mala idea. Considere por un momento la tabla que se muestra aquí:

En este caso, cada fila contiene información sobre el producto y su proveedor. Dado que un mismo proveedor puede suministrarle una gran cantidad de productos, el nombre y la dirección de ese proveedor tendrán que repetirse muchas veces. Esto supone un desperdicio de espacio en disco. Registrar la información del proveedor una sola vez en una tabla independiente para los proveedores y vincular esa tabla a la de productos es una solución mucho mejor.

Un segundo problema con este diseño surge cuando es necesario modificar la información sobre el proveedor. Por ejemplo, supongamos que necesita cambiar la dirección de un proveedor. Al aparecer en varios lugares, accidentalmente podría cambiar la dirección en un solo lugar y olvidarse de cambiarla también en los demás. Si registra la información del proveedor en un único lugar, se evitará el problema.

Al diseñar la base de datos, intente siempre registrar cada hecho una sola vez. Si se encuentra repitiendo la misma información en más de un lugar, como la dirección de un determinado proveedor, coloque dicha información en una tabla aparte.

Una vez que haya elegido el tema representado por una tabla, las columnas de dicha tabla solo deberían almacenar datos sobre el tema. Por ejemplo, la tabla de productos debería almacenar únicamente datos sobre los productos. Dado que la dirección del proveedor es un dato del proveedor y no un hecho sobre el producto, esta pertenece a la tabla de proveedores.

Convertir los elementos de información en columnas

Para determinar las columnas de una tabla, decida cuál es la información de la que necesita realizar un seguimiento sobre el tema registrado en la tabla. Por ejemplo, para la tabla Clientes, una buena lista inicial de columnas contendría Nombre, Dirección, Ciudad-Provincia-Código postal, Enviar correo electrónico, Saludo y Dirección de correo electrónico. Cada registro de la tabla contiene el mismo conjunto de columnas, por lo que puede almacenar la información de Nombre, Dirección, Ciudad-Provincia-Código postal, Enviar correo electrónico, Saludo y Dirección de correo electrónico para cada registro. Por ejemplo, la columna de dirección contiene las direcciones de los clientes. Cada registro contiene datos sobre un cliente, y el campo dirección contiene la dirección de dicho cliente.

Una vez que haya determinado el conjunto inicial de columnas para cada tabla, podrá refinar aún más las columnas.

También debería tener en cuenta si la base de datos contiene información solo de origen nacional o también internacional. Por ejemplo, si va a almacenar direcciones internacionales, es mejor tener una columna Región en lugar de Estado, ya que esa columna puede incluir tanto estados internos como regiones de otros países o regiones. De forma similar, Código postal tiene más sentido que código ZIP si va a almacenar direcciones internacionales.

En la lista siguiente se muestran algunas sugerencias para determinar las columnas.

• No incluya datos calculados    

  En la mayoría de los casos, no se debe almacenar el resultado de los cálculos en las tablas. En su lugar, puede hacer que Access realice los cálculos cuando quiera ver el resultado. Por ejemplo, suponga que hay un informe de Productos en pedidos que muestra el subtotal de unidades en pedidos para cada categoría de producto en la base de datos. Pero no hay ninguna columna de subtotal de Unidades en pedidos en ninguna tabla. En su lugar, la tabla Productos incluye una columna Unidades en pedidos que almacena las unidades en pedidos para cada producto. Con esos datos, Access calcula el subtotal cada vez que imprima el informe. El subtotal en sí no debería almacenarse en una tabla.

• Almacene la información en sus partes lógicas más pequeñas    

  Es posible que se vea tentado a tener un único campo de nombres completos o de nombres de producto junto con las descripciones del producto. Si combina más de un tipo de información en un campo, más adelante le será difícil recuperar datos individuales. Intente dividir la información en partes lógicas. Por ejemplo, cree campos independientes para nombre y apellidos, o para la descripción, categoría y nombre del producto.

Una vez ajustadas las columnas de datos de las tablas, ya puede elegir la clave principal de cada tabla.

Especificar las claves principales

Cada tabla debe incluir una columna (o conjunto de columnas) que identifique exclusivamente cada fila almacenada en la tabla. Esto suele ser un número de identificación único, como un número de identificación de empleado o un número de serie. En la terminología de base de datos, esta información se denomina la clave principal de la tabla. Access usa los campos de clave principal para asociar rápidamente los datos de varias tablas y agrupar esos datos.

Si ya tiene un identificador único para una tabla, como un número de producto que identifica exclusivamente a cada producto en el catálogo, puede usar ese identificador como clave principal de la tabla, pero solo si los valores de esta columna serán siempre diferentes para cada registro. No puede tener valores duplicados en una clave principal. Por ejemplo, no use nombres de personas como clave principal, porque los nombres no son únicos. Es muy fácil que dos personas tengan el mismo nombre en una misma tabla.

Una clave principal siempre debe tener un valor. Si en algún momento el valor de una columna puede quedar sin asignar o ser desconocido (un valor que falta), no se puede usar como un componente de una clave principal.

Siempre debe elegir una clave principal cuyo valor no cambiará. En una base de datos que use más de una tabla, la clave principal de una tabla puede usarse como referencia en otras tablas. Si se cambia la clave principal, el cambio también se debe aplicar en todas partes en las que se hace referencia a la clave. Usar una clave principal que no cambia reduce la posibilidad de que no se sincronice con otras tablas que hacen referencia a ella.

1. Una columna establecida en el tipo de datos Autonumeración suele ser una buena clave principal. No hay dos identificadores de producto iguales.

En algunos casos, tal vez quiera usar dos o más campos que, juntos, proporcionan la clave principal de una tabla. Por ejemplo, una tabla de detalles de pedido que almacena datos de pedidos usaría dos columnas en su clave principal: Identificador de pedido e Identificador de producto. Cuando una clave principal está formada por más de una columna, también se denomina una clave compuesta.

Para la base de datos de ventas de productos, puede crear una columna Autonumeración para cada una de las tablas para que sirvan de clave principal: Id. de producto para la tabla Productos, Id. de pedido para la tabla Pedidos, Id. de cliente para la tabla Clientes e Id. de proveedor para la tabla Proveedores.

Crear las relaciones de tablas

Ahora que ha dividido la información en tablas, necesita una manera para volver a unir la información de forma que tenga significado. Por ejemplo, el siguiente formulario incluye información de varias tablas.

1. La información de este formulario procede de la tabla Clientes...

2. ...la tabla Empleados...

3. ...la tabla Pedidos...

4. ...la tabla Productos...

5. ... y la tabla Detalles de pedidos.

Access es un sistema de administración de base de datos relacional. En una base de datos relacional, se divide la información en tablas separadas, basadas en el temas. Después, se usan las relaciones de la tabla para combinar la información según sea necesario.

Crear una relación uno a uno

Otro tipo de relación es la relación de uno a uno. Por ejemplo, supongamos que necesita registrar información adicional sobre productos que casi nunca necesitará o que solo se aplica a unos pocos productos. Puesto que no necesita la información con frecuencia, y que almacenar la información de la tabla Productos daría como resultado un hueco en todos los productos a los que no se aplica, la coloca en una tabla aparte. Al igual que la tabla Productos, puede usar el Id. de producto como clave principal. La relación entre esta tabla y la tabla Productos es una relación de uno a uno. Para cada registro de la tabla Producto, existe un único registro coincidente en la tabla complementaria. Cuando se identifica este tipo de relación, ambas tablas deben compartir un campo común.

Al detectar la necesidad de una relación de uno a uno en la base de datos, tenga en cuenta si se puede combinar la información de las dos tablas en una sola. Si por algún motivo no quiere hacerlo, quizás porque se crearía una gran cantidad de huecos, la siguiente lista le muestra cómo puede representar la relación en su diseño:

• Si las dos tablas tienen el mismo tema, probablemente pueda configurar la relación usando la misma clave principal en ambas tablas.

• Si las dos tablas tienen diferentes temas con diferentes claves principales, elija una de las tablas (cualquiera de ellas) e inserte la clave principal de la otra tabla como clave externa.

Determinar las relaciones entre tablas le ayuda a asegurarse de que tiene las tablas y columnas correctas. Cuando existe una relación de uno a uno o uno a varios, las tablas relacionadas tienen que compartir una o varias columnas comunes. Cuando existe una relación varios a varios, se necesita una tercera tabla para representar la relación.

Refinar el diseño

Una vez que tiene las tablas, campos y relaciones que necesita, debería crear y rellenar las tablas con datos de ejemplo e intentar trabajar con la información: creando consultas, agregando nuevos registros, etc. Esto le permitirá resaltar los posibles problemas. Por ejemplo, tal vez deba agregar una columna que olvidó insertar durante la fase de diseño, y es posible que tenga una tabla que debería dividir en dos tablas para eliminar los datos duplicados.

Vea si puede usar la base de datos para obtener las respuestas que quiere. Cree bocetos de los formularios e informes y compruebe si muestran los datos que espera. Busque duplicaciones de datos innecesarias y, si encuentra alguna, modifique el diseño para eliminarla.

Crear una relación uno a varios

Considere este ejemplo: las tablas Proveedores y Productos en la base de datos de pedidos de productos. Un proveedor puede proporcionar cualquier cantidad de productos. Se puede decir que, para cualquier proveedor que se representa en la tabla Proveedores, puede haber muchos productos que se representan en la tabla Productos. La relación entre la tabla Proveedores y la tabla Productos es, por tanto, una relación uno a varios.

Para representar una relación uno a varios en el diseño de la base de datos, tome la clave principal del lado "uno" de la relación y agréguela como columna o columnas adicionales a la tabla en el lado "varios" de la relación. En este caso, por ejemplo, agregaría la columna Id. de proveedor de la tabla Proveedores a la tabla Productos. Así, Access puede usar el número de identificador del proveedor de la tabla Productos para dar con el proveedor correcto de cada producto.

La columna Id. de proveedor en la tabla Productos se denomina una clave externa. Una clave externa es la clave principal de otra tabla. La columna Id. de proveedor en la tabla Productos es una clave externa porque también es la clave principal en la tabla Proveedores.

Al establecer parejas de claves principales y claves externas, proporciona la base para unir las tablas relacionadas. Si no está seguro de qué tablas deberían compartir una columna común, identificar una relación uno a varios asegura que, en efecto, las dos tablas relacionadas requerirán una columna compartida.

Crear una relación de varios a varios

Considere la relación entre la tabla Productos y la tabla Pedidos.

Un solo pedido puede incluir varios productos. Por otra parte, un único producto puede aparecer en muchos pedidos. Por tanto, por cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos. Además, por cada registro de la tabla Productos puede haber varios registros en la tabla Pedidos. Este tipo de relación se denomina relación de varios a varios, porque, para cada producto, puede haber varios pedidos, y para cada pedido puede haber muchos productos. Tenga en cuenta que para detectar las relaciones de varios a varios entre las tablas, es importante que considere ambas partes de la relación.

Entre los temas de las dos tablas, productos y pedidos, existe una relación de varios a varios. Esto supone un problema. Para entender el problema, imagine qué pasaría si intentase crear la relación entre las dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para tener más de un producto por pedido, necesita más de un registro por pedido en la tabla Pedidos. Tendría que repetir la información del pedido en cada fila que esté relacionada con un único pedido, lo que provocaría un diseño ineficaz que podría producir datos inexactos

La respuesta es crear una tercera tabla, a menudo denominada tabla de unión, que divida la relación de varios a varios en dos relaciones uno a varios. Inserte la clave principal de cada una de las dos tablas en la tercera tabla. Como resultado, la tercera tabla registra cada repetición o instancia de la relación.

Cada registro de la tabla Detalles de pedidos representa un elemento de línea en un pedido. La clave principal de la tabla Detalles de pedidos consta de dos campos: las claves externas de las tablas Pedidos y Productos. Usar el campo de Id. de pedido por sí solo no sirve como clave principal para esta tabla, porque un pedido puede tener muchos elementos de línea. El Id. de pedido se repite para cada elemento de línea en un pedido, por lo que el campo no contiene valores únicos. Usar el campo de Id. de producto por sí solo tampoco sirve, porque un producto puede aparecer en varios pedidos diferentes. Pero juntos, los dos campos siempre generan un valor único para cada registro.

En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no están directamente relacionadas entre sí. En su lugar, están relacionadas indirectamente a través de la tabla Detalles de pedidos. La relación de varios a varios entre productos y pedidos se representa en la base de datos mediante dos relaciones de uno a varios:

• La tabla Pedidos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada pedido puede tener más de un elemento de línea, pero cada elemento de línea está conectado a un único pedido.

• La tabla Productos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada producto puede tener muchos elementos de línea asociados a él, pero cada elemento de línea se refiere a un solo producto.

En la tabla Detalles de pedido, puede determinar todos los productos en un pedido determinado. También puede determinar todos los pedidos de un producto en particular.

Después de incorporar la tabla Detalles de pedido, la lista de tablas y campos podría tener un aspecto similar a este: