Se puede diferir la comprobaci贸n de validez de las restricciones hasta el final de la transacci贸n. Una restricci贸n es diferida si el sistema comprueba que se satisface 煤nicamente en el momento de la validaci贸n. Si se viola una restricci贸n diferida, la validaci贸n provoca que se haga rollback de la transacci贸n. Si una restricci贸n es inmediata (no diferida), se comprueba al final de cada sentencia. Si se viola, se hace rollback de la sentencia de forma inmediata. Si una restricci贸n provoca una acci贸n (por ejemplo, DELETE CASCADE), esa acci贸n se toma siempre como parte de la sentencia que la provoc贸, independientemente de que la restricci贸n sea diferida o inmediata. Utilice la restricci贸n SET CONSTRAINTS para especificar, para una transacci贸n en particular, si se comprueban las restricciones diferibles despu茅s de cada sentencia DML o en el momento de la validaci贸n de la transacci贸n. Para crear restricciones diferibles, debe crear un 铆ndice no 煤nico para esa restricci贸n.
Puede definir restricciones como diferibles o no diferibles y como inicialmente diferidas o inicialmente inmediatas. Estos atributos pueden ser diferentes para cada restricci贸n.
Supuesto de uso: La pol铆tica de la compa帽铆a dicta que el n煤mero de departamento 40 se deber铆a cambiar a 45. El cambio de la columna DEPARTMENT_ID afecta a los empleados asignados a este departamento. Por tanto, haga que la clave primaria y las claves ajenas sean diferibles e inicialmente diferidas. Actualice la informaci贸n de departamentos y empleados, y todas las filas se validar谩n en el momento de la validaci贸n.

0 comentarios:
Publicar un comentario