4.1. Diseño conceptual: el modelo ER

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.