Una base de datos relacional de objetos ( ORD ), o un sistema de gestión de bases 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 están directamente relacionados. soportado en esquemas de bases 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 tipos y métodos de datos personalizados .
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 persistente 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.
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 este tipo de bases de datos no son óptimas 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 y objetos anidados. Esto aporta elementos comunes entre los sistemas de tipo aplicación y los sistemas de tipo base de datos, lo que elimina cualquier problema de discrepancia 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. [2] [3]
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 utilizar sistemas de bases de datos relacionales estándar con algún tipo de software de mapeo objeto-relacional (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 pertinentes), un DBMS relacional de objetos permite a los desarrolladores de software integrar sus propios tipos y métodos que aplicarles 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 mediante el tipo definido por el usuario (UDT). La jerarquía dentro de datos estructurados complejos ofrece una propiedad adicional, la herencia de tipos . Es decir, un tipo estructurado puede tener subtipos que reutilizan todos sus atributos y contienen atributos adicionales específicos del subtipo. Otra ventaja, el comportamiento de los objetos , está relacionada con el acceso a los objetos del programa. Estos objetos de programa deben poder almacenarse y transportarse para el procesamiento de la base de datos, por lo que normalmente 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 se pueden abordar en un sistema relacional adecuado, aunque el estándar SQL y sus implementaciones imponen restricciones arbitrarias y complejidad adicional [4] [ página necesaria ]
En la programación orientada a objetos (POO) , el comportamiento de los objetos se describe a través de 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 adjuntan ( firma del método ). Los lenguajes OOP llaman a esto principio de polimorfismo , que brevemente se define como "una interfaz, muchas implementaciones". Otros principios de programación orientada a objetos, herencia y encapsulación , están relacionados tanto con métodos como con atributos. La herencia de métodos se incluye en la herencia de tipos. La encapsulación en programación orientada a objetos es un grado de visibilidad declarado, por ejemplo, a través de los publicmodificadores de accesoprivate y .protected
Los sistemas de gestión de bases de datos relacionales de objetos surgieron de una investigación que tuvo lugar a principios de los años noventa. Esa investigación amplió los conceptos existentes de bases de datos relacionales agregando conceptos de objetos . Los investigadores pretendían 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 remontan su linaje a esa investigación: Illustra y PostgreSQL .
A mediados de la década de 1990 aparecieron los primeros productos comerciales. Estos incluían Illustra [5] (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., adquirido 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 siguiente 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 características ORDBMS.
Los informáticos llegaron a referirse a estos productos como "sistemas de gestión de bases de datos relacionales de objetos" u ORDBMS. [6]
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 cumpla con los aspectos orientados a objetos de SQL:1999 podría describirse como un producto de gestión de bases de datos relacionales de objetos. Por ejemplo, IBM Db2 , la base de datos Oracle y Microsoft SQL Server afirman ser compatibles con esta tecnología y lo hacen con distintos grados de éxito.
Un RDBMS normalmente puede incluir declaraciones SQL como estas:
CREAR TABLA Clientes ( Id CHAR ( 12 ) NOT NULL CLAVE PRIMARIA , Apellido VARCHAR ( 32 ) NOT NULL , Nombre VARCHAR ( 32 ) NOT NULL , FECHA DE NACIMIENTO NO NULL # DOB: Fecha de nacimiento ); SELECCIONE InitCap ( C . Apellido ) || ',' || InitCap ( C . FirstName ) DE Clientes C DONDE Mes ( C . DOB ) = Mes ( getdate ()) Y Día ( C . DOB ) = Día ( getdate ()) La mayoría de las bases de datos SQL actuales permiten la creación de funciones[actualizar] personalizadas , lo que permitiría que la consulta aparezca como:
SELECCIONE Formal ( C . Id ) DE Clientes C DONDE Cumpleaños ( C . DOB ) = Hoy () En una base de datos relacional de objetos, se podría ver algo como esto, con tipos de datos definidos por el usuario y expresiones como BirthDay():
CREAR TABLA Clientes ( Id Cust_Id NOT NULL PRIMARY KEY , Name PersonName NOT NULL , DOB DATE NOT NULL ); SELECCIONE Formal ( C. Id ) DE Clientes C DONDE Día de nacimiento ( C. DOB ) = HOY ; El modelo relacional de objetos puede ofrecer otra ventaja, ya que la base de datos puede utilizar las relaciones entre 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. Al utilizar un RDBMS tradicional, recopilar información tanto para el usuario como para su dirección requiere una "unión":
SELECCIONE InitCap ( C . Apellido ) || ',' || InitCap ( C . Nombre ), A . ciudad DESDE Clientes C UNIRSE Direcciones A ON A . Id_cliente = C . Id : la unión DONDE A. ciudad = "Nueva York" La misma consulta en una base de datos relacional de objetos aparece de manera más simple:
SELECCIONE Formal ( C. Nombre ) DE Clientes C DONDE C. DIRECCIÓN . ciudad = "Nueva York" - el vínculo es "entendido" por el ORDB 