Bases de datos: qué tipos hay y para qué se usan

Una base de datos (database) almacena datos y los conecta en una unidad lógica junto a los metadatos necesarios para su procesamiento. Las bases de datos son instrumentos de gran utilidad para gestionar grandes ficheros y facilitar la consulta de información. En muchas, además, puede definirse un esquema de permisos que establece qué personas o programas pueden acceder a los datos, y a cuáles, con el objetivo de presentar el contenido de forma adecuada y clara.

Los distintos sistemas de bases de datos se diferencian conceptualmente entre sí y tienen, por lo tanto, sus propias ventajas y desventajas. Pero, antes que nada, es conveniente diferenciar entre la base de datos en sí y el sistema que la gestiona. Como base de datos se designa al conjunto de los datos que se ha de ordenar, mientras que el sistema de gestión de la base de datos (SGBD) es responsable de su administración, determinando así su estructura, el orden, los permisos de acceso, las dependencias, etc. Para ello acostumbra a utilizar un compilador propio y un modelo adecuado de base de datos que determina la arquitectura del sistema de base de datos.

En muchos casos, solo ciertas aplicaciones, o aquellas que han sido exactamente definidas para ello, pueden leer estos sistemas. Es aquí donde, con frecuencia, se dan confusiones terminológicas cuando un programa de base de datos se define solo como “base de datos”. El término, además, se utiliza para referirse a simples colecciones de archivos, mientras que ,en su sentido estricto, una carpeta con archivos en un ordenador no constituye una base de datos.

Para aumentar la eficiencia estructural del tratamiento electrónico de los datos, ya en la década de los 60, se empezó a desarrollar el concepto de la base de datos electrónica como capa separada de software entre el sistema operativo y el programa de aplicación. Esto fue el resultado de la experiencia del día a día, pues tanto manipular los archivos como supervisar y repartir los permisos adquirió tal complejidad que el procesamiento electrónico de los datos no significó un avance real. Así, la idea del sistema de bases de datos electrónico se convirtió en una de las innovaciones más relevantes en el desarrollo del ordenador.

Los primeros modelos que se desarrollaron fueron las bases de datos en red y jerárquicas, si bien pronto demostraron ser demasiado simples y estar limitadas técnicamente. IBM fue la empresa que revolucionó el sector, con el desarrollo del modelo relacional de base de datos en los años setenta, con mucho el más potente, que pronto encontró un campo de cultivo favorable en el mundo laboral. Los productos que más éxito tuvieron en este momento, fueron el lenguaje de consultas a bases de datos SQL de Oracle y los sucesores de IBM, SQL/DS y DB2.

Hasta bien entrados los años 2000, cuando algunos proyectos de código libre insuflaron algo de aire fresco al sector, el mercado del software de base de datos estuvo gobernado por los pesos pesados. Entre los sistemas libres más populares se cuentan MySQL y PostgreSQL. La tendencia iniciada en 2001 hacia los sistemas NoSQL también contribuyó a la debilitación de la posición de los sistemas de bases de datos de los grandes fabricantes.

Hoy, los sistemas de bases de datos son imprescindibles en numerosos campos. Cualquier tipo de software concebido para las empresas se basa en robustas bases de datos con un gran número de opciones y herramientas para los administradores del sistema. La seguridad de los datos, además, ha ido ganando importancia con el tiempo, y es que en las bases de datos electrónicas se almacenan y cifran contraseñas, datos personales e incluso divisa digital.

El sistema financiero moderno, no es más que una red de bases de datos, en la cual la mayor parte de las cuantías monetarias solo existen como unidades electrónicas de información, cuya protección, por medio de bases de datos seguras es una de las tareas principales de las instituciones financieras. Aunque no solo por esto son cruciales las bases de datos electrónicas para la civilización moderna.

Un término muy extendido para describir las funciones y los requisitos de las transacciones en un database management system es el de ACID, acrónimo de atomicity, consistency, isolation y durability (atomicidad, consistencia, aislamiento, durabilidad). Estos cuatro parámetros, cubren los requisitos más importantes de un SGBD (ACID compliant):

• Atomicidad designa a la propiedad “todo o nada” de los gestores de bases de datos: para que una consulta sea válida y la transacción se complete correctamente se ha de llevar a cabo en el orden correcto de pasos.
• La consistencia (o coherencia) se da cuando al finalizar una transacción, la base de datos sigue siendo estable, lo que requiere la supervisión continua de todas las transacciones.
• El aislamiento es la condición que garantiza que las transacciones no se obstaculicen unas a otras, algo que normalmente se logra con ciertas funciones de bloqueo que aíslan los datos que participan en una transacción.
• La durabilidad significa que en un SGBD todos los datos se guardan a largo plazo incluso tras concluir una transacción y también, o especialmente, en el caso de fallos del sistema o caídas del SGBD. Para esta condición, son esenciales los registros de transacción, que protocolizan todos los procesos que tienen lugar en el SGBD.

A continuación detallamos una forma diferente de clasificar las funciones y los requisitos de un sistema de gestión de bases de datos:

Las diferencias entre los modelos de bases de datos más habituales es resultado de la evolución técnica de la transmisión electrónica de datos, que no solo perseguía la eficiencia y la manejabilidad, sino también, el empoderamiento de los fabricantes más renombrados.

Este es el modelo más antiguo, hoy superado en gran medida por el modelo relacional (entre otros), si bien recientemente su empleo ha ido creciendo. XML utiliza este sistema para guardar datos y algunas compañías de seguros y bancos recurren a las bases de datos jerárquicas sobre todo en las aplicaciones más antiguas de base de datos. El sistema de base de datos jerárquico más conocido es IMS/DB de IBM.

En las bases de datos jerárquicas las dependencias son inequívocas. Cada registro tiene solo un precedente (Parent-Child Relationships, PCR) a excepción de la raíz (root), constituyendo un esquema en árbol como el de arriba. Mientras que cada nodo “hijo”, solo puede tener un nodo “padre”, los “padres” pueden tener tantos “hijos” como quieran. Dado el estricto ordenamiento jerárquico, los niveles sin relación directa, no interactúan entre sí y conectar dos árboles diferentes tampoco es fácil. Por todo esto, las estructuras de base de datos jerárquicas son extremadamente inflexibles, pero muy claras.

Los registros con hijos se llaman records y los que no tienen se llaman hojas y son los que suelen contener los documentos. Los records sirven para clasificar las hojas. Las consultas a una base de datos jerárquica alcanzan a las hojas partiendo desde la raíz y pasando por los distintos records.

El modelo en red se desarrolló casi de forma simultánea al relacional, aunque con el tiempo sería superado por la competencia. A diferencia del modelo jerárquico, aquí los registros o records no revelan relaciones padre-hijo estrictas, sino que cada registro puede tener múltiples precedentes, lo que le da la estructura en red de su nombre. Para acceder a un registro tampoco hay, por eso mismo, un camino único e invariable.

Al registro situado en el centro de la imagen puede accederse en teoría desde los otros cinco, y accediendo a él, puede accederse a otros cinco registros. En el modelo en red también pueden definirse dependencias: el registro situado más arriba no está conectado directamente con el de más a la derecha, de modo que para llegar a él ha de pasar por el del centro, que puede aceptar o denegar el paso. Podría entonces establecer contacto con el de arriba a la izquierda. En el modelo en red, los registros pueden añadirse o eliminarse sin que la estructura global se vea afectada.

Hoy el modelo de base de datos en red se utiliza, sobre todo, en los grandes ordenadores. En otros campos se sigue confiando en el modelo jerárquico (clientes de IBM, sobre todo) o se ha dado el paso hacia el modelo relacional, mucho más flexible y fácil de utilizar. Algunos modelos conocidos de base de datos en red son el UDS de Siemens y el DMS de Sperry Univac. Con el tiempo, ambos fabricantes han desarrollado también interesantes formas mixtas entre el modelo en red y el relacional aunque sin lograr arrancar del todo. Con todo, aún hoy pueden encontrarse aspectos de estos intentos en el SQL de Siemens. La base de datos orientada a grafos, por su estructura reticular, es considerada la evolución moderna del modelo en red.

El modelo relacional trabaja con tablas independientes que determinan la localización de los datos y sus conexiones. Estos datos conforman un registro (en la imagen, una fila o “tupla”) y se guardan en columnas como atributos (en la imagen, de A1 a An). La relación es lo que resulta de los atributos interrelacionados. Para identificar inequívocamente un registro es elemental la clave primaria, que normalmente se define como el primer atributo (A1) y que no puede cambiarse. Dicho de otra manera, esta clave primaria o ID, define la posición exacta del registro con todos los atributos.

Las bases de datos de objetos no nacen hasta finales de 1980 y hasta hoy, solo han encontrado una escasa aplicación. Estas bases de datos, disponibles también en formato open source, suelen utilizarse en plataformas Java y .NET. La más conocida es db4o, que destaca, sobre todo, por un escaso uso de la memoria. Las bases de datos de objetos acostumbran a trabajar con el lenguaje OQL, muy similar a SQL.

En el modelo orientado a objetos, los datos se guardan en un objeto junto con sus funciones (métodos) y los atributos que los describen más en profundidad. En un sistema de gestión de bases de datos de objetos, son los métodos, depositados en el objeto junto con los datos, los que definen cómo se accede al objeto.

Los objetos pueden ser complejos y estar compuestos por múltiples tipos de datos, son únicos dentro del sistema de base de datos y se identifican con un identificador de objeto (OID en inglés) único. Como puede verse en la figura de arriba, los objetos se agrupan en clases (object category), dando como resultado una jerarquía de clases. Pese a la aparente similitud con el modelo jerárquico, aquí predomina el paradigma orientado a objetos y no existe ninguna relación padre-hijo fija. Aún así, a través de la clase puede definirse el método para el acceso.

Las ventajas de las bases de datos orientadas a objetos destacan, sobre todo, en problemas con tipos de datos complejos. Estas bases de datos trabajan, en su mayor parte, de forma autónoma sin recurrir a la normalización y a la correspondencia de ID, permitiendo así almacenar los objetos nuevos de forma relativamente simple y fluida. Sin embargo, las consultas son mucho más ágiles en un sistema de base de datos relacional. La escasa popularidad de los sistemas orientados a objetos resulta en una insuficiente compatibilidad con muchas de las aplicaciones de base de datos que se usan habitualmente.

En este modelo, los documentos son la unidad básica para el almacenamiento de datos. Estas unidades son las que estructuran los datos y no deben confundirse con los documentos de los programas de procesamiento de texto. Aquí, los datos se guardan en los llamados pares clave-valor, comprendiendo así, una “clave” y un “valor”. Como no están definidos ni la estructura ni el número de pares, los documentos que integran una base de datos orientada a documentos pueden resultar muy dispares entre sí. Cada documento es una unidad cerrada en sí misma y establecer relaciones entre documentos no resulta fácil, pero en este modelo no es necesario.

En el modelo relacional (arriba representado con las dos tablas), varias relaciones (tablas) se conectan entre sí para seleccionar un registro común. En el modelo documental, un único documento basta para guardar toda la información. Aquí no se está obligado a utilizar un determinado esquema porque, mientras se use siempre el mismo lenguaje de base de datos, este modelo está conceptualmente libre de esquemas.

Una idea fundamental de las bases de datos documentales es que los datos que guardan relación entre sí siempre se guardan juntos en un lugar (en el documento). Mientras que las bases de datos relacionales suelen representar y mostrar la información relacionada conectando varias tablas, en el modelo que nos ocupa es suficiente con consultar un solo documento. Esto reduce el número de procedimientos necesarios para consultar la base de datos.

Estos sistemas son especialmente interesantes para las aplicaciones web, puesto que permiten guardar formularios HTML completos. Fue sobre todo con el avance de la web 2.0 cuando estas bases de datos vieron aumentar su popularidad. Con todo, es necesario remarcar que entre los diversos sistemas basados en documentos se dan diferencias notables, desde la sintaxis hasta la estructura interna, por lo que no todas las bases de datos orientadas a documentos son apropiadas para cualquier escenario. Es debido a estas diferencias por lo que hoy disponemos de algunos sistemas de bases de datos orientados a documentos de la reputación de Lotus Notes, Amazon SimpleDB, MongoDB, CouchDB, Riak, ThruDB, OrientDB, etc.