1. Introducción

Una de las dificultades que existían a la hora de diseñar una BD es que el diseñador, a partir de las necesidades descritas por su cliente (quien ha pedido que le hagan una BD) se ponía a crear tablas sin pensar las posibles relaciones entre ellas , etc. Y luego no podía preguntarle al cliente si era eso lo que realmente quería, ya que el cliente no entiende de tablas.

Por ejemplo, una bibliotecaria le dice al diseñador que le haga una BD y, entre otras cosas le dice:

"Cuando un usuario se lleva un libro a casa se anota la fecha de préstamo y la de devolución".

El diseñador, al llegar a su puesto de trabajo, crea todas las tablas pensando que un usuario puede llevarse sólo un único libro y, por tanto, diseña las tablas de acuerdo con esto. Después de realizar todo el trabajo, cuando lo instala en la biblioteca, la bibliotecaria se da cuenta de que la aplicación no deja que un usuario pueda llevarse 2 o más libros.

¿Qué ha pasado? Un malentendido. Para evitar este tipo de cosas, debería hacerse como un esquema (como un dibujo) que refleje de forma clara los diferentes datos que se quieren guardar y cómo están relacionados. Así, a partir de ese dibujo que hace el diseñador, podrá preguntar a la bibliotecaria si son esas las relaciones o son otras. Es decir, le saldrá la pregunta de: "¿un usuario puede llevarse sólo 1 libro? ¿O muchos?".

Es decir: el diseñador de la BD debe concebir a la BD a un nivel superior: en lugar de centrarse en la implementación física de las tablas, debe trabajar con las diferentes entidades que habrá y de las relaciones entre ellas .

Con este propósito nace el Modelo Entidad-Relación (ER), propuesto por Peter Pin-Shan Chen en 1976. El modelo Entidad-Relación permite representar la realidad en términos de entidades, atributos y relaciones entre estas entidades.

Con este modelo se pretende tener una visión abstracta de los datos, independientemente de consideraciones de tipo físico. Como su nombre indica, el Modelo Entidad/Relación se basa en entidades (cualquier objeto de interés para el mundo real que se pretende moldear) que se relacionanentre sí.

Conclusión :

• El usuario conoce bien cómo funciona su empresa pero a menudo no sabe expresarlo de forma correcta y/o precisa para ser informatizado.

• El diseñador sabe crear tablas pero no conoce bien el negocio para el que debe crear la base de datos.

En este sentido, el uso del modelo ER facilita el diálogo entre diseñador informático y usuario. Es decir: como el modelo ER es sencillo pero potente, el diseñador realizará un primer esquema ER y, con él, aclarará posibles dudas con el usuario.

Para saber dónde estamos, volvemos a mostrar el ciclo de vida del software con el ejemplo de diseño de una BD para una biblioteca. En este tema veremos la fase de Análisis Conceptual. Partiremos de unos requerimientos ya hechos y, siguiendo las normas del modelo conceptual, obtendremos un esquema relacional ER y unas posibles restricciones de integridad (condiciones que deben cumplir los datos pero no se han podido reflejar en el ER).