Cita: si la tabla fuere ternaria
tendría que repetir el campo id_caja
como tendría que ir pues la ternaria
así serian de M:N tendría el campo id_caja repetido
id_caja id_color id_caja id_unidad
Damos por entendido esto:
-
Las relaciones ternarias no son conceptos del modelo físico de datos sino del modelo lógico. Esto implica que en el modelo lógico se representan abstracciones del mundo real. No puedes pasar de la abstracción a las tablas en una relación 1:1. No son equivalentes, sino que deben someterse a un proceso de
transformación.
-
Toda relación M:N determina la existencia de una tabla nueva (que no existe en el modelo lógico como entidad) que determina la relación. Debe contener como PK, la PK de las dos tablas relacionadas.
- Si tienes una relación entre tres entidades (ternaria), y la relación es N:N;N, esa relación se transforma también en una tabla nueva que represente la relación y contenga las PK de las tablas. En ella las PK de las tres son la PK de la tabla.
- En las ternarias de clase 1:1:1, o 1:1:N se debe analizar la lógica de la relación para saber qué claves migran a cuales tablas.
- Lo que es admisible, luego del proceso de
normalización de bases de datos (que aún no has enfrentado, asumo).
Lo que no tiene ningún sentido es que esté sucediendo esto:
Código SQL:
Ver originalCONSTRAINT fk_caja_color_unidad_id_caja
FOREIGN KEY (id_caja) REFERENCES caja(id_caja),
CONSTRAINT fk_caja_color_unidad_id_color
FOREIGN KEY (id_color) REFERENCES caja(id_color),
CONSTRAINT fk_caja_color_unidad_id_unidad
FOREIGN KEY (id_unidad) REFERENCES caja(id_unidad)
Porque la tabla
caja, o tiene por PK
id_caja, o la PK es
id_color, o lo es
id_unidad.
Si lo que quieres manejar es una clave de tres campos, entonces esa tabla está mal definida (dos de los campos son UNIQUE), y esta tabla en cuestión tiene mal definida las FK, porque si es un a PK de tres campos debería decir:
Código SQL:
Ver originalCONSTRAINT fk_caja_color_unidad_PK
FOREIGN KEY (id_caja) REFERENCES caja(id_caja, id_color, id_unidad)
¿Se comprende lo que digo?
Aclarame ese detalle.
Cita: el problema en si no es insertar datos sino diseñar la base de datos correctamente
Craso error: Si diseñas bien y entras los datos sin respetar las restricciones, el problema es tan grave como diseñar mal, porque significa que no estás entendiendo el concepto de
restricciones de clave foránea.
¿Quince tablas y tienes problemas de lógica?
Eso es una nimiedad. Espera que tengas que enfrentar bases de datos de más de 50 tablas y hablamos.
