• Restricciones de integridad

Restricciones de integridad

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:

1. 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.
2. 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.
1. 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.
2. 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.
1. 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.
1. 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.
2. 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.
2. 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.
1. 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.
1. 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.
2. 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.
2. 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.