Normalización BD

[[Delphius]]

Bueno,
Pensé que mjjj se tomaría la molestia de aportar más información.

Yendo al plano técnico, hay ciertos motivos por el cual no emplear claves compuestas:
1. Tanto en Firebird como en Interbase, el rendimiento de estos tipos de claves primarias es considerablemente lento comparado con el uso de claves simples.
2. El uso de claves compuestas obliga a una coincidencia exacta entre todos los campos que la componen, lo cual hace único a cada combinación y no es posible luego hacer búsquedas particulares sobre un campo que lo componen.

Por ejemplo (1,1), (1,2) ... (1,N) son considerados diferentes.... Eso está claro. Pero luego si uno quiere buscar los registros que tengan (1,..) le es imposible ya que el índice es compuesto y espera como "entrada" la segunda parte.

para entender porqué son únicos cada combinación, hagamos de cuenta que hay dos registros con clave (NULL, NULL): (NULL, NULL)1 y (NULL, NULL)2. Para el ojo humano no hay diferencia... pero para el motor no es lo mismo el primero del segundo... internamente es como si cada uno tuviera un "ID". Un principio de la lógica relacional (y de la mátemática misma diría dice que NULL <> NULL y por tanto no hay NULL iguales.
Lo mismo sucede en los casos (1,NULL), (1,NULL).

Para tener un poco más en claro sobre claves léase esto.

La gran mayoría de las veces, y así lo deja expresado la naturaleza del problema, no es necesaria una clave compuesta; Aunque si bien el concepto de clave compuesta no viola los principios del álgebra relacional y las reglas normales.

Yo NUNCA he empleado una clave compuesta. Hasta ahora no he visto un caso que justifique su uso... aunque claro, esto no quiere decir que no tenga practicidad. He aplicado la forma 2.

Tiene su uso: cuando se necesita hacer único a un conjunto específico de campos para identificar esa instancia (registro) de la entidad (tabla). Es decir: cuando para poder identificar un registro de otro, se necesite obligadamente de la definición de dos o más de sus características.

O al menos, así es como recuerdo la teoría. Debo admitir que ya tengo un tanto oxidado los conceptos de bases de datos y normalización.

Saludos,

[rgstuamigo]

hummmm....bueno...Primeramente antes de crear tus tablas se debería haber determinado todas tus entidades y las relaciones que existen entre ellas, como tambien la cardinalidad y participacion.
Por ejemplo en tu caso puedo ver las siguientes "entidades":

Entidad Usuarios
Entidad Empresas
Entidad Rendicion.

Aunque pienso que debiera existir una cuarta entidad la cual va relacionada con la entidad "rendicion", de ahí que se genera el "detalle"., para lo cual me gustarías que explicaras más a fondo cada uno de los atributos(Campos o columnas) de tu tabla "detrendiciones" ,además si nos explicas que exactamente se va detallar en dicha tabla y con qué tiene que ver y/o cuál es su propósito; te digo ésto por que de acuerdo a tu respuesta o explicacion que nos dés, te puedo hacer un diseño de tus tablas siguiendo la teoría del modelo entidad relacion para ir progresivamente ir aplicando la normalizacion por lo menos hasta llegar a una tercera forma Normal(3NF)
Saludos...

[JoAnCa]

Empezado por Delphius

Bueno,
Yo NUNCA he empleado una clave compuesta. Hasta ahora no he visto un caso que justifique su uso... aunque claro, esto no quiere decir que no tenga practicidad. He aplicado la forma 2.

Tiene su uso: cuando se necesita hacer único a un conjunto específico de campos para identificar esa instancia (registro) de la entidad (tabla). Es decir: cuando para poder identificar un registro de otro, se necesite obligadamente de la definición de dos o más de sus características.

O al menos, así es como recuerdo la teoría. Debo admitir que ya tengo un tanto oxidado los conceptos de bases de datos y normalización.

Saludos,

Amigo Delphius, te pongo un ejemplo de donde se pueden aplicar las llaves compuestas:

Un Hospital tiene Varios Consultorios
Cada Consultorio pertenece a un Hospital

El campo llave del Consultorio será su número identificativo, que en el mismo Hospital no se repite, pero ese mismo número lo puede tener otro Consultorio en otro Hospital
Entonces el Consultorio tendría la llave compuesta IdHospital, NroConsultorio, así no importa que el nro de consultorio se repita, pues el del Hospital es diferente

Esto solo es un ejemplo, pero como bien dices, no es muy común que se den estas situaciones

[[Delphius]]

Empezado por JoAnCa

Amigo Delphius, te pongo un ejemplo de donde se pueden aplicar las llaves compuestas:

Un Hospital tiene Varios Consultorios
Cada Consultorio pertenece a un Hospital

El campo llave del Consultorio será su número identificativo, que en el mismo Hospital no se repite, pero ese mismo número lo puede tener otro Consultorio en otro Hospital
Entonces el Consultorio tendría la llave compuesta IdHospital, NroConsultorio, así no importa que el nro de consultorio se repita, pues el del Hospital es diferente

Esto solo es un ejemplo, pero como bien dices, no es muy común que se den estas situaciones

¿Podrías explicarte nuevamente? No termino de comprender el ejemplo.

Saludos,

[rastafarey]

Bueno sigo insistiendo que solo hay que hacer un diagrama de entidad relacion colocar la cardinalidad y listo eso da la base de datos que necesitan. no veo la comlicacion.

Explicando el ejemplo.

Tabla empresa
Id Nombre
1 Empresita
2 LaOtraEmpresa
3 UnaEmpresaMas

Caso 1
Un empleado puede trabajar en varias empresas

Tabla Empleado
Id Nombre
1 Pedro
2 Juan
3 Carmen

Tabla Relacion
Id IdEmpresa IdEmpleado
1 1 1
2 1 2
3 1 3
4 2 1

IdEmpresa+IdEmpleado = Clave primaria

Caso 2
Un empleado puede trabajar en uan sola empresa

Tabla Empleado
Id Nombre IdEmpresa
1 Pedro 1
2 Juan 1
3 Carmen 2

Se pueden plantear mas caso pero eso depende de la naturaleza del problema.

[lbuelvas]

Resp, consideraría que por la dinámica del tiempo, es posible que una persona trabaje para la misma empresa mas de una vez, por ejemplo, se vincula del año 2000 al 2005, se retira y vuelve a vincularse desde el 2010 en adelante.

Podriá considerarse como sugiere JoAnCa identificar la tabla con el "Numero del Contrato", siempre y cuando cada empresa tenga numeraciones diferentes; como estoes dificllograr, puede usarse una llave artificial como por ejemplo un numero consecutivo.

[rastafarey]

Para ese caso seria otro diagrama. Por digo que todo depende de la naturaleza del problema.

Si plantean un problema con anbiguedad generaremos muchas controversias y muchas respuestas y todo esto se deve a que cada quien tien un punto de vista.

Ahora si aclaramos todos los criterios que debes usarse no creo que se genere ambiguedad.

Les voy a plantear una situacion. Hace un tiempo estaba realizando un sistema donde debia realizar una tabla de parestesco entre personas y como todo progrmador que no nos gusta escribir en papel si hacerlo a vuelo pajaro siempre se llegaba a un punto que las tablas no funcionanban como debian, saben como lo sulucione un simple diagrama y a la final el diagrama me dijo que habia que hacer una sola tabla. Si no escribimos en papel y ahcemos el diagrama la mente nos va jugar muchas bromas que a la larga las vamos a pagar con perdida de tiempo y dinero. Y para emendar el capote vamos aterminar haciendo una chapuzada.

[lbuelvas]

Resp, encuentro ambiguedad en tu ultimo post, quede con la incertidumbre si estas dirigiendo el comentario a todo el mundo o a mi especificamente. Llevo el suficiente tiempo desarrollando sistemas de gestión e impartiendo catedra universitaria en diseño de bases de datos y me considero con autoridad para tratar el tema de este post.

Lo que he querido aportar es simplemente ampliar la visión de lo que pasa cuando diseñamos bases de datos y no las proyectamos a que su uso puede perdurar durante varios años para una organización y las "chapuzadas" pasan cuando siguiendo el planteamiento que propongo te dicen que el empleado volvió a trabajar en la empresa, me explico, en un momentum del tiempo, es decir si detienes el tiempo, una persona no puede trabajar mas de una vez en la misma empresa, pero si miras a lo largo de los años una persona si puede trabajar varias veces en diferentes temporadas en la misma empresa; ese pequeño detalle puede obligar a un cambio en el diseño de la base de datos y del aplicativo mismo.

Por las razones expuestas, me demoro un poco mas en el diseño tratando de preveer cambios a futuro, dejando flexible el modelo para responder rápidamente ante los cambios que se presenten en requerimientos por parte del cliente.

Y comento que cuando me enfrento a diseñar una base de datos utilizo como tu comentas lápiz y papel, además los modelos los documento con herramientas disponibles para ello, los imprimo y cunado estoy programando los tengo pegados a la pared para tener la visión global y detallada del proyecto.