Gestión de Registros y Control de Concurrencia en Bases de Datos Relacionales

Organización de Registros en Agrupaciones de Tablas

Muchos Sistemas Gestores de Bases de Datos (SGBD) relacionales guardan cada relación en un archivo diferente, aprovechando completamente el sistema de archivos del Sistema Operativo (SO). Este enfoque es adecuado para bases de datos pequeñas, ya que una estructura de archivos sencilla reduce la cantidad de código necesaria para implementar el sistema.

Sin embargo, este método resulta menos satisfactorio a medida que aumenta el tamaño de la base de datos. En estos casos, una estructura de archivos más compleja puede ser más beneficiosa, incluso si se mantiene la estrategia de guardar cada relación en un archivo diferente. Muchos sistemas de BD de gran tamaño no utilizan directamente el SO subyacente para la gestión de archivos. Por el contrario, se asigna al sistema de BD un archivo de gran tamaño del SO, y en este archivo se guardan todas las relaciones.

Almacenamiento con Diccionario de Datos

Un SGBD relacional necesita almacenar metadatos sobre las relaciones, como su esquema. Esta información se denomina diccionario de datos o catálogo del sistema. Entre los datos que contiene se encuentran:

• Los nombres de las relaciones.
• Los nombres de los atributos de cada relación.
• Los dominios y las longitudes de los atributos.
• Los nombres de las vistas definidas en la BD y las definiciones de esas vistas.
• Las restricciones de integridad.

Además, muchos sistemas guardan datos de usuarios, estadísticas e índices, tales como:

• Los nombres de los usuarios autorizados.
• La información de las cuentas de usuarios.
• Contraseñas u otra información usada para autenticar a los usuarios.
• El número de tuplas de cada relación.
• El método de almacenamiento para cada relación (ej. con o sin agrupación).
• El nombre del índice.
• El nombre de la relación para la que se crea el índice.
• Los atributos sobre los que se define el índice.
• El tipo de índice formado.

Recuperabilidad y Control de Concurrencia en Transacciones

La recuperabilidad considera los fallos en una transacción durante una ejecución concurrente. Si una transacción T_i falla, es necesario deshacer su efecto para asegurar la propiedad de atomicidad. En un sistema que permite la concurrencia, también es crucial asegurar que cualquier transacción T_j que dependa de T_i sea abortada. Para garantizar esto, es necesario imponer restricciones al tipo de planificaciones permitidas en el sistema.

Planificaciones Recuperables

Una planificación es recuperable si, para todo par de transacciones T_i y T_j tales que T_j lee elementos de datos que T_i ha escrito previamente, la operación de confirmación (commit) de T_i aparece antes que la de T_j.

Planificaciones Sin Cascada

Una planificación es sin cascada si, para todo par de transacciones T_i y T_j tales que T_j lee un elemento de datos que T_i ha escrito previamente, la operación de confirmación (commit) de T_i aparece antes que la operación de lectura de T_j. Toda planificación sin cascada es también recuperable.

Es importante evitar los retrocesos en cascada, que ocurren cuando un fallo en una única transacción provoca una serie de retrocesos de transacciones dependientes. Estos retrocesos:

• Provocan un aumento significativo del trabajo necesario para deshacer cálculos.
• Hacen deseable restringir las planificaciones a aquellas en las que no puedan ocurrir retrocesos en cascada.

Implementación del Aislamiento

Las planificaciones que son serializables por conflictos o por vistas y sin cascada dejan la base de datos en un estado consistente. Existen varios esquemas de control de concurrencia que se pueden utilizar para asegurar que, incluso si se ejecutan concurrentemente muchas transacciones, solo se generen planificaciones aceptables, sin tener en cuenta la forma en que el sistema operativo comparte los recursos en el tiempo.

Un enfoque simple es que una transacción realice un bloqueo en la base de datos completa antes de comenzar y lo libere después de haberse confirmado. Sin embargo, esto solo permite ejecutar una transacción a la vez (generando planificaciones secuenciales), lo que produce un rendimiento pobre. El objetivo de los esquemas de control de concurrencia es proporcionar un elevado grado de concurrencia, al mismo tiempo que aseguran que todas las planificaciones generadas son serializables por conflictos o por vistas y son sin cascada.