- ppt descargar

Structured Query Language (lenguaje estructurado de consulta)
2.4 Manipulación de datos El lenguaje relacional SQL-92 Structured Query Language (lenguaje estructurado de consulta) Primer lenguaje de BD de alto nivel. Años 70. Diseñado e implementado en el IBM’s Research Laboratory (San José - California), para el SGBD Relacional experimental System R Definición de un lenguaje estándar para SGBDR ANSI (American National Standards Institute) + ISO (International Standardization Organization) SQL1 (ANSI 1986), extendido en 1989 (SQL-89) SQL-92 (SQL2), y SQL:1999 (extensiones de Orientación a Objetos, disparadores, …) SQL:2003 (incluye XML y otros conceptos recientes) Primeras implementaciones: ORACLE (finales 70) y poco después INGRES [Alapati 2003] El Cálculo Relacional es mucho mas fácil de usar que el Álgebra Relacional, pero todavía está basado en los principios de la lógica y por ello no es fácil de utilizar para la mayoría de la gente. Es, pues, necesaria una implementación del Cálculo Relacional fácil de usar. El SQL es una implementación y ha llegado a ser tremendamente popular como el lenguaje predominante y casi oficial para el modelo de datos relacional. Usando SQL es posible obtener cualquier relación que pueda ser obtenida utilizando cálculo Relacional. Es posible formular consultas con estructuras fáciles de formatear (“easy-to-format”), que son después procesadas por sofisticados servidores de bases de datos en formas complejas para obtener los datos requeridos. Su carácter intuitivo (”intuitive appeal”), facilidad de uso, y tremendo poder y sofisticación ha hecho de SQL el lenguaje elegido cuando se trabaja con una base de datos relacional. La existencia de un estándar SQL tiene las siguientes ventajas: Migración entre SGBDR es más fácil si sólo se usan características del estándar y ambos SGBD origen y destino las soportan Si un programa que accede a cierto SGBDR contiene SQL empotrado (que usa las características estándar), se podría cambiar a otro SGBDR (que también soporte el estándar) Tema 2. Modelo relacional de datos

2.4 Manipulación de datos: SQL-92
Lenguaje de bases de datos completo (no sólo «de consulta») Definición y Manipulación de Datos (LDD + LMD) Definición y destrucción de Vistas (LDV) Creación y destrucción de índices (aunque en SQL-92 «ya no existen») Incorporación de SQL dentro de código escrito con un Lenguaje de Programación de propósito general (Pascal, C, etc.) Los proveedores de SGBDR comerciales (Oracle) implementan variaciones de SQL Algunas incluyen características que no están estandarizadas (triggers /reglas activas  incluidos en la versión SQL:1999) Niveles de compatibilidad con el estándar de SQL Entry SQL Intermediate SQL Full SQL SQL no tiene comandos de control (IF...THEN...ELSE, WHILE, etc.) Actualmente, existen más de 100 productos (SGBD) comerciales basados en el modelo relacional y SQL92. Oracle7 es un superconjunto de SQL-92, en el nivel Entry SQL Tema 2. Modelo relacional de datos

Lo que vamos a estudiar... Consultas o Selección de datos Modificación de datos Vistas Definición y Alteración de datos Esquemas, Dominios, Tablas Restricciones de Integridad Generales (Asertos) Seguridad y Control de Acceso Las restricciones de integridad generales, así como las características de seguridad, las estudiaremos en temas posteriores. Tema 2. Modelo relacional de datos

Tabla SQL = Multiconjunto de filas (saco, bag)
2.4 Manipulación de datos: SQL-92 Consultas básicas (4) SQL-92 vs. Modelo Relacional Formal No utiliza los términos formales relación, atributo, tupla…, sino tabla, columna, fila… Permite que las tablas tengan 2 o más filas idénticas en todos los valores de sus columnas En general, tabla SQL  conjunto de filas, sino que Tabla SQL = Multiconjunto de filas (saco, bag) Es posible forzar que las tablas SQL sean conjuntos de filas: con restricciones de clave o mediante opción DISTINCT en una SELECT (*se verá*) Las columnas de una tabla están ordenadas, y es posible indicar un orden de visualización de las filas Una clave ajena puede referenciar a una clave candidata El SQL-92 no utiliza los términos formales “relación”, “atributo” y “tupla” sino “tabla”, “columna” y “fila”. Además, no se ajusta estrictamente al modelo relacional formal, puesto que permite (como se verá más adelante): Filas duplicadas en las tablas Orden entre las columnas de una tabla (el de creación) Presentar las filas en cierto orden, en función de los valores de una o varias columnas Claves ajenas a claves candidatas en general (y no sólo a claves primarias) Tema 2. Modelo relacional de datos

Esquema de base de datos COMPAÑÍA EMPLEADO NOMBRE APELLIDO NSS NIF FECHAN DIRECCION SEXO SALARIO NSSJEFE ND DEPARTAMENTO NOMBRED NUMEROD NSSDIRE FECHAINICDIRE OFICINA_DEPTO NUMEROD OFICINA PROYECTO NOMBREP NUMEROP LUGARP NUMEROD TRABAJA_EN NSSE NUMP HORAS FAMILIAR NSSE NOMBRE_FAMILIAR SEXO FECHAN PARENTESCO Tema 2. Modelo relacional de datos

Consultas básicas Orden SELECT: Instrucción básica de obtención de información SELECT <lista columnas> FROM <lista tablas> WHERE <condición> donde: <lista columnas> columnas cuyos valores va a obtener la consulta <lista tablas> tablas necesarias para realizar la consulta <condición> expresión booleana para identificar filas que obtendrá la consulta (expresión de reunión y/o de selección) Fecha de nacimiento y dirección del empleado llamado José Silva SELECT fechan, direccion FROM Empleado WHERE nombre = ‘José’ AND apellido = ‘Silva’; La consulta selecciona las filas de <lista tablas> que satisfacen <condición> y proyecta el resultado sobre las columnas de <lista columnas> Tema 2. Modelo relacional de datos

 <lista columnas>(<condición> ( T ))
2.4 Manipulación de datos: SQL-92 Consultas básicas (2) La orden SELECT ... FROM ... WHERE... No es igual a la operación restricción  del Álgebra Relacional SELECT de SQL tiene muchas más opciones y matices En caso de una única tabla T en <lista tablas> SELECT <lista columnas> FROM T WHERE <condición> es equivalente a...  <lista columnas>(<condición> ( T )) * Nombre, apellido y dirección de los empleados del departamento de Investigación SELECT nombre, apellido, direccion FROM Empleado, Departamento  reunión o join de tablas WHERE nombred=‘Investigación’  condición de selección AND numerod=nd;  condición de reunión entre tablas Tema 2. Modelo relacional de datos

Consultas básicas (3) Cualquier nº de condiciones selección/reunión en SELECT * Para cada proyecto ubicado en Santiago, obtener el nº del proyecto, nº del departamento que lo controla y el apellido, dirección y fecha de nacimiento del gerente de ese departamento SELECT numerop, numd, apellido, direccion, fechan FROM Proyecto, Departamento, Empleado WHERE numd=numerod AND nssdire=nss AND lugarp=‘Santiago’; Una SELECT puede obtener filas repetidas * Salario de los empleados de los departamentos de Administración y de Investigación SELECT salario FROM Empleado, Departamento WHERE (nombred = ‘Administración’ OR nombred = ‘Investigación’) AND numerod=nd; Tema 2. Modelo relacional de datos

Consultas básicas (5): uso de * Obtención de los valores de todas las columnas de las filas seleccionadas No es necesario listar todos los nombres tras cláusula SELECT Uso del símbolo * (todas las columnas) SELECT * FROM Empleado WHERE nd=5; SELECT * FROM Departamento WHERE nombred=‘Investigación’; SELECT * FROM Empleado, Departamento WHERE nombred=‘Investigación’ AND nd=númerod; Tema 2. Modelo relacional de datos

Consultas básicas (6): omisión de WHERE Selección incondicional Equivale a una condición TRUE para todas las filas  selección de todas las filas de... una tabla (si la cláusula FROM sólo contiene una tabla), o el producto cartesiano entre varias tablas (si FROM incluye más de una) * Seleccionar todos los nss de empleados SELECT nss FROM Empleado; * Obtener todas las combinaciones de nss de empleados y nombres de departamentos SELECT nss, nombred FROM Empleado, Departamento; Tema 2. Modelo relacional de datos

Consultas básicas (7): cadenas de caracteres Operador LIKE Comparación de cadenas de caracteres Caracteres reservados: ‘%’ y ‘_’ (comodines) *Nombres y apellidos de los empleados cuya dirección esté en Higueras, estado de México SELECT nombre, apellido FROM Empleado WHERE direccion LIKE ‘%Higueras, MX%’ ; Operador || Concatenación de cadenas de caracteres * Nombres completos en una sola columna de empleados con dirección en Higueras (México) SELECT nombre || ‘ ’ || apellido Tema 2. Modelo relacional de datos

Consultas básicas (8): aritmética y tiempo Operaciones aritméticas Aplicación de operadores aritméticos ( + - * / ) sobre valores numéricos * Salarios de los empleados que trabajan en el proyecto ProductoX, tras un aumento del 10% SELECT apellido, nombre, 1.1*salario FROM Empleado, Trabaja_en, Proyecto WHERE nss=nsse AND nump=numerop AND nombrep=‘ProductoX’ ;  el valor real de los salarios en la tabla EMPLEADO no cambia Operaciones con fechas, horas, marcas de tiempo e intervalos Especificación del valor de un INTERVAL como diferencia de dos valores DATE, TIME o TIMESTAMP Incremento y Decremento de valores de columnas de tipo DATE, TIME, TIMESTAMP en un intervalo compatible con el tipo Tema 2. Modelo relacional de datos

Consultas básicas (9): calificación En SQL los nombres de las columnas deben ser únicos dentro de cada tabla Consulta que referencia a varias columnas de igual nombre, pero de tablas distintas...  AMBIGÜEDAD Solución: CALIFICACIÓN El esquema COMPAÑÍA incluye las siguientes tablas: DEPARTAMENTO (nombred, numerod, nssdire, fechainicdire) OFICINA_DEPTO (numerod, oficina) * Código, nombre y lugares de los departamentos de Marketing y de Investigación SELECT Departamento.numerod, nombred, oficina FROM Departamento, Oficina_depto WHERE Departamento.nombred IN (‘Marketing’, ‘Investigación’) AND Departamento.numerod = Oficina_depto.numerod; Tema 2. Modelo relacional de datos

Consultas básicas (10): seudónimos Puede utilizarse seudónimos para acortar nombres de tabla dentro de las consultas con calificación: SELECT nombred, D.numerod, oficina FROM Departamento AS D, Oficina_depto L  ‘AS’ es opcional WHERE D.nombred IN (‘Marketing’, ‘Investigación’) AND D.numerod = L.numerod; Consulta que se refiere dos veces a la misma tabla AMBIGÜEDAD Solución: SEUDÓNIMOS * Obtener nombre y apellido de cada empleado y de su supervisor inmediato SELECT E.nombre, E.apellido, S.nombre, S.apellido FROM Empleado E, Empleado S WHERE E.nssjefe=S.nss; En SQL-92 el uso de ‘AS’ antes del seudónimo es opcional: basta con separar con un espacio en blanco el nombre de la tabla y su seudónimo. Tema 2. Modelo relacional de datos

Consultas básicas (11): renombrar columnas En el resultado de evaluar la consulta * Nombres de cada empleado y su supervisor, cambiando al mismo tiempo los nombres de las columnas resultantes a ‘nom_empleado’ y ‘nom_supervisor’ SELECT E.nombre AS nom_empleado, S.nombre AS nom_supervisor FROM Empleado E, Empleado S WHERE E.nssjefe = S.nss;  Nueva cabecera para la tabla resultado Seudónimos de columnas (y/o tablas) en cláusula FROM SELECT nom, num, oficina FROM Departamento D(nom, num, dire, inidire), Oficina_depto WHERE nom IN (‘Marketing’, ‘Investigación’) AND num = numerod; En ORACLE “AS” es opcional para las columnas y no está permitido para tablas (cláusula FROM) ORACLE7 no permite los seudónimos para columnas en la cláusula FROM Tema 2. Modelo relacional de datos

Consultas básicas (y 12): orden de presentación SQL permite presentar las filas resultado de una consulta de forma ordenada: Cláusula ORDER BY Ordenación según valores de una o varias columnas Ascendente ASC (por defecto) o Descendente DESC Suele ser una operación muy costosa las filas no se ordenan en disco: se ven ordenadas, pero no lo están *Nombre y apellido de los empleados, y proyectos en los que trabajan, en orden descendente por departamentos y, dentro de cada departamento, en orden alfabético ascendente por apellido y nombre SELECT nombred, apellido, nombre, nombre FROM Departamento, Empleado, Trabaja_en, Proyecto WHERE numerod=nd AND nss=nsse AND nump=numerop ORDER BY nombred DESC, apellido ASC, nombre ASC; Tema 2. Modelo relacional de datos

Tablas como conjuntos SQL no elimina filas repetidas del resultado de una consulta, porque... Eliminación de duplicados costosa (ordenar+recorrer+eliminar) El usuario puede desear ver las filas repetidas en el resultado Si se aplica una función agregada a filas, rara vez deben eliminarse las duplicadas Operador DISTINCT: Para eliminar duplicados del resultado de una consulta SQL Resultado = Relación del Modelo Relacional Formal (conjunto de filas) * Salarios de todos los empleados SELECT salario FROM Empleado; * Salarios distintos de empleados, sin importar cuántos perciban cada cantidad SELECT DISTINCT salario FROM Empleado; En ORACLE7, DISTINCT y UNIQUE son sinónimos Tema 2. Modelo relacional de datos

Tablas como conjuntos (2) Operaciones de conjuntos UNION(  ), INTERSECT(  ), EXCEPT ( — ) (minus en ORACLE) Resultado: conjunto de filas  las filas repetidas se eliminan Las tablas operando han de ser compatibles en tipo: igual nº de columnas, y columnas “correspondientes” con el mismo dominio * Nombres de los proyectos en que participa el empleado de apellido ‘Silva’, ya sea como trabajador o como gerente del departamento que controla el proyecto ( SELECT nombrep FROM Proyecto, Trabaja_en, Empleado WHERE numerop=nump AND nsse=nss AND apellido=‘Silva’ ) UNION ( SELECT nombrep FROM Proyecto, Departamento, Empleado WHERE numd=numerod AND nssdire=nss AND apellido=‘Silva’ ); Para no eliminar duplicados... UNION ALL, INTERSECT ALL, EXCEPT ALL En ORACLE los operadores son UNION, INTERSECT y MINUS ORACLE sí soporta la opción “ALL” Tema 2. Modelo relacional de datos

Tablas como conjuntos (3): conjuntos explícitos Un conjunto explícito de valores es una lista de valores encerrada entre paréntesis Puede aparecer en la cláusula WHERE * nss de los empleados que trabajan en los proyectos 1, 2 ó 3 SELECT DISTINCT nsse FROM Trabaja_en WHERE nump IN (1, 2, 3); Operador IN v IN V Indica si el valor v pertenece al conjunto de valores V Devuelve TRUE si algún elemento e de V cumple que v = e * nss de los empleados que trabajan en algún proyecto que no sea el 4 ni el 6 WHERE nump NOT IN (4, 6); (v IN V) = (v = ANY V) (v NOT IN V) = (v <> ALL V) En el caso del operador “=“, es más elegante utilizar IN y NOT IN Tema 2. Modelo relacional de datos

Tablas como conjuntos (4): conjuntos explícitos Operador ANY (o SOME) v <op> ANY V o v <op> SOME V ,, <op>  { , , , , <>,  } Compara un valor individual v con los elementos de un conjunto V Devuelve TRUE si algún elemento e de V cumple que v <op> e * nss de los empleados que trabajan en alguno de los proyectos 1, 2 ó 3 SELECT DISTINCT nsse FROM Trabaja_en WHERE nump = ANY (1, 2, 3); Operador ALL v <op> ALL V,, <op>  { , , , , <>,  } Compara un valor v con los elementos de un conjunto V Devuelve TRUE si para todo elemento e de V se cumple v <op> e * nss de los empleados que no trabajan en ninguno de los proyectos 1, 2 y 3 WHERE nump <> ALL (1, 2, 3); Tema 2. Modelo relacional de datos

Consultas anidadas Es una consulta SELECT completa, dentro de cláusula WHERE de otra consulta (consulta exterior) Obtiene valores de la BD que se usan en la condición de otra consulta, para obtener otros datos * Números de los proyectos en que participa el empleado de apellido ‘Silva’, sea como trabajador o como gerente del departamento que controla el proyecto SELECT DISTINCT numerop FROM PROYECTO WHERE numerop IN ( SELECT nump FROM Trabaja_en, Empleado WHERE nsse=nss AND apellido=‘Silva’ ) OR numerop IN ( SELECT numerop FROM Proyecto, Departamento, Empleado WHERE numd=númerod AND nssdire=nss AND apellido=‘Silva’ ) ; Es posible tener varios niveles de consultas anidadas Tema 2. Modelo relacional de datos

Consultas anidadas (2): comparar conjuntos Operador IN (otro uso del mismo operador) t IN S indica si la fila t pertenece al conjunto de filas S (subconsulta) * Nombre y dirección de los empleados que trabajan en algún proyecto. SELECT nombre, dirección FROM Empleado WHERE nss IN ( SELECT nsse FROM TRABAJA_EN ); * Números de seguridad social de aquellos empleados que trabajan en algún proyecto en el que trabaje el empleado ‘José B. Silva’, de forma que ambos tengan la misma combinación (proyecto, horas); es decir, todo empleado que trabaje las mismas horas que ‘José B. Silva’, en cada proyecto en el que trabajen ambos. El nss de ‘José B. Silva’ es ‘ ’. SELECT DISTINCT nsse FROM Trabaja_en WHERE (númp, horas) IN ( SELECT númp, horas FROM Trabaja_en WHERE nsse=‘ ’); Tema 2. Modelo relacional de datos

¿”Mejor” con DISTINCT en la subconsulta?
2.4 Manipulación de datos: SQL-92 Consultas anidadas (3): comparar conjuntos Operador ANY o SOME (otro uso del mismo operador) t <op> ANY S o t <op> SOME S,, <op>  { , , , , ,  } Compara una fila t con las filas resultado de una consulta anidada S Devuelve TRUE si alguna fila e de S cumple que t <op> e Operador ALL (otro uso del mismo operador) t <op> ALL S,, <op>  { , , , , ,  } Compara una fila t con filas resultado de una consulta anidada S Devuelve TRUE si para toda fila e de S se cumple que t <op> e * Nombres y apellidos de los empleados cuyo salario es menor que el de todos los empleados del departamento 5 SELECT nombre, apellido FROM Empleado WHERE salario < ALL ( SELECT salario FROM Empleado WHERE nd=5 ); El DISTINCT en la subconsulta reduciría el número de filas resultado de la misma, por lo que compararía menos veces el valor de salario. Sin embargo DISTINCT es costoso de ejecutar. ¿”Mejor” con DISTINCT en la subconsulta? Tema 2. Modelo relacional de datos

Consultas anidadas (4): columnas ambiguas Coincidencia de nombres de columnas en las consultas exterior y anidada  Ambigüedad * Nombre y apellidos de cada empleado con familiares de igual nombre y sexo que él SELECT nombre, apellido FROM Empleado WHERE nss IN ( SELECT nsse FROM Familiar WHERE nsse=nss AND nombre_familiar=nombre AND sexo=sexo );  ¿cómo evitar esta ambigüedad? Regla: Una columna no calificada se refiere a la tabla declarada en la consulta anidada más interior Si en una consulta anidada es necesario usar columnas de tablas declaradas en una consulta exterior  calificar SELECT nombre, apellido FROM Empleado E WHERE nss=nsse AND nombre_familiar=nombre AND sexo= E.sexo ); Tema 2. Modelo relacional de datos

Consultas anidadas (5): correlación Una consulta exterior y otra anidada están correlacionadas si una condición de la anidada contiene columnas de una tabla declarada en la consulta exterior SELECT nombre, apellido FROM Empleado WHERE nss IN ( SELECT nsse FROM Familiar WHERE nss=nsse AND sexo=‘F’ ); La consulta anidada se evalúa una vez para cada fila (o combinación de filas) de la consulta exterior Evalúa la consulta anidada para cada fila de EMPLEADO, Si el valor de nss de la fila EMPLEADO está en el resultado de la consulta anidada, selecciona la fila EMPLEADO para el resultado final Una consulta anidada que use el operador = o IN siempre puede expresarse como una reunión (join) SELECT E.nombre, E.apellido FROM Empleado, Familiar D WHERE nss=nsse AND D.sexo=‘F’; Tema 2. Modelo relacional de datos

Consultas anidadas (6): EXISTS Operador EXISTS (S): comprobación de tablas vacías Devuelve TRUE si la tabla S contiene al menos una fila Devuelve FALSE si S es una tabla vacía (sin filas) S suele ser una consulta anidada correlacionada * Nombre y apellido de cada empleado con familiares de igual nombre y sexo que él SELECT E.nombre, E.apellido FROM Empleado E WHERE EXISTS ( SELECT * FROM Familiar WHERE nsse=nss AND nombre_familiar=nombre AND sexo=E.sexo ); * Nombres de empleados sin familiares SELECT nombre, apellido FROM Empleado E WHERE NOT EXISTS (SELECT * FROM Familiar WHERE nsse=nss); EXISTS suele implicar una consulta anidada correlacionada que PUEDE EVITARSE utilizando el operador IN. La consulta resulta así más eficiente, por no contener una correlación. Tema 2. Modelo relacional de datos

Consultas anidadas (y 7): UNIQUE Operador UNIQUE (S): Comprobación de filas duplicadas Devuelve TRUE si NO hay filas repetidas en S S suele ser una consulta anidada correlacionada * Nombres y apellidos de los empleados que trabajan en un único proyecto SELECT nombre, apellido FROM Empleado WHERE UNIQUE ( SELECT nsse FROM Trabaja_en WHERE nsse = nss ); * Nombres, apellidos y salario de los empleados con un solo familiar SELECT nombre, apellido, salario FROM Empleado WHERE UNIQUE ( SELECT * FROM Familiar WHERE nsse = nss ); Oracle no implementa el operador UNIQUE. *************************************************** Un aspecto interesante que incorpora ORACLE y del cual no se menciona nada en el estándar es el siguiente: VISTAS EN LÍNEA Una vista en línea es una subconsulta (un SELECT…) en la cláusula FROM de otra consulta. No es una subconsulta anidada puesto que no aparece dentro de la cláusula WHERE (sino en la FROM) de la consulta exterior. Ejemplos: 1. La siguiente sentencia muestra los datos de los empleados que cobran el máximo salario en cada departamento: SELECT nd, nombred, nss, nombre, apellido, salario FROM (SELECT nd, MAX(salario) AS max_sal FROM Empleado GROUP BY nd), Empleado WHERE max_sal = salario; 2. La siguiente sentencia calcula el número de empleados y la suma de los salarios de los mismos para cada departamento, mostrando dichos datos como el % del total de empleados y de la suma total de los salarios de los empleados de todos los departamentos: SELECT A.numerod “Departamento”, A.num_emp / B.total_emp “%_Empleados”, A.sal_sum / B.total_sal “%_Salario” FROM (SELECT numerod, COUNT(*) AS num_emp, SUM(salario) AS sal_sum FROM Empleado GROUP BY numerod) A, (SELECT COUNT(*) total_emp, SUM(salario) total_sal FROM employees) B; Tema 2. Modelo relacional de datos

Nulos Null Ausencia o desconocimiento de información Comparar NULL con cualquier cosa da FALSE Operador IS NULL ,, IS NOT NULL v IS NULL es TRUE si v es NULL v IS NOT NULL es TRUE si v es un valor no NULL * Nombres de empleados sin supervisores SELECT nombre, apellido FROM Empleado WHERE nssjefe IS NULL; Es imposible realizar operaciones del tipo “nssjefe = NULL”, que siempre da FALSE, pues NULL no es un valor y es distinto a cualquier cosa, incluso a otro NULL. (* Recordamos... Cada NULL es distinto de todos los demás NULL  en una REUNIÓN, las filas con NULL en las columnas de reunión NO se incluyen en el resultado (excepto si REUNIÓN EXTERNA) *) Tema 2. Modelo relacional de datos

Funciones agregadas Función COUNT( ) Cuenta el número de filas o de valores especificados en una consulta Funciones SUM( ), MAX( ), MIN( ), AVG( ) Suma, máximo, mínimo y media aritmética (promedio) Aplicadas a un multiconjunto (saco, bag) de valores numéricos Pueden aparecer en cláusula SELECT * Suma de los salarios y salario máximo, mínimo y medio de los empleados SELECT SUM(salario), MAX(salario), MIN(salario), AVG(salario) FROM EMPLEADO; * Suma de los salarios y salario máximo, mínimo y medio de empleados del depto. de Investigación FROM Empleado, Departamento WHERE nd=númerod AND nombred=‘Investigación’; También pueden aparecer en cláusula HAVING (*se verá*) Ejemplo de COUNT: número de empleados que son jefes de algún otro Número de empleados jefes de otros: SELECT COUNT(*) FROM EMPLEADO J WHERE EXISTS (SELECT * FROM EMPLEADO E WHERE nssjefe=J.nss); FROM EMPLEADO WHERE nss IN (SELECT DISTINCT nssjefe FROM EMPLEADO); Tema 2. Modelo relacional de datos

FUNCIONES AGREGADAS Funciones agregadas (2): uso de * y de DISTINCT Uso de * * Número total de empleados de la compañía SELECT COUNT(*) FROM Empleado ( cuenta filas) * Contar el número de empleados de la compañía que tienen un jefe SELECT COUNT(nssjefe) FROM Empleado; ( cuenta filas con nssjefe no NULL) * Número de empleados en el departamento de Investigación SELECT COUNT(*) FROM Empleado, Departamento WHERE nd=númerod AND nombred=‘Investigación’; Uso de DISTINCT * Contar el nº de valores distintos de salario que pueden cobrar los empleados SELECT COUNT(salario) FROM Empleado; Error: NO se eliminan duplicados, así que COUNT(salario)  COUNT(*) SELECT COUNT(DISTINCT salario) FROM Empleado; OK !! Tema 2. Modelo relacional de datos

Funciones agregadas (y 3) y correlación Es posible que una consulta anidada y correlacionada con otra exterior, incluya una función agregada * Nombres de los empleados con 2 o más familiares SELECT apellido, nombre FROM Empleado WHERE 2  ( SELECT COUNT(*) FROM Familiar WHERE nss=nsse ); Tema 2. Modelo relacional de datos

Agrupación Cláusula GROUP BY Para formar subgrupos de filas dentro de una tabla Los grupos se forman según el valor de las columnas de agrupación Las filas de cada grupo tendrán el mismo valor en las columnas de agrupación Aplicación de funciones agregadas a grupos de filas * Para cada departamento, obtener su número, cuántos empleados tiene dicho departamento y el salario medio de los empleados del mismo SELECT nd, COUNT(*), AVG(salario) FROM Empleado GROUP BY nd ;  una columna de agrupación  Las columnas de agrupación deben aparecer en la cláusula SELECT, antes de cualquier función agregada, para que su valor (único para cada grupo) aparezca junto al resultado de aplicar la función al grupo Tema 2. Modelo relacional de datos

Agrupación (2) Cláusula HAVING Siempre junto a GROUP BY Condición que deben cumplir los grupos de filas asociados a cada valor de las columnas de agrupación Un grupo que no cumple la condición, no es seleccionado para el resultado * Para cada proyecto en el que trabajen más de dos empleados, obtener el número y nombre del proyecto, y el nº de empleados que trabajan en él SELECT numerop, nombrep, COUNT(*) FROM Proyecto, Trabaja_en WHERE numerop=nump GROUP BY numerop, nombrep HAVING COUNT(*) > 2 ; Tema 2. Modelo relacional de datos

Agrupación (y 3) WHERE... se aplica a filas individuales HAVING... se aplica a grupos de filas * Nº de empleados cuyos salarios superan los 1.800€ en cada departamento, pero sólo en el caso de departamentos en los que trabajen más de 5 empleados (* Consulta incorrecta ¿por qué? *) SELECT nombred, COUNT(*) FROM Departamento, Empleado WHERE númerod=nd AND salario>1800 GROUP BY nombred HAVING COUNT(*) > 5 ; (* pista: orden de ejecución *) (* Consulta correcta *) SELECT nombred, COUNT(*) FROM Departamento, Empleado WHERE númerod=nd AND salario>1800 AND nd IN (SELECT nd FROM Empleado GROUP BY nd HAVING COUNT(*) > 5) GROUP BY nombred ; Ejemplo: Departamento DIS con 15 empleados pero sólo 3 de ellos cobran más de 1.800€ En la práctica, la condición en el HAVING siempre incluye una o más funciones agregadas. Si no, podría llevarse a la cláusula WHERE. Ojo: en el WHERE no pueden aparecer las funciones agregadas!! El orden de ejecución está en la diapositiva 136. Tema 2. Modelo relacional de datos

Tablas reunidas Reunión especificada en la cláusula FROM de una consulta Hasta ahora la hemos especificado en cláusulas FROM y WHERE * Nombres y dirección de empleados del departamento de Investigación SELECT nombre, apellido, direccion FROM Empleado, Departamento  reunión de tablas WHERE nombred=‘Investigacion’ AND nd=numerod;  condición de reunión Consultas más comprensibles: separa condiciones de reunión y de selección SELECT nombre, apellido, direccion FROM (Empleado JOIN Departamento ON nd=numerod)  tabla reunida WHERE nombred=‘Investigacion’; ORACLE7 no soporta las tablas reunidas en la cláusula FROM Tema 2. Modelo relacional de datos

Tablas reunidas (2): anidamiento Es posible anidar varias especificaciones de reunión de tablas * Para cada proyecto ubicado en ‘Santiago’, obtener el nº de proyecto, el nº del departamento que lo controla y el apellido, dirección y fecha de nacimiento del gerente de ese departamento SELECT númerop, númd, apellido, dirección, fechan FROM ( ( Proyecto JOIN Departamento ON númd=númerod ) JOIN Empleado ON nssdire=nss ) WHERE lugarp=‘Santiago’; Tema 2. Modelo relacional de datos

Reunión Interna de tablas (inner join) Es el tipo de reunión “por defecto” SELECT ... FROM ( R1 JOIN R2 ON <condición_reunión> ) WHERE ... Si existe una fila t1 en R1 y otra fila t2 en R2, tales que cumplen la condición de reunión, la tabla resultado (reunida) incluirá la fila obtenida al combinar t1 y t2 SELECT E.nombre AS nom_empleado, S.nombre AS nom_supervisor FROM (Empleado E JOIN Empleado S ON E.nssjefe = S.nss); Son excluidas las filas EMPLEADO con NULL en nssjefe También puede especificarse como R1 INNER JOIN R2 ON <condición_reunión> Tema 2. Modelo relacional de datos

Reunión Natural de tablas (natural join) Sin condición de reunión explícita SELECT ... FROM ( R1 NATURAL JOIN R2 ) WHERE ... Equi-reunión implícita para cada par de columnas con igual nombre en una y otra tabla Sólo se incluye una de estas columnas en el resultado Si no coinciden los nombres de las columnas, es necesario RENOMBRAR una de ellas mediante AS en la cláusula FROM SELECT nombre, apellido, direccion FROM ( Empleado NATURAL JOIN (Departamento AS DEP(nombred, nd, dire, fech)) ) WHERE nombred=‘Investigacion’; ORACLE no implementa NATURAL JOIN Tema 2. Modelo relacional de datos

Reunión Externa de tablas (outer join) Útil si en una reunión se necesita obtener las filas… con valor NULL en las columnas de reunión, o sin correspondencia en la otra tabla Tipos de reunión externa: LEFT [OUTER] JOIN Reunión externa izquierda RIGHT [OUTER] JOIN Reunión externa derecha FULL [OUTER] JOIN Reunión externa completa o total SELECT E.nombre AS nom_empleado, S.nombre AS nom_supervisor FROM (Empleado E LEFT OUTER JOIN Empleado S ON E.nssjefe=S.nss); Obtiene también los empleados sin supervisor (con NULL en nssjefe) ****** Indicar cómo es posible realizar reunión externa en ORACLE Tema 2. Modelo relacional de datos

Evaluación de consultas En una consulta SQL hay un máximo de 6 cláusulas Sólo son obligatorias SELECT y FROM Orden de especificación de las cláusulas: SELECT <lista columnas> columnas o funciones que se van a obtener FROM <lista tablas> tablas necesarias (incluso las reunidas) WHERE <condición para filas> condiciones para selección de filas GROUP BY <lista columnas agrupación> especificación del agrupamiento de filas HAVING <condición para grupos> condición para selección de grupos de filas ORDER BY <lista columnas ordenación> orden de presentación del resultado Tema 2. Modelo relacional de datos

Evaluación de consultas (2) Orden de evaluación de las cláusulas: 1) FROM (es decir, la reunión o join de tablas, si se especifica más de una) 2) WHERE 3) GROUP BY 4) HAVING 5) SELECT 6) ORDER BY Diversas formas de especificar una misma consulta Ejemplo: es posible expresar una consulta utilizando... a) condiciones de reunión en cláusula WHERE, o b) tablas reunidas en la cláusula FROM, o c) consultas anidadas y el operador de comparación IN ... Flexibilidad Este orden de evaluación es “conceptual”, pues cada SGBDR tendrá rutinas especiales para optimizar y ejecutar las consultas Tema 2. Modelo relacional de datos

Evaluación de consultas (y 3) Ventajas e inconvenientes de esta flexibilidad:  – el usuario elige la técnica o enfoque más cómodo  – Confusión del usuario: ¿qué técnica uso? – Algunas técnicas son más eficientes que otras  el usuario debe determinar cuál En condiciones ideales... Usuario: se preocupa sólo de especificar la consulta correctamente SGBD: se ocupa de ejecutar la consulta de manera eficiente Pero en la práctica no suele ser así...  conviene saber qué tipos de consulta son más y menos costosos Recomendaciones a) por orden de elegancia IN EXISTS JOIN b) Por orden de eficiencia Aunque depende mucho del esquema de BD, los datos almacenados, y el SGBD (optimizador) de que se trate. Será necesario estudiar los manuales de uso del SGBD concreto y probar!  Recomendación (optimización de consultas): Consultas con mínimo anidamiento correlacionado y mínimo ordenamiento implícito Tema 2. Modelo relacional de datos

Inserción de datos Orden INSERT Añade una fila completa a una tabla Incluye nombre de la tabla y lista de valores para las columnas, escritos en igual orden al especificado en la orden CREATE TABLE INSERT INTO Empleado VALUES ( 'Ricardo', ‘C’, 'Martínez', ' ', ‘ ’, '30-DIC-52', 'Olmo 98, Cedros, MX', ‘M’, 37000, ' ', 4 ) ; Si se desea poner los valores de las columnas en cualquier orden, hay que especificar los nombres de las columnas en dicho orden INSERT INTO Empleado ( nombre, apellido, nss, nif, nd, salario, nssjefe, direccion, fechan, sexo ) VALUES ( 'Ricardo', ‘C’, 'Martínez', ' ', ‘ ’, 4, 37000, ' ', 'Olmo 98, Cedros, MX', '30-DIC-52', ‘M’ ) ; En Oracle7 no es posible insertar varias filas en una sola instrucción INSERT Tema 2. Modelo relacional de datos

Inserción (2) Inserción de varias filas en una sola orden INSERT Filas separadas por comas Cada fila se encierra entre paréntesis Especificación explícita de algunas columnas (y no todas) Omisión de columnas cuyo valor se desconoce Cada columna no especificada tomará el... valor por omisión: valor tomado de su cláusula DEFAULT, o NULL: si la columna permite nulos y no se definió cláusula DEFAULT para la misma * Inserción de un empleado del que sólo se conoce su nombre, apellidos, nss y nif INSERT INTO Empleado (nombre, apellido, nss, nif) VALUES ( 'Rubén', 'Ripoll', ' ‘, ‘ R’ ) ; ORACLE no soporta la inserción de varias filas a la vez Tema 2. Modelo relacional de datos

Inserción (3): Restricciones de Integridad Si SGBD con implementación total de SQL-92 El SGBD maneja e impone toda RI definida en esquema de BD (LDD) Si SGBD con implementación de algunas RI Menor complejidad, mayor eficiencia SGBD implementa comprobaciones para imponer RI que sí maneja INSERT INTO Empleado (nombre, apellido, nd) VALUES ( 'Roberto', 'Huertas', 2 ) ; Inserción rechazada: no se incluye valor para nss, que debe ser NOT NULL Programador debe asegurar la no violación de las RI no manejadas por el SGBD Supongamos que no existe departamento con numerod=8 INSERT INTO Empleado (nombre, apellido, nss, nif, nd) VALUES ( 'Roberto', 'Huertas', ' ', ‘ H’, 8 ) ; Si el SGBD sí maneja la Integridad Referencial Inserción rechazada Si el SGBD NO soporta la Integridad Referencial Inserción permitida  ¡el programador debe asegurar que esto no pase! Tema 2. Modelo relacional de datos

Inserción (y 4): filas resultado de una consulta Carga de una tabla con información sinóptica de la BD Sea una tabla INFO_DEPTOS vacía. En ella queremos almacenar los nombres de cada departamento, su nº de empleados y el salario conjunto de los empleados del mismo. INFO_DEPTOS ( nombre_depto, num_emps, sal_total) INSERT INTO Info_deptos ( nombre_depto, num_emps, sal_total ) SELECT nombred, COUNT(*), SUM(salario) FROM Departamento, Empleado WHERE númerod=nd GROUP BY nombred ; Es posible hacer SELECT ... FROM Info_deptos ...  INFO_DEPTOS puede contener información no actualizada Si se modifica información en EMPLEADO y/o DEPARTAMENTO, los cambios no se reflejarán en la tabla INFO_DEPTOS Una vista sí “contiene” siempre los datos más actuales (*se verá*) Sinóptico = que a primera vista presenta con claridad las partes principales de un todo. Tema 2. Modelo relacional de datos

Eliminación de datos Orden DELETE Elimina filas completas de una tabla Sólo una tabla en cláusula FROM Cláusula WHERE para seleccionar las filas que eliminar Si no hay WHERE, se eliminan todas las filas La tabla permanece, pero queda vacía DELETE FROM Empleado ; todas las filas DELETE FROM Empleado WHERE apellido=‘Bojórquez’; 0 filas DELETE FROM Empleado WHERE nss=‘ ’ ; 1 fila DELETE FROM Empleado WHERE nd IN ( SELECT numerod FROM Departamento WHERE nombre=‘Investigación’) ; 4 filas Propagación de eliminaciones Según acciones de mantenimiento de la Integridad Referencial especificadas con LDD en los CREATE TABLE (esquema de BD) Tema 2. Modelo relacional de datos

Actualización de datos Orden UPDATE Modifica valores de columnas en una o más filas de una tabla Se modifican filas de una sola tabla a la vez Cláusula SET especifica columnas que modificar y nuevos valores Cláusula WHERE para seleccionar filas que actualizar Si no hay WHERE, se aplica la modificación a todas las filas * Para el proyecto 10, cambiar el lugar a Belén y el nº de depto controlador al 5 UPDATE Proyecto SET lugarp = ‘Belen’, númd = 5 WHERE numerop=10 ; Propagación de modificaciones Si cambia un valor de clave candidata, este cambio se propaga a valores de clave ajena de filas de otras tablas, si así se especificó en las acciones de mantenimiento de la Integridad Referencial en la definición de la tabla con CREATE TABLE Tema 2. Modelo relacional de datos

Actualización (y 2) Modificación de varias filas a la vez con UPDATE * Conceder a todo empleado del departamento de Investigación un aumento salarial del 10% UPDATE Empleado SET salario = salario*1.1 WHERE nd IN (SELECT númerod FROM Departamento WHERE nombred=‘Investigación’) ; NULL o DEFAULT como nuevo valor de una columna UPDATE Empleado SET salario = DEFAULT; UPDATE Empleado SET nssjefe = NULL WHERE ... ; ORACLE7 sí permite utilizar el NULL como nuevo valor, pero no el DEFAULT Tema 2. Modelo relacional de datos

LDD: Definición de datos Esquema de Base de Datos Relacional Agrupa tablas y otros elementos, de una misma aplicación 1as versiones de SQL: todas las tablas dentro de un esquema único y global a todas las aplicaciones que accedían a la BD Orden CREATE SCHEMA: definición/creación de esquemas CREATE SCHEMA <nombre de esquema> AUTHORIZATION <identificador de autorización> <nombre de esquema> identifica el esquema <identificador de autorización> usuario/cuenta propietaria del esquema CREATE SCHEMA Compañía AUTHORIZATION JSILVA ; A continuación puede especificarse las definiciones de los elementos contenidos en dicho esquema Elementos del esquema: Tablas, Vistas, Dominios, Autorizaciones, Restricciones, etc. SGBD puede gestionar varias bases de datos, por ejemplo, BD1, BD2 y BD3 Cada base de datos puede contener varios esquemas, por ejemplo BD1 = {E1a, E1b, E1c, E1d} Un usuario/cuenta de base de datos puede ser el propietario de uno o varios esquemas. Por ejemplo el usuario u1 podría ser el propietario de los esquemas E1b y E1c. Cada esquema está compuesto de una colección de tablas, vistas, dominios, RI, etc. Por ejemplo E1b = {D1, D2, T1, T2, T3, T4, V1, RI1, RI2, RI3...} En Oracle7 la orden de creación de un esquema es: CREATE SCHEMA AUTHORIZATION <cuentaBD> Pues sólo es posible tener un esquema por cuenta. Los elementos del esquema se pueden crear en cq orden y las sentencias de creación de los diferentes elementos no deben finalizar con ‘;’ Tema 2. Modelo relacional de datos

Catálogo de base de datos relacional Conjunto nombrado de esquemas de BD en un entorno SQL Contiene un esquema especial, INFORMATION_SCHEMA, que almacena datos sobre la definición de todos los elementos de todos los esquemas existentes en el catálogo El Diccionario de Datos (Data Dictionary) de ORACLE se corresponde con el INFORMATION_SCHEMA del estándar SQL-92 Es posible compartir elementos (dominios, etc.) entre diferentes esquemas del mismo catálogo Sólo pueden definirse restricciones de integridad referencial entre tablas que existan en esquemas dentro del mismo catálogo Concepto incorporado en la versión SQL-92 del estándar Antes de comenzar a explicar cómo definir los diferentes tipos de elementos de un esquema de bases de datos, es interesante comprender el concepto de Catálogo de Bases de Datos Relacional. En particular, es importante entender la motivación y utilidad de un esquema especial contenido en todo catálogo, el INFORMATION_SCHEMA, que contiene los metadatos o definiciones de la estructura de los datos (además de otros aspectos como usuarios, restricciones de integridad y de seguridad, procedimientos y funciones, etc. Pág 24 y Capítulo 21 del libro Date&Darwen 1994. Pág 231 de [EN2002] En Oracle, al INFORMATION_SCHEMA se le llama Diccionario de Datos Tema 2. Modelo relacional de datos

LDD: definición de tablas Orden CREATE TABLE Define (crea) una tabla: nombre, columnas y restricciones Nombre único dentro del esquema Para cada Columna... nombre, tipo de datos (dominio) restricciones de columna Restricciones de tabla... de clave candidata, de integridad de entidad, de integridad referencial, o restricciones de otro tipo CREATE TABLE Empleado ( nombre ... apellido ... nss ... nif ... fechan ... direccion ... sexo ... salario ... nssjefe ... nd … ); Tema 2. Modelo relacional de datos

LDD: definición de tablas Indicación del esquema al que pertenece una tabla Esquema Explícito CREATE TABLE Compañia.Empleado ... Esquema Implícito en el contexto CREATE TABLE Empleado ... Ordenamiento de columnas y filas Columnas ordenadas tal como aparecen en CREATE TABLE Las filas no están ordenadas Las tablas creadas con CREATE TABLE son tablas BASE El SGBD las almacena físicamente en algún fichero de la BD El esquema implícito en el contexto es el esquema activo para el usuario que está conectado a la BD (cuyo nombre suele coincidir –al menos en ORACLE- con el nombre de la cuenta en la que se ejecuta el CREATE TABLE) Tema 2. Modelo relacional de datos

LDD: definición de tablas Especificación del tipo de datos de una columna Especificar directamente el tipo de datos tras nombre de la columna CREATE TABLE Empleado ( nombre VARCHAR(15) ... ... ); Definir un dominio y usar su nombre como tipo de datos Facilita cambio del tipo de datos usado por muchas columnas Esquema más comprensible CREATE DOMAIN Nombres VARCHAR(15); ... nombre NOMBRES ... Tema 2. Modelo relacional de datos

LDD: tipos de datos Numéricos Enteros y Reales INTEGER (también INT), SMALLINT, FLOAT, REAL, DOUBLE PRECISION Con formato DECIMAL(p,e) ( también DEC(p,e) ó NUMERIC(p,e) ) p: precisión, e: escala. El valor por omisión de la escala es e = 0 Cadena de caracteres Longitud fija CHAR(n) ( n: nº caracteres ) Longitud variable VARCHAR(n) ( n: máximo nº caracteres ) Cadena de Bits Longitud fija BIT(n) (n: nº bits) Longitud variable BIT VARYING(n) n:máx nº bits. Por omisión n=1 Precisión: número total de dígitos (incluidos decimales, no incluido signo ni punto decimal) Escala: número de dígitos decimales (a la derecha del punto decimal) TIPOS DE DATOS en ORACLE: (SQL Language Quick Reference) - LONG, NUMBER(p,e), por defecto p=38 y e=0 CHAR, VARCHAR(n), VARCHAR2(n) por defecto n=1 DATE (~ TIMESTAMP) Ojo: NUMERIC es de SQL-92 y no de ORACLE Tema 2. Modelo relacional de datos

LDD: tipos de datos Temporales DATE (10 posiciones) = YEAR, MONTH, DAY (yyyy-mm-dd) TIME (8 posiciones) = HOUR, MINUTE, SECOND (hh:mm:ss) Sólo permitidas fechas y horas válidas TIMESTAMP (marca de tiempo) DATE, TIME, fracciones de segundo y desplazamiento respecto al huso horario estándar (WITH TIME ZONE) INTERVAL Período de tiempo, para incrementar/decrementar el valor actual de una fecha, hora o marca de tiempo Se califica con YEAR/MONTH ó DAY/TIME para indicar su naturaleza Ejemplos de intervalo: 3 years, 90 days/50 minutes, 30 seconds ¿? [DD1994] Tema 2. Modelo relacional de datos

LDD: definición de dominios de datos CREATE DOMAIN <nombre dominio> <tipo de datos> [ DEFAULT <valor defecto> ] [ <lista de definición de restricciones de dominio> ] ; <tipo de datos>: uno de los proporcionados por el SGBD (built-in) <valor defecto>: (opcional) Especifica el valor por omisión para columnas definidas de este dominio Será asignado a cada columna con dicho dominio, si no tiene ya su propia cláusula DEFAULT <lista de definición de restricciones de dominio>: (opcional) Restric. Integridad que se aplican a toda columna definida sobre el dominio Cada RI puede tener un nombre: cláusula CONSTRAINT <nombre_RI> * Ejemplo: enumeración de posibles valores componentes del dominio CREATE DOMAIN Color VARCHAR(8) DEFAULT ‘sinColor’ CONSTRAINT color_valido CHECK (VALUE IN ( ‘rojo’, ‘amarillo’, ‘azul’, ‘verde’, ‘sinColor’ ) ) ; Si la definición del dominio COLOR no contiene la siguiente restricción… CONSTRAINT color_no_nulo CHECK (VALUE IS NOT NULL) … entonces el dominio sí incluye NULL. ORACLE7 no soporta definición de dominios Tema 2. Modelo relacional de datos

LDD: definición de tablas Especificación de restricciones de columna Cláusula NULL o NOT NULL Opción de nulo: indica si una columna puede contener o no NULL CREATE TABLE Empleado (... nombre VARCHAR(15) NOT NULL, ... ); Por omisión, se asume NULL La restricción NOT NULL es obligatoria para columnas componentes de una clave primaria Cláusula DEFAULT <valor> Valor por omisión (o por defecto) CREATE TABLE Empleado ( ... salario DECIMAL(5,2) DEFAULT 1000 NULL,... ); Si una columna no tiene DEFAULT, su valor por defecto es... El de su dominio, si su tipo es un dominio que incluye DEFAULT NULL en cualquier otro caso, siempre que la columna permita NULL En ORACLE7 no hace falta indicar NOT NULL para claves primarias, pues el SGBD asume por defecto que cada pk ha de ser UNIQUE (la combinación) y NOT NULL (cada componente). OJO: el valor por defecto debe pertenecer al dominio sobre el que está definida la columna correspondiente. En Oracle el valor por defecto debe indicarse tras el tipo de datos y delante de cualquier otra restricción de columna Tema 2. Modelo relacional de datos

LDD: definición de tablas Especificación de restricciones de tabla Cláusula PRIMARY KEY (<lista_columnas>) Columnas que componen la clave primaria Cláusula UNIQUE (<lista_columnas>) Columnas que forman una clave alternativa Cláusula FOREIGN KEY (<lista_columnas>) REFERENCES <tabla>(<lista_columnas>) Columnas clave externa (Integridad Referencial) SQL-92 permite que una clave externa se refiera a una clave primaria o una clave alternativa Cláusula CHECK (<expresión>) Condición sobre los valores de las columnas que debe cumplir toda fila de la tabla A diferencia del modelo relacional formal, SQL permite que las claves externas se refieran a claves CANDIDATAS en general, es decir, bien a claves primarias, bien a claves alternativas. NOT NULL opcional en las claves primarias (incluido implícitamente en la definición PRIMARY KEY), tanto en SQL-92 como en Oracle. Una columna UNIQUE puede contener NULL, a menos que se indique lo contrario en la definición de dicha columna. Ej. Columna nif en PERSONA, para considerar personas que por ser menores todavía no tienen nif) Tema 2. Modelo relacional de datos

LDD: definición de tablas CREATE TABLE Empleado ( nombre VARCHAR(15) NOT NULL, apellido VARCHAR(15) NOT NULL, nss CHAR(12) NOT NULL, nif CHAR(9) NOT NULL, fechan DATE NULL, direccion VARCHAR(30) , sexo CHAR(1) , salario DECIMAL(5,2) DEFAULT 1000 NULL, nssjefe CHAR(12) , nd NUMERIC(2) NOT NULL, PRIMARY KEY ( nss ), UNIQUE ( nif ), CHECK ( nssjefe <> nss ), CHECK ( sexo IN (‘H’, ‘M’) ), FOREIGN KEY (nssjefe) REFERENCES Empleado(nss), FOREIGN KEY (nd) REFERENCES Departamento(numerod) ); Tema 2. Modelo relacional de datos

LDD: definición de tablas Especificación de restricciones de tabla (cont.) Dar nombre a una restricción es opcional, pero muy conveniente CONSTRAINT <nombre_RI> <restricción> El nombre de restricción debe ser único dentro del mismo esquema Identifica una restricción, por si después debe ser eliminada o sustituida por otra CREATE TABLE Empleado ( ..., CONSTRAINT pk_empleado PRIMARY KEY ( nss ), CONSTRAINT nif_unico UNIQUE ( nif ), CONSTRAINT jefe_ok CHECK ( nssjefe <> nss ), ... ); Tema 2. Modelo relacional de datos

LDD: definición de tablas Especificación de restricciones de tabla (cont.) Si la restricción afecta sólo a una columna, puede especificarse en la definición de dicha columna (en la misma línea) Por ejemplo, si una clave externa no es compuesta, no se necesita la cláusula FOREIGN KEY CREATE TABLE Empleado ( nombre VARCHAR(15) NOT NULL, nss CHAR(12) PRIMARY KEY, nif CHAR(9) NOT NULL UNIQUE, nssjefe CHAR(12) NULL REFERENCES Empleado(nss), nd NUMERIC(2) NOT NULL REFERENCES Departamento(numerod), ..., CONSTRAINT jefe_ok CHECK ( nssjefe <> nss ), ... ); Tema 2. Modelo relacional de datos

LDD: definición de tablas Acciones de mantenimiento de la integridad referencial Cláusulas ON DELETE <acción> y ON UPDATE <acción> <acción>  { NO ACTION, CASCADE, SET NULL, SET DEFAULT } CREATE TABLE Empleado ( ..., CONSTRAINT jefe_emp FOREIGN KEY (nssjefe) REFERENCES Empleado(nss) ON DELETE SET NULL ON UPDATE CASCADE, CONSTRAINT dep_emp FOREIGN KEY (nd) REFERENCES Departamento(numerod) ON DELETE NO ACTION ON UPDATE CASCADE ); Estas acciones se detallan en el tema “Integridad en sistemas de bases de datos relacionales”. ORACLE… No implementa ON UPDATE (es decir, actúa siempre como si se definieran en modo NO ACTION) Permite incluir ON DELETE en sentencias CREATE TABLE con las siguientes opciones: - NO ACTION (por omisión) - SET NULL - CASCADE Tema 2. Modelo relacional de datos

LDD: definición de vistas Una vista es una tabla derivada de otras tablas Son tablas virtuales, pues no necesariamente existen en forma física Sentencia de definición o creación de una vista CREATE VIEW <nombre_vista> [ (<lista_nombres_columnas>) ] AS <consulta_de_definición> La consulta de definición… determina el contenido de la vista contiene las tablas base: tablas o vistas de las que se deriva la vista (también llamadas tablas de definición) CREATE VIEW Familiar_de_Empleado (empleado, familiar, parentesco) AS SELECT nombre, nombre_familiar, parentesco FROM Empleado, Familiar WHERE nss = nsse; No es el mismo concepto que el de VISTA en la Arquitectura de tres niveles ANSI/SPARC (esquema externo). Un esquema externo, por tanto, puede estar formado por tablas base y por vistas, o sólo por tablas base, o sólo por vistas. Tema 2. Modelo relacional de datos

LDD: definición de vistas Por defecto, la vista ‘hereda’ los nombres de las columnas... seleccionadas desde las tablas base siempre que ninguna columna sea el resultado de una operación aritmética o función de agregados CREATE VIEW Empleado_en_Proyecto AS SELECT nombre, apellido, nombrep, horas FROM Empleado, Proyecto, Trabaja_en WHERE nss = nsse AND nump = numerop ; Definición de nuevos nombres para columnas de la vista CREATE VIEW Info_Depto (nombre_depto, num_de_emps, sal_total) AS SELECT nombred, COUNT(*), SUM(salario) FROM Departamento, Empleado WHERE numerod = nd GROUP BY nombred ;  nombres que hereda la vista Tema 2. Modelo relacional de datos

LDD: definición de vistas Un estado de la vista EMPLEADO_EN_PROYECTO Empleado_en_Proyecto nombre apellido nombrep horas José Silva ProductoX 32.5 Ramón Nieto ProductoZ 40.0 ProductoY 07.5 Josefa Barceló 20.0 Federico Vizcarra 10.0 ... Tema 2. Modelo relacional de datos

LDD: definición de vistas Las vistas pueden utilizarse como mecanismo de... Simplificación de consultas Seguridad (*se verá en el tema de seguridad*) Adaptación de la información a las necesidades de cada usuario o grupo de usuarios Característica fundamental de las vistas Actualización Permanente El responsable de esta característica es el SGBD La vista no se crea cuando se define, sino cuando se consulta Una vista no “contiene información”, sino que “deja ver información” almacenada en sus tablas base Tema 2. Modelo relacional de datos

LDD: definición de vistas El SGBD traduce cualquier sentencia SQL sobre la vista a una expresión equivalente sobre sus tablas base: reemplaza el nombre de la vista por su consulta de definición y ejecuta CREATE VIEW Veterano AS SELECT nombre, nif, nss, fechan, nd FROM Empleado WHERE fechan<’01/01/1970’; Sentencia de usuario Traducción SELECT * FROM VETERANO WHERE nombre LIKE ‘G%’; SELECT nombre, nif, nss, fechan, nd FROM EMPLEADO WHERE fechan < ‘01/01/1970’ AND nombre LIKE ‘G%’; INSERT INTO VETERANO VALUES (‘Eva’, ‘ E’, ‘ ’, ‘14/11/1947’, 4); INSERT INTO EMPLEADO (nombre, nif, nss, fechan, nd) VALUES (‘Eva’ ‘ E’, ‘ ’, ‘14/11/1947’, 4); UPDATE VETERANO SET nd=1 WHERE nd=2; UPDATE EMPLEADO SET nd=1 WHERE fechan < ‘01/01/1970’ AND nd=2; DELETE FROM VETERANO WHERE nif = ‘ E’; DELETE FROM EMPLEADO WHERE fechan < ‘01/01/1970’ AND nif = ‘ E’; IMPORTANTE: en el INSERT INTO EMPLEADO las columnas para las que no se proporciona valor tomarán su valor por defecto (como es el caso de salario) o tomarán NULL. Tema 2. Modelo relacional de datos

LDD: consulta a través de vistas Las vistas no tienen ninguna limitación en operaciones de consulta El usuario no distingue si el elemento al que accede es una tabla base o una vista * Nombres de los empleados y de sus hijos/as SELECT empleado, familiar FROM Familiar_de_empleado WHERE parentesco LIKE ‘Hij_’ ; * Datos del departamento ‘Investigación’ SELECT * FROM Info_Depto WHERE nombre_depto=‘Investigación’ ; * Nombres y apellidos de los empleados que trabajan en el proyecto 'ProductoX' SELECT nombre, apellido, nombrep FROM Empleado_en_Proyecto WHERE nombrep=‘ProductoX’ ; Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas La actualización de datos a través de vistas tiene algunas limitaciones Por un lado, actualizar a través de una vista definida sobre varias tablas base suele dar problemas, pues puede haber ambigüedad UPDATE Empleado_en_Proyecto SET nombrep = ‘ProductoZ’ WHERE apellido=‘Silva’ AND nombre=‘José’ AND nombrep=‘ProductoX’; Esta modificación puede traducirse a dos actualizaciones distintas de las tablas base de la vista (EMPLEADO, PROYECTO y TRABAJA_EN), como se muestra en la siguiente diapositiva… Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas  UPDATE Trabaja_en SET nump = (SELECT numerop FROM Proyecto WHERE nombrep = ‘ProductoZ’) WHERE nsse = (SELECT nss FROM Empleado WHERE apellido = ‘Silva’ AND nombre = ‘José’) AND númp = (SELECT numerop FROM Proyecto WHERE nombrep = ‘ProductoX’) ;  Modifica los vínculos en TRABAJA_EN: cada fila que relacionaba las filas de ‘José Silva’ en EMPLEADO y de ‘ProductoX’ en PROYECTO, pasa a relacionar tal empleado con la fila ‘ProductoZ’ de PROYECTO  UPDATE Proyecto SET nombrep = ‘ProductoZ’ WHERE nombrep = ‘ProductoX’ ;  Produce igual efecto que  pero modifica nombrep en PROYECTO: al calcular la vista, mostrará ‘ProductoZ’ para todos los que antes aparecían con ‘ProductoX’ Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas Por otro lado, algunas actualizaciones a través de vistas carecen de sentido UPDATE Info_depto SET sal_total = WHERE nombred=‘Investigación’ ; sal_total se define como la suma de salarios individuales de los empleados y muchas actualizaciones de las tablas base satisfarían esta actualización Así que no se garantiza que “toda vista sea actualizable” Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas Una vista sería actualizable si... Implicara una única actualización posible de las tablas base, o bien Hubiera varias actualizaciones posibles, pero existiera un procedimiento específico de actualización de tablas base, tal que... El usuario pudiera elegir el procedimiento, especificándolo en la definición de la vista, o bien El SGBD pudiera elegir el procedimiento, según la actualización más probable Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas En general... Una vista con una sola tabla base SÍ es actualizable si sus columnas contienen la clave primaria u otra clave candidata de la tabla base Pues se establece una correspondencia entre cada fila de la vista y una única fila de la tabla base Una vista definida sobre varias tablas mediante reuniones NO es actualizable Una vista definida mediante agrupación y funciones agregadas Tema 2. Modelo relacional de datos

LDD: modificación a través de vistas Opción de verificación de vistas CREATE VIEW Emp_Precario AS SELECT nombre, apellido, nss, nif, salario, nd FROM Empleado WHERE salario < 900 ; *¿Qué pasaría al ejecutar estas sentencias? INSERT INTO Emp_Precario VALUES (‘Dimas’, ‘Pi', ‘ ’, ‘ D’, 1025, 1); UPDATE Emp_Precario SET salario = 950 WHERE nif=‘ E’; Cláusula WITH CHECK OPTION En la definición de toda vista actualizable que se vaya a utilizar para la modificación de datos Indica al SGBD que debe comprobar cada INSERT y UPDATE sobre la vista, y rechazarlo si su realización implicara que la fila nueva o modificada no cumpliera la condición de definición CREATE VIEW Emp_Precario AS SELECT nombre, apellido, nss, salario, nd FROM Empleado WHERE salario < 900 WITH CHECK OPTION ; Tema 2. Modelo relacional de datos

LDD: implementación de vistas 1. Estrategia de actualización de consultas de definición Cada consulta sobre la vista se traduce a una consulta sobre las tablas base La vista se rellena de filas a partir de la ejecución de la consulta  Poco eficiente cuando la <consulta_de_definición> es compleja, con tiempo de ejecución apreciable, y se aplican muchas consultas sobre la vista en poco tiempo 2. Estrategia de materialización de vistas 1ª consulta sobre la vista  creación de tabla temporal física Se conserva la tabla para posteriores consultas sobre la vista Necesaria estrategia para actualización incremental de la tabla temporal tras cualquier modificación sobre las tablas base  actualización permanente Si no se hace referencia a la vista tras un tiempo, el sistema la eliminará (y la recalculará en una consulta futura) Sea cual sea la estrategia de implementación, hemos de pensar que el contenido de la vista NO está almacenado. Tema 2. Modelo relacional de datos

LDD: Modificación de la estructura (alteración) de los elementos del esquema de base de datos Alteración de tablas: ALTER TABLE <nombre_tabla> ... ; Adición y Eliminación de Columnas Modificación de la Definición de Columnas Adición y Eliminación de Restricciones de Tabla Alteración de dominios: ALTER DOMAIN <nombre_dominio> ... ; Eliminación y Adición de valor por defecto Eliminación y Adición de Restricciones de Dominio Nos centraremos en las tablas que se almacenan (no alteración de vistas). Y en los dominios. Tema 2. Modelo relacional de datos

LDD: alteración de tablas Adición de una columna a una tabla ya existente ALTER TABLE <nombre_tabla> ADD <definición_columna> ; No está permitido NOT NULL en la definición de una nueva columna (si es necesaria esta restricción, podrá establecerse después) * Añadir una columna a EMPLEADO para contener el puesto de trabajo ALTER TABLE Empleado ADD puesto VARCHAR(12); Todas las filas de EMPLEADO tendrán puesto a NULL Para introducir un valor para la columna, en cada fila existente: Especificar la cláusula DEFAULT al añadir la columna: ALTER TABLE Empleado ADD puesto VARCHAR(12) DEFAULT ‘aprendiz’; Utilizar después una orden UPDATE Tema 2. Modelo relacional de datos

LDD: alteración de tablas Eliminación de una columna de una tabla ALTER TABLE <nombre_tabla> DROP <nombre_columna> <opción>; <opción> puede ser... CASCADE: elimina la columna y toda restricción o vista que le hace referencia RESTRICT: sólo elimina la columna si ninguna vista ni restricción le referencia * Eliminación de la columna dirección de la tabla EMPLEADO ALTER TABLE Empleado DROP direccion CASCADE; ALTER TABLE Departamento DROP numerod <opción>; Si <opción> = RESTRICT: no elimina la columna ‘numerod’, pues existe una columna ‘EMPLEADO.nd’ que le hace referencia Si <opción> = CASCADE: elimina la columna y la restricción de integridad referencial que vincula ‘EMPLEADO.nd’ con DEPARTAMENTO. La columna ‘EMPLEADO.nd’ no es eliminada, pero deja de ser clave ajena ORACLE7 NO permite la eliminación directa de una columna de una tabla. Tema 2. Modelo relacional de datos

LDD: alteración de tablas Modificación de la definición de una columna ALTER TABLE <nombre_tabla> ALTER <nombre_columna> <acción> ; <acción> indica la modificación que se desea realizar... Eliminación de la cláusula DEFAULT existente ALTER TABLE Departamento ALTER nssdire DROP DEFAULT; Definición de un nuevo valor por omisión ALTER TABLE Departamento ALTER nssdire SET DEFAULT ‘ ’; En ORACLE7 este comando permite modificar más elementos que en SQL-92 ALTER TABLE T MODIFY columna tipodatos DEFAULT expresion restriccion null/not null unique primary key check expresion Tema 2. Modelo relacional de datos

LDD: alteración de tablas Modificación de una restricción de tabla La restricción que se desea modificar debe tener un nombre Eliminación de una restricción de tabla ALTER TABLE <nombre_tabla> DROP CONSTRAINT <nombre_RI> <opción>; ALTER TABLE Empleado DROP CONSTRAINT jefe_emp CASCADE; Adición de una restricción de tabla ALTER TABLE <nombre_tabla> ADD CONSTRAINT <nombre_RI> <definición_RI>; ALTER TABLE Empleado ADD CONSTRAINT salario_ok CHECK (salario > 0); ALTER TABLE Empleado ADD CONSTRAINT puesto_ok CHECK (puesto IS NOT NULL); Tema 2. Modelo relacional de datos

LDD: alteración de dominios Orden ALTER DOMAIN <nombre_dominio> <acción>; <acción> indica la modificación que se desea realizar... Eliminación y Reemplazo del valor por omisión ALTER DOMAIN <nombre_dominio> DROP DEFAULT; ALTER DOMAIN <nombre_dominio> SET DEFAULT <valor>; Eliminación y Definición de nuevas restricciones de dominio ALTER DOMAIN <nombre_dominio> DROP CONSTRAINT <nombre_RI_dominio>; ALTER DOMAIN <nombre_dominio> ADD [ CONSTRAINT <nombre_RI_dominio> ] <restricción>; Tema 2. Modelo relacional de datos

LDD: eliminación de elementos del esquema Eliminación de una vista. Orden DROP VIEW Destruye una tabla derivada, junto con su definición en el INFORMATION_SCHEMA del catálogo DROP VIEW <nombre_vista> ; Eliminación de un dominio. Orden DROP DOMAIN Destruye un dominio de datos, junto con su definición en el INFORMATION_SCHEMA del catálogo DROP DOMAIN <nombre_dominio> <opción> ; <opción> puede ser... RESTRICT: destruye el dominio si no hay ninguna columna definida sobre él CASCADE: se elimina el dominio y toda columna definida sobre él pasa a tener el tipo de datos sobre el que se había definido el dominio (este aspecto es ampliado en el tema “Integridad en sistemas de bases de datos relacionales”) Tema 2. Modelo relacional de datos

LDD: eliminación de elementos del esquema Eliminación de una tabla. Orden DROP TABLE Destruye una tabla base, junto con su definición en el INFORMATION_SCHEMA del catálogo DROP TABLE <nombre_tabla> <opción>; <opción> puede ser... RESTRICT: Destruye la tabla sólo si no se le hace referencia desde ninguna otra tabla (clave ajena), ni es tabla base de una vista CASCADE: Elimina la tabla junto con restricciones y vistas que la referencian Eliminación de un esquema. Orden DROP SCHEMA Destruye un esquema de BD, junto con su definición en el INFORMATION_SCHEMA del catálogo DROP SCHEMA <nombre_esquema> <opción>; RESTRICT: Destruye el esquema sólo si no contiene ningún elemento CASCADE: Elimina el esquema y las tablas, dominios y demás elementos contenidos en el esquema ORACLE7 incluye las órdenes: DROP TABLE T CASCADE CONSTRAINTS  efecto Opción CASCADE DROP TABLE T  efecto Opción RESTRICT Tema 2. Modelo relacional de datos

2.5. Integridad en Sistemas de Bases de Datos Relacionales
Tipos de restricciones 2.5.1 Reglas de integridad: consideraciones generales y componentes 2.5.2 Reglas de integridad en SQL-92 Reglas de integridad de dominio Reglas de integridad de tabla Reglas de integridad generales y Disparadores 2.5.3 Comprobación de restricciones Puesto que una base de datos es una representación o modelo de una porción del mundo real, la información almacenada debe cumplir en todo momento las restricciones, reglas o normas existentes en esa realidad (las Reglas del Negocio). Este tema describe cómo definir o especificar dichas restricciones en un esquema de base de datos relacional, en forma de reglas de integridad, lo que permite al SGBD conocer e imponer automáticamente dichas restricciones y, de este modo, impedir que la información almacenada sea incorrecta o inconsistente, es decir, que no refleje la realidad. Ejemplos de dichas restricciones, reglas o normas son las siguientes: El DNI de los alumnos debe ser único Un alumno no puede consumir más de 6 convocatorias de una misma asignatura. Todo profesor pertenece a un departamento. … En la explicación de este tema, además del conjunto de facilidades para el control de la integridad de los datos proporcionadas por el estándar SQL-92, se incluyen indicaciones acerca de las ofrecidas por el SGBD Oracle. Tema 2. Modelo relacional de datos

2.5.1 Reglas de integridad Consideraciones generales
Integridad: consistencia o corrección de datos en la base de datos Las reglas de integridad (RI) no son específicas para cada usuario Consideraciones generales 1. Nos interesan las reglas de integridad específicas de una BD (reglas del negocio), además de RI Entidad, RI Referencial... 2. Veremos las RI definidas sobre tablas base Por estar restringidas a contener datos correctos (reflejar la realidad) La regla “los títulos de las películas son únicos” se aplica a la tabla base PELICULA, y también a cualquier vista definida sobre ésta ¿Podemos definir RI sobre una vista (tabla derivada)? Sería deseable La vista heredaría toda RI de sus tablas base y podría añadir nuevas (ejemplo: clave primaria o alternativa nueva para la vista) Sólo consideraremos RI sobre tablas base (por simplicidad) Tema 2. Modelo relacional de datos

2.5.1 Reglas de integridad Consideraciones generales (y 2)
3. Nos interesa soporte de RI declarativo No nos centraremos en... Procedimientos o funciones almacenados, Disparadores (triggers) 4. Una BD en un estado de integridad es correcta: No viola ninguna RI conocida por el SGBD, es decir, Satisface AND lógico de todas las RI definidas en su esquema 5. La integridad es importante en... DISEÑO (estructuras de datos y reglas de integridad adecuadas) EJECUCIÓN (corrección de la información) 6. RI son mantenidas en el INFORMATION_SCHEMA del catálogo Subsistema de Integridad del SGBD: controla operaciones de usuario (INSERT,UPDATE,DELETE...) para asegurar que NO violan las reglas de integridad Ampliación de algunos puntos para su exposición en clase: 3. Soporte de RI declarativo. La ventaja de definir RI mediante SQL (declarativo) es que su escritura resulta más fácil que si se definen en el código de la aplicación (lenguaje de programación) o mediante disparadores (triggers), por lo que se evitan errores de programación. Además, las RI definidas de forma declarativa no eliminan la flexibilidad de acceso ad hoc a los datos, a diferencia de utilizar procedimientos almacenados para la integridad de datos mediante acceso controlado a los datos. Tanto los procedimientos como las funciones y los disparadores son almacenados en la BD (en Oracle, por ejemplo todo el código PL/SQL es almacenado en el Diccionario de Datos). 6. RI mantenidas en el INFORMATION_SCHEMA del catálogo (diccionario de datos). Las RI son definidas para las tablas de la BD, y no para las aplicaciones que acceden a las mismas, y son almacenadas en el INFORMATION_SCHEMA del catálogo (o Diccionario de Datos), lo que significa que son “reglas centralizadas”. Por esto, los datos introducidos o modificados por cualquier aplicación deben ajustarse a las correspondientes reglas de integridad definidas sobre cada tabla. Los procedimientos almacenados no proporcionan esta ventaja; los disparadores sí la proporcionan, pero su complejidad es mucho mayor que la de las RI declarativas. Así que siempre es mejor emplear RI declarativas para implementar reglas del negocio que controlar la integridad a través del código de la aplicación. Por otro lado, si una regla del negocio cambia, la RI correspondiente es lo único que debe cambiar convenientemente. Si se implementara por programa, debería modificarse el código de la aplicación, recompilar, depurar y comprobar… con el coste que ello conlleva. Así que otra ventaja es que se aumenta la productividad en el desarrollo de aplicaciones. Tema 2. Modelo relacional de datos

2.5.1 Reglas de integridad Componentes de una RI Nombre actor_cache_ok
Regla almacenada en INFORMATION_SCHEMA del catálogo con ese nombre Aparecerá en diagnósticos, producidos por el sistema como respuesta a intentos de violación de la regla (mensajes de error al usuario) Restricción NOT EXISTS ( SELECT * FROM ACTOR WHERE cache  0 ) Expresión booleana  Restricción de Integridad  Regla de Integridad La regla ... se satisface  la restricción es TRUE es violada  la restricción es FALSE Respuesta a un intento de violación de la regla Indica al SGBD qué hacer si se intenta una operación que viola la RI Por defecto RECHAZAR, que implica... Deshacer los posibles daños causados por la operación Mostrar información de diagnóstico (mensaje) Podría ser un procedimiento de complejidad arbitraria: tratarErr(...) Tema 2. Modelo relacional de datos

2.5.1 Reglas de integridad Creación, destrucción y tipos
Creación de una regla de integridad... (en cualquier momento) SGBD comprueba: ¿el estado actual de la BD satisface RI? No  RI rechazada Sí  RI aceptada Es almacenada en el INFORMATION_SCHEMA del catálogo La regla es activada (entra en vigor) * Para la RI del ejemplo, actor_cache_ok , el SGBD controlará todo INSERT INTO ACTOR… y UPDATE ACTOR SET cache =… Destrucción de reglas de integridad el sistema elimina su definición del INFORMATION_SCHEMA Las RIs pueden restringir los valores legales de... Dominio Tabla, Columna Base de datos Tema 2. Modelo relacional de datos

2.5.2 Reglas de integridad en SQL-92
Categorías de reglas de integridad 1. Reglas de integridad de Dominio Asociadas a un dominio de datos específico Es una expresión de complejidad arbitraria que define un dominio 2. Reglas de integridad de Tabla RIs de complejidad arbitraria incluidas en la definición de una tabla Pueden ser restricciones de Columna restricciones de Clave Candidata restricciones de Clave Externa restricciones de Comprobación Una tabla vacía cumple cualquier RI de tabla, aunque esa RI sea “esta tabla no puede estar vacía” 3. Reglas de integridad Generales RIs de complejidad arbitraria no incluidas en la definición de ninguna tabla Son otro elemento más de la BD, al mismo nivel que una tabla o vista Para exponer los diferentes tipos de reglas de integridad existentes, se sigue la taxonomía definida por el estándar SQL-92. Junto con la descripción de cada tipo de regla, se indica la forma de especificarla en el esquema de la base de datos. SQL-92 clasifica las reglas de integridad en tres categorías, en función del elemento de base de datos al que están asociadas: reglas de integridad de dominio, de tabla base y generales. Las reglas de tabla base se dividen, a su vez, en restricciones de integridad de columna, de clave candidata (es decir, de clave primaria o integridad de entidad y de clave alternativa), de clave externa (o integridad referencial ) y de comprobación (tipo check), y por tanto incluyen las restricciones estudiadas en el tema anterior “Modelo Relacional de Datos”. Tema 2. Modelo relacional de datos

Otras consideraciones Es útil ver la base de datos sujeta a una “RI gigante”... resultado del AND de todas las RI... generales de tabla de dominio aplicadas a cada columna de las tablas Significado formal de la base de datos Una regla de integridad es independiente de cualquier aplicación específica que acceda a la base de datos No contiene parámetros ni variables host (referencias a variables de los programas de aplicación) Una variable host es una variable del programa utilizada en sentencias SQL, para recoger datos de la BD. Como quizá ya se comentó (diapositiva 5), las RI son definidas para las tablas de la BD, y no para las aplicaciones que acceden a las mismas, y son almacenadas en el INFORMATION_SCHEMA del catálogo (o Diccionario de Datos), lo que significa que son “reglas centralizadas” e independientes de las aplicaciones. Por esto, los datos introducidos o modificados por cualquier aplicación deben ajustarse a las correspondientes reglas de integridad definidas sobre cada tabla. Tema 2. Modelo relacional de datos

Reglas de Integridad de Dominio Definición del conjunto de valores componentes de un dominio: Enumeración de valores posibles: (‘marron’,‘gris’, ‘azul’, ‘verde’, ‘negro’) Expresión de definición: edad  0 AND edad  120 RI como parte de la sentencia de definición del dominio CREATE DOMAIN <nombre dominio> [ AS ] <tipo de datos> [ DEFAULT <valor defecto> ] [ [ CONSTRAINT <nombre restricción> ] CHECK (<condición>) ]+ ; <valor defecto> suele contener un literal (perteneciente al dominio) o NULL Aplicada a cada columna (de cualquier tabla) definida sobre el dominio CREATE DOMAIN Color_ojos AS VARCHAR(10) DEFAULT ‘marron’ CONSTRAINT color_valido CHECK ( VALUE IN (‘marron’,‘gris’,‘azul’,‘verde’,‘negro’) ); En realidad, <valor defecto> = { literal | función sin argumentos | NULL } y función sin argumentos contiene uno de estos valores: USER ó CURRENT_USER (authorization-ID actual) SESSION_USER (authorization-ID de sesión SQL actual) SYSTEM_USER (ID del usuario del SO actual) CURRENT_DATE (fecha del día) CURRENT_TIME (hora actual) CURRENT_TIMESTAMP (marca de tiempo actual) Tema 2. Modelo relacional de datos

Reglas de Integridad de Dominio (2) NOT NULL no es una restricción de dominio válida CREATE DOMAIN Estado_civil AS CHAR(1) NOT NULL  Incorrecto CONSTRAINT estado_civil_ok CHECK ( VALUE IN (‘S’, ‘C’, ‘V’, ‘D’) ) ; CREATE DOMAIN Estado_civil AS CHAR(1) CHECK (VALUE IS NOT NULL)  Correcto CONSTRAINT estado_civil_ok CHECK ( VALUE IN (‘S’, ‘C’, ‘V’, ‘D’) ) ; Alteración de un dominio ALTER DOMAIN <nombre dominio> <acción>... ; Permite añadir y eliminar restricciones de integridad de dominio y valor por defecto Explicado en el tema anterior En la ejecución, los dominios no cambian, sino los valores de las columnas. Esto significa que una RI-dominio ‘per se’ nunca se chequea, sino la RI-columna correspondiente. Tema 2. Modelo relacional de datos

Reglas de Integridad de Dominio (y 3) Eliminación de un dominio DROP DOMAIN <nombre dominio> { RESTRICT | CASCADE } ; Opción RESTRICT La eliminación falla si el dominio es referenciado en cualquier definición de columna en una tabla, de vista o restricción de integridad En otro caso, éxito: el descriptor del dominio es eliminado del INFORMATION_SCHEMA del catálogo Opción CASCADE El dominio es eliminado del INFORMATION_SCHEMA, junto con toda vista y RI cuya definición hace referencia al dominio Las RI de dominio asociadas no son eliminadas, sino que cada columna definida sobre el dominio... Es definida directamente sobre el tipo de datos subyacente al dominio Si no tiene DEFAULT explícito, toma el del dominio (si éste lo tenía) Hereda toda restricción de integridad asociada al dominio, convertida en una restricción de tabla, - sustituyendo VALUE por el nombre de la columna Ejemplo CREATE TABLE PERSONA ( … ojos Color NULL, ); Tras ejecutar DROP DOMAIN Color CASCADE; el atributo PERSONA.ojos quedará definido así: ojos VARCHAR(10) DEFAULT ‘marrón’ NULL CHECK ojos IN (‘marrón, ‘gris’, ‘azul’, ‘verde’, ‘negro’ ) Importante: el atributo podrá contener o el NULL o uno de los valores indicados en el CHECK. Tema 2. Modelo relacional de datos

 puede hacer referencia a otras tablas, además de a la que la incluye
2.5.2 Reglas de integridad en SQL-92 Reglas de Integridad de Tabla Restricción asociada a una tabla específica No existe si la tabla no existe y Eliminar la tabla implica eliminar la RI RI especificada dentro de CREATE TABLE CREATE TABLE <nombre tabla> ( <lista de elemento de tabla> ) ; donde elemento puede ser: Definición de columna, que puede incluir RIs de columna Definición de... (precedida o no de CONSTRAINT <nombre restricción>) Restricción de clave candidata Restricción de clave externa Restricción de comprobación (CHECK) RI añadida/eliminada con ALTER TABLE <nombre tabla>... Toda RI de tabla es comprobada inmediatamente: Una operación de modificación sobre la tabla incluye el chequeo de todas sus RI (como paso final de la operación)+(una posible) acción  puede hacer referencia a otras tablas, además de a la que la incluye Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (2) 1. Definición de Columna - RI de Columna Especificación del tipo de datos o dominio y otras RI de columna No necesita sentencia de creación explícita: es parte de la definición de columna, dentro de la sentencia de creación de la tabla CREATE TABLE Actor ( nombre VARCHAR(30) NOT NULL, cache INT(9) DEFAULT 2000 NOT NULL, ojos Color_ojos NOT NULL, agencia CHAR(4), ...) ; Si se especifica un dominio para una columna, la comprobación es derivada hacia la comprobación de la restricción de dominio Una RI de columna se destruye al eliminar la columna de la tabla Esto ya se ha dicho antes, de forma general para todas las RI_Tabla. Además, se indica después en forma de pseudo regla de integridad: Toda RI de columna es comprobada inmediatamente: todo intento de INSERT o UPDATE (sobre la columna) con un valortipo de datos (o valordominio) es rechazado al instante La respuesta a un intento de violación siempre es RECHAZAR Tema 2. Modelo relacional de datos

 Posibles Acciones de Mantenimiento de la Integridad Referencial
2.5.2 Reglas de integridad en SQL-92 Reglas de Integridad de Tabla (3) 2. Definición de Restricción de Clave Candidata Clave Primaria PRIMARY KEY (<lista columnas>)  incluye RI Entidad Clave Alternativa UNIQUE (<lista columnas>) 3. Definición de Restricción de Clave Externa FOREIGN KEY (<lista columnas>) REFERENCES <tabla> (<lista columnas>) [ ON DELETE { NO ACTION | CASCADE | SET DEFAULT | SET NULL } ] [ ON UPDATE { NO ACTION | CASCADE | SET DEFAULT | SET NULL } ]  Posibles Acciones de Mantenimiento de la Integridad Referencial (explicadas en el tema anterior) Una clave primaria no puede contener un NULL, pero una clave alternativa (UNIQUE) sí puede contener NULL, a menos que se indique lo contrario en la definición de la columna correspondiente. Ejemplo PACIENTE(nif, num_historial, nombre, fecha_nacimiento…) nif es clave alternativa (y puede contener NULL, por ejemplo para pacientes de poca edad, para los cuales aún no se ha expedido nif) num_historial es clave primaria HISTORIAL_PACIENTE(numero, fecha_apertura,centro_salud,nif_paciente) numero es clave primaria y, a la vez, clave ajena a PACIENTE(num_historial) Claves externas: acciones referenciales Mantenimiento de integridad referencial ante intentos de violación Ejecución de operaciones adicionales que dejan la BD consistente Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (4) Recordemos sobre las claves externas que… Cualquier (combinación de) columna(s) puede ser clave externa SQL-92 permite que una clave externa (FK) se refiera a una clave candidata (CK):  clave primaria o clave alternativa Una clave externa y la clave candidata a la que referencia… Deben contener el mismo nº de componentes (columnas) y Las columnas “correspondientes” deben estar definidas sobre el mismo dominio o tipo de datos Referencia desde una FK de la tabla T2 a una CK de la tabla T1... Asegurar que cada T2.FK contiene un valor existente en T1.CK es el problema de la integridad referencial Pueden existir ciclos referenciales y auto-referencias SQL-92 permite (¡por supuesto!) que una FK pueda contener NULL salvo si se especifica NOT NULL para dicha FK en el CREATE TABLE Cualquier columna (o conjunto de columnas) puede ser una clave externa, incluso si al mismo tiempo forma(n) parte de una clave candidata (primaria o alternativa). Lo siguiente ya se explicó en el tema anterior: Si FK no es compuesta, no se necesita cláusula FOREIGN KEY... CREATE TABLE Actúa_en CREATE TABLE Actúa_en (actor ... , (actor ... REFERENCES Actor(codA) ..., film ... , film REFERENCES Pelicula(codP) ..., papel ... , papel ... , PRIMARY KEY (actor, film), PRIMARY KEY (actor, film) FOREIGN KEY (actor) ) ; REFERENCES Actor(codA)..., FOREIGN KEY (film) REFERENCES Pelicula(codP)... ... ) ; Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (y 5) 4. Definición de Restricción de Comprobación (CHECK) Regla que se refiere únicamente a la tabla que la contiene Puede especificar restricciones adicionales para una columna *El caché de un actor siempre está entre 300 y 1200€ CREATE TABLE ACTOR ( ..., CONSTRAINT actor_cache_ok CHECK ( cache  300 AND cache  1200 ), ... ); Puede definir restricciones que involucran varias columnas *Toda película se estrena después de finalizar su rodaje CREATE TABLE PELICULA ( CONSTRAINT pelicula_fechas_ok CHECK ( fecha_fin_rodaje < fecha_estreno ), Tema 2. Modelo relacional de datos

Reglas de Integridad Generales (Asertos) Predicado que expresa una condición que la BD debe satisfacer siempre Puede involucrar cualquier número de columnas de cualquier cantidad de tablas Es un elemento de BD, independiente de tablas y vistas existentes Especifica restricciones de integridad que pueden no ser... de clave (primaria o alternativa) de integridad referencial (clave externa) Tiene un nombre y consta de una condición (CHECK) Tema 2. Modelo relacional de datos

Reglas de Integridad Generales (2) Satisfacción y violación de una RI general Si alguna fila de la BD hace falsa la condición, el aserto es violado Un estado de la BD satisface un aserto si ninguna (combinación de) fila(s) de dicho estado viola la condición que incluye Creación de una RI general CREATE ASSERTION <nombre restricción>  nombre obligatorio CHECK ( <condición> ) ; Eliminación de una RI general DROP ASSERTION <nomRestricción> ;  Sin opción RESTRICT o CASCADE Elimina el aserto del INFORMATION_SCHEMA del catálogo Tema 2. Modelo relacional de datos

todo X satisface Y  ningún X satisface NO( Y )
2.5.2 Reglas de integridad en SQL-92 Reglas de Integridad Generales (3) Normalmente, la <condición> se expresa en negativo: todo X satisface Y  ningún X satisface NO( Y ) *Todo actor representado por la agencia 1 debe cobrar 300€ o más CREATE ASSERTION RI1_age1_cache CHECK (NOT EXISTS (SELECT * FROM Actor WHERE agencia=1 AND cache<300)) ; *La paga mínima de los actores que actúan en una película es de € CREATE ASSERTION RI2_paga_minima CHECK  (SELECT MIN(paga) FROM Actua_en) ; *Toda agencia representa a un máximo de 40 actores CREATE ASSERTION RI3_num_actores_age CHECK (NOT EXISTS (SELECT * FROM Actor GROUP BY codAge HAVING COUNT(*) > 40)) ; Tema 2. Modelo relacional de datos

Reglas de Integridad Generales (4) *Todo actor debe haber participado al menos en una película CREATE ASSERTION RI4_actor_en_pelicula CHECK (NOT EXISTS (SELECT * FROM Actor WHERE codA NOT IN (SELECT actor FROM Actua_en))); *Todo actor no protagonista de una película cobra menos que cualquier protagonista CREATE ASSERTION RI5_paga_actores CHECK (NOT EXISTS (SELECT * FROM Actua_en ACT WHERE papel<>‘protagonista’ AND paga >= ANY (SELECT paga FROM Actua_en PROTA WHERE ACT.film=PROTA.film AND PROTA.papel=‘protagonista’)); *Debe de existir al menos una distribuidora de películas CREATE ASSERTION RI6_existe_distribuidora CHECK ( 0 < SELECT COUNT (*) FROM Distribuidora ) ;  este aserto... - debe crearse una vez que ya exista alguna fila en DISTRIBUIDORA - una operación DELETE puede violarlo, pero nunca lo hará un INSERT No hay viviendas sin dueño (uno de los esquemas de BD de la Práctica P1): CREATE ASSERTION vivienda_propiedad CHECK ( NOT EXISTS (SELECT * FROM VIVIENDA WHERE codViv NOT IN (SELECT vivienda FROM PROPIEDAD))); Tema 2. Modelo relacional de datos

Reglas de Integridad Generales (5) Algunas RI generales pueden ser expresadas como RI de tabla *El código de los guiones es único ( si hay 2 guiones con igual código, son el mismo) CREATE ASSERTION RI7_guion_codigo_unico CHECK ( NOT EXISTS ( SELECT * FROM Guion G1 WHERE G1.codG IN (SELECT codG FROM Guion G2 WHERE G1.titulo<>G2.titulo OR G1.resumen<>G2.resumen OR G1.nomAutorPpal<>G2.nomAutorPpal OR G1.fechaFin<>G2.fechaFin OR G1.fechaEntrega<>G2.fechaEntrega) ) );  este aserto... - Equivale a especificar UNIQUE( codG ) en el CREATE TABLE Guion (…) El primer aserto es equivalente a este: CREATE ASSERTION existencia_distribuidora CHECK ( EXISTS SELECT * FROM Distribuidora ) ; codG:CODGUI, titulo: TITULOS, resumen: TEXTO, nomAutorPpal:NOMBRES, fechaFin:FECHA, fechaEntrega:FECHA Tema 2. Modelo relacional de datos

Reglas de Integridad Generales (y 6) Y viceversa: algunas RI de tabla pueden ser expresadas como RI generales Excepto la parte de una RI de clave externa que indica la acción de mantenimiento de la integridad referencial (ON DELETE… ON UPDATE…) *Los actores y películas anotados en la tabla ACTUA_EN deben existir CREATE ASERTION RI8_actua_en_ok CHECK (NOT EXISTS (SELECT * FROM Actua_en WHERE actor NOT IN (SELECT codA FROM Actor) OR film NOT IN (SELECT codP FROM Pelicula)));  este aserto... - Equivale a especificar... FOREIGN KEY (actor) REFERENCES Actor(codA)... y FOREIGN KEY (film) REFERENCES Pelicula(codP)... ... dentro del CREATE TABLE Actor (...) Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 En muchos casos conviene especificar una acción que ejecutar tras la violación de una restricción: Abortar la transacción que provoca la violación, o Informar de ello al usuario (mensaje), o Ejecutar cierto procedimiento, o Realizar otras actualizaciones en la base de datos... Esto se consigue mediante los disparadores o triggers Un disparador se ejecuta de forma automática como efecto secundario de cierta modificación de la BD Los SGBDR usan ampliamente los disparadores, pero no formaron parte del estándar hasta la versión SQL:1999  cada SGBDR los implementó con su propia sintaxis  Los disparadores SQL:1999 son similares a los de Oracle Junto con la descripción de las reglas de integridad generales (o asertos) se introducen algunos aspectos relacionados con los disparadores (triggers) que, aunque no están incluidos en la especificación de SQL-92, son soportados por algunos de los productos comerciales más extendidos, como Oracle. Además, los triggers forman parte de la especificación del estándar SQL:1999. [SKS 2002] [MS 2002] Melton, Jim ; Simon, Alan R. : “SQL:1999. Understanding Relational Language Components” [Pág. 396 y siguientes] Los triggers están directamente relacionados con el concepto de Base de Datos Activa, puesto que la base de datos puede llevar a cabo acciones por sí misma sobre los datos que contiene, como respuesta a la ocurrencia de ciertos eventos. Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 (2) Para diseñar un disparador, se debe especificar : Las condiciones en las que se debe ejecutar: Evento que causa la comprobación del disparador Condición que se debe cumplir para ejecutarlo La Acción que se realizará cuando se ejecute Es el modelo de disparadores evento-condición-acción La BD almacena los disparadores, por lo que... son persistentes y están accesibles para todas las operaciones de BD El SGBD ejecuta automáticamente un disparador cada vez que ocurre el evento especificado y se cumple la condición correspondiente La ejecución del disparador se considera parte de la ejecución de la operación que provoca su activación Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 (3) Definición de un disparador CREATE TRIGGER <nombre_disparador> { BEFORE | AFTER } { INSERT | UPDATE [OF <lista columnas>] | DELETE } ON <nombre_tabla> [ REFERENCING OLD [ ROW | TABLE ] [ AS ] <nombre> [ NEW [ ROW | TABLE ] [ AS ] <nombre> ] ] [ FOR EACH ROW | FOR EACH STATEMENT ] [ WHEN <condición> ] BEGIN ATOMIC ... END; Evento Parametrización Granularidad Condición [SKS 2002, pág ] y [MS 2002, pág. 400 y siguientes] Evento: {BEFORE|AFTER} {INSERT|DELETE|UPDATE|UPDATE [OF <lista columnas>]} ON <nombre tabla>. Incluye el momento de disparo, que puede ser inmediatamente antes (BEFORE) o inmediatamente después (AFTER) de que los efectos de la sentencia disparadora (la que causa el evento, es decir, la ejecución o disparo del trigger) sean aplicados a la tabla sujeto. También incluye el evento, que especifica la naturaleza de la sentencia SQL (u otro evento como un cambio causado por una acción referencial) que causa el disparo del trigger: INSERT, DELETE o UPDATE (de cualquier columna o de determinadas columnas). Tabla sujeto (subject) del trigger: la identificada mediante <nombre tabla>. Un trigger siempre debe pertenecer al mismo esquema que su tabla sujeto. Cláusulas REFERENCING… : permiten crear alias (para tablas) o nombres de correlación (para valores) que se puede usar para referenciar los valores anteriores y/o nuevos en [cada fila afectada de la] tabla sujeto del trigger. Usar OLD sólo tiene sentido para operaciones UPDATE o DELETE. Usar NEW sólo tiene sentido para UPDATE o INSERT. Cláusula FOR EACH ROW : asegura que el código del disparador se ejecuta para cada fila afectada por la sentencia disparadora. En este caso se puede usar tanto REFERENCING {OLD | NEW} ROW como REFERENCING {OLD | NEW} TABLE. Cláusula FOR EACH STATEMENT: se realiza una acción única para la sentencia SQL completa que causó el evento. En este caso sólo se puede usar REFERENCING {OLD | NEW} TABLE. Las tablas temporales que son referenciadas por los nombres de correlación o alias (sea el trigger de fila o de sentencia) se llaman tablas de transición. Para un trigger BEFORE (de fila o sentencia) no se permite especificar OLD TABLE ni NEW TABLE, y la Acción [¿¿sólo puede incluir una sentencia SQL??] (sentencia disparada) no puede realizar cambios en la BD. Todo esto sólo está permitido para triggers AFTER. La razón es la siguiente: es muy posible que las tablas de transición indicadas por OLD TABLE y NEW TABLE se vean afectadas por restricciones de integridad y acciones referenciales activadas por los cambios causados por la sentencia disparada; por tanto, los valores de las filas en esa tabla no son estables o predecibles adecuadamente hasta después de que la sentencia disparada sea ejecutada. Condición: WHEN. El disparador se ejecuta sólo si la condición se evalúa a TRUE; si se evalúa a NULL (desconocido) o FALSE, no. Acción Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 (4) * Antes de que un usuario elimine una o varias filas de la tabla PELICULA, el sistema debe anotar dicha acción en una tabla DIARIO_BORRADOS, indicando el usuario y el momento concreto en el que se realiza dicha operación. CREATE TRIGGER anotacion_borrado_pelicula BEFORE DELETE ON PELICULA FOR EACH STATEMENT INSERT INTO Diario_Borrados VALUES( ‘PELICULA’, CURRENT_USER, CURRENT_TIMESTAMP); Si la acción del trigger sólo consiste en una sentencia SQL, no es necesario utilizar las palabras reservadas BEGIN ATOMIC ni END  Este trigger está escrito en SQL:1999, y no en SQL de Oracle… Acción: BEGIN ATOMIC ... END puede especificarse varias instrucciones SQL (INSERT, UPDATE, ...). Si la acción del trigger sólo consiste en una sentencia SQL, no es necesario utilizar las palabras reservadas BEGIN ATOMIC ni END. Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 (5) * Si un actor no protagonista de una película percibe una paga no inferior que la de un protagonista, asignarle el mínimo cobrado por un protagonista menos 1000€. CREATE TRIGGER PagaNoProta AFTER UPDATE OF paga ON ACTUA_EN REFERENCING NEW ROW AS nueva FOR EACH ROW WHEN nueva.papel <> ‘protagonista’ AND nueva.paga ≥ (SELECT MAX ( paga ) FROM ACTUA_EN WHERE film = nueva.film AND papel = ‘protagonista’ ) BEGIN ATOMIC UPDATE ACTUA_EN SET paga = (SELECT MIN( paga ) FROM ACTUA_EN WHERE actor = nueva.actor AND film = nueva.film END; En Oracle este trigger tendría el problema de la tabla mutante Se verá en las prácticas de PL/SQL IMPORTANTE: En ORACLE, este trigger tiene un error grave, conocido como el problema de la tabla mutante. Una tabla mutante es una tabla que está siendo modificada por una sentencia INSERT, UPDATE o DELETE, o una tabla que podría ser actualizada por los efectos de una acción referencial (DELETE CASCADE, por ejemplo). La sesión que ha emitido la sentencia disparadora del trigger no puede consultar o modificar una tabla mutante; esto significa que en la Acción del trigger no se puede consultar ni modificar una tabla mutante (en la diapositiva se intenta modificar la propia tabla sujeto del trigger, que está siendo modificada mediante un UPDATE). Esta restricción evita que un trigger vea un conjunto de datos inconsistente. Se aplica a todos los triggers que usan la cláusula FOR EACH ROW y triggers de sentencia que son disparados como resultado de un DELETE CASCADE. Las vistas que están siendo modificadas en triggers de tipo INSTEAD OF no se consideran mutantes. Cuando un trigger encuentra una tabla mutante, ocurre un error en tiempo de ejecución, los efectos del cuerpo del trigger y la sentencia disparadora son deshechas y el control se devuelve al usuario o la aplicación. Podría crearse otro trigger para la inserción de una fila en ACTUA_EN. Tema 2. Modelo relacional de datos

Disparadores - versión SQL:1999 (y 6) Los disparadores combinan los enfoques declarativo y procedimental El evento y la condición del disparador son declarativos Su acción opera por procedimientos Comparación ASSERTION vs. TRIGGER ASSERTION prohibe realizar una actualización que viola el aserto (es decir, que hace FALSE la condición) TRIGGER puede permitir la actualización que cumple la condición (es decir, que viola una RI), pero ejecuta una acción (que puede reparar la violación, dejando consistente la BD) Las condiciones especificadas en una y otro son inversas SQL:1999 simplifica la interacción inevitable entre las acciones referenciales (que podrían hacer cambios sobre cierta tabla) y los triggers (definidos para dicha tabla o que hacen cambios sobre ella) especificando que toda restricción de integridad, incluidas las restricciones de integridad referencial, es evaluada adecuadamente y toda acción referencial es ejecutada, antes de que los triggers AFTER sean disparados. La razón de esto es el requisito de que todas las restricciones sean satisfechas antes de que la sentencia SQL pueda ser considerada “exitosa”; esta determinación tiene que ser hecha después de que todos los triggers hayan sido procesados, porque la propia ejecución de los triggers podría cambiar los contenidos de las tablas de forma que se violara restricciones de integridad de diversos tipos. Tema 2. Modelo relacional de datos

Características adicionales (pseudo-RIs) SQL rechaza todo intento de INSERT o UPDATE que viole una especificación de tipo de datos Ejemplo: introducción de valor CHAR en columna definida como INTEGER Una especificación de tipo de datos puede verse como una “forma primitiva” de restricción de integridad de dominio Una violación de una RI de dominio o de tipo de datos se detecta en tiempo de ejecución SQL rechaza todo intento de INSERT o UPDATE sobre una vista, si viola la condición de definición de la vista Siempre que se haya especificado la “opción de verificación” en la definición de la vista (WITH CHECK OPTION) Tema 2. Modelo relacional de datos

2.5.3 Comprobación de restricciones
En general, el SGBD comprueba una RI de inmediato, como último paso de la ejecución de una sentencia SQL Si la RI es violada por la sentencia, ésta es cancelada y no tiene efecto sobre la base de datos A veces es necesario que ciertas restricciones no sean comprobadas hasta pasado un tiempo, pues si se hiciera de inmediato siempre fallarían Ciclo referencial EMP DEP Inicialmente, EMP y DEP están vacías CREATE TABLE EMP CREATE TABLE DEP ( cod_emp ... ( cod_dep ... , depto ... , jefe ... , FOREIGN KEY ( depto ) FOREIGN KEY ( jefe ) REFERENCES DEP ( cod_dep ) ... , REFERENCES EMP ( cod_emp )... , ... ) ; ) ; Con chequeo inmediato de las RI de clave externa (RI referencial), todo INSERT de una fila en EMP o en DEP fallaría, pues nunca encontraría la fila destino (referenciada) en la otra tabla… Tema 2. Modelo relacional de datos

Modos de comprobación En un momento dado, dentro de cierta transacción SQL, toda restricción de integridad debe estar en modo... INMEDIATE: será comprobada inmediatamente, o DEFERRED: será chequeada al final de la transacción (diferida) Para algunas restricciones de integridad, la comprobación diferida no tiene sentido: Restricciones de dominio y tipo de datos Restricción de columna NOT NULL y Restricciones de clave candidata (UNIQUE, PRIMARY KEY) En la exposición oral omitir el término TRANSACCIÓN, pues aún no se ha estudiado. Tema 2. Modelo relacional de datos

Modos de comprobación (2) Una definición de RI puede incluir estas dos cláusulas… [ INITIALLY {IMMEDIATE | DEFERRED} ] [ [ NOT ] DEFERRABLE ] Modo inicial de la RI: INITIALLY DEFERRED o INITIALLY IMMEDIATE Especifica el modo en el que está la RI tras de ser definida (creada) y al comienzo de cada transacción SQL Opción de cambio de modo: DEFERRABLE o NOT DEFERRABLE Indica si la RI puede pasar a modo DEFERRED Valores asumidos por omisión: Si no se indica ningún modo inicial, se asume INITIALLY IMMEDIATE Si se especifica INITIALLY IMMEDIATE (o se asume)... Si no se indica DEFERRABLE ni NOT DEFERRABLE, asume NOT DEFERRABLE Si se especifica INITIALLY DEFERRED, no puede indicarse NOT DEFERRABLE Puede ponerse DEFERRABLE, aunque se supone En Oracle7 no se implementa el modo de comprobación de esta forma. Pero existe la posibilidad de activar y desactivar (habilitar/inhabilitar) restricciones de integridad (Ver anexo) En Oracle9i sí se implementa (y además, mantiene la habilitación/inhabilitación). La sintaxis es la siguiente: INITIALLY (IMMEDIATE (DEFERRABLE | NOT DEFERRABLE) | DEFERRED [DEFERRABLE]) Tema 2. Modelo relacional de datos

Modos de comprobación (y 3) Sentencia SET CONSTRAINTS SET CONSTRAINTS {<lista restricciones> | ALL} { DEFERRED | IMMEDIATE} Establece el modo para varias RIs para la transacción actual Toda RI mencionada debe ser DEFERRABLE De hecho ALL  todas las RIs diferibles DEFERRED: toda RI mencionada pasa a modo diferido IMMEDIATE: cada RI pasa a modo inmediato y es comprobada si falla la comprobación de alguna RI, falla SET CONSTRAINTS y ninguna RI cambia de modo En Oracle9i también existe el comando SET CONSTRAINTS, que especifica, para una transacción particular, si una restricción de integridad diferible se chequeará tras cada sentencia LMD o bien cuando la transacción sea confirmada. Prerrequisitos Para especificar cuándo será comprobada una restricción diferible se debe tener el privilegio SELECT sobre la tabla a la que se aplica la restricción, a menos que se sea el propietario de la tabla. Sintaxis SET { CONSTRAINT | CONSTRAINTS } { <lista restricciones> | ALL } { IMMEDIATE | DEFERRED } ; <lista restricciones>: Especifica el nombre de una o más restricciones de integridad. ALL : Significa “todas las restricciones diferibles” IMMEDIATE: Indica que las condiciones especificadas por la restricción diferible serán comprobadas inmediatamente después de la ejecución de cada sentencia LMD DEFERRED: Indica que las condiciones especificadas por la restricción diferible serán chequeadas cuando la transacción sea confirmada Ejemplos Se puede verificar el éxito de las restricciones diferibles con anterioridad a su confirmación, ejecutando una sentencia SET CONSTRAINTS ALL IMMEDIATE La siguiente sentencia establece que tres restricciones pasen a modo diferido, es decir, serán comprobadas cuando la transacción se confirme. Este ejemplo falla si las restricciones fueron definidas como NOT DEFERRABLE. SET CONSTRAINTS emp_job_nn, emp_salary_min , DEFERRED; Los conceptos COMMIT y ROLLBACK los estudiaremos con detalle en un tema posterior. Han sido incluidos en este último apartado por una cuestión de completitud y coherencia del temario. Ejecutar COMMIT implica realizar SET CONSTRAINTS ALL IMMEDIATE Si la comprobación de alguna RI falla  COMMIT falla  la transacción completa falla (rollback) Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (5) Claves externas: acciones referenciales (recordatorio) Mantenimiento de integridad referencial ante intentos de violación Ejecución de operaciones adicionales que dejan la BD consistente ON DELETE... Indica la regla de borrado para filas de T1 respecto de T2.FK Qué ocurre si se intenta eliminar una fila r1 de T1 y existe alguna fila r2 en T2 que le hace referencia (e.d. contiene un valor r2.FK = r1.CK) Acciones referenciales posibles: a. NO ACTION (opción por omisión) Rechazar la operación de eliminación sobre T1 b. CASCADE Eliminar junto con r1 toda fila r2 de T2 que se refiera a r1 (propagación) c. SET DEFAULT Asignar su valor por defecto a cada componente de la FK en toda fila r2, y eliminar r1 Debe existir una fila en T1 con cada componente de CK a su valor por defecto d. SET NULL Asignar NULL a cada componente de la FK en todas las filas r2, y eliminar r1 Cada componente de la FK debe tener nulos permitidos Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (6) ON UPDATE... Indica la regla de actualización para T1.CK respecto de T2.FK Qué ocurre si se intenta modificar la clave candidata dentro de una fila r1 de T1 y existe alguna fila r2 en T2 que le hace referencia (contiene valor r2.FK = r1.CK) Acciones referenciales posibles: a. NO ACTION (opción por omisión) Rechazar la actualización sobre T1.CK b. CASCADE Propagar la actualización de CK a toda fila r2 de T2 que se refiera a r1 c. SET DEFAULT Asignar su valor por defecto a los componentes de FK que corresponden a componentes modificados de T1.CK, en todas las filas r2, y actualizar r1 Debe existir una fila en T1 con cada componente de CK a su valor por defecto d. SET NULL Asignar NULL a los componentes de la FK correspondientes a componentes modificados en T1.CK, en todas las filas r2, y actualizar r1 Tales componentes de la FK debe tener nulos permitidos Tema 2. Modelo relacional de datos

Reglas de Integridad de Tabla (7) Comportamiento ante una operación de manipulación de datos, en función de la acción referencial especificada Sea T2.FK una clave externa hacia la clave candidata T1.CK ... La definición de FK no incluye ON DELETE ni ON UPDATE... INSERT en T2 o UPDATE de T2.FK si el valor de T2.FK no existe en T1.CK  Rechazar (NO ACTION) DELETE en T1 o UPDATE de T1.CK si alguna fila de T2 le hace referencia  Rechazar (NO ACTION) La definición de FK incluye ON DELETE o bien ON UPDATE... si alguna fila de T2 le hace referencia  ejecución de la acción referencial especificada en las cláusulas Tema 2. Modelo relacional de datos

Presentaciones similares

Presentación del tema: ""— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Presentaciones similares

Presentación del tema: ""— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback