Normalización BD

[[Delphius]]

Empezado por Caral

Hola

No se pero a mi me sobra una tabla.
Saludos

No sobra amigo. Esa tabla que señalas es una tabla intermedia entre Usuarios y Empresas. De no estar presente esta tabla, la relación sería (1:M) y aquí lo que se busca es en realidad (M:M): que un usuario pueda estar en más de una empresa, y que a su vez en una empresa estén muchos (y por tanto, diferentes) usuarios.

Como te han dicho: no está del todo claro la estructura de tus tablas. Por favor no seas tan simplón en tus palabras. Explícate apropiadamente. Cuando más nos puedas decir al respecto más fácil se nos hará comprenderte.

Comprendo bien el uso de las tres primeras que describes, pero las dos restantes no le encuentro forma, uso y unión con el resto. No se aprecia la relación que se busca.

Respondiendo a tus preguntas iniciales:

Cual es la forma correcta de desarrollar esto?
La forma correcta es analizar el negocio o contexto. De dicho análisis surgen las entidades, sus campos y relaciones. No hay receta mágica que indique como llevar el diseño de un DB.

Existe una única forma correcta?
No. Como he dicho: no hay receta, el análisis lo dirá. Incluso en lo que hace al estilo de clave primaria simple vs compuesta; aunque en lo general son pocos los escenarios donde se estilan y se necesitan de claves compuestas.

Cada persona puede tener su propio diseño de una base de datos. Mientras se responda a las necesidades y requisitos estará bien. Habrá quienes "complican" el diseño en un lado para hacerlo más fácil en otro.

Como lo plantearía ustedes?
De las respuesta a 1 y 2 se debería entender que en realidad depende de un análisis del caso y ya cada uno hará su interpretación... no necesariamente todos vamos a coincidir. Cada uno lo podría interpretar diferente. Así como está expresado en tus palabras... hay mucho peligro de que se interprete cualquier cosa respecto a las tablas rendiciones y detrendiciones.

Si te explicas mejor quizá podamos ofrecerte guías, alternativas y sugerencias y podamos llegar a cierto consenso.

Saludos,

[guillotmarc]

Yo siempre opto por el caso 2.

Personalmente no me gustan las claves múltiples. Siempre utilizo claves primarias simples (caso 2) y hago las relaciones maestro-detalle mediante esa clave simple de relación (lógicamente, en un nuevo campo de clave foranea dentro de la tabla de detalle).

NOTA: Te recomiendo que utilices siempre el mismo nombre de campo. Es decir, que no pongas ID como campo de clave primaria en todas las tablas, sino que por ejemplo en la tabla de usuarios pongas el campo de clave primaria como ID_USUARIO, y que en todas las tablas relacionadas pongas el campo de clave foránea con exactamente el mismo nombre ID_USUARIO. Resulta menos confuso ver las relaciones si los campos se llaman igual tanto en el maestro como en el detalle.

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

[[Caral]]

Hola
Sigo pensando (aunque no es el tema) que no se necesita la tabla intermedia.
Es como cuando se quiere que un usuario tenga acceso a una parte determinada del programa, no se necesita una tabla para indicar a que parte entrara o no.
Lo mismo, si quiero que un usuario tenga acceso a la empresa X no necesito una tabla para ese fin.
Se le puede dar acceso a las empresas que uno quiera sin necesidad de tablas extras.
Una tabla extra representa: Mas mantenimiento, mas datos que buscar y leer, mas lentitud, mas espacio, etc., etc...
Entonces; Si se puede hacer de otra manera NO se necesita, solo se hace por que se quiere, no por necesidad.
Es solo mi opinion, pero no me gusta complicarme la vida.
Saludos

[[Delphius]]

Empezado por Caral

Hola
Sigo pensando (aunque no es el tema) que no se necesita la tabla intermedia.
Es como cuando se quiere que un usuario tenga acceso a una parte determinada del programa, no se necesita una tabla para indicar a que parte entrara o no.
Lo mismo, si quiero que un usuario tenga acceso a la empresa X no necesito una tabla para ese fin.
Se le puede dar acceso a las empresas que uno quiera sin necesidad de tablas extras.
Una tabla extra representa: Mas mantenimiento, mas datos que buscar y leer, mas lentitud, mas espacio, etc., etc...
Entonces; Si se puede hacer de otra manera NO se necesita, solo se hace por que se quiere, no por necesidad.
Es solo mi opinion, pero no me gusta complicarme la vida.
Saludos

Disculpa amigo, pero no entiendo. Es necesaria esta tabla intermedia entre Empresas y Usuarios. Si el problema indica y da a entender la cardinalidad de (M:M) o "muchos a muchos", es justificable y necesaria esta tabla intermedia para poder relacionar más de una instancia muchas veces. De otro modo sólo podría esperarse un caso de (1:M).

Es por ello que tanto rgstuamigo como yo hemos insistido en una descripción más detallada y completa. Debe evaluarse objetivamente el contexto a fin de determinar la cardinalidad. Algo fundamental para para poder establecer el diseño de las tablas y sus relaciones.

La teoría del álgebra relacional y de las reglas normales que ha mencionado rgstuamigo así lo indican: Una relación (M:M) debe "romperse" añadiendo una tabla intermedia para establecer dos vínculos (1:M). Luego se normalizan estas tablas.

No entiendo lo que comentas y el objetivo que planteas. Disculpa.

Saludos,

[[Caral]]

Empezado por Delphius

......
De otro modo sólo podría esperarse un caso de (1:M).

Amigo, esto no es cierto, Depende de como se haga la tabla y campos.

Empezado por Delphius

.......
Algo fundamental para para poder establecer el diseño de las tablas y sus relaciones.

Amigo, igual que lo anterior; depende.

Empezado por Delphius

La teoría del álgebra relacional y de las reglas normales que ha mencionado rgstuamigo así lo indican: Una relación (M:M) debe "romperse" añadiendo una tabla intermedia para establecer dos vínculos (1:M). Luego se normalizan estas tablas.

Sigo igual; depende.

Empezado por Delphius

No entiendo lo que comentas y el objetivo que planteas. Disculpa.

Entiendo tu punto.
No pretendo ningun objetivo, solo digo que no es necesario crear una tabla adicional para que un usuario pueda acceder a mas de una empresa.
La relacion la puedo hacer de muchas maneras sin necesidad de crear una tabla.
Estoy seguro que tu tambien podrias hacerlo sin nigun problema.
Saludos

[[Delphius]]

Puede ser Carlos, puede ser que pueda... aunque seguramente si siguiera ese enfoque muy posiblemente esté rompiendo algunas reglas normales y no conseguiría una buena normalización.

Admito que en ocasiones es deseable cierto grado de desnormalización, pero creo que para este caso, se perderían algunas virtudes y ventajas que ofrece unas buenas tablas bien estructuradas, índices y claves primarias y foráneas para agilizar las cosas.

Una de las maravillas del álgebra relacional y las reglas normales es la de eliminar la redundancia y de establecer vínculos fuertes que luego dan mayores capacidades.
Y creeme, no por añadir una tabla se hace las cosas más complejas. Si fueran 15 o más allí creo que si se podría aceptar tu planteo amigo.

Se pone mucho énfasis en la normalización porque con una buena estructuración se aprovecha mejor las capacidades del motor, las consultas tienden a ser más sencillas, rápidas y estables... Y si mjjj está llevando esto para algun trabajo de la universidad con más razón debe verse que se han aplicado las reglas normales... Son muy exigentes los profesores en esto.

Ya nos dirá mjjj.

Saludos,

[[Caral]]

Hola
Si amigo, se que es una manera de hacer las cosas y me imagino que debe ser la mejor.
Solo que aveces como buen alumno trato de que ampliéis las dudas.
Si no planteo una posibilidad es difícil que aprenda.
Yo estoy de acuerdo con lo que dices, solo que me gusta exprimiros el conocimiento, como puedo aprender si no es asi.
Gracias amigo por la paciencia.
Saludos

[[Delphius]]

Empezado por Caral

Hola
Si amigo, se que es una manera de hacer las cosas y me imagino que debe ser la mejor.
Solo que aveces como buen alumno trato de que ampliéis las dudas.
Si no planteo una posibilidad es difícil que aprenda.
Yo estoy de acuerdo con lo que dices, solo que me gusta exprimiros el conocimiento, como puedo aprender si no es asi.
Gracias amigo por la paciencia.
Saludos

Ha... ya veo, tu lo que quieres es que redacte mis típicos testamentos y que me explote la cabeza
Pues ahorita no puedo amigo. Desde el ajuste de tornillos que siento que se me hace más difícil realizar esas largas exposiciones.

Como tu ya sabes amiguito: habrá que acostumbrarse a que de a poquito la pandilla New se vaya despidiendo. Va a ser un tantito más aburrido, pero bueno hacía falta eso y a mis amigos ya no le estaba gustando que se colasen cada vez que nos juntábamos... reconozco que en ocasiones eran una mala influencia.

Saludos,

[JoAnCa]

Empezado por Caral

Hola
Sigo pensando (aunque no es el tema) que no se necesita la tabla intermedia.
Es como cuando se quiere que un usuario tenga acceso a una parte determinada del programa, no se necesita una tabla para indicar a que parte entrara o no.
Lo mismo, si quiero que un usuario tenga acceso a la empresa X no necesito una tabla para ese fin.
Se le puede dar acceso a las empresas que uno quiera sin necesidad de tablas extras.
Una tabla extra representa: Mas mantenimiento, mas datos que buscar y leer, mas lentitud, mas espacio, etc., etc...
Entonces; Si se puede hacer de otra manera NO se necesita, solo se hace por que se quiere, no por necesidad.
Es solo mi opinion, pero no me gusta complicarme la vida.
Saludos

Pues para que entiendas lo de la tabla intermedia, amigo Caral

Están las tablas Empresas y Usuarios (o empleados), un ejemplo ubicandote en la vida práctica
- Un empleado pudiera trabajar en varias empresas
- En una empresa trabajan varios empleados

Que relacion hay entre la empresa y el empleado?
Pues, Un Contrato, si no tienes un contrato con la empresa no puedes trabajar en ella

Ese Contrato es la "famosa" tabla intermedia que se necesita para relacionar a las empresas con los empleados, quedando por ejemplo de esta forma:

Empresas: CodEmp, NombreEmpresa, ...
Empleados: IdEmpleado, CodEmp, NombreEmpleado, ...
Contrato: NroCont, CodEmp, IdEmpleado, Puesto, FechaInicio, ...

Entiendes ahora?

mjjj
Como bien ya te han comentado
Las relaciones dependen del problema en cuestion, lo primero es leer y analizar bien la problemática, para poder deducir que tablas dependen de otra (relacion 1 a varios), analizar tambien las relaciones que tienen cada posible campo para ver en que tabla se pone, y evitar duplicados

Explicando la problemática, mas de uno de nosotros te podrá ayudar con el diseño de las relaciones

Tambien para entender un poco esto, puedes estudiar la Normalizacion de Bases de Datos