Entidades débiles y jerarquías

Una entidad fuerte o regular se sostiene sola: existe con independencia de cualquier otra y se puede identificar con sus propios atributos. Un alumno o un curso son entidades fuertes.

Una entidad débil, en cambio, solo significa algo colgada de otra entidad, llamada entidad fuerte o propietaria, a través de una relación que se denomina relación identificadora. La línea de un pedido no significa nada sin el pedido; un intento de test no significa nada sin el test al que corresponde.

La consecuencia práctica es que una entidad débil necesita algo que le dé identidad. Ese algo procede siempre de la entidad fuerte, entera o en parte, y por eso su identificación nunca es autónoma.

La prueba para reconocer una entidad débil es preguntarse si la ocurrencia sigue teniendo sentido cuando desaparece la entidad de la que depende. Si no lo tiene, es débil.

La debilidad tiene dos grados y distinguirlos es de lo que más se pregunta del subtema.

En la dependencia en existencia, la entidad débil necesita a la fuerte para poder existir, pero tiene un atributo propio que la identifica sin ayuda. Una factura que solo se emite si hay un pedido detrás depende en existencia del pedido; ahora bien, su número de factura la identifica ella sola, así que no depende en identificación.

En la dependencia en identificación (también llamada dependencia en identidad), la entidad débil no solo necesita a la fuerte para existir: además no tiene ningún atributo propio capaz de identificarla. Su clave se forma combinando la clave de la entidad fuerte con un atributo suyo llamado discriminante o clave parcial, que solo distingue dentro de un mismo propietario.

Es lo que ocurre con los ejemplares físicos de un manual en una biblioteca: uno y otro son indistinguibles si se miran por separado, y solo se identifican diciendo que son el ejemplar número tres de ese manual. Toda dependencia en identificación arrastra dependencia en existencia; al revés no.

Dependencia en existencia: no puede existir sin la otra, pero se identifica sola. Dependencia en identificación: además necesita la clave de la otra para identificarse.

Una jerarquía de generalización recoge en el modelo la relación «es un»: un empleado técnico es un empleado, un alumno de Curso Express es un alumno. Hay un supertipo con lo común y varios subtipos con lo particular de cada uno. Es la herencia de la programación orientada a objetos llevada al modelo de datos.

Se puede llegar a ella por dos caminos, y el nombre cambia según el camino. La generalización va de abajo arriba: se detectan atributos comunes en varios tipos de entidad y se extraen a un supertipo. La especialización va de arriba abajo: se parte de un tipo de entidad general y se descubre que ciertos ejemplares tienen atributos o relaciones propias que los demás no tienen.

Los subtipos heredan del supertipo tanto los atributos como las relaciones, y añaden los suyos. La clave del supertipo es también la clave de cada subtipo, lo que evita que un mismo ejemplar aparezca dos veces con identidades distintas.

El atributo discriminador es el que indica a qué subtipo pertenece cada ocurrencia del supertipo. Es un atributo del supertipo, con un valor por subtipo, y su papel se ve claro cuando la jerarquía se transforma en tablas: si toda la jerarquía se implementa con una sola tabla, el discriminador es lo único que distingue las filas de un subtipo de las de otro.

Una jerarquía no queda descrita solo con nombrar sus subtipos. Hacen falta dos restricciones que responden a dos preguntas distintas, y de ellas salen cuatro combinaciones posibles.

La primera pregunta es si todo ejemplar del supertipo tiene que pertenecer a algún subtipo. Si la respuesta es sí, la jerarquía es total y la cardinalidad mínima del supertipo es 1. Si puede haber ejemplares que no encajen en ninguno, es parcial y la mínima es 0.

La segunda pregunta es si un ejemplar puede pertenecer a varios subtipos a la vez. Si solo puede pertenecer a uno como máximo, la jerarquía es disjunta o exclusiva. Si puede pertenecer a varios, es solapada o no disjunta.

Total o parcial responde a la mínima: si es obligatorio pertenecer a algún subtipo. Disjunta o solapada responde a la máxima: a cuántos subtipos se puede pertenecer a la vez.

La agregación es un recurso del modelo E/R extendido que permite tratar una relación entera, con las entidades que enlaza, como si fuera una única entidad de nivel superior, para poder relacionarla a su vez con otra cosa.

Se necesita cuando aparece una relación entre una relación y una entidad, que el modelo básico no admite. Si un alumno realiza un intento de un test y hace falta registrar qué tutor ha revisado esa realización concreta, no se puede unir «tutor» a la relación «realiza» directamente: se agrega el bloque formado por alumno, test y la relación entre ambos, y esa agregación es la que se relaciona con tutor.

Sirve también como recurso de legibilidad: agrupar un trozo de un diagrama grande y tratarlo como una caja permite razonar sobre el conjunto sin perderse en el detalle. No hay que confundirla con la agregación de UML, que expresa una relación de todo y parte entre clases.