Base de datos orientada a objetos: el secreto mejor guardado de los modelos de bases de datos

La mayoría de las personas que gestionan re­gu­la­r­me­n­te bases de datos, como los pro­gra­ma­do­res de software, de­sa­rro­lla­do­res web o bi­blio­te­ca­rios, trabajan con bases de datos re­la­cio­na­les o con los co­rre­s­po­n­die­n­tes sistemas gestores de base de datos (SGBD), como MySQL o MariaDB. No obstante, hay otras al­te­r­na­ti­vas: las bases de datos orie­n­ta­das a objetos (también llamadas bases de datos de objetos) apenas se utilizan, pero pueden mejorar mucho el re­n­di­mie­n­to de algunos proyectos.

El modelo de base de datos orientada a objetos agrupa la in­fo­r­ma­ción en paquetes re­la­cio­na­dos entre sí: los datos de cada registro se combinan en un solo objeto, con todos sus atributos. De esta manera, toda la in­fo­r­ma­ción está di­s­po­ni­ble en el objeto, ya que sus datos quedan agrupados en lugar de di­s­tri­bui­dos en di­fe­re­n­tes tablas. En los objetos no solo pueden guardarse los atributos, sino también los métodos, lo que refleja la afinidad de estas bases de datos con los lenguajes de pro­gra­ma­ción orie­n­ta­dos a objetos: al igual que en estos, cada objeto presenta un conjunto de acciones que pueden llevarse a cabo.

Los objetos se dividen a su vez en clases. Más co­n­cre­ta­me­n­te, un objeto es una unidad concreta de una clase abstracta, lo que crea una jerarquía de clases y subclases. Dentro de esta es­tru­c­tu­ra, las subclases adoptan las pro­pie­da­des de las clases su­pe­ro­r­di­na­das y las co­m­ple­me­n­tan con sus propios atributos. Al mismo tiempo, los objetos de una clase también pueden re­la­cio­nar­se con otras clases, lo que rompe la jerarquía estricta y permite formar redes. Los objetos simples también pueden co­m­bi­nar­se para crear objetos más complejos.

Para gestionar los diversos objetos, el SGBD orientado a objetos co­rre­s­po­n­die­n­te asigna au­to­má­ti­ca­me­n­te un código de ide­n­ti­fi­ca­ción único a cada registro, que permite recuperar los objetos una vez que se han guardado.

Ejemplo: en el contexto de una base de datos orientada a objetos, podemos guardar una bicicleta como objeto, con todos sus atributos y métodos: es roja, se puede conducir, tiene sillín, etc. Este objeto forma parte de la clase “bi­ci­cle­tas”, en la que, por ejemplo, también podría incluirse una bicicleta azul y otra verde. A su vez, la clase “bi­ci­cle­tas” es una su­b­ca­te­go­ría de “vehículos”, que también incluye la clase “coches”. Por otra parte, el objeto también está re­la­cio­na­do con la clase “ac­ti­vi­da­des de ocio”. Si accedemos a este objeto a través de su código de ide­n­ti­fi­ca­ción único, di­s­po­n­dre­mos di­re­c­ta­me­n­te de todos sus métodos y atributos.

Como hemos dicho, las bases de datos re­la­cio­na­les son el estándar en pro­gra­ma­ción y de­sa­rro­llo web desde hace mucho tiempo. En este modelo, la in­fo­r­ma­ción se almacena en tablas re­la­cio­na­das entre sí. Las re­la­cio­nes también permiten almacenar y consultar in­fo­r­ma­ción compleja compuesta por varios elementos, al igual que en las bases de datos de objetos. En las últimas, sin embargo, todos los atributos de cada objeto están di­s­po­ni­bles de inmediato y, además, los registros pueden ser mucho más complejos. Por otra parte, con las bases de datos re­la­cio­na­les, lo más habitual es intentar si­m­pli­fi­car al máximo la in­fo­r­ma­ción que se introduce. Cuanto más complejo se vuelve el conjunto de los datos, más extensas son las re­la­cio­nes entre ellos, lo que ralentiza la base de datos.

El modelo de base de datos con el que decidamos trabajar dependerá mucho del uso que queramos darle. Las bases de datos de objetos son es­pe­cia­l­me­n­te adecuadas si ya estamos tra­ba­ja­n­do con lenguajes de pro­gra­ma­ción orie­n­ta­dos a objetos, como Java, porque los objetos del código fuente se pueden integrar fá­ci­l­me­n­te en la base de datos. Si re­cu­rri­mos a una base de datos re­la­cio­nal, lo que suele ser lo más frecuente, nos costará in­co­r­po­rar objetos complejos a la es­tru­c­tu­ra tabular.

Uno de los in­co­n­ve­nie­n­tes de este modelo es que su uso está poco extendido. Aunque se conoce desde la década de 1980, hasta ahora solo se han de­sa­rro­lla­do unos pocos SGBD para bases de datos orie­n­ta­das a objetos. La comunidad que se dedica a mejorar este modelo también es re­la­ti­va­me­n­te pequeña. Por ello, la mayoría de los de­sa­rro­lla­do­res prefieren utilizar bases de datos re­la­cio­na­les, que están ge­ne­ra­li­za­das, bien do­cu­me­n­ta­das y mucho más de­sa­rro­lla­das.

Lo que supone una ventaja en ciertas si­tua­cio­nes puede co­n­ve­r­ti­r­se en un in­co­n­ve­nie­n­te en otras: la co­m­ple­ji­dad de los objetos garantiza que hasta las consultas y ano­ta­cio­nes más complejas puedan llevarse a cabo mucho más rápido que en los modelos re­la­cio­na­les. Sin embargo, si los procesos son sencillos en co­m­pa­ra­ción, no se puede pre­s­ci­n­dir de la es­tru­c­tu­ra compleja, lo que puede conllevar problemas de ra­le­n­ti­za­ción.