Organizar los requisitos en tablas

Determinar las tablas en la base de datos puede ser el paso más difícil en el proceso de diseño de la base de datos. Se debe a que los resultados que se esperan de la base de datos (los informes que desea imprimir, los formularios que desea utilizar, las preguntas que desea responder) no son necesariamente pistas sobre la estructura de las tablas que los producen. Esta información indica lo que se desea saber, pero no cómo clasificar la información en tablas.

Como ejemplo, vea el formulario de pedidos de Análisis de los requisitos de datos. En él se incluyen datos sobre el cliente (su dirección y su número de teléfono) junto con datos sobre el pedido. Este formulario le proporciona un número de datos que sabe que deben almacenarse en la base de datos. Aunque todos los datos se incluyen en un mismo formulario, puede evitar fácilmente que la integridad de los datos se vea afectada si los almacena en tablas separadas.

Almacenar la información una sola vez reduce las posibilidades de error   Por ejemplo, si sólo usa una tabla para almacenar la información para un formulario de pedido, suponga que un cliente realiza tres pedidos diferentes. Podría agregar la dirección del cliente y el número de teléfono a su base de datos tres veces, una para cada pedido. Pero esto multiplica la posibilidad de errores de entrada de datos.

La tabla Customer almacena la información de dirección una sola vez.

Además, si el cliente cambia de domicilio, deberá aceptar información contradictoria o bien buscar y modificar cada uno de los registros de ventas del cliente en la tabla. Resulta mucho mejor crear una tabla Customer que almacene la dirección del cliente una sola ** vez en la base de datos. Así, si es necesario modificar los datos, sólo se hará una vez.

Evitar la eliminación de información valiosa   Suponga que un nuevo cliente realiza un pedido y que posteriormente lo cancela. Al eliminar el pedido de la tabla que contiene información de clientes y pedidos a la vez, se eliminaría también el nombre del cliente y su dirección. Sin embargo, es conveniente mantener a este nuevo cliente en la base de datos para poder enviarle el siguiente catálogo. Una vez más, es mejor conservar la información sobre el cliente en una tabla Customer aparte. De esta forma se puede eliminar el pedido sin perder la información del cliente.

Estudie la información que desee obtener de la base de datos y divídala en temas fundamentales que desee mantener, como por ejemplo clientes, empleados, productos que usted vende, servicios ofrecidos, etc. Cada uno de estos temas es un candidato para una tabla independiente.

Sugerencia   Una estrategia para dividir la información en tablas es observar primero los datos individuales y determinar de qué trata cada uno. Por ejemplo, en el formulario de pedidos de Comercial Tasmania, la dirección del cliente no está asociada a la venta, sino al cliente. Este hecho sugiere la necesidad de una tabla independiente para los clientes. En el informe de productos pedidos, el número de teléfono del proveedor no está asociado al producto en existencias, sino al proveedor. Esto sugiere que es necesaria una tabla independiente para los proveedores.

Ejemplo:

El formulario de pedidos y el informe de productos pedidos de Comercial Tasmania contienen información sobre los temas siguientes:

• Empleados
• Clientes
• Proveedores
• Productos
• Pedidos

A partir de esta lista, puede esbozar un borrador de las tablas de la base de datos, así como apuntar algunos de los campos de cada una.

Borrador de tablas y campos necesarios para la base de datos de Comercial Tasmania

Aunque la base de datos terminada de Comercial Tasmania contiene otras tablas, esta lista es un buen comienzo. En otras secciones verá cómo agregar otras tablas para perfeccionar el diseño.

Vea también

Análisis de los requisitos de datos | Determinar los campos necesarios | Diseñar bases de datos | Crear bases de datos | Trabajar con tablas