Caracterización de un SGBD Relacional
Para que un Sistema de Gestión de Bases de Datos (SGBD) pueda considerarse relacional, debe poseer las dos características siguientes:
- El usuario debe percibir las bases de datos como tablas, y nada más que como tablas.
- El SGBD debe manejar las operaciones de restricción, proyección y reunión natural, sin requerir definiciones previas de rutas de acceso físico.
Un SGBD que disponga de las tres operaciones anteriores, pero que necesite de la definición previa por el usuario de rutas de acceso físico para manejarlas, no puede considerarse como relacional, ya que ello significaría atentar contra uno de los principios del modelo relacional: la independencia entre la estructura lógica de los datos y su almacenamiento interno. Así, por ejemplo, no puede considerarse relacional un sistema que implementa la operación de restricción de forma que en la condición solo puedan intervenir columnas sobre las que existe definido un índice.
La existencia de índices, o cualquier otro mecanismo de rutas de acceso físico a los datos, mejora el rendimiento del sistema cuando procesa operaciones de manipulación de la base de datos. Aunque el uso de estos mecanismos no puede imponerse a los usuarios, el propio SGBD relacional los utiliza. Ante cualquier operación planteada por el usuario, la parte del sistema conocida como el optimizador se encargará de establecer las rutas más eficientes de acceso a los datos.
Un SGBD que sólo cumpla los dos criterios anteriores es un sistema mínimamente relacional. Si, además, maneja todas las operaciones del álgebra relacional, se puede decir que es relacionalmente completo. Y si, también, posee otras características del modelo relacional, incluyendo los dominios y las dos reglas de integridad, se denomina totalmente relacional.
El SGBD Oracle (Oracle Server)
Un SGBD Oracle consta de una base de datos Oracle y una instancia Oracle.
- Una base de datos Oracle es un conjunto de información tratado como una unidad.
- Una instancia Oracle está formada por un conjunto de procesos y estructuras de memoria compartidas que permiten definir, almacenar y manipular la base de datos, así como controlar el acceso, concurrencia y uso de la información.
Arquitectura de la Base de Datos
Una base de datos Oracle tiene una estructura física y una estructura lógica. La estructura física está constituida por los ficheros del sistema operativo que dan soporte a los datos. Los tablespaces y los objetos de esquema son los elementos que configuran la estructura lógica. Cuando Oracle habla de “estructura lógica”, está incluyendo en el término elementos que corresponden a los niveles externo y conceptual de la arquitectura ANSI. Los SGBD se apoyan, para gestionar el acceso a los datos, en el sistema operativo sobre el que se ejecutan.
La estructura física es gestionada a través de las rutinas del sistema operativo y la estructura lógica es gestionada directamente por el software de Oracle. El SGBD de Oracle soporta el lenguaje SQL, tanto autocontenido como huésped.
Estructura Física de la Base de Datos
La estructura física de una base de datos ORACLE está compuesta por tres tipos de ficheros: ficheros de datos, ficheros redo log y ficheros de control. Una base de datos Oracle está asociada a uno o más ficheros de datos, que contendrán todos los datos de la base. Los datos de las estructuras lógicas, como tablas e índices, se almacenan físicamente en ficheros reservados para la base de datos.
Ficheros de Datos
Los ficheros de datos tienen las siguientes características:
- Un fichero sólo puede estar asociado a una base de datos.
- El fichero, aunque en el momento de su creación para asociarlo a la base de datos tiene un tamaño fijo, puede definirse con características de “auto-extend” para hacer que incremente su tamaño en una cierta cantidad cuando se agote el espacio de almacenamiento de la base de datos.
- Uno o más ficheros de una base de datos forman una unidad lógica de almacenamiento denominada tablespace.
Durante el funcionamiento normal de la base de datos, la información contenida en un fichero de datos se lee, cuando se necesita, y se almacena en la memoria caché del servidor Oracle. La información nueva, o la modificada, no se graba necesariamente de inmediato en un fichero de datos.
Ficheros Redo Log
Un fichero en el que el SGBD graba la información necesaria para la recuperación de la base de datos después de un fallo en el sistema o en los dispositivos de almacenamiento. Su tamaño se determina en el momento de su creación y después no es modificable. Una base de datos tiene dos o más ficheros de este tipo, siendo utilizados de forma cíclica, es decir, el SGBD empieza a grabar en uno de ellos y cuando lo llena pasa al siguiente.
- NOARCHIVELOG: Modo por defecto al que una base de datos Oracle puede funcionar.
- ARCHIVELOG: Cuando trabaja en el segundo modo, un proceso del SGBD se encarga de salvar el contenido de los ficheros de redo log que se han llenado en otro soporte.
Fichero de Control
Cada base de datos Oracle tiene uno. En este fichero se registra la estructura física de la BD, y contiene, entre otros, los siguientes datos:
- Nombre de la base de datos.
- Fecha y hora de creación de la base de datos.
- Nombres y localizaciones de los ficheros de datos y de redo log.
- Información sobre puntos de verificación.
Debe estar disponible en todo momento durante el funcionamiento del SGBD, dado que en él se va a grabar información cada vez que se produzca un checkpoint o se modifique la estructura física de la base de datos.
Tablespaces
En una base de datos Oracle, el espacio de almacenamiento físico, constituido por los ficheros de datos, está estructurado en una o varias unidades lógicas denominadas tablespaces. El SGBD gestiona estas unidades lógicas asignando espacio en ellas a los objetos de esquema como tablas, índices, etc., para almacenar sus datos. Toda base de datos Oracle dispone al menos de un tablespace de nombre SYSTEM en el que están las tablas que soportan el catálogo. Un tablespace puede estar online u offline. Normalmente todos los tablespaces están online.
Los tablespaces facilitan las tareas de administración de la base de datos. Así, por ejemplo, los tablespaces permiten al administrador:
- Controlar la asignación de espacio en disco a los distintos objetos de la base, decidiendo en qué tablespace se almacenarán los datos de cada objeto y estableciendo un límite de ocupación de espacio para cada objeto.
- Controlar el uso del espacio de almacenamiento por parte de los usuarios asignándoles límites específicos en cada tablespace.
- Controlar la disponibilidad de los datos poniendo determinados tablespaces online u offline.
- Realizar operaciones parciales de backup o restore de la base de datos.
Para el SGBD, un tablespace es un conjunto de bloques de datos o páginas en los que va almacenando los datos de los distintos objetos.
Bloque
Se corresponde con un número determinado de bytes en disco comprendido entre 2KB y 32KB.
Extent
Es un número determinado de bloques contiguos que se asignan en una sola operación a un objeto. El tamaño del extent varía tanto de un objeto a otro como de una asignación a otra en el mismo objeto. Este tamaño viene controlado por los parámetros INITIAL, NEXT y PCTINCREASE.
- INITIAL y NEXT: Marcan, respectivamente, los tamaños del primer y segundo extent asignados a un objeto.
Segmento
El conjunto de extents asignados a un objeto. Existen cuatro tipos de segmentos: de datos, de índice, temporales y de rollback. Los segmentos de datos y los segmentos de índice se utilizan, respectivamente, para almacenar los datos de las tablas e índices de la base.
- MINEXTENS: El número de extents iniciales de un segmento.
Cluster
Es una estructura que permite almacenar juntas una o más tablas.
Rollback
La acción de deshacer todas las operaciones ya ejecutadas de una transacción.
Database Writer (DBWR)
Escribe en los ficheros de datos los bloques modificados del buffer caché de la base de datos.
Log Writer (LGWR)
Graba la información de redo log contenida en el buffer de redo log en el fichero de redo log activo.
Checkpoint (CKPT)
Genera, en instantes determinados, un punto de verificación (checkpoint) haciendo que el DBWR grabe en los ficheros de datos todos los bloques modificados y no grabados, si no existe su labor la hace el LGWR.
Archiver (ARCH)
Se ocupa de copiar los ficheros de redo log en un dispositivo de archivo. La copia se produce cuando un fichero se ha llenado y deja de estar activo. Este proceso sólo existe en aquellas bases de datos funcionando en modo ARCHIVELOG.