Tema 5: Desarrollar el Modelo Lógico de Datos

Identificar Entidades y Sus Atributos

Cuando se recogen los requisitos del sistema para al diseño de la base de datos, uno de los pasos que se realizan es el de definir los tipos de datos que contendrá la base de datos. Pueden separarse estos tipos de datos en categorías que representan una división lógica de información. En la mayoría de los casos, cada categoría de tipo de dato se traduce en un objeto tabla dentro de la base de datos. Hay normalmente, un conjunto de objetos primarios, y después de que ellos son identificados, surgen los objetos relacionados.

Por ejemplo, en la base de datos Editores, uno de los objetos primarios es la tabla Titulos. Uno de los objetos relacionado a la tabla Títulos es la tabla de RoyAgenda que proporciona información sobre la agenda de royalties asociada con cada libro. Otro objeto es la tabla TituloAutor que vincula a los autores con los libros.

Usando las categorías de datos definidas en los requisitos del sistema, se puede empezar a crear un mapa del objeto tabla dentro de la nueva base de datos. Por ejemplo, suponga que usted está diseñando una base de datos para el sistema de reservaciones de un hotel. Durante el proceso de recolección de requisitos de sistema, identifica varias categorías de datos, incluido los cuartos, huéspedes, y reservaciones. Como resultado, agrega tablas a su diseño de la base de datos que representan a cada una de estas categorías.

Al identificar las reglas comerciales para este sistema, usted determinó que el hotel tiene ocho tipos de cuartos y que los huéspedes regulares prefieren un cierto tipo de cuarto. Como resultado, tanto la tabla Habitaciones como la tabla Huespedes deberán incluir un atributo de tipo de cuarto. Usted decide crear una tabla para los tipos del cuarto.

Ahora, la tabla Habitaciones y la tabla Huespedes referencian a la tabla TipoHab sin tener que repetir una descripción del cuarto para cada cuarto y cada huésped. Además, ante un cambio en los tipos de cuarto, usted puede actualizar la información en un solo lugar, en lugar de tener que actualizar múltiples tablas y archivos.

Antes de que usted pueda completar el proceso de definir objetos de la tabla dentro de la base de datos, debe definir las relaciones entre las tablas. Siempre que identifique una relación muchos-a-muchos, tendrá que agregar una tabla de unión. Se discuten relaciones con más detalle adelante en este tema.

Después de que usted ha definido todas las tablas que puede definir a estas alturas, puede definir las columnas (atributos) para esas tablas. De nuevo, usted estará tomando esta información directamente de los requisitos del sistema en los que identificó qué tipos de datos deben ser incluidos en cada categoría de información.

Usando el ejemplo de base de datos del hotel, suponga que determinó durante el proceso de recolección de requisitos del sistema que la categoría Huespedes debe incluir información la siguiente información sobre los huéspedes: nombre, apellido, dirección, número de teléfono, y preferencias del cuarto. Como resultado, usted planea agregar columnas a la tabla de los Huespedes para cada uno de estos tipos de información. Usted también planea agregar un identificador único para cada huésped, tal como con cualquier entidad normalizada.

Identificar Relaciones Entre las Entidades

Después de que ha definido las tablas y sus columnas, usted debe definir las relaciones entre las tablas. A través de este proceso, podría descubrir que necesita modificar el diseño que ha creado.
Empiece escogiendo una de las tablas primarias y seleccionando las entidades que tienen relaciones con esa tabla. Siguiendo con el ejemplo del hotel, asuma que los requisitos del sistema indican que todas las reservaciones deben incluir cuarto e información del huésped. Los cuartos, huéspedes, y reservaciones son las categorías de datos. Como resultado, usted puede deducir que una relación existe entre los cuartos y reservaciones y entre los huéspedes y reservaciones. La Figura 5.4 muestras las relaciones entre estos objetos. Una línea que conecta las dos tablas significa una relación. Advierta que una relación también existe entre la tabla Habitaciones y la tabla TipoHab y entre la tabla Huespedes y la tabla TipoHab.

Una vez que establece que una relación existe entre las tablas, usted debe definir el tipo de relación. El 1 se refiere al lado uno de una relación, y el símbolo de infinito se refiere al lado muchos de una relación uno-a-muchos. Algunos autores también las llaman relaciones 1:N.

Para determinar los tipos de relaciones que existen entre las tablas, usted debe mirar los tipos de datos que cada tabla contiene y los tipos de conexiones entre ellos. Por ejemplo, una relación existe entre la tabla Huespedes y la tabla Reservas. La relación existe porque los huéspedes son parte de la información que se recaba cuando se registra una reservación. Según las reglas comerciales, un huésped puede hacer una o más reservaciones, pero cada reservación grabada puede incluir solo el nombre de un huésped, normalmente la persona que está haciendo la reservación. Como resultado, una relación uno-a-muchos existe entre las dos tablas: un huésped, una o muchas reservaciones.

Una relación también existe entre la tabla Reservas y la tabla Habitaciones. Según las reglas comerciales, una reservación puede solicitar uno o más cuartos, y un cuarto puede ser incluido en una o más reservaciones (en fechas diferentes). En este caso, existe una relación muchos-a-muchos: muchas reservaciones a muchos cuartos. En un diseño de base de datos normalizado, sin embargo, relaciones muchos-a-muchos deben ser modificadas agregando una tabla de unión y creando una relación uno-a-muchos entre cada tabla original y la tabla de unión.

Identificar Restricciones sobre los Datos

A estas alturas del proceso de diseño de la base de datos, usted debería tener definidas las entidades, sus atributos, y las relaciones entre entidades. Ahora, usted debe identificar las restricciones sobre los datos que se guardarán en las tablas. El mayor trabajo ya fue completado cuando usted identificó las reglas comerciales al momento de recoger los requisitos del sistema. Como se vio, las reglas comerciales incluyen todo las restricciones en un sistema, incluida la integridad de los datos y la seguridad del sistema. Para esta fase del proceso de diseño, su enfoque se centrará en las restricciones sobre los datos. Usted tomará las reglas comerciales relacionadas a los datos y las refinará y organizará. Debe intentar organizar las restricciones en base a los objetos que creó en la base de datos, y formularlas de modo que se refieran a ellos.

Suponga que una de las reglas comerciales indica: "Un registro de huésped puede, pero no es obligatorio, incluir una preferencia por uno de los tipos de cuarto predefinidos pero no puede incluir ninguna otra preferencia de tipo de cuarto." Al definir las restricciones sobre los datos, usted debe referenciar las tablas y columnas pertinentes y dividir la regla comercial de modo que cada restricción esté contenida en una instrucción simple:
· La columna de TipoHabID en la tabla Huespedes no requiere un valor.
· Todo valor distinto de NULL en la columna de TipoHabID en la tabla Huespedes debe ser un valor incluido en la columna de TipoHabID en la tabla de TipoHab.
· Una fila en la tabla de los Huespedes puede incluir sólo un valor en la columna de TipoHabID.

En cuanto sea posible, usted debe organizar las restricciones sobre los datos según las tablas y sus columnas. En algunos casos, una restricción se aplica al conjunto de una tabla, a más de una tabla, a una relación entre las tablas, o a la seguridad de los datos. En estos casos, intente organizar las restricciones de modo que sea lógica y más pertinente al proyecto. La meta de identificar las restricciones sobre los datos es tener un mapa claro del camino para cuando se creen los objetos de la base de datos y sus relaciones que fuerce la integridad de los datos.