El diagrama de entidad-relación (también conocido como DER, o diagrama E-R) es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.
¿Porque podríamos estar interesados en modelar los datos de un sistema?. Primeramente, porque las estructuras de datos y las relaciones pueden ser tan complejas que se deseará enfatizarlas y examinarlas independientemente del proceso que se llevará a cabo. De hecho, esto se da sobre todo si mostramos el modelo del sistema correspondiente a los usuarios ejecutivos quienes se preocupan más por los datos: ¿Qué dato requerimos para manejar nuestro negocio? ¿Quién lo tiene? ¿Quién tiene acceso a ellos?.
Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones entre almacenes de datos en el DFD que de otra forma se hubiera visto sólo en la especificación de procesos. Por ejemplo, un DER típico se muestra en la figura siguiente. Cada una de las cajas rectangulares corresponden a un almacén de datos en DFD y puede verse que hay relaciones que normalmente no se aprecian en un DFD.
Diagrama de entidad-relación típico.
Hay cuatro componentes principales en un diagrama de entidad-relación:
- Tipos de objetos.
- Relaciones.
- Indicadores asociativos de tipo de objeto.
- Indicadores de supertipo/subtipo.
Tipos de objetos
El tipo de objeto se representa en un diagrama de entidad-relación por medio de una caja rectangular; en la figura siguiente se muestra un ejemplo. Representa una colección de objetos (cosas) del mundo real cuyos miembros individuales o instancias tienen las siguientes características:
- Cada una puede identificarse de manera única por algún medio. Por ejemplo, si se tiene un tipo de objeto conocido como cliente, debemos ser capaces de distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su número de Seguro Social).
Un tipo de objeto
En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación del sistema de algo material del mundo real. Esto significa que los clientes, artículos de inventario, empleados, partes manufacturadas, etc., son objetos típicos. El objeto es algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estratégias y mapas.
Una persona (o cualquier cosa material) pudiera ser diversos tipos de objetos distintos en distintos modelos de datos, o incluso en un mismo modelo. Juan Pérez, por ejemplo puede ser empleado en un modelo de datos y cliente en otro. También pudiera ser empleado y cliente dentro del mismo modelo.
Relaciones
Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo. La figura 4.2.3 muestra una relación sencilla, que pudiera existir entre dos o más objetos.
Una relación
Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro. Así, en la figura anterior, la relación etiquetada como compras puede contener las siguientes instancias individuales:
- Instancia 1: el cliente 1 compra el artículo 1
- Instancia 2: el cliente 2 compra los artículos 2 y 3.
- Instancia 3: el cliente 3 no compra ningún artículo.
La relación representa algo que debe ser recordado por el sistema: algo que no pudo haberse calculado ni derivado mecánicamente. Así, el modelo de datos de la figura anterior indica que existe alguna razón relacionada con el usuario para recordar el hecho de que el cliente 1 compra el artículo 1, etc. Y también indica que no existe nada priori que hubiera permitido determinar que el cliente 1 compró el artículo 1 y nada más.
Notación alternativa para relaciones
El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier dirección. Y no muestran cardinalidad, es decir, no muestran el número de objetos que participan en la relación.
Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad como la ordinalidad.
Indicadores asociativos de tipo de objeto
El indicador asociativo de tipo de objeto representa algo que funciona como objeto y como relación. Por ejemplo, un cliente que adquiere un artículo. En donde la relación de compra no hace más que asociar un cliente con uno o más artículos. Pero suponga que existen datos que deseamos recordar acerca de cada instancia de una compra (por ejemplo a qué hora del día se hizo). ¿Dónde se podría almacenar dicha información? "Hora del día" no es un atributo de cliente, ni de artículo. Más bien, se asocia "Hora del día" con la compra misma, y esto se muestra en un diagrama como el que ilustra la figura siguiente.
Indicador asociativo de tipo objeto
Nótese que compra ahora se escribe dentro de una caja rectangular conectada por medio de líneas dirigidas, a un rombo de relación sin nombre. Esto pretende indicar que compra funciona como:
- Un tipo de objeto, algo acerca de lo cual se desea almacenar información. En este caso la hora en la cual se realizó la compra y el descuento, que se dio al cliente.
- Una relación que conecta los dos tipos de objetos cliente y artículo. Lo que significa aquí es que cliente y artículo se mantienen solo. Existirían con o sin la compra.
Indicadores de subtipo/supertipo
Los tipos de objetos de subtipo/supertipo consisten en tipos de objeto de una o más subcategorías, conectados por una relación. La figura 4.2.6 muestra un subtipo /supertipo típico: la categoría general es empleado y las subcategorias son empleados asalariados y empleado por horas. Nótese que los subtipos se conectan al supertipo por medio de una relación sin nombre. Note también que el supertipo se conecta con una línea que contiene una barra.
Indicador de subtipo/supertipo
Reglas para la construcción de diagramas de Entidad- Relación.
El primer DER típicamente se creará a apartir de entrevista iniciales con el usuario, y de su conocimiento de la materia en cuanto al negocio del usuario. Después de desarrollar el primer DER, el siguiente paso es asignar los datos del sistema a los diversos tipos de objetos. Se supone, que se sabe cuales son los datos. Esto puede suceder en cualquier de tres maneras:
1. Si el modelo del proceso (DFD) ya se ha desarrollado o se está desarrollando paralelamente al modelo de datos, entonces el diccionario de datos ya existirá.
2. Si el modelo del proceso no se ha desarrollado o no tiene intención de desarrollar, entonces pudiera tener que empezar por entrevistar a todos los usuarios apropiados para construir una lista exhaustiva de datos y sus definiciones.
3. Si está trabajando con un grupo de administración de datos, hay una buena probabilidad de que ya exista un diccionario de datos, que podría obtener durante el proyecto.
Existe un número de situaciones en las que los refinamientos del DER llevan a la eliminación de tipos de objetos y relaciones redundantes o erróneas. Las más comunes son:
1. Tipos de objetos que consisten en un identificador.
2. Tipos de objetos para los cuales existe una sola instancia.
3. Tipos asociativos de objetos flotantes.
4. Relaciones derivadas.
No hay comentarios:
Publicar un comentario