|
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 10:38:13. |
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