Normalización BD

[mjjj]

Explico un poco mas la situación.

La tabla usuarios contiene un listado de todos las personas que utilizan el programa.
La tabla empresas son las distintas empresas que se pueden escoger para trabajar en ellas.
La tabla empresa_usuario hace la relación que usuarios pueden utilizar que empresas.
La tabla rendiciones es la parte "maestra" o "encabezado" de las rendiciones que pueden hacer los distintos usuarios, además el correlativo (nren) es independiente por cada usuario en cada empresa.
La tabla detrendiciones es el "detalle" de la tabla rendiciones, en donde ncorr es el correlativo de los distintos items de la rendicion.

Espero se entienda mejor, gracias

[[Caral]]

Hola

Empezado por mjjj

Explico un poco mas la situación.

La tabla usuarios contiene un listado de todos las personas que utilizan el programa.
La tabla empresas son las distintas empresas que se pueden escoger para trabajar en ellas.
La tabla empresa_usuario hace la relación que usuarios pueden utilizar que empresas.
La tabla rendiciones es la parte "maestra" o "encabezado" de las rendiciones que pueden hacer los distintos usuarios, además el correlativo (nren) es independiente por cada usuario en cada empresa.
La tabla detrendiciones es el "detalle" de la tabla rendiciones, en donde ncorr es el correlativo de los distintos items de la rendicion.

Espero se entienda mejor, gracias

No se pero a mi me sobra una tabla.
Saludos

[mjjj]

¿Porque?

Como puedo saber que usuarios tienen acceso a la empresa "x".

En todo caso es lo que menos me preocupa... lo mas delicado esta en las tablas master-details (rendiciones-detrendiciones), con todas las complicaciones que expuse.

Alguna propuesta??

Gracias

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

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

[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