Relación imposible
 

Os cuento, estoy empezando a hacer un aplicación, todavía no he diseñado la BD, pero como siempre pienso en el futuro y llego a plantearme dudas.. bueno al hecho. Tengo que hacer una BD de contratos (en otro hilo ya he comentado otras dudillas que han sido más o menos resueltas :D ) joe mira que me enrrollo... bueno pues en esa BD tengo las siguientes tablas:

Contratos
idcontrato
FechaFirma
FechaEntradaVigor
Objeto
IdTipoContrato
etc..

Partes
idPartes
IdContrato
IdEmpresa
Clase
Responsable

Tengo más tablas pero mi pregunta es sobre estas dos; la tabla partes se refiere a las Partes que tiene el contrato, la empresa que contrata y las n empresas que son contratadas, el campo clase definirá si es contratante o contratista. Esta tabla la relaciono con contratos por el campo idcontrato de manera: Contratos ->1-n->Partes

Bueno la duda el usuario lo que quiere es que a la hora de ver un informe de contratos o en dbgrid ver lo siguiente:

idcontrato parte1 parte2 parten... FechaFirma FechaEntradaVigor Objeto IdTipoContrato
1 empresaA EmpresaB EmpresaN 01/02/08 01/02/08 Limpieza 3
2 empresaB EmpresaD EmpresaN 03/05/08 03/05/08 Seguridad 3
3 empresaA EmpresaY EmpresaN 17/07/08 17/07/08 Informatica 3

y eso con sql puessss no se me ocurre como sacárselo....

Ellos (Los usuarios :D) me dan la posibilidad de limitar las partes a 4 con lo que podría meter cuatro campos en la tabla contratos, pero luego a la hora de la búsqueda sería un poco rollo preguntar siempre por cuatro campos :

Código SQL [-]
where (parte1=x) or (parte2=x) or (parte3=x) or (parte4=x)

Bueno pues esa es mi pregunta, no se si debería ir aqui el hilo o en Conexión de BD, esto es una mezca de Diseño de BD y SQL :D

Lo que puedes utilizar es una tabla de "relaciones". Por ejemplo:De esta forma, para saber los partes de un contrato:

Código SQL [-]
SELECT partes.*
FROM partes, contratos, rel_contrato_parte
WHERE contrato.id = x
  AND rel_contrato_parte.id_contrato = contratos.id
  AND partes.id = rel_contrato_parte.id_parte;

Como ves, partes y contratos se relacionan a través de esa tabla "intermedia". Además, si en el futuro hay más de cuatro partes por contrato no tienes que cambiar el diseño de la base de datos.

Pero de la manera que he expuesto yo tambien puede poner cuantas partes quiera, lo único que no me salen como quiere el usuario que salgan, con lo que me pones tu tambien pasa lo mismo. de hecho es lo mismo que he expuesto yo... mi tabla partes es como la tabla de relacion que me pones tu, yo relaciono idcontrato y un idempresa.....

lo que quiero:

idcontrato parte1 parte2 parten... FechaFirma FechaEntradaVigor Objeto IdTipoContrato
1 empresaA EmpresaB EmpresaN 01/02/08 01/02/08 Limpieza 3
2 empresaB EmpresaD EmpresaN 03/05/08 03/05/08 Seguridad 3
3 empresaA EmpresaY EmpresaN 17/07/08 17/07/08 Informatica 3

lo que me has puesto tu:

parte1 contrato1 FechaFirma1 FechaEntradaVigor1 Objeto1
parte2 contrato1 FechaFirma1 FechaEntradaVigor1 Objeto1

lo que quiero es que las partes salgan por columnas y los contratos 1 a 1 por filas... creo que realmente es imposible hacer esto pero si tenéis alguna solución....

Esta clase de problemas (mostrar horizontalmente una tabla) la soluciono con procedimientos almacenados o con tamblas temporales.

Si es con tablas temporales, al crear el Form que contiene el grid o al lanzar el listado, relleno esta tabla. Dependiendo del tiempo que esté abierto este Form, también le pongo un botón para refrescar datos, que vuelve a rellenar la tabla temporal.

Hola, imposible no pero bastante elaborado si. Creo q como te dice ñuño una tabla intermedia, o un rediseño te lo optimizaria bastante. Lo q yo tenia pensado para solucionarlo

Código SQL [-]
select (select idcontratos from contratos) as idcontratos,
         (select first(idparte) from partes where idcontratos = contratos.idcontratos) as id1, 
         (select first(idparte) from partes where idcontratos = contratos.idcontratos and idparte <> id1) as id2, 
         (select first(idparte) from partes where idcontratos = contratos.idcontratos and idparte <> id1 and idparte <> id2) as id3, 
         (select first(idparte) from partes where idcontratos = contratos.idcontratos and idparte <> id1 and idparte <> id2 and idparte <> id3) as id4, 
         (select empresa from partes where idparte = id1) as empresa1, 
         (select empresa from partes where idparte = id2) as empresa2, 
         (select empresa from partes where idparte = id3) as empresa3, 
         (select empresa from partes where idparte = id4) as empresa4, 
         fechaentrada ...

luego no mostrando los campos id1,id2,id3,id4. Seria mas elegante recoger todos los campos 'idparte where idcontratos = contratos.idcontratos' y colocarlos en un 'array', para que luego mediante un where in [...] seleccionar las empresas, o bien mediante un bucle usando for... Desconozco bien bien como funcionan los bucles y arrays en sql, por lo que no pongo nada mas, pero es probable que se pueda hacer asi. Saludos.

je je coso lo que me has puesto lo había pensado también pero es muy engorroso a parte no te aseguras todas las partes del contrato recuerda que son n partes no solo cuatro si son solo cuatro al final optaré por ponerlas en la misma tabla contratos. En cuanto al rediseño estoy abierto a que me planteeis otra solución todavía no he empezado a crear la BD simplemente es la idea inicial.

Lo que dice duilioisola esta bien pero no se mucho sobre procedimientos almacenados en MySQL y como pasarle valores desde delphi. Se supone que lo que tendría que hacer es crear una tabla temporal donde meta los contratos 1 a 1 y mediante un for o algo asi vaya creando tantos campos como partes tenga el contrato??? pero asi en una misma tabla unos contratos tendrán más campos que otros ??? ahhhhh esto no puede ser...

Personalmente creo que no es una buena organización para mostrar datos (salvo utilizando Pivot Tables/Tablas dinámicas).
* Son muy ineficientes a la hora de calcularlas frente a otras posibilidades similares.
* Suelen ser incompletas (salvo casos particulares); En tu caso el cliente te ha limitado a 4. **NOTA**
* En tu caso además estás perdiendo información de las partes; Todo lo que no es la empresa.
* Si mencionar las complicaciones que ya han comentado a la hora de ordenar, filtrar,...

Si no consigues cambiar la opinión del cliente para que se "conforme" con un Maestro detalle o un agrupado, mi recomendación es que trabajes sobre tablas temporales utilizando Stored Procedures y luego muestres los datos.


_________________________________________
**NOTA**: Si me guaradara un euro cada vez que me pide algo y me dicen; "Con esto vale, lo otro no va a hacer falta" y un mes después me piden lo que nunca iba a ser necesario (porque ahora se ha vuelto imprescindible) sería rico.;)

si lo es, si :o. Es una relacion maestro detalle, con el numero de detalles variables, por lo que tendras que usar varias tablas.

je je :D ¿Por que te crees que lo quiero dejar ilimitado? porque se que al final donde dije x ahora es x+1.

cuando dices:

a que organización te refieres??? a la de meter las partes como campos de contratos??

si lo hago como he puesto en el primer post no pierdo, lo que pasa es que me faltaría una tabla empresas, no la he puesto para no liar, la tabla partes iría relacionada con la tabla empresas 1 - N, y en esta tabla estaría el nombre, el cif, la dirección... etc....

Aunque, si en contratos tansolo necesitas el nombre de las empresas de las partes...¿no te iria mejor ponerlas todas en un campo string o memo tansolo? (separadas por comas, o bien por #13). Para los filtros y para todo, al menos de la tabla contratos, te lo optimizaria bastante, y seria mas leible desde una dbgrid por ejemplo, que no tener un numero variable de columnas.

PD: incluso guardando sus idpartes correspondientes en otro campo oculto. Es un poco chapucilla si, pero funcionaria. Si no, deberas buscar el contrato con mayor numero de partes, e ir rellenando la consulta 'contratos' con tantos campos como le falten, incluyendo 'manualmente' (con lo de id<> a los que ya se tienen) por cada idcontrato...

Es una idea muy buena, es decir tu lo que harías es mantener la relacción maestro detalle (Contratos->Partes) y a parte crearías un campo memo en contrato con todas las partes asociadas uhmmmm esta bien lo único que tendría que tener actualizado ese campo siempre, es decir si hay una modificación en alguna de las partes tendría que cambiarlo en ese memo, y si se borra una parte, tambien la borraría en el memo.... me gusta la idea...

ya diras algo ;) saludos

Yo comenzaría preguntándole al cliente qué espera ver en todos los recuadros en blanco que quedarán. Porque donde un contrato esté asociado a diez empresas y los restantes sólo a dos o tres, va a haber muchos huecos sin sentido.

Tampoco veo porqué meter una tabla extra, no se trata de una relación n-n sino de una relación 1-n, cosa que ya está contemplada en el diseño.

Vistas las cosas, creo que la idea de coso es lo mejor que se puede hacer, aunque podrías hacerles un prototipo mostrándoles un maestro-detalle en forma, quien quita y los convences.

// Saludos

Entonces mi idea del principio + la aportación de incluir un campo texto con las partes (aportacion coso) es correcta no??

a que te refieres cuando dices...
Os dejo un link a una imagen del diseño fijaros en las tablas Contratos, PartesContrato y empresas ahi es donde esta el problema :D
Bueno realmente me pasa lo mismo con escrituras y apoderados, con lo cual tanto en contratos como en escrituras he añadido un campo, que será memo, para las partes y los apoderados.

Pues a poner un segundo dbgrid que muestre las distintas partes conforme nos movemos por el dbgrid de los contratos.

Has puesto el enlace a la vista en miniatura. Comprenderás que de ahí no es posible hacerse ninguna idea :p

// Saludos

Hola

:)

Salud OS

¡Ah vaya! Ni siquiera me había fijado en la pregunta exacta de Tony :o. Gracias por la aclaración Eliseo, quien quita y se acostumbran a nuestras expresiones :D.

// Saludos

Chance y si :D:D:D

Salud OS

Edite la url del link, espero que ahora se vea correctamente.

Efectivamente quien quita que no entendiese la frase hecha "quien quita" :D. Aqui vamos entendiendo ya toda vuestra jerga, somos minoría ;)

Lo que dices sobre el maestro detalle con los dos dbgrid ya estaba en mi cabeza, si lo que pasa es a la hora de los informes, pero bueno como bien dices...

Ahí va una idea:

Antes de presentar el dbgrid o el informe podrias calcular el máximo número de partes que vas a obtener.

Una vez obtenido el número de columnas que vas a necesitar solo tendrías que montar una query añadiendo las columnas necesarias.

Por ejemplo, esto funcionaria en sqlserver. En mysql creo que es parecido,

Código SQL [-]
SELECT COUNT(ID_PARTES) FROM PARTES_CONTRATO WHERE ID_CONTRATO IN("LISTA DE CONTRATOS")

Código SQL [-]
select id_contrato, 
case when id_parte=1 then ID_EMPRESA else "" end,
case when id_parte=2 then ID_EMPRESA else "" end,
.....
case when id_parte=numeropartes then ID_EMPRESA else "" end,
FechaFirma, FechaEntradaVigor, Objeto, IdTipoContrato
from contratos a 
inner join PartesContrato b on
a.id_contrato=b.id_contrato
where a.id_contrato in(..lista de contratos..)

Esto lo puedes ir formando en un query y así obtener de forma dinamica las columnas que necesites. De esta forma el contrato con el máximo numero de partes tendría todas las columnas rellenas y los restantes columnas en blanco donde no existiese el id_parte.

Todo esto se puede hacer siempre y cuando el ID_PARTE sea secuencial.

Espero haberte ayudado en algo.

Muchas gracias Nelet, es buena idea pero compleja para implementar, veo más conveniente crear un memo con las partes implicadas en el contrato como dijo coso, es más práctivo a la hora de mostrar un dbgrid o exportarlo a un excel... pero repito muchas gracias por la solución....

De nada, que pa eso estamos...

Y además, no había caído en que coso ya te sugirió esa opción. Xe, me hago mayor y no leo todo.

Eso es muy simple.

Hace unos años (en 1999!!) me toco hacer el rediseño de la entrada de notas u hoja de calificaciones.

Si miran un reporte de esos, veran que es una columna con nombres y una columna por cada periodo de notas (que pueden ser hasta 12....)

Y si, la idea original era un miercolero de selects y funciones en fox. Luego se me ocurrio que cual era el lio de simplemente clavar las columnas directamente en la estructura? Asi que queda masomenos:

idAlumno, idMateria, obs1...obs2, otros campos

Y !zaz! se simplifico el codigo que da miedo, y los reportes salieron mas facilitos!

A veces, hay que perderle el miedo a desnormalizar. Desde entonces aprendi que la funcion de una estructura de BD no es la normalizacion, sino la adaptacion mas natural para la aplicacion (y generalmente es la forma de entrada de datos mas comun).

¿Es decir que tu solución al problema sería la siguiente?:

tabla contratos
y entonces, cuando me dijesen que existe una nueva parte, tu lo que harías es crear un campo nuevo no???

Realmente desnormalizas, pero no te digo yo que me dan ganas de hacerlo porque te ahorras dolores de cabeza :D

El problema es que muchas veces la aplicación está mal diseñada, por lo tanto la adaptación más natural para la aplicación es errónea.

Sigo pensando que esa estructura no es correcta. No es buena para almacenar información (puesto que no es fija -numero fijo de campos-), no es buena para mostrar información (por lo que ya se ha comentado antes) y no es buena para recuperar información (puesto que no está normalizada); Esto último implica que lo que apriori parace más sencillo luego se vuelva más complicado y lento.

Por ejemplo, buscar o agrupar los contratos que tienen partes con una empresa; Calcular el importe facturado a una empresa (a partir de los partes a esa empresa) o los contratos que tienen algun parte de una determinada Clase.
1º) para esto vas a tener que empezar a hacer:
... OR PARTE1 ... OR PARTE2 ...OR PARTE3...
2º) Si mañana se necesitan 5 partes, en lugar de 4, además de cambiar las inteficies, vas a tener que cambiar las consultas.

No digo con esto que la normalización se tenga que llevar a "raja-tabla", yo mismo en casos muy puntuales he "desnormalizado", pero creo que este caso no lo justifica; Es mi opinión, pero creo que esa solución es una pésima opción.

Piensa a la larga, no sea que los dolores de cabeza que te ahorres ahora, se conviertan en errores más grandes dentro de un tiempo...

ja ja ja no si por eso lo digo Neftali, ya hace varios post he decidido implementar la idea de coso (maestro->detalle + campo memo informativo en maestro con los datos del detalle para consultas) , pero en un principio me pense plantar los 4 campos de partes y a tomar vientos :D

Yo estoy de acuerdo con Neftalí. Sin saber más detalles acerca del sistema en particular, no es posible determinar si una denormalización es conveniente o no. De que lo hacemos lo hacemos. Yo tengo una tabla de personas con dos campos para teléfonos. Estrictamente hablando tendría que que separarlos en una tabla aparte pero no hay ningún viso de que en algún futuro sea necesario, así que, no hay necesidad.

Pero si existe esa posibilidad -y hablando de empresas que forman parte de un contrato, da la impresión de que así será- no puede evitarse la mormalización.

Y, como menciona el mismo Neftalí, muchos reportes se complicarán terriblemente por no haber normalizado.

Vamos, que la normalización no es un concepto que alguien se fumó por ahí.

// Saludos

Pues yo aun sabiendo los detalles de la aplicación :D te hacen dudar ...muchas veces hay que ser vidente :D El usuario me jura y perjura que en un contrato solo abrá 3 partes a lo sumo 4. Pero claro yo no me fio y por eso normalizo y saco la tabla partes fuera de la tabla contratos.

Luego tengo la tabla Escrituras de Poder* y me pasa lo mismo, el usuario me dice que como máximo en una escritura puede haber 8 apoderados, pero como antes yo no me fio y normalizo sacando la tabla apoderados fuera de la tabla escrituras.

Es dificil ser vidente y por eso me cubro en salud normalizando, lo único que a priori y para informes quizás es más facil desnormalizar, porque imaginate que tu normalizas tu tabla de personas y sacas la tabla teléfonos, y ahora te piden el informe -> Persona Telefono1 telefono2 telefonoX.... MasDatos ....

Yo de momento voy a normalizar e incluire un campo en el maestro con todos sus detalles :D. Haré una demo, como bien me dijistes y trataré de convencerles ;)



(*) Papeles que otorgan poder a cierta persona/s , por ejemplo un empresario otorga el poder de firmar facturas a su empleado pepito y juanito.

Me parece que las tablas como las planteas al comienzo estan correctas, eso te permite agregar mas partes e independizar tu codigo de la cantidad de partes que sean..
En cuanto al campo memo no me parece una buena solución ya que tendrás que ocuparte de mantenerlo actualizado, y tendrás datos redundantes. La idea de coso me parece buena: ver todas las partes en una columna (string separado por algun delimitador)
No es necesario que agregues un campo memo que luegos vas a tener que actualizar y mantener....
Simplemente puedes hacer un store procedure que te retorne todos los row de los contartos, y en una columna extra el string con las partes (y como dice coso, en otro string puedes retornar las id de las partes tambien con delimitadores, por si las necesitas)
Desde un store procedure es muy facil realizar esto.
Por cada contrato buscas todas sus partes y armas el string, y retornas los datos cada vez que cambia el contrato

El SP lo puedes utilizar tanto para llenar una grilla como para los listados

Saludos

Hola a todos,
y personalmente dejaría la estructura de las tablas normalizadas. Para visualizar las partes tal y como te indican un store procedure o un campo calculado en la tabla, de tipo string en el que concatenes los nombres de las empresas separados por un guión. Te valdrá para cuando haya uno o veinticinco, con sólo cambiar el ancho de la columna, que lo puede hacer hasta el tarado del usuario que pide esta memez ( si es capaz, claro ).

Saludos

Hombre, yo no creo que sea una memez, ni mucho menos que el usuario sea un tarado. Uno no sabe cuáles son sus necesidades ni porqué desea ver la información de tal o cual manera. Así como no es deseable que un cliente nos diga cómo programar, tampoco es deseable decirle a él como debe hacer las cosas.

Yo le he propuesto a Tony lo del demo simplemente porque a veces el usuario puede no haber contemplado cierta posibilidad, pero eso no lo convierte en estúpido.

En cuanto a la concatenación, yo la haría mostrando cada empresa en una línea porque si las ponemos en una sóla, además de que visualmente puede no ser agradable o claro, puede generar una columna demasiado ancha.

// Saludos

Y aqui llega el burro, que tira la patada:D

No es porque esté en contra de una u otra postura. Se han propuesto muchas alternativas, cada una tiene sus ventajas y desventajas.
Nomás me paso por aquí para preguntar algo ¿Que tan alta es posibilidad de que exista un cambio en alguna ley/norma/artículo/etc y afecte el modo en que se compone un contrato?

Si el cliente te asegura, de que no hay más de 4 partes es por algo. Lo que se debería averiguar y analizar porque son 4 y no 50 (por decir un número exagerado). Muy posiblemente se deba a una imposición legal. Por tanto la pregunta que debería hacerse a estas alturas ¿Exista una altísima posibilidad de que haya modificaciones en la ley civil que regula el sistema contractual?

La idea del desarrollo de la demo es muy buena, sobre todo cuando los requisitos no son muy claros.

¿A que viene el rollo que estoy soltando?
A que a lo mejor por normalizar, y por prepararse a un cambio (que ni siquiera se sabe que pueda ocurrir, y que es posible que nunca ocurra) se "complica" el diseño de la base de datos.
Tal vez tener una tabla desnormalizada no es mucho problema.

Mejor analizar si es posible y viable la idea del cambio antes de estar gastando esfuerzo inútil en prepararse a algo que tal vez nunca ocurra.

¿Se entiende a lo que voy?

Además, en el caso de que en un futuro se exija tener más partes, tu tendrías el tiempo de preparar tener diseñado ya una nueva versión del sistema. Lo cual te permitiría hacer mejores negocios con el cliente.

Nomás digo, no es que se me deba hacer caso. Es mi humilde punto de vista.

Saludos,

Claro.

Yo trabaje (mi primer empleo!) en una firma de abogados y es cierto que es todo un lio manejar esos documentos. Y me parece muy raro el requerimiento. Sera que una BD es la mejor opcion? Esto es un problema de datos no estructurados.... en fin.

Una opcion mas y que tambien uso es la de los dataset en memoria. La idea es armar la estructura del clientdataset tal como se quiere ver y "por dentro" hacer los enlaces. La ventaja es que existe la flexibilidad de hacer cambios luego y se da una vision al usuario tal como quiere.

Tambien es valido y quizas mejor desempeño hacer una vista que usando triggers se hacen las actualizaciones. O con grid poderosos como los de DevExpress.

Lo que me da cosa con todo esto es que no me "entra" la idea de cojer un documento que a la final es como una carta, partirlo y luego ensamblarlo... no se, me parece poco natural.

Quizas seria bueno que exploraras bien el asunto en lapiz y papel. Tambien, leer un poco como se tratan datos no estructurados y como se usan tags para relacionarlos con la bd.

pues si....

:D Bueno bueno esto mas que un hilo parece un debate ;) por partes...

Gracias Hach, buena idea va en la línea de lo que quiero montar y asi me ahorro un campo aunque me tendréis que ayudar con el store procedure ;)


:D je je cuando le enseñe la demo lo verá de otra manera a veces hay que ser buen comercial para acabar trabajando como tu quieres....

esta bien la idea pero como el dbgrid que utilizo (estandar) solo muestra una fila(no puedo ampliar el alto de la misma) al final por cada contrato solo se verá la primera empresa, ahí tengo que ver como lo hago.....

Te digo como llego a la conclusión el usuario de que quería cuatro campos:
"Actualmente tenemos unos 200 contratos y en ninguno he superado las tres partes asi que ponme 4 campos que seguro que no llegamos a más"; ante eso uhmmm opté por hacer variable ese campo :D por supuesto que no es por ley, tu puedes hacer un contrato entre muuuuuchas partes, si fuera por ley ni pregunto al usuario :p

La necesidad que le surge al usuario es digitalizar los contratos y tenerlos accesibles via pc, actualmente cada vez que quieren ver algo de un contrato o escritura tienen que ir a la caja fuerte, abrirla y ver los datos que necesitan, con la aplicación lo verían ipsofacto

uhmmm estudiaré tus opciones... en cuanto a DevExpress intento no instalarme nuevos componentes para desarrollar y eso que tengo D5 :D