Diseño básico de una base de datos – Parte II

En esta segunda parte analizaremos cada unos de los ‘Procesos del diseño’ de la base de datos que listamos en la Primera parte de este articulo.

Así que iniciemos…

Determinar la finalidad de la base de datos.

Una buena técnica es plasmar con lápiz y papel, el proposito de la base de datos: como se va a usar y quien la piensa utilizar.

Si la base de datos es pequeña, con una breve descripción será suficiente, pero si la base datos es más compleja  y/o la utilizan muchas personas (como por lo general ocurre), entonces quizas necesites un par de párrafos para definir el uso de la base de datos.

El objetivo de esto es tener una declaración de intenciones bien definidas que te sirvan de referencia en todo el proceso de diseño.

 

Buscar y organizar la información necesaria.

Se puede iniciar con la información existente, es decir, con el material en papel que ocupa la empresa o negocio que requiere la base de datos.

Ejemplo: Si se va a almacenar la información de los clientes, se puede tomar la información de los formularios y/o archivos de los clientes existentes en la empresa o negocio. En caso de no disponer de esta información, imagina la información que se requiere de cada cliente, identifica cada elementos y crea un listado de ellos; cada uno de estos elementos representa una posible columna de una tabla; no te preocupes si la lista no es perfecta al principio, enumera todos los elementos que se te ocurran, mas tarde podrás depurarla y adecuarla correctamente.

 

Dividir la información en tablas.

Primero elige los temas o entidades principales. Por ejemplo: después de buscar y organizar la información de una base de datos de ‘ventas de productos’, la lista preeliminar podría ser similar a la que te muestro a continuaciónLos elementos principales aquí mostrados son: ‘Productos’, ‘Clientes’, ‘Proveedores’ y ‘Pedidos’, los cuales son elementos básicos para iniciar; una tabla para almacenar los datos de los clientes, otra para almacenar los productos, los proveedores y otra para registrar los pedidos.

Aunque estos elementos no completen la lista, es un buen inicio. Puedes seguir ajustando la lista hasta tener el diseño correcto.Algo muy importante es evitar incluir todos los elementos en una sola tabla, observa por un momento la siguiente tabla:

En este ejemplo, cada fila tiene la información del proveedor (nombre y direccion). Como hay muchos productos de ‘un solo’ proveedor, la información del proveedor debe repetirse muchas veces (por cada producto que corresponde a ese proveedor), con esto se malgasta el espacio en disco; registrar la información del proveedor en una tabla aparte y luego vincularla a la tabla productos, seria la mejor opción.

Otro problema surge cuando desee modificar algún datos del proveedor, por ejemplo: la dirección; como esta aparece en varios lugares, podría cambiarla en un lugar y olviderse de cambiarla en los demás lugares.

Un problema más. Si un Provedor solo vende un producto y deseas eliminar ese producto pero NO la información del Proveedor,¿cómo hacerlo?, No se puede, puesto que cada producto contiene los datos del proveedor, al eliminar el producto también se eliminan los datos del proveedor. Todos estos problemas los evitamos si almacenamos la información del Proveedor en una tabla distinta.

Cuando diseñes la base de datos, intenta registrar cada dato UNA SOLA VEZ. Si estas repitiendo la misma información en varios lugares, colocala en una tabla distinta.

Convertir los elementos de información en columnas.

Para determinar las columnas de una tabla, necesitas tener muy en claro la información que deseas registrar en cada tabla. Por ejemplo: para una tabla de clientes, existen valores que no pueden faltar, como: nombre, apellidos, domicilio, telefono, codigo postal, etc. Después de haber determinado el conjunto inicial de elmentos, podrás ajustar con mayor precisión las columnas.

• Lo que debes evitar: incluir datos calculados.

No debes almacenar el resultado de los calculos en las tablas. En lugar de ello, realiza las operaciones cuando se necesiten ver los resultados. Por ejemplo: Deseas un informe de ‘Ventas’ el cual tiene un campo llamado total, pero no hay ninguna tabla con los totales de las ventas; pero en las ventas se almacena el costo del articulo y la cantidad vendida, con estos datos puedes calcular los importes de cada producto y despues sumar todos los importes para determinar el total. Pero el ‘Total’ propiamente dicho no se debe almacenar en alguna tabla, se debe calcular al momento.

•  Divide la información en partes logicas mas pequeñas.

Quizas desees habilitar un único campo para los nombres completos o para los nombres de productos junto con sus descripciones. Si combinas varios tipos de información en un campo, será difícil recuperar datos individuales más adelante. Intenta dividir la información en partes lógicas. Por ejemplo, crea campos distintos para el nombre y el apellido, o para el nombre del producto, la categoría y la descripción.

 

Especificar claves principales

Cada tabla debe incluir una columna o conjunto de columnas que identifiquen inequívocamente cada fila almacenada en la tabla. Esto es un número de identificación exclusivo, como un número de nomina de empleado o un número de serie. En la terminología de bases de datos, esta información recibe el nombre de Clave Principal  de la tabla.

Las motores de base de datos utilizan los campos de clave principal para asociar rápidamente datos de varias tablas y reunir automáticamente esos datos.

Si ya tiene un identificador exclusivo para una tabla, como un número de producto que identifica inequívocamente cada producto del catálogo, puede utilizar ese identificador como clave principal de la tabla, pero sólo si los valores de esa columna son siempre diferentes para cada registro. No puede tener valores duplicados en una clave principal.

Por ejemplo, no utilice los nombres de las personas como clave principal, ya que los nombres no son exclusivos. Es muy fácil que dos personas tengan el mismo nombre en la misma tabla.
Una clave principal siempre debe tener un valor. Si el valor de una columna puede quedar sin asignar o vacío (porque no se conoce) en algún momento, no puede utilizarlo como componente de una clave principal. Debes elegir siempre una clave principal cuyo valor no cambie.

Si cress que no hay ninguna columna o conjunto de columnas que pueda constituir una buena clave principal, considere la posibilidad de utilizar una columna que tenga el tipo de datos Autonumérico, por lo general a ese campo se le pone el nombre de ID (identificador).

Cuando se utiliza el tipo de datos Autonumérico, se asigna automáticamente un valor. Este tipo de identificador no es «fáctico», es decir, no contiene información objetiva sobre la fila que representa. Los identificadores de este tipo son perfectos para usarlos como claves principales, ya que no cambian y son unicos.

 

Crear relaciones entre tablas.

Después de haber dividido la información en tablas, se necesita un modo de reunir de nuevo la información de forma provechosa. Por ejemplo, el siguiente formulario incluye información de varias tablas.

1. La tabla de clientes…
2. La tabla de precios…
3. La tabla de productos…
4. La tabla de Detalle de venta…

La mayoria de las bases de datos son relacionales. En una base de datos relacional, la informción se divide en tablas distintas en función del tema.

A continuación veremos los tipos de relaciones que existen.

• Relación de uno a varios. Por ejemplo: las tablas Proveedores y Productos de la base de datos de pedidos de productos. Un proveedor puede suministrar cualquier número de productos y, por consiguiente, para cada proveedor representado en la tabla Proveedores, puede haber muchos productos representados en la tabla Productos. La relación entre la tabla Proveedores y la tabla Productos es, por tanto, una relación de uno a varios.
• Relación varios a varios. Considere la relación entre la tabla Productos y la tabla Pedidos. Un solo pedido puede incluir varios productos. Por otro lado, un único producto puede aparecer en muchos pedidos. Por tanto, para cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos. Y para 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 un producto puede haber varios pedidos, y para un pedido puede haber varios productos.
• Relación de uno a uno. Supongamos, por ejemplo, que necesita registrar información complementaria sobre productos que apenas va a necesitar o que sólo se aplica a unos pocos productos. Como no necesita la información con frecuencia, y como almacenar la información en la tabla Productos crearía un espacio vacío para todos los productos que no necesitan esa información, la coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza el identificador de producto como clave principal. La relación entre esta tabla complementaria y la tabla Productos es una relación de uno a uno. Para cada registro de la tabla Productos hay un único registro coincidente en la tabla
  complementaria. Cuando identifique esta relación, ambas tablas deben compartir un campo común.

Ajustar el diseño.

Una vez tengas todas las tablas, los campos y las relaciones necesarias, debes de rellenar las tablas con datos de ‘ejemplo’ y probar como funcionan con la información; por ejemplo: crear consultas, agregar nuevos registros, etc. Esto te permitirá encontrar posibles problemas, como quizas agregar una columna mas a alguna tabla o dividir una tabla en dos, para evitar datos duplicados.

Crea formularios y reportes para determinar que la información se muestra de forma correcta.

Aplicar las reglas de normalización.

Estas reglas sirven para comprobar si las tablas están estructuradas correctamente. El proceso de aplicar las reglas al diseño de la base de datos se denomina normalizar la base de datos o, simplemente, normalización.
La normalización es más útil una vez representados todos los elementos de información y después de haber definido un diseño preliminar. La idea es asegurarse de que se han dividido los elementos de información en las tablas adecuadas. Las reglas se aplican consecutivamente en cada paso para garantizar que el diseño adopta lo que se conoce como «forma normal». Hay cinco formas normales ampliamente aceptadas: de la primera forma normal a la quinta forma normal. En este artículo se abordan las tres primeras, porque todas ellas son necesarias para la mayoría de los diseños de base de datos.

Primera forma normal. Establece que en cada intersección de fila y columna de la tabla existe un valor y nunca una lista de valores. Por ejemplo, no puede haber un campo denominado Precio en el que se incluya más de un precio. Si considera cada intersección de filas y columnas como una celda, cada celdasólo puede contener un valor.

Segunda forma normal. La segunda forma normal exige que cada columna que no sea clave dependa por completo de toda la
clave principal y no sólo de parte de la clave. Esta regla se aplica cuando existe una clave principal formada por varias columnas. Suponga, por ejemplo, que existe una tabla con las siguientes columnas, de las cuales Id. de pedido e Id. de producto forman la clave principal:

• Id. de pedido (clave principal)
• Id. de producto (clave principal)
• Nombre

Este diseño infringe los requisitos de la segunda forma normal, porque Nombre de producto depende de Id. de producto, pero no de Id. de pedido, por lo que no depende de toda la clave principal. Debe quitar Nombre de producto de la tabla, ya que pertenece a una tabla diferente (a la tabla Productos).

Tercera forma normal. La tercera forma normal exige no sólo que cada columna que no sea clave dependa de toda la clave principal, sino también que las columnas que no sean clave sean independientes unas de otras. O dicho de otra forma: cada columna que no sea clave debe depender de la clave principal y nada más que de la clave principal. Por ejemplo, considere una tabla con las siguientes columnas:

• IdProducto (clave principal)
• Nombre
• PVP
• Descuento

Suponga que la columna Descuento depende del precio de venta al público (PVP) sugerido. Esta tabla infringe los requisitos de la tercera forma normal porque una columna que no es clave, la columna Descuento, depende de otra columna que no es clave, la columna PVP. La independencia de las columnas implica que debe poder cambiar cualquier columna que no sea clave sin que ninguna otra columna
resulte afectada.

Al seguir y tomar en cuenta todos y cada unos de los conceptos aquí analizados, te permitirá ser mas eficaz al momento de crear el diseño de una base de datos.