Sistemas de gestión de bases de datos

'

Historia de las bases de datos y su evolución:

No voy a enrollarme mucho en lo que sería la historia de las bases de datos y en sus primeros planteamientos con los modelos relacionales, pero es interesante hacer un pequeño repaso, más que nada por culturilla general 😉 . Los primeros modelos relacionales de bases de datos se plantearon allá por los años 70, pero antes, pues puedes imaginarte como se organizaba y como se almacenaba la información. Simples ficheros sin ningún tipo de control, donde la redundancia y las inconsistencias eran visibles desde lo más alto de Madrid. El modelo relacional fue presentado y definido por Edward F.Codd  en 1970.

Pasa el tiempo y aparecen los Objetos (Si no sabes que es un objeto en programación, echa un ojo a esto). La programación orientada a objetos mejoro notablemente la forma en la que se desarrollaban los programas y por lo tanto, también en las bases de datos, evitando tanta encapsulación y una estructura rígida que tenía ( y tiene) el modelo relacional. Este paradigma, se transformó luego en lo que sería el modelo conocido como NOSQL.

Ahora que ya conoces un poco de historia…

Arquitectura funcional de un Sistema Gestor de Bases de Datos

arquitectura SGBD

Como puedes ver en la imagen de arriba, el SGDB lo forman diferentes componentes, de los cuales cada uno se encarga de una función claramente definida. Los componentes más importantes serian el Gestor de consultas ( Query Manager) y el Gestos de Datos ( Data Manager).

Query Manager

El gestor de consultas es el encargado de transformar una consulta declarativa en una consulta entendible por el SGBD, para conseguir esto, el proceso ( bastante complejo ) se ayuda de los siguientes componentes:

  • View Manager: o gestor de la vista, primero analiza donde se va a realizar la consulta, para el usuario, esto es transparente, realmente al usuario le da igual si la consulta la realiza en una vista materializada, en una tabla o un fichero.
  • Segurity Manager: Gestor de seguridad es el encargado de ver si ese usuario, tiene los permisos suficientes para poder realizar la consulta. Al administrar un sistema de bases de datos, hay que tener muy en cuenta que tipo de usuarios y aplicaciones van a tener acceso a los datos y que van a poder hacer con ellos. Para eso, defirnir roles y privilegios es un básico.
  • Constraints Checker: Control de Constrain, cuando definimos una tabla, definimos ciertas restricciones, como el tipo de datos, la longitud del campo, etc.. Pues este “controlador” sería el encargado de asegurar que la consulta no viola ninguna de ellas.
  • Query optimiser: El optimizador de consulta, creo sinceramente que es el componente más complejo y más difícil de optimizar por parte del SGBD, ya que de el depende la velocidad con la que se realizan las consultas. Cuando vemos que un SGBD es más eficiente que otro, en muchas ocasiones, es por el esfuerzo y sudor que los ingenieros han depositado en este componente. La optimización de la consulta se compone de tres componentes:
    • Optimización Semántica
    • Optimización Sintáctica
    • Optimización Física

Execution Manager:

Una vez pasado todos los controles y optimizada la consulta, el control de ejecución de consulta es el encargado de transformar esa consulta en una consulta llamada atómica, donde básicamente es una consulta en algebra relacional.

Scheduler:

Programador o en ocasiones también llamado balanceador, es el encargado de gestionar el acceso a las consultas, es el componente que decide “que consulta” y cuando ejecutarla. Es una primera aproximación al mecanismos que evita que existan inconsistencias dentro de una base de datos, impidiendo, por ejemplo, que dos consultas actualicen de forma simultanea un mismo registro.

Data Manager:

Es el encargado de gestionar todo lo relacionado con los datos, haciendo que sean accesibles de forma rápida y consistentes. Cuando consultamos a los datos de una base de datos, estos deben ser resueltos en un tiempo relativamente corto, es por eso, que el uso del almacenamiento debe estar lo más optimizado posible, llevando y guardando los datos del disco a memoria.

Recovery Manager:

Este pequeño componente es una de las piezas claves de que nuestros datos no se pierdan nunca. Es el encargado de recuperar los datos en caso de alguna incidencia o fallo crítico.

Imagina la situación siguiente:

Un usuario quiere insertar un registro en la base de datos, el SGBD recupera la tabla ( la lleva a memoria), registra el cambio y confirma al usuario que la inserción ha sido aceptada y guardada, pero realmente esos datos aún están en memoria volátil, por lo que hasta que esos datos no se llevan a memoria física, no podremos asegurar que están a salvo. Ahora bien, y si justo en ese momento, hay un problema con un generador y se apaga… ¿Se habrán salvado esos datos a tiempo?,¿Estaremos seguros 100% de la persistencia de ese dato?. Lamentablemente no, y por eso necesitamos de mecanismos de Roll-back y de recuperación de datos.

 

 

Más artículos sobre IT

IT

Elemento complexType del esquema XML:

El elemento del esquema XML complexType se utiliza básicamente para definir un tipo de elemento que consiste en más subelementos. Como podría ser...