DISEÑO DE UN SISTEMA MANEJADOR DE BASES DE DATOS

ORIENTADO A OBJETOS

NELSON JAVIER CELIS CRUZ YELIXE MENDOZA USCATEGUI

Ingeniero del software Ingeniería del software
Universidad Francisco de Paula Santander Universidad Francisco de Paula Santander
nelsonjcelisc@yahoo.com Yelixemendoza@yahoo.com
COLOMBIA COLOMBIA

RESUMEN
El propósito de este artículo es difundir las conclusiones establecidas por los autores en el proyecto: “Diseño de
un sistema manejador de base de datos orientado a objetos”. Los sistemas manejadores de bases de datos
orientados a objetos aprovechan la expresividad del paradigma de la orientación a objetos para elaborar
esquemas de bases de datos más robustos y completos que facilitan la construcción de software más complejo
como: Aplicaciones CAD, CAM, GIS, y software de lógica descriptiva. Actualmente existen estándares y
herramientas que pueden ser utilizados en la elaboración de un sistema manejador de bases de datos orientado a
objetos para solucionar problemas como la persistencia de los objetos y la comunicación entre el cliente y el
servidor, centrándose en el problema de diseñar e implementar un lenguaje de manipulación y definición de
datos, y la transformación semántica entre el objeto y sus relaciones con otros objetos.

PALABRAS RELEVANTES y transformen a las bases de datos relacionales

?? SMBDOO
?? IDL
?? OQL
?? Persistencia
?? Orientación a objetos
1 INTRODUCCIÓN
Los sistemas de gestión de bases de datos
orientados a objetos (SGBDOO) heredan las
funcionalidades propuestas para los sistemas
de gestión de bases de datos (SGBD) más la
funcionalidad de un modelo de datos orientado
a objetos (MDOO) [7] como se ilustra en la
figura 1.
SGBDOO = SGBD + MDOO
Figura 1. Composición de un SGBDOO
De esta forma, un SGBDOO tiene
características que pertenecen a los sistemas
de gestión de base de datos como:
persistencia, concurrencia, procesamiento de
consultas ad-hoc, y características que
pertenecen al modelo de datos orientado a
objetos como: manejo de objetos complejos,
identidad del objeto, encapsulamiento, tipos o
clases, herencia, polimorfismo y sobrecarga.
Al utilizar un modelo de datos orientado a
objetos se hace más fácil modelar o abstraer
sistemas del mundo real. En la actualidad los
ingenieros de software y desarrolladores que
utilizan metodologías que se apoyan en UML
ocupan parte del proceso de diseño e
implementación en elaborar clases que oculten
en aparentes objetos perdiendo tiempo en
dichos procesos. La promesa que hacen los
SGBDOO es eliminar este desfase y
proporcionar un SGBD que sea accesible
desde múltiples lenguajes de alto nivel.
ODMG [8], Object Data Management Group,
representa el primer intento de estandarización
de las bases de datos orientadas a objetos.
Este grupo está integrado por los principales
fabricantes de SGBDOO existentes en el
mercado. En el año de 1990 la ODMG propone
tres principios básicos para los SGBD de
tercera generación (3G).
Se enmarcan los siguientes principios:
Principio 1: “Además de los servicios
tradicionales de gestión de datos, los SGBD 3G
proporcionarán gestión de objetos”
Principio 2: “Los SGBD 3G deben subsumir los
SGBD de segunda generación (ó relacionales)”
Principio 3: “Los SGBD 3G deben ser abiertos
a otros subsistemas”
El estándar ODMG versión 3.0 [3][8] establece
una serie de características básicas sobre la
base de datos, el modelo de datos, el lenguaje
de especificación de objetos y el lenguaje de
consulta.
En la actualidad existen distintos manejadores
de bases de datos orientados a objetos, desde
algunos bastante primitivos que simplemente
proporcionan persistencia y el manejo de
algunos tipos de relaciones entre objetos hasta
otros muy completos que soportan
características como: capacidad de
concurrencia, almacenamiento de métodos en
la base de datos, lenguajes de consulta,
manejo de herencia simple, tecnología cliente /
servidor, entre otras [3].
La arquitectura de un sistema es la estructura
conceptual que permite definirlo y especificarlo
por medio de la identificación del conjunto de
piezas que lo componen y cómo estas se
relacionan entre sí.
En mayo de 1985 el consorcio
ANSI/X3/SPARC presenta un modelo de
referencia para el desarrollo de las bases de
datos el cual es utilizado como marco de
referencia para el estudio, descripción y
análisis de los sistemas manejadores de bases
de datos.
El modelo de referencia ANSI/X3/SPARC está
conformado por tres niveles o componentes
que conforman un sistema manejador de base
de datos (figura 2).
HGD
LD LDi
SCTD SO
Figura 2. Modelo ANSI/X3/SPARC
El modelo de referencia (MR), se conforma de
las siguientes piezas: El sistema de control de
transformación de datos (SCTD), que funciona
cómo núcleo (corazón) del sistema de manejo
de bases de datos, y proporciona los
operadores para la descripción y manipulación
de datos; La interfaz de lenguaje de datos
interno (LDi) por medio del cual el SCTD,
establece la conexión con los servicios
proporcionados por el sistema operativo (SO);
La interfaz de lenguaje de datos (LD), lenguaje
que permite a los usuarios del sistema realizar
peticiones de recuperación de datos al SCTD;
Y finalmente las herramientas de gestión de
datos (HGD), que son los programas de
aplicación que permiten a los usuarios
interactuar con el SCTD y realizar la correcta
administración de las bases de datos.
2 ARQUITECTURA CORBA DE
OMG
Una aplicación es un conjunto de clases e
instancias que interactúan a través del corredor
de requerimientos de objetos, que es un bus de
software que permite que los objetos hagan y
reciban peticiones y respuestas (figura 3).
Cada aplicación o servicio se modela como un
objeto.
OS: Es la colección de objetos de servicio que
proveen las funciones básicas para crear y
mantener objetos de cualquier categoría.
FC: Es la colección de clases y objetos que
proveen capacidades de propósito general que
son útiles en cualquier aplicación.
OA: Son los objetos específicos de cualquier
aplicación de usuario final.
OA FC
Corredor de
requerimientos de objetos
OS
Figura 3. Arquitectura básica CORBA
3 CONCEPTOS BÁSICOS
Un objeto modela cualquier entidad identificada
unívocamente, que persiste a lo largo del
periodo de vida del objeto y que es
independiente de las propiedades y
comportamientos del objeto.
Las operaciones se aplican a los objetos. Las
operaciones asociadas con un objeto
caracterizan su comportamiento. Los objetos se
crean como instancias de los tipos. Un tipo
caracteriza el comportamiento de sus
instancias por medio del conjunto de
operaciones asociadas con el tipo. Las
interrelaciones entre los tipos son supertipo y
subtipo.
El estado de un objeto es el conjunto de
valores e interrelaciones de dicho objeto. Cada
objeto tiene una identidad única distinta e
independiente de cualquier otra característica.
La identidad es constante (inmutable). Cada
objeto tiene un identificador que denota o
refiere a dicho objeto (OId).
El conjunto de los OIds se denota como Obj.
Los objetos no cambian de tipo.
Cada operación tiene una firma que consiste de
un nombre, un conjunto de parámetros y un
conjunto de resultados.
El conjunto de todas las firmas de un tipo es la
interfaz del tipo y ella incluye las que son
heredadas de sus supertipos.
Cada instancia de un tipo satisface la interfaz ?? El número y tipo de los parámetros es el
de dicho tipo. mismo
El conjunto de todas las instancias de un tipo ?? El número y tipo de los resultados es el
es la extensión del tipo. mismo
Los tipos se organizan en jerarquía formando
un digrafo acíclico. Los tipos abstractos no tienen instancias y
La raíz de la jerarquía es el tipo Objeto. sirven para definir estructura y comportamiento
Los nuevos tipos creados por las aplicaciones común para los subtipos. Cuando una
son subtipos del tipo Objeto. operación es pedida, se selecciona una
El conjunto de todos los tipos de objetos se implementación de la misma para ser
denomina OTipos. ejecutada. Este proceso se denomina
despachar.
Valores que no son objetos se denominan no-
objetos. El conjunto de los objetos y los no- La operación Omega: omega:(X1: sigma1, X2:
objetos conforman todos los valores sigma2, ..., Xn: sigman)=> (Y 1: ro1, Y2: ro2,...,
denotables, DVal. Ym : rom )
El conjunto de los no-objetos se denomina cuando es invocada r1 ,..., rm <= omega(E 1, E2,
NObj. ..., En)
El conjunto de los tipos de los no-objetos se donde omega es el nombre de Omega, Ei son
denomina NTipos. los argumentos de entrada y ri los resultados.
DVal=Obj/\NObj Una petición es válida si los Ei se pueden
evaluar en alfai o en sus tipos inmediatos alfai
Cada no-objeto debe pertenecer a un tipo menor o igual que sigmai.
NTipo. Estos no forman parte de la jerarquía de
objetos. La firma garantiza que la petición regrese un
No se especifican operaciones para los objetos conjunto de resultados betai del tipo o de su
y los no-objetos, ya que sus tipos son tipo inmediato betai menor o igual que roi.
diferentes. La semántica del pase de argumentos es por
Una operación describe una acción que se valor.
puede aplicar a los parámetros. Una clase define una especificación y una
La invocación de una operación es un evento implementación del tipo.
que puede producir: Un objeto es una instancia de una clase.
Los tipos pueden tener varias
?? Un conjunto de resultados inmediatos implementaciones, por lo cual sus instancias
(Observador) pueden pertenecer a varias clases.
?? Efectos colaterales expresados en un
cambio de estado (Transformador) 4 DISEÑO DE UN SISTEMA
?? Excepciones (Errores y advertencias) MANEJADOR DE BASES DE
DATOS ORIENTADO A
Cada tipo T que pertenece a OTipos tiene un
conjunto de operaciones Ops(T) = {Omega1 ,
T OBJETOS.
T La realización del SMBDOO enmarca las
Omega2 ,..}
Especialización y generalización son relaciones siguientes actividades:
entre los tipos que están basadas en sus
interfaces. Ellas definen las reglas por las ?? Elaboración de un modelo de datos
cuales unos objetos de un tipo son aceptados orientado a objetos.
en el contexto de otro tipo. ?? Definición de la estructura y el
Herencia es un mecanismo para re-usar almacenamiento físico de los datos.
estructura y comportamiento, lo cual permite ?? Definición del mecanismo de comunicación
que un tipo sea definido en términos de otro. entre el sistema de base de datos y los
Un objeto es una instancia directa de un tipo si usuarios.
ella es una instancia de ese tipo y no de los ?? Definición de un modelo para acceder a la
subtipos del tipo. base de datos orientada a objetos.
Si S es un subtipo de T (T es un supertipo de 4.1 ELABORACIÓN DE UN MODELO
S), entonces para cada operación Omegak T DE DATOS ORIENTADO A
que pertenece a Ops(T) existe una operación
correspondiente OmegajS que pertenece a
OBJETOS.
Ops(S) tal que : El modelo de datos indica al SMBD y al usuario
el modo de abstraer los sistemas analizados
que hacen parte del mundo real, de aquí surge
?? Tienen el mismo nombre
la importancia de establecer el modelo de
datos.
Elisa Bertino menciona sobre el modelo de
datos: “No hay un modelo común a utilizar
como punto de referencia, ningún fundamento
formal,tampoco ningún estándar para los
modelos orientados a objetos, como si lo hay
en el caso del modelo relacional” [5]. Por lo
tanto, el modelo de datos debe ser el primer
resultado del diseño pues es el punto de
partida para realizar el diseño del SMBD.
Para la realización del modelo de datos se
utiliza el estándar UML [10] (lenguaje unificado
de modelado, por sus siglas en ingles) como
herramienta para representar simbólicamente
el conjunto de datos persistentes relacionados
entre sí, es decir, los esquemas de bases de
datos.
Las características distintivas incluidas en el
modelo de datos orientado a objetos son:
4.1.1 Clases
Las clases representan la forma de modelar
entidades del mundo real que presentan
atributos y métodos comunes. Una
característica típica de los objetos en un
SMBDOO es su persistencia. Los objetos o
instancias de clases son persistentes cuando
pueden almacenarse en memoria secundaria
(una base de datos o un archivo) y recuperarse
posteriormente, en lugar de existir solo en
memoria principal. El modelo de datos adiciona
la característica de persistencia al representar
clases que abstraen objetos persistentes,
clases persistentes. Para diferenciar una clase
como persistente se adiciona junto al nombre
de la clase la etiqueta “<<persistente>>” como
se muestra en la figura 4
Nombre
<<persistente>>
Atributos
Métodos
Figura 4. Representación de una clase
persistente.
El modelo de datos introduce las etiquetas de
persistencia para que el ingeniero de software
logre incluir las clases persistentes y no
persistentes en un solo diagrama de clases;
facilitando de esta forma un mejor
entendimiento del sistema analizado y las
relaciones entre las clases.
4.1.2 Agregación y composición
La agregación y la composición describen
objetos compuestos de otros objetos, los
conceptos de agregación y composición
difieren en que la composición permite a los
objetos parte, existir al eliminar el objeto
compuesto, en cambio la agregación elimina
los objetos parte junto con el objeto
compuesto. La agregación es representada por
un rombo sin rellenar, la composición también
es representada por un rombo pero relleno.
4.1.3 Herencia
La herencia se representa con una flecha que
apunta al padre. Además el modelo de datos
exige que si una clase hija es persistente
entonces su padre debe ser persistente y
pertenecer a la misma base de datos para que
de este modo el SMBD pueda proporcionar
integridad referencial. En la figura 5 se muestra
un ejemplo de la representación de herencia
entre una persona (clase padre) y un empleado
(clase hija) para un esquema de base de datos.
persona
<<persistente>>
- id
- nombre
- dirección
+ agregar ()
+ eliminar ()
empleado
<<persistente>>
- sueldo
- jefe
+ calcular_sueldo()
+establecer_sueldo()
Figura 5. Representación de herencia
4.1.4 Representación de una base de
datos
Si el analista y/o diseñador del sistema
considera conveniente separar las clases
persistentes para concebirlas como una base
de datos puede hacerlo utilizando un paquete
de base de datos. Además si el sistema maneja
mas de una base de datos, es ventajoso indicar
la base de datos a la que pertenece.
Un paquete en UML es un elemento que
agrupa a su vez otros elementos dentro de él.
El paquete de base de datos es un paquete
que agrupa clases persistentes y sus
relaciones, es decir, un paquete de base de
datos contiene el diagrama de clases
persistentes.
Un paquete se simboliza por una carpeta con
nombre y los elementos que contiene. Para
representar un paquete de base de datos se almacenados y el valor es el contenido del
adiciona junto al nombre que identifica el atributo, llamaremos a estos archivos físicos:
paquete, la etiqueta “<<base de datos>>” como pila de instancias de la clase n, donde n es el
se ilustra en la figura 6. nombre de la clase.

Nomina Cada objeto del esquema de base de datos

<<base de datos>> tendrá su propia pila de instancias sin importar
si presenta relaciones de herencia,
persona composición, agregación y asociación, los
<<persistente>>
* objetos relacionados se almacenan en la lista
- id
- nombre de propiedades del objeto, en donde en el
- departamento 1 campo valor contendrá el ido del objeto
+ agregar () departamento referenciado.
+ eliminar () <<persistente>>
+ consultar () - id
- nombre
Se dice entonces que el conjunto de
+ agregar() propiedades almacenadas para un objeto en la
+eliminar() pila de instancias representa una instancia de
una clase.
4.2.3 Diccionario de datos.
Figura 6. Representación de un paquete de Base El diccionario de datos se describe como la
de datos
base de datos que utiliza el SMBD para ejercer
control sobre la integridad de los datos, el
4.2 DEFINICIÓN DE LA diccionario de datos almacena la descripción
ESTRUCTURA Y EL de las clases y sus relaciones (agregación,
ALMACENAMIENTO FÍSIC O DE composición, herencia, asociación).
LOS DATOS.
El diccionario de datos contiene un grafo
4.2.1 Identificadores de objetos (IDO)
dirigido para cada uno de los tipos de
Una clase es la abstracción de un conjunto de
relaciones: un grafo que representa las
objetos. Cada objeto es identificado con un IDO
relaciones de agregación (grafo de
[1] [5] que es asignado por el sistema, trayendo
agregación), un grafo que representa las
como ventaja que el programador no tiene que
relaciones de composición (grafo de
preocuparse por asignar una clave que
composición), un grafo que representa las
identifique al objeto; cada IDO es único en la
relaciones de asociación (grafo de asociación)
base de datos.
y un grafo que representa las relaciones de
herencia (grafo de herencia) que tiene la
El concepto de IDO introduce 2 nociones de
particularidad de ser acíclico. Entiéndase por
igualdad entre objetos:
clases los vértices del grafo.
?? Identidad por igualdad: consiste en que 2
El conjunto de vértices representa cada una de
objetos son idénticos si tienen el mismo las clases del esquema de base de datos y el
IDO.
conjunto de aristas representa las relaciones
?? Igualdad por valor: consiste en que 2 entre las clases.
objetos son iguales si los valores de sus
atributos son iguales. El SMBD no almacena los métodos en la base
de datos, posteriormente se aclarara en donde
La identidad subsume la igualdad, es decir, 2 se almacenan los métodos de las clases.
objetos pueden ser iguales pero no idénticos y
si 2 objetos son idénticos necesariamente son Para la realización de consultas sobre la base
iguales. de datos los grafos tienen la propiedad de crear
subgrafos con los vértices solicitados en la
Los dos proporcionan un soporte importante consulta incluyendo sus aristas. Este aspecto
para establecer mecanismos que controlen la es de especial cuidado pues se tiene que
integridad y persistencia de los objetos. prever que vértices adicionales deben ser
4.2.2 Almacenamiento de los objetos. incluidos en el subgrafo de consulta.
Los objetos son almacenados en archivos
físicos con la siguiente estructura: <IDO, Para un subgrafo de consulta de herencia se
atributo, tamaño, valor> para cada atributo del trae toda la jerarquía de herencia de los
objeto; donde el IDO es el identificador único vértices solicitados ya que es posible que el
del objeto, el atributo es el nombre del atributo usuario solicite un atributo de una clase padre.
del objeto, el tamaño es el número de bytes
Para un subgrafo de consulta de agregación se
traen las clases referenciadas a la clase
solicitada. Para un subgrafo de composición se
traen las clases anexadas a la clase solicitada.
Además al traer clases adicionales a las
solicitadas se debe tener en cuenta que éstas a
su vez deben cumplir las condiciones
anteriormente mencionadas.
4.3 DEFINICIÓN DEL MECANISMO
DE COMUNICACIÓN ENTRE EL
SISTEMA DE BASE DE DATOS
Y LOS USUARIOS.
Esta actividad define el lenguaje de
manipulación y definición de los datos que
utiliza el usuario. Desafortunadamente hasta la
fecha no se ha profundizado mucho en el
estudio de este tópico y solo se han elaborado
unas conclusiones tempranas al respecto.
Estas son:
El lenguaje de definición de datos es la interfaz
que presenta el SMBD al usuario para poder
implementar el esquema de base de datos, el
SMBD diseñado utilizara el lenguaje IDL
propuesto en el estándar CORBA para definir
las clases persistentes y sus relaciones
(agregación, herencia, composición,
asociación). El SMBD presentará un
componente que interprete las declaraciones
de clases realizadas por el usuario y con este
genere el archivo físico que contendrá la pila de
instancias y la actualización del diccionario de
datos, es decir, la vinculación de la clase a
cada uno de los grafos de relaciones.
El lenguaje de manipulación de datos permite
al usuario crear instancias de una clase,
modificar sus atributos, eliminar instancias y
consultar los datos.
El SMBD diseñado contempla dos maneras de
realizar operaciones sobre los datos:
El primero, un lenguaje de consultas tipo SQL
llamado lenguaje de consulta a objetos (OQL,
por sus siglas en ingles), que funcionaría de la
siguiente manera: en vez de enviar de manera
directa la consulta al SMBD, éste proporcionará
una clase que gestione las consultas, y será a
través de ésta clase que el usuario realizará
sus consultas, una vez procesada la consulta
en el SMBD se retornará al usuario una clase
llamada “resultado_de_consulta” que se
compone de un conjunto de instancias que son
el resultado de una consulta OQL (figura 7). A
bajo nivel el “resultado_de_consulta” manejará
una lista doblemente encadenada en donde
cada nodo contendrá una instancia; se le
deberá enviar además al
“resultado_de_consulta” una cabecera donde
se indique el numero de atributos, valor,
nombre del atributo y tipo de dato, para que el
resultado de consulta pueda proveer al usuario
un procedimiento que facilite el acceso a los
atributos de las instancias por medio de sus
nombres.
El segundo método para realizar operaciones
sobre los datos es a través de un conjunto de
atributos proporcionados por la propia clase,
con la limitación de que solo será posible hacer
consultas exclusivamente a la clase.
Las operaciones de inserción, eliminación y
actualización de instancias se llevarán a cabo
exclusivamente desde la clase.
Como es necesario que toda clase que
pertenezca a la base de datos proporcione
mecanismos de inserción, eliminación,
actualización y persistencia, se exige que las
clases hereden de una clase base que
proporcione los mecanismos anteriormente
mencionados.
4.4 DEFINICIÓN DE UN MODELO
PARA ACCEDER A LA BASE DE
DATOS ORIENTADA A
OBJETOS.
En esta etapa se definen los métodos de
comunicación entre el cliente y el servidor,
pues se tiene como requisito del sistema
soportar la arquitectura Cliente/Servidor. Con
métodos de comunicación se quiere decir todo
lo necesario para que el sistema funcione en
redes siendo la comunicación entre el cliente y
el servidor transparente para el usuario.
Sin duda alguna la creación de un protocolo de
alto nivel que soporte la comunicación de los
objetos a través de la red requiere una cantidad
de tiempo considerable e innecesaria ya que
actualmente existen estándares que facilitan
estos servicios; teniendo en cuenta el principio
de la ODMG que dice: “Los SGBD 3G deben
ser abiertos a otros subsistemas” se elige el
estándar abierto para la comunicación entre
objetos CORBA propuesto por el grupo OMG
(grupo de administración de objetos, por sus
siglas en ingles)(ver figura 7).
SMBD
Consulta Resultado
consuta
USUARIO
Figura 7. Esquema de comunicación básico.
“La Arquitectura Común de Mediador de
Peticiones (CORBA The Common Object
Request Broker) del Grupo de Administración
de Objetos (OMG) suministra una arquitectura
independiente de la plataforma e independiente
del lenguaje de programación para la escritura
de aplicaciones distribuidas orientadas a
objeto.” [6].
En la sección 2.2.3 de este articulo se
mencionó que el SMBD almacenaría
únicamente los atributos y relaciones de las
clases y no se aclaró en que lugar ó quien era
el responsable de contener los procedimientos
de las clases. El encargado de ejecutar y
almacenar los procedimientos de las clases es
un mediador de peticiones de objetos (ORB,
por sus siglas en ingles).
Además de almacenar y ejecutar los
procedimientos de las clases el ORB tiene las
siguientes responsabilidades:
?? Retornar los objetos de tipo
“resultado_de_consulta”.
?? Recibir y enviar al SMBD las peticiones del
usuario ya sea de definición de datos (idl) o
manipulación de datos (oql ó los
procedimientos de las clases que
pertenecen a la base de datos).
?? Retornar al usuario mensajes, de error ó
información, que lance el SMBD.
5 CONCLUSIONES.
El SMBD diseñado posee la
arquitectura (ver figura 8):
SMBDOO
Pila de instancias
Diccionario de datos
ORB
Repositorio de clases
Cliente
Figura 8. Esquema básico de SMBDOO
propuesto
Este diseño se apoya en la arquitectura
CORBA, como se menciono anteriormente,
para los procesos de comunicación con el
cliente. El SMBDOO esta compuesto por tres
piezas básicas:
Pila de instancias: encargada del
almacenamiento físico de los atributos de los
objetos en estructuras de almacenamiento
<IDO, atributo, tamaño, valor>. La pila de
instancias administra estos atributos en
archivos separados, uno para cada clase.
Además se encarga de administrar las distintas
bases de datos separándolas en paquetes.
Estos paquetes podrían representarse en disco
como un árbol de directorios, al igual que en
Java.
Diccionario de datos: el cual contiene toda la
información necesaria para controlar la
integridad de los datos, en éste se almacena la
descripción de las clases y sus relaciones
(agregación, composición, herencia,
asociación), estas relaciones se almacenan
como un grafo dirigido, en realidad un grafo
para cada una de las relaciones como se
mencionó en la sección 2.2.3.
ORB: el ORB CORBA proporciona la
comunicación entre el SMDB y el cliente y
ejecuta los procedimientos de las clases. A su
vez el ORB contiene un repositorio de clases
en el cual se almacenan todas las clases de las
distintas bases de datos. Para diferenciar las
siguiente distintas bases de datos (paquetes de bases de
datos) se representaran en disco como un árbol
de directorios al igual que la pila de instancias,
nótese que la pila de instancias y el repositorio
de clases podrían o no compartir el mismo
espacio físico en disco, pero con el propósito
de crear un modelo flexible se conciben como
artefactos almacenados en ubicaciones
distintas. Además el hecho que ORB se
encuentre dentro de el SMBDOO no quiere
decir que en la practica se encuentre en la
misma computadora el ORB y el SMBDOO.
El SMBDOO se encarga de:
?? Recibir y procesar las peticiones de
manipulación y definición de datos.
?? Enviar mensajes.
?? Enviar instancias.
Cliente: el cliente se comunica de manera
bidireccional con el ORB.
?? Envía peticiones de creación de clases con
el lenguaje idl.
?? Envía consultas a varias clases por medio
de las clases de gestión de consultas que
contienen la sentencia oql del usuario.
?? Envía por medio de los procedimientos de
las clases que pertenecen a la base de
datos peticiones para insertar, actualizar,
eliminar y filtrar valores de las clases.
?? Recibe mensajes del SMBD.
?? Recibe objetos de tipo
“resultado_de_consulta”.
?? Recibe objetos de la base de datos.
6 REFERENCIAS
[1] Johnson, James L. Database: models,
languages, design. Oxford University Press.
1997.
[2] C.J. Date. Introducción a los sistemas de
bases de datos. Volumen I. Quinta Edición.
Addison Wesley. 1998.
[3] Ana Belén Martínez Prieto. Un Sistema de
Gestión de Bases de Datos Orientadas a
Objetos sobre una Máquina Abstracta
Persistente. Universidad de Oviedo. 2001.
[4] Dany Leonardo Martínez Murcia. Davinci:
Prototipo de un Sistema Manejador de Bases
de Datos Orientado por Objetos. Universidad
Francisco de Paula Santander. 2000.
[5] Elisa Bertino. Sistemas de Bases de Datos
Orientados a Objetos. Addison Wesley. 1995.
[6] Common Objects Request Broker
Architecture. http://www.jguru.com.
[7] Todd R. Manion. Objects Objects
Everywhere. http://www.acm.org/crossroads/
xrds7-3/objects.html. ACM Crossroads Student
Magazine.
[8] Ramakanth S. Devorakonda. Sistemas de
bases de datos relacionado a objetos.
http://www.acm.org/crossroads/xrds7-
3/ordbms.html. ACM Crossroads Student
Magazine. Estándar ODMG.
http://www.odmg.org.
[9] Peter Kueng. Comparison of ten OODBMS.
Institute of computer science.
[10] Rational Software Corporation. The Unified
Modelling Language: Notation and Semantics
Gudes. http://www.rational.com
[11] Isabel Besembel. Modelo de objetos OMG.
http://www.pgcomp.ula.ve/DISTANCI
A/BDA/omg.html.
[12] Won Kim. Modern Database Systems: The
Object Model Interoperability, and Beyond.
ACM Press.
[13] Esperanza Marcos Martínez. Bases de
Datos Orientadas a Objetos.
http://kybele.escjet.urjc.es/documentos/bd/tema
2.pdf. Universidad Rey Juan Carlos. Grupo de
investigación Kybele.