[SOLUCIONADO] tabla relacional en modelado

[code0]

un saludo a todos compañeros, tengo una duda, sabemos que cuando una tabla (persona) tiene un numero grande de tablas relacionadas, lo mejor es hacer una tabla relacional para que minimice tantas concurrencias en relaciones a una sola tabla, pues tener 15 claves foráneas no es muy adecuado, la pregunta es como funciona esta tabla relacional en el momento de relacionarla, o sea a la tabla persona se asignan varios cargos (tablas) como lo son: sonidistas, vigilantes, diseñadores, publicistas, diseñadores, lideres, directores, etc.. estas son tablas las cuales el id de cada una forman una tabla relacional así:

Tabla relacional:

persona_servicio
id_sonidistas
id_vigilantes
id_diseñadores
id_publicistas
id_lideres
id_directores

espero me puedan ayudar, como hacer esta relacion, muchas gracias por su apoyo.

[gnzsoloyo]

Desde el vamos, eso está mal diseñado y peor relacionado.
Si tienes una relación entre persona y servicio, y tienes sonidistas, vigilantes, diseñadores, etc., lo que tienes mal es que has creado una tabla separando las personas por profesión.
Eso, disculpa que te lo diga, pero no sólo no tiene sentido, sino que además no lo he visto jamás, y si lo presentaras como TP en la universidad tendrías el reprobado de la materia asegurado sin más que mirar...
NUNCA se diseña una tabla de persona por profesión, sino que en todo caso tienes una relación entre persona y profesión. Y cuando se trata del servicio brindado por una persona con determinada profesión, dependerá de la construcción del sistema, ya que si se trata de empelados de la misma empresa, lo que se vincula es en todo caso el Empleado_id con el servicio prestado, mientras que el que pertenezca a una área profesional determinada está dado por si incorporación en un esquema de herencia/jerarquía, donde la entidad principal es empleado, y las hijas serán Servicio, Vigilancia, Sonido, Diseñador, Publicidad, Director, etc.


Así como lo lo muestras, se infiere qu eel diseño está realmente mal construido.

¿POdrías postear un DER de l a base para ver qué es lo que has hecho y poder darte algún consejo útil?

[code0]

Jmm que verguenza, claro que si compañero, ahi te va un ejemplo, muchas gracias por su tiempo, o sea que lo que me quiere decir, es que simplemente haga una tabla profesion? o en este caso, servicio, y luego este servicio , relacionarlo en la tabla persona?

[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.

[code0]

Ok me queda muy clara su explicación,,muchas gracias por su ayuda, me doy cuenta de mis errores tan grandes, muchas gracias, lo haré.