Diseño de Base de Datos HERENCIA

[Xavi_20]

Tengo una Duda que ya quiero quitármelo para comenzar a Programar los Procesos Almacenados y es esto, En la presente Imagen:



PERSONA es la Tabla General y de ahí Derivaremos si es CLIENTE, PROVEEDOR, TRABAJADOR, ya eso es Programación y Procesos Almacenados.

Pero bueno, tengo una Duda con Respecto a Cliente, mi CLIENTE puede ser Natural o Jurídico, por lo que he pensado en Poner un Campo Booleano en la tabla CLIENTE (agrego un campo llamado "Personanoj" que 1 sea Natural y 0 Jurídico) ¿Es Dable, Que Opinas?, Ahora si es persona Jurídica ¿donde queda el Nombre de razón social? pues lo que he pensado es que se Almacene en el Campo Nombre de la Tabla Persona. Quiero saber vuestra opinión. y si es que me das sugerencias para ir mejorandolo. Gracias.

[quimfv]

Si es PERSONA física o jurídica es un atributo de PERSONA no de cliente.... y apartir de ahí todo te funcionarà, un trabajador no , pero un proveedor tambien puede ser jurídico no?

[GuzmanDiaz18]

Claro tienes razón, ahora ya en la tabla persona he creado un campo llamado "naturaljuridico", me aceptara 1 y 0.

(1) Natural
(0) Jurídico

Es que no tenia una definición clara, mis Trabajadores también son Persona Naturales al Contar con un numero de RUC para trabajar como tal, ya que netamente estas personas deben de contarlos si o si.

Ahora mis Clientes, pueden ser Físicas o Jurídicas y mis Proveedores pueden ser Solamente Jurídicas.

Ahora creo que esta parte ya esta entendida, pero tengo otra y ultima Duda y es que ya si registro digamos un Cliente Jurídico o una Empresa Proveedor (Jurídica), Estas necesitara sus Personas de Contactos y/o Personas Legales, ¿como hago esta relación?, tendría que sacar otra relación de Cliente a Persona, o tendría que crear una tabla netamente para personas de contacto. gracias.

[quimfv]

Si la relacion es 1:n es decir cada persona jurídica puede tener n personas (fiscas) de contacto y una persona física no puede ser representante de mas de 1 persona jurídica. En este caso lo resuelves con un campo mas en persona para guardar el id de la persona representada....

Si la relación es n:m luego necesitas una tabla auxiliar con dos FK referenciadas a persona....

Otra solución es considerar que las personas de contacto son otro tipo de persona y guardarlas en una tabla a parte.... es muy posible que de esas personas no tengas todos los datos....aun que así en esencia estas forzando un poco el modelo.

[Xavi_20]

Y tu ¿como lo manejarias?, osea tanto Cliente, como Proveedor y Trabajador como lo manejarías, porque he visto que lo trabajan por tipos y todas los campos pasan a formar parte de la tabla persona.

[BSD_FAN]

amigo primero que todo en el modelo relacional no se habla de "HERENCIA", la herencia y el polimorfismo son casi exclusivos de la programcion orienta a objetos.

Cuando existe una relación no exclusiva por ejemplo una persona puede ser simultáneamente estudiante y docente se puede modelar con 2 tablas, sin son excluyentes incluyes los atributos en la misma tabla.

[quimfv]

El modelo teorico de tablas y el modelo físico no tienen por que ser iguales. Esta claro que se podria manejar en una sola tabla.... pero si te fijas en los campos que tienes para cada tipo de persona veras que para los trabajadores tienes muchos mas campos, luego para todos los clientes y proveedores esos campo propios del trabajador quedaran en blanco con lo que se usará mal el espació en disco....

Un apropuesta

Personas
Campos comunes a todas las personas

Trabajadores
Campos propios de los trabajadores

Terceros
Analizando un poco veras que practicamente clientes y proveedores pueden tener los mismos campos y con solo agregar un campo llamado tipo donde indique si es proveedor o cliente (o los dos, que se podria dar) te funcionará.


Contactos
No son personas de la tabla Personas, ya que con el identificador del tercero, un nombre y un telefono seguramente tienes bastante.

Luego yo crearia como minimo tres vistas para trabajar con mas comodidad

ViewTrabajadores
Trabajadores join Personas

ViewClientes
Terceros join Personas
where cientes

ViewProveedores
Terceros join Personas
where proveedores