Normalización BD

[[Caral]]

Hola
No se cual es la mejor o la adecuada forma de hacerlo.
Yo no suelo usar claves primarias salvo en las tablas que contengan campos unicos o en tablas que tenga que ligar con otras (contados casos), en las demas simplemente no pongo nada.
No creo que sea el mas adecuado para decirte si es o no correcto.
Saludos

[Casimiro Noteví]

Para ayudar mejor haría falta saber más de las tablas y sus campos, por ejemplo, ¿qué es rendiciones y detrendiciones?

[Kipow]

Nada como el viejo entidad-relacion para poder aclarar eso si con una explicacion de cada una de las entidades.

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

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