Una base de datos relacional de objetos ( ORD ), o sistema de gestión de bases de datos relacionales 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 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 tipos de datos y métodos personalizados .
Se puede decir que una base de datos relacional de objetos proporciona un punto intermedio 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 las OODBMS en las 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 interfaz de programación de aplicaciones (API) 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-objeto surge del hecho de que tanto las bases de datos relacionales como las de objetos tienen sus propias ventajas y desventajas. 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 aporta puntos en común entre los sistemas de tipos de aplicación y los sistemas de tipos de bases 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. [2] [3]
El objetivo básico de las bases de datos relacionales de objetos es tender un puente entre las bases de datos relacionales y las técnicas de modelado orientadas a objetos que se utilizan en lenguajes de programación como Java , C++ , Visual Basic (.NET) o C# . Sin embargo, una alternativa más popular para lograr ese puente es utilizar sistemas de bases de datos relacionales estándar con algún tipo 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 pertinentes), un DBMS relacional de objetos permite a los desarrolladores de software integrar sus propios tipos y los métodos que se aplican a ellos 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 los 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, 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. Dichos objetos del 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 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 los métodos (funciones de objeto). Los métodos denotados 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 OOP llaman a esto el principio de polimorfismo , que se define brevemente como "una interfaz, muchas implementaciones". Otros principios de OOP, la herencia y la 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 accesopublic , privatey .protected
Los sistemas de gestión de bases de datos relacionales-objeto surgieron de investigaciones que se llevaron a cabo a principios de los años 1990. Esa investigación amplió los conceptos existentes de bases de datos relacionales al agregar conceptos de objetos . Los investigadores apuntaron a conservar un lenguaje de consulta declarativo basado en el cálculo de predicados como un componente central de la arquitectura. Probablemente el proyecto de investigación más notable, Postgres (UC Berkeley), generó dos productos que rastrean su linaje a esa investigación: Illustra y PostgreSQL .
A mediados de la década de 1990, aparecieron los primeros productos comerciales. Estos incluyeron Illustra [5] (Illustra Information Systems, adquirida por Informix Software , que a su vez fue adquirida por International Business Machines ( IBM ), Omniscience (Omniscience Corporation, adquirida por Oracle Corporation y se convirtió en el Oracle Lite original) y UniSQL (UniSQL, Inc., adquirida por KCOM Group ). 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 kit de desarrollo de software (SDK) de C++ . En la década siguiente, 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 científicos informáticos comenzaron a denominar a estos productos "sistemas de gestión de bases de datos relacionales de objetos" u ORDBMS. [6]
Muchas de las ideas de los primeros intentos 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 gestión de bases de datos relacionales de objetos. Por ejemplo, IBM Db2 , Oracle Database y Microsoft SQL Server afirman que admiten esta tecnología y lo hacen con distintos grados de éxito.
Un RDBMS comúnmente podría involucrar instrucciones SQL como estas:
CREAR TABLA Clientes ( Id CHAR ( 12 ) NOT NULL CLAVE PRINCIPAL , Apellido VARCHAR ( 32 ) NOT NULL , Nombre VARCHAR ( 32 ) NOT NULL , DOB FECHA NOT NULL # DOB: Fecha de nacimiento ); SELECT InitCap ( C . Apellido ) || ', ' || InitCap ( C . Nombre ) FROM Clientes C WHERE Mes ( C . DOB ) = Mes ( getdate ()) AND 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:
SELECCIONAR 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 y expresiones definidos por el usuario como BirthDay():
CREAR TABLA Clientes ( Id Cust_Id NO NULL CLAVE PRINCIPAL , Nombre PersonName NO NULL , DOB FECHA NO NULL ); SELECCIONAR Formal ( C . Id ) DE Clientes C DONDE BirthdayDay ( C . DOB ) = TODAY ; El modelo relacional de objetos puede ofrecer otra ventaja, ya 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 almacenar cero o más direcciones para cada cliente. Si se utiliza un RDBMS tradicional, la recopilación de información tanto del usuario como de su dirección requiere una "unión":
SELECT InitCap ( C.Surname ) || ' , ' || InitCap ( C.FirstName ) , A.city FROM Clientes C JOIN Direcciones A ON A.Cust_Id = C.Id -- la unión WHERE A.city = " Nueva York " La misma consulta en una base de datos relacional de objetos parece más sencilla:
SELECT Formal ( C . Nombre ) FROM Clientes C WHERE C . dirección . ciudad = "Nueva York" -- el enlace es "comprendido" por ORDB 