Normalización BD
 

Me imagino que este es un tema bastante recurrente para muchos programadores... cual es la mejor forma de estructurar una BD relacional.

Una misma situación resuelta de dos maneras.

Caso 1:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id_usuario, id_empresa) PK: id_usuario, id_empresa
rendiciones (id_usuario, id_empresa, nren, tipo) PK: id_usuario, id_empresa, nren
detrendiciones (id_usuario, id_empresa, nren, ncorr, detalle) PK: id_usuario, id_empresa, nren, ncorr

Caso 2:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id, id_usuario, id_empresa) PK: id
rendiciones (id, id_ue, nren, tipo) PK: id
detrendiciones (id, id_ren, ncorr, detalle) PK: id

Siguiendo con la lógica del caso 2, la clave primaria siempre sería simple, es decir un solo campo... esto es correcto?

Si bien yo solo planteo un ejemplo, creo que es aplicable a cual situación.

Cual es la forma correcta de desarrollar esto?
Existe una única forma correcta?
Como lo plantearía ustedes?

Espero me puedan guiar a la mejor resolución de mi problema.
Gracias

Hola
Me da la impresion de que por simpleza la opcion 2 es mejor, pero no creo que se pueda aplicar en todos los casos.
Ahora: ¿Es realmente necesario poner todas estas claves primarias?.
Saludos

Gracias cara po tu pronto respuesta.

Si no pongo las claves primaras como está expuesto, como lo harías tu?

Cual es la forma que plantea la teoría de como se hace esto?
Me imagino que esa es la forma correcta de hacerlo.

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

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

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

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

Hola
No se pero a mi me sobra una tabla.
Saludos

¿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

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,

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.

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,

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":
Aunque pienso que debiera existir una cuarta entidad :rolleyes: 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...:)

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,

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

Amigo, igual que lo anterior; depende.

Sigo igual; depende.

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

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,

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 :D :p
Pues ahorita no puedo amigo. Desde el ajuste de tornillos que siento que se me hace más difícil realizar esas largas exposiciones. :o

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. :D :p ;)

Saludos,

resp
 

La relacion entre tablas de una base de datos depende de su cardinalidad.
Si es de 1 a 1 se usa una clave foranea en una de las tablas
Si es de 1 a n se usa una clave foranea en la tabla n
Si es de n a n se crea una nueva tabla con ambas claves foraneas.

Y como siempre recomiendo no hay mejor normalizacion que la que sale de un buen diagrama de entidad relacion. Ya que muchas veces las formas normales se rompen en algunos casos por eso no normalizo usando dichas formas normales(ese es mi criterio y eso me dice la practica). Cada quien en libre de eleigir como normalozar su bd.