Generalización: es el proceso según el cual se crea un conjunto de entidades a partir de otros que comparten ciertos atributos.
A veces existen situaciones en que sea conveniente crear una entidad como una fusión de otras, en principio, diferentes, aunque con atributos comunes. Esto disminuye el número de conjuntos de entidades y facilita el establecimiento de interrelaciones.
Por ejemplo, estamos modelando la gestión de una biblioteca, en la que además de libros se pueden consultar y prestar revistas y películas. Desde el punto de vista del modelo E-R, deberíamos crear conjuntos de entidades distintos para estos tres tipos de entidad, sin embargo, todos ellos tienen comportamientos y características comunes: préstamos, ubicaciones, ejemplares, editorial. También tienen atributos específicos, como el número de revista, o la duración de la película.
La idea es crear una entidad con una única copia de los atributos comunes y añadir los atributos no comunes. Además se debe añadir un atributo que indique que tipo de entidad estamos usando, este atributo es un discriminador.
La desventaja de la generalización es que se desperdicia espacio de almacenamiento, ya que sólo algunos de los atributos no comunes contienen información en cada entidad, el resto se desperdicia.
La ventaja es que podemos establecer el mismo tipo de interrelación con cualquier entidad del conjunto. En nuestro ejemplo, en lugar de tener que establecer tres interrelaciones de péstamo, o ubicación, bastará con una de cada tipo.
Es el proceso inverso al de generalización, en lugar de crear una entidad a partir de varias, descomponemos una entidad en varias más especializadas.
Especialización: es el proceso según el cual se crean varios tipos de entidades a partir de uno. Cada una de los conjuntos de entidades resultantes contendrá sólo algunos de los atributos del conjunto original.
La idea es lógica: si la generalización tiene ventajas e inconvenientes, cuando los inconvenientes superan a las ventajas, será conveniente hacer una especialización.
Por ejemplo, para gestionar la flota de vehículos de una empresa usamos un único conjunto de entidades, de modo que tratamos del mismo modo motocicletas, utilitarios, limusinas, furgonetas y camiones. Pero, desde el punto de vista de mantenimiento, se pueden considerar entidades diferentes: cada una de ellas tiene revisiones distintas y en talleres diferentes. Es decir, las diferencias superan a los atributos comunes. Este conjunto de entidades es un buen candidato a la especialización.
En realidad, es irrelevante si una entidad en fruto de una generalización o de una especialización, no deja de ser una entidad, y por lo tanto, no afecta al modelo.
No hay unanimidad total con respecto a la representación de diagramas E-R, he encontrado algunas discrepancias en los distintos documentos que he consultado, dependiendo de la variedad concreta del modelo que usen. Pero a grandes rasgos todos están de acuerdo en lo que expondremos aquí.
Las entidades se representan con un rectángulo, y en su interior el nombre de la entidad:
Las entidades débiles pueden representarse mediante dos rectángulos inscritos. Ya sabemos que existe una dependencia de existencia entre la entidad débil y la fuerte, esto se representa también añadiendo una flecha a la línea que llega a la entidad débil.
Los atributos se representan mediante elipses, y en su interior el nombre del atributo:
Algunas variantes de diagramas E-R usan algunas marcas para indicar que cierto atributo es una clave primaria, como subrayar el nombre del atributo.
También es frecuente usar una doble elipse para indicar atributos multivaluados:
Atributo multivaluado: (o multivalorado) se dice del atributo tal que para una misma entidad puede tomar varios valores diferentes, es decir, varios valores del mismo dominio.
Las interrelaciones se representan mediante rombos, y en su interior el nombre de la interrelación:
En los extremos de las líneas que parten del rombo se añaden unos números que indican la cantidad de entidades que intervienten en la interrelación: 1, n. Esto también se suele hacer modificando el extremo de las líneas. Si terminan con un extremo involucran a una entidad, si terminan en varios extremos, (generalmente tres), involucrarán a varias entidades:
Sobre las líneas a veces se añade el rol que representa cada entidad:
A veces es conveniente añadir información sobre el dominio de un atributo, los dominios se representan mediante hexágonos, con la descripción del dominio en su interior:
Un diagrama E-R consiste en representar mediante estas figuras un modelo completo del problema, proceso o realidad a describir, de forma que se definan tanto las entidades que lo componen, como las interrelaciones que existen entre ellas.
La idea es simple, aparentemente, pero a la hora de construir modelos sobre realidades concretas es cuando surgen los problemas. La realidad es siempre compleja. Las entidades tienen muchos atributos diferentes, de los cuales debemos aprender a elegir sólo los que necesitemos. Lo mismo cabe decir de las interrelaciones. Además, no siempre está perfectamente claro qué es un atributo y qué una entidad; o que ventajas obtenemos si tratamos a ciertos atributos como entidades y viceversa.
Al final, nuestra mejor arma es la práctica. Cuantos más problemas diferentes modelemos más aprenderemos sobre el proceso y sobre los problemas que pueden surgir. Podremos aplicar la experiencia obtenida en otros proyectos, y, si no reducir el tiempo empleado en el modelado, al menos sí reducir los retoques posteriores, el mantenimiento y el tiempo necesario para realizar modificaciones sobre el modelo.
Podemos dividir el proceso de construir un modelo E-R en varias tareas más simples. El proceso completo es iterativo, es decir, una vez terminado debemos volver al comienzo, repasar el modelo obtenido y, probablemente, modificarlo. Una vez satisfechos con el resultado (tanto nosotros, los programadores, como el cliente), será el momento de pasar a la siguiente fase: el modelo lógico.
Uno de los primeros problemas con que nos encontraremos será decidir qué son entidades y qué atributos.
La regla principal es que una entidad sólo debe contener información sobre un único objeto real.
Pero en ciertos casos esto nos puede obligar a crear entidades con un único atributo. Por ejemplo, si creamos una entidad para representar una persona, uno de los atributos puede ser el lugar de nacimiento. El lugar de nacimiento: población, provincia o país, puede ser considerado como una entidad. Bueno, yo creo que un país tiene muchas y buenas razones para ser considerado una entidad. Sin embargo en nuestro caso concreto, tal vez, esta información sea sólo eso: un lugar de nacimiento. ¿Debemos pues almacenar esa información como un atributo de persona o debemos, por el contrario, crear una entidad independiente?.
Una regla que puede ayudarnos en esta decisión es que si una entidad sólo tiene un atributo, que sirve para identificarlo, entonces esa entidad puede ser considerara como un atributo.
Otro problema frecuente se presenta con los atributos multivaluados.
Por ejemplo, cada persona puede ser localizada en varios números de teléfono. Considerando el teléfono de contacto como un atributo de persona, podemos afirmar que tal atributo es multivaluado.
Pero, aunque como su propio nombre indica no dejan de ser atributos, es mejor considerar a los atributos multivaluados como entidades débiles subordinadas. Esto nos evitará muchos problemas con el modelo lógico relacional.
Para crear un diagráma conceptual hay que meditar mucho. No hay un procedimiento claro y universal, aunque sí se pueden dar algunas directrices generales:
Quiero hacer notar que, la mayor parte del proceso que hemos explicado para crear un diagrama E-R, también puede servir para crear aplicaciones, aunque no estén basadas en bases de datos.
Existen varias extensiones al modelo E-R que hemos visto, aunque la mayor parte de ellas no las vamos a mencionar.
Una de ellas es la cardinalidad de asignación, que se aplica a atributos multivaluados. Consiste en establecer un número mínimo y máximo de posibles valores para atributos multivaluados.
Por ejemplo, en nuestra entidad persona habíamos usado un atributo multivaluado para los teléfonos de contacto. Habíamos dicho que, para evitar problemas en el modelo lógico, era mejor considerar este atributo como una entidad. Sin embargo hay otras soluciones. Si por ejemplo, establecemos una cardinalidad para este atributo (0,3), estaremos imponiendo, por diseño, que para cada persona sólo puede haber una cantidad entre 0 y 3 de teléfonos de contacto. Si esto es así, podemos usar tres atributos, uno por cada posible teléfono, y de ese modo eliminamos el atributo multivaluado.
No siempre será posible establecer una cardinalidad. En el ejemplo planteado se la elegido de una forma completamente arbitraria, y probablemente no sea una buena idea. En otros casos sí existirá una cardinalidad clara, por ejemplo, en un automóvil con cinco plazas, las personas que viajen en él tendrán una cardinalidad (1,5), al menos tiene que haber un conductor, y como máximo otros cuatro pasajeros.
Otra posible extensión consiste en algo llamado "entidad compuesta". En realidad se trata de una interrelación como las que hemos visto, pero a la que se añaden más atributos.
Por ejemplo, en la relación de matrimonio entre dos personas, podríamos añadir un atributo para guardar la fecha de matrimonio.
© Enero de 2005 Salvador Pozo, salvador@conclase.net