tabla relacional en modelado

[Kritik]

Te estás complicando mucho. Y el diseño es más fácil.

Tienes que ver de la tabla persona qué campos se pueden englobar en un tipo menor. Por ejemplo, datos de contacto. Los datos de contacto de una persona son bastantes campos (Teléfono, dirección, código postal e incluso datos de contacto virtuales como email o página web). Así pues, todos esos campos única y exclusivamente van a pertenecer a 1 persona, y son todo el conjunto. No puede haber ninguna otra persona que repita exactamente todos los mismos datos de contacto. Un hermano puede vivir en el mismo sitio, y tener el mismo teléfono... pero no tener el mismo email. Así pues puedes sacar todos los datos de contacto de la tabla persona, datos que están directamente relacionados con la tabla persona y así disminuir la cantidad de campos que tienes en la tabla persona, y a su vez... enlazarlos todos ellos al PK de la tabla persona. De forma que, por ejemplo todos los registros de contacto vayan enlazados al PK que tengas en la tabla persona, También has de pensar qué campo/s conviertes en PK de tu tabla persona. Tiene que se un campo/s que no puedan ser repetidos nunca. Por ejemplo, el DNI (salvo errores administrativos que de vez en cuando surgen) o Nombre+Apellido1+Apellido2+nºDNI (esos 4 campos como pk ya es mega-difícil que se vayan a duplicar por mucho error que haya habido con repetición de nºs de DNI...

Y de esa forma, otros datos directamente enlazados a la persona, como pueden ser datos de salud (grupo sanguíneo, alergias, etc) pueden ir también enlazados a tu PK de la tabla persona, porque cada registro de tu tabla salud va con una relación 1-1 a la tabla persona. Una persona solo puede tener un registro de salud, y un registro de salud, con todos sus datos solo puede pertenecer a 1 persona. (o si lo prefieres M-1... 1 registro de salud puede pertenecer a varias personas, porque varias personas pueden tener el mismo grupo sanguíneo y las mismas alergias)

De forma que no necesitas otras claves foráneas en la tabla persona.

Ahora bien... tú quieres que una persona adquiera propiedades laborales según la oficina en la que esté, por lo que creas un campo oficina que te enlaza a las propiedades especificadas en la tabla oficina. Y lo mismo te pasa con otro tipo de propiedades que según cambian te adquieren unas propiedades y otras provenientes de otras tablas. Y de esa forma tienes, como dices, muchísimas tablas.

Bueno, pues en ese caso... lo que te pasa es que tienes los datos mal organizados. Quizás no debas enlazar todas las tablas a la tabla persona. Los tipos de topología pueden ser mixtos también. Puedes tener una estrella en la que todas las tablas dependan de persona, o puedes tener algunas tablas que dependan de las que dependen de persona. O puedes englobar los datos para poder juntar 2 tablas y así simplificar el problema.

Tabla 1: (2 campos)
Registro 1:
A B
Tabla 2:(2 campos)
Registro 1:
1 2
Suma de Tabla 1+2:(2 campos) (O como las quieras juntar)
Registro 1:
A 1
Registro 2:
A 2
Registro 3:
B 1
Registro 4:
B 2

-----------------

Edito:

Después de haber leído un poco sobre tu problema concreto... es cierto que una persona no puede llevar en su tabla todos los derechos que su puesto de trabajo le proporciona. La sección donde trabaja, quien es su jefe, quienes son sus subordinados.... eso no puede depender directamente de la persona... sino que esas cosas dependen de su puesto de trabajo. De forma que si una persona es trasladada de un departamento a otro... con solo cambiar el campo puesto de trabajo ya se le cambian todas las cosas que dependen del puesto de trabajo... su jefe, sus subordinados, las carpetas a las que tiene acceso en la red, etc. Todo eso depende no de la persona, sino de su puesto de trabajo.

De esa forma, tienes una topología mixta... en la que no todas las tablas dependen directamente de persona, sino que hay tablas que enlazan a otras que a su vez esas otras dependen de persona. O incluso en 3 o más niveles. Aunque siga siendo una estrella, puede ser que de una tabla que vaya directamente a persona le salgan 2 ramajes a 2 tablas... o 3, o 4... Dependiendo de la complejidad de tu programa.
Por ejemplo la tabla comisiones según objetivos puede depender del puesto de trabajo, en el caso de que el trabajo sea comercial. Y la tabla de coches de empresa dependen de la tabla trabajo siempre que el trabajo sea comercial o dirección. Pero a su vez la tabla que relaciona todos los gastos de los coches de empresa, los diferentes talleres, etc dependen de la tabla de coches de empresa... toda esa información no puede ir en persona, ni en trabajo... sino que son tablas que dependen de tablas que dependen de tablas que dependen de persona.

Como ves... no todo tiene que ser una pura estrella en la que todas las tablas vayan directamente a persona. Sino que aun siendo una estrella, puede ser una estrella de estrellas, o un árbol... como tú lo quieras organizar. Pero eso si, en cada tabla solo hay información directamente relacionada con el propósito de la tabla. En la tabla persona solo hay información de la persona, no del tipo de gasolina que utiliza su coche, ni de nada que no sea una propiedad de la persona. Y lo mismo pasa con el resto de tablas. Cada tabla única y exclusivamente tiene información sobre las propiedades del objeto para lo que está hecha esa tabla.

Otro ejemplo de tabla mal diseñada es aquella en la que se guarda información sobre las características de una planta, su altura, el tipo de hoja, etc... en la tabla de insectos. La tabla insectos única y exclusivamente guarda características de los insectos. Como puede ser el nombre de la planta de la cual se alimenta. Pero no las propiedades de la planta... eso estará en la tabla plantas.

A veces es difícil abstraer el problema de la vida real en un sistema de tablas... pero es que el trabajo de un programador no se limita única y exclusivamente a picar código... sino que para programar bien, diseñar buenas bases de datos, hay que saber bien como abstraer el problema a un sistema informático. Sea una manera de como organizar los datos, o sea la manera en la que un programa ha de ir ejecutándose. Pero cuantas más veces abstraigas problemas de la vida real a sistemas informáticos... mejor te saldrán.