En el mundo real existen ciertas restricciones que deben cumplir los elementos en �l existentes; por ejemplo, una persona s�lo puede tener un n�mero de DNI y una �nica direcci�n oficial. Cuando se dise�a una base de datos se debe reflejar fielmente el universo del discurso que estamos tratando, lo que es los mismo, reflejar las restricciones existentes en el mundo real.
Los componentes de una restricci�n son los siguientes:
- La operaci�n de actualizaci�n (inserci�n, borrado o eliminaci�n) cuya ejecuci�n ha de dar lugar a la comprobaci�n del cumplimiento de la restricci�n.
- La condici�n que debe cumplirse, la cual es en general una proposici�n l�gica, definida sobre uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o falso).
- La acci�n que debe llevarse a cabo dependiendo del resultado de la condici�n.
- Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a su dominio, por ejemplo EDAD >= 18 - 65.
- Integridad de entidad: la clave primaria de una entidad no puede tener valores nulos y siempre deber� ser �nica, por ejemplo DNI.
- Integridad referencial: las claves ajenas de una tabla hija se tienen que corresponder con la clave primaria de la tabla padre con la que se relaciona. Por ejemplo, en la tabla familiares de los empleados necesitaremos el DNI de empleado, que es la clave ajena de la tabla.
Las restricciones se clasifican en:
- Inherentes
- Est�n impuestas por el modelo,
- No tiene que ser definidas por el usuario, ya que se encuentran en el propio modelo,
- Se activan en el momento de la definici�n del esquema cuando se produce un intento de violaci�n,
- Se rechaza todo esquema que no cumple estas restricciones,
- Introducen rigideces en el modelo.
- Sem�nticas
- Impuestas por el universo del discurso,
- Tienen que ser definidas por los dise�adores,
- Se activan en el momento de la actualizaci�n de la base de datos,
- Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha otros medios a fin de que no se produzca un estado de inconsistencia),
- Ayudan a capturar la sem�ntica de los datos y a conseguir su consistencia.
- Ajenas
- Se especifican en los programas de aplicaci�n,
- No est�n almacenadas en el esquema de la base de datos,
- Pueden ser violadas por actualizaciones en las que no se haya programado la restricci�n,
- El sistema de bases de datos no puede comprobar si son consistentes en s� mismas.
- El optimizador no puede tomarlas en consideraci�n,
- Proporcionan el m�ximo de flexibilidad,
- Pueden ser programadas en un lenguaje de prop�sito general o en alg�n lenguaje propio del sistema de bases de datos,
- Suponen una importante carga de programaci�n y mantenimiento.
- Propias
- Se identifican en el esquema,
- Est�n almacenadas en el esquema de la base de datos,
- No pueden ser violadas por ninguna actualizaci�n.
- Acci�n General
- Es obligatorio especificar la condici�n y la acci�n,
- Son procedimentales (al menos en parte, ya que la acci�n se especifica siempre mediante un procedimiento),
- Suponen carga de programaci�n,
- Es muy dif�cil (pr�cticamente imposible en la mayor parte de los casos) que el sistema de bases de datos pueda comprobar su consistencia,
- El optimizador no puede tomarlas en consideraci�n,
- Hasta ahora no est�n estandarizadas,
- Est�n muy ligadas a los productos,
- Son muy flexibles,
- Tienen nombre y existencia propia dentro del programa.
- Procedimientos almacenados
- Es obligatorio especificar la condici�n (adem�s de la acci�n),
- Son totalmente procedimentales,
- Pueden ser tan complejas como imponga la sem�ntica del mundo real (tanto en la condici�n como en la acci�n),
- Son las m�s flexibles dentro de las restricciones propias.
- Disparadores
- Combinan los enfoques declarativo (en la condici�n) y procedimental (en la acci�n),
- Pueden ser tan complejas como imponga la sem�ntica del mundo real en cuanto a la acci�n, y bastantes complejas en la condici�n (todo lo que permite la proposici�n l�gica mediante la que se expresa la condici�n),
- El cumplimiento de la condici�n dispara la acci�n,
- Son m�s flexibles que las restricciones de acci�n espec�fica.
- Acci�n Espec�fica
- La acci�n est� impl�cita en la misma restricci�n, por lo que no hay que definirla,
- Son declarativas, puesto que no especifica la acci�n y la condici�n, si se define, es declarativa,
- El no cumplimiento de la condici�n lleva a aplicar la acci�n,
- Podr�an ser definidas mediante un lenguaje de tipo general,
- El sistema de bases de datos puede comprobar si son consistentes en s� mismas,
- El optimizador puede tomarlas en consideraci�n,
- No suponen carga de programaci�n, s�lo de definici�n.
- Condici�n General
- No se especifica la acci�n, que es siempre de rechazo (el no cumplimiento de la condici�n lleva consigo el rechazo de la actualizaci�n),
- Es obligatorio declarar la condici�n mediante una proposici�n l�gica que permite condiciones de complejidad arbitraria,
- Adem�s de la condici�n, se puede especificar alg�n otro componente,
- Son m�s flexibles que las de condici�n espec�fica,
- Es m�s dif�cil optimizar su ejecuci�n que en el caso de las de condici�n espec�fica.
- Verificaci�n
- No tienen existencia en s� mismas,
- Su definici�n forma parte de la definici�n del elemento afectado por la restricci�n,
- Se aplican a un �nico elemento y aunque pueden afectar a otros, en este caso se complica su definici�n,
- Pueden no tener nombre.
- Aserci�n
- Tienen existencia por s� mismas,
- Se definen con independencia de cualquier elemento del esquema,
- Pueden afectar a m�s de un elemento,
- Tienen nombre.
- Condici�n Espec�fica
- Son opciones proporcionadas por el propio modelo,
- No se especifica ninguno de los componentes relativos a una restricci�n (ni la operaci�n, ni la condici�n, ni la acci�n),
- Son poco flexibles,
- El optimizador puede tomarlas en consideraci�n,
- Su ejecuci�n puede ser m�s f�cilmente optimizada que las de condici�n general.