Llaves foráneas muchos a muchos (ya no entiendo) Urgente

[Ojopex2]

Hola a todos, la verdad tengo más o menos claro el tema de las llaves foráneas en mysql, con MySql Workbench construí una base de datos y lo que resultó no puedo introducir datos. Así que ya estoy muy confuso.

Les cuento primero lo que tengo que hacer.

Tengo una tabla de 'ordenes_trabajos', otra donde hay una lista de posibles tareas para las ordenes o sea una tabla 'tareas' y necesito hacer una tabla donde queden las tareas asignadas a la base de datos en una tercera tabla que se llama 'trabajos'.

Esa tabla se generó haciendo una relacion de muchos a muchos entre las tablas tareas y ordenes_trabajos.
Tengo entendido que ahí tienen que ir las FK en los dos campos que hay.

el código SQL que me genera Workbench es el siguiente para esa tabla:

Código:

CREATE  TABLE IF NOT EXISTS `sav_muller`.`trabajos` (
  `tareas_id_tarea` INT NOT NULL ,
  `ordenes_trabajo_id_ot` INT NOT NULL ,
  INDEX `fk_tareas_has_ordenes_trabajo_tareas1` (`tareas_id_tarea` ASC) ,
  INDEX `fk_tareas_has_ordenes_trabajo_ordenes_trabajo1` (`ordenes_trabajo_id_ot` ASC) ,
  CONSTRAINT `fk_tareas_has_ordenes_trabajo_tareas1`
    FOREIGN KEY (`tareas_id_tarea` )
    REFERENCES `sav_muller`.`tareas` (`id_tarea` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_tareas_has_ordenes_trabajo_ordenes_trabajo1`
    FOREIGN KEY (`ordenes_trabajo_id_ot` )
    REFERENCES `sav_muller`.`ordenes_trabajo` (`id_ot` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

La cual al importarla desde phpmyadmin se me queda pegado y excede el límite de tiempo de 300 segundos.

La verdad ya no entiendo que es lo que pasa. Ya que antes, en otro SQL

Código:

CREATE  TABLE IF NOT EXISTS `sav_muller`.`trabajos` (
  `tareas_id_tarea` INT NOT NULL ,
  `ordenes_trabajo_id_ot` INT NOT NULL ,
  PRIMARY KEY (`tareas_id_tarea`, `ordenes_trabajo_id_ot`) ,
  INDEX `fk_trabajos_tareas1` (`tareas_id_tarea` ASC) ,
  INDEX `fk_trabajos_ordenes_trabajo1` (`ordenes_trabajo_id_ot` ASC) ,
  CONSTRAINT `fk_trabajos_tareas1`
    FOREIGN KEY (`tareas_id_tarea` )
    REFERENCES `sav_muller`.`tareas` (`id_tarea` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_trabajos_ordenes_trabajo1`
    FOREIGN KEY (`ordenes_trabajo_id_ot` )
    REFERENCES `sav_muller`.`ordenes_trabajo` (`id_ot` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

crea la tabla, pero al insertarle datos no me deja ya que dice que el primer campo está duplicado.

La verdad ya estoy con un dolor de cabeza con esto, si alguien me puede explicar que puedo hacer se lo agradecería.

Espero sus aportes.

Gracias.

[ramonw]

Hola, me parece que no podés tener 2 PRIMARY KEY

Código PHP:

PRIMARY KEY (`tareas_id_tarea`, `ordenes_trabajo_id_ot`) ,
 

Además las columnas involucradas en la clave foránea y en la clave referenciada deben tener iguales tipos de datos, fijate esto en la otra tabla.

[gnzsoloyo]

Iniciado por ramonw

Hola, me parece que no podés tener 2 PRIMARY KEY

Código PHP:

PRIMARY KEY (`tareas_id_tarea`, `ordenes_trabajo_id_ot`) ,
 

Además las columnas involucradas en la clave foránea y en la clave referenciada deben tener iguales tipos de datos, fijate esto en la otra tabla.

Eso no son dos PK, sino una PK de dos campos...

Respecto al problema, la cosa sería:
- La tabla Trabajos es la representación N:M entre Tareas y Ordenes_Trabajo.
- En ese contexto, corresponde que la PK de la tabla Trabajos esté compuesta por la PK de las otras dos tablas.
- Eso implica que cada valor de ID de la tabla Ordenes_Trabajo se relaciona una sola vez con uno o más de un registro de la tabla Tareas, pero sólo con un ID por vez.
- De eso se infiere que en una Orden de Trabajo, cada tarea sólo puede aparecer una sola vez, y nada más.
- En ese contexto, el diseño de la tabla:

Código MySQL:

CREATE  TABLE IF NOT EXISTS `sav_muller`.`trabajos` (
  `tareas_id_tarea` INT NOT NULL ,
  `ordenes_trabajo_id_ot` INT NOT NULL ,
  PRIMARY KEY (`tareas_id_tarea`, `ordenes_trabajo_id_ot`) ,
  INDEX `fk_trabajos_tareas1` (`tareas_id_tarea` ASC) ,
  INDEX `fk_trabajos_ordenes_trabajo1` (`ordenes_trabajo_id_ot` ASC) ,
  CONSTRAINT `fk_trabajos_tareas1`
    FOREIGN KEY (`tareas_id_tarea` )
    REFERENCES `sav_muller`.`tareas` (`id_tarea` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_trabajos_ordenes_trabajo1`
    FOREIGN KEY (`ordenes_trabajo_id_ot` )
    REFERENCES `sav_muller`.`ordenes_trabajo` (`id_ot` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;
 

es completamente correcto, así que lo que estás tratando de meter en la tabla Trabajos es dos veces la misma tarea con la misma orden de trabajo y eso no es razonable.

Así pues, en principio lo que parece es que lo que estás haciendo es mal las inserciones, y no el diseño de la tabla.

[ramonw]

Hola gnzsoloyo, me podes explicar muy brevemente que es una PK de dos campos ?

La verdad que no sabia que se podia dividir la PK en dos campos.

Saludos.

[gnzsoloyo]

Iniciado por ramonw

Hola gnzsoloyo, me podes explicar muy brevemente que es una PK de dos campos ?

La verdad que no sabia que se podia dividir la PK en dos campos.

Saludos.

Es algo que surge del modelo relacional, pero para explicarlo tienes que volver a la definición básica que se da en la asignatura de Bases de Datos, en todas las carreras de informática.
Palabras más, palabras menos se expresa:
"Una clave primaria o PRIMARY KEY es un campo o conjunto de campos que identifica unívocamente un registro en una tabla".
En el modelado de sistemas de datos, una PK debe surgir del análisis de los atributos propios de la relación que se expresa en esa tabla, por lo tanto, debería haber al menos un atributo que pueda permitir identificar un registro entre los miles o millones que se encuentren en esa tabla, o en toda posible tabla similar en diferentes bases de datos (es lo que se debe intentar).
Infortunadamente no siempre es posible encontrar un único atributo que cumpla el principio de unicidad, por lo que en esos casos se debe identificar el subconjunto de más de un atributo que puede hacerlo. Allí es donde aparecen las PK compuestas.

Tu confusión puede provenir de la práctica difundida entre los desarrolladores que no han tenido estudios formales, de "crear" PKs simplemente agregandoles un campo autonumérico e incremental. Eso es una salida por la tangente que muestra falta de análisis del sistema y eventualmente trae problemas en las migraciones, consolidaciones de bases y creaciones de Datawarehouses o Datamarts.
Lo ideal es que las claves autonuméricas se eviten dentro de lo posible, y sólo se usen si llegados a la 3FN en la normalización, no se ha podido encontrar un determinante de la relación que pueda ser clave candidata. Pero sólo en esos casos.
Lamentablemente es muy fácil usar ese tipo de soluciones, y en los tutoriales no se hace mención de los problemas que causan a futuro.

Por lo demás, debes recordar también que las PK de tablas que intervienen en una relaicón N:M son parte de la PK que identifica el registro que expresa la relación, en la tabla relacional que debe crearse para administrarla. En ese caso la PK de ambas tablas es el identificador único en la tabla relacional, por lo que la PK de ambas pasa a ser en la nueva tabla, la PK, no sólo porque expresa la relación entre ambas, sino porque define la dependencia de esa tabla de las tablas origen.
¿Se entiende?
Lo que pueden suceder en ese caso es que es que en algún momento te encuentres con PKs que tienen 2, 3, 4, 5, u 11 campos, ya que están heredando claves, y si las claves de origen son compuestas... Que no te extrañe.