Base de datos objeto-relacional

Una base de datos objeto-relacional ( ORD ), o sistema de gestión de bases de datos objeto-relacional ( 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 los sistemas puramente relacionales, admite la extensión del modelo de datos con tipos de datos y métodos personalizados .

Se puede decir que una base de datos objeto-relacional ofrece un punto intermedio entre las bases de datos relacionales y las bases de datos orientadas a objetos . En las bases de datos objeto-relacionales, el enfoque es esencialmente el de las bases de datos relacionales: los datos residen en la base de datos y se manipulan colectivamente mediante consultas en un lenguaje de consulta; en el otro extremo se encuentran los sistemas de gestión de bases de datos orientadas a objetos (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 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 objeto-relacional surge del hecho de que tanto las bases de datos relacionales como las orientadas a objetos tienen sus ventajas y desventajas. El isomorfismo del sistema de base de datos relacional con una relación matemática le permite aprovechar muchas técnicas y teoremas útiles de la teoría de conjuntos. Sin embargo, 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 definidos por el usuario arbitrarios, así como objetos anidados. Esto genera una similitud entre los sistemas de tipos de aplicación y los sistemas de tipos de base de datos, lo que elimina cualquier problema de incompatibilidad . Pero las bases de datos orientadas a objetos, a diferencia de las relacionales, no proporcionan ninguna base matemática para su análisis profundo. ^{[ 2 ] [ 3 ]}

El objetivo fundamental de las bases de datos objeto-relacionales es salvar la brecha entre las bases de datos relacionales y las técnicas de modelado orientado a objetos utilizadas en lenguajes de programación como Java , C++ , Visual Basic (.NET) o C# . Sin embargo, una alternativa más popular para lograrlo es utilizar sistemas de bases de datos relacionales estándar con algún tipo de software de mapeo objeto-relacional (ORM). Mientras que los sistemas de gestión de bases de datos relacionales (RDBMS ) o SQL tradicionales se centraban en la gestión eficiente de datos provenientes de un conjunto limitado de tipos de datos (definidos por los estándares del lenguaje correspondiente), un sistema de gestión de bases de datos objeto-relacional permite a los desarrolladores de software integrar sus propios tipos y los métodos que se les aplican en el sistema.

El ORDBMS (al igual que el ODBMS o el OODBMS ) está integrado con un lenguaje de programación orientado a objetos . Las propiedades características de los 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 SQL se basa en la definición preliminar del esquema mediante el 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 objetos , está relacionada con el acceso a los objetos del programa. Dichos objetos del programa deben ser almacenables y transportables para su procesamiento en la base de datos; por lo tanto, 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 ^{[ 4 ].}

En la programación orientada a objetos (POO), el comportamiento de los objetos se describe mediante 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 asocian ( firma del método ). Los lenguajes de POO denominan a esto el principio de polimorfismo , que se define brevemente como "una interfaz, muchas implementaciones". Otros principios de POO, la herencia y la encapsulación , están relacionados tanto con los métodos como con los atributos. La herencia de métodos se incluye en la herencia de tipos. La encapsulación en POO es un grado de visibilidad declarado, por ejemplo, mediante los publicmodificadores de accesoprivate y .protected

Los sistemas de gestión de bases de datos objeto-relacionales surgieron de investigaciones realizadas a principios de la década de 1990. Dicha investigación amplió los conceptos existentes de bases de datos relacionales mediante la incorporación de conceptos de objetos . Los investigadores buscaban mantener 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 destacado, Postgres (UC Berkeley), dio origen a dos productos que se remontan 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 International Business Machines ( IBM ), Omniscience (Omniscience Corporation, adquirida por Oracle Corporation y que 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 lanzó 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) en C++ . Para 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 llegaron a referirse a estos productos como "sistemas de gestión de bases de datos objeto-relacionales" o ORDBMS. ^{[ 6 ]}

Muchas de las ideas de los primeros intentos de bases de datos objeto-relacionales se han incorporado en gran medida a SQL:1999 mediante 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 objeto-relacionales. Por ejemplo, IBM Db2 , Oracle Database y Microsoft SQL Server afirman ser compatibles con esta tecnología, con distintos grados de éxito.

Un sistema de gestión de bases de datos relacionales (RDBMS) suele incluir sentencias SQL como estas:

CREATE TABLE Customers ( Id CHAR ( 12 ) NOT NULL PRIMARY KEY , Surname VARCHAR ( 32 ) NOT NULL , FirstName VARCHAR ( 32 ) NOT NULL , DOB DATE NOT NULL # DOB: Fecha de nacimiento ); SELECT InitCap ( C . Surname ) || ', ' || InitCap ( C . FirstName ) FROM Customers C WHERE Month ( C . DOB ) = Month ( getdate ()) AND Day ( C . DOB ) = Day ( getdate ())

Más recienteLas bases de datos SQL permiten la creación de funciones personalizadas , lo que permitiría que la consulta apareciera de la siguiente manera:

SELECCIONAR Formal ( C . Id ) DE Clientes C DONDE Cumpleaños ( C . DOB ) = Hoy ()

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

CREATE TABLE Customers ( Id Cust_Id NOT NULL PRIMARY KEY , Name PersonName NOT NULL , DOB DATE NOT NULL ); SELECT Formal ( C . Id ) FROM Customers C WHERE BirthDay ( C . DOB ) = TODAY ;

El modelo objeto-relacional puede ofrecer otra ventaja, ya que la base de datos puede utilizar las relaciones entre los datos para recopilar fácilmente registros relacionados. En una aplicación de agenda de contactos , se agregaría una tabla adicional a las anteriores para almacenar cero o más direcciones para cada cliente. Utilizando un SGBD tradicional, recopilar información tanto del usuario como de su dirección requiere una "unión":

SELECT InitCap ( C . Surname ) || ', ' || InitCap ( C . FirstName ), A . city FROM Customers C JOIN Addresses A ON A . Cust_Id = C . Id -- la unión WHERE A . city = "New York"

La misma consulta en una base de datos objeto-relacional aparece de forma más sencilla:

SELECT Formal ( C . Name ) FROM Customers C WHERE C . address . city = "New York" -- el enlace es 'entendido' por ORDB

• Base de datos orientada a documentos
• SQL
• Comparación de sistemas de gestión de bases de datos objeto-relacionales
• Tipo estructurado
• Base de datos de objetos
• Mapeo objeto-relacional
• Modelo relacional
• Consulta integrada en el lenguaje
• Marco de entidades

• Savushkin, Sergey (2003), Un punto de vista sobre ORDBMS , archivado del original el 1 de marzo de 2012 , recuperado el 21 de julio de 2012..
• Evaluación comparativa del rendimiento de JPA– Comparación de productos ORM Java JPA (Hibernate, EclipseLink, OpenJPA, DataNucleus).
• Punto de referencia de PolePosition– muestra las ventajas y desventajas en el rendimiento de las soluciones en el contexto de la discrepancia de impedancia objeto-relacional .