¿Qué es una base de datos?

Una base de datos (database) almacena datos y los conecta en una unidad lógica junto a los metadatos ne­ce­sa­rios para su pro­ce­sa­mie­n­to. Las bases de datos son in­s­tru­me­n­tos de gran utilidad para gestionar grandes ficheros y facilitar la consulta de in­fo­r­ma­ció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 di­fe­re­n­cian co­n­ce­p­tua­l­me­n­te entre sí y tienen, por lo tanto, sus propias ventajas y de­s­ve­n­ta­jas. Pero, antes que nada, es co­n­ve­nie­n­te di­fe­re­n­ciar 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 re­s­po­n­sa­ble de su ad­mi­ni­s­tra­ción, de­te­r­mi­na­n­do así su es­tru­c­tu­ra, el orden, los permisos de acceso, las de­pe­n­de­n­cias, etc. Para ello aco­s­tu­m­bra a utilizar un co­m­pi­la­dor propio y un modelo adecuado de base de datos que determina la ar­qui­te­c­tu­ra del sistema de base de datos.

En muchos casos, solo ciertas apli­ca­cio­nes, o aquellas que han sido exac­ta­me­n­te definidas para ello, pueden leer estos sistemas. Es aquí donde, con fre­cue­n­cia, se dan co­n­fu­sio­nes te­r­mi­no­ló­gi­cas 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 co­le­c­cio­nes de archivos, mientras que ,en su sentido estricto, una carpeta con archivos en un ordenador no co­n­s­ti­tu­ye una base de datos.

Para aumentar la efi­cie­n­cia es­tru­c­tu­ral del tra­ta­mie­n­to ele­c­tró­ni­co de los datos, ya en la década de los 60, se empezó a de­sa­rro­llar el concepto de la base de datos ele­c­tró­ni­ca como capa separada de software entre el sistema operativo y el programa de apli­ca­ción. Esto fue el resultado de la ex­pe­rie­n­cia del día a día, pues tanto manipular los archivos como su­pe­r­vi­sar y repartir los permisos adquirió tal co­m­ple­ji­dad que el pro­ce­sa­mie­n­to ele­c­tró­ni­co de los datos no significó un avance real. Así, la idea del sistema de bases de datos ele­c­tró­ni­co se convirtió en una de las in­no­va­cio­nes más re­le­va­n­tes en el de­sa­rro­llo del ordenador.

Los primeros modelos que se de­sa­rro­lla­ron fueron las bases de datos en red y je­rá­r­qui­cas, si bien pronto de­mo­s­tra­ron ser demasiado simples y estar limitadas té­c­ni­ca­me­n­te. IBM fue la empresa que re­vo­lu­cio­nó el sector, con el de­sa­rro­llo del modelo re­la­cio­nal 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 in­su­fla­ron 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 Po­s­t­gre­S­QL. La tendencia iniciada en 2001 hacia los sistemas NoSQL también co­n­tri­bu­yó a la de­bi­li­ta­ción de la posición de los sistemas de bases de datos de los grandes fa­bri­ca­n­tes.

Hoy, los sistemas de bases de datos son im­pre­s­ci­n­di­bles 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 he­rra­mie­n­tas para los ad­mi­ni­s­tra­do­res del sistema. La seguridad de los datos, además, ha ido ganando im­po­r­ta­n­cia con el tiempo, y es que en las bases de datos ele­c­tró­ni­cas se almacenan y cifran co­n­tra­se­ñas, datos pe­r­so­na­les e incluso divisa digital.

El sistema fi­na­n­cie­ro moderno, no es más que una red de bases de datos, en la cual la mayor parte de las cuantías mo­ne­ta­rias solo existen como unidades ele­c­tró­ni­cas de in­fo­r­ma­ción, cuya pro­te­c­ción, por medio de bases de datos seguras es una de las tareas pri­n­ci­pa­les de las in­s­ti­tu­cio­nes fi­na­n­cie­ras. Aunque no solo por esto son cruciales las bases de datos ele­c­tró­ni­cas para la ci­vi­li­za­ción moderna.

Un término muy extendido para describir las funciones y los re­qui­si­tos de las tra­n­sac­cio­nes en un database ma­na­ge­me­nt system es el de ACID, acrónimo de atomicity, co­n­si­s­te­n­cy, isolation y du­ra­bi­li­ty (ato­mi­ci­dad, co­n­si­s­te­n­cia, ai­s­la­mie­n­to, du­ra­bi­li­dad). Estos cuatro pa­rá­me­tros, cubren los re­qui­si­tos más im­po­r­ta­n­tes de un SGBD (ACID compliant):

• Ato­mi­ci­dad designa a la propiedad “todo o nada” de los gestores de bases de datos: para que una consulta sea válida y la tra­n­sac­ción se complete co­rre­c­ta­me­n­te se ha de llevar a cabo en el orden correcto de pasos.
• La co­n­si­s­te­n­cia (o co­he­re­n­cia) se da cuando al finalizar una tra­n­sac­ción, la base de datos sigue siendo estable, lo que requiere la su­pe­r­vi­sión continua de todas las tra­n­sac­cio­nes.
• El ai­s­la­mie­n­to es la condición que garantiza que las tra­n­sac­cio­nes no se ob­s­ta­cu­li­cen unas a otras, algo que no­r­ma­l­me­n­te se logra con ciertas funciones de bloqueo que aíslan los datos que pa­r­ti­ci­pan en una tra­n­sac­ción.
• La du­ra­bi­li­dad significa que en un SGBD todos los datos se guardan a largo plazo incluso tras concluir una tra­n­sac­ción y también, o es­pe­cia­l­me­n­te, en el caso de fallos del sistema o caídas del SGBD. Para esta condición, son ese­n­cia­les los registros de tra­n­sac­ción, que pro­to­co­li­zan todos los procesos que tienen lugar en el SGBD.

A co­n­ti­nua­ción de­ta­lla­mos una forma diferente de cla­si­fi­car las funciones y los re­qui­si­tos de un sistema de gestión de bases de datos:

Las di­fe­re­n­cias entre los modelos de bases de datos más ha­bi­tua­les es resultado de la evolución técnica de la tra­n­s­mi­sión ele­c­tró­ni­ca de datos, que no solo perseguía la efi­cie­n­cia y la ma­ne­ja­bi­li­dad, sino también, el em­po­de­ra­mie­n­to de los fa­bri­ca­n­tes más re­no­m­bra­dos.

Este es el modelo más antiguo, hoy superado en gran medida por el modelo re­la­cio­nal (entre otros), si bien re­cie­n­te­me­n­te 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 je­rá­r­qui­cas sobre todo en las apli­ca­cio­nes más antiguas de base de datos. El sistema de base de datos je­rá­r­qui­co más conocido es IMS/DB de IBM.

En las bases de datos je­rá­r­qui­cas las de­pe­n­de­n­cias son ine­quí­vo­cas. Cada registro tiene solo un pre­ce­de­n­te (Parent-Child Re­la­tio­n­shi­ps, PCR) a excepción de la raíz (root), co­n­s­ti­tu­ye­n­do 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 or­de­na­mie­n­to je­rá­r­qui­co, los niveles sin relación directa, no in­ter­ac­túan entre sí y conectar dos árboles di­fe­re­n­tes tampoco es fácil. Por todo esto, las es­tru­c­tu­ras de base de datos je­rá­r­qui­cas son ex­tre­ma­da­me­n­te in­fle­xi­bles, 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 do­cu­me­n­tos. Los records sirven para cla­si­fi­car las hojas. Las consultas a una base de datos je­rá­r­qui­ca alcanzan a las hojas partiendo desde la raíz y pasando por los distintos records.

El modelo en red se de­sa­rro­lló casi de forma si­mu­l­tá­nea al re­la­cio­nal, aunque con el tiempo sería superado por la co­m­pe­te­n­cia. A di­fe­re­n­cia del modelo je­rá­r­qui­co, aquí los registros o records no revelan re­la­cio­nes padre-hijo estrictas, sino que cada registro puede tener múltiples pre­ce­de­n­tes, lo que le da la es­tru­c­tu­ra en red de su nombre. Para acceder a un registro tampoco hay, por eso mismo, un camino único e in­va­ria­ble.

Al registro situado en el centro de la imagen puede accederse en teoría desde los otros cinco, y ac­ce­die­n­do a él, puede accederse a otros cinco registros. En el modelo en red también pueden definirse de­pe­n­de­n­cias: el registro situado más arriba no está conectado di­re­c­ta­me­n­te 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 es­ta­ble­cer contacto con el de arriba a la izquierda. En el modelo en red, los registros pueden añadirse o eli­mi­nar­se sin que la es­tru­c­tu­ra global se vea afectada.

Hoy el modelo de base de datos en red se utiliza, sobre todo, en los grandes or­de­na­do­res. En otros campos se sigue confiando en el modelo je­rá­r­qui­co (clientes de IBM, sobre todo) o se ha dado el paso hacia el modelo re­la­cio­nal, 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 fa­bri­ca­n­tes han de­sa­rro­lla­do también in­te­re­sa­n­tes formas mixtas entre el modelo en red y el re­la­cio­nal aunque sin lograr arrancar del todo. Con todo, aún hoy pueden en­co­n­trar­se aspectos de estos intentos en el SQL de Siemens. La base de datos orientada a grafos, por su es­tru­c­tu­ra reticular, es co­n­si­de­ra­da la evolución moderna del modelo en red.

El modelo re­la­cio­nal trabaja con tablas in­de­pe­n­die­n­tes que de­te­r­mi­nan la lo­ca­li­za­ción de los datos y sus co­ne­xio­nes. 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 in­ter­re­la­cio­na­dos. Para ide­n­ti­fi­car ine­quí­vo­ca­me­n­te un registro es elemental la clave primaria, que no­r­ma­l­me­n­te 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 en­co­n­tra­do una escasa apli­ca­ción. Estas bases de datos, di­s­po­ni­bles también en formato open source, suelen uti­li­zar­se en pla­ta­fo­r­mas 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 aco­s­tu­m­bran 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 pro­fu­n­di­dad. En un sistema de gestión de bases de datos de objetos, son los métodos, de­po­si­ta­dos en el objeto junto con los datos, los que definen cómo se accede al objeto.

Los objetos pueden ser complejos y estar co­m­pue­s­tos por múltiples tipos de datos, son únicos dentro del sistema de base de datos y se ide­n­ti­fi­can con un ide­n­ti­fi­ca­dor 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 je­rá­r­qui­co, 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 orie­n­ta­das 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 no­r­ma­li­za­ción y a la co­rre­s­po­n­de­n­cia de ID, pe­r­mi­tie­n­do así almacenar los objetos nuevos de forma re­la­ti­va­me­n­te simple y fluida. Sin embargo, las consultas son mucho más ágiles en un sistema de base de datos re­la­cio­nal. La escasa po­pu­la­ri­dad de los sistemas orie­n­ta­dos a objetos resulta en una in­su­fi­cie­n­te co­m­pa­ti­bi­li­dad con muchas de las apli­ca­cio­nes de base de datos que se usan ha­bi­tua­l­me­n­te.

En este modelo, los do­cu­me­n­tos son la unidad básica para el al­ma­ce­na­mie­n­to de datos. Estas unidades son las que es­tru­c­tu­ran los datos y no deben co­n­fu­n­di­r­se con los do­cu­me­n­tos de los programas de pro­ce­sa­mie­n­to de texto. Aquí, los datos se guardan en los llamados pares clave-valor, co­m­pre­n­die­n­do así, una “clave” y un “valor”. Como no están definidos ni la es­tru­c­tu­ra ni el número de pares, los do­cu­me­n­tos que integran una base de datos orientada a do­cu­me­n­tos pueden resultar muy dispares entre sí. Cada documento es una unidad cerrada en sí misma y es­ta­ble­cer re­la­cio­nes entre do­cu­me­n­tos no resulta fácil, pero en este modelo no es necesario.

En el modelo re­la­cio­nal (arriba re­pre­se­n­ta­do con las dos tablas), varias re­la­cio­nes (tablas) se conectan entre sí para se­le­c­cio­nar un registro común. En el modelo do­cu­me­n­tal, un único documento basta para guardar toda la in­fo­r­ma­ción. Aquí no se está obligado a utilizar un de­te­r­mi­na­do esquema porque, mientras se use siempre el mismo lenguaje de base de datos, este modelo está co­n­ce­p­tua­l­me­n­te libre de esquemas.

Una idea fu­n­da­me­n­tal de las bases de datos do­cu­me­n­ta­les 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 re­la­cio­na­les suelen re­pre­se­n­tar y mostrar la in­fo­r­ma­ción re­la­cio­na­da co­ne­c­ta­n­do varias tablas, en el modelo que nos ocupa es su­fi­cie­n­te con consultar un solo documento. Esto reduce el número de pro­ce­di­mie­n­tos ne­ce­sa­rios para consultar la base de datos.

Estos sistemas son es­pe­cia­l­me­n­te in­te­re­sa­n­tes para las apli­ca­cio­nes web, puesto que permiten guardar fo­r­mu­la­rios HTML completos. Fue sobre todo con el avance de la web 2.0 cuando estas bases de datos vieron aumentar su po­pu­la­ri­dad. Con todo, es necesario remarcar que entre los diversos sistemas basados en do­cu­me­n­tos se dan di­fe­re­n­cias notables, desde la sintaxis hasta la es­tru­c­tu­ra interna, por lo que no todas las bases de datos orie­n­ta­das a do­cu­me­n­tos son apro­pia­das para cualquier escenario. Es debido a estas di­fe­re­n­cias por lo que hoy di­s­po­ne­mos de algunos sistemas de bases de datos orie­n­ta­dos a do­cu­me­n­tos de la repu­tación de Lotus Notes, Amazon SimpleDB, MongoDB, CouchDB, Riak, ThruDB, OrientDB, etc.