UNIDAD 4 TAREA 2

INTEGRIDAD DE BASE DE DATOS

INTEGRIDAD DE ENTIDAD

Esta regla de entidad dice: ningún componente de la clave primaria de una relación base puede aceptar nulos.

Con nulos queremos decir información faltante por una razón, por ejemplo si la propiedad no es aplicable o si el valor se desconoce.

Establece que la clave primaria en una tabla de una tabla debe tener un valor único para cada fila de la tabla; si no, la base de datos perderá su integridad. El DBMS comprueba automáticamente la unicidad del valor de la clave primaria. Un intento de insertar o actualizar una fila con un valor de la clave primaria ya existente fallará.

EJEMPLOS :

·         Otras relaciones bien podrían tener una clave primaria en la cual se permiten nulos. Como por ejemplo vamos a suponer  que se permiten nulos para el atributo P.COLOR en la base de datos proveedores y partes, y consideremos la relación resultante de la consulta “obtener todos los colores de las partes”.

·         En esta relación, puesto que la clave primaria está formada por edificio y número, no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para número.

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

INTEGRIDAD DE DOMINIO

La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos.

El domino de valor posibles puede estar asociado con cada atributo. Los límites de dominios son una forma elemental y fácil de probar por el sistema siempre que se introduce un nuevo dato en la base de datos.

EJEMPLOS:

·         Si en la relación empleados (DNI, nombre, apellido, edad) el dominio es DNI que es el conjunto predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Jesús”, que no es un entero.

·    Supongamos que ahora en la relación EMPLEADOS (DNI, nombre, apellido, edad) hemos declarado que dominio (edad) es el dominio definido por el usuario supongamos también que el dominio edad sea definido como el conjunto de los entero que están entre 16 y 65. En este caso por ejemplo no será posible insertar un empleado con un valor de 90 para edad.

INTEGRIDAD REFERENCIAL

La base de datos no debe de contener valores de clave ajena sin concordancia.

Con el termino “valores de clave ajena sin concordancia “queremos decir aquí un valor no nulo de clave ajena para el cual no existe un valor concordante de la clave primaria  es la relación objetivo pertinente, sirve para asegurarse que los registros de tablas relacionadas son válidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad.

Adviértase que esta integridad exige concordancia de las claves ajenas muy específicamente, con claves primarias no con claves alternativas.

“manejo de integridad referencial” y “manejo de claves ajenas” significa exactamente lo mismo.

EJEMPLOS:

·         Supongamos una base de datos con las entidades Persona y Factura. Toda factura corresponde a una persona y solamente una. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas. Supongamos que una persona se identifica por su atributo DNI (Documento Nacional de Identidad). También tendrá otros atributos como el nombre y la dirección. La entidad Factura debe tener un atributo DNI_cliente que identifique a quién pertenece la factura.Por sentido común es evidente que todo valor de DNI_cliente debe corresponder con algún valor existente del atributo DNI de la entidad Persona. Esta es la idea intuitiva de la integridad referencial.

Considere la relación departamentos y empleados. Es posible modificar el CONSTRAINT para que acepte el borrado en cascada.

INTEGRIDAD DEFINIDA POR EL USUARIO

La integridad definida por el usuario permite definir reglas de negocios específicas que no caigan dentro de alguna de las categorías anteriores. Todas las categorías soportan integridad definida por el usuario (todas las restricciones a nivel columna y a nivel tabla en el comando CREATE TABLE, procedimientos almacenados y desencadenadores).

Son reglas establecidas por el propio diseñador de la base de datos y que corresponden a políticas o normas de la empresa.

Algunas de estas reglas se puedes especificar en la base de datos, sin tener que definirlas en las aplicaciones. Esto seria lo ideal no solo para velar por la integridad de la base de Datos, sin importar el ambiente desde el cual se esté teniendo acceso a la base de datos, sino por la  reutilización de código que además permite una mayor adaptabilidad del sistema a los cambios organizacionales.

EJEMPLOS:

·         Puede ser que no podamos matricular alumnos en un centro educativo de secundaria, menores de 12 años. El principio, para el modelo datos seria indiferente que en nuestros sistemas tuvieron alumnos matriculados menores de 12 años, pero no para los encargados de gestionar el centro educativo, para los que seria inaceptable que alumnos menores de esa edad estuvieron causando estudios en el centro.