Inicio > Departamentos > Informática > Análisis de Sistemas II
Inicio
Presentación
Programa
Bibliografía
Docentes
Horarios
Exámenes
Apuntes

Apuntes > Herramientas del Análisis Estructurado > Diagrama de Entidad-Relación

Diagramas de Entidad- Relación.

 

 Porqué son útiles los Modelos de Datos en el Análisis de Sistemas.

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.

¿Por qué podríamos estar interesados en modelar datos en un sistema?

En primer lugar 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.

El diagrama de entidad- relación es una herramienta efectiva de modelado para comunicarse con el grupo de administración de base de datos. Basándose en la información presentada por el DER, este grupo puede ver el tipo de claves o índices o apuntadores que se necesitarán para llegar de manera eficiente a los registros de las bases de datos.

Para el analista, el DER representa un gran beneficio también: enfatiza las relaciones entre almacenes de datos en el DFD que de otra forma se hubieran visto solo en la especificación de proceso.

 

 Los componentes de un DER.

Existen cuatro tipos de componentes principales en un diagrama de Entidad- Relación:

  1. Tipos de objetos.
  2. Relaciones.
  3. Indicadores asociativos de tipo de objeto.
  4. Indicadores de supertipo/ subtipo.

 Tipos de objetos.

Se representa en un DER por medio de una caja rectangular. Representa una colección o conjunto 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. Existe alguna forma de diferenciar entre instancias individuales del tipo de objeto.

 Cada uno juega un papel necesario en el sistema que se construye. Es decir para que el tipo de objeto sea legitimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros.

 Cada uno puede describirse por uno o más datos.

 

 

 

Un tipo de Objeto.

El objeto es algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto también puede ser algo no material: por ejemplo horarios, planes, estándares, estrategias, mapas, etc.

 

 Relaciones.

Los objetos se conectan entre si mediante relaciones. Una relación representa un conjunto de conexiones entre objetos. 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.

La relación representa algo que debe ser recordado por el sistema, no pudo haberse calculado o derivado mecánicamente.

Puede existir más de una relación entre dos objetos.

Notaciones alternativas para Relaciones.

 

 Representación mediante rombo, no puede indicarse cardinalidad ni orden.

  Notación de punto ancla, el inconveniente no deja visible el nombre de la relación.

En el ejemplo, el cliente es el punto ancla, objeto primario desde el cual debe leerse la relación.

 

La relación consiste en un cliente conectado con N artículos, el cliente podrá adquirir de 0 a N artículos, pero se indica que solo habrá un cliente en cada instancia de relación.

 

Notación flecha de dos puntas, alternativa para relaciones de 1 a muchos, mientras que se emplea una flecha simple o línea simple; para relaciones de 1 a 1. Aparece el nombre de la relación.

 

 Indicadores Asociativos de Tipo de Objetos.

Esta es una notación especial, representa algo que funciona como objeto como relación. Otra forma de considerarlo es que el tipo asociativo de objeto representa una relación acerca de la cual se desea mantener alguna información.

Por ejemplo imaginemos una relación compra entre cliente y artículo, pero supongamos que deseamos recordar datos acerca de la instancia de cada compra como hora del día en que se hizo, entonces estos atributos corresponden a la compra; no corresponde almacenarlos en articulo ni en cliente.

Compra funcionará ahora como tipo de objeto del cual almacenaremos información; una relación que conecta los tipos de objeto Articulo y Cliente que existirán con o sin la Compra. La Compra depende de la existencia de Cliente y Articulo.

 

  Indicadores de Subtipo / Supertipo.

Los tipos de objetos de objetos de Subtipo / Supertipo consisten en tipos de objetos de una o más sub- categorías conectados por una relación.

Por ejemplo una categoría general Empleado y las sub- categorías son Empleado Asalariado y Empleado Por Horas. Los subtipos se conectan al supertipo por una relación sin nombre, el supertipo se conecta a la relación por una línea que tiene una barra.

 

En esta notación el supertipo se describe por datos que se aplican a todos los subtipos, por ejemplo todos los empleados se describen por:

nombre

domicilio particular

años de servicio

Por el contrario cada subtipo se describe por medio de datos diferentes, de otro modo no haría falta hacer distinción entre ellos.

Por ejemplo Empleado Asalariado se describe por:

salario mensual

porcentaje anual adicional

Y el Empleado por Horas por:

paga por hora

cantidad por tiempo extra

hora de comienzo

 

 Reglas para la construcción de Diagramas de Entidad- Relación.

El modelo inicial de objetos y relaciones usualmente se derivara de 1) su comprensión de la aplicación del usuario, 2) entrevistas con el usuario, 3) cualquier otro tipo de recolección e investigación de información que pueda usar.

No debe esperar que el primer diagrama de E-R que haga sea el final, que revisará con el usuario o entregará al diseñador del sistema. Como todas las demás herramientas de modelado, los diagramas de E-R deben revisarse y mejorarse muchas veces. La primer versión será solo un borrador y las demás versiones se realizarán utilizando una serie de reglas de refinamiento que se presentan a continuación.

 Añadir tipos de objetos adicionales.

Después de haber desarrollado el primer DER, el siguiente paso es agregar datos del sistema a los diversos tipos de objetos.

El proceso de asignación puede ofrecer una de tres razones para crear nuevos tipos de objetos:

 Es posible encontrar datos que pueden asignar a algunas instancias de un tipo de objeto pero no a otras.

En este caso se necesitará crear un conjunto de subtipos abajo del tipo de objeto con el que ha estado trabajando, y asignar los datos específicos a los subtipos apropiados. Por ejemplo en el desarrollo de un sistema de personal y se identifica un tipo de objeto Empleado. Muchos de los datos se aplican a todas las instancias de un empleado, como fecha_de_contratación, pero luego se descubren datos como numero- de- embarazos que debe atribuirse solo a empleadas. Esto llevaría a crear Empleados Varones y Empleadas como subtipos de la categoría general de Empleado.

  Pueden descubrirse datos aplicables a todas las instancias de dos objetos distintos.

 

Si esto ocurre, deberá crearse un supertipo nuevo y asignarle los datos comunes al supertipo. Por ejemplo, tal vez se identificó Cliente de Contado y Cliente a Crédito como dos tipos de objetos distintos cuando se creó el DER para un sistema de pedidos. Sin embargo, existen datos como nombre_del_cliente y domicilio_del_cliente describen ambos tipos de cliente de la misma forma, lo cual apoyaría la creación de un supertipo Cliente.

 

 Puede descubrirse que algunos datos describen relaciones entre otro tipo de objetos.

 

En estos casos debería reemplazarse la relación desnuda entre los dos objetos con un tipo asociativo de objeto. Por ejemplo en un primer borrador de DER existe una relación de Compra entre Cliente y Articulo. Durante la asignación de datos puede encontrarse con que hay un dato fecha- de- compra que 1) parece pertenecer a la relación Compra y 2) proporciona datos acerca de la interacción de un Cliente con un Artículo. Esto sugiere que debe sustituirse la relación de Compra por un tipo asociativo de objeto.

 

 Por ultimo, podrían presentarse grupos que se repiten. Por ejemplo consideremos el tipo de objeto Empleado con los datos obvios que lo componen como nombre, domicilio, etc. Suponiendo que hay datos adicionales como nombre_del_hijo, edad_del_hijo, etc. Entonces podríamos describir un objeto nuevo llamado Hijo, porque existen múltiples instancias de información relacionadas con los hijos de cada instancia de un Empleado y cada instancia de información relacionada se define de manera única por el nombre_del_hijo. El proceso de eliminar objetos incluidos en otros es parte de una actividad de refinamiento más general llamada normalización.

 

 

  Eliminar Tipos de Objetos.

Existe un buen 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óneos. Examinaremos cuatro situaciones comunes:

 Tipos de objetos que consisten solo en un identificador.

Existe en estos casos la oportunidad de eliminar el tipo de objeto y asignar el identificador, como dato a un tipo de objeto relacionado.

Este refinamiento solo tiene sentido si existe una correspondencia uno a uno entre instancias del objeto que está a punto de ser eliminado e instancias del objeto relacionado.

Por ejemplo imagine que se creo para un sistema de personal dos tipos de objetos Empleado y Cónyuge, relacionados por una relación Casado con. Durante el proceso de asignar datos a los diversos objetos, puede descubrirse que el único dato que se guarda del Cónyuge es su nombre. En este caso el refinamiento será eliminar Cónyuge como tipo de objeto e incluir nombre- del- cónyuge como dato dentro del objeto Empleado.

 

 Tipos de objetos para los cuales existe solo una instancia.

Por ejemplo imaginemos que se muestra la relación entre Paciente y Medicamentos de un hospital, pero supongamos que la única información que se guarda acerca del medicamento es su nombre y supongamos también que el hospital sólo administra un tipo de medicamento. En este caso el medicamento es una constante y no tiene que mostrarse en el diagrama. Esto significa que el diagrama no tendría un almacén de datos llamado Medicamentos.

 

 

 

  Tipos asociativos de objetos flotantes.

Recordando el ejemplo anterior del hospital, sí como antes se sugirió Medicamento es un objeto de instancia única, solo con identificador, entonces se eliminaría. Pero supongamos ahora que Tratamiento es un tipo de objeto asociativo entre Paciente y Medicamento; aunque ahora se conecte solo con un tipo de objeto sigue siendo un tipo de objeto asociativo. Esto se conoce como tipo de objeto asociativo flotante, es legitimo en un DER aunque poco usual.

 

 

 Relaciones derivadas.

Las relaciones que pueden derivarse o calcularse deben eliminarse del DER, debe mostrar los requerimientos para los datos almacenados.

Por ejemplo si la relación Renovar entre Conductor y Licencia puede calcularse basándose en alguna fecha, entonces debe eliminarse. Esto lleva a que los tipos de objetos no están conectados, no es necesario que todos los tipos de objetos estén conectados entre sí.