|
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
Cita:
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 |
Cita:
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": Cita:
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 |
Cita:
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, |
Cita:
Cita:
Cita:
Cita:
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 |
Cita:
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. |
Hola amigos foristas, la pregunta planteada por el compañero mjjj es bastante interesante y ha sido tema de mutiples discusiones.
Quiero comentar sobre las tres primeras tablas. Ambas aproximaciones son válidas, sin embargo quiero replantear el modelo del negocio de la siguiente manera: Imaginemos que necesitamos registrar informacion sobre usuarios o clientes y tambien registrar la informacion de empresas; en cada empresa pueden laborar uno o mas usuarios y cada usuarios pueden trabajar en una o mas empresas. 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 Caso 2: Tablas: usuarios (id, nombre, apellido) PK: id empresas (id, nombre) PK: id empresa_usuario (id, id_usuario, id_empresa) PK: id Hay algo que normalmente no se enseña en cursos básicos de bases de datos y es la dinámica del tiempo. Cuando diseñemos bases de datos debemos pensar que el sistema se va a utilizar no por un año sino por un periodo de al menos 5 años. Los 2 modelos nos permite indicar el usuario para que empresa trabaja, pero preguntemonos: El usuario puede renunciar a una de las empresas y un tiempo despues puede volver a trabajar en esa misma empresa, en esta situación y solo con tres tablas el caso 1 no nos sirve, el caso 2 es mas flexible en cuanto a diseño. Esto nos lleva a que cuando nos encontremos con una relación m:n (eviten escribir m:m porque se estaría diciendo que existe igual numero de elementos en cada una de las entidades) pensemos en que no solo se resuelve con una tabla de asociación sino que esa tabla de asociación puede ayudarnos a "enriquecer" el modelo. Entonces esa tabla empresa_usuario podria quedar asi: empresa_usuario ( id not null, id_usuario not null, id_empresa not null, estado not null fecha_ingreso not null, fecha_egreso ) PK: id El campo estado puede decirnos si esta vinculado, suspendido, contrato cancelado,etc. Fecha de ingreso como su nombre lo indicanos dira cuando se establecio esa relación y fecha de egreso tendrá un valor null hasta que haya finalizado la relación del usuario con la empresa. Sobre si es mejor las tablas identificarlas con un identificador único entero (ID) es algo que defienden los puristas defensores del modelo orientado a objetos, es muy flexible pero la construcción de aplicaciones y elaboración de consultas es mas compleja y no tan eficiente como con la creación de llaves "relacionales" (mas de un atributo). Ambas aproximaciones (relacional y de objetos) tienen sus ventajas y desventajas, por eso utilizo una u otra o una mezcla de ambas dependiendo de la situación que deba resolver de forma que mantenga un equilibrio entre simplicidad y efciencia. |
resp
empresas
n | posee | n usuarios hay una relacion n a n lo cual da nacimiento a una tercera tabla la tabla de relaion entre epresas y cliente. solo hay que hacer un buen diagrama de entidad relecion poner la cardinalidad y el resultado sera la mejor base de datos que se pueda disenar. |
Cita:
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 |
Cita:
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 |
Cita:
Saludos, |
Resp
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. |
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. |
Resp
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. |
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. |
Resp
Bueno segun veo no estamos siendo controdictorios. No se si me considere con autoridad para tratar el tema, pero ya tengo casi 18 años desarrolando bases de datos. Y como todos sabemos siempre hay algo que nos falto y cierto caso que no tomamos en cuenta. Por eso digo que todo se basa el la naturaleza del problema. Aunque por mas expertos y mas experiencia que tengamos el algun momento se nos va a pasar cierto casoo regla que no tomamos en cuentas. Lo que siempre querido expresar en este post en que si tomamos todos los casos con un buen diagrama de entidad relacion nos va dar la bd que necesitamos. Bueno eso lo digo en mi caso. No es mi intencion molestar ni contradecir a nadie.
|
| La franja horaria es GMT +2. Ahora son las 22:47:43. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi