En la actualidad, hay mucha atención hacia los OODBMS, tanto en el terreno de desarrollo como en el teórico, no hay una definición estándar de lo que estos sistemas significan. Existen tres problemas principales que impiden una definición generalizada:

El problema de estos sistemas es similar al de las bases de datos relacionales a mitad de los setenta. La gente se dedicaba a desarrollar implementaciones en lugar de definir las especificaciones para luego hacer la tecnología que permitiera implementarlas. Se espera que de los prototipos y desarrollos actuales de los OODBMS surja un modelo. Aunque también se corre el riesgo de que alguno de éstos se convierta en el estándar por su demanda en el mercado. A manera de definición podemos decir que un OODBMS debe satisfacer dos criterios:

Criterios que debe cumplir un OODBMS

Objetos complejos

Los objetos complejos son creados a partir de objetos simples —tipos de datos—. Éstos son:

• Enteros
• Caracteres
• Cadenas de bytes
• Expresiones del tipo booleano
• Números de punto flotante

Los objetos complejos pueden ser:

• Tuplas
• Conjuntos —sets—
• Listas
• Arreglos

Un OODBMS debe tener como mínimo conjuntos —set—, listas y tuplas.

Identidad de objetos

La identidad de objetos ha existido desde hace mucho tiempo en los lenguajes de programación, pero en las bases de datos es más reciente. El objetivo es contar con objetos que tengan una existencia independiente de sus valores. Así, dos objetos pueden ser idénticos si son el mismo objeto o pueden ser iguales si tienen los mismos valores. La identidad cobra relevancia cuando un objeto se comparte con otros y cuando se actualiza. En un modelo basado en identidad, dos objetos pueden compartir un objeto hijo.

Por ejemplo, pensemos en dos personas: Arturo y Valeria; cada uno tiene un hijo llamado Jaime. En la vida real, hay dos posibles situaciones:

a) Arturo y Valeria son padres de Jaime, por lo que existe identidad del objeto Jaime; es decir, se trata en realidad del mismo objeto. Identidad de los objetos

b) Hay dos niños del mismo nombre. Esto implica igualdad de dos objetos Jaime, porque tienen el mismo nombre, pero no son el mismo objeto. Igualdad de valores en los objetos

Asumiendo que Arturo y Valeria son en realidad padres de un mismo niño Jaime, todas las actualizaciones al hijo de Arturo, también son aplicadas al hijo de Valeria, ya que se trata del mismo objeto: Jaime. Si el sistema no tuviera identidad, sino que se basara en igualdad de objetos, serían necesarias dos actualizaciones a los dos objetos Jaime.

Soportar identidad de objetos implica que el OODBMS ofrece:

• Operaciones como asignación de objetos
• Copiado de objetos
• Comprobación de la identidad o igualdad de objetos.

La principal manera de implementar la identidad de objetos es mediante un OID —objeto identificador— independiente de los valores de los atributos del objeto. Éstos son implementados por el sistema, lo que mejora el rendimiento.

Según Date (2001, p. 847), los OID son innecesarios e indeseables en el nivel del modelo. En comparación con las claves primarias, los OID están ocultos al usuario, mientras que aquéllas no. El uso de estos OID no elimina el uso de claves primarias, ya que son necesarias para unir al sistema con la realidad en la que se inserta; pensemos, por ejemplo, en los folios de facturación.

Ejemplo de una factura señalando su folio de facturación

Encapsulación

La idea de encapsulación es tomada de los lenguajes de programación en los que para todo objeto existe:

Partes del encapsulamiento

Traducido a bases de datos, un objeto encapsula programas y datos.

Empleado Juan Rodríguez

Por ejemplo, en un sistema relacional, un empleado es representado por una tupla. Para ser consultado desde una aplicación, es necesario usar un lenguaje para programar procedimientos que serán almacenados fuera de la base datos; es más, ese lenguaje puede ser, en realidad, la combinación de un lenguaje de alto nivel con el estándar relacional SQL. En un sistema de bases de datos orientado a objetos, definimos al empleado como un objeto que tiene una parte de datos —probablemente muy similar al registro que definiríamos en el sistema relacional— y una parte de operaciones, la cual consiste, por ejemplo, en operaciones de aumentodeSalario() y bajaDefinitiva() que accederían a los datos del empleado. Cuando se almacene un nuevo empleado, datos y operaciones serían guardados en la base y no fuera de ella.

Herencia

La herencia tiene dos ventajas:

1. Es una herramienta poderosa de modelado, ya que brinda una descripción precisa del mundo.
2. Ayuda a simplificar la implementación de las aplicaciones.

Para entender el manejo de la herencia en los sistemas de bases de datos orientados a objetos, asumamos que tenemos empleados y estudiantes.

Clase persona
Clase empleado	Clase estudiante
Cada empleado tiene nombre, edad y salario, además podemos aumentar su sueldo. Empleado hereda de persona	Por su parte, cada estudiante tiene edad, nombre y un conjunto de calificaciones con las cuales podemos obtener su promedio. Estudiante hereda de persona

Ejemplo de la herencia en un OODBMS

En un sistema relacional, el diseñador de bases de datos definiría una relación empleado y estudiante y también escribiría el código para la operación de aumentar sueldo. Para la relación estudiante, tendría que escribir el código para la operación de obtener promedio.

En un sistema orientado a objetos, usando adecuadamente la herencia, nos daríamos cuenta de que empleado y estudiante son personas y comparten los atributos nombre y edad. Entonces, declararíamos una clase empleado como un tipo especial de la clase persona, que incluiría una operación especial para aumentar Sueldo() y un atributo de salario. De forma similar, se declararía el estudiante como un tipo especial de la clase persona con el atributo adicional de conjunto de grados y la operación especial para obtener Promedio().

El modelo es más cercano a la realidad y nos permite ahorrar código de programación. Por esto, se dice que la herencia ayuda a reutilizar código, ya que cada programa está disponible para ser compartido.

Sobreescritura y sobrecarga

En la programación orientada a objetos, tenemos la ventaja de poder reescribir métodos con el mismo nombre. Esto significa contar con varios métodos que se llamen igual, pero que realicen distintas operaciones. Para poder programar estos métodos llamados sobrecargados, es necesario que cambie algo en sus parámetros, como el número, orden o tipo de dato. Esto mismo es posible en una base de datos orientada a objetos.

Ejemplo de métodos de sobreescritura y sobrecarga

Completa capacidad computacional —computational completeness—

Los administradores de bases de datos relacionales cuentan con un lenguaje para realizar procesos computacionales sobre los datos: el SQL. Además, adicionan un lenguaje procedimental que permite la definición de variables, manejo de excepciones, ciclos y estructuras condicionales. Algunos de estos lenguajes son:

Los administradores de bases de datos orientadas a objetos también deben contar con un lenguaje que puede realizar cualquier procesamiento. En este sentido, lo más común es que los OODBMS integren lenguajes computacionalmente completos dentro de la base de datos. Estos pueden ser los que ya existen en el mercado y que se usan como lenguajes aplicación general (Java, C++, etcétera).