Bdoo

Bases de datos orientadas a objetos
1
1

INDIC

Pag

Por qu surgen los SGBDOO? ....................................................................... 2
Qu es un SGBD? .......................................................................................... 2
Qu es un sistema de bases de datos orientadas a objetos? ........................... 3
Manifiestos acerca de los SGBDOO ............................................................... 4
Manifiesto de Atkinson .................................................................................... 5
Caractersticas obligatorias ................................................................ 5
Caractersticas opcionales .................................................................. 10
Opciones abiertas ............................................................................... 11
Manifiesto de Stonebraker ............................................................................... 11
Primer principio ................................................................................. 11
Segundo principio .............................................................................. 12
Tercer principio .................................................................................. 12
Tercer manifiesto ............................................................................................. 12
Lenguajes de definicin, manipulacin y consulta .......................................... 13

Qu es POET y qu ofrece? ............................................................................. 15
POET y C++ ..................................................................................................... 15

Diferencias entre SGBD SGBDOO .............................................................. 21
Observaciones complementarias ...................................................................... 22
Bibliografa ...................................................................................................... 22

2
1OR QU SURGN IOS SGBDOO?

Los sistemas de gestin de bases de datos orientadas a objetos surgen debido a la
falta de capacidad semntica del Modelo Relacional para atender nuevos tipos de
aplicaciones:
Diseo y fabricacin en ingeniera(CASE, CAD/ CAM)
Bases de datos grficas y de imgenes.
Bases de datos cientficas.
Sistemas de informacin geogrfica.
Bases de datos multimedia.
Acceso uniforme a sistemas de mltiples bases de datos.

Este tipo de aplicaciones necesita trabajar con datos de forma diferente a lo que
conocemos porque necesitan:
Estructuras ms complejas para los objetos.
Transacciones de mayor duracin.
Nuevos tipos de datos para almacenar imgenes o grandes bloques de texto
Necesidad de definir operaciones no estndar, especificas para cada aplicacin.
Controlar versiones y configuraciones.

QU S UN SGBD?

Un sistema de gestin de bases de datos es un conjunto de datos relacionados entre
s y un grupo de programas para tener acceso a esos datos. Las principales razones para
emplear un SGBD son:
Tamao. Cuando el volumen de informacin aumenta, es necesario algn
sistema que nos facilite el intercambio de informacin con memoria secundaria,
la bsqueda rpida, etc.
Concurrencia. Es necesario un mecanismo de control sobre la informacin
cuando sobre ella pueden existir varias personas o programas interactuando, de
modo que coordine sus accesos para que cada uno no invalide el trabajo
realizado por el resto.
Recuperacion e Integriaaa. Cuando la informacin sobre la que se est
trabajando es importante, es necesario algn mecanismo que se encargue de
protegerla de prdidas accidentales provocadas por fallos de energa, fallos de la
propia aplicacin, etc.
Persistencia. Representa la posibilidad de que la informacin permanezca an
despus de desconectar el ordenador.

Adems de lo anteriormente expuesto un SGBD suele proporcionar otras
capacidades adicionales, tales como:
Distribucion, o posibilidad de que la informacin est almacenada en lugares
diferentes. Los usuarios no necesitan conocer dnde est la informacin, el
SGBD la encuentra para ellos.
Seguriaaa, que permite restringir el acceso a la informacin a usuarios no
autorizados.

3
Aaministracion, que permite a los usuarios o administradores de bases de datos
examinar, controlar y ajustar el comportamiento del sistema. Permite por tanto
mantener las restricciones de integridad definidas por el usuario.

Un SGBD necesita para su funcionamiento dar soporte a tres reas bsicas
mediante un lenguaje para cada una de ellas:
Definicion ae Datos (Data Definition Language). Debe permitir a los usuarios
definir nuevas estructuras y tipos de informacin.
Manipulacion ae Datos (Data Manipulation Language). Debe permitir acceder a
las instancias de dichas estructuras de informacin, permitiendo incluso su
modificacin.
Consultas (Query). Debe permitir a los usuarios enunciar declarativamente la
informacin que desean, siendo el propio SGBD quin se encargue de obtenerla.
El soporte para la consulta suele incluir un motor que examinar la declaracin
de la informacin que se ha solicitado, elaborar un plan de ejecucin para
obtenerla, optimizar ese plan basndose en el conocimiento de la base de datos
(ndices, que informacin es local y cual es remota, etc.) y finalmente la
ejecutar.

QU S UN SISTMA D BAS D
DATOS ORINTADA A OBJTOS?

Las bases de datos de objetos estn diseadas para simplificar la programacin
orientada a objetos. Almacenan los objetos directamente en la base de datos, y emplean
las mismas estructuras y relaciones que los lenguajes de programacin orientados a
objetos.
Un SGBDOO es un sistema de objetos y un sistema de bases de datos. Se puede
entonces decir que un SGBDOO es un SGBD que almacena objetos, permitiendo
concurrencia, recuperacin...
Para los usuarios tradicionales de bases de datos, esto quiere decir que pueden
tratar directamente con objetos, no teniendo que hacer la traduccin a tablas o registros.
Para los programadores de aplicaciones, esto quiere decir que sus objetos se conservan,
pueden ser gestionados aunque su tamao sea muy grande, pueden ser compartidos
entre mltiples usuarios, y se mantienen tanto su integridad como sus relaciones.
Las bases de datos tradicionales almacenan slo datos, mientras que las bases de
datos orientadas a objetos almacenan objetos, con una estructura arbitraria y un
comportamiento. Una simple metfora (Esther Dyson) ayuda a ilustrar la diferencia
entre ambos modelos. Consideremos el problema de almacenar un coche en un garaje al
final del da. En un sistema de objetos el coche es un objeto, el garaje es un objeto, y
hay una operacin simple que es almacenar-coche-en-garaje. En un sistema relacional,
todos los datos deben ser traducidos a tablas, de esta forma el coche debe ser
desarmado, y todos los pistones almacenados en una tabla, todas las ruedas en otra, etc.
Por la maana, antes de irse a trabajar hay que componer de nuevo el coche para poder
conducir (problema: al componer piezas puede salir una moto en vez de un coche).

4
Como podemos ver un coche se representara dependiendo del tipo de sistema de
gestin de bases de datos:

Una posible solucin sera traducir cada objeto a tablas, pero esto es una tarea
tediosa, y en el caso de utilizar datos complejos puede llegar a ser excesivamente
complicado. El problema de la traduccin a tablas implica:
Tiempo ae aesarrollo. El tiempo empleado en generar el cdigo para la
traduccin de objetos a tablas y viceversa.
Errores. Debidos precisamente a esa traduccin.
Inconsistencia. Debida a que el ensamblaje/ desensamblaje puede realizarse de
forma diferente en las distintas aplicaciones.
Tiempo ae Efecucion. Empleado en el ensamblaje/ desensamblaje.

Muchos vendedores de bases de datos relacionales estn incorporando capas de
objetos sobre sus motores relacionales (basados en tablas), que son bastante tiles para
la integracin con aplicaciones y bases de datos de objetos, y que pueden ayudar en la
generacin de algunos cdigos de ensamblaje/ desensamblaje, pero no mejora en
absoluto el tiempo de ejecucin del problema (el coche todava necesita ser ensamblado
y desensamblado).

MANI1ISTOS ACRCA D IOS
SGBDOO
Manifiesto de los Sistemas de Bases de Datos al Objeto puras, ATKINSON, 1989
Enfoque purista que sostiene que los SGBO deben soportar una modelo
de objetos puros y no basarse en extensiones semnticas de modelos
clsicos como el relacional.
Manifiesto de los SBD de Tercera Generacin, STONEBRAKER, 1990
SGBD Relacionales extendidos que sean capaces de soportar los
conceptos de orientacin al objeto.
Postura que propugnan los principales vendedores de productos
relacionales.
Tercer manifiesto, DARWEN y DATE 1995
Reinterpretan el modelo relacional bajo la visin orientada al objeto.

5
MANI1ISTO D ATKINSON.
CARACTRSTICAS D IOS SGBDOO 1URAS
Las caractersticas que debe seguir una sistema de gestin de bases de datos para
considerarse orientado a objetos se dividen en tres grupos:
Obligatorias Trece reglas
Opcionales, aquellas que pueden aadirse para mejorar el sistema pero que no
son obligatorias Cinco reglas
Abiertas, aquellas que el diseador puede incluir para adaptar el sistema a sus
necesidades. Cuatro reglas

CARACTERSTICAS OBLIGATORIAS: 'Las reglas de oro"

I. TIpos comp!eJos
Un sistema de BBDDOO debe poder dar cabida a diferentes tipos de datos, desde
los ms sencillos a objetos ms complejos, todos ellos de pueden resumir en estos ocho:
Tipo abstracto para construir otros tipos. Permite construir nuevos tipos a
partir de caracteres, float, enteros. Por ejemplo: punteros, nmeros
complejos, cadenas de bits...
Array. Son matrices de elementos de datos, como los que podemos
encontrar en innumerables aplicaciones cientficas.
Secuencia ae tipo: Insertar elementos en una matriz en cualquier posicin.
Tuplas: Forma natural de representar las propiedades de una entidad.
Confunto: 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 heterogneas.
Composicion recursiva ael resto ae tipos, se utiliza para representar objetos
complejos, tales como documentos, espacios geomtricos...

II. IdentIdud de obJeto

La identidad es aquella propiedad de un objeto que lo distingue de todos los dems
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 IDO
(IDentificaaor ae Obfeto) 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 sern diferentes si tienen IDOs diferentes, aunque sus atributos tengan los
mismos valores. As, dos objetos pueden ser idnticos (son el mismo objeto, tienen el
mismo IDO) o iguales (tienen el mismo valor). Esto implica que dos objetos idnticos
son a su vez iguales, mientras que lo inverso no es cierto.

6
La identidad de los objetos es adems una potente primitiva que puede ser la base
para el manejo de tuplas, conjuntos, y objetos complejos recursivos. Tambin permite
operaciones tales como asignacin o copia de objetos.

III. ncupsu!umIento

El encapsulamiento se centra en la implementacin que da lugar al
comportamiento observable de un objeto. El encapsulamiento se consigue a menudo
mediante la ocultacin de informacin, es decir, se basa en ocultar todos los secretos de
un objeto que no contribuyen a sus caractersticas esenciales. El encapsulamiento
proporciona, por tanto, barreras explcitas entre abstracciones diferentes.

Existen dos visiones diferentes del encapsulamiento[ATK89], la primera y
original que es la del lenguaje de programacin; y la segunda que es la adaptacin de
esa visin 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 programacin la estructura de datos es claramente parte de la
implementacin y no de la interfaz.
Como se puede observar, el encapsulamiento proporciona una forma lgica de
independencia de los datos, ya que se puede cambiar la implementacin de un tipo sin
cambiar ninguno de los programas que usan ese tipo.

IV. TIpos y c!uses

Existen dos categoras principales de sistemas orientados a objetos, los que
soportan el concepto de clase 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, cul es
el orden y tipo de sus argumentos y cul es el tipo del resultado.
El concepto de clase es diferente al de tipo. Su especificacin es la misma que la
de un tipo, pero es una nocin de tiempo de ejecucin. Contiene dos aspectos:
La fabrica de objetos: crea nuevos objetos de la clase.
Almacn de objetos: conjunto de objetos que son las instancias de la clase, su
extensin.

7
A menuao los conceptos ae tipo y clase se utili:an inaistintamente. Sin embargo,
cuando ambos estn presentes en el mismo lenguaje, se puede decir que las clases
implementan a los tipos. Podemos entonces concluir afirmando que los tipos son la
puesta en vigor ae la clase ae los obfetos, ae moao que los obfetos ae tipos aistintos no
pueaen intercambiarse o. como mucho. pueaen intercambiarse ae formas muy
restringiaas.

V. HevencIu

Las clases o tipos heredan de sus ancestros.

Ventajas de la herencia:
Ayuda al modelado porque proporciona una descripcin concisa y precisa del
mundo.
Ayuda a compartir especificaciones e implementaciones en las aplicaciones

Tipos de herencia a destacar en los sistemas de gestin de bases de datos:
Herencia de sustitucin: en cualquier lugar donde podamos tener un objeto de
tipo t podemos sustituirlo por un objeto de tipo t si t hereda de t (este tipo de
herencia se basa en la similitud del comportamiento).
Herencia de inclusin: corresponde a la nocin de clasificacin y se basa en la
estructura del objeto, no en las operaciones. Afirma que t es subtipo de t si cada
objeto de tipo t es tambin un objeto de tipo t.
Herencia de restriccin: es un subcaso de la herencia de inclusin. Un tipo t es
un subtipo de t si est formado por todos los objetos de t que satisfacen una
restriccin dada.
Herencia de especializacin: un tipo t es un subtipo de un tipo t si los objetos
del tipo t son objetos del tipo t que contienen informacin ms especfica.
VI. 1o!ImovIIsmo, sobvecuvgu y !Iguduvu tuvdIu

Existen casos en los que se desea tener el mismo nombre para diferentes
operaciones. Supongamos la operacin 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 visualizacin. Es decir, necesitamos
visualizar un conjunto cuyos miembros no se conocen en tiempo de compilacin.
En una aplicacin 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 operacin en una clase ms general. As dibuja
tendr un nico nombre y podr emplearse indiferentemente sobre cualquier figura.
nicamente se redefinir la implementacin de las operaciones para cada una de las
subclases; esto es lo que se llama suplantacion. El hecho de que el mismo nombre de
operacin denote varios programas distintos es lo que se conoce como sobrecarga o
polimorfismo. De esta manera, para visualizar un conjunto de elementos simplemente
aplicaremos la operacin dibuja a cada uno de ellos, y el sistema ser el que se encargue
de seleccionar la implementacin adecuada en tiempo de ejecucin.
Para proporcionar esta nueva funcionalidad, el sistema no puede asociar los
nombres de las operaciones con los mtodos correspondientes en tiempo de

8
compilacin; se har en tiempo de ejecucin. Esto es lo que se conoce como ligaaura
taraia, y dificulta o imposibilita el chequeo de tipos.

VII. Comp!etud de c!cu!os

Puede expresarse cualquier funcin computable utilizando el lenguaje de
modificacin de datos de un sistema de base de datos.

VIII. tensIbI!Idud

El conjunto de tipos predefinidos que aporta el sistema de base de datos debe ser
extensible mediante algn mecanismo que permita definir tipos nuevos.
No debe haber distincin en cuanto al uso de los tipos definidos por el sistema y
los extendidos.

IX. 1evsIstencIu

La persistencia es una de las caractersticas 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 conservacin de los
datos, mientras que la persistencia heredada del modelo de objetos hace referencia no
slo a la conservacin del estado de un objeto, si no tambin a la conservacin de la
clase, que debe trascender a cualquier programa individual, de forma que todos los
programas interpreten de la misma manera el estado almacenado.
Se puede distinguir entre:
Persistencia en el espacio, que hace referencia al hecho de que los objetos
creados en una mquina puedan llevarse a otra, y que incluso puedan tener
representaciones diferentes en diferentes mquinas.
Persistencia en el tiempo, hace referencia a la cualidad de los objetos de
sobrevivir a la ejecucin del proceso que los cre.

X. GestIn de u!mucenumIento

La gestin del almacenamiento secundario es soportada por un conjunto de
mecanismos que no son visibles al usuario, tales como gestin de ndices, agrupacin de
datos, seleccin del camino de acceso, optimizacin 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,
crendose de esta forma una independencia entre los niveles lgicos y fsicos del
sistema.


9
XI. ConcuvvencIu

El SGBO debe gestionar el acceso de mltiples usuarios a la vez. Soportando la
nocin de atomicidad de una secuencia de operaciones y la comparticin controlada.
Debe ofrecerse serializacin de las operaciones.
Si se introduce concurrencia en nuestro sistema hay que considerar cmo 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 algn mecanismo de exclusin mutua,
de forma que el estado del objeto sobre el que se acta no est corrupto cuando los dos
objetos activos intentan actualizarlo simultneamente. En presencia de la concurrencia
no hay que definir simplemente los mtodos de un objeto; hay que asegurarse tambin
de que la semntica de estos mtodos se mantiene a pesar de la existencia de mltiples
usuarios concurrentes.

XII. RecupevucIn

El sistema debe proporcionar como mnimo el mismo nivel de recuperacin 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:
Interrupcin en el suministro de energa, de forma que se pierda la informacin
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 errneas a los usuarios y que la base de datos entre en un estado
incongruente.

Una vez que el subsistema de recuperacin de la base de datos ha detectado el
fallo, procede a su clasificacin (ya que cada uno de ellos debe manejarse de manera
diferente), para posteriormente restaurar la base de datos al estado anterior al de la
ocurrencia del fallo.

XIII. 1ucI!Idud de consu!tus ud-noc

El sistema debera proporcionar la funcionalidad de un lenguaje de consulta
aa hoc, es decir, permitir al usuario hacer cuestiones sencillas a la base de datos. Este
tipo de consultas tienen como misin proporcionar la informacin solicitada por el
usuario de una forma correcta y rpida.
En los SGBDOO los lenguajes de consulta constituyen una funcionalidad
importante.
Estos lenguajes de consulta deben satisfacer cuatro criterios:
Ser de alto nivel, es decir, deben ser capaces de expresar consultas no triviales
en pocas palabras.
Ser aeclarativos, es decir, que la atencin se dirija hacia el QUE se desea, y no
hacia COMO se obtiene.

10
Ser eficientes. esto es, la formulacin de la consulta debe permitir alguna forma
de optimizacin.
Ser inaepenaientes ae la aplicacion, es decir, debera trabajar sobre cualquier
base de datos.

Pero a diferencia de los SGBD relacionales, en los sistemas orientados a objetos,
los lenguajes de consulta no constituyen la nica forma de acceder a los datos. En los
SGBDOO tambin se puede acceder a los datos de forma navegacional. Esta forma de
acceso se basa en los identificadores de los objetos y en la jerarqua de agregacin, de
forma que dado un IDO, el sistema accede al objeto directamente y navega a travs de
los objetos a los que se refieren sus atributos.

CARACTERSTICAS OPCIONALES

I. HevencIu mu!tIp!e

Tipo de herencia que permite a una clase tener ms de una super-clase y heredar
caractersticas de sus ancestros. As, si un sistema ofrece herencia mltiple pueden
surgir una serie de conflictos, como el hecho de que dos o ms superclases tengan un
atributo con el mismo nombre, pero con dominios diferentes . Tambin puede ocurrir
que exista herencia repetiaa, esto pasa cuando dos o ms superclases "hermanas",
comparten una superclase comn, 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. CompvobucIn de tIpos

El SGBDOO debe realizar una comprobacin de tipos para evitar posibles
problemas de rebasamiento y compatibilidad de tipos en ejecucin.

III. DIstvIbucIn

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 operacin de manera transparente.

IV. TvunsuccIones de dIseno

V. VevsIones

La mayora de las nuevas aplicaciones, tales como CAD/CAM y CASE,
comprenden una actividad de diseo que requiere alguna forma de versionado.

11
Una versin es una instantnea semnticamente significativa tomada al objeto de
diseo en un momento dado en el tiempo. Una versin de un objeto se crea a partir de
las modificaciones hechas en el tiempo a las versiones previas de ste, comenzando con
una versin inicial. La traza de estas aerivaciones se mantiene a travs de una historia
de las versiones.
Una versin de un objeto complejo puede constar de las versiones especficas de
sus objetos componentes.

OPCIONES ABIERTAS

I. 1uvudIgmu de pvogvumucIn
II. SIstemu de vepvesentucIn
III. SIstemu de tIpos
IV. UnIIovmIdud

MANI1ISTO D STONBRAKR
Se considera el manifiesto de definicin de sistemas gestores de bases de datos de
tercera generacin siendo
SGBD primera generacin: Sistemas Jerrquicos y de Red.
SGBD segunda generacin: Sistemas Relacionales.
SGBD tercera generacin: siguiente generacin de sistemas de bases de datos
cuyos principios bsicos de desarrollo presenta el manifiesto.

Las caractersticas se recogen en tres principios bsicos junto con trece
proposiciones que indican los requerimientos ms especficos de estos sistemas, las
cuales no difieren mucho de las trece caractersticas obligatorias que indicaba el
manifiesto de Atkinson. As los tres principios y las proposiciones para conseguirlos son
los siguientes:

Primer PRINCIPIO
ADEMS DE LOS SERVICIOS TRADICIONALES DE GESTIN DE DATOS, LOS SGDB DE
TERCERA GENERACIN PROPORCIONARN GESTIN DE OBJETOS Y REGLAS MS RICAS.

Proposiciones:
1.1 Los SGBD de la tercera generacin debe tener un sistema de tipos rico
1.2 La herencia es aconsejable
1.3 La reutilizacin y la encapsulacin son aconsejables.
1.4 Se deberan asignar IDO para los registros slo si no est disponible una
clave primaria.
1.5 Las reglas de convertirn en una caracterstica primordial de los futuros
sistemas. Las reglas no deberan asociarse con una funcin especfica.


12
Segundo PRINCIPIO
LOS SGDB DE TERCERA GENERACIN DEBEN INCLUIR A LOS SGBD DE SEGUNDA

Proposiciones
2.1 Un SGBD de la tercera generacin debe tener un lenguaje de acceso
declarativo y de alto nivel.
2.2 Deben existir dos formas de especificar colecciones: por enumeracin de sus
miembros o mediante un lenguaje de consulta.
2.3 Las vistas deben ser actualizables.
2.4 Los indicadores de resultados no deben aparecer en los datos.

Tercer PRINCIPIO
LOS SGDB DE TERCERA GENERACIN DEBEN ESTAR ABIERTOS A OTROS SUBSISTEMAS.

Proposiciones:
3.1 Se puede acceder a un SGBD de tercera generacin desde mltiples
lenguajes de alto nivel.
3.2 Debe soportar la persistencia de las variables.
3.3 El lenguaje SQL es una forma universal de expresin de datos.
3.4 Las consulta y sus respuestas deben constituir el nivel ms bajo de
comunicacin entre un cliente y un servidor.

TRCR MANI1ISTO
El enfoque purista ha sido duramente criticado por expertos de bases de datos
relacionales:
Los productos relacionales se apoyan en un lenguaje basado en la
lgica, que lleva ms de dos mil aos demostrando su validez.
Sera una pena desperdiciar ms de veinte aos de investigacin y
desarrollo en bases de datos relacionales.

El Tercer Manifiesto, DARWEN y DATE, 1995
Reinterpreta el modelo relacional bajo una visin orientada al objeto.
Propone un lenguaje D que proporciona algunas ventajas de la
orientacin al objeto, como los tipos de datos y la herencia, manteniendo
el fundamento terico del modelo relacional. No se trata de una
extensin del lenguaje SQL.
Segn el manifiesto, tal lenguaje D, debe estar sujeto a una serie de
prescripciones, proscripciones y lo que denomina sugerencias muy
fuertes las cuales divide en categoras.
RM: surgen del Modelo Relacional
OO: no surgen del Modelo relacional


13
INGUAJS D D1INICION (ODI),
MANI1UIACION(OMI) Y
CONSUITA(OQI)
Lenguaje ODL
El DDL o lenguaje de definicin de datos, se utiliza para expresar la estructura y
condiciones de integridad sobre el esquema de la base de datos. En una base de datos
relacional define las tablas, los atributos en la tabla, el dominio de los atributos y las
restricciones sobre un atributo o una tabla.
En un SGBDOO el DDL debe ser empleado para definir no slo lo anteriormente
mencionado, si no tambin para definir mtodos, datos compuestos, relaciones ISA,
herencia, etc.
El DDL propuesto por ODMG-93 Estandarizacin de los sistemas de bases de
datos orientados a objetos denominado ODL pretende principalmente facilitar la
portabilidad de los esquemas de las bases de datos. Este ODL no es un lenguaje de
programacin completo, define las propiedades y los prototipos de las operaciones de
los tipos, pero no los mtodos que implementan esas operaciones.

El ODL intenta definir tipos que puedan implementarse en diversos lenguajes de
programacin; no est por tanto ligado a la sintaxis concreta de un lenguaje de
programacin particular. De esta forma un esquema especificado en ODL puede ser
soportado por cualquier SGBDOO que sea compatible con ODMG-93.
La sintaxis de ODL es una extensin de la del IDL ( Interface Definition
Language) desarrollado por OMG como parte de CORBA (Common Object Request
Broker Architecture).
A continuacin se va a exponer un breve ejemplo de definicin de una interfaz
mediante el lenguaje de definicin (ODL). La interfaz representada corresponde al tipo
Seccin del diagrama anterior:


14
,QWHUIDFH Seccion
( H[WHQW secciones
.H\ (es_seccion_de, numero))
{
DWWULEXWH 6WULQJ numero;
UHODWLRQVKLS Profesor Es_asesorada_por LQYHUVH Profesor::Ensea;
UHODWLRQVKLS PA Tiene_PA LQYHUVH PA::Asiste;
UHODWLRQVKLS Curso Es_seccion_de LQYHUVH Curso::Tiene_secciones;
};
La traduccin ODL-C++, por ejemplo, se expresar como una librera de clases y
una extensin a la gramtica estndar de definicin de clases de C++.
Lenguaje OML
El lenguaje de manipulacin es empleado para la elaboracin de programas que
permitan crear, modificar y borrar datos que constituyen la base de datos.
ODMG-93 no propone un OML estndar, simplemente sugiere que este lenguaje
sea la extensin de un lenguaje de programacin, de forma que se puedan realizar entre
otras las siguientes operaciones sobre la base de datos:
Creacin de un objeto
Borrado de un objeto
Modificacin de un objeto
Identificacin de un objeto
Lenguaje OQL
El lenguaje de consulta propuesto por ODMG-93, presenta las siguientes caractersticas:
No es computacionalmente completo. Sin embargo, las consultas pueden invocar
mtodos, e inversamente los mtodos escritos en cualquier lenguaje de
programacin soportado pueden incluir consultas.
Tiene una sintaxis abstracta.
Su semntica formal puede definirse fcilmente.
Proporciona un acceso declarativo a los objetos.
Tiene una sintaxis concreta al estilo SQL, pero puede cambiarse con facilidad.
Puede optimizarse fcilmente.
No proporciona operadores explcitos para la modificacin, se basa en las
operaciones definidas sobre los objetos para ese fin.
Proporciona primitivas de alto nivel para tratar con conjuntos de objetos, pero no
se restringe slo a ellas.


15

QU ES POET Y QU OFRECE

POET es una base de datos orientada a objetos que soporta la semntica de C++ y
Java. Es potente y fcil de usar. POET, utiliza clases y objetos para proporcionar las
siguientes caractersticas:
Encapsulacin
Herencia
Polimorfismo
Tipos de datos definidos por el usuario
Identidad
Modelos naturales para las relaciones entre objetos

Por ser una base de datos ofrece las siguientes caractersticas:
Persistencia
Gran capacidad de almacenamiento
Consultas basadas en valores
Comparticin de objetos entre programas
Sofisticado manejo de errores para operaciones de la base de datos

Adems, por ser orientada a objetos soporta:
Solucin a las referencias en un programa
De una a varias referencias
Consultas basadas en valores con rpida respuesta
ndices
Manejo de objetos inteligentes
Miembros temporales
POET es eficiente para realizar programas largos y complicados y tambin para
aquellos que manejen grandes cantidades de datos y consultas que necesiten una
respuesta rpida.

POET Y C++

I. COMO HACR UNA CIAS 1RSISTNT
Para hacer que una clase de C++ sea persistente slo hay que aadir la palabra
reservada persistent delante de ella:
persistent class Persona
{
private:
char nombre[30];
short edad;
Address direccion;
public:
};

16
Nuestro compilador de C++ no reconoce esta palabra (persistent). Por eso este
tipo de clases se deben declarar en un fichero a parte con extensin. HCD, as el
precompilador (PTXX) puede crear un archivo que permita tener clases persistentes con
cualquier compilador de C++. Adems el precompilador crea la clase diccionario para la
base de datos y produce clases especificas de administracin que permiten crear colas y
manejar los objetos persistentes. Cualquier objeto de una clase persistente puede ser
almacenado en una base de datos. POET crea la base de datos a partir de las clases que
hemos declarado persistentes, e introduce la definicin de dichas clases en el
diccionario de datos

II. ABRIR Y CRRAR UNA BAS D DATOS

PtBase es una clase que representa una base de datos particular en un programa
que utilice en POET como complemento a C++.
Cuando se abre una base de datos se crea un objeto PtBase que se puede utilizar
para sealar objetos de la base de datos.
Se pueden tener varios objetos PtBase abiertos simultneamente, esto implica que
podemos abrir varias bases de datos en un programa, lo cual nos da mucha versatilidad
en programacin de nuestros sistemas de gestin. Un objeto puede hacer referencia a
otros en la misma base de datos o usar referencias cruzadas para otros objetos en otras
bases de datos. La versin Cliente/ Servidor de POET permite la concurrencia de
usuarios.
Antes de abrir una base de datos se debe llamar a la funcin global InitPOET() que
crea un objeto PtRoot para manejar las bases (de la clase Ptbase) que se abren. Para
abrir la base de datos se utiliza la funcin PtRoot:: GetBase() .El primer parmetro es el
nombre del servidor al que nos queremos conectar. LOCAL significa que estamos en
el modo de un solo usuario; si queremos conectarnos a un servidor hay que especificar
su nombre. Para cerrar la base de datos se utiliza la funcin PtRoot::UngetBase().
Un ejemplo:
#include <poet.hxx>
int main(int, char**)
{
InitPOET(PtTransactionByBase,ClientName);
PtBase* pObjBase;
// Abrimos la base de datos
int err=PtBase::POET()->GetBase(LOCAL, base,pObjBase);
if (err < 0)
{
PtBase::POET()->UngetBase(pObjBase);
ErrorExit(Could not open database, err);
}
// Cerramos la base de datos
PtBase::POET()->UngetBase(pObjBase);
DeinitPOET();
return 0;
}


17
III. AIMACNAR UN OBJTO

Si tenemos un objeto persistente, podemos asignarlo a una base de datos y
almacenarlo.
Persona *pPersona = new Persona;
pPersona->Assign(pObjbase);
err = pPersona->Store();
check(err);

IV. AIIST: NCONTAR UN OBJTO N UNA BAS D
DATOS

Cuando el precompilador encuentra la declaracin de una clase, se crea un
conjunto que almacena objetos de todo tipo. Este conjunto se denomina AllSet.
Podemos ir recorriendo este conjunto para encontrar todos los objetos de un tipo
especificado:
PersonaAllSet TodasPersonas(pObjbase);
Persona* pPersona;
long i;
for(i=0;TodasPersonas.Get(pPersona,i,PtSTART)==0;i++)
{
pPersona->DoSomething();
TodasPersonas.Unget(pPersona);
// borra el objeto si no se esta usando
}
Un AllSet contiene tambin objetos cuyas clases son derivadas de la clase. (Si, por
ejemplo, tenemos tres clases llamadas Estudiantes, Sacerdotes y Programadores que
derivan de Personas, todos los objetos que derivan de estas clases tambin se encuentran
en PersonaAllSet).

V. NCONTRAR OBJTOS UTIIIZANDO 1UNTROS

Los programas de C++ utilizan habitualmente punteros y referencias para mostrar
las relaciones entre objetos. POET intenta que las referencias que se encuentran en el
programa se mantengan en la base de datos. Por ejemplo, si tenemos una persona en la
base de datos y queremos acceder a los datos de los padres de esa persona directamente
usando punteros:
{
....
public:
Persona* padre;
Persona* madre;
....
};


18
Esto conlleva dos problemas: nuestra base de datos tiene que ser capaz de
encontrar punteros en los objetos definidos por el usuario, adems, tiene que ser capaz
de representar referencias de punteros de manera que las direcciones sean
independientes.
ENCONTRAR LOS PUNTEROS
Para poder encontrar los punteros necesitamos acceder a la declaracin de la clase.
Como los compiladores no son capaces de acceder a esta informacin, POET lo ha
implementado en su propio precompilador.
POET no permite que no se inicialicen los punteros, si se le asigna un valor que no
sea 0 se asume que el objeto no es correcto.

VI. CONSUITAS: NCONTRAR OBJTOS USANDO
VAIORS

Como C++ no proporciona ningn lenguaje estndar de consulta, POET lo ha
implementado incluyendo funciones en una biblioteca de clases. Como las consultas
deben estar estructuradas en funcin de los elementos en una clase, el precompilador
genera una clase consulta para cada una de las clases que pueden ser almacenadas en la
base de datos. Las consultas son capaces de soportar los condicionales:
menor que mayor que igual a menor o igual que mayor o igual
que adems se pueden utilizar las operaciones
and or not or exclusivo
Por supuesto, tambin se admiten parntesis en las consultas.
UNA CONSULTA SIMPLE
Una clase consulta contiene mtodos para decidir las condiciones de una consulta.
Por ejemplo, la clase consulta para la clase Persona tendra una funcin miembro para
cada objeto derivado de la clase Persona
{ PtString Nombre; };

Despus, el precompilador generar la siguiente clase consulta:
class PersonQuery: public PtQuery
{public:
SetName (PtString& param, PtCmpOp co = PtEQ);
};
Cuando utilizamos esta clase consulta para ver, por ejemplo, todas las personas
cuyo nombre empieza por A, necesitamos un AllSet (PersonasAllSet) para poder ver
a todas las personas que cumplen esta caracterstica.
// En el fichero PERSON.HCD :
typedef lset<Persona*> PersonaSet;
// En el fichero fuente:
PersonaAllSet* all = new PersonaAllSet(&objbase);
PersonaSet* result = new PersonaSet;
PersonaQuery q;
Persona* pPersona;
q.SetName ((PtString) "A*", PtEQ );
// PtString permite comodines
all->Query ( &q, result );

19
// Imprimimos el conjunto de resultados...
for (int i=0;
result->Get(pPerson, i, PtSTART) == 0; ++i)
{
pPerson->Print();
result->Unget(pPerson);
}
delete all;
delete result;
UNA ORDENACIN SIMPLE
Para especificar el tipo de orden del resultado de una consulta, la clase consulta
generada por el precompilador tiene funciones especificas:
PersonQuery : public PtQuery
{
...
public:
SortByName(PtSortOp mode);
SortByFirstName(PtSortOp mode);
...
};
NDICES
Los ndices proporcionan rapidez a las consultas y son tiles para definir el orden
que se desea obtener en el resultado. Para construir un ndice, se declara con la palabra
reservada useindex en la clase y se utiliza la siguiente sintaxis:
{
char nombre [30];
Address direccion;
useindex PersonaIndex;
....
};
indexdef PersonaIndex : Persona
{
nombre[[10]];
//Se encuentran en el ndice los 10 primeros carac.
};
La declaracin de indexdef puede contener cualquier numero de miembros, y el
tipo de orden se toma desde el principio hasta el final de la declaracin.
Una clase puede tener cualquier numero de ndices, pero hay que tener en cuenta
que cada nuevo ndice ocupa espacio en el disco duro y POET se ve forzado a actualizar
el rbol de ndices cada vez que se aade un nuevo objeto, por lo tanto no se debe
abusar de esta gran facilidad que nos ofrece el sistema de gestin de bases de datos
orientada a objetos POET.


20
VII. MIMBROS TM1ORAIS

Como no siempre se quiere almacenar todo lo que esta relacionado con un objeto,
existe la posibilidad de declarar los miembros de una clase como temporales con la
palabra reservada transient (transitorios).
{
private:
char name [30];
Address address;
transient WINDOW *viewer;
public:
....
};
Para que este tipo de declaraciones no d problemas habr que inicializar los
miembros temporales usando PtObject::Activate(), como se describe en la siguiente
seccin.

VIII. ACTIVACION D OBJTOS

POET no asume ninguna responsabilidad respecto a los objetos temporales y, por
tanto no sern inicializados cuando se lea un objeto de la base de datos. Sin embargo,
POET da a cada objeto persistente una funcin virtual que es llamada cuando un objeto
se lee de la base de datos en memoria. La funcin se denomina PtObject::Activate(), y si
se vuelve a definir esta funcin en la declaracin de la clase POET llamara a la nueva
funcin definida cada vez que se carga un objeto de esa clase por su propia definicin
de clase abstracta:
{
private:
PtString nombre;
transient WINDOW * viewer;
public:
virtual void Activate(){viewer = new WINDOW; }
};
Antes de que POET llame a la funcin Activate() recin definida, construye el
objeto en memoria y carga todos los datos miembros de la base de datos.

IX. 1ROTGR UN OBJTO - CONCURRNCIA

Si varios programas acceden a la vez a la misma base de datos puede que nos
interese protegerlo. POET permite proteger un objeto cuando lo lees, proteger los
resultados de una consulta, o proteger todos los objetos en AllSet. Se pueden especificar
distintas clases de proteccin y se puede especificar a qu objetos se referir esta
proteccin.
Por ejemplo, supongamos que queremos proteger un objeto para que nadie
sobrescriba sobre l, mientras estamos leyndolo. La forma de conseguirlo es

21
especificar la proteccin en el mtodo Get(). El objeto se desprotege cuando se llame a
Unget(). El cdigo para realizar esto podra ser el siguiente:
PtLockSpec LockSpec(PtLK_WRITEvWRITE, PtFLAT);
// proteccion contra escritura, flat
MyAllSet.Get(&p, 0, PtSTART, &LockSpec);
// Inicializar la proteccin
p->ChangeYourself();
p->Store();
p->Unget(&p, &LockSpec); // Libera la proteccin
X. TRANSICIONS

Las transiciones permiten realizar cambios en la base de datos y se realizan de
forma atmica, es decir, cuando comienzas una transaccin usando
PtBase::BeginTransaction(), todos los cambios que puedan realizarse en la base de
datos se guardan en memoria cach en vez de escribirse directamente . Si se llama a la
funcin PtBase::CommitTrnsaction(), todos los cambios que se guardaban en la
memoria cach son escritos en la base de datos. Durante una transaccin se pueden
quitar todos los cambios con la llamada a la funcin PtBase::AbortTransaction(). Si se
produce un error antes de que se produzca el asentimiento de la transaccin, los cambios
que se pretenden realizar no tienen efecto, as, siempre estaremos en un estado
consistente.

XI. DTCTANDO VNTOS

A veces un programa necesita saber qu esta ocurriendo en la base de datos. POET
permite insertar funciones llamadas callback que son llamadas cuando se cumple una
condicin especifica. La deteccin de eventos se utiliza fundamentalmente para:
Progress callbacks: determinar cada cierto tiempo que tanto por ciento de las
operaciones en la base de datos ha sido completado.

Watch & Notify: informar al programa sobre lo que otros usuarios estn
haciendo con los objetos en la base de datos.
Si queremos actualizar un objeto mientras que otro usuario esta cambindolo
slo tendremos que aadir la palabra clave watch.


22
DI1RNCIAS NTR SGBD SGBDOO
SGBD Re!ucIonu!es:
Los datos residen en la base de datos y los procesos se encuentran en las
aplicaciones desarrolladas mediante el lenguaje de datos asociado al SGBD
(SQL) inmerso en un lenguaje de programacin.
Desarrollo bajo Sistemas Relacionales:
o Modelo conceptual de datos modelo lgico
Eficientes para aplicaciones tradicionales de negocios.

SGBD OvIentudos u obJetos:
Gestionan objetos en los cuales estn encapsulados los datos y las operaciones
que actan sobre ellos.
Desarrollo bajo SGBDOO: un nico modelo subyacente, implementado en el
SGBBOO, al que pueden acceder directamente las aplicaciones.
Intentan satisfacer necesidades de aplicaciones ms complejas.
Caracterstica clave: poder que dan al diseador de la base de datos tanto para
especificar la estructura de los objetos complejos como las operaciones que se
pueden aplicar a estos objetos.

ObsevvucIones comp!ementuvIus
El objeto de estudio de este trabajo es muy amplio, por lo tanto debido al lmite
tanto en espacio como en tiempo de exposicin, as como nuestro escaso conocimiento
previo; nos obliga a presentar a presentar solo una mnima parte de lo que suponen los
sistemas de gestin de bases de datos orientados a objetos. As pues si alguien desea
ampliar ms informacin sobre este tema, disponemos de ms datos acerca de:
- Java en POET
- Comparacin de C++ y Java en POET.
- Ms informacin sobre los manifiestos
- Modelo de objetos de Poet
- Modelo de objetos de ODMG-93 que es el sistema que parte de
las caractersticas que se indican en el tercer manifiesto.

BIb!IogvuIIu
Ana Beln Martnez Prieto Introduccin a los sistemas de gestin de bases de
datos orientados a objetos Universidad de Oviedo
M Jos Polo Martn Apuntes de la asignatura Ampliacin de Bases de datos
Segundo curso de Ingeniera Superior en Informtica de sistemas Universidad
de Salamanca
Malcolm P. Atkinson, Franois Bancilhon, David J. DeWitt, Klaus R. Dittrich ,
David Maier, Stanley B. Zdonik The Object-Oriented Database System
Manifesto (1989)

23
Michael Stonebraker The Third-Generation Database Manifiesto: A Brief
Retrospection (1990)
Hugh Darwen, C. J. Date The Third Manifesto (1995)
Manual del programador Poet C++ - http: //www.poet.com

Bdoo

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bdoo

Cargado por

Copyright:

Formatos disponibles

Bases de datos orientadas a objetos

También podría gustarte