El documento describe las bases de datos orientadas a objetos. Combinan los datos y procedimientos de una entidad, permitiendo la reutilización de entidades. Soportan relaciones de muchos a muchos y el acceso a datos es a través de relaciones almacenadas con los datos. No son apropiadas para consultas ad hoc pero normalmente las soportan.

1. QUE SON LAS BASES DE DATOS ORIENTADOS A OBJETOS
El desarrollo del paradigma orientado a objetos aporta un gran cambio en el modo en que vemos los datos
y los procedimientos que actúan sobre ellos. Tradicionalmente, los datos y los procedimientos se han
almacenado separadamente: los datos y sus relaciones en la base de datos y los procedimientos en los
programas de aplicación. La orientación a objetos, sin embargo, combina los procedimientos de una
entidad con sus datos.
Esta combinación se considera como un paso adelante en la gestión de datos. Las entidades son unidades
auto contenidas que se pueden reutilizar con relativa facilidad. En lugar de ligar el comportamiento de
una entidad a un programa de aplicación, el comportamiento es parte de la entidad en sı, por lo en
cualquier lugar en el que se utilice la entidad, se comporta de un modo predecible y conocido.
El modelo orientado a objetos también soporta relaciones de muchos a muchos, siendo el primer modelo
que lo permite. Aun así se debe ser muy cuidadoso cuando se diseñan estas relaciones para evitar pérdidas
de información por otra parte, las bases de datos orientadas a objetos son navegaciones:
El acceso a los datos es a través de las relaciones, que se almacenan con los mismos datos. Esto se
considera un paso atrás. Las bases de datos orientadas a objetos no son apropiadas para realizar consultas
ad hoc, al contrario que las bases de datos relacionales, aunque normalmente las soportan. La naturaleza
navegacional de las bases de datos orientadas a objetos implica que las consultas deben seguir relaciones
predefinidas y que no pueden insertarse nuevas relaciones “al vuelo”.
No parece que las bases de datos orientadas a objetos vayan a reemplazar a las bases de datos
relacionales en todas las aplicaciones del mismo modo en que ́estas reemplazaron a sus predecesoras.
Los objetos han entrado en el mundo de las bases de datos de formas:
 SGBD orientados a objetos puros: son SGBD basados completamente en el modelo orientado a
objetos.
 SGBD híbridos u objeto–relacionales: son SGBD relacionales que permiten almacenar objetos en
sus relaciones (tablas).
 A continuación se definen los conceptos del paradigma orientado a objetos en programación, ya
que el modelo de datos orientado a objetos es una extensión del mismo.
Objeto.
Es un elemento auto contenido utilizado por el programa. Los valores que almacena un objeto se
denominan atributos, variables o propiedades. Los objetos pueden realizar acciones, que se denominan
métodos, servicios, funciones, procedimientos u operaciones. Los objetos tienen un gran sentido de la
privacidad, por lo que solo dan información sobre sı mismos a través de los métodos que poseen para
compartir su información. También ocultan la implementación de sus procedimientos, aunque es muy
sencillo pedirles que los ejecuten.
Los usuarios y los programas de aplicación no pueden ver que hay dentro de los métodos, solo pueden
ver los resultados de ejecutarlos. A esto es a lo que se denomina ocultación de información o
encapsulamiento de datos.
Cada objeto presenta una interface pública al resto de objetos que pueden utilizarlo. Una de las mayores
ventajas del encapsulamiento es que mientras que la interface publica sea la misma, se puede cambiar la
implementación de los métodos sin que sea necesario informar al resto de objetos que los utilizan. Para
pedir datos a un objeto o que ́este realice una acción se le debe enviar un mensaje. Un programa
orientado a objetos es un conjunto de objetos que tienen atributos y métodos. Los objetos interactúan
enviándose mensajes. La clave, por supuesto, es averiguar que objetos necesita el programa y cuáles
deben ser sus atributos y sus métodos.

2. Clase.
Es un patrón o plantilla en la que se basan objetos que son similares. Cuando un programa crea un objeto
de una clase, proporciona datos para sus variables y el objeto puede entonces utilizar los métodos que se
han escrito para la clase. Todos los objetos creados a partir de la misma clase comparten los mismos
procedimientos para sus métodos, también tienen los mismos tipos para sus datos, pero los valores
pueden diferir.
Una clase también es un tipo de datos. De hecho una clase es una implementación de lo que se conoce
como un tipo abstracto de datos. El que una clase sea también un tipo de datos significa que una clase se
puede utilizar como tipo de datos de un atributo.
Tipos de clases.
En los programas orientados a objetos hay tres tipos de clases: clases de control, clases entidad y clases
interface.
 Las clases de control gestionan el flujo de operación de un programa (por ejemplo, el programa
que se ejecuta es un objeto de esta clase)
 Las clases entidad son las que se utilizan para crear objetos que manejan datos (por ejemplo,
clases para personas, objetos tangibles o eventos).
 Las clases interface son las que manejan la entrada y la salida de información (por ejemplo, las
ventanas gráficas y los menús utilizados por un programa).
En los programas orientados a objetos, las clases entidad no hacen su propia entrada/salida. El teclado es
manejado por objetos interface que recogen los datos y los envían a los objetos entidad para que los
almacenen y los procesen. La salida impresa y por pantalla la formatea un objeto interface para obtener
los datos a visualizar de los objetos entidad. Cuando los objetos entidad forman parte de la base de datos,
es el SGBD el que se encarga de la entrada/salida a ficheros.
El resto de la entrada/salida la manejan los programas de aplicación o las utilidades del SGBD. Muchos
programas orientados a objetos tienen un cuarto tipo de clase: la clase contenedor. Estas clases
contienen, o manejan, múltiples objetos creados a partir del mismo tipo de clase. También se conocen
como agregaciones. Las clases contenedor mantienen los objetos en algún orden, los listan e incluso
pueden permitir búsquedas en ellos. Muchos SGBD orientados a objetos llaman a sus clases contenedor
Extents (extensiones) y su objetivo es permitir el acceso a todos los objetos creados a partir de la misma
clase.
Tipos de métodos.
Hay varios tipos de métodos que son comunes a la mayoría de las clases:
Constructores. Un constructor es un método que tiene el mismo nombre que la clase. Se ejecuta cuando
se crea un objeto de una clase. Por lo tanto, un constructor contiene instrucciones para inicializar las
variables de un objeto. Destructores. Un destructor es un método que se utiliza para destruir un objeto.
No todos los lenguajes orientados a objetos poseen destructores accesores. Un accesor es un método
que devuelve el valor de un atributo privado de otro objeto. Así es como los objetos externos pueden
acceder a los datos encapsulados. Mutadores. Un mutador es un método que almacena un nuevo valor
en un atributo. De este modo es como objetos externos pueden modificar los datos encapsulados.
Además, cada clase tendrá otros métodos dependiendo del comportamiento especıfico que deba poseer.
Sobrecarga de métodos.
Una de las características de las clases es que pueden tener métodos sobrecargados, que son métodos
que tienen el mismo nombre pero que necesitan distintos datos para operar. Ya que los datos son

3. distintos, las interfaces públicas de los métodos serán diferentes. Por ejemplo, consideremos una clase
contenedor. (Marqués, 12 de abril de 2002)
CARACTERÍSTICAS
Un sistema de base de datos orientados a objetos debe poseer las siguientes características, desde los
más sencillos a objetos más complejos.
I. Tipos complejos
Array: Son matrices de elementos de datos, como los que podemos encontrar en innumerables
aplicaciones científicas.
 Sentencia de tipo: Insertar elementos en una matriz en cualquier posición.
 Tuplas: Forma natural de representar las propiedades de una entidad.
 Conjunto: Forma natural de representar los grupos del mundo real.
 Funciones: Para crear, modificar y borrar otros objetos.
 Uniones: Elementos de datos que pueden tomar diferentes valores de los diferentes tipos, es
decir, matrices heterogéneas.
II. Identidad de objeto
La identidad es aquella propiedad de un objeto que lo distingue de todos los demás objetos. La idea es
que en un modelo con identidad de los objetos, la existencia de un objeto es independiente de su valor.
Cada objeto se representa por un ID (Identificador de objetos) que es único dentro de toda la base de
datos. Estos IDOs no tienen que ser gestionados por el programador ya que son implementados a bajo
nivel por el sistema, lo que a su vez incrementa el rendimiento del mismo. De esta forma dos objetos
serán diferentes si tienen IDOs diferentes, aunque sus atributos tengan los mismos valores. Así, dos
objetos pueden ser idénticos (son el mismo objeto, tienen el mismo IDO) o iguales (tienen el mismo valor).
Esto implica que dos objetos idénticos son a su vez iguales, mientras que lo inverso no es cierto.
La identidad de los objetos es además una potente primitiva que puede ser la base para el manejo de
tuplas, conjuntos, y objetos complejos recursivos. También permite operaciones tales como asignación o
copia de objetos.
III. Encapsulamiento
El encapsulamiento se centra en la implementación que da lugar al comportamiento observable de un
objeto. El encapsulamiento se consigue a menudo mediante la ocultación de información, es decir, se
basa en ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales. El
encapsulamiento proporciona, por tanto, barreras explícitas entre abstracciones diferentes.
Existen dos visiones diferentes del encapsulamiento [ATK89], la primera y original que es la del lenguaje
de programación; y la segunda que es la adaptación de esa visión para la base de datos. Desde el punto
de vista de las bases de datos, esto se traduce en el hecho de que un objeto abarca operaciones y datos,
pero con una diferencia.
En las bases de datos no está claro si la parte estructural es parte de la interfaz (depende del sistema),
mientras que en los lenguajes de programación la estructura de datos es claramente parte de la
implementación y no de la interfaz. Como se puede observar, el encapsulamiento proporciona una forma
lógica de independencia de los datos, ya que se puede cambiar la implementación de un tipo sin cambiar
ninguno de los programas que usan ese tipo.
IV. Tipos y clases

4. Existen dos categorías principales de sistemas orientados a objetos, los que soportan el concepto de clases
y los que soportan el concepto de tipo. Un tipo en un sistema orientado a objetos se corresponde con el
concepto de tipo abstracto de datos.
Es un conjunto de objetos que tienen un mismo comportamiento (comparten una misma funcionalidad)
que se puede observar desde afuera. Esto significa que el tipo al cual un objeto pertenece depende de
qué operaciones puedan invocarse sobre el objeto.
V. Herencia
Las clases o tipos heredan de sus ancestros.
Ventajas de la herencia:
 Ayuda al modelado porque proporciona una descripción concisa y precisa del mundo.
 Ayuda a compartir especificaciones e implementaciones en las aplicaciones.
VI. Polimorfismo, sobrecarga y ligadura tardía.
Existen casos en los que se desea tener el mismo nombre para diferentes operaciones. Supongamos la
operación dibuja que toma un objeto como entrada y lo dibuja en pantalla. Dependiendo del tipo de
objeto (cuadrado, estrella, flecha,...) debemos emplear diferentes mecanismos de visualización. Es decir,
necesitamos visualizar un conjunto cuyos miembros no se conocen en tiempo de compilación.
En una aplicación que emplee el sistema convencional, habrá tantas operaciones como figuras a
representar: dibuja cuadrado, dibuja estrella, dibuja flecha, etc.
En un sistema orientado a objetos se definirá la operación en una clase más general. Así dibuja tendrá un
único nombre y podrá emplearse indiferentemente sobre cualquier figura.
VII. Complejidad de cálculos
Puede expresarse cualquier función computable utilizando el lenguaje de modificación de datos de un
sistema de base de datos.
VIII. Extensibilidad.
El conjunto de tipos predefinidos que aporta el sistema de base de datos debe ser extensible mediante
algún mecanismo que permita definir tipos nuevos.
No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos.
IX. Persistencia
La persistencia es una de las características que los SGBDOO heredan tanto de los SGBD como del modelo
de objetos. La diferencia está en que la persistencia proporcionada por el SGBD tradicional, se refiere
únicamente a la conservación de los datos, mientras que la persistencia heredada del modelo de objetos
hace referencia no sólo a la conservación del estado de un objeto, sino también a la conservación de la
clase, que debe trascender a cualquier programa individual, de forma que todos los programas
interpreten de la misma manera el estado almacenado.
X. Gestión de almacenamiento
La gestión del almacenamiento secundario es soportada por un conjunto de mecanismos que no son
visibles al usuario, tales como gestión de índices, agrupación de datos, selección del camino de acceso,
optimización de consultas, etc. Estos mecanismos evitan que se tengan que escribir programas para
mantener índices, asignar el almacenamiento en disco, o trasladar los datos entre el disco y la memoria
principal, creándose de esta forma una independencia entre los niveles lógicos y físicos del sistema.
XI. Concurrencia

5. El SGBO debe gestionar el acceso de múltiples usuarios a la vez. Soportando la noción de atomicidad de
una secuencia de operaciones y la compartición controlada. .
Si se introduce concurrencia en nuestro sistema hay que considerar cómo los objetos activos sincronizan
sus actividades con otros, así como con objetos puramente secuenciales. Por ejemplo, si dos objetos
activos intentan enviar mensajes a un tercer objeto, hay que tener la seguridad de que existe algún
mecanismo de exclusión mutua, de forma que el estado del objeto sobre el que se actúa no está corrupto
cuando los dos objetos activos intentan actualizarlo simultáneamente. En presencia de la concurrencia no
hay que definir simplemente los métodos de un objeto; hay que asegurarse también de que la semántica
de estos métodos se mantiene a pesar de la existencia de múltiples usuarios concurrentes.
XII. Recuperación
El sistema debe proporcionar como mínimo el mismo nivel de recuperación que los sistemas de bases de
datos actuales. De forma que, tanto en caso de fallo de hardware como de fallo de software, el sistema
pueda retroceder hasta un estado coherente de los datos. Los fallos de los que un sistema debe ser capaz
de recuperarse pueden producirse por diferentes motivos, por ejemplo:
Interrupción en el suministro de energía, de forma que se pierda la información almacenada en la
memoria principal y en los registros de uso general.
Errores de software, debido a que los resultados generados son incorrectos, lo que provoca respuestas
erróneas a los usuarios y que la base de datos entre en un estado incongruente.
XIII. Facilidad de consulta ad hoc
El sistema debería proporcionar la funcionalidad de un lenguaje de consulta ad hoc, es decir, permitir al
usuario hacer cuestiones sencillas a la base de datos. Este tipo de consultas tienen como misión
proporcionar la información solicitada por el usuario de una forma correcta y rápida. (Prieto, 2011)
CARACTERÍSTICAS OPCIONALES
I. Herencias múltiples
Tipo de herencia que permite a una clase tener más de una super-clase y heredar características de sus
ancestros. Así, si un sistema ofrece herencia múltiple pueden surgir una serie de conflictos, como el hecho
de que dos o más superclases tengan un atributo con el mismo nombre, pero con dominios diferentes.
También puede ocurrir que exista Herencias repetidas, esto pasa cuando dos o más superclases
"hermanas", comparten una superclase común, ya que entonces hay que decidir si la clase que hereda de
ambas debe tener una sola copia o muchas copias de la estructura de la clase compartida.
II. Distribución
Los objetos de las bases de datos pueden estar almacenados en diferentes ubicaciones, sin que el usuario
al acceder a ellos sea consciente de esta circunstancia, el sistema debe proporcionar una forma de realizar
esta operación de manera transparente.
III. Versiones
La mayoría de las nuevas aplicaciones, tales como CAD/CAM y CASE, comprenden una actividad de diseño
que requiere alguna forma de versionado una versión es una instantánea semánticamente significativa
tomada al objeto de diseño en un momento dado en el tiempo.
Una versión de un objeto se crea a partir de las modificaciones hechas en el tiempo a las versiones previas
de éste, comenzando con una versión inicial. La traza de estas derivaciones se mantiene a través de una
historia de las versiones.

6. Una versión de un objeto complejo puede constar de las versiones específicas de sus objetos
componentes. (Prieto, 2011)
VENTAJAS Y DESVENTAJAS
Las ventajas de un BDOO son:
 Mayor capacidad de modelado:
 Un objeto permite encapsular tanto un estado como un comportamiento.
 Un objeto puede almacenar todas las relaciones que tenga con otros objetos.
 Los objetos pueden agruparse para formar objetos complejos (herencia).
 Se pueden construir nuevos tipos de datos a partir de los ya existentes
 Agrupar propiedades comunes de diversas clases e incluirlas en una superclase, lo que reduce la
redundancia.
 Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un menor
tiempo de desarrollo.
 El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en
un SGBDOO. Mientras que SQL utiliza el acceso asociativo.
 El acceso navegacional es más adecuado para gestionar operaciones como los despieces,
consultas recursivas, etc.
 Hay muchas áreas en las que los SGBD tradicionales no han tenido excesivo éxito como el CAD,
CASE, OIS, sistemas multimedia, etc. en los que las capacidades de modelado de los SGBDOO han
hecho que esos sistemas sí resulten efectivos para este tipo de aplicaciones. .
 Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los SGBD
relacionales.
Las desventajas de una BDOO son:
 Carencia de un modelo de datos universal.
 No hay ningún modelo de datos que esté universalmente aceptado para los SGBDOO y la mayoría
de los modelos carecen una base teórica.
 Carencia de experiencia.
 Lentitud a la hora de ejecutar el sistema.
 Todavía no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales.
 Carencia de estándares.
 Existe una carencia de estándares general para los SGBDOO.
 Competencia. Con respecto a los SGBDR y los SGBDOR.
 El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en
un SGBDOO. Mientras que SQL utiliza el acceso asociativo.
 Estos productos tienen una experiencia de uso considerable. SQL es un estándar aprobado y
ODBC es un estándar de facto. Además, el modelo relacional tiene una sólida base teórica y los
productos relacionales disponen de muchas herramientas de soporte que sirven tanto para
desarrolladores como para usuarios finales.
 La optimización de consultas compromete la encapsulación.
 La optimización de consultas requiere una compresión de la implementación de los objetos, para
poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el
concepto de encapsulación. Bases de Datos Orientadas a Objetos
 El modelo de objetos aún no tiene una teoría matemática que le sirva de base. (Torres, 2010)

7. DIFERENCIAS ENTRE EL MODELO DE OBJETOS Y EL MODELO RELACIONAL
Mientras que en una BDR los datos a almacenar se almacenan representados en tablas en un BDOO los
datos se almacenan como objetos. Un objeto en BDOO como en POO es una entidad identificable
unívocamente que describe tanto el estado como el comportamiento de una entidad del ‘mundo real’.
El estado de un objeto es descrito mediante atributos mientras que su comportamiento es definido
mediante métodos.
La forma de identificar objetos es mediante un identificador de objetos (OID, Object Identifier), único para
cada objeto. General mente este identificador no es accesible ni modificable para el usuario (modo de
aumentar la integridad de entidades y la integridad referencial). Los OID son independientes del
contenido. Es decir, si un objeto cambia los valores de atributos, sigue siendo el mismo objeto con el
mismo OID. Si dos objetos tienen el mismo estado pero diferentes OID, son equivalentes pero tienen
identidades diferentes.
Cada objeto contiene define procedimientos (métodos) y la interfaz mediante la cual se puede acceder a
él y otros objetos pueden manipularlo. La mayoría de los SGBDOO permite el acceso directo a los atributos
incluyendo operaciones definidas por el propio SGBDOO las cuales leen y modifican los atributos para
evitar que el usuario. (María Pilar Azcarate Toro, 2011)
Bibliografía
María Pilar Azcarate Toro, A. C. (2011). Base de datos orientado a objetos y objeto relacional.
Pereira.
Marqués, M. (12 de abril de 2002). Bases de datos orientadas a objetos (Vol. 2). Diseño de
Sistemas de Bases de Datos.
Prieto, A. B. (2011). Introducción a los sistemas de gestión de bases de. Universidad de Oviedo.
Torres, J. P. (2010). Base de datos orientado a objetos (Vol. 2). IES SAN VICENTE.