Diseño de Bases de Datos – Parte 2

Diseño de tablas y sus relaciones

En la primer parte de este artículo habiamos creado el modelo entidad relación del ejemplo de recorridos turísticos y teníamos lo siguiente:

En donde mencionabamos que un turista puede realizar varios recorridos turísticos, y que un recorrido turístico es realizado por varios turistas, por lo que tenemos una relación de muchos a muchos entre ambas entidades: Turistas y Recorridos. En este modelo tenemos sólo dos entidades: Turista y Recorrido. “Realiza” es la relación que existe entre las dos entidades.

Ahora bien, si sabemos que para cada turista necesitamos registrar su nombre, edad, nacionalidad y sexo y que además los recorridos están identificados con un número de recorrido, un nombre y una descripción de la ruta y los atractivos turísticos que se visitan, así como, la fecha en que cada turísta realiza un recorrido, el modelo lo podemos completar con dicha información de la siguiente manera:

La fecha no la colocamos en el recorrido, ya que la entidad Recorrido es un catálogos de los recorridos turísticos que se ofrecen y que se realizan en distintas fechas por distintos turistas, así que la fecha la colocamos en la relación entre ambas entidades.

Con esta información, ahora podemos describir algo similar a esto: “John Smith, hombre británico de 30 años de edad, realizó el 20 de enero de 2008, el recorrido número 1 – Teotihuacan, Recorrido a la zona arqueológica, con escalada a la pirámide del sol, comida en reataurante xxx,…. etc. etc.”

Cuando tenemos entidades con muchisimos datos, no se vuelve práctico colocarlos todos en el modelo entidad-relación, sin embargo, podemos colocar los datos más relvantes para darle sentido al modelo.
En la entidad Recorrido, el número de recorrido, será el valor que nos identifique de manera única a cada registro, es decir, a cada recorrido, por lo tanto no habrá dos recorridos con el mismo número.

Para el caso de la entidad Turista, no tenemos hasta el momento un atributo que identifique de manera única a cada turista, no podemos utilizar el nombre, ya que varias personas pueden llamarse igual, lo mismo sucedería con la edad, el sexo y la nacionalidad, por lo que agregaremos un atributo que sea un identificador único para cada registro o turista, este identificador lo llamaremos idTurista y tendrá valores numéricos consecutivos.

Nuestro siguiente paso ahora es realizar la transformación del modelo entindad-relación al modelo relacional, es decir, diseñar las tablas de la base de datos en donde almacenaremos la información de este sistema.

Reglas de transformación

Las tres reglas básicas para realizar la transformación del modelo entidad-relación al modelo relacional son:

• Toda entidad se transforma en una tabla.
• Las relaciones de muchos a muchos (N:M) se transforman en tablas.
• Las relaciones uno a muchos (1:N) dan lugar o bien a una propagación de identificador único o bien a una tabla.

Tomando en cuenta la primer regla, tranformamos las dos entidades del modelo en dos tablas correspondientes:

Como se mencionó anteriormente y podemos observar en la figura de la tablas, la tabla Turista contiene un atributo adicional (campo) llamado idTurista, el cual se convierte en la clave primaria de esta tabla, es el atributo que nos permite establecer un identificador único para cada turista. Para el caso de la tabla Recorrido, el identificador único (clave primaria) será el número del recorrido.

El modelo relacional impone una serie de restricciones inherentes:

1. En una tabla no puede haber dos registros iguales (obligatoriedad de clave primaria).
2. El orden de los registros y de los atributos no es relevante.
3. Cada atributo sólo puede tomar un único valor del dominio sobre el cual está definido, a excepción del caso de los campos repetitivos que si se permiten en FileMaker.
4. Ningún atributo que forme parte de la clave primaria puede tener valores nulos o vacíos (integridad de entidades).

Las restricciones con respecto a los atributos, las veremos más adelante.

Mientras tanto, para la segunda regla de transformación tenemos que: Las relaciones N:M dan lugar a una tabla cuya clave primaria o identificador único será la concatenación de los identificadores principales de las entidades que se enlazan con esta relación. De esta forma, los campos que forma la clave primaria de esta nueva tabla son claves ajenas o foraneas respecto a las tablas en las que estos campos son clave primaria.

La relación “Realiza”, da lugar a una tabla que llamaremos Realiza, (el nombre puede ser distinto), que contiene ademas de los atributos que forma la clave primaria, el campo fecha.

idTurista se refiere al identificador único de la tabla turista, pero en esta tabla se convierte en una clave foranea que forma parte de la clave primaria de la tabla Realiza. número es la clave primaria en la tabla Recorrido, pero se convierte en clave foranea en esta tabla y forma parte también, de la clave primaria de la tabla Realiza.

La tabla realiza enlaza a las tablas Turista y Recorrido, por lo tanto su clave primaria o identificador único está formado por dos campos, es decir, es una clave primaria compuesta.

Ahora bien, ¿Que sucede si un mismo turista realiza dos veces un mismo recorrido?, ya sea por que le gustó, por que quiso repetir la experiencia, etc. por lo que sea, pero si el mismo turista lo realiza dos veces, es obvio que no puede hacerlo el mismo día si tomamos en cuenta que son recorridos de todo un día.

Tomando en cuenta las reglas y restricciones mencionadas anteriormente, en la que deciamos que en una tabla no puede haber dos registros iguales, el valor que diferenciaría a estos dos registros es precisamente la fecha. Por lo tanto, para la tabla Realiza, incorporamos a la clave primaria el campo fecha. De esta forma la clave primaria de la tabla Realiza estará compuesta por los campos: idTurista, numero y fecha.

Finalmente, al diseñar las tres tablas resultantes y enlazarlas para establecer la relación entre ellas, el diagrama relacional nos queda de la siguiente forma:

Aún no podemos decir que las tablas quedarán construidas de esta forma en FileMaker, antes de construirlas necesitamos tomar encuenta algunas consideraciones sobre el dominio de los atributos, valores multivaluados, depencencias funcionales y restricciones en cuanto a la información que será almacenada en la base de datos.

Todos estos puntos los trataremos en la siguiente parte de este artículo, en donde veremos los esquemas de normalización para reducir al máximo la redundancia de datos.