SQL - duda identifying

Buenas, estoy empezando a diseñar una base de datos y antes de ponerme a crear tablas quiero tener claro si puedo hacer lo que tengo en mente.



Creo que uno de los problemas más importantes que tengo que solucionar es lo siguiente:

Quiero crear una tabla PERSONA con características generales que hereden las tablas EMPLEADO, DIRECTIVO, ARTISTA y PRODUCTOR, de momento.

A su vez, de la tabla EMPLEADO heredan sus características las tablas LIMPIEZA, INFORMATICO y ADMINISTRATIVO.


Mi duda no es cómo implementar la herencia de atributos. Lo que quiero hacer es que sea imposible crear una persona simplemente, sino que sea necesario crear una de las tablas "finales", como INFORMATICO.

Así, al crear una instancia de informático se crearía una instancia de empleado y otra instancia de persona (automáticamente).


Además de esto, querría que el ID_INFORMATICO (que sería la PK de INFORMATICO) llegara a EMPLEADO
y PERSONA como PK también, para que a la hora de filtrar las personas pueda ver directamente si esa persona es directivo, artista, si es empleado informático o administrativo, solo con la PK.



No tengo ni remota idea de si esto es posible, pero en mi cabeza me parece un esquema interesante.


Gracias de antemano.

Hola Jesus:

En un Modelo Entidad-Relación, para "heredar" los atributos de una tabla "padre" a una tabla "hija" lo que haces es incluir la llave principal de la tabla padre en la tabla hija como LLAVE FORANEA (FK).

Ahora bien, para la segunda parte de tu pregunta:

"Mi duda no es cómo implementar la herencia de atributos. Lo que quiero hacer es que sea imposible crear una persona simplemente, sino que sea necesario crear una de las tablas "finales", como INFORMATICO."

Esto en realidad es ya una lógica de negocio, que no tiene nada que ver con diseño de BD's en si, por lo tanto, esto lo tienes que controlar mediante PROCEDIMIENTOS ALMACENADOS (SP) y TRIGGERS y con el manejo de TRANSACCIONES.

Estrictamente, desde el punto de vista de diseño de BD's, sólo puedes asegurarte de que no existan tablas FINALES sin que existan las tablas PADRE (mediante FK) pero a la inversa, no puedes validarlo.

Es decir, que es perfectamente válido que puedan existir PERSONAS que no estén asociadas a EMPLEADOS, DIRECTIVOS, ARTISTAS o PRODUCTORES, pero no es posible que exista un EMPLEADO sin que exista un registro asociado en la tabla PERSONAS. ¿Se entiende?

Ahora bien, con el manejo de TRANSACCIONES, lo que te permite es manejar esta lógica de negocio en una capa separada del diseño. ya sea con transacciones directamente en la BD's utilizando SP o desde cualquier lenguaje de programación con el que estés trabajando.

Investiga un poco sobre este tema si es que no estás muy familiarizado.

Saludos
Leo.

Me es de gran ayuda las orientaciones que me das para saber sobre qué tengo que buscar información, porque acabo de empezar y sí que estoy perdido.

La solución a medias que pude encontrar con lo que sé es hacer las tablas padre no instanciables y que solo se puedan instanciar las finales, ya que me di cuenta -un rato despues de publicar mi duda- que quizás estaría duplicando o triplicando información en el esquema que había planteado.

Muchas gracias por contestar!!!!!!!!!