Crear llave foránea

[reyvi]

bueno tengo una tabla que contiene el nombre de los pacientes de un Hospital. En otra tabla (cambios_MP) almaceno el ID_paciente además de contener un campo ID qeu se autoincrementa. Cunado intento crear una llave foranea en la tabla cambios_mp me da un error 1452 que dice

1452 - Cannot add or update a child row: a foreing key constrain fail .......

alguien puede ayudarme a solucionar esto????

[gnzsoloyo]

Es un problema muy común: Al menos uno de los valores que existe en un registro de la tabla cambios_MP, donde el valor que existe en el campo ID_paciente, no existe en la tabla referida.
Esto es muy habitual cuando estás agregando FKs en tablas que ya contienen datos, y que no han sido correcamente verificadas.

Postea la estructura de la tabla Pacientes, la de cambios_MP y la sentencia que estás usando para intentar crear la FK.

Código SQL:

SHOW CREATE TABLE cambios_MP;
SHOW CREATE TABLE pacientes;
 

[reyvi]

esta es la tabla paciente

Código MySQL:

DROP TABLE IF EXISTS `pacientes`;
CREATE TABLE `pacientes` (
  `Id` int(11) NOT NULL auto_increment,
  `Nombre` varchar(255) default NULL,
  `CI` varchar(11) NOT NULL default '0',
  `Fecha_nac` varchar(10) default '0000-00-00',
  `Sexo` enum('M','F') default NULL,
PRIMARY KEY  (`Id`,`CI`,`Numero_HC`),
  UNIQUE KEY `CI` (`CI`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 

y esta es la tabla de cambios

Código MySQL:

CREATE TABLE `cambios` (
  `Id` int(11) NOT NULL auto_increment,
  `Id_paciente` int(11) default NULL,
  `Fecha` varchar(10) default '0000-00-00',
  `Id_medico` int(11) default NULL,
  `Id_causa` int(11) default NULL,
  `Notas` text,
  `Id_provincia` int(11) default NULL,
  PRIMARY KEY  (`Id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;
 

AHHHH la llave foránea la estoy creando desde navicat

[gnzsoloyo]

la llave foránea la estoy creando desde navicat

Bueno, eso implica que tienes datos sucios, es decir, en la tabla "cambios", hay registros que no están relacionados con la tabla "pacientes", o al menos los valores que existen no se corresponden a Ids de los mismos.
Para verificar qué casos no cumplen la restricción, ejecuta esto:

Código SQL:

SELECT *
FROM cambios 
WHERE Id_paciente NOT IN(SELECT id FROM pacientes);
 

Además de esto, estoy viendo que estás usando VARCHAR para almacenar fechas y eso está muy, pero muy mal. Ese es el tipo de metidas de pata que no debes cometer.
Los datos de tipo fecha deben ser DATE o DATETIME, pero jamás se deben usar VARCHAR.
NUNCA.

[reyvi]

BUno, ya realicé la consulta que me dijsite que ejecutara y me sale vacía, sin ningún dato, en cuanto a lo demás (el campo fecha) eso es algo que ya voy a solucionar, que me recomiendas que siga haciendo a ver si logro hace la FK???

[gnzsoloyo]

Uhhh!
Ya vi donde está el error... Tienes una de esas metidas de pata mayúsculas.

¿Me puedes decir por qué creas una PK compuesta para la tabla pacientes?

Código MySQL:

PRIMARY KEY  (`Id`,`CI`,`Numero_HC`)
 

Eso no tiene ningún sentido desde el momento en que el primer campo es AUTO_INCREMENT.
Allí está el problema. Se me pasó porque al ver el AI no tenía por qué ponerme a mirar la definición de la PK. Solemos asumir que ese campo AI será la PK también.

Recordemos: Una FK es un campo o conjunto de campos que referencia a la PK de otra tabla. Y cuando la PK de referencia es compuesta, la FK debe tener la misma cantidad de campos, del mismo tipo y en el mismo orden, cosa que no se cumple en tu caso.
En otras palabras, ya la tabla "Pacientes" está mal definida.

[reyvi]

Qué es una PK compuesta?????? y por qué me dices que si el campo está AUTO_INCREMENT tiene problemas??????

[gnzsoloyo]

Iniciado por reyvi

Qué es una PK compuesta??????

Es exactamente eso que estás haciendo: Declarando una PK que se compone de más de un campo de la tabla:

Código MySQL:

DROP TABLE IF EXISTS `pacientes`;
CREATE TABLE `pacientes` (
  `Id` int(11) NOT NULL auto_increment,
  `Nombre` varchar(255) default NULL,
  `CI` varchar(11) NOT NULL default '0',
  `Fecha_nac` varchar(10) default '0000-00-00',
  `Sexo` enum('M','F') default NULL,
 
   ## Esto determina que la PK está compuesta de tres campos:
PRIMARY KEY  (`Id`,`CI`,`Numero_HC`),
 
  UNIQUE KEY `CI` (`CI`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 

Una pregunta: ¿Tienes claro lo que es una PK, para qué existe, y cómo impacta en el modelo de datos?
¿Y para qué es una FK?

Sin ofender, son temas críticos.

Por cierto, no veo de dónde sale ese campo "`Numero_HC`" de tu tabla, por lo que deduzco que no estás posteando la estructura completa.
¿Me equivoco?

[reyvi]

BUeno mira las PK siempre he tenido clro que son muy importantes a la hora de relacionar tablas, esto de las FK, es algo en lo que me estooy iniciando pues te explico bien como es el caso de todo esto.

La tabla paciente es la tabla principal pero esta tiene una relación de uno a varios en otras tablas, en la cuales cada una de ella posee el campo Id_pacienbte, tales como cambios, factores_riesgo, etc.

LA duda que tienes sobre el campo Numero_HC eso es un valor que se inserta y no es más que el número de historia clínica que tiene un paciente.

La relación de todas estas tablas las manejo desde PHP, pero quisiera realizar una relación mediante una FK para actualiza o eliminar en cascada, ya que si elimino un paciente el mismo sql mediante la FK va a hacer lo demás sino tendría que generar varias consultas para limpiar los datos del paciente que se eliminó.

Me hago entender, gracias por tu tiempo, y tranquilo que no me ofendes en lo apsoluto, estoy aprendiendo y es necesario todo lo que me dices y las dudas que te surgen. Gracias por todo... aquí seguimos

[gnzsoloyo]

Lo primero que en realidad deberías hacer, por lo que a mi me parece, es estudiar mejor el modelo Entidad-Relación, y sus fundamentos, porque tienes que comprender que la existencia de las PK y FK no tienen un motivo tan liviano. Son críticos en el modelo, y muy importantes para las consultas en SQL.

Una PK es un campo o conjunto de campos que identifica unívocamente un registro en una tabla, por eso es único, irrepetible y no puede ser nulo. Y entre otras cosas, no se eligen por que si, ni se crean a partir de cualquier cosa al azar.
Una PK, según el paradigma, debería ser un atributo propio de la entidad representada. En el caso de un paciente tienes más de una opción: Su documento, su numero de historia clínica, u otro dato que sólo le pertenezca a esa única persona en todo el universo.
Pero lo que seguro NO PUEDE SER es la suma de los dos. SI lo hicieras podrías poner el mismo numero de documento para otro paciente, simplemente porque su historia clínica sería otra...
No se deben combinar datos únicos de una persona entre si. Se pierde la unicidad de su dominio.
¿Se entiende?

En el modelo ER, las relaciones se determinan y restringen en la implementación por medio de claves foráneas (FK), y son fundamentales para proteger la integridad de los datos, en especial cuando las tablas no tienen claves propias (entidades débiles), normalizadas y con cardinalidades 1: y N:M.
Las FK son obligatoriamente idénticas a la PK a la que apuntan,por consecuencia si la PK es compuesta, la FK también.

La tabla paciente es la tabla principal pero esta tiene una relación de uno a varios en otras tablas, en la cuales cada una de ella posee el campo Id_pacienbte, tales como cambios, factores_riesgo, etc.

Un "factor de riesgo", o "cambios" no se puede definir como perteneciente directamente a ese único paciente. No a menos que un determinado "factor de riesgo" sólo pueda pertenecer a un único paciente... cosa que veo poco probable.
A mi entender hay al menos una tabla "FactoresDeRiesgo" que se relaciona en cardinalidad N:M con los pacientes (más de un paciente puede presentar los mismos factores), y es en esa tabla donde se presentan las FK de lso factores y los pacientes... como PK de esa misma tabla.
¿Se va entendiendo cómo lo veo yo?

La relación de todas estas tablas las manejo desde PHP, pero quisiera realizar una relación mediante una FK para actualiza o eliminar en cascada, ya que si elimino un paciente el mismo sql mediante la FK va a hacer lo demás sino tendría que generar varias consultas para limpiar los datos del paciente que se eliminó.

Manejar las relaciones desde la aplicación es una mala idea a ciertos niveles. Es fácil que se produzcan errores de integridad referencial por defectos de programación indetectables (por ejemplo poner un espacio vacío en lugar de un NULL). Es la única forma si usas tablas MyISAM, pero con las InnoDB tienes las FK... y transacciones.

Resumiendo, habría que revisar el modelado de los datos para limpiar las cosas que no estén bien definidas, creando las FK en el orden y necesidad correctos.

[reyvi]

Tienes muchísima razón en todo lo que expones me puse a revisar todo devidamente y he tenido que hacer varios cambios. Gracias por tu ayuda. AHHHH ya logré hacer la FK, resulta ser que habían datos en las tablas hice una copia sin ellos y pude hacerlo todo perfectamente bien