Generalización, agregación y asociación

Generalización:

El proceso de especialización expuesto en el punto anterior nos permite lo siguiente:

-Definir un conjunto se subclases a partir de una entidad.
-Asociar atributos específicos a cada subclase.
-Establecer relaciones específicas entre cada subclase con otras entidades o subclases.


Podemos pensar en un proceso inverso de abstracción en el cual suprimimos las diferencias entre las distintas entidades, identificando sus características comunes, y generalizando dichas entidades en una sola superclase de la cual las entidades iniciales serían subclases especiales. Por ejemplo, supongamos las entidades COCHE y CAMION de la figura 2(a); podremos generalizarlas en la entidad VEHICULO, como se muestra en la figura 2(b). Tanto COCHE como CAMION serán ahora subclases de la superclase generalizada VEHICULO. Usamos el término generalización para referirnos al proceso de definición de una entidad generalizada a partir de unas entidades dadas.

Hay que tener en cuenta que el proceso de generalización puede ser visto funcionalmente como el proceso inverso de especialización. Por tanto, en la figura 2 podemos ver {COCHE, CAMION} como una especialización de VEHICULO, así como VEHICULO puede verse como la generalización de COCHE y CAMION. De la misma forma podemos ver en la figura 1 a EMPLEADO como la generalización de SECRETARIA, TÉCNICO e INGENIERO. En algunas ocasiones se utilizan flechas para representar en los diagramas cual a sido la técnica de identificación de superclases/clases.

Agregación:

La agregación es un tipo especial de relación en el que se modela una semántica del tipo “tiene” o “es parte de”, en la que una entidad represente una entidad de mayor tamaño (el “todo”), compuesta de entidades más pequeñas (las “partes”).

Asociación:

Un modelo de datos debe especificar las asociaciones existentes entre las entidades. Estas asociaciones son las relaciones entre entidades. Por ejemplo, la frase "los clientes compran productos" nos dice que hay dos entidades, "Clientes" y "Productos", que están relacionadas por "comprar".

La gran mayoría de las asociaciones son binarias, como "los clientes compran productos" o "los empleados venden productos". Entre las dos hay una asociación ternaria implícita: "los empleados venden productos a los clientes". Con las dos asociaciones binarias independientemente no podríamos saber a qué clientes se han vendido los productos que ha vendido un cierto empleado: en este caso necesitamos de la asociación ternaria.

Las asociaciones entre dos entidades cualesquiera pueden ser de tres tipos: uno-a-uno, uno-a-muchos y muchos-a-muchos.

Asociaciones uno-a-uno: Si es cierto que cualquier ejemplar de la entidad X se puede asociar con tan sólo un ejemplar de la entidad Y, entonces decimos que la asociación es uno-a-uno. Cuando elegimos una asociación uno-a-uno debemos asegurarnos de que o bien se mantiene la asociación en todo momento, o en caso de que cambie no nos interesan los valores pasados.

Por ejemplo: si asumimos que en los despachos de un edificio hay uno por persona, entonces la asociación será uno-a-uno. Pero esta asociación sólo es cierta en un momento dado. A lo largo del tiempo, se irán asignando diferentes empleados en el edificio. Habrá que valorar si el mantenimiento de esta información es útil en nuestro modelo o no.

Asociaciones uno-a-muchos: Es el tipo de asociación más común, donde un solo ejemplar de una entidad se puede asociar con cero, uno o muchos ejemplares de otra entidad. Por ejemplo, una persona puede tener varios números de teléfono.

Asociaciones muchos-a-muchos: Los clientes compran en muchas tiendas, una tienda tiene muchos clientes. Como este tipo de relaciones no se puede modelar directamente en una base de datos relacional, se modela usando una tabla intermedia que tenga una asociación uno-a-muchos con cada uno de los participantes originales. Por ejemplo, un pedido puede tener muchos tipos de confección, y un tipo de confección puede aparecer en varios pedidos.