01.19.08
¿Herencia en BBDD?
El otro día en un curso de Business Intelligence surgió un caso como este.
Imaginaos que tenemos una base de datos donde almacenamos información al respecto de proveedores, clientes, trabajadores, representantes y convocatorias.
En un momento dado se quieren enviar invitaciones a los diferentes proveedores, clientes… y se quiere tener constancia a nivel de base de datos de quiénes han sido invitados a cada convocatoria.
No sé por qué me vino a la cabeza inmediatamente una solución orientada a objetos, así que intenté plasmar la idea a nivel de modelo relacional, surgiendo algo similar a esto:
Como véis, la herencia se ve a simple vista. La clase invitado es una clase abstracta de la cual heredan tanto el representante, como el proveedor, cliente y trabajador. Para resolver la herencia a nivel de modelo relacional las cuatro tablas inferiores guardan foreign key contra invitado. Además podréis ver que en la tabla LINEA_CONVOCATORIA se tiene referencia a la tabla INVITADO, con esto hacemos algo similar a pasar a un método por parámetro la clase abstracta, para que luego en tiempo de compilación, y según el objeto que se pase (y que obligatoriamente tendrá que heredar de invitado), se actue en consecuencia.
¿Problemas de esto? Mantener a base de datos puede ser como mínimo extraño. El campo CO_INVITADO de todas las tablas debería admitir NULL (por cierto hay una errata en el diagrama al respecto ya que como podéis ver es NOT NULL, y por eso la cardinalidad hacia INVITADO aparece siempre como 1, cuando debería ser 0..1). Además, fijaros en el detalle de que la tabla INVITADO tiene un campo llamado TABLA. Allí almacenaríamos el nombre de la tabla donde realmente está el invitado… jejeje, aquí es donde se pierde la historia y me deja de gustar el tema, pero es la única manera que se me ocurrió resolver de dónde sacar de dónde viene el invitado cuando empezamos a buscar a partir de la tabla LINEA_CONVOCATORIA, es decir, lo que sería en tiempo de compilación que se te pasara un objeto INVITADO y resolver dependiendo de si el objeto es un proveedor, cliente…
Esto solución resulta como mínimo curiosa. ¿Se os ocurre cómo mejorarla? ¿Proponéis alternativas?
En el curso se dijo de resolver esto a nivel de Triggers, y dejarse de historias. A mi sinceramente, no me gustan los Triggers, pero eso no quiere decir que no sean la mejor forma de resolver este tipo de problemas.
Saludos!
Miguel.
Muz said,
January 29, 2008 at 6:36 pm
Hola he leido tu articulo y he pensado otra posible solución a lo del campo tabla. Una solución alternativa que se me ocurre es parametrizar, por ejemplo podriamos asignar el grupo 001 -> 100 para los representantes, 101-> 200 para proveedores etc..
Saludos
Miguel said,
January 30, 2008 at 8:33 pm
Sirve, claro, pero tiene el problema de que si tenemos más ocurrencias que el rango definido para cada una de las entidades con las que contamos (representantes, proveedores…) entonces el sistema falla… y lo peor es cómo lo redefinimos sobre la marcha para aumentar el rango… eso sería más complicado aún resolverlo porque los rangos superiores estarían copados por las otras entidades. Podríamos jugar con rangos más grandes y con mayor separación entre ellos, pero al final ante un número infinito de inserciones siempre existiría un caso que tendríamos que ampliar.
Gracias por la aportación!