4. Introducción al diseño de bases de datos

4. Introducción al diseño de bases de datos Dataprix 26 November, 2009 - 15:23

Aunque las sentencias SQL de creación de tablas son bastante claras para un usuario técnico, de cara a la reunión previa a la toma de decisión sobre el SGBD concreto en el que vamos a implantar la solución, necesitaremos algo más.

Teniendo en cuenta que entre los asistentes a la reunión no hay más técnicos especializados en bases de datos que nosotros, hemos pensado que disponer  un  modelo  entidad-relación  del  sistema  nos  ayudará  a  comunicar mejor la estructura que estamos planteando y, de paso, a demostrar (o, si es necesario, corregir) que el modelo relacional que planteamos al inicio es el correcto.

 

4.1. Diseño conceptual: el modelo ER

4.1. Diseño conceptual: el modelo ER Dataprix 26 November, 2009 - 15:33

Vamos a plantear en primer lugar el modelo obtenido y, después, comentaremos los aspectos más interesantes:

 

                 

 

El modelo, expresado de este modo, es mucho más comprensible por parte de personal no técnico o no especializado en tecnologías de bases de datos.

A partir de la expresión gráfica del modelo, identificamos limitaciones o puntos de mejora, que anotamos a continuación:

•    Probablemente, debemos incluir información de facturación a clientes por las peticiones realizadas.

•    Probablemente, habrá peticiones que puedan agruparse en una entidad superior (un proyecto o trabajo), o bien peticiones relacionadas entre ellas (peticiones que deban resolverse antes que otras).

Una vez identificadas estas limitaciones, vamos a ampliar el modelo para corregirlas e impresionar a nuestros superiores de cara a la reunión.

•    Información de facturación a clientes:

 

            

 

Lo único que hemos introducido ha sido la entidad FACTURA, que se relaciona con N peticiones y con un único cliente. Un CLIENTE puede tener varias facturas asociadas, pero una petición sólo puede pertenecer a una única factura.

•    Grupos de peticiones y relaciones entre ellas.
 

            

 

La pertenencia a un proyecto será opcional, y así lo indicamos en el diagrama. Por lo que respecta a las relaciones de peticiones entre ellas, se trata de una interrelación recursiva. Si queremos contemplar casos como los siguientes, debemos expresar la relación como M:N recursiva y opcional. En la interrelación RELACIONA, debemos contemplar algún atributo que indique de qué tipo de relación se trata en cada caso:

•    Una petición depende de una o más peticiones.
•    Una petición bloquea a una o más peticiones.
•    Una petición es la duplicada de una o más peticiones.
•    Una petición está relacionada con una o más peticiones.

4.2. Diseño lógico: la transformacion del modelo ER al modelo relacional

4.2. Diseño lógico: la transformacion del modelo ER al modelo relacional Dataprix 27 November, 2009 - 10:54

En el apartado anterior sugerimos unas ampliaciones sobre el modelo ER que proporcionaban más prestaciones al proyecto. A continuación, vamos a realizar la transformación al modelo relacional de estas ampliaciones:

•    Información de facturación a clientes.

 

         

 

Según las transformaciones vistas en el módulo “El lenguaje SQL”, la entidad FACTURA se transforma en la relación FACTURA, con los siguientes atributos:

 

FACTURA(numfactura, fecha, cliente)

Donde cliente es una clave foránea que corresponde a la interrelación TIENE entre CLIENTE y FACTURA. Un cliente puede tener N facturas, pero una factura pertenece sólo a un único cliente.
 

La interrelación entre FACTURA y PETICION del tipo 1:N se transforma también en una nueva clave foránea, que aparece siempre en el lado N de la interrelación; o sea, en la relación PETICION. Si existen peticiones que no deban facturarse (porque se han cerrado sin resolverse, o eran duplicadas de otras, etc.), su clave foránea tomaría el valor NULO.

•    Grupos de peticiones y relaciones entre ellas.

 

         

 

Por una parte, la entidad proyecto debe transformarse en la relación PROYECTO, con atributos como los siguientes:

PROYECTO(codigo, nombre, fechainicio, fechafin)

La relación 1:N entre PROYECTO y PETICIÓN se transformará en la inserción de una nueva clave foránea en la relación PETICION, que podrá tener valor NULO si la petición no pertenece a ningún proyecto; es decir, si se trata de una petición aislada. La relación PETICION quedaría así:

PETICION(referencia, cliente, resumen, estado, fecharecepcion, fechainicio, fechafin, tiempoempleado, factura, proyecto)

Por lo que respecta a las relaciones entre peticiones, se trata de una interrelación  recursiva  N:M,  y  por  lo  tanto  se  transformará  en  una  nueva  relación, PETICION_RELACION:

PETICION_RELACION(referencia_peticion1, referencia_peticion2, tiporelacion)

 

 

Ejemplo
Si la relación debe indicar sim- plemente que dos peticiones están relacionadas, entonces no importa qué referencia sea, la 1 o la 2.

En este caso, y según el valor que pueda tomar el atributo {tiporelacion}, tendrá importancia o no qué referencia de petición aparece en cada atributo de la relación.

En cambio, si el atributo {tiporelacion} indica un bloqueo o una dependencia entre relaciones (porque una debe resolverse antes que otra, por ejemplo), entonces sí tiene sentido qué referencia de petición se almacena en el atributo 1 y cuál en el 2. En todo caso, esta tarea corresponderá a la solución que se adapte y trabaje con la base de datos en último término, no al propio modelo.