AGRADECIMIENTOS

A Dios todo poderoso, por permitirnos haber

llegado hasta este momento tan importante de
nuestra formacin profesional.

A nuestros padres por el apoyo incondicional

que nos brindan para seguir nuestros sueos
de hacernos unos profesionales de calidad

A nuestros profesores, gracias por su tiempo, por

su apoyo as como por la sabidura que me
transmitieron en el desarrollo universitario.

LOS AUTORES

RESUMEN

En el presente trabajo de investigacin trata acerca de las base de datos

orientados a objetos.
En el mundo de las base de datos existe 2 modelos principalmente, modelo
relacional (SQL) y modelos no-relacional (NoSQL), he hecho en los 90s surge el
concepto de bases de datos orientadas a objetos (BDOO) qu se pens que
revolucionaria la manera de hacer persistente la informacin en los sistemas de
software pero esto no pero esto no logro ser pero hoy en la actualidad volvieron a
la palestra debido a que el modelos tradicionales presentan algunas deficiencias
para aplicaciones ms complejas como sistemas de informacin geogrficos o
sistemas multimedia. Los requerimientos y caractersticas de estas nuevas
aplicaciones son muy diferentes de las tpicas aplicaciones de gestin debido a
que las transacciones son de una duracin mayor y se necesitan nuevos tipos de
datos para almacenar imgenes y textos.
Las BDOO surgen o vuelven a sonar para satisfacer estas necesidades, ya que la
orientacin a objetos ofrece flexibilidad para manejar algunos de estos requisitos y
no estn limitadas por los tipos de datos y los lenguajes de consulta de los
sistemas de base de datos tradicionales.
En el presente trabajo de investigacin abarcaremos conceptos previos acerca de
la orientacin a objetos los cuales nos permitirn posteriormente introducirnos sin
ninguna complicacin al mundo de las BDOO.

INDICE

Agradecimientos.............................................................................................. 0
Resumen.......................................................................................................... 1
Introduccin..................................................................................................... 5
Capitulo 1: conceptos bsicos de orientacin a objetos...................................6
1.1.

Objetos................................................................................................ 7

1.2.

Clases:................................................................................................. 8

1.3.

Metodos:............................................................................................. 9

1.4.

Herencia............................................................................................ 10

1.5.

Encapsulamiento............................................................................... 11

1.6.

Polimorfismo...................................................................................... 12

Captulo 2: El modelo de datos orientados a objetos.....................................16

2.1. Relaciones:........................................................................................... 16
2.2. Integridad de relaciones:......................................................................16
2.3. UML ..................................................................................................... 19
Captulo 3: Caracteristicas de las base de datos orientados a objetos..........20
Capitulo 4: Ventajas y Desventajas de las BDOO...........................................22
4.1.

Ventajas de un SGBDOO....................................................................22

4.2.

Desventajas de una BDOO................................................................23

Captulo 5: El modelo estndar ODMG ..........................................................25

5.1. Modelo de objetos:.............................................................................. 25
5.2. Lenguaje de definicin de objetos ODL................................................33
5.3. Lenguaje de consulta de objetos OQL .................................................36
Captulo 6: Conclusiones ............................................................................... 41
Bibliografia:.................................................................................................... 42

INDICE DE FIGURAS
2

Figura 1: Representacin de un objeto auto con sus atributos y mtodos.

..................................................................................................................6
Figura 2: Representacin grfica de una clase rbol................................7
Figura 3: Ejemplo de Cdigo Fuente de un mtodo constructor en java...8
Figura 4: Ejemplo de Cdigo Fuente de un mtodo destructor en C++....9
Figura 5: Ejemplo de Cdigo Fuente de mtodos accesores y mutadores
en java......................................................................................................9
Figura 6: Ejemplo de Cdigo Fuente sobrecarga de mtodos en java.....10
Figura 7: Ejemplo de Herencia y Herencia Mltiple.................................11
Figura 8: Encapsulamiento......................................................................12
Figura 9: Polimorfismo de sobrecarga.....................................................13
Figura 10: Polimorfismo paramtrico......................................................14
Figura 11: Polimorfismo subtipado..........................................................15
Figura 12: Clase aparejador....................................................................17
Figura 13: Clase Obra..............................................................................17
Figura 14: Interface Object.....................................................................26
Figura 15: Herencia BDOO......................................................................29
Figura 16: El uso de ODL (Clase Persona)...............................................32
Figura 17. El uso de ODL (Clase Estudiante, Clase Calificacion, Clase
EstudianteGrad)......................................................................................33
Figura 18: El uso de ODL (Clase Titulo, Clase Departamento, Clase
Curso, Clase Edicion)..............................................................................34
Figura 19: El uso de ODL (Clase EdicionActual)......................................35
Figura 20: sintaxis bsica de OQL...........................................................36
Figura 21: Primera forma de una variable iterador.................................36
Figura 22: Consulta ODL.........................................................................38
Figura 23: Consulta ODL.........................................................................39

INTRODUCCIN

Las BDOO son aquellas cuyo modelo de datos est orientado a objetos y
almacenan y recuperan objetos en los que se almacena estado y comportamiento.
Su origen se debe a que en los modelos clsicos de datos existen problemas para
representar cierta informacin, puesto que aunque permite representar gran
cantidad de datos, las operaciones que se puede realizar con ellos son bastante
simples.
Las clases utilizadas en un determinado lenguaje de programacin orientado a
objetos son las mismas clases que sern utilizadas en una BDOO; de tal manera,
que no es necesaria una transformacin del modelo de objetos para ser utilizado
por un SGBDOO. De forma contraria el modelo relacional requiere abstraerse lo
suficiente como para adaptar los objetos del mundo real a tablas.
Las bases de datos orientadas a objetos surgen para evitar los problemas que
surgen al tratar de representar cierta informacin, aprovechar las ventajas del
POO en el campo de base de datos y para evitar transformaciones entre modelos
de datos (usar el mismo modelo de objetos).

CAPITULO 1: CONCEPTOS BSICOS DE ORIENTACIN A OBJETOS

4

El desarrollo del POO brinda un gran cambio en la forma en la que vemos los
datos y los procedimientos que actan sobre ellos. Tradicionalmente tanto datos
como procedimientos se han almacenado separados sin embargo el POO
combina los procedimientos de una entidad con sus datos. sea el
comportamiento es parte de la entidad en s.
El modelo orientado a objetos tambin soporta relaciones muchos a muchos, por
otra parte las BDOO son navegacionales, el acceso a los datos es a travs de las
relaciones que se almacenan con los mismos datos. Las BDOO no son apropiadas
normalmente para realizar consultas ad hoc, al contrario que las base de datos
relacionales aunque normalmente las soportan. Los objetos han entrado en el
mundo de las bases de datos de forma:

SGBD orientados a objetos puros: son SGBD basados completamente en el

modelo orientado a objetos.

SGBD hbridos u objeto relaciones: son SGBD relacionales que permiten

almacenar objetos en sus relaciones (tablas).

1.1. OBJETOS
Es un elemento auto contenido utilizado por el programa. Los valores que
almacena un objeto son llamados normalmente atributos pero tambin pueden
ser llamados como variables o propiedades. Estos objetos a su vez pueden
realizar acciones los cuales se les denomina mtodos.

Figura 1: Representacin de un objeto auto con sus

atributos y mtodos.

Los objetos tienen un gran sentido de la privacidad por lo que solo brindan
informacin de s mismos a travs de mtodos que poseen para compartir su
informacin. Los usuarios y los programas de aplicacin no pueden ver lo que
hay dentro de los mtodos, slo pueden ver los resultados de ejecutarlos. A
esto se le conoce como ENCAPSULAMIENTO. Que es una de las
caractersticas principales de POO.

1.2. CLASES:
Es un patrn o plantilla en la que se basan objetos que son similares cuando
un programa crea un objeto de una clase, brinda datos para sus variables y el
objeto puede entonces utilizar mtodos que se han escrito para la clase. Todos
los objetos creados a partir de la misma clase comparten los mismos
procedimientos para sus mtodos. Una clase tambin es un tipo de datos. De
hecho una clase es una implementacin de lo que se conoce como un tipo
abstracto de datos. El que una clase sea tambin un tipo de datos significa que
una clase se puede utilizar como tipo de datos de un atributo.

Figura 2: Representacin grfica

de una clase rbol

En la figura podemos observar la clase rbol y los objetos que se crearan

posteriormente. Todos estos objetos tendrn el mismo comportamiento
designado en la clase rbol.

1.2.1.

TIPOS DE CLASES:

En la Programacin orientada a objetos hay 3 tipos de clases:

Clase de control: Gestiona el flujo de operacin de un programa.

Clase entidad: Son las que se utilizan para crear objetos de que manejan
datos.

Clase interface: Son las que manejan la entrada y salida de informacin.

1.3. METODOS:
Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se
desencadena tras la recepcin de un mensaje. Desde el punto de vista del
comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un
7

cambio en las propiedades del objeto o la generacin de un evento con un nuevo

mensaje para otro objeto del sistema.
1.3.1.

TIPOS DE MTODOS:

Dentro de los tipos de mtodos existen 4 que son comunes a la mayora de las
clases:

Constructores: Es un mtodo que tiene el mismo nombre que la clase. Se

ejecuta para instanciar un objeto

Figura 3: Ejemplo de Cdigo Fuente de un mtodo

constructor en java

Destructores: Son mtodos que se encargan de destruir un objeto, no

todos los lenguajes de programacin orientados a objetos soportan los
destructores, JAVA no soporta los destructores mientras que C++ si los hay.

Accesores: Es un mtodo que devuelve el valor de un atributo privado de

otro objeto. De este modo los objetos externos pueden acceder a los datos
encapsulados, en la POO se les conoce como getters.

Figura 4: Ejemplo de Cdigo Fuente de un mtodo

destructor en C++.

Figura 5: Ejemplo de Cdigo Fuente

de mtodos accesores y mutadores
en java.
Mutadores: Es un mtodo que almacena un nuevo valor de un atributo, de
este moto un objeto externo puede modificar los datos encapsulados, en la
POO se les conoce como setters

1.3.2.SOBRECARGA DE MTODOS:

Una de las caractersticas de las clases es que pueden tener mtodos

sobrecargados, que son mtodos con el mismo nombre pero que necesitan
distintos atributos para operar y por ende la accin que realizan es diferente.
Un claro ejemplo podra imaginemos que tenemos una clase persona que
contiende un mtodo trabajar, si instanciamos los objetos Doctor y Profesor
ambos tienen el mtodo trabajar pero este mtodo realiza acciones diferentes
adems de necesitar atributos diferentes.

Figura 6: Ejemplo de Cdigo Fuente

sobrecarga de mtodos en java.

1.4. HERENCIA
Este concepto es especfica de la POO, donde una clase nueva se crea a partir
de una clase existente, esta nueva clase contiene los atributos y mtodos de
su clase padre. La principal ventaja de la herencia es la capacidad de definir
atributos y mtodos nuevos para la subclase.
Adems existe lo que es la HERENCIA MULTIPLE este tipo de herencia no es
soportada por todos los lenguajes orientados a objetos, C++ permite la
herencia mltiple, lo que significa que una clase puede heredar de los atributos
de otras dos superclases. Este mtodo puede utilizarse para agrupar atributos
y mtodos desde varias clases dentro de una sola.

Figura 7: Ejemplo de Herencia y Herencia Mltiple.

10

1.5.

ENCAPSULAMIENTO:

Es un mecanismo que consiste en organizar datos y mtodos de una

estructura, conciliando el modo en que el objeto se implementa, es decir,
evitando el acceso a datos por cualquier otro medio distinto a los especficos.
Por lo tanto la encapsulacin garantiza la integridad de los datos que contiene
un objeto.

Publico: Funciones de toda clase pueden acceder a los datos o mtodos

de una clase que se define con el nivel de acceso pblico, es el nivel de
proteccin ms baja.

Protegido: El acceso a los datos est restringido a las funciones de clases

heredadas, es decir, la funcin miembro de esta clase y todas las
subclases.

Privado: El acceso a los datos est restringido a los mtodos de esa clase
en partculas, Este es el nivel ms alto de proteccin de datos.

Figura 8: Encapsulamiento
11

1.6.

POLIMORFISMO:

Proviene del griego que significa Que posee varias formas diferentes. Este es
uno de los conceptos esenciales de la POO. As como la herencia est
relacionada con las clases y su jerarqua, el polimorfismo se relaciona con los
mtodos, existen 3 tipos de polimorfismos:

Polimorfismos de sobrecarga

Polimorfismos paramtrico

Polimorfismos de inclusin

1.6.1.Polimorfismo de sobrecarga:

El polimorfismo de sobrecarga ocurre cuando las funciones del mismo nombre

existen, con funcionalidad similar, en clases que son completamente
independientes una de otra (stas no tienen que ser clases secundarias de la
clase objeto). Por ejemplo, la clase lnea, la clase rectngulo y la clase circulo
pueden todas tener la funcin Dibujar. Esto significa que no necesitamos
preocuparnos sobre el tipo de objeto con el que estamos trabajando si todo lo
que deseamos es verlo en la pantalla.
Por lo tanto, el polimorfismo de sobrecarga nos permite definir operadores
cuyos comportamientos varan de acuerdo a los parmetros que se les aplican.
As es posible, por ejemplo, agregar el operador + y hacer que se comporte de
manera distinta cuando est haciendo referencia a una operacin entre dos
nmeros enteros (suma) o bien cuando se encuentra entre dos cadenas de
caracteres (concatenacin).

12

Figura 9: Polimorfismo de sobrecarga.

1.6.2.Polimorfismo paramtrico:

El polimorfismo paramtrico es la capacidad para definir varias funciones

utilizando el mismo nombre, pero usando parmetros diferentes (nombre y/o tipo).
El polimorfismo paramtrico selecciona automticamente el mtodo correcto a
aplicar en funcin del tipo de datos pasados en el parmetro.
Por lo tanto, podemos por ejemplo, definir varios mtodos homnimos
de addition() efectuando una suma de valores.

El mtodo int addition(int,int) devolvera la suma de dos nmeros enteros.

float addition(float, float) devolvera la suma de dos flotantes.

char addition(char, char) dara por resultado la suma de dos caracteres

definidos por el autor.

Una signature es el nombre y tipo (esttico) que se da a los argumentos de una

funcin. Por esto, una firma de mtodo determina qu elemento se va a llamar.

13

Figura 10: Polimorfismo paramtrico.

1.6.3.

Polimorfismo subtipado:

La habilidad para redefinir un mtodo en clases que se hereda de una clase base
se llama especializacin. Por lo tanto, se puede llamar un mtodo de objeto sin
tener que conocer su tipo intrnseco: esto es polimorfismo subtipado. Permite no
tomar en cuenta detalles de las clases especializadas de una familia de objetos,
enmascarndolos con una interfaz comn (siendo esta la clase bsica).
Imagine un juego de ajedrez con los objetos rey, reina, alfil, caballo, torre y pen,
cada uno heredando el objeto pieza. El mtodo movimiento podra, usando
polimorfismo subtipado, hacer el movimiento correspondiente de acuerdo a la
clase objeto que se llama. Esto permite al programa realizar movimiento sin tener
que verse conectado con cada tipo de pieza en particular.

Figura 11: Polimorfismo subtipado.

14

CAPTULO 2: EL MODELO DE DATOS ORIENTADOS A OBJETOS

El modelo de datos orientados a objetos es una extensin de paradigma

orientado a objetos. Los objetos que se utilizan en POO son anlogos a las
entidades que se usan en la Bases de datos orientadas a objetos puros pero
como una gran diferencia: los objetos del programa desaparecen cuando el
programa termina su ejecucin, mientras que los objetos de la base de datos
permanecen. A esto se le denomina persistencia.
2.1. RELACIONES:
Las relaciones se utilizan para hacer concatenaciones (join) de tablas. Por el
contrario en las BDOO implementan sus relaciones incluyendo en cada objeto
los identificadores de los objetos con los que se relaciona. Un identificador de
15

objeto es un atributo interno que tiene cada objeto. Ni los usuarios ni los
programadores pueden ver o manipular estos identificadores, estos son
asignados por el SGBD y es l el nico que los utiliza. Puede soportar la
relacin 1 a muchos, muchos a muchos y ya que el paradigma orientado a
objetos soporta la herencia, una base de datos orientada a objetos tambin
puede utilizar la relacin es un entre objetos. En teora una BDOO debe
soportar 2 tipos de herencia: la relacin es un y la relacin extiende. La
relacin es un, que tambin se conoce como generalizacin-especializacin,
crea una jerarqua donde las subclases son tipos especficos de las
superclases. Con la relacin extiende, sin embargo, una clase expande su
superclase en lugar de estrecharla en un tipo ms especfico.

2.2. Integridad

de relaciones:

Para que las relaciones funcionen en una BDOO pura, los identificadores de los
objetos deben corresponderse en ambos extremos de la relacin. Por ejemplo, si
los aparejadores de una empresa de control de calidad se deben relacionar con
las obras de construccin que supervisan, debe haber algn modo de garantizar
que, cuando un identificador de un objeto Obra se incluye en un objeto
Aparejador, el identificador de este mismo objeto Aparejador se debe incluir en el
objeto Obra anterior. Este tipo de integridad de relaciones, que es de algn modo
anlogo a la integridad referencial en las bases de datos relacionales, se gestiona
especificando relaciones inversas.
La clase Aparejador tiene un atributo de tipo conjunto llamado supervisa. Del
mismo modo la clase Obra tiene un atributo llamado es_supervisada. Para
garantizar la integridad de esta relacin, un SGBDOO puro deber permitir que el
diseador de la base de datos pueda especificar donde debe aparecer el
identificador del objeto inverso, como se muestra en las siguientes figuras:
En la clase Aparejador

Figura 12: Clase aparejador.

16

Y en la clase Obra

Figura 13: Clase Obra.

Siempre que un usuario o un programa de aplicacin inserta o elimina un
identificador de objeto de la relacin supervisa en un objeto Aparejador, el SGBD
actualizara automticamente la relacin es_supervisada en el objeto Obra
relacionado. Cuando se hace una modificacin en el objeto Obra, el SGBD lo
propagar automticamente al objeto Aparejador.
Del mismo modo que en las bases de datos relacionales es el diseador de la
base de datos el que debe especificar las reglas de integridad referencial, en las
BDOO es tambin el diseador el que debe especificar las relaciones inversas
cuando crea el esquema de la base de datos.

2.3. UML
Existen distintas notaciones o modelos para disear esquemas conceptuales de
BDOO, como las siguientes notaciones:

Notacin de Coad/Yourdon

Notacin de Shlaer/Mellor

OMT

Booch

17

Cada modelo presenta distintas deficiencias, por lo que algunos de sus autores
han desarrollado conjuntamente un lenguaje, denominado UML (lenguaje
unificado de modelado), que las evita.

CAPITULO 3: CARACTERISTICAS DE LAS BASE DE DATOS ORIENTADAS A

OBJETOS Y SU DIFERENCIA CON RESPECTO A LAS BASE DE DATOS
RELACIONALES

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 unvocamente 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 mtodos.
Las caractersticas asociadas a las BDOO son:

Objetos: cada entidad del mundo real se modela como un objeto.

La forma de identificar objetos es mediante un identificador de objetos

(OID, Object Identifier), nico para cada objeto. Generalmente 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.

18

Encapsulamiento: cada objeto contiene y define procedimientos (mtodos)

y la interfaz mediante la cual se puede acceder a l y otros objetos pueden
manipularlo. La mayora 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 tenga que
implementar una cantidad considerable de mtodos cuyo nico propsito
sea el de leer y escribir los atributos de un objeto. Generalmente, los
SGBDOO permiten al usuario especificar qu atributos y mtodos son
visibles en la interfaz del objeto y pueden invocarse desde afuera.

Otros conceptos utilizados de la misma manera que en la POO son:

o Clases
o Herencia simple, mltiple y repetida.
o Polimorfismo de operacin, de inclusin y paramtrico; ligadura
tarda (latebinding); sobrecarga (overloading) y suplantacin o
anulacin (overriding).
o Objetos complejos.

19

CAPITULO 4: VENTAJAS Y DESVENTAJAS DE LAS BDOO

Aunque los SGBDOO pueden proporcionar soluciones apropiadas para muchos

tipos de aplicaciones avanzadas de bases de datos, tambin tienen sus
desventajas.

4.1.Ventajas de un SGBDOO:

Mayor capacidad de modelado: El modelado de datos orientado a objetos

permite modelar el mundo real de una manera mucho ms fiel. Esto se
debe a:
o Un objeto permite encapsular tanto un estado como un comportamiento.
o Un objeto puede almacenar todas las relaciones que tenga con otros
objetos Los objetos pueden agruparse para formar objetos complejos
(herencia).

Ampliabilidad: Esto se debe a:

o Se pueden construir nuevos tipos de datos a partir de los ya existentes.
o Agrupacin de propiedades comunes de diversas clases e incluirlas en
una superclase, lo que reduce la redundancia.
o Reusabilidad de clases, lo que repercute en una mayor facilidad de
mantenimiento y un menor tiempo de desarrollo.

Lenguaje de consulta ms expresivo: El acceso navegacional desde un

objeto al siguiente es la forma ms comn de acceso a datos en un
SGBDOO. Mientras que SQL utiliza el acceso asociativo. El acceso
20

navegacional es ms adecuado para gestionar operaciones como los

despieces, consultas recursivas, etc.

Adecuacin a las aplicaciones avanzadas de base de datos: 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.

Mayores prestaciones. Los SGBDOO proporcionan mejoras significativas

de rendimiento con respecto a los SGBD relacionales. Aunque hay autores
que han argumentado que los bancos de prueba usados estn dirigidos a
aplicaciones de ingeniera donde los SGBDOO son ms adecuados.
Tambin est demostrado que los SGBDR tienen un rendimiento mejor que
los SGBDOO en las aplicaciones tradicionales de bases de datos como el
procesamiento de transacciones en lnea (OLTP).

4.2.

Desventajas de una BDOO:

Carencia de un modelo de datos universal: No hay ningn modelo de

datos que est universalmente aceptado para los SGBDOO y la mayora de
los modelos carecen una base terica.

Carencia de experiencia: Todava no se dispone del nivel de experiencia

del que se dispone para los sistemas tradicionales.

Carencia de estndares: Existe una carencia de estndares general para

los SGBDOO.

Competencia: Con respecto a los SGBDR y los SGBDOR. Estos productos

tienen una experiencia de uso considerable. SQL es un estndar aprobado
y ODBC es un estndar de facto. Adems, el modelo relacional tiene una
slida base terica y los productos relacionales disponen de muchas

21

herramientas de soporte que sirven tanto para desarrolladores como para

usuarios finales.

La optimizacin de consultas compromete la encapsulacin: La

optimizacin de consultas requiere una compresin de la implementacin
de los objetos, para poder acceder a la base de datos de manera eficiente.
Sin embargo, esto compromete el concepto de encapsulacin.

El modelo de objetos an no tiene una teora matemtica coherente que le

sirva de base.

CAPTULO 5: EL MODELO ESTNDAR ODMG

Un grupo de representantes de la industria de las bases de datos formaron el

ODMG
(Object Database Management Group) con el propsito de definir estndares para
los SGBD orientados a objetos. Este grupo propuso un modelo estandar para la
22

semntica de los objetos de una base de datos. Su ltima versin, ODMG 3.0,
apareci en enero de 2000. Los principales componentes de la arquitectura
ODMG para un SGBD orientado a objetos son los siguientes:

Modelo de objetos.

Lenguaje de definicin de objetos (ODL, Object Definition Language).

Lenguaje de consulta de objetos (OQL, Object Query Language).

Conexin con los lenguajes C++, Smalltalk y Java (al menos).

5.1. MODELO DE OBJETOS:

El modelo de objetos ODMG permite que tanto los diseos, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone de
las siguientes primitivas de modelado:

Los componentes bsicos de una base de datos orientada a objetos son los
objetos y los literales. Un objeto es una instancia auto contenida de una
entidad de inters del mundo real. Los objetos tienen algn tipo de
identificador nico. Un literal es un valor especfico, como Amparo o 36.
Los literales no tienen identificadores. Un literal no tiene que ser
necesariamente un solo valor, puede ser una estructura o un conjunto de
valores relacionados que se guardan bajo un solo nombre.

Los objetos y los literales se categorizan en tipos. Cada tipo tiene un

dominio especifico compartido por todos los objetos y literales de ese tipo.
Los tipos tambin pueden tener comportamientos. Cuando un tipo tiene
comportamientos, todos los objetos de ese tipo comparten los mismos
comportamientos. En el sentido prctico, un tipo puede ser una clase de la
que se crea un objeto, una interface o un tipo de datos para un literal (por
ejemplo, integer). Un objeto se puede pensar como una instancia de un
tipo.
23

Lo que un objeto sabe hacer son sus operaciones. Cada operacin puede
requerir datos de entrada (parmetros de entrada) y puede devolver algn
valor de un tipo conocido.

Los objetos tienen propiedades, que incluyen sus atributos y las relaciones
que tienen con otros objetos. El estado actual de un objeto viene dado por
los valores actuales de sus propiedades.

Una base de datos es un conjunto de objetos almacenados que se

gestionan de modo que puedan ser accedidos por mltiples usuarios y
aplicaciones.

La definicin de una base de datos est contenida en un esquema que se

ha creado mediante el lenguaje de definicin de objetos ODL (Object
Definition Language) que es el lenguaje de manejo de datos que se ha
definido como parte del estndar propuesto para las bases de datos
orientadas a objetos.

5.1.1. Los tipos de objetos

Los tipos de objetos se descomponen en atmicos, colecciones y tipos
estructurados.
Los tipos coleccin, que se derivan de la interface Collection, son la propuesta del
estndar para las clases contenedor. Los objetos coleccin identificados por el
estndar son los siguientes:

Set<tipo>: es un grupo desordenado de objetos del mismo tipo. No se

permiten duplicados.

24

Bag<tipo>: es un grupo desordenado de objetos del mismo tipo. Se

permiten duplicados.

List<tipo>: es un grupo ordenado de objetos del mismo tipo. Se permiten

duplicados.

Array<tipo>: es un grupo ordenado de objetos del mismo tipo que se

pueden acceder por su posicin. Su tamao es dinmico y los elementos se
pueden insertar y borrar de cualquier posicin.

Dictionary<clave,valor>: es como un ndice. Est formado por claves

ordenadas, cada una de ellas emparejada con un solo valor.

Los tipos estructurados son los siguientes:

Date: es una fecha del calendario (da, mes y ao).

Time: es una hora (hora, minutos y segundos).

Timestamp: es una hora de una fecha (con precisin de microsegundos).

Interval: es un periodo de tiempo.

Estos tipos tienen la misma definicin que los tipos con el mismo nombre del
estndar de SLQ.
Los objetos se crean utilizando el mtodo new() . Adems, todos heredan la
interface que se muestra a continuacin:

Figura 14: Interface Object.

25

Cada objeto tiene un identificador de objeto nico generado por el SGBD, que no
cambia y que no se reutiliza cuando el objeto se borra. Cada SGBD genera los
identificadores siguiendo sus propios criterios.
Los objetos pueden ser transitorios o persistentes. Los objetos transitorios existen
mientras vive el programa de aplicacin que los ha creado. Estos objetos se usan
tanto como almacenamiento temporal como para dar apoyo al programa de
aplicacin que se est ejecutando. Los objetos persistentes son aquellos que se
almacenan en la base de datos.

5.1.2. Literales:
Los tipos literales se descomponen en atmicos, colecciones, estructurados o
nulos. Los literales no tienen identificadores y no pueden aparecer solos como
objetos, sino que estn embebidos en objetos y no pueden referenciarse de modo
individual. Los literales atmicos son los siguientes:

boolean: un valor que es verdadero o falso.

short: un entero con signo, normalmente de 8 o 16 bits.

long: un entero con signo, normalmente de 32 o 64 bits.

unsigned short: un entero sin signo, normalmente de 8 o 16 bits.

unsigned long: un entero sin signo, normalmente de 32 o 64 bits.

float: un valor real en coma flotante de simple precisin.

double: un valor real en coma flotante de doble precisin.

octet: un almacn de 8 bits.

char: un carcter ASCII o UNICODE.

string: una cadena de caracteres.

enum: un tipo enumerado donde los valores se especifican explcitamente

cuando se declara el tipo.

Los literales estructurados contienen un nmero fijo de elementos heterogneos.

Cada elemento es un par <nombre, valor> donde valor puede ser cualquier tipo
26

literal. Los tipos estructurados son: date, time, timestamp, interval y struct. Y los
tipos coleccin son:

set<tipo>

bag<tipo>

list<tipo>

array<tipo>

dictionary<clave,valor>

5.1.3. TIPOS:
Una de las caractersticas ms importantes del paradigma orientado a objetos es
la distincin entre la interface pblica de una clase y sus elementos privados
(encapsulacin).
El estndar propuesto hace esta distincin hablando de la especificacin externa
de un tipo y de sus implementaciones.
Una interface es una especificacin del comportamiento abstracto de un tipo de
objeto y contiene las signaturas de las operaciones. Aunque una interface puede
tener propiedades (atributos y relaciones) como parte de su especificacin, estas
no pueden ser heredadas desde la interface. Adems, una interface no es
instanciable por lo que no se pueden crear objetos a partir de ella (es el
equivalente de una clase abstracta en la mayora de los lenguajes de
programacin).
Una clase es una especificacin del comportamiento abstracto y del estado
abstracto de un tipo de objeto. Las clases son instanciables, por lo que a partir de
ellas se pueden crear instancias de objetos individuales (es el equivalente a una
clase concreta en los lenguajes de programacin).
El estndar propuesto soporta la herencia simple y la herencia mltiple mediante
las interfaces. Ya que las interfaces no son instanciables, se suelen utilizar para
especificar operaciones abstractas que pueden ser heredadas por clases o por
otras interfaces. A esto se le denomina herencia de comportamiento y se
27

especifica mediante el smbolo :. La herencia de comportamiento requiere que el

spertipo sea una interface, mientras que el subtipo puede ser una clase o una
interface.
La herencia es una relacin es un:

Figura 15: Herencia BDOO.

La interface o clase ms baja de la jerarqua es el tipo ms especfico. Ya que
hereda los comportamientos de todos los tipos que tiene por encima en la
jerarqua, es la interface o clase ms completa. En el ejemplo anterior, los tipos
ms especficos son Silla, Mesa y Sof.
Uno de los beneficios prcticos de la herencia es que se puede hacer referencia a
los subtipos como su spertipo. Por ejemplo, un programa de aplicacin puede
hacer referencia a sillas, mesas y sofs como muebles o incluso como artculos de
venta. Esto hace que sea ms sencillo tratar los subtipos como un grupo cuando
sea necesario.
Los subtipos se pueden especializar como sea necesario aadindoles
comportamientos.
Los subtipos de un subtipo especializado heredan tambin los comportamientos
aadidos.
El modelo orientado a objetos utiliza la relacin extiende (extends) para indicar la
herencia de estado y de comportamiento. En este tipo de herencia tanto el subtipo
como el spertipo deben ser clases. Las clases que extienden a otra clase ganan
acceso a todos los estados y comportamientos del spertipo, incluyendo cualquier
cosa que el spertipo haya adquirido a travs de la herencia de otras interfaces.

28

Una clase puede extender, como mximo, a otra clase. Sin embargo, si se
construye una jerarqua de extensiones, las clases de ms abajo en la jerarqua
heredan todo lo que sus supertipos heredan de las clases que tienen por encima.
El modelo permite al diseador que declare una extensin (extent) para cada tipo
de objeto definido como una clase. La extensin de un tipo tiene un nombre e
incluye todas las instancias de objetos persistentes creadas a partir de dicho tipo.
Declarar una extensin denominada empleados para el tipo de objeto Empleado
es similar a crear un objeto de tipo Set<Empleado> denominado empleados. Una
extensin se puede indexar para que el acceso a su contenido sea ms rpido.
Una clase con una extensin puede tener una o ms claves (key). Una clave es un
identificador nico. Cuando una clave est formada por una sola propiedad, es
una clave simple; si est formada por varias propiedades, es una clave
compuesta. A diferencia del modelo relacional, las claves nicas no son un
requisito.
Una implementacin de un tipo consta de dos partes: la representacin y los
mtodos.
La representacin es una estructura de datos dependiente de un lenguaje de
programacin que contiene las propiedades del tipo. Las especificaciones de la
implementacin vienen de una conexin con un lenguaje (language binding). Esto
quiere decir que la representacin interna de un tipo ser diferente dependiendo
del lenguaje de programacin que se utilice y que un mismo tipo puede tener ms
de una representacin.
Los detalles de las operaciones de un tipo se especifican mediante un conjunto de
mtodos. En la especificacin externa de cada operacin debe haber al menos un
mtodo. Sin embargo, un tipo puede incluir mtodos que nunca se ven desde
fuera del tipo. Estos mtodos son los que realizan algunas funciones necesarias
para otros mtodos del tipo.
Los mtodos se escribirn en el mismo lenguaje de programacin utilizado para
expresar la representacin del tipo. Si una base de datos soporta aplicaciones
programadas en C++, Java y Smalltalk, entonces ser necesario tener tres

29

implementaciones para cada tipo, una para cada lenguaje, aunque cada programa
de aplicacin utilizara solo la implementacin que le corresponda.
5.1.4. PROPIEDADES:
El modelo de objetos ODMG define dos tipos de propiedades: atributos y
relaciones. Un atributo se define del tipo de un objeto. Un atributo no es un objeto
de primera clase, por lo tanto no tiene identificador, pero toma como valor un
literal o el identificador de un objeto.
Las relaciones se definen entre tipos. El modelo actual solo soporta relaciones
binarias con cardinalidad 1:1, 1:n y n:m. Una relacin no tiene nombre y tampoco
es un objeto de primera clase, pero define caminos transversales en la interface
de cada direccin. En el lado del muchos de la relacin, los objetos pueden estar
desordenados (set o bag) u ordenados (list). La integridad de las relaciones la
mantiene automticamente el SGBD y se genera una excepcin cuando se intenta
atravesar una relacin en la que uno de los objetos participantes se ha borrado. El
modelo aporta operaciones para formar (form) y eliminar (drop) miembros de una
relacin.

5.1.5. TRANSACCIONES:
El modelo estndar soporta el concepto de transacciones, que son unidades
lgicas de trabajo que llevan a la base de datos de un estado consistente a otro
estado consistente. El modelo asume una secuencia lineal de transacciones que
se ejecutan de modo controlado. La concurrencia se basa en bloqueos estndar
de lectura/escritura con un protocolo pesimista de control de concurrencia. Todos
los accesos, creacin, modificacin y borrado de objetos persistentes se deben
realizar dentro de una transaccin. El modelo especifica operaciones para iniciar,
terminar (commit) y abortar transacciones, as como la operacin de checkpoint.
Esta ltima operacin hace permanentes los cambios realizados por la transaccin
en curso sin liberar ninguno de los bloqueos adquiridos.
30

5.2. Lenguaje de definicin de objetos ODL:

ODL es un lengua je de especificacin para definir tipos de objetos para sistemas
compatibles con ODMG. ODL es el equivalente del DDL (lengua je de definicin de
datos) de los
SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la
signatura de las operaciones. La sintaxis de ODL extiende el lengua je de
definicin de interfaces (IDL) de la arquitectura CORBA (Common Object Request
Broker Architecture). El uso de ODL se muestra mediante un ejemplo:

Figura 16: El uso de ODL (Clase Persona)

31

Figura 17. El uso de ODL (Clase Estudiante, Clase Calificacion,

Clase EstudianteGrad)

32

Figura 18: El uso de ODL (Clase Titulo, Clase Departamento,

Clase Curso, Clase Edicion)

33

Figura 19: El uso de ODL (Clase EdicionActual)

5.3. Lenguaje de consulta de objetos OQL

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de
modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas
de alto nivel para conjuntos de objetos y estructuras. Est basado en SQL-92,
proporcionando un superconjunto de la sintaxis de la sentencia SELECT.
OQL no posee primitivas para modificar el estado de los objetos ya que las
modificaciones se pueden realizar mediante los mtodos que estos poseen.
La sintaxis bsica de OQL es una estructura SELECT...FROM...WHERE... ,
como en SQL.
Por ejemplo, la siguiente expresin obtiene los nombres de los departamentos de
la escuela de Ingeniera:

34

Figura 20: sintaxis bsica de OQL

En las consultas se necesita un punto de entrada, que suele ser el nombre de un
objeto persistente. Para muchas consultas, el punto de entrada es la extensin de
una clase. En el ejemplo anterior, el punto de entrada es la extensin
departamentos, que es un objeto coleccin de tipo set<Departamento>. Cuando
se utiliza una extensin como punto de entrada es necesario utilizar una variable
iteradora que vaya tomando valores en los objetos de la coleccin. Para cada
objeto de la coleccin (slo la forman objetos persistentes) que cumple la
condicin (que es de la escuela de Ingeniera), se muestra el valor del atributo
nombre.
El resultado es de tipo bag<string>. Cuando se utiliza SELECT DISTINCT... el
resultado es de tipo set ya que se eliminan los duplicados.
Las variables iterador se pueden especificar de tres formas distintas:

Figura 21: Primera

forma de una
variable iterador.
El resultado de una consulta puede ser de cualquier tipo soportado por el modelo.
Una consulta no debe seguir la estructura SELECT ya que el nombre de cualquier
objeto persistente es una consulta de por s. Por ejemplo, la consulta:
departamentos;

35

Devuelve una referencia a la coleccin de todos los objetos Departamento

persistentes. Del mismo modo, si se da nombre a un objeto concreto, por ejemplo
a un departamento se le llama departamentoinf (el departamento de informtica),
la siguiente consulta:
departamentoinf;
Devuelve una referencia a ese objeto individual de tipo Departamento. Una vez se
establece un punto de entrada, se pueden utilizar expresiones de caminos para
especificar un camino a atributos y objetos relacionados. Una expresin de camino
empieza normalmente con un nombre de objeto persistente o una variable
iterador, seguida de ninguno o varios nombres de relaciones o de atributos
conectados mediante un punto. Por ejemplo:
departamentoinf.director;
departamentoinf.director.categoria;
departamentoinf.tiene profesores;
La primera expresin devuelve una referencia a un objeto Profesor, aquel que
dirige el departamento de informtica. La segunda expresin obtiene la categora
del profesor que dirige este departamento (el resultado es de tipo string). La
tercera expresin devuelve un objeto de tipo set<Profesor>. Esta coleccin
contiene referencias a todos los objetos
Profesor que se relacionan con el objeto cuyo nombre es departamentoinf. Si se
quiere obtener la categora de todos estos profesores, no podemos escribir la
expresin:
departamentoinf.tiene profesores.categoria;
El no poder escribir la expresin de este modo es porque no est claro si el objeto
que se devuelve es de tipo set<string> o bag<string>. Debido a este problema de

36

ambigedad, OQL no permite expresiones de este tipo. En su lugar, es preciso

utilizar variables iterador:

SELECT p.categoria
FROM p in departamentoinf.tiene profesores;
SELECT DISTINCT p.categoria
FROM p in departamentoinf.tiene profesores;

En general, una
consulta OQL puede devolver un resultado con una estructura compleja
especificada en la misma consulta utilizando struct. La siguiente expresion:
departamentoinf.director.tutoriza; devuelve un objeto de tipo set<EstudianteGrad>:
una coleccin que contiene los estudiantes graduados que son tutorizados por el
director del departamento de informtica. Si lo que se necesita son los nombres y
apellidos de estos estudiantes y los ttulos que tiene cada uno, se puede escribir la
siguiente consulta:

Figura 22: Consulta ODL.

OQL es ortogonal respecto a la especificacin de expresiones de caminos:
atributos, relaciones y operaciones (mtodos) pueden ser utilizados en estas
expresiones, siempre que el sistema de tipos de OQL no se vea comprometido.
Por ejemplo, para obtener los nombres y apellidos de los estudiantes que tutoriza
el profesor Gloria Martnez, ordenados por su nota media, se podra utilizar la
siguiente consulta (el resultado, por estar ordenado, sera de tipo list):
37

Figura 23: Consulta ODL.

OQL tiene adems otras caractersticas que no se van a presentar aqu:

Especificacin de vistas dando nombres a consultas.

Obtencin como resultado de un solo elemento (hasta ahora hemos visto

que se devuelven colecciones: set, bag, list).

Uso de operadores de colecciones: funciones de agregados (max, min,

count, sum, avg) y cuantificadores (for all, exists).

Uso de group by

CAPTULO 6: CONCLUSIONES

38

BIBLIOGRAFIA:
39

(s.f.). Bases de Datos Orientadas a Objeto y el estndar ODMG.

Bertino, E., & Martino, L. (s.f.). Sistemas de bases de datos orientadas a

objetos: Conceptos y arquitecturas.

Connolly, T., & Begg, C. (s.f.). Sistemas de bases de datos: Un enfoque

prctico para diseo, implementacin y Gestin.

Elmasri, & Nawathe. (s.f.). Sistemas de Bases de Datos.

Johnson, J. (s.f.). Bases de Datos,Modelos, Lenguajes, Diseos.

Korth, H., & Silverschatz, A. (s.f.). Fundamentos de Bases de Datos.

Sudargham.

Silberschatz, Korth, & Sudarshan. (s.f.). Fundamentos de Bases de datos.

McGraw Hill.

40