Sistemas de bases de datos

Un sistema de bases de datos está formado por:

• La base de datos: conjunto de datos relacionados entre sí. A su vez está formada por:
  • Diccionario de datos: contiene la descripción de la estructura de la BD, los “metadatos”.
  • Datos
• El sistema gestor de bases de datos: conjunto de programas que permite definir, crear, manipular y controlar el acceso a la base de datos.
• Los usuarios: administradores, diseñadores, usuarios finales, etc.

Ventajas del uso de SGBD

• Disminución y control de la redundancia
• Evitar inconsistencias (copias distintas del original)
• Mantener la integridad (es decir, la información almacenada es correcta). Para esto se utilizan las denominas Restricciones de Integridad (de tipo de dato, longitud, etc.)
• Facilidad para representar, obtener y actualizar relaciones entre datos.
• Control del acceso, seguridad y concurrencia.
• Facilidad para respaldar los datos y recuperarlos ante errores.
• Flexibilidad, cambios en la estructura sin afectar a los datos almacenados.

Modelo de datos

El modelo de datos de una BD es un conjunto de conceptos que describen los tipos de los datos, sus relaciones, y las restricciones que éstos deben cumplir; además de operaciones para consulta y modificación tanto de estos datos como de la estructura de la BD. Tipos:

• Conceptuales (alto nivel): cercanos al mundo real, se basan en entidades, que tienen atributos que las definen, y que se relacionan con otras entidades. Por ejemplo, UML.
• Lógicos: permiten describir la estructura lógica global, son entendibles por los usuarios pero están cerca también de la organización física de los datos. Por ejemplo, relacional u orientado a objetos.
• Físicos: describen la estructura física de la BD, la forma de guardar y acceder a los registros, bloques, etc.

Esquemas y estado

Esquema: especifica el diseñado de la BD, los metadatos.

Estado: conjunto de datos que contiene la BD en un momento concreto. El gestor debe asegurar que sea siempre consistente.

Lenguajes e interfaces

LDD: lenguaje de definición de datos, permite especificar la estructura conceptual de la BD.

LDA: lenguaje de definición de almacenamiento.

LDV: lenguaje de definición de vistas, que permite definir las vistas de usuario. La mayoría de gestores utilizan LDD para definir las vistas.

LMD: lenguaje de manipulación de datos, permite el acceso, inserción, eliminación y modificación de los datos. Puede ser procedimental (qué obtener y como) o declarativo (que obtener pero no como).

Modelo relacional de datos

Es el modelo más usado, basado en registros.

En la definición formal, las relaciones cumplen estas propiedades:

• No existen tuplas repetidas
• Las tuplas no están ordenadas
• Los atributos no están ordenados
• Los valores de los atributos son atómicos

Reglas de integridad

Definen al gestor las restricciones que se aplican a las tuplas. El modelo relacional especifica dos tipos de características de integridad, aunque existen más:

• Claves candidatas, primarias y alternativas: subconjunto de atributos que cumplen la restricción de unicidad (no hay dos tuplas con los mismos valores para esos atrib.) ni contienen nulos.
• Claves ajenas: conjunto de atributos de una relación que hace referencia a la clave primaria de otra relación (o la misma). Permite establecer vínculos entre relaciones. El gestor debe asegurar que todas las claves ajenas tienen correspondencia (a no ser que sean nulas).

Nulos

Representan atributos desconocidos, perdidos o no aplicables. En las claves primarias, ninguno de sus atributos puede contener un nulo. En las ajenas si se permite el nulo.

Lenguajes de bases de datos

Álgebra relacional

Colección de operadores que utilizan relaciones como operandos y devuelven relaciones como resultado.

En las operaciones que necesiten que las relaciones de entrada sean compatibles, ambas relaciones deben tener mismo número de atributos y del mismo dominio.

Operaciones

Cálculo relacional

Se expresa mediante condiciones:

Cuyo resultado es el conjunto de tuplas t que satisfacen la condición. Ejemplos:

• { t | ACTOR(t) and t.cache>2000 }
• { t.nombre, t.nacionalidad | ACTOR(t) and t.cache>5000 }
• (∀t) (BANCO(t) and not(t.ciudad = ‘Londres’))
• (∃t) (BANCO(t) and t.ciudad = ‘Amsterdam’)

Integridad de datos

Reglas de integridad

Están formadas por:

• Nombre
• Restricción de integridad que se evalúa
• Respuesta a un intento de violación
  • Rechazar la operación
  • Otro procedimiento

Puede ser de varios tipos:

• De Dominio: definen un dominio. Ejemplo:

CREATE DOMAIN Color_ojos AS VARCHAR(10)

DEFAULT ‘MARRON’

CONSTRAINT color_valido

CHECK (VALUE IN (‘MARRON’,‘GRIS’,‘AZUL’,‘VERDE’,‘NEGRO’));

• De Tabla: incluidas junto a la definición de una tabla, y se aplican a:
  • Columnas: definen el tipo de dato, dominio, si está permitido el nulo, etc.

CREATE TABLE Actor

(nombre VARCHAR(30) NOT NULL)

• Claves candidatas y externas
  • Comprobaciones a nivel de tabla (CHECK)

CREATE TABLE PELICULA (

...,

CONSTRAINT pelicula_fechas_ok

CHECK (fecha_fin_rodaje < fecha_estreno ),

... );

• Generales (Asertos): no están incluidas a nivel de tabla, son otro elemento más de la BD. Puede involucrar cualquier número de tablas.

CREATE ASSERTION RI1_age1_cache

CHECK (NOT EXISTS (SELECT * FROM Actor

WHERE agencia=1 AND cache<300));

Comprobación de restricciones

Las restricciones se pueden comprobar de dos modos:

• IMMEDIATE: tras cada sentencia SQL ejecutada
• DEFERRED: al final de la transacción

Disparadores (Triggers)

Permiten especificar la acción a ejecutar tras la violación de una restricción. Para diseñarlos, se deben especificar:

• Evento que causa la comprobación del disparador.
• Condición que se debe cumplir para ejecutarlo.
• Acción realizada cuando se ejecute.

Ejemplo de declaración:

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;

Transacciones

Una transacción es una acción, o secuencia de acciones, llevada a cabo por un usuario o programa de aplicación, y que lee y actualiza el contenido de la base de datos. Sus propiedades son:

• Atomicidad: se ejecuta todo o nada de la transacción
• Integridad: la transacción lleva la BD de un estado de consistencia a otro.
• Concurrencia: los cambios realizados por T no son visibles hasta que se confirma.
• Recuperación: una vez finalizada con éxito, sus cambios perduran aunque el sistema falle.

Las transacciones se finalizan con COMMIT o ROLLBACK.4

Control de la concurrencia

Problemática asociada a la concurrencia

Algunos de los problemas asociados a la concurrencia son:

• Actualización perdida: cuando dos T leen un mismo valor, una de ellas lo escribe y luego la otra también los escribe, pero sin tener en cuenta el valor escrito por la primera.
• Lectura sucia: cuando una transacción lee un valor establecido por una transacción que ha fallado y se está deshaciendo.
• Resumen incorrecto: utilizar funciones de agregación, como cuenta o suma, sobre datos que están siendo modificados por otra transacción.
• Lectura no repetible: cuando una T lee un valor dos veces, pero en mitad de las lecturas otra T modifica dicho valor.

Serializabilidad

El objetivo de la Serializabilidad es el de planificar las transacciones para que no ocurran interferencias entre ellas.

Una planificación serie es aquella que permite que las operaciones de cada transacción se ejecuten consecutivamente sin que se intercales operaciones de otras transacciones. Ineficientes.

Una planificación no serie es aquella en la que las operaciones si se intercalan. Hay que buscar la forma de que esta intercalación no produzca errores. Se le denomina serializable si es equivalente a alguna planificación serie con las mismas transacciones. Esta equivalencia se puede definir mediante “equivalencia por conflictos”:

• Si dos T solo leen datos, el orden no importa.
• Si leen y escriben datos distintos, el orden no importa.
• Si leen los mismos datos y al menos una escribe el elemento, entran en conflicto y sí importa el orden de su ejecución.

Para convertir una planificación no serie a serializable se utiliza un grafo de precendencia:

• Se crea un nodo por cada transacción en P
• Crear una arista T_j→T_k si T_k lee o escribe un valor después de que T_j lo haya escrito.
• Crear una arista T_j→T_k si T_k escribe un valor después de que T_j lo haya leido.

Si el grafo contiene un ciclo, P no es serializable. En caso contrario, para convertirla en serializable se realiza una ordenación topológica de los nodos.

Métodos de bloqueo

Su objetivo es el de asegurar la serializabilidad de toda planificación de transacciones mediante un conjunto de reglas y protocolos. El uso de bloqueos no garantiza la serializabilidad de las planificaciones.

Los métodos de bloqueo se basan en el uso de bloqueos para controlar el acceso concurrente a datos:

• Bloqueo compartido: la T puede leer el elemento pero no escribirlo
• Bloqueo exclusivo: la T puede leer y actualizar el elemento.

Bloqueo en dos fases

Es el más conocido. Una transacción T sigue el protocolo de bloqueo en dos fases si todas las operaciones de bloqueo preceden a la primera operación de desbloqueo. Se puede dividir la T en dos fases:

• Fase de expansión (o crecimiento)
  • T puede adquirir bloqueos
  • T no puede liberar ningún bloqueo
• Fase de contracción
  • T puede liberar bloqueos existentes
  • T no puede adquirir ningún bloqueo

Este método si asegura la serializabilidad (si todas las T lo aplican), pero reduce la concurrencia y puede provocar problemas de interbloqueos o bloqueos indefinidos.

Algunas modificaciones del B2F son:

• B2F conservador o estático: T debe bloquear todos los elementos a los que tendrá acceso antes de comenzar a ejecutarse. (Sin interbloqueos)
• B2F estricto: T no libera ningún bloqueo exclusivo hasta terminar. Puede producir interbloqueos.
• B2F riguroso: T no libera ningún tipo de bloqueo hasta terminar.

Problema de interbloqueo

Se produce cuando dos o más transacciones están esperando que se libere un bloqueo establecido por la otra transacción. El gestor de la BD debe detectarlos y romperlos.

Existen tres técnicas de gestión de interbloqueos:

• Temporizaciones de bloqueos: las transacciones que esperan bloqueos solo esperarán una cierta cantidad de tiempo. Si transcurrido ese tiempo no pueden conseguirlo, se reiniciarán.
• Prevención de interbloqueos: se le asigna una marca temporal a cada transacción según su instante de inicio. Cuando una transacción intenta bloquear un elemento ya bloqueado, se pueden utilizar dos algoritmos:
  • Esperar-morir: si la T es más vieja que la que tiene el bloqueo espera, si no se aborta y reinicia.
  • Herir-esperar: si la T es más vieja, aborta y reiniciar la transacción que tiene el bloqueo (la joven, pero conserva su marca), si no espera.
• Detección de interbloqueos: se crea un grafo que muestra las dependencias entre transacciones y buscar ciclos en él. En caso de encontrarlos, aborta algunas transacciones para romperlos, intentando que dicha operación sea lo menos costosa posible.

Problema de inanición

Una transacción sufre inanición cuando se aborta varias veces y nunca termina su ejecución. La solución es asignar prioridades más altas a las T abortadas varias veces para que no vuelvan a ser víctimas.

Problema de bloqueo indefinido

Se produce cuando el gestor nunca selecciona una T que está esperando para establecer un bloqueo, debido a que siempre hay otras con más prioridad delante.

Se puede solucionar de dos modos:

• El primero que llega, primero en ser atendido.
• Aumento de prioridad en la espera, quien más tiempo lleva esperando más prioridad tiene.

Recuperación de fallos

El gestor debe asegurar que las transacciones ejecuten todas sus operaciones y su efecto sea permanente en la BD, o bien que no tengan ningún efecto en la BD ni otras T. (atomicidad y durabilidad).

Tipos de fallos

• Fallo local: solo afecta a la T fallida.
  • Fallo local previsto
  • Fallo local no previsto (bug o interrupción del usuario)
  • Fallo por imposición del control de concurrencia
• Fallo global: afecta a todas las T.
• Fallo del sistema (caída suave): mal funcionamiento de hardware o la red. Sin daños de disco.
• Fallo del soporte físico (caídas duras): BD corrupta
• Fallos físicos: desastres naturales, incendios, robos…

Recuperación

El objetivo es volver a dejar la BD en un estado correcto tras un fallo. El gestor se encarga de que ninguna transacción se pierda o se quede a medio ejecutarse.

Uno de los mecanismos empleados es el de la utilización de un fichero de bitácora donde se almacenan los detalles sobre las operaciones efectuadas

Recuperación del fallo de una transacción

• Si el fallo ocurre cuando T está en ejecución, se deshace. Para ello, se recorre la bitácora en orden inverso, deshaciendo cada una de las operaciones de escritura realizadas por la transacción.
• Si T ya ha sido confirmada, se debe rehacer T, leyendo la bitácora en orden desde su primera operación de escritura.

Bitácora adelantada

Consiste en impedir que el COMMIT de una T se complete hasta que toda la bitácora de esa T no se haya llevado a disco. Una vez llevado a disco, se realizan los cambios hechos por T en la BD de forma permanente, de manera que si el fallo ocurre en ese momento, se puede recuperar con la bitácora.

Puntos de comprobación

Es una marca incluida en la bitácora que implica:

• La escritura del disco del búfer de bitácora.
• La escritura en disco de todos los cambios hechos a la BD.

Estas entradas permiten recuperar el sistema desde el último punto de comprobación en vez de tener que comenzar desde el principio.

Planificación recuperable

Una planificación es recuperable si ninguna transacción T se confirma antes de haberse confirmado toda transacción U de la que T lee. Esto asegura que una vez que una T se ha confirmado, nunca será necesario deshacerla.

Esto puede dar lugar a reversiones en cascada, dado que una T no confirmada puede anularse porque ha leído de otra que se ha abortado.

Planificación estricta

Una planificación estricta impide que las transacciones lean o escriban elementos de otras transacciones que no han sido confirmadas o abortadas.

Estrategias de recuperación

Ante un fallo de tipo 5 ó 6, la única solución es restaurar una copia de seguridad y rehacer las entradas desde la bitácora.

Ante fallos del tipo 1 al 4, se utiliza la bitácora para rehacer o deshacer las transacciones afectadas.

Técnica basada en la actualización inmediata

La T puede modificar la BD en disco antes de terminar. Ante un fallo se rehace o deshace según el estado de la T en el momento del error.

Técnica basada en la actualización diferida

La T nunca modifica la BD en disco hasta que no se confirma. Si el fallo ocurre antes del punto de confirmación, no es necesario hacer nada. En caso contrario, es necesario rehacer sus operaciones.

Variación de la actualización inmediata

La T puede modificar la BD en disco antes de terminar. No se considera el punto de confirmación hasta que la T guarda sus cambios en disco. En caso de fallo antes de dicho punto, se deshace la operación, si ocurre después no se hace nada.

Niveles de aislamiento de transacción

SET TRANSACTION <modoacceso> ISOLATION LEVEL <aislamiento>

Modos de acceso:

• READ ONLY: prohíbe actualizaciones
• READ WRITE: por defecto

Nivel de aislamiento:

SQL

Consulta de datos: SELECT

SELECT <lista columnas> columnas o funciones que desea 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

Operaciones de conjuntos

UNION (U), INTERSECT (∩), EXCEPT (-)

En Oracle, EXCEPT se expera como MINUS. Las tablas operando deben ser compatibles. Para no eliminar duplicados se utiliza UNION ALL, INTERSECT ALL, EXCEPT ALL.

Conjuntos explícitos

v IN (…): indica si el valor v pertenece al conjunto de valores.

v <op> ANY(…): compara v con los elementos del conjunto, y devuelve TRUE si cumple para alguno de ellos. También se puede usar SOME(…)

v <op> ALL(…): compara v con los elementos del conjunto, y devuelve TRUE si cumple para todos ellos.

Consultas anidadas

EXISTS (S): comprueba que S no es una tabla vacía

UNIQUE (S): devuelve TRUE si NO hay filas repetidas en S

Vistas en línea

Es una subconsulta en la cláusula FROM de otra consulta. Ejemplo:

SELECT X.nd, X.nombred, E.nss, E.nombre, E.apellido, E.salario

FROM Empleado E, (SELECT nd, MAX(salario) AS max_sal FROM Empleado GROUP BY nd) X WHERE E.salario = X.max_sal AND E.nd = X.nd;

Reuniones

• INNER JOIN: por defecto, reúnen las tablas mediante una condición de reunión
• NATURAL JOIN: realiza una equi-reunión entre cada par de columnas con igual nombre de cada tabla.
• LEFT | RIGHT | FULL [OUTER] JOIN: reunión externa que incluya filas con NULL o sin correspondencia.

Inserción, modificación y eliminación de datos

INSERT INTO <tabla> [<columnas>] VALUES (<valores>)

UPDATE <tabla> SET <columna>=<valor>, [<columna2>=<valor2>, …] FROM <tabla> WHERE <condiciones> como valores se pueden usar NULL o DEFAULT

DELETE FROM <table> WHERE <condiciones>

El programador debe asegurar que los datos introducidos cumplen las restricciones de integridad del sistema, en caso contrario, el gestor rechazará aquellas consultas que no las cumplan.

LDD

Esquemas

Un esquema es un conjunto de tablas y otros elementos.

CREATE SCHEMA <nombre de esquema>

AUTHORIZATION <identificador del usuario propietario>

Eliminación de un esquema:

DROP SCHEMA <nombre_esquema> <CASCADE|RESTRICT>;

Tablas

Crea tablas, y define sus columnas y restricciones.

CREATE TABLE <nombre> (

<columna> VARCHAR(15) [NULL|NOT NULL] [DEFAULT <valor>],

...

[PRIMARY KEY <columnas],

[UNIQUE <columnas],

[FOREIGN KEY <columnas REFERENCES <tabla>(<columnas>) [ON DELETE <NO ACTION, CASCADE, SET NULL, SET DEFAULT>] [ON UPDATE <action>]],

[[CONSTRAINT <nombre_restricción>] CHECK (<expresión>)],

...

);

Tipos de datos

• Numéricos
  • INTEGER/INT
  • SMALLINT
  • REAL
  • FLOAT
  • NUMERIC(p, e) o DECIMAL(p, e), donde p es el número de dígitos y e la escala.

En ORACLE, todos los tipos numéricos se expresan con NUMBER(p, e)

• Caracteres
  • CHAR(n)
  • VARCHAR(n)
• Cadenas de bits
  • BIT(n)
  • BIT VARYING(n)
• Temporales
  • DATE
  • TIME
  • TIMESTAMP
  • INTERVAL
• Dominios personalizados
  • Se crean con CREATE DOMAIN, incluyendo su nombre, valor por defecto y restricciones de valores
  • Se destruyen con DROP DOMAIN <nombre> <CASCADE|RESTRICT>

Alteración de tablas

• Añadir columna: ALTER TABLE <nombre_tabla> ADD <definición_columna>
• Eliminar columna: ALTER TABLE <nombre_tabla> DROP <nombre_columna> <CASCADE|RESTRICT>
• Modificar columna: ALTER TABLE <nombre_tabla> ALTER <nombre_columna> <acción>;
• Añadir restricción: ALTER TABLE <nombre_tabla> ADD CONSTRAINT <nombre_RI> <definición_RI>
• Eliminar restricción: ALTER TABLE <nombre_tabla> DROP CONSTRAINT <nombre_RI> <opción>
• Eliminación de tablas: DROP TABLE <nombre> <CASCADE|RESTRICT>

Vistas

Una vista es una tabla derivada de otras tablas.

CREATE VIEW <nombre_vista> [ (<lista_nombres_columnas>) ]

AS <consulta_de_definición>

Para eliminarlas:

DROP VIEW <nombre>

Las vistas no se crean físicamente, si no que el gestor las crea cuando se consultan, por lo que su información siempre está actualizada. El gestor traduce las consultas a las vistas por su equivalente en consultas a la tabla base.

Sin embargo, la actualización de las vistas si está limitada, debido a que si la vista tiene más de una tabla base o utiliza funciones agregadas, las operaciones de actualización pueden ser ambiguas o imposibles de realizar.

La cláusula WITH CHECK OPTION indica al gestor que las actualizaciones llevadas a cabo sobre la vista deben comprobar que cumplen las condiciones de ésta. Por ej.: una vista con WITH CHECK OPTION que muestra salarios inferiores a 900€, no dejaría insertar ni actualizar un salario mayor a ese número.

El gestor puede trabajar de dos formas: traduciendo las consultas a la vista o creando una tabla física temporal como caché.

Índices

Los índices son una estructura de datos auxiliar que permite realizar búsquedas sobre uno o más atributos de manera eficiente.

Se crean índices automáticamente para claves PRIMARY KEY y UNIQUE.

CREATE INDEX <nombre> ON <table>(<columnas>)

DROP INDEX <nombre>