Base de datos relacional de objetos

Una base de datos relacional de objetos (ORD), o sistema de gestión de base de datos relacional de objetos (ORDBMS), es un sistema de gestión de bases de datos (DBMS) similar a una base de datos relacional, pero con un modelo de base de datos orientado a objetos: los objetos, las clases y la herencia se admiten directamente en los esquemas de la base de datos y en el lenguaje de consulta. Además, al igual que con los sistemas relacionales puros, admite la extensión del modelo de datos con métodos y tipos de datos personalizados.

Ejemplo de un modelo de base de datos orientado a objetos

Se puede decir que una base de datos relacional de objetos proporciona un término medio entre las bases de datos relacionales y las bases de datos orientadas a objetos. En las bases de datos relacionales de objetos, el enfoque es esencialmente el de las bases de datos relacionales: los datos residen en la base de datos y se manipulan colectivamente con consultas en un lenguaje de consulta; en el otro extremo están los OODBMS en los que la base de datos es esencialmente un almacén de objetos persistentes para software escrito en un lenguaje de programación orientado a objetos, con una API de programación para almacenar y recuperar objetos, y poco o ningún soporte específico para consultas.

Resumen

La necesidad básica de una base de datos relacional de objetos surge del hecho de que tanto la base de datos relacional como la de objetos tienen sus ventajas y desventajas individuales. El isomorfismo del sistema de base de datos relacional con una relación matemática le permite explotar muchas técnicas y teoremas útiles de la teoría de conjuntos. Pero estos tipos de bases de datos no son óptimos para ciertos tipos de aplicaciones. Un modelo de base de datos orientado a objetos permite contenedores como conjuntos y listas, tipos de datos arbitrarios definidos por el usuario, así como objetos anidados. Esto trae elementos comunes entre los sistemas de tipo de aplicación y los sistemas de tipo de base de datos, lo que elimina cualquier problema de desajuste de impedancia. Pero las bases de datos de objetos, a diferencia de las relacionales, no proporcionan ninguna base matemática para su análisis profundo.

El objetivo básico de la base de datos relacional de objetos es cerrar la brecha entre las bases de datos relacionales y las técnicas de modelado orientadas a objetos utilizadas en lenguajes de programación como Java, C++, Visual Basic.NET o C#. Sin embargo, una alternativa más popular para lograr dicho puente es usar un sistema de base de datos relacional estándar con alguna forma de software de mapeo relacional de objetos (ORM). Mientras que los productos RDBMS o SQL-DBMS tradicionales se centraban en la gestión eficiente de datos extraídos de un conjunto limitado de tipos de datos (definidos por los estándares de lenguaje relevantes), un DBMS relacional de objetos permite a los desarrolladores de software integrar sus propios tipos y los métodos que aplicarlos en el DBMS.

El ORDBMS (como ODBMS o OODBMS) está integrado con un lenguaje de programación orientado a objetos. Las propiedades características de ORDBMS son 1) datos complejos, 2) herencia de tipos y 3) comportamiento de objetos. La creación de datos complejos en la mayoría de los ORDBMS de SQL se basa en la definición preliminar del esquema a través del tipo definido por el usuario (UDT). La jerarquía dentro de los datos complejos estructurados ofrece una propiedad adicional, herencia de tipo. Es decir, un tipo estructurado puede tener subtipos que reutilicen todos sus atributos y contengan atributos adicionales específicos del subtipo. Otra ventaja, el comportamiento de los objetos, está relacionada con el acceso a los objetos del programa. Dichos objetos de programa deben ser almacenables y transportables para el procesamiento de la base de datos, por lo que generalmente se denominan objetos persistentes. Dentro de una base de datos, todas las relaciones con un objeto de programa persistente son relaciones con su identificador de objeto (OID). Todos estos puntos pueden abordarse en un sistema relacional adecuado, aunque el estándar SQL y sus implementaciones imponen restricciones arbitrarias y complejidad adicional.

En la programación orientada a objetos (POO), el comportamiento de los objetos se describe a través de los métodos (funciones de objetos). Los métodos indicados por un nombre se distinguen por el tipo de sus parámetros y el tipo de objetos a los que se adjuntan (firma del método). Los lenguajes de programación orientada a objetos llaman a esto el principio del polimorfismo, que se define brevemente como "una interfaz, muchas implementaciones". Otros principios de programación orientada a objetos, herencia y encapsulación, están relacionados tanto con los métodos como con los atributos. La herencia de métodos está incluida en la herencia de tipos. La encapsulación en OOP es un grado de visibilidad declarado, por ejemplo, a través de los modificadores de acceso public, private y protected.

Historia

Los sistemas de administración de bases de datos relacionales de objetos surgieron de una investigación que se llevó a cabo a principios de la década de 1990. Esa investigación amplió los conceptos de bases de datos relacionales existentes al agregar conceptos de objetos. Los investigadores intentaron conservar un lenguaje de consulta declarativo basado en el cálculo de predicados como componente central de la arquitectura. Probablemente el proyecto de investigación más notable, Postgres (UC Berkeley), generó dos productos que rastrean su linaje hasta esa investigación: Illustra y PostgreSQL.

A mediados de la década de 1990, aparecieron los primeros productos comerciales. Estos incluían Illustra (Illustra Information Systems, adquirida por Informix Software, que a su vez fue adquirida por IBM), Omniscience (Omniscience Corporation, adquirida por Oracle Corporation y se convirtió en el Oracle Lite original) y UniSQL (UniSQL, Inc., adquirida por KCOMS). El desarrollador ucraniano Ruslan Zasukhin, fundador de Paradigma Software, Inc., desarrolló y envió la primera versión de la base de datos Valentina a mediados de la década de 1990 como un SDK de C++. En la próxima década, PostgreSQL se había convertido en una base de datos comercialmente viable y es la base de varios productos actuales que mantienen sus funciones ORDBMS.

Los informáticos llegaron a referirse a estos productos como "sistemas de gestión de bases de datos relacionales de objetos" o ORDBMS.

Muchas de las ideas de los primeros esfuerzos de bases de datos relacionales de objetos se han incorporado en gran medida a SQL: 1999 a través de tipos estructurados. De hecho, cualquier producto que se adhiera a los aspectos orientados a objetos de SQL:1999 podría describirse como un producto de administración de base de datos relacional de objetos. Por ejemplo, IBM Db2, la base de datos Oracle y Microsoft SQL Server afirman admitir esta tecnología y lo hacen con diversos grados de éxito.

Comparación con RDBMS

Un RDBMS comúnmente puede incluir instrucciones SQL como estas:

 CREATE CUADRO Clientes () Id CHAR()12) NO NULL PRIMARÍA KEY, Apellido VARCHAR()32) NO NULL, FirstName VARCHAR()32) NO NULL, DOB Fecha NO NULL # DOB: Fecha de nacimiento ); SELECT InitCap()Apellido) Silencio ', ' Silencio InitCap()FirstName) DESDE Clientes Donde Mes()DOB) = Mes()Fecha()) Y Día()DOB) = Día()Fecha())

La mayoría de las bases de datos SQL actuales permiten la creación de funciones personalizadas, lo que permitiría que la consulta apareciera como:

 SELECT Formal()Id) DESDE Clientes Donde Cumpleaños()DOB) = Hoy()

En una base de datos relacional de objetos, uno podría ver algo como esto, con tipos de datos definidos por el usuario y expresiones como BirthDay():

 CREATE CUADRO Clientes () Id Cust_Id NO NULL PRIMARÍA KEY, Nombre PersonName NO NULL, DOB Fecha NO NULL ); SELECT Formal() C.Id ) DESDE Clientes C Donde Nacimiento () C.DOB ) = TODAY;

El modelo relacional de objetos puede ofrecer otra ventaja en el sentido de que la base de datos puede hacer uso de las relaciones entre los datos para recopilar fácilmente registros relacionados. En una aplicación de libreta de direcciones, se agregaría una tabla adicional a las anteriores para contener cero o más direcciones para cada cliente. Usando un RDBMS tradicional, recopilar información tanto para el usuario como para su dirección requiere "unirse":

 SELECT InitCap()C.Apellido) Silencio ', ' Silencio InitCap()C.FirstName), A.ciudad DESDE Clientes C Únase Addresses A ON A.Cust_Id=C.Id - La unión Donde A.ciudad="Nueva York"

La misma consulta en una base de datos relacional de objetos parece más sencilla:

 SELECT Formal() C.Nombre ) DESDE Clientes C Donde C.dirección.ciudad="Nueva York" -- el enlace es 'comprendido' por el ORDB