Organización de un SGBD relacional

BLOQUE 5: ORGANIZACIÓN DE UNA SISTEMA GESTOR DE
BASES DE DATOS RELACIONALES
5.1.- INTRODUCCIÓN
Normalmente los usuarios de Sistemas Informáticos están rodeados de grandes
volúmenes de datos, que no resultan muy útiles cuando no están bien documentados y no tienen
asociada una semántica precisa que indique el significado y utilidad de cada uno de ellos. De
aquí surge la necesidad de disponer de un diccionario de recursos de información (DRI) que
contenga las descripciones de todos los datos que constituyen el sistema informático y ayuden a
la gestión de la información.
Esto se consigue almacenando, administrando y controlando lo que se denominan
metadatos, es decir los datos que definen y describen los datos que maneja el sistema. En
principio se crearon dos almacenes distintos para contener esta información:
 Diccionario de datos: que contenía la información sobre los datos almacenados en la
base de datos, sus definiciones, significado, estructura, etc., que era mantenido por el
propio usuario.
 Directorio de datos: contenía donde y como estaban almacenados los datos en la base de
datos y era mantenido por el Sistema Gestor de Base de Datos.
En las bases de datos relacionales aparece el concepto de catálogo del Sistema Gestor de
Base de Datos, que une ambas cosas, el diccionario de datos y el directorio de datos y además lo
gestiona el propio SGBD y es una base de datos más dentro de la propia base de datos, por esta
razón también recibe el nombre de metabase.
El catálogo del sistema gestor de una base de datos relacional supone grandes ventajas para
el usuario y sobre todo para el administrador de la base de datos ya que esta mantenido de forma
automática por el SGBD y además se puede acceder a él como a cualquier otra base de datos
mediante el lenguaje SQL.
Según palabras de Codd (1990), el requisito para que un SGBD pueda considerarse relacional es
que “soporte un catálogo dinámico en línea en el que la descripción de la base de datos se
represente como cualquier otro dato, permitiendo a los usuarios autorizados aplicar el mismo
lenguaje relacional tanto a la descripción como a los datos regulares”.
Pág. 1
5.2.- CATÁLAGO DE LA BASE DE DATOS
El catálogo de una base de datos está formado por un conjunto de tablas donde se recoge
toda la información sobre las tablas, columnas, índices, permisos, etc., que tiene una determinada
base de datos.
El mantenimiento de las tablas del catálogo lo realiza automáticamente el Sistema Gestor
de la Base de Datos, las tablas se almacenan en el directorio de la base de datos . Ejemplos de
este catálogo pueden ser:
. systables: tablas que componen la base de datos.
. syscolumns: columnas que forman cada una de las tablas de la base de datos.
. sysindexes: índices de cada tabla
. systabauth: permisos de acceso a las tablas.
. syscolauth: permisos de acceso a las columnas.
. sysusers: permisos de acceso a la base de datos.
. sysviews: composición de views.
. sysdepend: estructura de las views.
. syssynonyms: sinónimos de las tablas.
. sysforeing: claves referenciales de cada tabla.
. syscolattr: atributos CTSQL de cada columna.
. syscollating: secuencia de ordenación.
Pág. 2
5.3.- ESTRUCTURA DEL SISTEMA GESTOR DE BASES DE DATOS
Un sistema de base de datos está formado por diferentes módulos y cada uno se encarga
de realizar funciones concretas, aunque generalmente algunas de esas funciones las puede
realizar el sistema operativo.
Administrador
Programadores
Usuarios
USUARIOS
PROCESADOR DE CONSULTAS
Sistema Gestor
de la Base de
Datos
GESTOR DE ALMACENAMIENTO
Indices
Datos estadísticos
Almacenamiento
en disco
Diccionario de datos
Archivos de datos
Las funciones que desarrolla el sistema gestor de la base de datos (aunque no siempre) se
pueden incluir en dos módulos:
Procesador de consultas: para ello dispone de los siguientes módulos:
a) Compilador del lenguaje de manejo de datos (DML): que traduce las instrucciones SQL a
instrucciones de bajo nivel y transforma las solicitudes del usuario en otras mas
eficientes, las optimiza.
b) Precompilador de lenguaje de manejo de datos (DML): que convierte las instrucciones
SQL embebidas en otro lenguaje de programación en instrucciones que entiende el
procesador de consultas.
Pág. 3
c) Interprete del lenguaje de definición de datos(DDL): que interpreta las instrucciones
DDL y realiza las anotaciones correspondientes en el catálogo de la base de datos.
d) Motor de evaluación de consultas: ejecuta las instrucciones de bajo nivel generadas por el
compilador del DML.
Gestión del almacenamiento: es el interfaz entre los datos almacenados en el disco y las
instruciones de bajo nivel obtenidas por el procesador de consultas, está compuesto por los
siguientes módulos:
a) Gestor de autorización e integridad: comprueba que se satisfagan las reglas de integridad
impuestas y las debidas autorizaciones de los usuarios para acceder a los datos.
b) Gestor de transacciones: se asegura de que la base de datos tenga un estado consistente
aunque existan fallos del sistema y de que la ejecución de transacciones consistentes
ocurran sin conflictos.
c) Gestor de archivos: gestiona la reserva de espacio de almacenamiento en disco y las
estructuras de datos usadas para representar la información.
d) Gestor de memoria interna: es el responsable de traer los datos del disco a memoria
principal.
Pág. 4
5.4.- ACCESO AL ALMACENAMIENTO
Las bases de datos contienen varios archivos diferentes que son mantenidos por el
sistema operativo subyacente, cada archivo se divide en unidades de almacenamiento de longitud
constante llamadas bloques que son las unidades de asignación de almacenamiento y de
transferencia de datos. Cada bloque puede contener varios elementos de datos dependiendo de la
organización física de los datos que se utilice.
Uno de los principales objetivos de las bases de datos es minimizar el número de accesos
al disco para ello mantiene en memoria principal todos los bloques posibles, de forma que
cuando se necesite un determinado dato, el bloque que lo contienen ya esté en memoria y no sea
necesario realizar un acceso a disco. El espacio donde se almacenan los bloques es la memoria
intermedia (buffer) y el subsistema responsable de la asignación del espacio de memoria
intermedia se denomina gestor de la memoria intermedia.
El sistema de trabajo es el siguiente: los programas de bases de datos realizan solicitudes
al gestor de memoria intermedia cuando necesitan un bloque, si ese bloque está en memoria
intermedia el gestor pasa al solicitante su dirección en memoria principal. Si el bloque no está en
memoria intermedia, el gestor primero asigna espacio en memoria intermedia para el bloque, si
hiciera falta espacio, descarta alguno de los bloques, escribiendolo en el disco si ha habido
alguna modificación y despues accede al disco para leer y bloque solicitado y lo escribe en
memoria intermedia pasando la dirección correspondiente al solicitante.
Los sistemas que se utilizan para la sustitución de bloques en memoria intermedia pueden
ser diferentes. En los programas que no utilizan una base de datos es imposible predecir con
precisión cuales serán los bloques a los que se va a hacer referencia por tanto los sistemas
operativos normalmente utilizan el sistema LRU (Least Recently Used, menos utilizado
recientemente) para sustuir los bloques en memoria intermedia. En las aplicaciones que utilizan
bases de datos, se dispone de información para conocer al menos a corto plazo cual será la
información necesaria (optimizador), además existen bloques como los correspondientes al
catálogo de la base de datos, que se utilizan constantemente, o los índices de los archivos que se
utilizan con más frecuencia que los propios archivos de la base de datos, por tanto debe evitar
quitarlos de la memoria intermedia. Hay otra serie de factores que debe tener en cuenta como
conservar la consistencia de la base de datos si existe concurrencia de varios usuarios etc. Por
todo lo expuesto un sistema de base de datos debe utilizar sistemas diferentes al LRU para
realizar la sustitución de bloques en la memoria intermedia y no siempre es suficiente la gestión
realizada por el sistema operativo.
Pág. 5
5.5.- ORGANIZACIÓN DE LOS ARCHIVOS.
AGRUPACIONES (CLUSTERS)
En los sistemas de bases de datos se organiza la información en diferentes archivos
formado cada uno de ellos por registros que contienen información sobre la misma entidad de
negocio, por tanto es equivalente a cualquier otro sistema de ficheros. Todo sistema operativo
dispone de un sistema de gestión de archivos que será donde se apoye la base de datos para
gestionar sus tablas.
La información sobre el contenido de cada archivo se encuentra en la cabecera de archivo
(FAT) y la información sobre los archivos que contiene el disco en el directorio del disco y
normalmente es el sistema de gestión de archivos del sistema operativo quien mantiene el
almacenamiento físico de los datos, esta forma de implementar las bases de datos relacionales
deja de ser eficiente a medida que aumenta el tamaño de la base de datos.
Sistemas de bases de datos de gran tamaño no utilizan directamente el sistema operativo
para la gestión de archivos, sino que se asigna a la base de datos un archivo de gran tamaño del
sistema operativo donde se guardan todas las relaciones y la gestión de este archivo corresponde
al sistema gestor de base de datos.
Supongamos la siguiente consulta:
SELECT num_cuenta, nombre,calle,ciudad
FROM impositor,cliente
WHERE impositor.nombre=cliente.nombre
si tenemos dos archivos diferentes:
impositor
Nombre
López
López
López
Abril
Num_cuenta
C-102
C-220
C-503
C-305
cliente
Nombre
López
Abril
Calle
Principal
Del Pez
Ciudad
Almazán
Burgo
En el peor de los casos si cada registro se encuentra en un bloque diferente tendremos que
realizar tantos accesos a disco como registros necesitamos.
Si realizamos el almacenamiento de la siguiente manera:
López
López
López
López
Abril
Abril
Principal
C-102
C-220
C-503
Del Pez
C-305
Almazán
Burgo
Pág. 6
Esta estructura mezcla las tuplas de dos relaciones pero permite un procesamiento mas
eficaz ya que cuando se lee una tupla correspondiente a la relación cliente pasa todo el bloque a
memoria intermedia y por tanto pasan también las tuplas de la relación impositor que se
relacionan con dicho cliente, si un cliente tiene tantas cuentas que no caben en el mismo bloque,
estarán en otro bloque y como mucho se realizarán dos lecturas para procesar los datos
correspondientes a dicho cliente.
Para poder realizar consultas sobre la misma relación, se añade un sistema de punteros
que recorre los registros que pertenecen a la misma relación.
Esta forma de almacenar la información se denomina en agrupaciones o clusters y la
agrupación que se debe realizar depende de los tipos de consulta que se vayan a obtener en la
aplicación y su frecuencia por tanto se determinan en la fase de diseño de la base de datos
cuando se ha estudiado la carga que va tener.
Un buen SGBD debe permitir al administrador que especifique agrupamientos diferentes
para distintos archivos o modificar un determinado agrupamiento si cambian las requerimientos
de la aplicación, pero en ningún momento un cambio en el agrupamiento debe suponer
modificaciones en las aplicaciones que utilizan dichos datos ya que debe existir total
independencia entre los datos y los programas.
Pág. 7
5.6.- EL OPTIMIZADOR DE SQL
El optimizador de ‘queries’ decide la estrategia de búsqueda sobre las tablas que
intervienen en las sentencias teniendo en cuenta los siguientes factores:
Índices existentes.
Uso del ROWID
Número de filas en la tabla
Enlaces
Orden de las condiciones en la cláusula WHERE.
Orden de las tablas en la cláusula FROM de la instrucción SELECT.
Para tomar una decisión realiza los siguientes pasos:
 Paso 1.- analiza las condiciones incluidas en la cláusula WHERE y las agrupa por tabla,
evaluando los rangos de valores en cada tabla.
 Paso 2.- teniendo en cuenta los rangos encontrados en cada tabla selecciona la mejor
estrategia de búsqueda: por índice, por ROWID o secuencial. Para ello comprueba si las
columnas implicadas forman parte de algún índice, si incluye condiciones por ROWID o
en el peor de los casos si debe realizar un acceso secuencial a toda la tabla.
 Paso 3.- selección de la secuencia de acceso a las diferentes tablas que intervienen,
decidiendo cual será la primera tabla a la que tiene que acceder que en principio será la
que devuelva un menor número de filas con el menor número de lecturas en el disco. Esto
decisión la toma teniendo en cuenta los datos obtenidos en el paso 2. Una vez
seleccionada la primera tabla vuelve al paso 2 para ver los enlaces de la tabla relacionada
con el resto. Este proceso continúa hasta terminar con todas las tablas que intervienen en
la sentencia.
El optimizador solamente decide en el caso de que una estrategia sea mejor que el resto,
sino no hay ningún motivo para decantarse por una forma de acceder u otra elige la primera
estrategia encontrada. La persona que realiza los programas puede forzar al SQL a utilizar una
estrategia determinada en función de cómo escriba sus sentencias.
Para tomar la decisión de qué índice es el más adecuado intervienen los siguientes
elementos:
1.- Número de partes del índice referenciadas en la WHERE mediante condiciones =, >=,
>, LIKE, IN, BETWEEN.
2.- Si un índice es compuesto solamente se tendrá en cuenta la referencia a una de sus
partes si se referencian todas las componentes del índice anteriores a esa parte en otras
condiciones de la WHERE.
3.- Un índice referenciado en todas sus partes por las condiciones indicadas es mejor que
un índice del que no se referencian todas sus componentes.
Pág. 8
4.- Un índice referenciado en todas sus partes por condiciones de igualdad es mejor que
otro referenciado en todas sus partes por cualquier otra condición.
5.- Un índice referenciado en todas sus partes por condiciones de igualdad es mejor que
otro en su mismo caso si el primero es único y el segundo no.
6.- Si hasta aquí llegamos en condiciones de igualdad de los dos índices, el optimizador
seleccionará en primer lugar el primero al que se hace referencia en la cláusula WHERE
y si esta columna pertenece a los dos índices se elige el que sea clave primaria (si lo es),
sino el que se haya creado antes.
7.- Una condición es optimizable si es única o está unida a otras condiciones por la
cláusula AND.
SELECT * FROM clientes WHERE num_cliente>20 OR num_provincia>10
no es optimizable y se hará un acceso secuencial a la tabla.
SELECT * FROM clientes WHERE num_cliente>20 AND num_provincia>10
Si es optimizable y se accederá por num_cliente si hay un índice para dicha columna o
bien hay un índice compuesto en el que la primera columna es num_cliente, si hubiera
índices para num_cliente y num_provincia, se accederá por num_cliente por ser el que se
ha referenciado primero. Por tanto el programador puede forzar los accesos por
num_provincia si escribe la sentencia de la siguiente manera:
SELECT * FROM clientes WHERE num_provincia>10 AND num_cliente>20.
8.- Una condición optimizable por ROWID es siempre mejor que un acceso por índice,
en el caso: SELECT * FROM clientes WHERE num_cliente>15 AND rowid in
(13,23,1,45), accederá directamente a las filas indicadas por el ROWID.
9.- Una claúsula ORDER BY supone realizar una ordenación del resultado de una
SELECT salvo si la ordenación se puede optimizar, esto ocurre cuando se dan todas las
condiciones siguientes:
 La SELECT se realiza sobre una sola tabla.
 No se ha podido determinar ningún índice de acceso a la tabla o bien el
índice de acceso coincide con el de ordenación.
Para determinar la secuencia de accesos a las tablas se tienen en cuenta las siguientes
condiciones:
 siempre es mejor acceder primero a la tabla cuyas filas válidas sea menor, ya que en
principio el número de accesos a disco es menor. Para conocer el número de filas
devuelve cada tabla utiliza siempre las condiciones más restrictivas, siempre es mejor una
tabla a la que se puede acceder mediante un índice o por ROWID que otra que no pueda
serlo.
 Si existen dos tablas a las que no se puede acceder por índice se elige la que tenga menos
filas. El número de filas se obtiene de la columna nrow de la tabla systables, por lo que es
conveniente tener actualizada esta columna.
 Si a dos tablas no se va a acceder por índices y tienen el mismo número de filas se elige
el orden de acceso definido en la cláusula FROM.
Pág. 9