El concepto de Sistema Gestor de Bases de Datos (SGBD) puede definirse de la siguiente forma:

 Sistema Gestor de Bases de Datos (SGBD). Un software que proporciona servicos para la creación, el almacenamiento, el procesamiento y la consulta de la información almacenada en base de datos de forma segura y eficiente.  Un SGBD actúa como un intermediario entre las aplicaciones y los datos.

 Es decir, vamos a considerar aquí un SGDB como un software que proporciona funcionalidad añadida al sistema de ficheros para facilitar la gestión de datos.

Los SGBD pueden residir (y normalmente así lo hacen para mejorar el rendimiento) en una máquina diferente a la que ejecuta las aplicaciones. De hecho, las aplicaciones modernas se programan de forma que se puede utilizar esta característica de distribución física, aunque a la hora de instalar la aplicación no se utilice y se ubique todo el software en la misma máquina. Esto ha dado lugar a diferentes configuraciones de la arquitectura de las aplicaciones, todas ellas conocidas como arquitecturas multi-capa. La Figura 1 muestra arquitecturas típicas de dos, tres y cuatro capas, con ejemplos concretos de protocolos y piezas software, suponiendo que se utiliza Java como plataforma de desarrollo.

Figura 1

La división en capas generalmente se estrucuta en tes partes: presentación, lógica y datos. En las arquitecturas de dos capas (2C), la capa de presentación tiene la interfaz de usuario y todo el código para el procesamiento de los datos. La parte que se separa es la gestión de los datos que proporciona un SGBD. La interfaz entre las dos capas suele hacerse a través de una interfaz de programación de aplicaciones, por ejemplo, JDBC1 en el caso de Java. Para ello, en el lado de la aplicación se cuenta con un manejador (driver) que se encarga de gestionar las comunicaciones. Estas normalmente se hacen vía TCP/IP, de acuerdo al protocolo propio de cada SGBD. En las aplicaciones de tres capas (3C) aparece una capa intermedia que suele denominarse de “lógica” o “lógica del negocio”. La idea es que en esa capa estén las aplicaciones, y éstas se puedan acceder mediante algún cliente ligero. El ejemplo típico de uno de estos clientes son los navegadores Web. Así, el navegador es la interfaz (la presentación), y en el servidor Web está el código de acceso a la base de datos (lógicamente, entre el cliente y el servidor se utiliza HTTP como protocolo). De este modo se evita que en la máquina del usuario sea necesario instalar nada más que el navegador. En Java, estas aplicaciones 2C utilizan tecnología de servidor Web como JSP. Un elemento adicional de separación puede darse en la capa intermedia, en el caso de que se utilice un servidor de aplicaciones.

Los SGBD pueden considerarse como intermediarios entre las aplicaciones y la representación de los datos. Así, los desarrolladores ven los datos desde una perspectiva de más alto nivel. Esa perspectiva es la del modelo de bases de datos utilizado. De esta forma, el desarrollo de aplicaciones separa dos aspectos:

Ambos tipos de actividades no se hacen en secuencia, sino de forma simultánea, pero en la mayoría de las aplicaciones actuales se utiliza un SGBD de un tipo u otro. Así, el desarrollo de las aplicaciones en general requiere menos esfuerzo, ya que los desarrolladores no tienen que preocuparse de diseñar una gestión de datos eficiente, dado que el SGBD se supone que se encarga de eso. Los desarrolladores solo tratan con el SGBD mediante lenguajes normalizados (y a veces estandarizados) de alto nivel que ocultan muchos detalles de almacenamiento y permiten al programador centrarse en definir qué datos quiere obtener o guardar, y no en los detalles de cómo estos datos están almacenados y cómo se puede acceder de forma eficiente a ellos.

En otras palabras, es una función esencial de los SGBD en proporcionar independencia de los datos y las aplicaciones. Así, se puede diseñar la base de datos incluso antes que las aplicaciones, y ese diseño permitirá que se desarrollen múltiples aplicaciones posteriormente.

Los SGBD ocultan la representación interna de los datos ofreciendo un conjunto de funciones de más alto nivel. No obstante, en ocasiones es necesario “descender” un poco en los detalles de almacenamiento. Por ejemplo, esto a veces hace falta cuando se necesita ajustar el rendimiento de las consultas al máximo. En otros casos, una base de datos puede guadar información de cientos de entidades. Esto sucede por ejemplo en algunos sistemas de gestión empresarial. Pero muchas aplicaciones no requiren manipular o consultar todas las tablas, sino que a veces sólo necesitan algunos datos de unas pocas entidades.

Los diferentes niveles de abstracción a menudo se denominan niveles:

Es importante notar que una vista de una base de datos para sus usuarios es como una base de datos (más pequeña) a nivel lógico.

En una base de datos, las definiciones de la información se denominan esquemas (es decir, el esquema son las definiciones, no los datos en sí). El más importante de los esquemas es el esquema lógico, que realmente define la información a almacenar. El esquema físico define cómo se almacena esa información. También se habla a veces del esquema de una vista, haciendo referencia a la definición de la parte de la definición de la base de datos a la que la vista da acceso. Las diferentes vistas se definen mediante un conjunto de lenguajes.

Como ya hemos visto, los SGBD nos permiten implementar diferentes tipos de restricciones. En los ejemplos hemos visto restricciones de unicidad (no puede haber dos filas con el mismo valor en la clave primaria), o de valores nulos (algunos campos pueden tener valores nulos y otros no). También implicitamente el limitar el tamaño de un campo (como en CHAR(10)) es una restricción que afecta a los tipos de datos. Hay otros tipos de restricciones, pero lo importante es entender que un buen diseño de bases de datos pasa por una consideración detallada y acertada de las restricciones de la definición de los datos.

Los ordenadores no son máquinas perfectas, y en ocasiones ocurren desastres. Sea por desatención o por los duendes, en ocasiones un ordenador deja de funcionar temporalmente (por ejemplo, cuando falta la corriente eléctrica).

¿Qué es lo que ocurre si hay una de esas caídas en la máquina que contiene el SGBD? Si tenemos suerte, el SGBD no estaría haciendo ninguna operación de acceso a los datos en esos momentos, pero la fortuna es sólo para unos pocos. En la mayoría de los casos, el SGBD estaría haciendo algún tipo de actualización, de modo que parte de los dato estuvieran en memoria principal. Los SGBD modernos proporcionan mecanismos de recuperación que impiden que la información en la base de datos quede en un estado incoherente.

El resultado si no hubiese esos mecanismos de recuperación sería que los datos en la base de datos podrían quedar inconsistentes. Incluso la propia base de datos podría quedar dañada en su estructura.

Los mecanismos de recuperación funcionan considerando transacciones. Una transacción es un conjunto de operaciones que deben ejecutarse “a la vez”. “A la vez” no quiere decir aquí exactamente en el mismo instante de tiempo, sino que o bien se ejecutan todas o bien ninguna. Por ejemplo, si tenemos una transacción que representa un intercambio en el horario y aulas de dos exámenes dentro de una base de datos con ese calendario, el cambio podría hacerse mediante dos sentecias SQL REPLACE: una para cambiar cada una de las filas en una supuesta tabla examenes. Pues bien, si el sistema cae cuando se ha ejecutado una de ellas y no la otra, el resultado sería que los dos exámenes coincidirían en aula y hora (un estado incoherente). Pero esto no ocurrirá si el programador tienen el buen juicio de colocar las dos sentencias REPLACE como operaciones de una misma transacción. En ese caso, si se realizó el primer REPLACE y no el segundo, el SGBD deshará (rollback) los cambios del primero al volver a estar en funcionamiento.

Además de las caídas a las que hemos mencionado, las bases de datos pueden quedar en estados incoherentes si varios programas intentan actualizar los datos a la vez. Los SGBD para estos casos también consideran las transacciones como secuencias de operaciones “todo o nada”. Además, los SGBD proporcionan diferentes mecanismos de control de concurrencia.

Hay diferentes políticas de control de concurrencia, unas más liberales y otras más restrictivas, con sus ventajas e inconvenientes. Una política restrictiva típica es la de bloquear la parte de la base de datos que se está actualizando. Así, lo que se hace es serializar (es decir, hacer pasar “uno a uno”) el acceso de los diferentes programas (de las diferentes transacciones) a esa determinada porción de los datos.

Una base de datos es por tanto un almacén separado de las aplicaciones. Típicamente, una base de datos en una empresa será utilizada por diferentes Departamentos para diferentes usos. Por ello, es lógico que diferentes personas (usuarios) tengan diferentes posibilidades (derechos, privilegios o permisos) de uso y manipulación, no solo de los datos, sino del esquema que los define.

Típicamente, en un SGBD existe la figura del Administrador de Base de Datos (DBA, Database administrator) que tiene todos las posibilidades sobre las bases de datos albergadas en el SGBD, y que puede comenzar a crearlas. Así, el sistema de privilegios actuará por delegación, es decir, el DBA creará una base de datos y repartirá ciertos privilegios sobre ella a ciertor usuarios (o grupos de usuarios). A su vez, algunos de estos usuarios tendrán derecho a delegar a otros ciertos privilegios sobre ciertas partes de la base de datos, etc.

A todo este sistema de privilegios se denomina habitualmente control de acceso. Además del control de acceso, un SGBD proporciona un registro de todos los accesos a las bases de datos, permitiendo así auditar los cambios, es decir, inspecionar quién hizo qué en qué momento.

Hay muchos otros servicios que habitualmente proporcionan los SGBD. Entre ellos podemos contar los servicios de copia de seguridad (backup), la compresión de datos o la felxibilidad en añadir nuevos tipos de datos.

A pesar de que los SGDB nos proporcionan muchas herramientas para una gestión eficaz y eficiente de los datos, hay aspectos fundamentales que no dependen del uso de un SGBD, sino de un buen diseño de la base de datos. Es decir, dependen del trabajo de los diseñadores. Por ejemplo, spongamos que tenemos el siguiente esquema de base de datos:

PEDIDOS(id-cliente, nombre-cliente, id-producto, nombre-producto, cantidad-pedida, fecha, stock-producto)

PRODUCTOS(id, nombre, precio)

CLIENTES(id, nombre, ...)

El diseño en este caso causará diferentes problemas. Entre ellos podemos mencionar:

En resumen, el SGBD nos garantiza lo que incluyamos como restricciones, y se preocupa de la concurencia y las caídas, pero no es capaz de mitigar el daño de un mal diseño.