Informática‎ > ‎Bases de Datos‎ > ‎

03. Sistemas de gestión de datos

SISTEMA DE GESTIÓN DE BASES DE DATOS

Un sistema de gestión de bases de datos es una herramienta de software que permite la creación y manipulación de bases de datos definidas de acuerdo a las reglas del modelo subyacente al sistema.

SGBD

↓ se basa

modelo de datos

↓ se compone

estructuras de datos y operadores asociados

(o constructores de tipos)

Como ya se ha comentado en el tema I, los sistemas de gestión de bases de datos proporcionan una interfaz entre los programas de aplicación que acceden a los datos y el sistema operativo, caracterizándose principalmente porque permiten una descripción unificada de los datos y la definición de vistas parciales de los mismos para distintos usuarios. Las propiedades que se deben exigir a todo SGBD para que satisfaga las expectativas depositadas en la tecnología de bases de datos son: el mantenimiento de la independencia, la integridad y la seguridad de los datos.

Componentes y funciones de un sistema de gestión de bases de datos

De los objetivos perseguidos con las técnicas de bases de datos, expuestos en el tema I se pueden deducir cuáles son las funciones de un SGBD, y de estas funciones es sencillo inferir cuáles deben ser sus componentes básicos. En la Tabla 3.1 se presenta un resumen de estos tres aspectos.

 

Objetivos de las técnicas de BD

 

Funciones del SGBD

 

Componentes del SGBD

 

descripción unificada de los datos e independiente de las aplicaciones

--------------------------------------------------------

independencia de las aplicaciones respecto a la representación física de los datos

--------------------------------------------------------

definición de vistas parciales de los datos para distintos usuarios


 

definición de la base de datos a varios niveles: esquemas

- esquema lógico (definición de las estructuras de la base de datos)

- esquema interno (implementación de las estructuras del esquema lógico)

- esquemas externos (definición de estructuras derivadas)

establecer las correspondencias entre los esquemas

 

lenguajes para la definición de esquemas y los traductores asociados

 

gestión de datos

 

manipulación: consulta y  actualización

gestión y administración de la base de datos

 

lenguajes de manipulación y traductores asociados

herramientas para:

- reestructuración

- simulación, estadísticas

- impresión

 

integridad y seguridad de los datos

 

control de:

- la integridad semántica

- los accesos concurrentes

- la reconstrucción de la base de datos en caso de fallo

- la seguridad

 

herramientas para:

- control de la integridad

- reconstrucción frente a fallos

- control de la seguridad

Tabla 3.1: Objetivos, funciones y componentes de un SGBD

Las funciones de definición de esquemas y el establecimiento de las correspondencias entre ellos se verán con más detalle en el apartado 3.2 y las funciones de control de la integridad y la seguridad de la base de datos son el objetivo de los apartados 3.3 y 3.4 respectivamente.

Esquema de acceso del SGBD a los datos

Como se ilustró en la figura 1.1 del tema I, el SGBD introduce un nuevo nivel de independencia entre los usuarios y los datos, constituyendo en la práctica una capa sobre el sistema operativo del computador.

Como ya se indicó en el tema I, debido a las características de la base de datos relativas al volumen de datos y a su previsible existencia en un periodo dilatado de tiempo, ésta debe almacenarse en un dispositivo de memoria secundaria; lo que actualmente significa el uso de discos magnéticos. En un disco magnético, la memoria (bytes) disponible se divide en bloques (páginas) de longitud fija, que se definen cuando se da formato al disco, estos bloques representan la unidad de transferencia de datos entre el disco y la memoria principal. La transferencia la realiza el dispositivo de entrada/salida del computador, quien deposita el bloque leído en buffers de memoria principal (áreas contiguas de memoria con capacidad para uno o varios bloques de datos).

En el disco magnético, y desde el punto de vista del SO, los datos se organizan en ficheros de registros. En un fichero los registros se estructuran siguiendo alguna de las organizaciones de ficheros disponibles en el sistema. Cada tipo de organización implica una distribución física particular de los registros en el disco y un tipo de acceso (secuencial o directo) a los mismos. Estas organizaciones de ficheros son las que se utilizan para implementar las estructuras de datos de la base de datos, según se define en el esquema físico.

Esta jerarquía de abstracciones de datos (bloques de datos - ficheros de registros - estructuras de base de datos) existente en un sistema de bases de datos explica la Figura 3.1 en la que se ilustra el esquema de acceso del SGBD a los datos para satisfacer un requerimiento de consulta (esta figura puede verse como un refinamiento de la figura 1.1 del tema I).

Figura 3.1: Esquema de acceso del SGBD a los datos.

  • Paso 1: el programa de aplicación del usuario 1 realiza una consulta al SGBD.

  • Paso 2: el SGBD consulta el esquema externo 1, el esquema lógico y el esquema físico, realiza la correspondencia entre ellos y traduce la consulta del usuario en una operación de lectura sobre un fichero.

  • Paso 3: el SGBD emite órdenes al administrador de ficheros del SO indicando el registro que debe leer y en el fichero en el que está almacenado.

  • Paso 4: el SO solicita al administrador de entrada/salida el bloque en el que se encuentra el registro requerido.

  • Paso 5: el administrador de entrada/salida del SO recupera el bloque de datos solicitado y lo transfiere de la memoria secundaria a los buffers de memoria principal (si el bloque no estuviera ya en la memoria principal).

  • Paso 6: el administrador de archivos del SO devuelve al SGBD el registro solicitado.

  • Paso 7: el SGBD, comparando el esquema externo 1 y el esquema lógico, realiza las transformaciones necesarias para determinar los datos requeridos, y transfiere estos datos al área de trabajo del programa que ha realizado la consulta.

Si la consulta del usuario (paso 1) exige la recuperación de varios registros de datos los pasos del 3 al 6 se repetirán para cada uno de los registros necesitados. Recuperados estos registros, el SGBD los examina en memoria principal para ejecutar el paso 7.

INDEPENDENCIA DE DATOS

En el tema I se introdujo el concepto de independencia de datos, y se presentó brevemente la arquitectura que los sistemas de gestión de bases de datos soportan para asegurar esta independencia. En este apartado se va a analizar con más detalle la arquitectura de niveles de un SGBD así como los tipos de independencia que ésta proporciona.

Como ya se ha comentado en numerosas ocasiones, una de las características principales de la tecnología de bases de datos es la independencia de datos, entendida como la propiedad que asegura que los programas de aplicación escritos por los usuarios sean independientes de los cambios realizados en datos que no usan o en los detalles de representación física (implementación) de los datos a los que acceden.

En 1977, el grupo de estudio ANSI/SPARC realizó una propuesta de arquitectura para los sistemas de gestión de bases de datos, en la que se planteaba la definición de la base de datos en tres niveles de abstracción distintos: conceptual, interno, y externo. Las definiciones de la base de datos (esquema) en cada uno de estos niveles, deben tener las siguientes características: el esquema conceptual es la descripción del sistema de información con independencia del SGBD concreto que se vaya a utilizar, el esquema interno es la descripción del esquema conceptual en términos de su representación física y, por último, los esquemas externos son las distintas vistas parciales que del sistema de información tienen los diferentes usuarios.

En el estado actual de desarrollo de las técnicas de bases de datos, no existe ningún “modelo conceptual” accesible desde cualquier SGBD que permita definir el esquema conceptual; por este motivo, muchos autores prefieren distinguir dos esquemas en el lugar del esquema conceptual de la propuesta ANSI/SPARC (ver apartado 1.5 del tema I):

  • esquema conceptual: descripción del sistema de información desde un punto de vista organizativo independiente del SGBD que se utilice e incluso de que se utilicen o no técnicas de bases de datos. En este esquema se describe la información y las funciones de la organización desde un punto de vista no informático.

  • esquema lógico: definición de la base de datos expresada en términos del modelo de datos en que se base el SGBD que se vaya a utilizar, sin entrar en detalles de su representación física.

  • esquema interno (físico): definición de la representación de la base de datos en la memoria secundaria del computador. En este esquema no sólo se define la implementación elegida para las estructuras de datos del esquema lógico sino que se especifican también otros detalles sobre la organización de la base de datos en el disco.

  • esquema externo: definición de los datos de interés para un grupo de usuarios. Cada esquema externo consiste en un conjunto de estructuras (derivadas) definidas a partir de las estructuras del esquema lógico.

Ejemplo 3.1

En el ejemplo 2.35 del tema II, se presentaba el esquema lógico relacional correspondiente al sistema de información de una universidad. El esquema lógico se presentaba también definido en el lenguaje estándar SQL.

En el ejemplo se puede observar como un esquema lógico consiste en un conjunto de estructuras de datos y de restricciones de integridad sobre ellas definidas de acuerdo a las reglas de un modelo de datos, en este caso el Modelo Relacional.

Ejemplo 3.2

En el ejemplo 2.47 del tema II, se definía un esquema externo sobre el esquema lógico de la base de datos sobre la docencia en la universidad, comentado en el ejemplo anterior.

El esquema externo representa “la vista” de la base de datos para el departamento DSIC, en la que se incluyen sólo los datos de interés para este departamento.

El esquema externo consiste en un conjunto de relaciones derivadas (vistas) definidas a partir de las relaciones básicas del esquema lógico. Estas vistas no contienen datos almacenados, aunque pueden ser manipuladas por los usuarios del esquema externo como si se tratase de relaciones básicas. Como ya se comentó en el apartado 2.6 del tema II, la actualización de vistas está sometida a ciertas restricciones en los sistemas de gestión de bases de datos.

Para evaluar una consulta definida sobre vistas el SGBD traduce la consulta del usuario en una nueva consulta en la que se combina la definición de la consulta original y la de las vistas implicadas en ella.

Un informe con la docencia del DSIC para el presente curso académico por semestres y asignaturas se resolvería con la siguiente consulta al esquema externo del DSIC:

SELECT A.semestre, A.código, P.nombre, D.gteo, D.gprac

FROM Asignatura_DSIC A, Profesor_DSIC P, Docencia_DSIC D

WHERE A.código=D.cod_asg

AND

P.código=D.cod_pro

Para obtener el informe con una presentación particular debe utilizarse algún generador de informes (o un lenguaje de programación) que agrupe los datos de la anterior consulta de la forma deseada.

Ejemplo 3.3

Así como las definiciones del esquema lógico (Ejemplo 3.1) y del esquema externo (Ejemplo 3.2) presentados anteriormente son independientes del SGBD que se vaya a utilizar (están definidos en el lenguaje estándar SQL), la definición del esquema interno correspondiente dependerá de cada SGBD particular.

Un SGBD que soporte la arquitectura de niveles debe:

  • permitir definir los distintos esquemas de la base de datos y, en cada uno de ellos, los aspectos que interesan de los datos y sus interrelaciones. Como excepción, el esquema conceptual se define exteriormente al SGBD en términos de algún modelo conceptual (por ejemplo el modelo Entidad-Relación).

  • establecer las correspondencias entre los esquemas de forma que se pueda saber que un dato (X) en un esquema se corresponde con un dato (Y) en otro esquema.

  • aislar los esquemas de manera que los cambios en un esquema no afecten a los esquemas de nivel superior y en última instancia a los programas de aplicación.

Este último requisito se conoce por independencia de datos, en la Figura 3.2 se muestra la arquitectura de un SGBD y los niveles de independencia de datos que se comentan a continuación.

Figura 3.2: Arquitectura de niveles en un SGBD

  • independencia lógica entre el esquema lógico y los esquemas externos: los esquemas externos y los programas de aplicación no deben verse afectados por modificaciones del esquema lógico referentes a datos que no utilizan.

  • independencia física entre esquema lógico y esquema interno: el esquema lógico no debe verse afectado por cambios en el esquema interno referentes a la implementación de las estructuras de datos, los modos de acceso, el tamaño de las páginas y otros detalles de representación física.

Ejemplo 3.4

A continuación se presentan algunos ejemplos de modificaciones del esquema lógico que no obligarían a modificar los esquemas externos en un SGBD con independencia lógica; los ejemplos hacen referencia al esquema lógico del Ejemplo 3.1 y al esquema externo del Ejemplo 3.2:

  • se puede ampliar la relación Profesor con más campos, como el número de seguridad social, la titulación, etc., sin que esto afecte al esquema externo del DSIC y por lo tanto a todos los programas que se hayan desarrollado sobre él,

  • se puede eliminar la relación Departamento sin que este cambio en el esquema lógico afecte al esquema externo del DSIC. En general la eliminación de datos del esquema lógico no afectará a los esquemas externos que no los incluían en su definición,

  • si se reestructura el esquema lógico reagrupando los datos en estructuras distintas a las originales, las aplicaciones desarrolladas sobre el esquema externo del DSIC pueden no verse afectadas siempre que sea posible definir el mismo esquema externo a partir del nuevo esquema lógico, es decir siempre que se puedan definir las mismas relaciones (vistas) que lo componían, en este caso sólo será preciso cambiar la definición de las vistas.

El SGBD dispone de la definición de los esquemas lógico, interno y externos para satisfacer las peticiones de los programas. Cada programa de aplicación tiene un área de trabajo asociada en la cual recibe los datos y los mensajes del SGBD. En la Figura 3.3 se presenta un refinamiento de la Figura 3.1, en el que se ilustran las correspondencias entre esquemas (pasos 2.1, 2.2, 2.3, 7.1, 7.2) que el SGBD debe realizar para satisfacer una consulta del usuario, al establecimiento de estas correspondencias se le conoce como ligadura.

Figura 3.3: Funcionamiento del sistema ante una consulta a la base de datos

  • Paso 2.1: el SGBD obtiene el esquema externo 1 y examina la descripción de los datos solicitados.

  • Paso 2.2: el SGBD obtiene el esquema lógico y realiza la transformación correspondiente entre el esquema externo 1 y el esquema lógico.

  • Paso 2.3: el SGBD examina en el esquema interno la representación física de los datos solicitados.

  • Paso 7.1: el SGBD, comparando el esquema externo 1 y el esquema lógico, deduce los datos pedidos por el usuario 1 realizando para ello las transformaciones necesarias (transformaciones inversas a las realizadas en el paso 2.2).

  • Paso 7.2: el SGBD transfiere los datos requeridos al área de trabajo del programa que ha realizado la consulta

Como se observa en la figura anterior, el SGBD para ejecutar una operación del usuario debe traducir esta operación expresada en términos del esquema externo en una operación expresada en términos del esquema interno, es decir debe aplicar las correspondencias entre esquemas (ligadura).

La ligadura es la transformación de una operación descrita en términos del esquema externo en otra descrita en términos del esquema interno.

Esta transformación es necesaria ya que el SGBD necesita convertir un dato del esquema externo en un campo de un registro de un fichero del esquema interno. Dado que esta transformación pasa por el esquema lógico se puede hablar de ligadura lógica, o transformación entre el esquema externo y el lógico, y ligadura física, o transformación entre el esquema lógico y el interno.

Una vez ha tenido lugar la ligadura, desaparece la independencia de datos ya que el esquema externo ha sido traducido en términos del esquema interno; así resulta que, si la ligadura se ha producido al compilar el programa de aplicación, entonces cada vez que se produzca un cambio en el esquema lógico y/o interno será necesario volver a compilarlo, mientras que si la ligadura no tuviera lugar hasta la ejecución del programa no sería necesario (salvo para aquellos programas que utilicen datos directamente afectados por el cambio y que por ello deban modificar sus instrucciones). La ligadura puede tener lugar en uno de los momentos siguientes:

  • en la compilación, o en un paso de precompilación,

  • en el montaje para generar el módulo ejecutable del programa,

  • al iniciarse la ejecución de un programa, o, más exactamente, antes de que empiece a solicitar accesos a la base de datos, o

  • en cada acceso a la base de datos.

Cuanto más tarde se produzca la ligadura menos modificaciones habrá que realizar sobre los programas. En el Figura 3.3 se ha ilustrado la ejecución de una operación de consulta suponiendo que la ligadura se realiza en cada acceso a la base de datos.

Así pues, la independencia de datos es mayor cuanto más tardía es la ligadura. Obviamente, la construcción de un SGBD es tanto más compleja cuanto mas tardía es la ligadura; por otra parte, puesto que la ligadura puede tener un coste temporal que no es despreciable, el funcionamiento de las aplicaciones que utilizan la base de datos es tanto menos eficiente cuanto más frecuente sea la ligadura.

Ejemplo 3.5

En un sistema relacional la ligadura lógica se realiza cuando el SGBD traduce una consulta sobre un esquema externo en una consulta sobre las relaciones básicas a partir de las cuales se han definido las vistas que aparecen en la consulta original. En el caso del Ejemplo 3.2, establecer la ligadura lógica significa traducir la consulta

SELECT A.semestre, A.código, P.nombre, D.gteo, D.gprac

FROM Asignatura_DSIC A, Profesor_DSIC P, Docencia_DSIC D

WHERE A.código=D.cod_asg AND P.código=D.cod_pro

en la consulta

SELECT A.semestre, A.código, P.nombre, D.gteo, D.gprac

FROM Asignatura A, Profesor P, Docencia D

WHERE A.código=D.cod_asg AND P.código=D.cod_pro AND A.dep=’DSIC’

INTEGRIDAD

Uno de los objetivos de la tecnología de bases de datos es mantener la integridad de la base de datos, entendida como calidad de la información almacenada. Pero qué se entiende por ¿calidad de la información?

En los ejemplos Ejemplo 3.6 y Ejemplo 3.7, se presentan dos situaciones en las que la integridad de la base de datos se pierde por dos motivos distintos.

Ejemplo 3.6

A continuación se presenta la ejecución concurrente de los programas P1 y P2 que acceden a los mismos datos:

En el ejemplo se ilustra como el acceso concurrente (no controlado) de dos programas a los mismos datos puede causar la pérdida de actualizaciones. En este caso se ha perdido la actualización de P1.

Ejemplo 3.7

Procedimiento de recuperación:

  • sustituir el fichero de Cuentas por su copia de seguridad

Efecto negativo:

  • se han perdido las actualizaciones de 50 transacciones.

En el ejemplo se ilustra el procedimiento de recuperación de datos seguido en sistemas de gestión de datos primitivos (sistemas de ficheros).

La tecnología de bases de datos debe proporcionar mecanismos de recuperación de la base de datos más potentes que los mostrados en el ejemplo, de forma que permitan devolver a la base de datos a un estado íntegro lo más cercano posible en el tiempo al momento en que se produjo el fallo.

En el tema I se decía: en un sistema de bases de datos, los datos deben estar estructurados de forma que reflejen fielmente los objetos, las relaciones y las restricciones existentes en la parcela del mundo real del cuál la base de datos es una representación. Asimismo, y para que esta representación sea fiable, la base de datos debe ser sensible a los sucesos del mundo real, reflejando los cambios que la ocurrencia de éstos pueda provocar en la parcela del mundo representada.

Pero ¿cómo se representan los objetos, las relaciones y las restricciones existentes en el mundo real?, esto se hace al insertar en la base de datos la información correspondiente a los objetos y las relaciones de acuerdo con las estructuras de datos y las restricciones definidas en el esquema de la base de datos. Y ¿cómo se reflejan en la base de datos los cambios producidos por la ocurrencia de sucesos en el mundo real?, esto se hace por medio de actualizaciones de los usuarios sobre la base de datos.

Por ello, con el término “calidad de la información almacenada” se pretende hacer referencia a estos dos aspectos de los datos:

  1. el SGBD debe asegurar que los datos se almacenan correctamente, de acuerdo a las estructuras definidas, y que cumplan las restricciones especificadas en el esquema de la base de datos, y

  2. el SGBD debe asegurar que las actualizaciones de los usuarios sobre la base de datos se ejecutan correctamente y que se mantienen permanentemente.

De acuerdo con todo esto, para cumplir el objetivo de mantener la integridad de la base de datos, el SGBD debe disponer de herramientas y técnicas para:

  1. comprobar las restricciones de integridad, definidas en el esquema de la base de datos (frente a cualquier actualización del usuario),

  2. controlar la correcta ejecución de las actualizaciones (en un entorno concurrente), y

  3. recuperar (o reconstruir) la base de datos en el caso de que se pierda la integridad por algún motivo.

De todo lo dicho se desprende que la integridad de la base de datos se deteriora principalmente al realizar operaciones de actualización incorrectas sobre los datos o, lo que es menos frecuente, debido a accidentes o fallos físicos.

En un sistema de bases de datos, las operaciones de acceso a la base de datos, ya sean de lectura o de actualización, se organizan en transacciones que se diseñan agrupando operaciones que se deben ejecutar conjuntamente y no de forma aislada. La necesidad de agrupar operaciones en transacciones está provocada por la existencia de restricciones en el esquema de la base de datos, como se ilustra en el Ejemplo 3.8.

Ejemplo 3.8

Sea el esquema relacional del ejemplo 2.25 del tema II:

Empleado(dni: dom_dni, nombre: dom_nom, dirección: dom_dir, no_emp: dom_no, dep: dom_dep)

    CP: {no_emp}

    UNI: {dni}

    VNN: {nombre}

    CAj: {dep} → Departamento f(dep)=cod_dep

Departamento(cod_dep: dom_dep, descripción: dom_des)

    CP: {cod_dep}

    VNN: {descripción}

Restricciones de integridad (general):

∀DX: Departamento ( ∃EX: Empleado (DX.cod_emp = EX.dep))

Como es fácil observar, la base de datos correspondiente al esquema no es actualizable a través de operaciones aisladas de inserción. Si se desea insertar un nuevo empleado, debe existir primero su departamento de adscripción (clave ajena dep en Empleado), y si se inserta primero el departamento debe existir algún empleado adscrito a él (restricción general). Por ello la única forma de introducir datos en la base de datos, es insertando un nuevo departamento con su primer empleado a través de una transacción. La transacción funcionará como una operación elemental, es decir el efecto de las operaciones que la forman será considerado globalmente y no de forma aislada. Si la transacción se considera una unidad de ejecución la comprobación de las restricciones se realizará cuando toda la transacción se haya ejecutado, y por lo tanto la actualización de la base de datos será posible.

Concepto de transacción

Una transacción es una secuencia de operaciones de acceso a la base de datos que constituye una unidad lógica de ejecución.

Unidad lógica de ejecución significa que la transacción es equivalente a una operación elemental a todos los efectos.

Aunque una transacción puede incluir otro tipo de operaciones, cálculos aritméticos, interacción con el usuario, etc., desde el punto de vista del SGBD sólo son relevantes las operaciones de acceso a la base de datos, es decir las operaciones de lectura o de actualización de datos. Por otra parte y, aunque desde el punto de vista del usuario, existen tres tipos de operaciones de actualización: inserción, borrado y modificación, para el SGBD las operaciones de actualización se traducen siempre en la escritura de datos sobre la base de datos: la escritura de nuevos datos (inserción), la escritura de datos modificados (modificación) y la escritura de datos marcados como borrados (borrado). Por ello, y ya que el interés se centra en estudiar el procesamiento de transacciones por parte del SGBD, se considerará que las operaciones de una transacción consistirán exclusivamente en operaciones de lectura y escritura de datos. Por simplicidad, y para no hacer referencia a ningún modelo de datos particular, estas operaciones se van a representar de la siguiente forma:

  • leer (X): indica la lectura del dato (de la base de datos) de nombre X sobre una variable (del programa de acceso) del mismo nombre.

  • escribir (X): indica la escritura del valor de una variable (del programa de acceso) de nombre X sobre el dato (de la base de datos) del mismo nombre.

En la notación anterior se han obviado las referencias a la estructura de datos a la que pertenece el dato X (por ejemplo la tupla de una relación en el caso relacional).

De acuerdo a la jerarquía de abstracciones de datos expuesta en el 3.1.2, un dato de la base de datos (el dato X) coincidirá con un campo de un registro del fichero que implementa una estructura de la base de datos, registro que estará almacenado en un bloque del disco. Por lo tanto, y siguiendo el esquema de acceso expuesto en la Figura 3.1, las operaciones de lectura (leer (X)) y de escritura (escribir (X)) exigirán la ejecución de los siguientes pasos:

leer (X):

  1. buscar la dirección del bloque de disco que contiene el dato X

  2. copiar el bloque en un buffer de memoria principal (si el bloque no está ya en alguno de los buffers del sistema)

  3. copiar el dato X del buffer a la variable X del programa de acceso.

escribir (X):

  1. buscar la dirección del bloque de disco que contiene (o debe contener) el dato X

  2. copiar el bloque en un buffer de memoria principal (si es que el bloque no está ya en alguno de los buffers del sistema)

  3. copiar el dato X de la variable del programa de acceso a la posición adecuada dentro del buffer.

  4. copiar el bloque actualizado del buffer al disco (inmediatamente o en algún instante de tiempo posterior).

El paso 4 de la operación escribir (X) es el único que actualiza la base de datos. En algunas ocasiones el bloque actualizado no es almacenado inmediatamente en el disco, pudiendo sufrir, hasta que esto sucede, otras actualizaciones. La decisión de copiar el bloque del buffer al disco es tomada por el sistema operativo o por el sistema de gestión de bases de datos.

Además de las operaciones que constituyen propiamente la transacción, para un correcto procesamiento, el SGBD debe poder detectar el comienzo y el final de la transacción así como la confirmación o anulación de la misma después de haber finalizado. Estas operaciones se indican explícitamente por medio de sentencias del lenguaje de manipulación o bien implícitamente a través de otras operaciones de acceso al SGBD. La semántica de cada una de estas operaciones es la siguiente (la sintaxis no se corresponde con la de ningún lenguaje real):

  • Principio: el usuario indica al SGBD el comienzo de la ejecución de la transacción.

  • Fin (con confirmación parcial): el usuario indica al SGBD que todas las operaciones de la transacción se han ejecutado. El fin de la transacción no significa que sus cambios vayan a ser grabados definitivamente sobre la base de datos, en ese momento es preciso hacer comprobaciones (integridad, concurrencia, etc.) que determinarán si la transacción es definitivamente confirmada y todos sus cambios son grabados en la base de datos o por lo contrario debe ser anulada por el SGBD.

  • Anulación: el usuario o el SGBD finaliza la transacción anulando todos sus cambios. indica al SGBD que la transacción ha finalizado y que sus efectos deben ser anulados. Las razones por las que el usuario anula una transacción son totalmente subjetivas (reconocimiento de que la transacción era incorrecta, falta de datos, etc). Las razones por las que el SGBD puede anular una transacción en curso pueden ser de distinto tipo (comprobaciones, controles de concurrencia, etc).

  • Confirmación (definitiva): el SGBD confirma definitivamente una transacción confirmada (parcialmente) por el usuario. En ese momento se debe asegurar de que sus cambios son grabados sobre la base de datso.

Algunas de estas operaciones se realizan implícitamente, por ejemplo la conexión al SGBD desde un programa de usuario pude implicar el inicio de una transacción, la terminación normal del mismo puede representar su confirmación, y la terminación anormal su anulación.

En la Figura 3.4 se muestra el diagrama de transición de estados de las transacciones.

Figura 3.4: Diagrama de transición de estados de una transacción

Las propiedades que debe poseer una transacción son:

  • atomicidad: una transacción es una unidad atómica de ejecución en la que o se ejecutan todas sus operaciones o no se ejecuta ninguna.

  • consistencia: la transacción debe conducir a la base de datos de un estado consistente a otro estado consistente. Un estado consistente es aquel en el que se cumplen todas las restricciones especificadas en el esquema de la base de datos.

  • aislamiento: una transacción se debe procesar como si se ejcutase de forma aislada (en solitario).

  • persistencia: cuando una transacción es confirmada, sus cambios deben ser grabados sobre la base de datos y no deben perderse debido a fallos de otras transacciones o del sistema.

El SGBD debe velar para que se cumplan estas propiedades. La propiedad de atomicidad es responsabilidad del módulo de recuperación (o reconstrucción). La propiedad de consistencia es responsabilidad de los programas de aplicación o del módulo de comprobación de la integridad del SGBD. La propiedad de aislamiento es responsabilidad del módulo de control de la concurrencia.

La propiedad de persistencia es responsabilidad del módulo de recuperación (o reconstrucción).

Integridad semántica

Una restricción de integridad es una propiedad del mundo real del cual la base de datos es una representación, para que esta representación sea consistente con la realidad, la base de datos debe satisfacer las restricciones en cualquier instante de su historia.

Las restricciones de integridad se definen en el esquema lógico de la base de datos siendo responsabilidad del SGBD velar por su cumplimiento. Si consideramos que la base de datos evoluciona (cambia de estado) al ejecutar una transacción sobre ella, el SGBD debe comprobar las restricciones en el estado posterior a cada transacción, informando al usuario (o al programa) responsable de la misma del resultado de la comprobación.

En algunos sistemas sin embargo, no es posible definir las restricciones de integridad en el esquema de la base de datos siendo responsabilidad de los programadores el introducir en el código de los programas de acceso a la base de datos, los controles necesarios para su comprobación.

Las restricciones que pueden definirse sobre una base de datos se clasifican en función del número de estados de la base de datos que se ven implicados en la propiedad representada por la restricción.

  • restricciones estáticas: expresan propiedades que deben satisfacerse en cada estado de la base de datos.

  • restricciones de transición: expresan propiedades que se deben cumplir en cada par de estados consecutivos.

Ejemplo 3.9

Las siguientes dos propiedades corresponden a una restricción estática y una restricción de transición:

  • “La edad de una persona debe ser un valor entero positivo”

  • “La edad de una persona no debe decrecer”

Restricciones de integridad estáticas en el Modelo Relacional

Una restricción de integridad estática puede ser siempre representada por una fórmula bien formada cerrada de cálculo relacional, sin embargo los sistemas relacionales ofrecen una sintaxis particular para expresar algunos tipos de restricciones. Así en SQL se pueden expresar restricciones de integridad de los siguientes tipos (ver el apartado 2.5.1):

  • restricciones sobre dominios,

  • restricciones sobre atributos,

  • restricciones sobre relaciones, y

  • restricciones sobre la base de datos.

En el SQL la definición de las restricciones es declarativa, es decir en la definición se expresa con una notación (más o menos abreviada) la propiedad en que consiste la restricción, encargándose el SGBD de determinar las operaciones de actualización que pueden ser relevantes para la restricción así como de determinar la forma más eficiente de comprobarla. Para cualquier tipo de restricción se puede indicar al sistema el instante en el cual debe comprobarse la restricción, al finalizar la transacción o después de cada operación individual de la misma. En algunos casos (definición de claves ajenas) la sintaxis del SQL permite expresar también algunas acciones compensatorias que el sistema debe realizar, en el caso en que se viole la restricción, para seguir manteniendo la integridad en la base de datos.

Ejemplo 3.10

En el esquema relacional del Ejemplo 2.35 del tema II, aparecen restricciones de los siguientes tipos:

  • restricciones sobre dominios, por ejemplo en la definición del dominio Créditos:

CREATE DOMAIN Créditos AS NUMBER(1,1) CHECK value>0

  • restricciones sobre atributos, por ejemplo en la definición del atributo nombre de la relación Profesor:

nombre    VARCHAR (50)    NOT NULL

  • restricciones sobre relaciones, por ejemplo las definiciones de clave primaria y clave ajena en la relación Asignatura:

PRIMARY KEY (código),

FOREING KEY (dep) REFERENCES departamento (código)

                ON UPDATE CASCADE

En todos estos casos la comprobación de la restricción se realizará después de cada operación de actualización de la base de datos, ya que no se ha incluido en su definición ninguna opción y la comprobación inmediata es el tipo de comprobación por defecto.

Respecto a las acciones a tomar en caso de violación de la integridad, éstas sólo se pueden indicar en la definición de claves ajenas; en el ejemplo se ha incluido una directriz para la actualización sobre la relación Departamento, y no se ha incluido ninguna directriz frente al borrado en Departamento, por lo que en este último caso el comportamiento del SGBD será restrictivo.

Respecto a restricciones generales sobre la base de datos, en el esquema del ejemplo 2.35 aparece la restricción RI_Docencia para controlar la carga docente de los profesores según su categoría. A continuación se presenta otra restricción de estas características que ha estado implícita en el uso que se ha hecho de la base de datos:

"Las asignaturas adscritas a un departamento sólo pueden ser impartidas por profesores del departamento"

CREATE ASSERTION docencia

    CHECK (NOT EXISTS (SELECT *

                        FROM Asignatura A, Docencia D, Profesor P

                        WHERE A.código=D.cod_asg AND

                              P.código=D.cod_prof AND

                              P.dep<>A.dep)

           )

Procedimientos de comprobación de la integridad

Algunos sistemas de gestión de bases de datos permiten definir procedimientos en los cuales el diseñador puede programar explícitamente la comprobación de alguna restricción de integridad, liberando al sistema de esta función. En estos procedimientos se debe indicar:

  • las operaciones de actualización que deben activar el procedimiento,

  • el código de programa que comprueba la propiedad en que consiste la restricción, y

  • la acción o acciones que se deben tomar en caso de violación de la restricción (rechazo o acciones compensatorias).

Estos procedimientos forman también parte del esquema de la base de datos.

Accesos concurrentes

Como se ha comentado anteriormente, para mantener la integridad de la base de datos el SGBD debe controlar los accesos concurrentes evitando que los resultados de la ejecución de un programa sean incorrectos, incoherentes o se pierdan debido a la ejecución simultánea de otro programa que accede a los mismos datos. Las interferencias que pueden producirse entre programas que actualizan la base de datos son las siguientes:

  1. pérdida de actualizaciones,

  2. obtención de información incoherente correspondiente a varios estados válidos de la base de datos, y

  3. lectura de datos actualizados (no confirmados) que han sido sometidos a cambios que todavía pueden ser anulados.

A continuación se presentan ejemplos de cada uno de los tres tipos de interferencias.

Ejemplo 3.11.

En un registro hay dos campos, A y B, cuyos valores en un momento dado son a0 y b0. El programa P1 lee el registro y a continuación lo lee también el programa P2, luego P1 sustituye a0 por otro valor a1 y graba el registro con los valores a1 y b0; un poco después P2 cambia b0 por b1 en el registro que había leído grabándolo con los valores a0 y b1. La actualización de P1 se ha perdido. (Pérdida de actualizaciones)

Ejemplo 3.12.

Se está ejecutando un programa que lista los saldos de cien cuentas bancarias y que calcula el total; mientras se está en la cuenta no 50 se transfiere dinero de la no 100 a la no 1. El saldo total calculado será incorrecto. (Información incoherente obtenida a partir de dos estados válidos)

Ejemplo 3.13.

Se está ejecutando un programa P1 que cambia el valor del campo A de un registro. Un programa P2 lee el nuevo valor de A antes de que P1 finalice. Finalmente el programa P1 es abortado deshaciéndose todas sus actualizaciones. El programa P2 ha leído datos no confirmados. (Uso de datos actualizados cuyos cambios no han sido confirmados)

Entre las técnicas utilizada más frecuentemente para evitar los problemas derivados de los accesos concurrentes están las técnicas basadas en la reserva de ocurrencias de datos. Estas técnicas limitan la simultaneidad de los accesos concurrentes. Así, en el caso de los ejemplos Ejemplo 3.11 y Ejemplo 3.13 el programa P1 debería reservar el registro desde que lo lee hasta después de confirmar la actualización; en el Ejemplo 3.12, se deberían reservar todas las cuentas. Los programas deben solicitar las reservas a un módulo del SGBD que se encarga de llevar el control de las mismas. Lo contrario de la reserva es la liberación que cancela una reserva efectuada.

Reconstrucción de la base de datos

Las propiedades de atomicidad y persistencia de una transacción obligan al SGBD a asegurar que:

  1. los cambios producidos por cualquier transacción confirmada sean grabados sobre la base de datos y una vez grabados no se pierdan, y que

  2. los cambios producidos por cualquier transacción fallada que ya han sido grabados sobre la base de datos sean deshechos.

Las causas por las que una transacción confirmada no es grabada completamente sobre la base de datos tienen su origen en el desajuste temporal que existe entre el instante en que se confirma la transacción y el instante en que se copian los bloques con los datos actualizados del buffer (o buffers) al disco. En el intervalo que transcurre entre ambos instantes de tiempo pueden producirse diversos fallos del sistema que provoquen la pérdida de memoria principal y que causen que algunos de esos bloques no lleguen a ser copiados nunca.

Las causas por las que una transacción confirmada, cuyos cambios ya habían sido grabados sobre la base de datos, se pierde son debidas a la ocurrencia de fallos que provoquen la pérdida de memoria secundaria .

Las causas por las que una transacción falla pueden ser locales a la transacción y producidas durante el funcionamiento normal del sistema: errores de la transacción (operaciones de acceso a la base de datos que no son válidas, cálculos aritméticos incorrectos, etc.); excepciones (violación de la integridad), control de la concurrencia (estado de bloqueo (deadlock) entre dos transacciones), decisiones humanas (por programa o explícitas), etc.; o bien pueden ser externas a la transacción:

errores del sistema (de hardware o de software) que interrumpen su ejecución. Cuando una transacción falla puede suceder que algunos de sus cambios (o todos) hayan sido ya grabados sobre la base de datos.

Resumiendo, entre las causas externas a la transacción que pueden provocar la pérdida de la integridad de la base de datos, se distinguen:

  • los fallos del sistema que provocan la pérdida de memoria principal: interrupción del suministro eléctrico, error del software del SGBD, error del sistema operativo, etc., y

  • los fallos del sistema de almacenamiento que provocan la pérdida de memoria secundaria: aterrizaje de las cabezas de lectura de los discos, fallos del controlador de discos, accidentes o catástrofes, etc.

A continuación se van a presentar de forma simplificada las técnicas utilizadas por el SGBD para reconstruir la base de datos frente a fallos de ambos tipos (al final del apartado se comentarán las simplificaciones asumidas).

Reconstrucción frente a fallos del sistema

Para poder recuperar transacciones confirmadas que no han sido grabadas completamente o anular transacciones falladas, el SGBD debe disponer de herramientas que registren las transacciones que tienen lugar sobre la base de datos, asimismo debe disponer de técnicas que, con esa información, devuelvan la base de datos a un estado íntegro en el que se puede asegurar la calidad de la información almacenada. El módulo encargado de realizar estas tareas es el módulo de reconstrucción. A continuación se presentan estas herramientas y técnicas.

El método más extendido es el de la utilización de un fichero denominado diario (log o journal).

En el diario se registra información sobre todas las operaciones de actualización de las transacciones. El diario se almacena en disco para evitar su desaparición por una caída del sistema y periódicamente se copia en cinta magnética para prevenir posible accidentes que deterioren el disco.

El tipo de entradas (registros) que el sistema necesita grabar en el diario sobre las transacciones son las siguientes:

  • [inicio, T]: indica que se ha iniciado la ejecución de la transacción de identificador T (este identificador es asignado por el sistema).

  • [escribir, T, X, valor_antes, valor_después]: indica que la transacción T ha realizado una operación de actualización sobre el dato X, siendo el valor de este dato antes de la operación valor_antes, y su valor después de la operación valor_después.

  • [leer, T, X]: indica que la transacción T ha leído el dato X.

  • [confirmar, T]: indica que la transacción T ha sido confirmada.

  • [anular, T]: indica que la transacción T ha sido anulada.

Además cada entrada puede llevar información adicional como un puntero al anterior registro del diario que haga referencia a la misma transacción.

Cuando una transacción falla (por causas locales a la transacción o por fallo del sistema) el módulo de reconstrucción puede utilizar la información grabada en el diario para deshacer sus efectos; para ello debe volver a actualizar los datos modificados por la transacción con su valor original (valor_antes). En el caso de fallo del sistema el proceso deberá aplicarse a todas las transacciones no confirmadas en el momento de realizarse la reconstrucción; una transacción T no ha sido confirmada cuando en el diario aparece la entrada [inicio, T] y no aparece la entrada [confirmar, T].

De la misma forma, cuando se produce un error del sistema, el módulo de reconstrucción debe volver a ejecutar las transacciones que en el diario aparecen como confirmadas, ya que no se tiene la seguridad de que sus cambios hayan sido grabados sobre la base de datos; para ello será suficiente volver a realizar las actualizaciones con el nuevo valor del dato (valor_después). Una transacción T se considera confirmada cuando la entrada [confirmar, T] ha sido grabada en el diario; hasta ese momento no se puede tener la seguridad de que todas sus operaciones se han ejecutado y que además han sido grabadas en el diario para asegurar su aplicación sobre la base de datos.

Si el diario recoge información sobre todas las transacciones que han tenido lugar en un periodo de tiempo prolongado (por ejemplo desde que se arrancó el sistema por la mañana) el proceso de recuperación puede ser muy costoso, ya que obliga a volver a ejecutar todas las transacciones confirmadas que estén registradas en el diario, aunque probablemente muchas de ellas ya habrán sido grabadas sobre la base de datos. Para evitar costosos procesos de recuperación se graban en el diario lo que se conoce como puntos de verificación (checkpoint).

Los puntos de verificación (o de recuperación) se graban en el diario periódicamente. Grabar un punto de verificación significa:

  • suspender temporalmente la ejecución de transacciones,

  • grabar en el diario el punto de verificación,

  • forzar la grabación de todas las actualizaciones de las transacciones confirmadas, copiando los correspondiente bloques de los buffers de memoria principal al disco, y

  • reanudar la ejecución de las transacciones que han sido suspendidas.

Con esta técnica el proceso de reconstrucción se inicia a partir del último punto de verificación grabado en el diario.

Figura 3.5: Toma de puntos de verificación.

En la Figura 3.5 se representan cinco transacciones en estados distintos cuando se produce un error del sistema. La transacción T1 había sido confirmada antes del último punto de verificación, por lo tanto se tiene la seguridad de que sus cambios han sido grabados permanentemente sobre la base de datos. La transacción T2 se inició antes del último punto de verificación y se confirmó después de él, antes de producirse el error del sistema, por lo tanto no podemos asegurar que todas sus actualizaciones hayan sido grabadas. La transacción T3 se inició también antes del último punto de verificación y no había finalizado cuando se produjo el error del sistema, por lo tanto deberá ser anulada automáticamente cuando se reinicie el sistema y deberán deshacerse todos sus cambios. La transacción T4 se inició después del último punto de verificación y finalizó antes de producirse el error, por lo tanto no se puede asegurar que sus actualizaciones hayan sido grabadas sobre la base de datos. Por último la transacción T5 se inició después del último punto de verificación y no había finalizado al producirse el error, por lo tanto deberá ser anulada y deshechos sus cambios. La reconstrucción de la base de datos, al volver a iniciarse el sistema, significará por lo tanto: anular las transacciones T3 y T5 y deshacer los cambios que pudiesen haber producido, y recuperar (volver a ejecutar) las transacciones T2 y T4.

Reconstrucción frente a fallos del sistema de almacenamiento

En el caso de que se produzca un fallo del sistema de almacenamiento, con pérdida de memoria secundaria, la base de datos puede quedar dañada total o parcialmente. En estos casos la reconstrucción de la base de datos exige el uso de nuevas herramientas: las copias de seguridad de la base de datos.

La técnica de reconstrucción que se sigue consiste en recrear la base de datos actual a partir de la copia de seguridad más reciente y de la información (histórica) grabada en el diario desde el instante de tiempo en que se realizó dicha copia. Para ello se carga la base de datos a partir de la copia de seguridad y a continuación se rehacen todas las transacciones que aparecen confirmadas en el diario desde la fecha de la copia. Es interesante destacar que en este tipo de reconstrucción no es necesario deshacer las transacciones que aparecen anuladas en el diario, ya que sus cambios han desaparecido al utilizar una copia de seguridad anterior que se supone íntegra.

En toda la exposición que se ha hecho sobre la reconstrucción de la base de datos frente a fallos, se han asumido por simplicidad, las siguientes hipótesis de trabajo:

  • las anotaciones en el diario se hacen directamente sobre el disco.

  • la técnica de recuperación utilizada permite que las actualizaciones de la transacción se graben en la base de datos antes de que la transacción sea confirmada (actualización inmediata).

  • la ejecución concurrente de las transacciones se realiza de forma que cada transacción se puede recuperar independientemente de las otras transacciones.

Obviamente, ninguna de estas hipótesis es necesaria.

Respecto a la grabación de las entradas en el diario, éstas pueden permanecer durante algún tiempo en buffers de memoria principal, evitando de esta forma los accesos frecuentes al disco. En esta situación el sistema de recuperación debe asegurarse de que cualquier cambio sobre la base de datos (física) es registrado previamente en el diario (físico).

Respecto a las técnicas de reconstrucción, éstas pueden estar basadas en la actualización inmediata o en la actualización diferida. Las técnicas con actualización diferida no actualizan la base de datos hasta después de que la transacción haya sido confirmada. En este caso el proceso de recuperación ante un fallo del sistema es distinto; las transacciones que no aparecen confirmadas en el diario no deben ser deshechas ya que se tiene la seguridad de que sus cambios no han sido grabados; respecto a las transacciones que aparecen confirmadas en el diario deberán ser rehechas ya que no se tiene la seguridad de que hayan sido ya grabadas.

Respecto a la recuperación independiente de las transacciones, sólo se puede asegurar cuando el procesamiento concurrente de las transacciones se realiza con ciertas restricciones, como se ilustra en el Ejemplo 3.14.

Ejemplo 3.14

En la siguiente ejecución concurrente de T1 y T2, T2 lee un dato que ha sido actualizado por T1, posteriormente T2 es confirmada antes que T1 falle. La anulación de T1 obliga no sólo a deshacer los cambios que haya podido realizar sobre la base de datos sino a anular también T2 que ya había sido confirmada (anulación en cacada).

Una restricción que se puede imponer al procesamiento concurrente para evitar el problema anterior consiste en no permitir que una transacción lea ni actualice un dato que ha sido actualizado por otra transacción hasta que esta última sea confirmada o anulada (procesamiento estricto).

SEGURIDAD

Este objetivo de los SGBD consiste en asegurar que a la información almacenada sólo pueden acceder las personas autorizadas y en la forma autorizada. A continuación se presentan algunas técnicas utilizadas para cubrir este objetivo.

Identificación de usuario

Consiste en determinar quién es la persona que está solicitando acceder a la base de datos como paso previo a la determinación de qué tipos de accesos tiene permitidos. La identificación se realiza normalmente por medio de una clave de acceso.

Determinación de accesos permitidos

Básicamente, existen dos formas de establecer los accesos permitidos para cada usuario de la base de datos:

  • Cada usuario tiene asociada una lista de autorizaciones que denotan los datos accesibles y las operaciones permitidas sobre cada uno de ellos.

  • Definición de distintos niveles de autorización, lo que significa que todos los usuarios con el mismo nivel pueden realizar las mismas operaciones sobre los mismos objetos.

Claramente, la primera forma es más flexible y permite una mejor especificación de las autorizaciones.

Gestión de autorizaciones transferibles

Un sistema de gestión de autorizaciones de acceso debe satisfacer los siguientes requerimientos:

  • Conocimiento de las autorizaciones de accesos de cada usuario; de éstos unas pueden ser transferibles (a terceros) y otras no.

  • Revocación posterior de una autorización de acceso.

  • La revocación de una autorización de acceso transferible implica la revocación automática de todas las autorizaciones que son resultado de una transferencia de la misma.

  • Si un usuario puede recibir de otros más de una autorización por el mismo acceso, cada una de estas autorizaciones puede ser revocada independientemente de las demás.

Comments