Mejor Practica?

Oye, como se implementa eso en SQL Server 2000 ?


"Alejandro Mesa" wrote in message
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
>

Ricardo,

Estoy de acuerdo con tu comentario. No he dicho que lo que el quiere hacer
es lo correcto, solo
hago referencia ha que este tipo de entidades suele usarse en determinados
casos. Un ejemplo
es cuando modelamos el horario (schedule) de clases en alguna escuela o
universidad. En este caso
tendriamos alumnos y profesores (plantilla de la escuela o contratados para
ciertos cursos).

No se porque querria modelar empresa y empleado bajo una super-entidad.

Saludos,

AMB

"Ricardo Passians" wrote:

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