Base de datos orientada a objetos, definición y origen

Entre los conceptos tecnológicos que nos vamos a acostumbrar a tratar dentro de este sector una base de datos orientada a objetos es uno de los que terminará convirtiéndose en el pan nuestro de cada día. ¿Pero cuál es su definición específica? Entendemos este tipo de base de datos como aquellas en las que toda la información está basada en forma de objetos, lo que permite que se combine con un lenguaje de programación específico para dar forma a los ODBMS, los gestores de bases de datos concentradas en objetos. Es importante tener en cuenta que entre los lenguajes más utilizados dentro de esta compatibilidad destacan Visual Basic.Net, Java y C++, entre otros. El gran interés existente en utilizar ODBMS viene precedido porque ofrecen un buen rendimiento, imponen niveles de inversión reducidas y cuentan con un buen margen de integración con lenguajes conocidos.

Descarga nuestra guía gratuita: Lo que debes saber si quieres estudiar informática

Un origen histórico

A inicios de la década de los años 60 se gesta el origen de este tipo de bases de datos. Ocurre en Noruega, donde el doctor Nygaard, especialista en la elaboración de sistemas informáticos que llevaban a cabo simulaciones de sistemas de naturaleza física, puso a punto esta nueva tendencia. Acostumbrado a buscar la representación informática del rendimiento de elementos físicos como el motor de un coche, Nygaard tenía ciertas necesidades que hasta ese momento nadie podía satisfacer. En su época, todavía los sesenta, había ciertos obstáculos que impedían que su trabajo pudiera llegar a buen puerto. Se encontraba con que el software del momento era excesivamente complicado y debía recurrir a modificaciones en cada una de sus operaciones. El proceso de trabajo superaba los límites de la comodidad, dado que por cada iniciativa que llevaba a cabo tenía que contemplar varias alteraciones y posibilidades que cubrían las alternativas a sus planteamientos. Todo ello hacía que el trabajo fuera demasiado absorbente y que se saliera de los límites de lo tolerable.

Esta situación hizo que el doctor Nygaard y su equipo planteasen alternativas. Así es como trabajaron en la elaboración de un software que se diseñase de forma paralela al objeto físico en cuestión. Esto suponía cambiar la forma de trabajar, pero con el objetivo de alcanzar un resultado mucho más adecuado y beneficioso. El equipo del doctor planteó un requisito clave: que el programa fuera un reflejo del objeto. Si el objeto físico en cuestión estaba formado por 50 componentes principales, el software también debería tener 50 módulos. Esto garantizaría que por cada pieza del objeto habría una contraposición en el software, todo ello visible y analizable. Y si el objeto en cuestión funcionaba bien gracias a la comunicación de sus 50 piezas, el software también lo haría a través de la comunicación de los 50 módulos y de sus componentes.

¿Qué ganó Nygaard? Se encontró con que su solución le resolvía todos los problemas. Disponía de un mantenimiento absolutamente dominado, sin sorpresas, pero al mismo tiempo también veía que ahora sus programas se podían dividir de forma lógica. De esta forma, con los posteriores análisis y pruebas el doctor podría cambiar las piezas de forma independiente y cómoda, así como hacerlo con facilidad. Así es como comenzó a realizar pruebas más fiables, específicas y de resultados precisos.

Y entonces se descubrió su potencial

Uno de los principales problemas a los que se enfrentaba Nygaard en su época se encontraba en que debía realizar procesos de trabajo largos para una tarea posterior que no simbolizaba tanta dificultad. No era tirar horas de trabajo a la basura, pero sí sentía que su tiempo se estaba desperdiciando dentro del contexto. Por eso planteó soluciones y descubrió que finalmente la orientación a objetos con la que había trabajado le resolvía este aspecto. El motivo se encontró en que pudo introducir la reusabilidad en la creación del software. A partir de este momento cada programa no representaba un inicio y final para el software, sino que en el proceso de creación muchos elementos podían recuperarse y mantenerse en activo para futuras creaciones.

Pero con este descubrimiento Nygaard necesitaba un lenguaje que le sirviera de apoyo. Así fue como nació Simula-67, lenguaje que hoy día aún se usa y que está considerado como uno de los inventos más importantes en el mundo de la informática aunque no sea algo conocido en términos populares.

Con el paso del tiempo la industria continuó el trabajo en las bases de datos orientada a objetos. Una década después el equipo de Alan Kay y Xerox tomó de referencia el trabajo de Simula-67 para crear otro lenguaje similar: Smalltalk. En los años 80 este lenguaje fue utilizado en combinación con algunas de las ideas que habían sido más características de Simula-67 para dar forma a otro lenguaje que tiene gran importancia hoy día: C++, que se ocupó de que este tipo de trabajo alcanzara sus máximos niveles de rendimiento.