Mejor Practica?

Si, es correcto. Yo prefiero 'separar' las demas entidades en distintas
tablas pues se ve bastante claro que son distintas entidades. Ademas,
siguiendo las reglas de normalizacion es lo mas natural.


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Isaias" escribió en el mensaje
news:

Antonio

Tal vez te refieras al PUESTO, que ocupa un EMPLEADO en la compañia

Saludos
IIslas


"Antonio Ortiz" wrote:

Yo solo dejaria Vendedores y Empleados juntos, pues es muy posible que
'Vendedores' sea un subconjunto de datos de Empleados y por tanto
tendrias
datos duplicados. Bastaria con un campo 'TipoEmpleado'.


saludos,

Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"JHenao" escribió en el mensaje
news:
> Saludos,
> Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> El escenario : un sistema en el que intervienen Clientes, Vendedores,
> Proveedores y Empleados.
> En dilema:
> ¿Como regla general, Seria buena practica unir estas entidades en una
> sola
> tabla ya que son similares y establecer la diferencia a través de un
> campo
> tipo, o es mejor que
> conserven la independencia?
>
> Personalmente soy amigo de la segunda pero me plantearon la otra
> alternativa
> y la verdad no estoy seguro.
>
> JHenao
> MCP
> Medellín - Colombia
>

Ricardo,

Existen casos en que la union ayuda a evitar redundancia en los datos, que
es a la final lo que el modelo relacional trata de evitar. Para esto se usan
las entidades Super-tipos y Sub-tipos (posiblemente la traduccion esta mal
por mi parte).

Supertypes and Subtypes
http://64.233.161.104/search?q=cache:KmiIw-Pp1mIJ:www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt+supertypes+and+subtypes+and+relational+modeling&hl=en&gl=us&ct=clnk&cd


AMB


"Ricardo Passians" wrote:

Para mi es una MUY MALA PRACTICA de diseño de BD querer juntarlas en una
sola. Recuerda que son ENTIDADES (conjuntos) diferentes y por tanto con
reglas declarativas de integridad diferentes. Imagina por ej. que el
cliente o el proveedor sean una empresa, o que un vendedor no sea
necesariamente un empleado, o que los empleados requieran necesariamente
especificar su sueldo, su puesto y departamento, etc. etc., cuantas
excepciones tendrías que manejar? No crees que sería innecesariamente
costoso el mantenimiento?

Me parece que tu confusion viene de uno de esos viejos vicios de los
programadores de tratar de ver orientación a objetos (OO) en una BD
relacional para luego erroneamente manejar las reglas de integridad desde la
aplicacion. Todo lo que sea una entidad o una relación diferenciada debes
presentarla en una tabla independiente y usar el propio SGBD para definir
las reglas de integridad y/o negocios hasta donde sea posible.

Ricardo Passians




"JHenao" wrote in message
news:
> Saludos,
> Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> El escenario : un sistema en el que intervienen Clientes, Vendedores,
> Proveedores y Empleados.
> En dilema:
> ¿Como regla general, Seria buena practica unir estas entidades en una
> sola
> tabla ya que son similares y establecer la diferencia a través de un
> campo
> tipo, o es mejor que
> conserven la independencia?
>
> Personalmente soy amigo de la segunda pero me plantearon la otra
> alternativa
> y la verdad no estoy seguro.
>
> JHenao
> MCP
> Medellín - Colombia
>

Hola,
Es interesante el articulo, pero aplica para bd's relacionales??
si es asi es como se estableceria la 'herencia' a travez de una relación?

Gracias!!

JHenao
MCP
Medellín - Colombia


"Alejandro Mesa" escribió:

Ricardo,

Existen casos en que la union ayuda a evitar redundancia en los datos, que
es a la final lo que el modelo relacional trata de evitar. Para esto se usan
las entidades Super-tipos y Sub-tipos (posiblemente la traduccion esta mal
por mi parte).

Supertypes and Subtypes
http://64.233.161.104/search?q=cache:KmiIw-Pp1mIJ:www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt+supertypes+and+subtypes+and+relational+modeling&hl=en&gl=us&ct=clnk&cd


AMB


"Ricardo Passians" wrote:

> Para mi es una MUY MALA PRACTICA de diseño de BD querer juntarlas en una
> sola. Recuerda que son ENTIDADES (conjuntos) diferentes y por tanto con
> reglas declarativas de integridad diferentes. Imagina por ej. que el
> cliente o el proveedor sean una empresa, o que un vendedor no sea
> necesariamente un empleado, o que los empleados requieran necesariamente
> especificar su sueldo, su puesto y departamento, etc. etc., cuantas
> excepciones tendrías que manejar? No crees que sería innecesariamente
> costoso el mantenimiento?
>
> Me parece que tu confusion viene de uno de esos viejos vicios de los
> programadores de tratar de ver orientación a objetos (OO) en una BD
> relacional para luego erroneamente manejar las reglas de integridad desde la
> aplicacion. Todo lo que sea una entidad o una relación diferenciada debes
> presentarla en una tabla independiente y usar el propio SGBD para definir
> las reglas de integridad y/o negocios hasta donde sea posible.
>
> Ricardo Passians
>
>
>
>
> "JHenao" wrote in message
> news:
> > Saludos,
> > Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> > El escenario : un sistema en el que intervienen Clientes, Vendedores,
> > Proveedores y Empleados.
> > En dilema:
> > ¿Como regla general, Seria buena practica unir estas entidades en una
> > sola
> > tabla ya que son similares y establecer la diferencia a través de un
> > campo
> > tipo, o es mejor que
> > conserven la independencia?
> >
> > Personalmente soy amigo de la segunda pero me plantearon la otra
> > alternativa
> > y la verdad no estoy seguro.
> >
> > JHenao
> > MCP
> > Medellín - Colombia
> >
>
>
>

JHenao,

Es interesante el articulo, pero aplica para bd's relacionales??

Es parte de su metodologia.

si es asi es como se estableceria la 'herencia' a travez de una relación?

Depende de las reglas de tu negicio. La restriccion de integridad se crea en
el subtipo referenciando la clave primaria del supertipo.

Fijate que tambien pueden existir otras restricciones ligadas a
"Completeness" y/o "Disjointedness".

Tenemos dos reglas para "Completeness", especializacion completa o parcial.
Al igual que para "Disjointedness", los subtipos pueden solaparse o ser
disyuntivos.

En este link se explica un poquito mejor, ademas de mostrar mas ejemplos.

The Enhanced E-R Model and Business Rules
http://mis2.uis.edu/fall99/mis542/c...w04L01.htm


AMB




"JHenao" wrote:

Hola,
Es interesante el articulo, pero aplica para bd's relacionales??
si es asi es como se estableceria la 'herencia' a travez de una relación?

Gracias!!

JHenao
MCP
Medellín - Colombia


"Alejandro Mesa" escribió:

> Ricardo,
>
> Existen casos en que la union ayuda a evitar redundancia en los datos, que
> es a la final lo que el modelo relacional trata de evitar. Para esto se usan
> las entidades Super-tipos y Sub-tipos (posiblemente la traduccion esta mal
> por mi parte).
>
> Supertypes and Subtypes
> http://64.233.161.104/search?q=cache:KmiIw-Pp1mIJ:www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt+supertypes+and+subtypes+and+relational+modeling&hl=en&gl=us&ct=clnk&cd
>
>
> AMB
>
>
> "Ricardo Passians" wrote:
>
> > Para mi es una MUY MALA PRACTICA de diseño de BD querer juntarlas en una
> > sola. Recuerda que son ENTIDADES (conjuntos) diferentes y por tanto con
> > reglas declarativas de integridad diferentes. Imagina por ej. que el
> > cliente o el proveedor sean una empresa, o que un vendedor no sea
> > necesariamente un empleado, o que los empleados requieran necesariamente
> > especificar su sueldo, su puesto y departamento, etc. etc., cuantas
> > excepciones tendrías que manejar? No crees que sería innecesariamente
> > costoso el mantenimiento?
> >
> > Me parece que tu confusion viene de uno de esos viejos vicios de los
> > programadores de tratar de ver orientación a objetos (OO) en una BD
> > relacional para luego erroneamente manejar las reglas de integridad desde la
> > aplicacion. Todo lo que sea una entidad o una relación diferenciada debes
> > presentarla en una tabla independiente y usar el propio SGBD para definir
> > las reglas de integridad y/o negocios hasta donde sea posible.
> >
> > Ricardo Passians
> >
> >
> >
> >
> > "JHenao" wrote in message
> > news:
> > > Saludos,
> > > Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> > > El escenario : un sistema en el que intervienen Clientes, Vendedores,
> > > Proveedores y Empleados.
> > > En dilema:
> > > ¿Como regla general, Seria buena practica unir estas entidades en una
> > > sola
> > > tabla ya que son similares y establecer la diferencia a través de un
> > > campo
> > > tipo, o es mejor que
> > > conserven la independencia?
> > >
> > > Personalmente soy amigo de la segunda pero me plantearon la otra
> > > alternativa
> > > y la verdad no estoy seguro.
> > >
> > > JHenao
> > > MCP
> > > Medellín - Colombia
> > >
> >
> >
> >

Mira a lo largo de los años ha habido muchos intentos de tratar la herencia
en el modelo relacional pero muchas vueltas y los resultados terminan
volviendo a lo básico. Ademas quien dice que la normalizacion tiene que ser
100% estricta? Todo depende de lo costoso que resulte desnormalizar un
poquito.
Para el caso que hablamos pues si el compañero insiste, lo que pudiera es
crear una nueva SUPER-entidad (quizas "persona", aunque no aplicaria para
empresas) que incluya SOLO los campos comunes de todas las demas mas una PK
artificial, pero por supuesto que deberá seguir teniendo las demas
separadas y enumeradas como entidades independientes pero solo con los
atributos no comunes y una referencia a la PK de la "super-entidad". O este
criterio pudiera aplicarlo solo para algunas tablas.


"Alejandro Mesa" escribió en el
mensaje news:

Ricardo,

Existen casos en que la union ayuda a evitar redundancia en los datos, que
es a la final lo que el modelo relacional trata de evitar. Para esto se
usan
las entidades Super-tipos y Sub-tipos (posiblemente la traduccion esta mal
por mi parte).

Supertypes and Subtypes
http://64.233.161.104/search?q=cache:KmiIw-Pp1mIJ:www.cbe.wwu.edu/misclasses/mis421s04/presentations/supersubtype.ppt+supertypes+and+subtypes+and+relational+modeling&hl=en&gl=us&ct=clnk&cd


AMB


"Ricardo Passians" wrote:

Para mi es una MUY MALA PRACTICA de diseño de BD querer juntarlas en una
sola. Recuerda que son ENTIDADES (conjuntos) diferentes y por tanto con
reglas declarativas de integridad diferentes. Imagina por ej. que el
cliente o el proveedor sean una empresa, o que un vendedor no sea
necesariamente un empleado, o que los empleados requieran necesariamente
especificar su sueldo, su puesto y departamento, etc. etc., cuantas
excepciones tendrías que manejar? No crees que sería innecesariamente
costoso el mantenimiento?

Me parece que tu confusion viene de uno de esos viejos vicios de los
programadores de tratar de ver orientación a objetos (OO) en una BD
relacional para luego erroneamente manejar las reglas de integridad desde
la
aplicacion. Todo lo que sea una entidad o una relación diferenciada
debes
presentarla en una tabla independiente y usar el propio SGBD para definir
las reglas de integridad y/o negocios hasta donde sea posible.

Ricardo Passians




"JHenao" wrote in message
news:
> Saludos,
> Me gustaría que me aconsejaran en una decisión de diseño de una BD.
> El escenario : un sistema en el que intervienen Clientes, Vendedores,
> Proveedores y Empleados.
> En dilema:
> ¿Como regla general, Seria buena practica unir estas entidades en una
> sola
> tabla ya que son similares y establecer la diferencia a través de un
> campo
> tipo, o es mejor que
> conserven la independencia?
>
> Personalmente soy amigo de la segunda pero me plantearon la otra
> alternativa
> y la verdad no estoy seguro.
>
> JHenao
> MCP
> Medellín - Colombia
>