El primer paso que debe seguir al diseñar una base de datos es determinar el propósito de la misma ycómo va a utilizarla. De esta forma averiguará la información que desea obtener de la base de datos. A partir de ahí, podrá determinar los temas sobre los que necesita almacenar datos (las tablas) y los datos que necesita almacenar sobre cada tema (los campos de las tablas).
Hable con las personas que vayan a utilizar la base de datos. Intercambie ideas sobre las preguntas que esas personas desearían plantearle a la base de datos. Diseñe los informes que le gustaría obtener de la base de datos. Reúna los formularios que utiliza actualmente para introducir yregistrar los datos. En los pasos posteriores del proceso de diseño utilizará toda esta información.
Ejemplo: Hacer un seguimiento de las ventas y el inventario.
Suponga que Importadores Neptuno, una empresa de importación/exportación que vende alimentos de todo el mundo, desea tener una base de datos que pueda hacer un seguimiento de la información sobre las ventas y el inventario de la empresa.
Empiece elaborando una lista de preguntas a las que debe responder la base de datos. ¿Cuántas ventas de nuestros productos hemos conseguido el mes pasado? ¿Dónde viven nuestros mejores clientes? ¿Quién es el proveedor de nuestro producto más vendido?
Acontinuación, reúna los formularios e informes que contienen la información que debe ser capaz de producir la base de datos. Actualmente, la empresa utiliza un informe impreso para hacer un seguimiento de los productos pedidos y un formulario de pedido para tomar los nuevos pedidos.
Determinar las tablas necesarias
Determinar las tablas a incluir en su base de datos puede ser el paso más delicado de todo el proceso de diseño, ya que los resultados que desea obtener de la base de datos (los informes que desea imprimir, los formularios que desea utilizar, las preguntas o consultas a las que desea obtener respuesta) no proporcionan necesariamente ninguna pista sobre la estructura de las tablas que los producen. Le dirán lo que quiere saber, pero no cómo disponer la información en tablas.
Tome como ejemplo un formulario de pedido típico. Este formulario incluye datos sobre el cliente (la dirección yel número de teléfono del cliente) y datos sobre el pedido. Dicho formulario le indica una serie de datos que usted sabe que desea almacenar en la base de datos. Pero seguramente tendría problemas si almacenara los datos sobre los clientes en la misma tabla que los datos sobre los pedidos.
- Introducir errores en información duplicada. Suponga que el mismo cliente hace tres pedidos diferentes. Podría agregar la dirección y el número de teléfono del cliente tres veces a la base de datos, una por cada pedido. Esto multiplicaría la posibilidad de cometer errores al introducir los datos. Además, si, el cliente cambia de dirección, tendría que aceptar la existencia de información contradictoria su base de datos, o bien buscar y modificar en la tabla todos los registros de ventas realizadas a dicho cliente. Es mucho mejor tener una tabla Clientes que almacene una sola vez la dirección del cliente en la base de datos. De esta forma, si necesita modificar los datos bastará con que lo haga una sola vez.
- Eliminar información valiosa. Suponga que un nuevo cliente hace un pedido y luego lo cancela. Al eliminar el pedido de la tabla que contiene detalles sobre los clientes y sus pedidos se eliminará el nombre y la dirección del cliente. Usted desea conservar este nuevo cliente en la base de datos de forma que pueda enviarle el próximo catálogo. De nuevo, es mejor incluir la información sobre el cliente en una tabla Clientes distinta que la de pedidos. De esta forma, podrá eliminar el pedido sin eliminar la información sobre el cliente.
Examine la información que desea obtener de la base de datos y divídala en los temas fundamentales de los que desea hacer un seguimiento, tales como los clientes, los empleados, los productos que vende, los servicios que ofrece, etc. Cada uno de estos temas es candidato a ser una tabla distinta.
Para determinar los campos que conviene incluir en una tabla, decida lo que necesita saber sobre las personas, las cosas o los eventos registrados en la tabla. Considere los campos como características de la tabla. Cada registro (o fila) de la tabla contiene el mismo conjunto de campos o características. Por ejemplo, un campo Dirección en una tabla Clientes contiene las direcciones de los clientes. Cada registro de la tabla contiene datos sobre un cliente, yel campo Dirección contiene la dirección de dicho cliente.
Determinar los campos necesarios
Sugerencias para determinar los campos
He aquí algunas sugerencias para determinar los campos que debe incluir en una tabla:
– Asegúrese de que cada campo de una tabla está directamente relacionado con el tema de la tabla. Un campo que describa aspectos propios de otra tabla deberá pertenecer a la otra tabla. Más adelante cuando defina las relaciones existentes entre las tablas, aprenderá a combinar los datos procedentes de campos de distintas tablas. Por ahora, asegúrese de que cada campo de una tabla describe directamente el tema concreto de la tabla. Si ve que está repitiendo la misma información en distintas tablas, significa que tiene campos innecesarios en algunas de ellas.
– No incluya datos derivados o calculados. En la mayoría de los casos, no le interesará almacenar en tablas los resultados de los cálculos. Puede hacer que el SGBD realice los cálculos siempre que necesite ver el resultado. Por ejemplo, un informe de productos pedidos presentaría el subtotal de unidades pedidas para cada categoría de productos incluida en la base de datos. No obstante, en ninguna tabla de la base de datos hay ningún campo de subtotal Unidades pedidas. En su lugar, la tabla Productos incluiría un campo Unidades pedidas que almacena las unidades pedidas para cada producto individual. Utilizando esos datos, el SGBD calculará el subtotal siempre que se imprima el informe. No es necesario almacenar en una tabla el subtotal propiamente dicho.
– Incluya toda la información que necesite. Es fácil omitir información importante que pudiera necesitar en el futuro. Vuelva a revisar la información que reunió en el primer paso del proceso de diseño. Examine sus formularios e informes en papel para asegurarse de que toda la información que necesitaba anteriormente está incluida en las tablas de la base de datos o puede derivarse de ellas. Piense en las preguntas que le va a plantear al SGBD. ¿Podrá encontrar el SGBD todas las expuestas utilizando tan sólo la información incluida en sus tablas?
– Almacene la información en sus partes lógicas más pequeñas. Quizá tenga la tentación de incluir un solo campo para nombres completos o para nombres de productos junto con las descripciones de dichos productos. Si en un campo combina más de un tipo de información, será difícil recuperar posteriormente los datos individuales. Procure dividir la información en partes lógicas; por ejemplo, cree un campo para el nombre y otro para apellidos, o bien uno para el nombre de producto, otro para la categoría y un tercero para la descripción.
Campos de clave principal
La potencia de un sistema de administración de bases de datos relacionales surge de su capacidad para buscar, localizar y combinar rápidamente información almacenada en distintas tablas. Para que el SGBD funcione de la manera más eficiente posible, cada tabla de la base de datos debe incluir un campo o una serie de campos que identifique inequívocamente cada fila o registro individual almacenado en la tabla.
Normalmente, suele emplearse un número exclusivo de como un numero de ID de empleado o un número de serie. En la terminología de datos, esta información identificadora se denomina clave principal de la tabla. El SGBD utiliza los campos de clave principal para asociar rápidamente datos de distintas tablas y poder presentarle todos los datos conjuntamente.
Si ya dispone de un identificador único para una tabla, como por ejemplo una serie de números de producto creados para identificar los artículos que tiene en existencia, podrá utilizar dicho identificador como clave principal de la tabla. Pero debe asegurarse de que los valores de este campo siempre sean distintos para cada registro, ya que el SGBD no permite la existencia de valores duplicados en un campo de clave principal. Por ejemplo, no utilice nombres de personas como clave principal, ya que los nombres no son únicos (en la misma tabla podría haber dos personas con el mismo nombre).
Si todavía no tiene pensado utilizar ningún identificador único para una tabla, podrá emplear un campo que simplemente numere consecutivamente los registros. Cualquier SGBD incluso le proporcionará una clave principal de ese tipo.
Cuando elija los campos de clave principal, tenga en cuenta lo siguiente:
- Cualquier SGBD no permite la existencia de valores duplicados o nulos en un campo de clave principal. Por ello, no debe elegir una clave principal que pudiera contener este tipo de valores.
- Puede utilizar el valor del campo de clave principal para buscar registros, por lo que dicho campo no debe ser demasiado largo, y sí fácil de recordar y de escribir. Quizá convenga que tenga un número limitado de letras o dígitos, o que esté dentro de un determinado rango.
- El tamaño de la clave principal influye en la velocidad de las operaciones que se realizan en la base de datos. Cuando cree campos de clave principal podrá establecer una propiedad para limitar el tamaño de dichos campos. Para obtener el máximo rendimiento, utilice el menor tamaño posible necesario para que quepan los valores que desea almacenar en el campo.
Determinar las relaciones
Ahora que ha dividido la información en tablas, necesita una forma de indicar al SGBD cómo debe recuperar conjuntamente dicha información de forma significativa.
En un SGBD relacionales es posible almacenar datos relacionados en distintas tablas de la base de datos. A continuación, debe definir relaciones entre las tablas y el SGBD utilizará dichas relaciones para encontrar información asociada entre sí pero almacenada en diferentes tablas.
Esto es posible incluyendo en una tabla un campo que sea la clave principal de otra tabla. El campo así incluido se denomina clave externa.
Así, para establecer una relación entre dos tablas, tabla A y tabla B, debe agregar la clave principal de una tabla a la otra, de forma que dicha clave aparezca en ambas tablas. Pero ¿cómo decide la clave principal que debe utilizar? Para establecer correctamente la relación, es preciso determinar primero la naturaleza de la relación. Hay tres tipos de relaciones entre tablas:
· Relaciones «uno a varios».
· Relaciones «varios a varios».
· Relaciones «uno a uno».
Crear una relación «uno a varios». La relación «uno a varios» es el tipo más frecuente en bases de datos relacionales. En una relación de este tipo, un registro de la tabla A puede tener más de un registro coincidente en la tabla B, pero un registro de la tabla B tiene como máximo un registro coincidente en la tabla A.
Para establecer la relación, agregue el campo o los campos que componen la clave principal del extremo «uno» de la relación a la tabla situada en el extremo «varios» de la relación.
Crear una relación «varios a varios». En una relación «varios a varios», un registro de la tabla A puede tener más de un registro coincidente en la tabla B, y un registro de la tabla B también puede tener más de un registro coincidente en la tabla A. Este tipo de relación requiere cambiar el diseño de la base de datos antes de poder especificar correctamente la relación al SGBD.
Para detectar las relaciones «varios a varios» entre las tablas, es importante que observe la relación en los dos sentidos. Por ejemplo, examine la relación entre pedidos y productos en una compañía de ventas de artículos: un pedido puede incluir más de un producto. Así, por cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos. Pero esto no es todo: cada producto puede aparecer en varios pedidos. Por ello, por cada registro de la tabla Productos puede haber varios registros en la tabla Pedidos.
Los temas de las dos tablas, pedidos yproductos, tienen una relación «varios a varios», lo cual plantea un problema en el diseño de la base de datos. Para entender el problema, imagine lo que ocurriría si intentara establecer la relación entre las dos tablas agregando el campo «clave principal» de producto a la tabla Pedidos. Para tener más de un producto en un solo pedido necesita más de un registro en la tabla Pedidos por cada pedido. De esta forma repetiría una yotra vez la información sobre pedidos para cada registro relativo a un único pedido; este diseño, además de ser ineficiente, produciría datos inexactos. Tendría el mismo problema si incluyera el campo «clave principal» de pedido en la tabla Productos: tendría más de un registro en la tabla Productos para cada producto. ¿Cómo se resuelve este problema?
La respuesta es crear una tercera tabla que divida la relación «varios a varios» en dos relaciones «uno a varios». En esta tercera tabla se incluiría la clave principal de cada una de las dos tablas anteriores.
Cada registro de la tabla Detalles de pedidos representa un artículo de un pedido La clave principal de la tabla Detalles de pedidos consta de dos campos: las claves externas que provienen de las tablas Pedidos y Productos. El campo «clave principal» de pedido por sí solo no actúa como clave principal para esta tabla, ya que un pedido puede contener muchos artículos. El campo «clave principal» de pedido se repite para cada artículo de un pedido, por lo que el campo no contiene valores únicos. El campo «clave principal» de producto por sí solo tampoco actúa como clave principal, ya que un producto puede aparecer en varios pedidos distintos Pero conjuntamente, estos dos campos siempre producen un valor único para cada registro.
Crear una relación «uno a uno». En una relación «uno a uno», un registro de la tabla Ano puede tener más de un registro coincidente en la tabla B, yun registro de la tabla B no puede tener más de un registro coincidente en la tabla A. Este tipo de relación es poco frecuente y puede requerir ciertos cambios en el diseño de la base de datos.
Las relaciones «uno a uno» entre tablas son poco frecuentes ya que, en muchos casos, la información de las dos tablas podría combinarse en una sola tabla. Por ejemplo, suponga que ha creado una tabla Jugadores de ping-pong para hacer un seguimiento de la información relativa a la jornada de recolección de fondos para la Asociación de ping-pong de la empresa anterior. Puesto que todos los jugadores de ping-pong son empleados de la empresa, esta tabla tiene una relación «uno a uno» con la tabla Empleados.
Podría agregar todos los campos de la tabla Jugadores de ping-pong a la tabla Empleados. Pero la tabla Jugadores de ping-pong está diseñada para hacer un seguimiento de un evento que se produce una sola vez, y cuando termine dicho evento ya no necesitará la información de la tabla. Además, no todos los empleados juegan al ping-pong; por eso, si la tabla Empleados contuviera estos campos, estarían vacíos para muchos registros. Por todas estas razones conviene crear una tabla distinta.
Cuando detecte la necesidad de establecer una relación «uno a uno» en su base de datos, piense si puede incluir la información en una sola tabla. Si no desea hacerlo por alguna razón, haga lo siguiente para establecer dicha relación:
- Si las dos tablas son del mismo tema, probablemente podrá establecer la relación utilizando el mismo campo de clave principal en ambas tablas.
- Si las dos tablas son de distintos temas y tienen distintas claves principales, elija una de las tablas (cualquiera de ellas) e incluya su campo de clave principal en la otra tabla, como clave externa.
