integridad referencial

[quilmes_05]

como funciona la integridad referencial con las claves forañas en mysql?esta bien lo que pienso?si tengo las siguiente tablas con sus atributos:

PERSONA EMPLEO
----------- -------------
nombre id_empleo(pk)
edad nombre
dni (pk) dni_empleado_FK


por ej: con la integridad cascade para actualizar y eliminar . dni_empleado_FK es foraneo
a dni .
yo puedo agregar un dni_empleado_FK que no este en dni?
si actualizo el dni_empleado_FK,se actualiza el de dni?

[quimfv]

si actualizo el dni_empleado_FK,se actualiza el de dni?

No exactamente al reves cuando hagas algo en la tabla referenciada (en este caso persona) se reflejará en la tabla referenciate (en este caso empleo). Si eliminas un empleado se eliminaran sus empleos...

yo puedo agregar un dni_empleado_FK que no este en dni?

No si agregas un dni en EMPLEOS que no este en PERSONAS te saltará un error y no te permitira hacer la inserción. Una FK solo admite valores que esten en el campo referenciado (en este caso en dni de persona) y nulos... Es decir puedes insertar emplos sin empleados pero no emplear personas que no tengas fichadas.

En personas puedes insertar personas sin empleo pero no personas sin dni (PK).

[quilmes_05]

gracias por la respuesta muy clara,pasa que yo estoy en workbench y cuando pongo una foranea no cumple con la integridad,osea agrego un empleo con unempleado con no existe y me lo deja,que puede ser,mira te dejo el escript que me genera:

este ejemplo no es el de persona empleo seria las tablas a y b cada una con su clave ide y b una foranea ide_a_fk

Código MySQL:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
 
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
 
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
 
 
 
DROP SCHEMA IF EXISTS `base2` ;
 
CREATE SCHEMA IF NOT EXISTS `base2` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
 
USE `base2` ;
 
 
 
-- -----------------------------------------------------
 
-- Table `base2`.`a`
 
-- -----------------------------------------------------
 
DROP TABLE IF EXISTS `base2`.`a` ;
 
 
 
CREATE  TABLE IF NOT EXISTS `base2`.`a` (
 
  `ide` INT NOT NULL ,
 
  PRIMARY KEY (`ide`) )
 
ENGINE = InnoDB;
 
 
 
 
 
-- -----------------------------------------------------
 
-- Table `base2`.`b`
 
-- -----------------------------------------------------
 
DROP TABLE IF EXISTS `base2`.`b` ;
 
 
 
CREATE  TABLE IF NOT EXISTS `base2`.`b` (
 
  `ide` INT NOT NULL ,
 
  `ide_a_fk` INT NULL ,
 
  PRIMARY KEY (`ide`) ,
 
  INDEX `ide_a_fk_idx` (`ide_a_fk` ASC) ,
 
  CONSTRAINT `ide_a_fk`
 
    FOREIGN KEY (`ide_a_fk` )
 
    REFERENCES `base2`.`a` (`ide` )
 
    ON DELETE CASCADE
 
    ON UPDATE CASCADE)
 
ENGINE = InnoDB;
 
 
 
USE `base2` ;
 
 
 
 
 
SET SQL_MODE=@OLD_SQL_MODE;
 
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
 
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
 

[gnzsoloyo]

En ese ejemplo, la tabla B tiene la FK definida como nulable, lo que significa que es una relación no mandatoria, sino opcional.
En definitiva, te permitirá ingresar registros sin problemas en tanto el campo FK sea:
1) Un valor que existe en la tabla A.
2) NULL.

Lo que no te permitirá es poner un valor que no exista en la tabla A.

¿Se entiende?
El error básico consiste en que si defines una FK normalmente se la pone como NOT NULL para evitar que se ingresen datos huérfanos.

En definitiva, las restricciones funcionan bien, pero la lógica aplicada al diseño está mal, porque no estás cumpliendo con las reglas de negocio del sistema.

¿Se entiende la idea?

[quimfv]

...o sea agrego un empleo con un empleado con no existe y me lo deja...

Estas seguro?

Si entras un nuevo empleado e a te debe dejar.

Pero si antes lo entras en b NO TE DEJARÁ.