RESTRICCIONES PDF

RESTRICCIONES INTEGRIDAD DE DOMINIO 3.4. Restricciones Restricciones Inherentes del Modelo Relacional. No existen tuplas repetidas (obligatoriedad de clave primaria). La relación se ha definido como un conjunto de tuplas, y en matemáticas los conjuntos por definición no inclu...

RESTRICCIONES INTEGRIDAD DE DOMINIO 3.4. Restricciones Restricciones Inherentes del Modelo Relacional. No existen tuplas repetidas (obligatoriedad de clave primaria). La relación se ha definido como un conjunto de tuplas, y en matemáticas los conjuntos por definición no incluyen elementos repetidos. Hay que decir, sin embargo, que muchos de los SGBD relacionales sí admiten duplicidad de tuplas. El orden de las tuplas y el de los atributos no es relevante. Cada atributo de cada tupla solo puede tomar un único valor sobre el dominio sobre el que está definido. Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo (regla de integridad de entidad) Estas restricciones son las que marcan la diferencia entre una tabla y una relación, ya que una tabla presenta las filas y las columnas en un orden, del cual carecen las relaciones. Por otro lado, una tabla podría contener filas repetidas. De todos modos, es muy común utilizar el término tabla para referirse a una relación. Las 12 reglas de Codd Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo, Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional. Estas reglas en la práctica las cumplen pocos sistemas relacionales. Las reglas son: 1 1. Información. Toda la información de la base de datos debe estar representada explícitamente en el esquema lógico. Es decir, todos los datos están en las tablas. 2. Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre de la columna o atributo que contiene el dato 3. Tratamiento sistemático de los valores nulos. El DBMS debe permitir el tratamiento adecuado de estos valores. 4. Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un esquema relacional. 5. Sublenguaje de datos completo. Al menos debe de existir un lenguaje que permita el manejo completo de la base de datos. Este lenguaje, por lo tanto, debe permitir realizar cualquier operación. 6. Actualización de vistas. El DBMS debe encargarse de que las vistas muestren la última información. 7. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe actuar sobre conjuntos de filas, nunca deben actuar registro a registro. 8. Independencia física. Los datos deben de ser accesibles desde la lógica de la base de datos aún cuando se modifique el almacenamiento. 9. Independencia lógica. Los programas no deben verse afectados por cambios en las tablas. 2  10. Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos (en el diccionario de datos), no en los programas de aplicación. 11. Independencia de la distribución. El sublenguaje de datos debe permitir que sus instrucciones funcionen igualmente en una base de datos distribuida que en una que no lo es. 12. No subversión. Si el DBMS posee un lenguaje que permite el recorrido registro a registro, éste no puede utilizarse para incumplir las reglas relacionales. Restricciones Semánticas o de Usuario. 1. Restricción de Clave Primaria (PRIMARY KEY), permite declarar un atributo o conjunto de atributos como la clave primaria de una relación. 2. Restricción de Unicidad (UNIQUE), permite que una clave alternativa o secundaria pueda tomar valores únicos para las tuplas de una relación (como si de una clave primaria se tratara). Se entiende que la clave primaria siempre tiene esta restricción. 3. Restricción de Obligatoriedad (NOT NULL), permite declarar si uno o varios atributos de una relación debe tomar siempre un valor. 4. Restricción de Integridad Referencial o de Clave Foránea (FOREIGN KEY), se utiliza para que mediante claves foráneas podamos enlazar relaciones de una base de datos. La integridad referencial nos indica que si una relación tiene una clave foránea que referencia a otra relación, cada valor de la clave foránea o ajena tiene que ser igual a un valor de la clave principal de la relación a la que referencia, o bien, ser completamente nulo. Los atributos que son clave foránea en una relación no necesitan tener los mismos nombres que los atributos de la clave primaria con la cual ellos se 3  corresponden. El diseñador de la base de datos deberá poder especificar qué operaciones han de rechazarse y cuáles han de aceptarse, y en este caso, qué operaciones de compensación hay que realizar para mantener la integridad de la base de datos. Para ello el diseñador debe plantearse tres preguntas por cada clave foránea: 1. ¿Puede aceptar nulos esa clave foránea? Por ejemplo, (tomando como referencia las relaciones PROVEEDORES, ARTICULOS) ¿tiene sentido la existencia de un articulo cuyo proveedor se desconoce? Evidentemente, no. En algunos casos esta respuesta podría ser distinta, por ejemplo, en una base de datos con las relaciones EMPLEADOS y DEPARTAMENTOS, podría existir un empleado no asignado de momento a un departamento. 2. ¿Qué deberá suceder si se intenta eliminar una tupla referenciada por una clave foránea? Por ejemplo, si se intenta eliminar un proveedor del cual existe algún artículo. En general, para estos casos existen por lo menos tres posibilidades: Restringir: La operación de eliminación se restringe sólo al caso en el que no existe alguna tupla con clave foránea que la referencie, rechazándose en caso contrario. En nuestro ejemplo, un proveedor podrá ser borrado, si y sólo si, por ahora, no suministra artículos. Propagar en cascada: La operación de borrado se propaga en cascada eliminando también todas las tuplas cuya clave foránea la referencien. En nuestro ejemplo, se eliminaría el proveedor y todas las tuplas de artículos suministrados por él. Anular: Se asignan nulos en la clave foránea de todas las tuplas que la referencien y se elimina la tupla referenciada. En nuestro ejemplo, no tiene mucho sentido, pero consistiría en asignar nulos al NIF-PROV de todas las tuplas de articulos pertenecientes al proveedor que queremos borrar, y posteriormente borrar al proveedor. 4 3. ¿Qué deberá suceder si hay un intento de modificar la clave primaria de una tupla referenciada por una clave foránea? Por ejemplo, si se intenta modificar la clave de un proveedor del cual existe algún artículo. Se actúa con las mismas tres posibilidades que en el caso anterior: Restringir Propagar en cascada. Anular 5. Restricción de Valor por Defecto (DEFAULT), permite que cuando se inserte una tupla o registro en una tabla, para aquellos atributos para los cuales no se indique un valor exacto se les asigne un valor por defecto. 6. Restricción de Verificación o Chequeo (CHECK), en algunos casos puede ocurrir que sea necesario especificar una condición que deben cumplir los valores de determinados atributos de una relación de la BD, aparte de las restricciones vistas anteriormente. 7. Aserciones (ASSERTION): Esta restricción generaliza a la anterior, lo forman las aserciones en las que la condición se establece sobre elementos de distintas relaciones (por ello debe tener un nombre que la identifique). 8. Disparadores (TRIGGERS), a veces puede interesar espeficar una acción distinta del rechazo cuando no se cumple una determinada restricción semántica. En este caso, se recurre al uso de disparadores o triggers que nos permiten además de indicar una condición, especificar la acción que queremos que se lleve a cabo si la condición se hace verdadera. Los disparadores pueden interpretarse como reglas del tipo evento-condición- acción (ECA) que pueden interpretarse como reglas que especifican que cuando se produce un evento, si se cumple una condición, entonces se realiza una determinada acción. 5 3.5. Integridad de dominio La regla de integridad de dominio está relacionada, como su nombre indica, con la noción de dominio. Esta regla establece dos condiciones. La primera condición consiste en que un valor no nulo de un atributo 𝐴𝑖 debe pertenecer al dominio del atributo 𝐴𝑖 ; es decir, debe pertenecer a dominio (𝐴𝑖 ). Esta condición implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo. Ejemplo Si en la relación EMPLEADOS (DNI, nombre, apellido, edademp) hemos declarado que dominio (DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero. Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el usuario. Observemos que los dominios definidos por el usuario resultan muy útiles, porque nos permiten determinar de forma más específica cuáles serán los valores admitidos por los atributos. Ejemplo Supongamos ahora que en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(edademp) es el dominio definido por el usuario edad. Supongamos también que el dominio edad se ha definido como el conjunto de los enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un empleado con un valor de 90 para edademp. 6 La segunda condición de la regla de integridad de dominio es más compleja, especialmente en el caso de dominios definidos por el usuario; los SGBD actuales no la soportan para estos últimos dominios. Por estos motivos sólo la presentaremos superficialmente. Esta segunda condición sirve para establecer que los operadores que pueden aplicarse sobre los valores dependen de los dominios de estos valores; es decir, un operador determinado sólo se puede aplicar sobre valores que tengan dominios que le sean adecuados. Ejemplo Analizaremos esta segunda condición de la regla de integridad de dominio con un ejemplo concreto. Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no se permitirá consultar todos aquellos empleados cuyo DNI sea igual a ‘Elena’ (DNI = ‘Elena’). El motivo es que no tiene sentido que el operador de comparación = se aplique entre un DNI que tiene por dominio los enteros, y el valor ‘Elena’, que es una serie de caracteres. De este modo, el hecho de que los operadores que se pueden aplicar sobre los valores dependan del dominio de estos valores permite detectar errores que se podrían cometer cuando se consulta o se actualiza la base de datos. Los dominios definidos por el usuario son muy útiles, porque nos permitirán determinar de forma más específica cuáles serán los operadores que se podrán aplicar sobre los valores. Ejemplo Veamos otro ejemplo con dominios definidos por el usuario. Supongamos que en la conocida relación EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio definido por el usuario númerosDNI y que dominio(edademp) es el dominio definido por el usuario edad. Supongamos que númerosDNI corresponde a los enteros positivos y que edad corresponde a los enteros que están entre 16 y 65. En este caso, será incorrecto, por ejemplo, consultar los empleados que tienen el valor de DNI igual al valor de edademp. El motivo es que, aunque tanto los valores de 7  DNI como los de edademp sean enteros, sus dominios son diferentes; por ello, según el significado que el usuario les da, no tiene sentido compararlos. Sin embargo, los actuales SGBD relacionales no dan apoyo a la segunda condición de la regla de integridad de dominio para dominios definidos por el usuario. Si se quisiera hacer, sería necesario que el diseñador tuviese alguna forma de especificar, para cada operador que se desease utilizar, para qué combinaciones de dominios definidos por el usuario tiene sentido que se aplique. El lenguaje estándar SQL no incluye actualmente esta posibilidad. Referencias bibliográficas Elizabeth Pulido Romero, Óscar Escobar Domínguez y José Ángel Núñez Pérez. Base de datos. Ciudad de México: Grupo Editorial Patria, 2019. eLibro. Marqués, Mercedes. 2024. Bases de datos. Castelló de la Plana: D - Universitat Jaume I. Servei de Comunicació i Publicacions, 2009. eLibro Alcalde (2 de octubre de 2017). Diseño de Bases de Datos ( II ) - Restricciones. El baúl del programador. Recuperado el 20 de febrero de 2024 de https://elbauldelprogramador.com/diseno-de-bases-de-datos-ii/ 8