[SOLUCIONADO] Duda FK NULL

[TomaToma]

Hola,
alguien puede ayudarme con una duda?

Tengo:

DocumentoA
DocumentoB
DocumentoC

Y quiero anexar archivos en todos ellos.

Había pensado crear una tabla Archivos con 3 FK para:
IdDocumentoA, idDocumentoB, idDocumentoC

De modo que un archivo anexo en DocumentoA, tendrá los FK NULL de DocumentoB y DocumentoC.

La idea es tener una única tabla Anexos para almacenar todos los anexos de los 3 documentos (y no crear 3 tablas Anexos, una para cada DocumentoX).

¿Veis mala idea 1 tabla Anexos para guardar Anexos de DocumentoA, DocumentoB y DocumentoC donde un Anexo de DocumentoX, implicará tener los otros 2 como NULL?

Gracias y un saludo a todos

[gnzsoloyo]

Tu planteo sólo tiene sentido si estos son tablas diferentes:

DocumentoA
DocumentoB
DocumentoC

¿Lo son? ¿O son documentos en una tabla?

[ElAthlit]

Hola gnzsoloyo,
en primer lugar muchas gracias por contestar.

DocumentoA
DocumentoB
DocumentoC

Son 3 tablas diferentes.

¿Que opinas? (soy novato)

Gracias y un saludo!

[gnzsoloyo]

¿Tres tablas para documentos?
Depende de qué documentos sean... SI fuesen documentos comerciales del tipo Factura, Remito, Recibo, Contrato, etc., se justifica, porque se trata de entidades diferentes con diferentes atributos. Pero si los atributos son los mismos, y se separan de acuerdo al proceso que apliquen, entonces es un error de diseño.
Los procesos no se representan en las Bases de Datos. Que sean documentos a mostrar en diferentes vistas es irrelevante. Una vista de una aplicacion puede ser una tabla, o medio centenar de tablas. Depende del analisis de los datos.

Antes de avanzar, explícanos claramente qué son esos documentos, como se usan y qué contienen que los diferencien o los ,hagan similares. Bien podria ser que estemos ante una relación padre/hijo, y lo estés modelando mal.

[TomaToma]

Hola gnzsoloyo,
gracias por contestar.

DocumentoA,B y C lo hice para simplificar la explicación.

Tengo 3 entidades diferentes:
Incidencia
Informe
Consulta

y entre ellas no tienen ningún vínculo directo.

Cada una de ellas tiene atributos diferentes, pero todas tienen en común que pueden albergar anexos.

La idea principal pues:
Incidencia -> Tabla
Informe -> Tabla
Consulta -> Tabla

Y para que puedan tener anexos:
Anexos -> Tabla

Donde la tabla Anexos:
idAnexo -> Clave principal
atributoX -> Campo varchar
atributoX -> Campo varchar
atributoX -> Campo varchar
idIncidencia -> FK tabla Incidencia
idInforme -> FK tabla Informe
idConsulta -> FK tablaConsulta

De modo que un Anexo de un Informe, tendría una entrada similar:
Tabla Anexo:
ID -> 1
atributoX -> xxxxx
atributoX -> xxxxx
atributoX -> xxxxx
idIncidencia -> null
IdInforme -> 1
idConsulta -> null

Muchas gracias por la ayuda que me estás prestando.

Saludos!

[Libras]

Asi como lo planteas para evitar los campos Null puedes hacerlo de la siguiente manera:

idAnexo -> Clave principal
atributoX -> Campo varchar
atributoX -> Campo varchar
atributoX -> Campo varchar
id_docto -> Fk con las 3 tablas incidencia, informe y consulta
tipo_docto

y una tabla catalago de los tipos de docto

tipos_docto
id tipo

asi te evitarias los campos Null en tu tabla :)

[gnzsoloyo]

Mmmm... el problema que le veo a esa solución es que un mismo campo se está refernciando a tres tablas diferentes, cosa inadmisible en los DBMS que conozco. Solamente podrías implementarlo programáticamente, pero no podrías mantener una restriccion de FK.

A mi entender la cosa tiene dos opciones:

1) Crear una relacion padre/hijo con las tres tablas, las que hereden una PK de una tabla "Documento", que las agrupe, lo que permitiria que la tabla Anexo apunte a la PK de la tabla padre.

2) Crear tres tablas de anexos, una para cada tipo de documento.

Personalmente me quedaría con la primera opción:

DOCUMENTO(id_documento, id_tipodoc)
TIPODOCUMENTO(id_tipodoc, tipo_doc)
INCIDENCIA(id_documento, ....)
INFORME(id_documento, ....)
CONSULTA(id_documento, ....)
ANEXO(id_anexo, id_documento, ....)

Ahora bien, si la cantidad de datos de un anexo para un tipo de documento es diferente para al menos un tipo específico, este modelo no es aplicable y debe obligatoriamente usarse una tabla para cada tipo de anexo, o una tabla de tercer nivel para los datos opcionales. No es admisible en el modelo relacionar usar campos opcionales nulables. es un error de normalización.

[Libras]

Buen punto, me quede pensando en si se podia relacionar un campo con 3 llaves foraneas(me sonaba a que no :P jejejeje) muchas gracias por la aclaracion

[TomaToma]

Hola gnzsoloyo y Libras,
muchas gracias por vuestro tiempo y ayuda!!

Estudiaré la primera opción!

Saludos

[gnzsoloyo]

Una pregunta, no se si lo comentaste ya: ¿Con qué DBMS estás trabajando?
Sería buena idea que cual sea que utilices, nos postees los diagramas de tablas con sus relaciones, cuando avances en el proyecto, a fin de ver si realmente está bien encarado.
Un DER físico de la base muestra claramente lo que necesitamos ver, y hay muchas herramientas para diseño en ese tema. Además los puedes exportar como imágenes...

[TomaToma]

Hola gnzsoloyo,
utilizo MYSQL. Utilizaré 'MySQL Workbench', que tiene buena pinta.

Gracias y un saludo!