La tierra ecosistema

UNIDAD II - El modelo Entidad-Relación.

Es más lento la obtención de un diseño lo más óptimo posible, pero el tiempo invertido se recupera al no tener que volver atrás para replantearse el diseño de los datos. Un buen diseño es la clave para iniciar con buen pie el desarrollo de una aplicación basada en una base de datos o la implementación de un sistema.

Es de destacar la importancia de un buen diseño. Un diseño apresurado o simplemente bosquejado puede mostrarse inservible o muy mejorable cuando la aplicación ya está parcialmente codificado, o el administrador de la base de datos ya tiene organizados el mantenimiento y el control de acceso a los datos.

Esquema: diseño general de la base de datos a nivel lógico. Incluye el tipo de datos y las relaciones entre ellos. Es de naturaleza fija y solo se altera excepcionalmente. El esquema se define y se mantiene utilizando el lenguaje de definición de datos (DDL) Lenguaje de Definición de Datos..

Instancia: contenido concreto de la base de datos en un momento dado. Varía con el tiempo, al añadir, eliminar o modificar datos, utilizando el lenguaje de modificación de datos (DML) Lenguaje de Manipulación de Datos.

El diseño de una base de datos se realiza a dos niveles. El primero es el nivel conceptual, en la cual se contempla una estructura abstracta y no implementable directamente con un SGBD. El segundo es el nivel físico, en el cual la base de datos es ya implementable.  

Detalladamente, las fases del diseño de una base de datos son las siguientes:

Toda entidad tiene existencia propia, es distinguible del resto de las entidades, tiene nombre y posee atributos definidos en un dominio determinado.

Una entidad es todo aquello de lo que se desea almacenar información. En el diagrama E-R las entidades se representan mediante rectángulos u óvalos.

Una relación es una asociación o relación matemática entre varias entidades. Las relaciones también se nombran.  Se representan en el diagrama E-R mediante flechas y rombos. Cada entidad interviene en una relación con una determinada cardinalidad.

La cardinalidad (número de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad relacionada) se representa mediante una pareja de datos, en minúsculas, de la forma (cardinalidad mínima, cardinalidad máxima), asociada a cada uno de las entidades que intervienen en la relación.

Son posibles las siguientes cardinalidades: (0,1), (1,1), (0,n), (1,n), (m,n).

El tipo de relación se define tomando los máximos de las cardinalidades que intervienen en la relación. Hay cuatro tipos posibles:

Una a una (1:1). En este tipo de relación, una vez fijado un elemento de una entidad se conoce la otra. Ejemplo: alumno y carrera.

Una a muchas (1:N). Ejemplo: alumno y materias.

Muchas a una (N:1). Simetría respecto al tipo anterior según el punto de visto de una u otra entidad.

Muchas a muchas (N:N). Ejemplo: personas y viviendas.

Toda entidad debe ser unívocamente identificada y distinguible mediante un conjunto de atributos (quizás un solo atributo) denominado identificador o clave principal o primaria.

Metodología de diseño conceptual

El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos humanos, etc. A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales.

Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores.

El esquema conceptual también tendrá una documentación, que se irá produciendo durante su desarrollo.

Las tareas a realizar en el diseño conceptual son las siguientes:

1.- Identificar las entidades.

2.- Identificar las relaciones.

3.- Identificar los atributos y asociarlos a entidades y relaciones.

4.- Determinar los dominios de los atributos.

5.- Determinar los identificadores.

6.- Dibujar el diagrama entidad-relación.

7.- Revisar el esquema conceptual local con el usuario.

1. Identificar las entidades. En primer lugar hay que definir los principales objetos que interesan al usuario. Estos objetos serán las entidades. Una forma de identificar las entidades es examinar las especificaciones de requisitos de usuario, en estas especificaciones se buscan los nombres nominales que se mencionan.

Por ejemplo: número de empleado, nombre de empleado, número de inmueble, dirección del inmueble, alquiler, número de habitaciones).

También se buscan objetos importantes como personas, lugares o conceptos de interés, excluyendo aquellos nombres que sólo son propiedades de otros objetos. Por ejemplo, se pueden agrupar el número de empleado y el nombre de empleado en una entidad denominada empleado, y agrupar número de inmueble, dirección del inmueble, alquiler y número de habitaciones en otra entidad denominada inmueble.

Otra forma de identificar las entidades es buscar aquellos objetos que existen por sí mismos. Por ejemplo, empleado es una entidad porque los empleados existen, sepamos o no sus nombres, direcciones y teléfonos. Siempre que sea posible, el usuario debe colaborar en la identificación de las entidades.

No siempre es obvio saber si un objeto es una entidad, una relación o un atributo. Por ejemplo ¿cómo se podría clasificar matrimonio?.

Conforme se van identificando las entidades, se les dan nombres que tengan un significado y que sean obvias para el usuario. Los nombres de las entidades y sus descripciones se anotan en el diccionario de datos.

2. Identificar las relaciones. Una vez definidas las entidades, se deben definir las relaciones existentes entre ellas.

Del mismo modo que para identificar las entidades se buscaban nombres en las especificaciones de requisitos, para identificar las relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Conforme se van identificando las relaciones, se les van asignando nombres que tengan significado para el usuario y se anotan en el diccionario de datos los nombres de las relaciones, su descripción y las cardinalidades con las que participan las entidades en ellas.

La mayoría de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que también puede haber relaciones en las que participen más de dos entidades.

Es muy importante repasar las especificaciones para comprobar que todas las relaciones explícitas o implícitas, se han encontrado. Si se tienen pocas entidades, se puede comprobar por parejas si hay alguna relación entre ellas. De todos modos, las relaciones que no se identifican ahora se suelen encontrar cuando se valida el esquema con las transacciones que debe soportar.

3. Identificar los atributos y asociarlos a entidades y relaciones. Son atributos los nombres que identifican propiedades, cualidades, identificadores o características de entidades o relaciones. Lo más sencillo es preguntarse, para cada entidad y cada relación,

¿Que quiero se quiere saber de ...?

La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Al identificar los atributos, hay que tener en cuenta si son simples o compuestos. Por ejemplo, el atributo dirección puede ser simple, teniendo la dirección completa como un solo valor: `San Rafael 45, Colonia 2 de Abril; o puede ser un atributo compuesto, formado por la calle (`San Rafael'), el número (`45') y la población (`Colonia 2 de Abril').

El escoger entre atributo simple o compuesto depende de los requisitos del usuario. Si el usuario no necesita acceder a cada uno de los componentes de la dirección por separado, se puede representar como un atributo simple. Pero si el usuario quiere acceder a los componentes de forma individual, entonces se debe representar como un atributo compuesto.

También se deben identificar los atributos derivados o calculados, que son aquellos cuyo valor se puede calcular a partir de los valores de otros atributos. Por ejemplo, el número de empleados de cada oficina. Donde hay que considerar los atributos derivados es en el diseño físico.

...