Última actualización: 2026-11-02

Contenido de esta página

• ¿Qué significa BDOO?
• Modelo de datos orientado a objetos: los conceptos aplicados al almacenamiento
• El desajuste objeto-relacional: la razón de ser de las BDOO
• El estándar ODMG 3.0 y el lenguaje de consulta OQL
• ¿Por qué no se impusieron las bases de datos orientadas a objetos?
• Ejemplos de bases de datos orientadas a objetos que siguen vivas
• Base de datos objeto-relacional: la vía que ganó
• Ventajas y desventajas de las bases de datos orientadas a objetos
• ¿Cuándo tiene sentido hoy una base de datos orientada a objetos?

Historia real. Entre el 4 y el 6 de diciembre de 1989, en el parque de investigación de Kioto, Japón, se reunió la primera conferencia internacional sobre bases de datos deductivas y orientadas a objetos [1]. Entre los trabajos invitados había uno con un título poco académico: The Object-Oriented Database System Manifesto, el manifiesto de los sistemas de bases de datos orientados a objetos [1].

Lo firmaban seis autores, con afiliaciones en las universidades de Glasgow, Wisconsin, Zúrich y Brown, además de otras dos instituciones [2]. Escribieron sus reglas como mandamientos. Uno de ellos dice, en inglés antiguo, «Thou shalt remember thy data»: recordarás tus datos [2]. Las citas en otro idioma de esta página son traducción propia.

Los autores temían algo concreto. En el campo de la computación, advertían, un producto temprano suele volverse el estándar de hecho y no desaparece nunca. Entre sus ejemplos pusieron a SQL, el lenguaje con el que se consultan las bases de datos relacionales [2]. Su última regla pedía cuestionar todas las anteriores [2].

Treinta y siete años después, SQL sigue ahí. Las bases de objetos, no tanto. Esta página explica qué proponía ese manifiesto, por qué la idea tenía sentido y dónde terminó.

¿Qué significa BDOO?

BDOO significa base de datos orientada a objetos. Es un sistema que guarda los objetos de un programa tal como el programa los usa: cada uno con sus datos, sus operaciones y sus vínculos con otros objetos. El programador no tiene que convertirlos en filas de una tabla para guardarlos ni volver a armarlos al leerlos.

El manifiesto de 1989 puso la vara alta. Exigió trece rasgos obligatorios: ocho para ser un sistema orientado a objetos y cinco para ser, además, una base de datos de verdad [2]. Entre los cinco de base de datos está la persistencia, es decir, que los datos sobrevivan cuando el programa se cierra [2]. También el trabajo de varios usuarios a la vez, la recuperación tras una falla y una forma sencilla de hacer consultas [2].

En la clasificación general de las bases de datos por modelo, esta es una casilla entre muchas. El mapa completo está en tipos de bases de datos.

Modelo de datos orientado a objetos: los conceptos aplicados al almacenamiento

El modelo de datos orientado a objetos organiza la información en objetos agrupados por clases, en lugar de tablas. Una clase es el molde: dice qué datos tiene un objeto y qué operaciones admite. Cada objeto es un caso concreto de ese molde. La tabla resume cómo cambia cada concepto cuando el objetivo ya no es solo programar, sino guardar.

Concepto	Qué significa al guardar datos	Ejemplo	Cómo lo resuelve una base relacional
Objeto complejo	Un objeto se arma con listas, conjuntos y otros objetos, combinables entre sí [2]	Una mascota con su lista de controles de peso	Una tabla por cada nivel, unidas por claves
Identidad	El objeto existe aparte de su valor: dos objetos pueden ser iguales sin ser el mismo [2]	Dos mascotas con la misma dueña	Un número identificador que alguien debe asignar y cuidar [2]
Encapsulamiento	El objeto guarda juntos sus datos y sus operaciones; desde afuera solo se ven las operaciones [2]	Un empleado que sabe «subir sueldo»	Los programas viven fuera de la base, en archivos aparte [2]
Clase o tipo	El conjunto de clases reemplaza al esquema clásico de la base [2]	La clase Mascota	El esquema de tablas y columnas
Herencia	Una clase hereda datos y operaciones de otra más general [2]	Empleado y Estudiante heredan de Persona	Una tabla por clase, con las operaciones comunes escritas dos veces [2]
Polimorfismo	Una misma operación hace cosas distintas según el tipo del objeto, y el sistema elige cuál al ejecutarse [2]	«Mostrar» dibuja un gráfico o imprime una ficha	Un programa que pregunta por el tipo de cada dato y elige la operación [2]

La identidad merece un ejemplo, porque es la que el código de más abajo pierde en el camino. El manifiesto plantea a dos padres, cada uno con un hijo de 15 años del mismo nombre [2]. Sin identidad no hay forma de saber si es el mismo niño o son dos. Con identidad, si es el mismo niño, ambos padres apuntan al mismo objeto, y un cambio en el hijo se ve desde los dos lados [2].

La herencia ahorra trabajo medible. En el ejemplo del manifiesto, un diseño relacional exige seis programas para empleados y estudiantes; con una clase común Persona bastan cuatro [2].

El desajuste objeto-relacional: la razón de ser de las BDOO

El desajuste objeto-relacional, que en inglés se llama impedance mismatch, es la fricción de traducir objetos a tablas y de vuelta. Los programas piensan en objetos anidados; las bases relacionales, en filas planas. Cada vez que un dato cruza esa frontera, alguien tiene que desarmarlo y volverlo a armar.

Michael Stonebraker y Joseph Hellerstein, dos investigadores de bases de datos, lo describieron en 2005 con una imagen doméstica. Conectar una aplicación con una base relacional exigía pasar del idioma del programa al de la base y regresar. Era, escribieron, como «pegar una manzana sobre un panqueque» [3]. Las bases de objetos se propusieron quitar ese paso [3].

Ejemplo del desajuste con clases en Python y SQLite

El siguiente ejemplo, con una veterinaria ficticia, muestra el problema en pequeño. Usa Python y sqlite3, el módulo de su biblioteca estándar para trabajar con SQLite, un motor de bases de datos que guarda todo en un archivo [17]. Lo corrí con Python 3.11 y SQLite 3.53.1.

import sqlite3
from dataclasses import dataclass, field

# 1. El mundo de los objetos: un propietario compartido y controles anidados
@dataclass
class Propietario:
    nombre: str
    telefono: str

@dataclass
class Control:
    mes: str
    peso: float

@dataclass
class Mascota:
    nombre: str
    propietario: Propietario
    controles: list[Control] = field(default_factory=list)

    def promedio(self):
        return round(sum(c.peso for c in self.controles) / len(self.controles), 2)

duena = Propietario("Luz Pérez", "300 000 0000")
luna = Mascota("Luna", duena, [Control("enero", 4.5), Control("febrero", 3.8)])
max_ = Mascota("Max", duena, [Control("enero", 3.9)])

# Luna y Max apuntan al MISMO objeto propietario (identidad, no copia)
print("¿Mismo propietario?", luna.propietario is max_.propietario)

# 2. El mundo de las tablas: hay que partir cada objeto en filas
con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE propietario (id INTEGER PRIMARY KEY, nombre TEXT, telefono TEXT);
CREATE TABLE mascota (id INTEGER PRIMARY KEY, nombre TEXT,
                      propietario_id INTEGER REFERENCES propietario(id));
CREATE TABLE control (mascota_id INTEGER REFERENCES mascota(id),
                      mes TEXT, peso REAL);
""")

# La identidad del objeto se vuelve un número que alguien debe asignar
cur = con.execute("INSERT INTO propietario (nombre, telefono) VALUES (?, ?)",
                  (duena.nombre, duena.telefono))
id_duena = cur.lastrowid
for m in (luna, max_):
    cur = con.execute("INSERT INTO mascota (nombre, propietario_id) VALUES (?, ?)",
                      (m.nombre, id_duena))
    id_mas = cur.lastrowid
    for c in m.controles:
        con.execute("INSERT INTO control VALUES (?, ?, ?)", (id_mas, c.mes, c.peso))

# 3. De vuelta: una consulta con uniones y un bucle para rearmar los objetos
filas = con.execute("""
SELECT m.nombre, p.nombre, p.telefono, c.mes, c.peso
FROM mascota m
JOIN propietario p ON p.id = m.propietario_id
JOIN control c ON c.mascota_id = m.id
ORDER BY m.id
""").fetchall()
print("Filas planas:", len(filas))

rearmados = {}
for nom_m, nom_p, tel, mes, peso in filas:
    mas = rearmados.setdefault(nom_m, Mascota(nom_m, Propietario(nom_p, tel)))
    mas.controles.append(Control(mes, peso))

luna2, max2 = rearmados["Luna"], rearmados["Max"]
print("Peso promedio de Luna:", luna2.promedio())
print("¿Mismo propietario tras rearmar?", luna2.propietario is max2.propietario)

La salida fue esta:

¿Mismo propietario? True
Filas planas: 3
Peso promedio de Luna: 4.15
¿Mismo propietario tras rearmar? False

Dos mascotas, su dueña y tres controles de peso se volvieron tres tablas, tres filas planas al consultarlas y un bucle para reconstruirlos. Y algo se perdió en el viaje. Al rearmarlas, Luna y Max quedaron con dos copias de su dueña, no con la misma persona. Si una copia cambia de teléfono, la otra no se entera. Es el problema de los dos padres del manifiesto, reproducido en una veterinaria de juguete.

Ejemplo de base de datos orientada a objetos, en miniatura

Python trae un módulo que deja ver la idea contraria. Se llama shelve y guarda objetos casi arbitrarios en un archivo, como si fuera un diccionario que no se borra al cerrar el programa [17].

import shelve
from dataclasses import dataclass, field

@dataclass
class Propietario:
    nombre: str
    telefono: str

@dataclass
class Control:
    mes: str
    peso: float

@dataclass
class Mascota:
    nombre: str
    propietario: Propietario
    controles: list[Control] = field(default_factory=list)

duena = Propietario("Luz Pérez", "300 000 0000")
pacientes = [Mascota("Luna", duena, [Control("enero", 4.5)]),
             Mascota("Max", duena, [Control("enero", 3.9)])]

# Se guarda el grafo de objetos tal cual, bajo UNA sola clave
with shelve.open("veterinaria") as bd:
    bd["pacientes"] = pacientes

# Otro momento, otro proceso: se abre y se recupera el mismo grafo
with shelve.open("veterinaria") as bd:
    luna, max_ = bd["pacientes"]

print(luna.controles[0])
print("¿Mismo propietario?", luna.propietario is max_.propietario)

Salida:

Control(mes='enero', peso=4.5)
¿Mismo propietario? True

No hubo tablas, ni claves, ni bucle de reconstrucción, y la dueña sigue siendo una sola. Eso es lo que prometía una BDOO. Ocurre porque toda la lista de pacientes se guardó bajo una sola clave: si cada mascota va en una clave distinta, la identidad compartida se pierde. Ojo con la escala, eso sí: shelve no es una base de datos orientada a objetos. No ofrece consultas, ni trabajo simultáneo de varios usuarios, ni recuperación ante fallas, que el manifiesto exigía [2]. Y su documentación advierte que abrir un archivo de origen desconocido puede ejecutar código arbitrario [17].

El estándar ODMG 3.0 y el lenguaje de consulta OQL

El ODMG (Object Data Management Group, grupo de gestión de datos de objetos) intentó dar a las bases de objetos un estándar común, como SQL lo era para las relacionales. Entre sus miembros con voto había fabricantes como O2 Technology y Objectivity [5]. Su meta declarada era que un programa pudiera correr sobre más de un producto [5]. La versión 3.0 salió en 2000, en un libro de la editorial Morgan Kaufmann [6].

Su pieza más conocida es OQL, sigla en inglés de lenguaje de consulta de objetos. El propio estándar lo describe como «muy cercano a SQL 92», con extensiones para objetos complejos, identidad, rutas entre objetos y polimorfismo [5]. Dos diferencias pesan:

1. No modifica datos directamente. OQL no trae órdenes para actualizar; llama a las operaciones definidas en cada objeto, para no romper el encapsulamiento [5].
2. Se usa desde el lenguaje del programa. El estándar definía conexiones con tres lenguajes de programación, C++, Smalltalk y Java, y OQL podía invocarse desde cualquiera de ellos [5].

La versión 3.0 amplió el alcance hacia las herramientas que guardan objetos en bases relacionales [6]. El grupo, según el sitio que conserva sus textos, cambió su carta de fundación y pasó a definir una interfaz de almacenamiento de objetos que funciona con cualquier gestor [5]. El estándar de las bases de objetos terminó hablando también con las tablas.

¿Por qué no se impusieron las bases de datos orientadas a objetos?

Stonebraker y Hellerstein dieron su explicación en 2005, y la presentaron como opinión. Según ellos, todas las empresas de bases de objetos habían fracasado o se habían dedicado a otra cosa [3]. Apuntaron sobre todo al mercado de diseño de ingeniería, como los programas de dibujo técnico, que nunca creció lo suficiente [3]. Sus cuatro razones:

1. Poco valor percibido. Ahorraban al cliente escribir los programas que cargan y descargan objetos, un servicio por el que no estaba dispuesto a pagar mucho [3].
2. Sin estándares. Los productos de cada proveedor eran incompatibles entre sí [3].
3. Recompilar todo. Si cambiaba una operación sobre datos guardados, había que volver a enlazar todos los programas que la usaban [3].
4. Un solo lenguaje. Las bases se ataban a C++; una aplicación escrita en otro lenguaje no podía leer esos datos [3].

Su lección es breve: los programas no se venden si el usuario no tiene un dolor grave [3]. En 2024, Stonebraker y Andrew Pavlo recordaron la conclusión de aquel trabajo. El modelo relacional con un sistema de tipos ampliable, es decir, el objeto-relacional, ha dominado a todos sus rivales [4].

Ejemplos de bases de datos orientadas a objetos que siguen vivas

Las bases de objetos no desaparecieron: se quedaron en nichos. Este es el estado de cinco productos, revisado en las páginas oficiales de cada fabricante el 2 de noviembre de 2026.

Producto	Estado según su fabricante	Qué ofrece
ObjectDB	Versión 2.9.5, publicada el 2 de marzo de 2026 [14]	Base de objetos para Java que usa JPA, la interfaz estándar de Java para guardar objetos [14]
Actian NoSQL Database	Antes se llamaba Versant Object Database [15]	Transacciones para modelos de objetos muy complejos, sin código de traducción a tablas [15]
Actian NoSQL FastObjects	Antes se llamaba Versant FastObjects [15]	Guarda los objetos directamente y deduce el esquema de las clases del programa [15]
InterSystems IRIS	Plataforma vigente del fabricante [16]	Varios modelos sobre los mismos datos, con acceso por objetos y por SQL [16]
InterSystems Caché	Producto maduro, sin desarrollo nuevo salvo versiones de mantenimiento [16]	La plataforma anterior de la empresa, que hoy invita a migrar a IRIS [16]

Versant fue una de las empresas emergentes que, según Stonebraker y Hellerstein, empujaron las bases de objetos en los ochenta [3]. Una base llamada Versant Object Database sigue en el mercado, con otro nombre [15]. ObjectDB, por su parte, sostiene en su página que convertir objetos de Java a filas de tablas es lento [14]. Es la tesis del desajuste, dicha por quien vende la alternativa.

Falta db4o, otra base de objetos que suele aparecer en los programas de clase. Su dominio, db4o.com, no respondía al cierre de esta página, así que aquí no se afirma si sigue viva.

Base de datos objeto-relacional: la vía que ganó

Una base de datos objeto-relacional conserva las tablas y SQL, pero deja que el usuario cree sus propios tipos de datos, tipos con estructura interna y relaciones de herencia. PostgreSQL, el motor de código abierto que nació en un proyecto de la Universidad de California en Berkeley, se presenta así: como un sistema de bases de datos objeto-relacional [7]. Cómo llegó esa idea a los motores relacionales lo cuenta la historia de las bases de datos.

Recurso en PostgreSQL 18	Qué rasgo de los objetos imita	Límite que declara su manual
Tipo compuesto	Objeto complejo: una columna puede guardar un registro con varios campos [8]	Al declararlo, hoy no admite restricciones, como «no nulo» [8]
Herencia de tablas	Herencia: una tabla hija recibe todas las columnas de la madre [9]	«Una limitación seria»: los índices y las claves foráneas solo valen para una tabla, no para sus hijas [9]
Columna jsonb	Objetos anidados de forma libre, en JSON, un formato de texto para datos [10]	Recomienda que los documentos conserven una estructura más o menos fija [10]

El manual hace una aclaración que vale citar. La norma de SQL, desde su versión de 1999, define su propia herencia de tipos, y esa herencia difiere en muchos aspectos de la de PostgreSQL [9].

En esta página solo publico código que ejecuté; los ejemplos de PostgreSQL se leen completos en su manual oficial [8] [9] [10]. Quien venga de una base de datos relacional reconocerá todo lo demás: tablas, claves y SQL.

Los ORM: SQLAlchemy, Django y Hibernate

Un ORM, sigla en inglés de mapeo objeto-relacional, es una librería que hace automáticamente la traducción entre clases y tablas. Es la otra mitad de la victoria relacional: en vez de cambiar la base, se pone un traductor en el programa.

• SQLAlchemy se define como el kit de herramientas de SQL y mapeador objeto-relacional de Python; su serie actual es la 2.1 [11].
• Django, un marco para hacer sitios web en Python, dice que en general cada modelo, es decir, cada clase, corresponde a una sola tabla [12].
• Hibernate, para Java, cuenta que su adopción empezó entre programadores que buscaban salir del pantano del código de traducción escrito a mano [13].

El traductor no borra el desajuste; lo esconde. Stonebraker y Pavlo nombran el problema «N+1» como propio de los ORM: varias consultas para traer los datos relacionados con un solo objeto [4].

Ventajas y desventajas de las bases de datos orientadas a objetos

Las ventajas de una BDOO salen directo del modelo; las desventajas, de su historia comercial. Las ventajas de la programación orientada a objetos como estilo de programar son otro tema, que se aprende con lenguajes como Python.

Ventajas	Desventajas
Sin traducción entre objetos y tablas: lo que el programa usa es lo que se guarda [2] [3]	Un estándar que cambió de rumbo: el ODMG pasó a una interfaz para cualquier gestor [5]
La identidad se conserva: un objeto compartido sigue siendo uno [2]	En su época, atadas a un lenguaje: otra aplicación no podía leer los datos [3]
Herencia y polimorfismo dentro de la base, con menos código repetido [2]	Las primeras ofrecían transacciones y consultas débiles, según Stonebraker y Hellerstein [3]
Buen desempeño en objetos grandes que se abren y se procesan largo rato [3]	Sin protección de los datos frente a la aplicación, porque corrían en su mismo espacio de memoria [3]

¿Cuándo tiene sentido hoy una base de datos orientada a objetos?

Tiene sentido cuando el modelo de objetos es muy complejo, vive en un solo lenguaje y el costo de traducirlo a tablas se nota todos los días. Es el terreno que ObjectDB y Actian describen en sus propias páginas [14] [15]. Para casi todo lo demás, el camino corto es una base relacional con un ORM, o con columnas jsonb donde los datos cambian de forma.

Mi posición, y es opinión: para un analista de datos en Colombia, aprender una BDOO como herramienta de trabajo rinde poco. Aprender el desajuste rinde mucho. Explica por qué existen los ORM, por qué el código que mezcla clases y SQL se vuelve lento y por qué PostgreSQL acepta tipos propios.

Los firmantes de Kioto pidieron cuestionar sus propias reglas. El mercado lo hizo por ellos, y se quedó con lo mejor de su propuesta.

Preguntas frecuentes

¿Cuál es la diferencia entre una base de datos orientada a objetos y una relacional?

La relacional guarda filas en tablas y une la información por medio de claves. La orientada a objetos guarda objetos con identidad propia, que pueden contener otros objetos y traer sus operaciones. En la primera, los programas viven aparte de los datos; en la segunda, datos y operaciones van juntos [2].

¿PostgreSQL es una base de datos orientada a objetos?

No en el sentido del manifiesto de 1989. Es una base relacional que su propio sitio presenta como objeto-relacional [7]. Admite tipos compuestos y herencia entre tablas, pero se consulta con SQL y guarda filas [8] [9].

¿Un ORM convierte una base relacional en una base de objetos?

No. El ORM traduce en el programa; la base sigue guardando tablas. Por eso persisten costos como el de las consultas «N+1», que Stonebraker y Pavlo asocian a los ORM [4].

¿MongoDB es una base de datos orientada a objetos?

Stonebraker y Pavlo sostienen que las bases de documentos, cuyo ejemplo más popular según ellos es MongoDB, son en esencia lo mismo que las de objetos de los años ochenta [4]. Según ellos, también repiten el argumento del desajuste [4]. Es su tesis, no un dato medido.

¿Qué hace el módulo shelve de Python si no es una base de datos?

Guarda objetos de Python en un archivo, bajo una clave de texto, para recuperarlos en otra ejecución [17]. Sirve para prototipos y scripts personales. No debe abrir archivos de terceros, porque cargarlos puede ejecutar código [17].

Referencias

1. Kim, W., Nicolas, J.-M. y Nishio, S. (eds.). Deductive and Object-Oriented Databases. Proceedings of the First International Conference on Deductive and Object-Oriented Databases (DOOD89), Elsevier (ficha del libro) — conferencia en el Kyoto Research Park, Kioto, Japón, del 4 al 6 de diciembre de 1989; el manifiesto de Atkinson, Bancilhon, DeWitt, Dittrich, Maier y Zdonik figura entre los trabajos invitados. Elsevier: ficha de Deductive and Object-Oriented Databases — Consultada: 2026-11-02.
2. Atkinson, Malcolm; Bancilhon, François; DeWitt, David; Dittrich, Klaus; Maier, David y Zdonik, Stanley. The Object-Oriented Database System Manifesto (1989; versión HTML alojada en la Universidad Carnegie Mellon) — afiliaciones (Glasgow, Altaïr, Wisconsin, Zúrich, Oregon Graduate Center, Brown); trece rasgos obligatorios (ocho de orientación a objetos y cinco de gestor de bases de datos); «Thou shalt remember thy data»; un producto temprano se vuelve estándar de hecho («Fortran, Lisp, Cobol and SQL are good examples»); identidad con el ejemplo de los dos padres; encapsulamiento con el empleado; clases que reemplazan al esquema; herencia con seis programas frente a cuatro; polimorfismo y enlace tardío; «Thou shalt question the golden rules». Carnegie Mellon University: The Object-Oriented Database System Manifesto — Consultada: 2026-11-02.
3. Stonebraker, Michael y Hellerstein, Joseph M. What Goes Around Comes Around, capítulo 1 de Readings in Database Systems, 4.ª edición (MIT Press, 2005), sección VIII «OO Era» — el «impedance mismatch» entre bases relacionales y lenguajes como C++; «gluing an apple onto a pancake»; empresas pioneras (Ontologic, Object Design, Versant) con C++ persistente; mercado de ingeniería que nunca creció; «all of the OODB vendors have failed, or have repositioned their companies»; cuatro razones presentadas como «In our opinion»; débil soporte de transacciones y consultas; «Lesson 13: Packages will not sell to users unless they are in “major pain”». Universidad de Washington: What Goes Around Comes Around (PDF) — Consultada: 2026-11-02.
4. Stonebraker, Michael y Pavlo, Andrew. What Goes Around Comes Around… And Around…, ACM SIGMOD Record, vol. 53, n.º 2, junio de 2024 — «the relational model with an extendable type system (i.e., object-relational) has dominated all comers»; las bases documentales son «essentially the same as object-oriented DBMSs from the 1980s» y repiten el argumento del desajuste; el problema «N+1» de los ORM. Texto leído en la copia de la Universidad Carnegie Mellon. ACM: What Goes Around Comes Around… And Around… (DOI) — Consultada: 2026-11-02.
5. Object Data Management Group. The Object Database Standard: ODMG 2.0, extracto del libro conservado en ODBMS.org — meta de aplicaciones portables entre productos; OQL «is very close to SQL 92», con extensiones para objetos complejos, identidad, rutas, polimorfismo y operaciones; OQL no trae operadores de actualización y llama a las operaciones de los objetos; conexiones con C++, Smalltalk y Java; nota del sitio: ODMG 3.0 se publicó en enero de 2000 y el ODMG cambió su carta de fundación para ser un estándar de interfaz de almacenamiento de objetos que funciona con cualquier gestor. ODBMS.org: ODMG 2.0 Book Extract — Consultada: 2026-11-02.
6. Cattell, R. G. G.; Barry, Douglas K. y otros (eds.). The Object Data Standard: ODMG 3.0, Morgan Kaufmann (ficha del libro en Elsevier) — 1.ª edición del 4 de abril de 2000; amplía el estándar hacia los mapeos que guardan objetos en bases relacionales; conserva lo de la versión 2.0, incluido OQL (capítulo 4: rutas, polimorfismo, sintaxis). Elsevier: The Object Data Standard, ODMG 3.0 — Consultada: 2026-11-02.
7. The PostgreSQL Global Development Group. About — «PostgreSQL is a powerful, open source object-relational database system»; origen en el proyecto POSTGRES de la Universidad de California en Berkeley, en 1986. PostgreSQL: About — Consultada: 2026-11-02.
8. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 8.16 «Composite Types» — un tipo compuesto representa la estructura de una fila; una columna puede declararse de tipo compuesto; al declararlo no se pueden incluir restricciones como NOT NULL. PostgreSQL: Documentation 18, Composite Types — Consultada: 2026-11-02.
9. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 5.11 «Inheritance» — la tabla hija hereda todas las columnas de la madre; SQL:1999 y posteriores definen una herencia de tipos que difiere en muchos aspectos; «A serious limitation»: índices y claves foráneas solo aplican a tablas individuales. PostgreSQL: Documentation 18, Inheritance — Consultada: 2026-11-02.
10. The PostgreSQL Global Development Group. PostgreSQL 18 Documentation, sección 8.14 «JSON Types» — jsonb se guarda en un formato binario descompuesto; aun donde se busca la máxima flexibilidad, se recomienda que los documentos JSON tengan una estructura algo fija. PostgreSQL: Documentation 18, JSON Types — Consultada: 2026-11-02.
11. SQLAlchemy. The Python SQL Toolkit and Object Relational Mapper (sitio oficial) — definición del proyecto; serie actual 2.1 (versión 2.1.6). SQLAlchemy: sitio oficial — Consultada: 2026-11-02.
12. Django Software Foundation. Models, documentación de Django 6.1 — «Generally, each model maps to a single database table»; cada modelo es una clase de Python. Django: Models — Consultada: 2026-11-02.
13. Hibernate. Hibernate ORM (sitio oficial) — persistencia para Java y bases relacionales; su adopción la impulsaron programadores que buscaban salir del «quagmire of handwritten object/relational mapping code». Hibernate: Hibernate ORM — Consultada: 2026-11-02.
14. ObjectDB Software. ObjectDB: Fast JPA Object Database for Java (portada) y página de descarga — versión 2.9.5 publicada el 2026-03-02 (descarga); según la portada, «requires slow conversions between graphs of Java objects and flat database table rows»: guardar objetos de Java en un gestor relacional exige conversiones lentas entre grafos de objetos y filas planas. ObjectDB: portada y ObjectDB: descarga y versión vigente — Consultada: 2026-11-02.
15. Actian. Actian NoSQL Object Databases — «Formerly known as Versant Object Database or VOD»; transacciones para modelos de objetos muy complejos sin código de mapeo; «Formerly known as Versant FastObjects», guarda los objetos directamente y genera el esquema a partir de las clases. Actian: NoSQL Object Databases — Consultada: 2026-11-02.
16. InterSystems. Documentación de InterSystems IRIS («Introduction», orientación para programadores) y de Caché («Why Migrate to InterSystems IRIS?») — IRIS es una plataforma de datos multimodelo con acceso por objetos y SQL sobre los mismos datos; Caché «is now a mature product and is no longer subject to new development, except for maintenance releases». InterSystems: IRIS, Introduction y InterSystems: Why Migrate to InterSystems IRIS? — Consultada: 2026-11-02.
17. Python Software Foundation. Python 3.15 documentation: módulos sqlite3 y shelve — sqlite3 es la interfaz DB-API 2.0 para SQLite; un «shelf» es un objeto persistente parecido a un diccionario, cuyos valores pueden ser casi cualquier objeto de Python; «it is insecure to load a shelf from an untrusted source». Python: sqlite3 y Python: shelve — Consultada: 2026-11-02.

Cómo investigamos esta página

• Pregunta que responde: Qué es una base de datos orientada a objetos, por qué nació del choque entre objetos y tablas y dónde terminó su idea.
• Fuentes: identificadas 31 → incluidas 18
• Criterios de inclusión: manifiesto de 1989, artículos de Stonebraker, estándar ODMG y documentación oficial de PostgreSQL, ORM y fabricantes; nada de blogs ni enciclopedias.
• Fecha de corte de los datos: 2026-11-02