S.E.I.T. D.G.I.T. S.E.P.
/I I1
CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO
TECNOL~GI$O
,
cenidet It
TRADUCTOR DE CONSULTAS DEL
MODELO RELACIONAL AL MODELO'ORIENTADO A OBJETOS I \
I1
TESIS
Que para obtener el grado de Maestro en Cien'ciac en Ciencias Computjcionaies
José Aurelio Cota Zazueta
I
presenta
I
Directores de Tesis M.C. Mario Guillén Rodriguez
M.C. Humberto Hernández Garcia
I CUERNAVACA MORELOS DICIEMBRE DE 1999
Centro Nacional de Investigación y Desarrollo Tecnológico I1
FORM4 C3 REVISION DE TESIS
I1
Cuernavaca, Morelos a 7 de Diciembre de 199! '!
M.C. Máximo López Sánchez Presidente de la Academia de Ciencias Computacionales Presente I'
I1
Nos es grato comunicarle, que conforme a losi lineamientos para la obtención del grado dt Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesi! denominada: Traductor de Consultas del Mbdelo Relaciona1 al Modelo Orientado i
Objetos, realizada por el C. José Aurelio Cota.'kazueta, y habiendo cumplido con todas la! correcciones que le fueron indicadas, acordamos'no tener objeción para que se le conceda I¿ autorización de impresión de la tesis. I
.., , .. . . .... , .. i..,,... i,
. . . . , Sin otro particular, quedamos de usted. , . 1 ' l ?
I... ' ., 1, T .--,-.. 1^ - .. ,
. < . . J $ y . .I .:.-e . I,.... ,. , i
Atentamente
La comisión de revjsion de tesis . ..:, ...., >.
.. ,. .. ~1 . <..
Dr. G h e m6 Rddriguez Ortiz P / I!
'J
c\. G " < k L *- M.C. Mario Guillén Rodriguez
Director d e tesis M.C? Humbqz6 Hernández Garcia
-.-6irector de tesis ,I
C.C.P. Dr. Javier Ortiz HernandedJefe del Departarnento'ide Ciencias Cornputacionales
INIERIOR IMERNADO PALMIRA m. CUERMVACA. MOR MÉXICO
EMM orti7lolcnnirl~f P A I my
APARlADo POSTAL 5-1 64 CP 62050, CUERMVACA. TELS.(73)12 2314.12 7613.18 7741.FA%[73)12 2434
Centro Nacional de Investigación y Desarrollo Tecnológico FORMAlC4 I
AUTORIZACION DE IMPIRES16N DE TESIS 1 8
Cuernavaca, Morelos. A 7 de Diciembre de 1999 11
C. José Aureiio Cota Zazueta Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente
Después de haber atendido las indicaciones sbgeridas por la *&omisión Revisora de la Academia de Ciencias Cornputacionales en relahión a su trabajo de tesis: Traductor de Consultas del Modelo Relaciona1 al Modelo Orie'ntado a Objetos, me es grato comunicarle, que conforme a los linearnientos .establecidos paha la obtención del grado de Maestro en Ciencias en este Centro, se le concede la aulorizaci.on para que proceda con la impresión de su tesis. 1:
I!
. . . . . . . . . . . . Atentamente
I\/
I M E ~ O R IMER~WCCI PALMIRA w. CVERMVACA. MOR MÉXICO
EW [email protected] rnx
APARTADO POSTAL 5-1 64 CP 62050, CUERNAVACA. lELS.(73)12 2314.12 7613.16 7 7 4 1 , F M ( 7 3 ) 12 2434 cenidd
Agradecimientos I1
li Priiiieramente, le agradezco a Dios por danne la oportunidad de concluir mis estudios de maestría, así también de contar con esa gente qde me quiere y que yo quiero...!!
Agradezco infinitamente a mi familia A mis padresXandelaria Zazueta y Mateo C&a por todo el apoyo que me han brindado a través de mi formación como personara lo largo de toda mi vida. Espero tenerlos siempre conmigo, ya que siempre están enlmi mente y en mi corazón. A mis hermanas ... Vicky y Nachy, 'por todo el apoyo moral que me han proporcionado en los momentos que más lo he necesitado, y tanigién porestar con mi! padres, que es lo que yo quisiera. A Violeta ... por todo el amor que me ha dado y por todas las atenciones que ha tenido para mi desde que nos conocimos y por todo ese apoyo que me ha servido para seguir adelante.
I1
¡I
i A todos mis compañeros de generación, y en especial para: Cecilia.López Romero,
Félix Agustin Castro, Joaquín Fuente y Garcia, Mano Guillén y Humberto Hemández, los cuales me han brindado su amistad y apoyo en tpdos los aspectos, cosa que es muy
valiosa y por lo cual yo les dqy mil gracias.
A mis directores de esis M.C. Mario Guillén Rodriguez, M.C. Humberto vemández Garcia ... les agradezco toda la paciencia que me tuvieron durante el d e s e l l o de la tesis, también por los conocimientos que me transmitieror, los cuales .I fueron fundamentales para ei desarrollo del trabajo de tesis.
1/
4
ACenidet ,, Por permitir realizarme profesionalmente y logar uno de mis objetivos. A todos mis maestros que en determinado momento nos olhigarbn a seguir adelante y a no damos por vencidos. A mis compañeros que hemos"pasabo las mismas situaciones y que espero les vaya muy bien ep su desarrollo profesional.
I1 .
I
A todos ellos .... GRACIAS. 11
Tabla de Contenido 'I
~I Indice .................................................................................................................................................................. 11
................................................................................................................................................. IV I,ista de Figuras II i: Lista de Tablas .................................................................................................................................................... V I1
11
1 mDICE ,,
Capitulo 1. Introducción. I . I Introducción ..........
. Capítulo 2. Planteamiento y análisis del problema 2.1 Marco teonco .................................................................. .I ............................................................................... 6
........................... IO 2.2 Planteaniiento gene 2.3 Estado del arte ..................... 13
21 2.5 Técnica de solución ...................................................................................................................... 23
. .
2.4 Alcance del proyecto ..........................................................................................................
ii Capitulo 3. Arquitectura del sistema
3.2 Creación de grafos relacionales
3.4 Generación de consultas orient
3.1 Traductor de esquemas ............
3.3 Obtención de grafos orientados .................................................. 33
Capitulo 4. Transformación de esquenias 4.1 Modelos de datos ... 4.1.1 El modelo rela ................................................... 4.1.2 El modelo orien ............... 4.2 Transformación d 4.3 Transformación 4.4 Herramienta de t
I1
Capitulo 5. T r a d u c c i h de consuitas 5.1 Grafos relacionales ................................................................................................. 5.2 Grafos orientados a objetos .......... 5.3 Generacion de consulias orientadas a objetos ................. i ............................................................................ 56 5.4 Lenguajes de consultas OQL y SQL .........
:I
.,
I It
I .I
'! I
Capitulo 6. Pruebas I '
6. I Objetivos de las p 6.2 Descripción del 6.3 OODBMS Poet ............ 6.4 Esquema de la base de 6.4. I Esquema orientado a 6.4.2 Esquema rela ............................ 63
...............................
6.5 Contenido inici 6.6 Caso de pnieba
I, Capitulo 7. Conclusiones 7.1 Conclusiones gen 7.2 Resultados obt ......................................... 71 7.3 Alcances logra ........................................... 73 7.4 Recomendacio 7.5 Trabajos futuros. . .
'I Referencias ........................................................................................................................................................ 15
... 111
' I
Lists de Figuras . .
Figura: 2.2.1 Esquema de un sistema multibase de datos
Figura: 3 Arquitectura del traductor de consultas 1,
ii Figura: 3. I . Un esquema orientado a objetos
Figura: 3.2.1 Una reunion
Figura: 3.2.2. Una cláusula Where dentro de un grafo de prdlicados relaciona1
Figura: 3.3. I Grafo de predicados orientado a objetos resultante de la transformación de grafos
Figura: 4.3.1 Representación de un Atributo Simple y uno complejo
Figura: 4.3.2 Represeniación de un Atributo Conjunto-Complejo
Figura: 4.4.1. Interfaz gráfica de la herramienta de diseilo y,,üansformación de esquemas
orientados a objetos. ;j
Figura: 4.4.2. Ubicación del archivo de defmición de clases
i;
I1 II . 11
Figura: 4.4.3. Un esquema orieniado a objetos !i Figura: 4.4.4. Diagrama de flujo de la transformación de esquemas
I1 ,I ¡I
Figura: 4.4.5. Esquema orientado a objetos lransforniado en esquema
Figura: 5.1.1 Grafo de Predicados Relaciona1
. . 1 1
¡I Figura: 5. I .2 Reunión fonnada por la tabla Profesor y AlumnoG
Figura: 5.2.1 Subgrafo formado por dos relaciones
Figura: 5.2.2 Subgrafo formado por dos clases
Figura: 5.2.3 Alternativas
Figura: 5.2.4. Grafo de Predicados intermedio
Figura: 5.2.5. Grafo de Predicados Objeto resultante de la &asforniación de grafos
Figura: 5.3.1. Ruta de expresión simple
Figura: 5.3.2. Ruta de expresión doble
Figura: 5.3.3. Ruta de expresión simple con loin explícito
Figura: 6.4.1.1 Esquema Orientado a Objetos de prueba
Figura: 6.6.1 Carga del esquema orientado a objetos dentro de la herramienta de transformación
de esquemas
I!
L
11 . ,
"t
> ,
Figura: 6.6.2 Resu!!ada: de !r transformación del esquema;orientado a objetos a esquema
relaciona vimal.
Figura: 6.6.3 Obtención de los grafos de predicados.
Figura: 6.6.4 Obtención de la consulta OQL a partir del gdfo de predicados orientado a objetos.
Figura: 6.6.5 Resultados de la consulta.
,
i2
27
31
33
34
37
42
43
45
45
47
50
51
57
57
59
59
6a
61
62
63
63
63
69
12
73
75
76
iv
! I ' '
I Lista de Tablar
I! 1. Versiones de SQL 2 .
3. Equivalencias entre modelos 11
4. Reglas de transformaci$n de esquemas 1,
Sintixis de las consultas permitidas por el traductor
5 . Tablas obtenidas de la transformación de esquemas !I 6.
7.
8. Definición de clases
Tipos de atributos contenidos dentro de las clases
Ejemplo de consulta en SQL ' i I,
11
I I 24
29
30
32
42
SI 61
!I
V
Introducción En este capítulo se muestra el panorama general de la problemática tratada en la tesis, la
solución propuesta, los beneficios al seguir las técnicas propuestas, las nuevas tendencias del
uso de infonnación que manejan las empresas y la organización del documento.
1;
11
It
1.1. Introducción
Actualmente el procesamiento de datos se caiacteriza por aplicaciones que involucran el
acceso y manipulación de información de varios sistemas preexistentes de base de datos y de
sistemas de información que por lo regular se enhentran en s o h a r e y hardware heterogéneos
y distribuidos a través de una red de computadoras. La distribución de la información,
rkpprtrsenta la naitirakza descentralizada de las empresas modernas, mientras que su automiilia
y heterogeneidad surgen como una consecuencia de las diversas necesidades de procesamiento
de infonnación. Originalmente, los sistemas de una empresa se ejecutaban en fonna individual
y aislada, pero ha llegado a ser evidente11 la necesidad de cooperación entre ellos.
Desafortunadamente, el potencial para la integkación cooperativa no fue considerado como
parte de su diseño original y todavía no /existe un modelo general que soporte la
interoperabilidad entre los sistemas.
u .
.:I
/I It
1,
!I
11, lost Aurelio Cola k u e m
:. +raducior de conrUpr del Mcdclo Rclacional a1 Modelo Oricntado a Objetos
1.2. Antecedentes ,
El problema de la integración de datos heterogéneos I1
alternativas de solución. 81
es complejo y se han propuesto varias
Cuando los sistemas a integrar son únicamente bases de datos existen al menos dos !l. posibles soluciones. La primera es la integración fisica de todos los datos necesarios para una
aplicación dentro de una sola base de datos. Esta dolución se llama Almacenamiento de Datos I! 1; (Datawarehousing). I
La solución alternativa es la integración Iogica de todos los datos requeridos por una
aplicación dentro de una base de datos lógica. Esta forma de integración crea la ilusión de un
sistema de base de datos sencillo que oculta a'llos usuarios lo complejo de los diferentes
sistemas administradores de bases de datos (SA;BD) y métodos de acceso. Esta altemativa
proporciona, a los usuarios, un acceso uniforme .a los datos almacenados en vanas bases de
datos, sin la necesidad de transferir información a,,una nueva base de datos. A los sistemas con
estas caractensticas se les denomina sistemas multibases de datos.
11
/I ,I
II
II
Un sistema multibase de datos (SMD) es Un medio que integra una colección de bases
de datos, que tienen caractensticas de ser preexistentes, autónomas, heterogéneas y que están
distribuidas en diferentes nodos de una red de computadoras. Un SMD permite acceder datos
localizados en vanos sistemas administradores de bases de datos por medio de transacciones
globales que toman de referencia un esquema', global lógico formado por los diferentes
esquemas de los sistemas de bases de datos a integrar. En tales sistemas, las transacciones
globales se ejecutan bajo el control de SMD. L& transacciones globales se descomponen en
varias transacciones que acceden a diferentes SABDs. Cada una de las transacciones se debe
transformar al lenguaje de consultas utilizado por el SABD local. En forma independiente las
transacciones locales se ejecutan bajo el control dp los SABDs locales.
'I
/I ;I
II A
I/
!I
Ij I1
!
@ Cenidet 1999 Página 2
lost Aurelio Cota iazuita dcl hiodclo Rclactonal al Modelo Oncnwdo a Objclor
Los usuarios del SMD pueden hacer con$ltas hacia los sistemas de información a
partir de una consulta global en un lenguaje global: que puede ser SQL. La consulta global se ii
descompone en varias subconsultas que corresponden a cada uno de los sistemas de I1
información involucrados. Cada subconsulta se .aduce del lenguaje global al lenguaje de I!
consultas utilizado por el sistema local. I¡
El trabajo de tesis presentado consiste en la implantación de un traductor de consultas
de SQL a un lenguaje orientado a objetos mediante el uso e implantación de la técnica de 'I Grafos de Predicados [IO].
II
1.3. Objetivo 4
:I I:
El objetivo principal de la tesis es el desarrollo d& una herramienta de software que permita la
traducción de consultas realizadas en SQL a consultas equivalentes realizadas en el lenguaje
Orientado a objetos llamado OQL [13]. La traducción de consultas se lleva a cabo con la
finalidad de que usuarios con conocimientos de sistemas de base de datos relacionales accedan
a los datos almacenados en sistemas de bases de datos orientadas a objetos, y donde los
sistemas de información a acceder fonnan parte de un SMD.
1
!I '!I
!I
11
El trabajo desarrollado en la tesis proporciona un traductor de consultas a algún
a sistemas de bases de datos orientadas a sistema multibase de datos, para que permita acceder 'I objetos a partir de consultas en SQL.
1.4. Beneficios
El acceso a los datos de una BD se realiza por medio de un lenguaje de consultas. Los I ' sistemas de bases de datos pueden estar basados en II diferentes modelos de datos y por lo tanto
pueden utilizar diferentes lenguajes de consultas ,que aprovechen las bondades del modelo de
datos utilizado. Para que los usuarios de un sistema de información puedan acceder a los datos 1
0 Cenidet 1999 Página 3
11 l a x Aurelia Cola k u e l a Tnduclor de Consullar dci Modclo pciacional al Mcdclo Oncntado a ObJcior
II /.
I/ I! 'I
.: I:
de otro sistema, es necesario que tengan conoc.imiento de los mecanismos y del lenguaje de
consultas de ese nuevo sistema de información, tal es el caso de los sistemas de bases de datos
orientados a objetos (OODBMS, por sus sigl;as en- inglés Object Oriented Database
'1 ! Management System). 1
Mediante el uso del traductor de consultas fesarrollado en el trabajo de tesis, es posible
que usuarios que usan SQL puedan acceder a las Cases de datos orientadas a objetos mediante I! el uso de SQL. Además el traductor permite realizar desarrollo de aplicaciones con mayor
rapidez y facilidad, al evitar el aprendizaje de un nuevo lenguaje de consultas.
11 Dentro del ámbito de los sistemas de almacenes de datos es posible utilizar el traductor
como una iiiterfaz durante el proceso de población de datos al almacén de datos. En este caso,
el traductor recibiria consultas en SQL, las traddkina y las aplicaría s h e las bases de datos
orientadas a objetos y los resultados se enviarían' al proceso de población de la base de datos
para realizar las adaptaciones y filtraciones nicesarias para ser almacenados dentro del
almacén de datos.
I¡
I, !I I
.;I
1.5. Metodologia 'I '1
Para el desarrollo del traductor de consultas se uiilizó la técnica de Grafos de Predicados [IO].
La técnica de grafos de predicados toma como entrada un esquema orientado a objetos y a
partir de un conjunto de reglas de transfonnacibn de esquemas lo convierte a un esquema
relacional equivalente. El esquema relacional equivalente es utilizado por usuarios del SMD
para realizar consultas con ese esquema utilizando SQL. Posteriormente las consultas en SQL
se descomponen y se representan en forma de UA g a f o relacional a partir del cual se obtiene
un grafo orientado a objetos, de'donde se genera la consulta en el lenguaje orientado a objetos.
,I
I!
3 . :
I1 .
I
II
'I
II La implantación del traductor de consultas consta de varias etapas en las cuales se
desarrollaron herramientas que permiten procesar la información de .las bases de datos y las I'
consultas a traducir. Las herrm'ientas se listan a continuación: II . ,
,i @ Cenidet 1999 Página 4
11
'i Traductor de Conyllar del hfodclo Rclarional al Modelo Onmiado a Ohjetor loíi Autcho Coi3 Zazucia
II
1. Diseño y transformación de esquemas.orientados a objetos. La herramienta pemite crear y
recuperar un esquema orientado a objetos y lo transforma en un esquema relacional
equivalente. Para la transfonnación se hace uso de reglas de transformación de esquemas,
descritas a detalle en el capitulo 4.
!I
~i
11
2. Creación de grafos de predicados. El usuarioi(de1 traductor introduce una consulta en SQL
que se aplica al esquema relacional obtenido: en la etapa anterior. La consulta en SQL se II transforma en un grafo relacional. A partir del g a f o relaciona1 se genera un nuevo g a f o
t equivalente denominado Grafo Orientado a Objetos. El detalle de 10s algoritmos se
i/ presenta en el capítulo 5.
:I
3. Generación de consultas. Con base en el grafo orientado a objetos,%e procede a formar la
consulta en el lenguaje OQb, en el capítulo 5~1se detalla el algoritnio para la1 generación de
la consulta en OQL a partir del grafo orientado a objetos. Para efectos de comprobación de
resultados se usó el sistema administrador de bases de datos orientadas a objetos Poet [ I I]. ,I
1 1.6. Organización del Documento I1 !i
II . En el capítulo 2 se describe la problemática que'lda origen al desarrollo de la tesis. El capitulo
3 muestra la arquitectura utilizada para la implantación del traductor de consultas. Dentro del
capítulo 4 se describe la implantación y creación de la herramienta para el diseño y
transfoniiación de esquemas o,nentados a objetos. El capitulo 5 describe la creación de los
gafos de predicados relacionales y su correspondiente conversión en grafos de predicados
orientados a objetos. También se menciona el;'proceso a seguir para obtener una consulta
Ij
I
orientada a objetos a partir de la estructura formada 11 por el ga fo de predicados orientado a I
objetos. En el capitulo 6, se muestra un ejemplo del uso del traductor de consultas en todas sus
etapas. Finalmente, dentro del capítulo 7 se hace un análisis del trabajo desarrollado y se
presentan las conclusiones y se dan algunas recomendaciones para trabajos futuros.
li
/I
@ Cenidet 1999 Página 5
il
11 Tnducior dc Conr+ar del Modelo Rclacional al Mdclo Oieniado a Objcior lor+ Aurclio Cola Zazuela
' t
(1 Planteamiento y
Aiiálisis del Problema 11
li
En el marco teórico se mencionan los principales conceptos computacionales utilizados, para
una mayor comprensión del problema. Enseguida se hace el planteamiento del problema, se
presenta el estado del arte y el alcance del proyecfo.
/I
1,
!I 2.1. Marco Teórico I1
11: I :
En el desarrollo de la tesis se combinan varios conceptos importantes entre los cuales se
mencionan: abstracción, encapsulamiento, acceso a bases de datos y polimorfismo, que han
dado origen a otros conceptos,'como la programación orientada a objetos, modelos de datos,
lenguajes de consultas, integración de datos heterogéneos, que están cambiando el curso de las II
tareas e influyendo en gran medida en las actividades de las empresas e instituciones que I!
utilizan grandes volúmenes de información. Enseguida se muestra brevemente la definición de
los conceptos básicos en el desarrollo de la tesis.
ll 1 II
11
@ Cenidet 1999 I Página 6
II lost Awelio Cola Luucta Traductor de Cansuliar del Modcla Relational 81 Modela Oncnlado a Ob~clor
I 11. II . II .
11 .
/I
I1
Programación Orientada a Objetos. Puede .definirse como una técnica o estilo de
programación que utiliza objetos como bloque esencial de construcción. LOS objetos se basan
en el concepto de los tipos abstractos de datos, ampliamente utilizados por los programadores
en las décadas de los setentas y ochentas. Un tipo de dato abstracto es un tipo de dato definido
por el programador junto con un conjunto de opefaclones que se pueden realizar sobre ellos.
Se denominan abstractos para diferenciarlos de los! tipos de datos fundamentales o básicos. Sin
embargo, la potencia real de los objetos reside en las propiedades que soportan como son:
herencia, encapsulación y polimorfismo junto con:los conceptos de objetos, clases, métodos y
mensajes [3]. Ya que la programación orientada a objetos presenta algunas características
importantes para el manejo de información, se han tomado estos conceptos para la
representación de los objetos del mundo real y se'han desarrollado bases de datos orientadas a !l .
objetos.
Un método común para crear bases de datps orientadas a objetos (OODBMS) consiste
en extender un lenguaje de ,programación orientado a objetos para que soporte las
características de bases de datos tales como persistencia, transacciones y consultas. Entre
algunos productos comerciales basados en esta metodología se encuentran:
a) Objetivity, Objectstore y Versant de 1991 utilizan C++.
b) Gemstone y Versant utilizan Smalltalk.
11
I1 11
!I
/I 11
Modelos de datos. Un modelo de datos es un conjunto de herramientas conceptuales para
describir los datos, sus relacion.es, su semántica y.sus limitantes [4]. Se han propuesto varios
modelos de datos diferentes, los cuales pueden dividirse en tres grupos: los modelos lógicos
basados en objetos, lógicos basados en registr0s.y modelos físicos. Los modelos de datos han
tenido su aplicación y uso, pero en la actualidad el modelo de datos relaciona1 es el más
utilizado. De hecho se utiliza ep la mayoría de los sistemas de bases de datos.
I
II
I! I
!I A partir de la década pasada, la naturaleza de las aplicaciones de bases de datos ha
evolucionado de aplicaciones simples a complejas. Las aplicaciones simples recuperan pocas
cantidades de registros que contienen datos ,!pequeños y simbólicos. Las aplicaciones
complejas almacenan y recuperan datos complejos que pueden estar anidados @or ejemplo
/I
11
11
@ Cenidet 1999 Página I
lb JorC Aurelio Cola Zizuela ,i
'
Traductor de Con+ar del Modclo Rclasional al Modclo Oncntado a Objcior 8 1
ii
E I t
cuenta de materiales), datos compuestos @or ejemplo conjuntos, arreglos, estructuras), datos
de multiinedia (ejemplo imágenes, audios, textos). La tecnología orientada a objetos
proporciona un marco de trabajo común en el cvai se representan las estructuras de datos
simples y coniplejas. A continuación se mericiona)el ejemplo de un sistema complejo donde el
sistema relaciona1 muestra algynas limitantes: I n muchos de los sistemas de información
geográfica (GIS por sus siglas en inglés Geographic Information Systems) se usan bases de
datos relacionales o alguna aplicación específica 'be base de datos no estandarizada. La razón
principal de este hecho, e s qued no existían bases de datos comerciales orientadas a objetos
disponibles hasta hace poco tiempo.
I.
I,
11 .
II 'I
Los datos de los GIS incluyen números y cadenas cortas, grandes datos sin estructura
tales como texturas, estructuras de datos complejas de datos como construcciones de
geometría 3D y objetos compuestos que son representaciones comprimMas de tales datos. Los
sistemas de base de datos relacionales carecen del mecanismo para trabajar con estos tipos de
datos: Sus métodos tabulares no pemiiten el modelado de jerarquías de objetos complejos.
Aunque la mayoría de los sistemas relacionales $aportan grandes objetos binarios (BLOB por
sus siglas en inglés Binary Large Object Block-) para almacenar datos gráficos, no pueden
consultarse de igual forma que los tipos de datos onentados a objetos.
!l.
/I
I ' I/
1,
¡I .
i! I
'1
En contraste, los OODBMS permiten construir jerarquías complejas de estructuras de
datos. Los OODBMS están optimados para trabajar con datos en formato binario
eficientemente y contienen las características de los sistemas relacionales. !i
I 1 Lénguajes de Consultas. Sirven para que el umario solicite información de la base de datos.
Son normalmente de alto nivel, mayor que I& lenguajes de programación estándar. Los
lenguajes de consultas se ,, pueden clasificar en lenguajes procedimentales o no I I:
procedimentales. En un lenguaje procedimentali 11 el usuario ordena al sistema que realice una
serie de operaciones con la base de datos para obtener el resultado deseado. En un lenguaje no
procedimiental el usuario describe la información que desea sin indicar un procedimiento
especifico para obtenerla. La mayor parte de los sistemas comerciales de base de datos ofiecen
un lenguaje de consulta que incluye elementos de los dos enfoques. Dos
I'
Ir .
1:
@ Cenidet 1999 I Página 8
It Jort Aurclio Cola Za2ueia Traductor de Conr$tar del Modelo Relaoonal 81 Modelo Oncnlado a Ob~ctor
)I . .-ii
lenguajes que no son muy amigables, pero que muestran las técnicas fundamentales de
extracción y manipulación de datos de las base de datos son: El álgebra relacional y el cálculo ‘1 : j
I.
. , relacional [4].
11 ~l El álgebra relacional es un lenguaje de consultas de procedimientos, porque cuando se
escribe una expresión en álgebra relacional, se proporciona una secuencia de operaciones que I‘
genera la respuesta a la consulta. Por otro lado, el cálculo relacional es un lenguaje sin I[
procedimientos; donde se da una descripción f o y a l de la información deseada sin especificar
cómo obtenerla. Estos lenguajes formales permiten representar las consultas en forma concisa.
Sin embargo, los sistemas comerciales de base dedatos requieren de un lenguaje de consultas
más “amigable con el usuario”. Existe una diversidad de lenguajes de consultas comerciales,
donde el nombre “lenguaje de consultas” no es correcto debido a que realizan muchas otras
funciones, además de consultar bases de datos. Algunos de los lengd8jes de consultas más
importantes, cada uno con estilos diferentes de ¿onsulta de bases de datos son: SQL, Que1 y
II
11 II
!I QBE [41. I
El SQL fue estandarizado para el uso d e d o de los modelos de datos relacionales. Es el
lenguaje de consultas más importante y ampliamente utilizado a través de la historia. SQL
permite definir y manipular datos [7]. Hoy existen diferentes versiones de SQL con
extensiones para ser utilizados dentro de otros modelos de datos. La versión de SQL que se
maneja en la tesis es un subconjunto de la versión estandarizada en 1989. En la tabla I se
muestran características de los estándares.
I/i
II I)
!I
<..
. . . .
!I
‘I
@ Cenidet 1999 Página 9
II lore hurilio Cola Zaruio , Tnducior dc Conrulwr del Modelo Rclacional al Modclo Oncn13dO a Objcior
11
SQL86
SQL89
SQL92
L SQL93
11
II Carac'terís ticas
Estándar inicial de SQL. Conjunto 'limitado de características, con algunas
restricciones de integridad
Revisión mínima del estándar del 86. Añade integridad referencial. Acceso a
bases de datos relacionales.
Revisión completa del lenguaje (superconjunto del 89). Sobre todo añade más
potencia semántica' en la definición de datos (restricciones de integridad,
dominios, más tipos de datos). Mejora el lenguaje de consultas (ej. Producto
natural y externo) y elimina'probleinas de ortogonalidad. Acceso a bases de
datos relacionales con algunas extensiones para acceder en poca medida a
Ii 1 ,I/
II
II I!
. OODBMS 'Ii
Superconjunto del SQL 92. Acceso,completo a bases de datos orientadas a
objetos. 1 ~l
Tabla 1: Versiones del lenguaje SQL
En la actualidad los OODBMS utilizan un lenguaje estándar para la manipulación de
los datos denominado OQL (por sus siglas en 'inglés Object Query Language). OQL fue
establecido por la ODMG @or sus siglas en inglés Object Data Management Group) [13]. La
ODMG es una de las agrupaciones más importadtes, con gran cantidad de socios, ha logrado
vanos estándares en la fabricación de los OODBMS.
il
11 t
2:2. Planteamiento General del Problema. I,
. I
d
Actualmente en las empresas se utilizan varios iipos de SABD, debido a que cada tipo de
aplicación puede ser mejor sophada por un SABD dirigido al tipo de aplicación. Los diversos
sistemas de base de datos a menudo utilizan diferentes modelos de datos y.lenguajes de
consulta, y su coexistencia dificulta a los usuanos el acceso a los datos en los diferentes
II
11. 'sistemas. Algunos SABD en el mercado son:' II Oracle [14], Sybase [15], Informix [16],
Microsoft SQL Server [17], Habitat [18], Poet [ l l ] , Objectstore [19], Gemstone [20], Versant
I¡ I t I @ Cenidet 1999 Página 10
ti lor¿ Aurelio Cota 7azucta Traductor de Con!ultas del Modelo Rclacianal al Modelo Orientado a Objcior
11 .!I [21]. Cada SABD posee características particulares de su fabricante y a menudo utilizan
lenguajes de consulta diferentes, dependiendo del modelo de datos utilizado.
'I
Actualmente la globalización y la compet/tividad entre las empresas hacen necesarias
la integración de la información entre las entidades de una misma empresa e incluso entre
empresas, a fin de lograr una toma de decisiones'más rápida y eficiente. Muchas veces es
compleja la obtención conjunta de datos desde diferentes fuentes de información o bases de
datos, porque la interacción no está disponible de manera instantánea y es necesaria la
intervención de diferentes factores o mecanism?s. Una forma que facilita y permite a los
usuarios el acceso a los datos en los sistemas de información, sin la necesidad de conocer el
uso de todas las formas de acceso, es la construcción de un sistema global capaz de soportar
un solo modelo de datos y un lenguaje de consultas global, ubicado sobre diferentes sistemas
de base de datos locales y que realice las consultas de una manera simple y transparente. Un
sistema con estas caractensticasmes llamado sistema multibase de datos [6] . En la figura 2.1. se
muestra el esquema de un SMD.
11 I/
li
II I) I1
II
II 11 I/
I
@ Cenidet 1999
Consulta en lenguaje Glbbal +, Global
I Descomposición en
Subcdhsultas I1 11
Trsiluctor I Traductor
r BD Orkiitada 6 D a Archivos Planos
Objetos ox /I
BD Relacional
Figura 2.2.1. Esquema de Multibase de Datos
9 9 - 0 6 5 2 Página 11
¡I lost AurclioCoia &.sell Ttaduclor dc Coniullar del Modclo Relaciona1 al hlcdelo Chicnlado a Objetos
I!
El SMD utiliza un esqueina global $e r'esulta de la integración de los esqueinas 11
exportados desde las bases de datos locales. .Los usuarios del SMD utilizan un lenguaje de !I
consultas global para especificar consultas haciendo uso del esquema global. Por ejemplo, si
se hace uso del modelo relaciona1 para la definición del esquema global, entonces se usa SQL
como un lenguaje de consulta global. En la tesis se contempla el modelo relacional para
definir el esquema global y SQL para lenguaje de consultas global.
Conceptualmente una consulta global puede procesíirse en tres pasos:
I! li
¡I
II
li I1
La consulta global se descompone en varias subconsultas. Un planificador distribuye las
subconsultas hacia las bases de datos locales.
La descomposición de la consulta global en subconsultas, se realiza en el mismo lenguaje
global. Si el lenguaje de la su6consulta es diferknte del lenguaje de consultas del SABD
local, se debe traducir la subconsulta al lenguajede la base de datos local. Por ejemplo, si
el lenguaje de consultas global es SQL y el lengyaje del sistema manejador local es OQL,
entonces la subconsulta debe traducirse al lenguaje de consultas orientado a objetos. De
acuerdo con la cantidad de diferentes lenguajes locales, esa misma cantidad de traductores
será necesaria para cubrir todas las traduccion'es [I] .
Por último, una vez que las subponsultas ya fueron traducidas y procesadas por las bases
de datos locales, los resultados retornados se cambinan para formar la respuesta de la
consulta global.
1'
I!
. I1
I1 \I
r 11
.
I\
Dado que una consulta global puede tradycirse a diferentes subconsultas, cada
subconsulta puede ser evaluada por un sistema de base de datos local, respetando su
autonomía de sitio. AI realizar las traducciones de un lenguaje de consultas a otro, se deben
tomar en cuenta algunas consideraciones. En ocasion(, no es posible traducir consultas de un
lenguaje a un conjunto equivalente de consii!!ar: i n nirn !enguaje, porque ciertas operaciones
en el lenguaje fuente no son soportadas de manera carrecta en el lenguaje destino. Por
ejemplo, una consulta relaciona1 con un predicado rquni6n [ I ] puede no tener una consulta
equivalente en el sistema manejador de base de datos IMS [ I ] . En esta situación, la consulta se
traduce en una consulta más amplia (por ejemplo un superconjunto de los resultados
deseados), tal que la restricción reuhión sea manejada por un postprocesador de consultas.
Para detectar este tipo de operaciones,ye usa un componente filtro.
;I
I!
~t
I'
II
I1 ,I
II
I1
@ Cenidet 1999 Página 12
I/ '!I
. ' . , I :~
la actualidad e\ USO de las bases de datos orientadas a objetos está cobrando
popularidad, dando como consecuencia el surgimienfo de nuevos Sistemas Administradores de ')
Bases de Datos Orientadas a Objetos (OODBMS). LOS SMD actuales no consideran
traductores de consultas que permitan acceder a los datos de los OODBMS por 10 que es
necesario considerar su in tegrach a los SMD. La I1 problemática descrita da origen a 10s objetivos del presente trabajo de tesis.
![
I/
'I
I' li
'I
.t I'
2.3. Estado del Arte
Para el desarrollo de la tesis
integración de sistemas
tipos de lenguajes que
bases de datos, la
tienen acceso, los
sobre los que se
ejecutan, además de las características que tienen. Actualmente existen tecnologías de bases de
datos diferentes, donde cada una responde a difer'entes necesidades y se enfocan a diferentes
tipos de usuarios. Todas tienen sentido y no complten necesariamente entre ellas, ya que cada
una logra su objetivo de integrar los datos deluna forma en particular. Las tecnologías
mencionadas y algunos productos son [9]:
a) Base de datos relacionales bysadas en el modeio de datos SQL92 estándar [7]. Representan
la información en forma de tablas, utilizadas por los usuarios para formular sus consultas. '! II
Las bases de datos relacionales son las más utilizadas y entendidas en muchos segmentos ti
del mercado.
/I
,I
I ,>
b) Bases de datos orientadas a objetos basadas e$ el modelo de datos ODMG [13]. Consisten
en almacenar objetos de -forma persistenv creados en un lenguaje de programación
orientada a objetos. Algunos manejadores quk utilizan esta tecnología son 02, Objetivity,
Object Design, Poet y Verslnt.
11 '1 I/
/I c ) Base de datos objeto-relaciona1 sop0 ando !el modelo SQL92 con algunas extensiones.
Son bases de datos relacionales que h ,f n extendido J. su lenguaje de consultas para que tenga I 1 il
Página 13 @ Cenidet 1999 I
11
!'
..I::::. ' . .
capacidad de guardar, administrq recúfe$,q objetos. Algunos vendedores de esta . ' . . .,.:
tecnología de base de datos in luyen Unisql, ilustra (recientemente adquirido por I I/
informix), Omniscence, con Aertisiigas con Opcie.
IMDAS (221
@ Cenidet 1999
I/ II Página 14
I
I
Es un sistema federado fuertemente acoplado, desarrollado por el Instituto Nacional de Tecnología y Estándares y la Universidad de Florida, cuenta con un esquema simple de datos.
El modelo de integración de datos utiliza la semántica del modelo de datos de red para
representar estructuras complejas, relaciones y 1: las diversas restricciones de integridad
encontradas en las empresas de manufactura.
'I ' )I
INTERBASE [22]
Es un prototipo multibase de datos desarrollado por la Universidad de Purdue, diseñado para
proveer una herramienta que consiste en una interfaz que facilita el desarrollo de aplicaciones
en un ambiente distribuido de software heterogénp de recursos tales como: bases de datos,
biblioteca de herramientas y prograinas de aplicación. El diseño del manejador de información
de INTERBASE se basa en la lofali7~ción e inicio de los servicios remotos, transferencia y
transformación de datos entre los diferentes servicios.
! II
II . . NDMS [22]
Sistema manejador de datos en red, es un sistema desarrollado por la C U I , en Italia, incluye
un soporte para los sistemas manejadores de bases de datos corno IDMS, ADABAS y
RODAN, que trabajan sobre el hardware de IBM, y, para INGRES, que trabaja sobre hardware
DEC VAX. Usa el modelo de datos relacional como modelo de datos global. Involucra tres
modelos de abstracción: el esquema interno, la aplikación del esquema (esquema conceptual)
y vista de usuario final (esquema externo).
¡I II 1; .I
MRDSM [22] 1:
.'. 11 Desarrollado por INRIA, Francia, extiende el sistema manejador de base de datos relacional
MRDS de HONEYWELL para soportar, múltiples bases de datos. El objetivo del MRDSM es
.acoplar la heterogeneidad semántica para proveer, acceso uniforme a las bases de datos.
MRDSM opera en un dominio específico de múltiples sistemas manejadores de bases de datos
relacionales MRDS que se encuentran ejecutándose /en un sistema HONEYWELL. No existe
un esquema global en MRDSM, en cambio los usuafios pueden crear un esquema conceptual
conocido como multi-esquema formado con elementos de los esquemas de las bases de datos
locales. El multi-esquema está asociado con uno o más esquemas dependientes, los cuales
i'
!;
I1 I/
/I
I1 @ Cenidet 1999 Página 15
i
proveen detalles tales como: dependencias entre bases de datos incluyendo la manipulación,, privacía y dependencias equivalentes. Las dependencias de equivalencias manejan datos
semánticamente incompatibles, pero del mismo tipo.
i.
OMNIBASE [22]
Es un prototipo desarrollado por la Universidadlde Houston. Consiste en una interfaz de
usuario global, utiliza una base de datos de conocimiento para analizar consultas enviadas por
usuarios y para remover refereiicias ambiguas. Al analizar las consultas del usuario son
enviadas a un analizador de consulta global y desc0,mpuestas en un conjunto de subconsultas.
1,
I¡ I1 . ir
I ,I
PRECI [22 ]
Es un prototipo desarrollado por la Universidad de Keele y la Univehidad de Aberdeen en
colaboración con un gran número de centros de investigación, principalmente británicos.
PRECI es un sistema manejador de bases de datos distribuidas generalizado, está hecho para la
recuperación de heterogeneidad11 y para proveer actualizaciones limitadas en los datos. El
esquema de cada base de datos existente se redefine y cada uno es conocido como un nodo.
Las consultas a las bases de datos o nodos se realizan mediante una interfaz de relacion
j/
II . ~1 11 I/
I
,!
ii algebraica. //
ADDS [22]
El sistema de base de datos distribuido Ammo (ADDS) provee acceso uniforme a bases de
ADDS utiliza el modelo de datos
refacional y además aplica una extensión de lenguajes de consulta de álgebra relacional, es así
que podemos asegurar que soporta un conjunto de operaciones del lenguaje SQLIANSI. Los
esquemas de las bases de datos locales son mapeados en múltiples esquemas federados,
conocidos como base de datos compuestas (por Ius siglas en inglés CDB). Los m a p a s se
almacenan en el diccionario de datos ADDS, el cual se reproduce en todos 10s sitios donde se
1,
datos preexistentes heterogéneaii distribuidas. El ¡I sistema . ,t. !I
L 1,
pretenda generar la consulta. 1, ! '
@ Cenidet 1999
!! Página 16
Jose Aurclio Cota k u r t a Traductor de Con$u;!x dcl Mcáclo Relaciona1 ai M d c l o Onenlado a Ob~cios
11
Las CDB's soportan la integración de modelos de datos jerárquico, relacional y de red.
Los sistemas manejadores locales que se puedin soportar concurrentemente son IMS,
SQL/DS, DB2, RIM, INGRES y FOCUS. Los campos de datos son semánticamente
equivalentes para las diferentes bases de datos locales. 11
DATAPLEX [22]
Es un sistema manejador de bases de datos heterogéneo distribuido, desarrollado por General
Motors Corporation. Pennite consultas, transacciones y actualizaciones en el manejo de los
datos en los diversos sistemas !le bases de datos distnbuidas locales, de manera que la
localización de los datos es transparente a las peticiones. En este ambiente los diferentes
sistemas manejadores de bases de datos pueden ejpcutarse en vanos sistemas operativos y la
conexión se hace por una comunicación entre protdcolos.
I
II
II . . .
!i
I / ' 0.
DATAPLEX emplea el modelo relacion?l como su modelo de datos global. Los I:
modelos de las bases de datos locales pueden ser, diferentes, por consiguiente cada esquema
local es transformado a su esquema equivalente en el modelo relacional. El esquema
conceptual se implementa como un conjunto de eiquemas relacionales coincidentes, uno para
cada base de datos local. El prototipo DATAPLEX incorpora los sistemas manejadores de
datos IMS, que se ejecutan sobre el sistema operdtivo MVS, e INGRES, que trabaja sobre el
't 11 II
I/ !I !!
sistema operativo VMS. 1 ~l
MERMAID [22]
Desarrollado por la compañía de integración de datos CID, es un SMD que soporta múltiples
&quemas federados. Se conoce como un sistema previo que localiza e integra los datos
almacenados por sistemas manejadores de bases de datos locales, parte de los cuales podrán
ser compartidos por usuarios globalec.
,I
s 11 I/
11
I, MULTIBASE[22]
Desarrollado por la tecnologia, de información1 avanzada de Xerox, provee una interfaz
uniforme de integración para la recuperación be datos de bases de datos heterogheas I
preexistentes. Fue diseñado para permitir a los upanos I, . referenciar información de las bases I/
@ Cenidet 1999 Página 17
!I I
I1 lorc 4urclio Cota L v u e w T d x t o r de Conru!ws del Modclo Relscionai a1 Slcdclo Oncniado a Ohjetor
11 de datos; para presentar una vista de integración' global de la información. MULTIBASE
facilita en forma sencilla y directa la consulta sobre las múltiples bases de datos. Con la
integración del esquema y un simple lenguaje de consulta (DAPLEX) simplifica el
conocimiento necesario por parte,del usuario.
II
I1 11 It
,,
I! I ORACLE V5 [22]
En la versión de ORACLE V5.1.'17, se inicia el desarrollo de un sistema manejador multibase
de datos para este producto. Una de las caractensticas es que permite la creación de varias
bases de datos en un mismo sitio y la formulación de consultas elementales de rnultibase de
datos. El lenguaje de manipulación de ORACLE está en términos de SQL*PLUS. El lenguaje
de ORACLE también ofrece comandos para consultar entre bases de datos desconocidas en.
otros sistemas comerciales, pero4en gran parte, éstjs deben ser similares al SABD.
'i 81
I!
I¡ 0.
SUPRA [22] f
Es un producto de CMCOM; provee una im,plantación comercial para la arquitectura
triesqueina de ANSUSPARC. El inicio de este8)desarrollo fue en Alemania. El kernel de
SUPRA consiste de dos módulos básicos: el imanejador relacional ,de datos distribuido
(DRDM) y el manejador de procesos de datos heterogéneos (HDMP), junto con una porción
de directorio global. Usando el kernel en cada servidor local, los requerimientos de cada nodo
se coordinan en la entrada de' la unidad de trabajo, incluyendo la descomposición de la
consulta como un requerimiento de protocolo nedral y la determinación a dónde se tienen que
enviar. Los nodos receptores locales reconocen al kernel y trasladan los requeriniientos al
leiiguaje de manipulación de datos local apropiado, recogen los datos, calculan su
#I
li
I I
'I -
transformación y regresan los resultados al nodo ,que I1 lo requiri6. . . . .
SYBASE [22] I .I
Intenta abrir su arquitectura tan ampliamente como sea posible para permitir que alguna base
ambiente heterogéneo. SYBASE está basado en e1 modelo relacional y soporta tanto consultas
prograinadas como interactivas por el SQL SERVER de alguna aplicación con el servidor z
de datos, aplicación o servicio sean integrados ¡I en la arquitectura clienteíservidor en un
1;
@ Cenidet 1999 Página 18
11
4 I'
lor¿ AurclioColi iazucu Tmduclor dc Consultar &I Modrlo Rciariaisi al W d r l o Oncnwdo a Objcios
abierto, EI SQL SERVER también soporta los disparadores como objetos independientes en 'I :c
las bases de datos. I
Aparte de 10s prototipos de sistemas muhibase2 que se han hecho, también se han creado
herramientas que facilitan la integración de sistemas de información que por su forma - de
acceder a los datos se muestran en varias clasificac¡ones:
I , Integración de bases de datos pre-relacionales $.relacionales.
2. Integración de bases de datos pre-relacionales y orientadas a objetos utilizando un lenguaje
I!
' t
!I 'I
1 81 extendido. l.
3. Integración de bases de datos' sin esquemas. ,:
I) A continuación se muestra un listado de alginos productos comerciales que realizan ia
.I *. integracion de datos ya mencionada:
I .- Integración de bases de datos pre-relacionales y relacionales:
a) EDNSQL de Information Builders Corp. (Enterprise Data AccesdSQL) fue introducido
en el mercado en 1991. Proporciona una familia de productos, por medio de los cuales
logra una amplia cantidad de productos integrados. De manera general, en conjunto con
todos sus productos y hemientas , puede integrar sistemas tales como DB/2, Oracle,
Infonnix, Sybase, Rdb, Ingres, Lotus DataLens, etc.
.I
'I
II
II 11
'I P /I
b) Sybase Omni SQL. Logra juntar bases de datos heterogéneas para hacer transparente la
localización de las mismas; el dialecto SQL 'y los proveedores de la base de datos en la
cual los datos están almacenados. Algunas cadactensticas:
Integración de datos,heterogéneos.
Reuniones distribuidas heterogéneas,;;
I1
Soporte de ODBC.
Hardware y Software soportado: HP9000!800 con HP/UX, RS/6000 con AIX 3.2, Sun
con SunOs 4.12, VAX con W S 5.5.
Fuentes de' Datos Soportados:
@ Cenidet 1999
,-
I1 , ,l. Transacciones SQL estándares para acceder a vanas fuentes de datos,
Catálogo de datos y'traducciones completas de ,SQL, i:
il Relacionales: Oracle, DB2, Sybase SQL Server 4.0 y más.
11
I1 Página 19
I
No-Relacionales: Soporte de .archivos / / W S (Sol0 V A W M S ) , Y SoPofie de
archivos ISAM (HP, RS16000 y Sun). '
I1
c) IBM Datdoiner. Habilita a los usuarios para que sean capaces de juntar datos a través de
una simple consulta SQL y una simple interfaz,';ocultando las diferentes bases de datos del
usuario y las aplicaciones. El usuario no tiene conocimiento de dónde residen los datos que
está manejando. Datdoiner piovee acceso puntb a punto a varias fuentes de datos remotos
al mismo tiempo. Algunas d e p s caractenstica; más importantes son:
Transparencia de localización de datos, dialectos de SQL, protocolos de redes, sistemas
operativos, tipos de datos, códigos de errores y diferencias funcionales. /I
Soporte de un amplio rango de estándares (ODBC, XOPEN CLI, y Client Application
Enabler) y lenguaje servidores de aplicacio'nes(C, FORTRAN, y COBOL). '1)
.
1 11 ,I
11 .
Phafonnas de los clientes: DOS, Windows, AIX, OS/2, HP-UX, S:faris 'I Fuentes de datos utilizadas:
Relacionales: IBM DB2 family, Oi;acle, y Sybase
No-Relacionales: IMS, y archivos VSAM. '1 11
I!
d) User Data Management System (UDMS) de Unidata, Inc.
e) ODBC Development Toolki! 1.2 de Automatiin Technology Inc.
'I
'1)
2.- Integración de bases de dato; pre-relacionales 11 y orientadas a objetos utilizando un lenguaje
'I extendido:
II a) UniSQLlM de UniSQL, Inc. Permite el desa$ollo de aplicaciones usando una sola vista y
un solo lenguaje de base de idatos para múltiples bases de datos relacionales y orientadas a
objetos. Es una extensión 'del sisteina.manejador de bases de datos objeto y relaciona1 11
UniSQLB: con Drivers (Gateway) para acceder a bases de datos externas: Actualmente 'I
UniSQLlM ofrece controládores para Oracle, Sybase SQL Server, Ingres y Versant; II UniSQL también ofrece un producto generador de manejadores para generar un manejador
especial para algún sistema de base de datos relaciona1 basado en SQL
I/
11
11 I
@ Cenidet 1999
11 Página 20
.
lost Aurdio Cola Zarucia iraduiior dr Conrul$r d d Modelo Relaciona1 al Mdclo Oneniado a Ohjcior
b) Total ObjectHub de Cincom Systems, Inc.
c) Pangaea de Telos Corp.
d) The Garlic Project de IBM Almaden Research Center.
e) ECRC Multidatabase System Project.
f) Efendi Project de Siemens Nixdorf Infoqnation Systenis.
il
!I i 11
3.- Integración de bases de datos sin esquemas: :
i! a) TSIMMIS Project de Stanford University.
b) Infoiiamess Project de Bellcore y University de Georgia.
c) Carnot y Infosleuth Projects de, MCC.
En todos los sistemas mencionados para lo&w acceder a los distintos sistemas de
infoiiiiación, hacen uso de traductores de consultasl!'Los traductores be consultas detectados
hasta este punto de la investigación, traducen desde un modelo relacional 'a otros modelos,
excepto al modelo orientado a objetos y los sistemas que hacen uso del modelo orientado a
objetos el acceso lo realizan mediante la extensión de los lenguajes de consultas.
!I 1)
II
II
1) I\
/I
I! En la tesis se describe la creación de un traductor de consultas del modelo relacional a un
lenguaje de consultas para el modelo orientado a objetos utilizando SQL y OQL
respectivamente como lenguajes de consultas. La creación del sistema traductor es con la
finalidad de facilitar las consultas a los usuarios, y que puedan realizar consultas utilizando
SQL a datos en bases de datos orientadas a objetos. I
I 'I '!
2I4 Alcance del proyecto. li
L .
La coexistencia de diferentes sistemas de información con diferentes modelos de datos, tales
como relacional, orientado a objeto\, jerárquico, de red, etc. traen consigo que los usuarios
tengan problemas al acceder a los datos. Una f o h a de interacción entre los diferentes
sistemas de información es mediante la implantación de un SMD que unifique los sistemas de
información y que los datos sean accedidos utilizando un solo modelo de datos y un'lenguaje
de consultas.
!I . It
1;
I!
'I '
@ Cenidet 1999 Página 2 1
ti I & Aurelio Cola LvueL? Traducior dr Cons$rai del hiodelo Relaciona1 al Mcdclo Orientado a Objcior
Un SMD utiliza un modelo de datos y un IEnguaje de consultas global para representar
y acceder a los sistemas de infodnación participantes, para este trabajo se considera el modelo
relaciona1 como modelo global y el SQL comb lenguaje de consultas. LOS SMD están
fonnados por varios tipos de sistemas, entre ellos sistemas orientados a objetos. Para acceder a
los sistemas de infonnación participantes, se requiere que el sistema multibases de datos tenga
un traductor de consultas diseñado especialmente para cada tipo de sistema de información.
II
1 11 /I
I1 'I
La tesis consiste en el desarrollo de un traductor de consultas, el cual traduce consultas
en SQL a un lenguaje de consultas orientado a obljetos (para efectos de validación se utiliza el
lenguaje OQL). Las consultas de SQL pennitidas corresponden a un subconjunto del estándar
del SQL de 1989 debido a que esta versión de SQL es de las más sencillas y más utilizadas, y
las nuevas versiones no están implantadas de manera total en algunos6jABD. El subconjunto
utilizado en la tesis es soportado por todas las versiones de SQL. En las consultas consideradas
están aquellas sin anidación de concultas en la clausula "Where". A continuación en la tabla 2
se muestra la sintaxis de las consultas pennitidas por el traductor de consultas:
,I
I¡
i1 11
II .
II 11
!I
I
"SELECT "
donde:
"*" I <columnas> "FROM" < t a L b "WHERE" <condiciones>
'1 <coluninas>: <identificador> ". "<identiticador> ,,
C," <identificador> "."<identifkador> )* 'I 11
II
11
i,
< tablas>: <identi f icadoo "."<identificador>
- ("," <identificador> "."<identificador> )* <condiciones>: <identificador> "."<ideniificadop ' I = '* <identificador> "."<identificador>
I <identifirador> "."<identificador> <operador> "texto" 6 .
<identificador>: C'a" - 'Y1 "A" - "y 1 &Q)+
. . <operador> I"=" I '%*' I *'<" I] 11
Tabla 2. Sintaxis de las consultas pennitidas por el traductor de consultas I1 I1
@ Cenidet 1999 I1
Página 22
il
lor6 AurilioCola ZaiucO Traduclor de Conrul!ar del Modelo Rdacional al hicdclo Oncniada a Objclor
il .lI
2.5. Técnica de Solución. , 1
!I Para el desarrollo del traductor de consultas se utiliza una técnica de traducción de consultas
Ilainada Grafos de Predicados [ IOJ . Una de las granbes ventajas de la técnica es que permite la
traducción bidireccional entre el modelo relaciona¡ y el orientado a objetos. En este trabajo
solo se considera el enfoque de 'traducción de relacional a orientado a objetos. Se decidió
utilizar la técnica de grafos de predicados porque ha demostrado tener mayor información
seinántica que la técnica de grafos de consultas, pcopuesta en la literatura [ IO] . La técnica de
grafos de predicados consiste en tomar una consulta en SQL y analizarla para generar un g a f o
relacional en el cual se representa dicha consulta y se obtiene información acerca de las tablas
y las relaciones entre ellas dentro de la consulta. Enseguida se analiza el g a f o relacional y se
transfonna en un gafo orientado a objetos, de'donde se obtiene la consulta orientada a
objetos.
I1
11
/I /I
I/ ' I
I1 !I 1
5 11 II
/I
Haciendo un breve resumen de la técnica, en ella se muestra al usuario una vista I
relacional de los datos, es decir, las bases de datos ionentadas a objetos se representan en tablas virtuales y mediante ellas el &ario puede realizar lí sus consultas usando el SQL, olvidándose
1: de los detalles y del lenguaje para acceder a una base de datos orientada a objetos.
'/
' . ... .,.
@ Cenidet 1999 'I
Página 23
(i Arquitectura
del Sistema
!I El capítulo muestra en forma get!eral el procesamiento de la información a través de la técnica
de traducción de consultas, así como una breve descnpcih de los módulos que componen a la
arquitectura utilizada. I1 I1
ii
SQL es el lenguaje estándar usado por las baseslde datos relacionales, y sus instrucciones y
operaciones son dirigidas'para ese tipo bases de datos. Para otro sistema de infonnación con
modelo de base de datos diferente es posible utiljzar otro lenguaje que permita acceder a los
datos.
11.
'1
. . El objetivo del presente trabajo es acceder por medio d: SQL a una base de datos
orientada a objetos la cual tieke su propio lenguaje de.consultas. Para que el acceso sea
posible, es necesario mostrar una vista relaciona1,de las clases del esquema objeto y hacer una
traducción de la consulta en SQL a OQL y de esta forma acceder a los datos de la base de
datos orientada a objetos. De acuerdo con la lityratura [lo] los pasos a seguir para lograr lo
anterior son:
I . Transformación de los esquemas orientados a objetos en esquemas relacionales.
1 . I
I1
I NI
/I
Ni Página 24 I
0 Cenidet 1999
I 1
lor¿ Aureho Cola Za7ucla Traductor dc Consultar del Mcdrlo Rclaciooal al Mcdelo Oncniado a Objetor
2. Consttucción de grafos relacionales ,I a.partir de Id ' t consulta.
3. Conversión de grafos relacionales en grafos orientados a objetos.
4. Generación de consultas en OQL'a partir de los grafos orientados a objetos. 1; I1
La arquitectura del traductor de consultas1 se muestra en la figura 3, definiendo las
'i
I!
entradas y salidas de los procesos.
Grafo
Relacional
Transfonnación del Grafo Relacional en Grafo Orientado a Objetos Grafo Relacional .
Virtual
Creación de Consultas OQL
I , Esquema Ejecutar ~ ~~ 11 1 ~ I Consuira en OQL I Onentado a I -b I Consulta OQ&
Resultados, , 4
Figura 3. Arquitectura del traductor de consultas
La arquitectura muestra, el proceso para 'lransfonnar una consulta reali.zada en SQL.
Inicialmente se tiene un OODBMS, con un esquema (en adelante se denominará esquema
objeto) que describe la estructura de la base de datos orientada a objetos. El esquema objeto
describe las clases y atributos que componen a ¡a base de datos. El esquema objeto se debe
transfonnar en un esquema equivalente (que en ,adelante se denominará esquema relacional)
de una base de datos relacional! Es decir se toma el esquema objeto y a través de un conjunto
@ Cenidet 1999 I! Página 25
I: I
I/ i ! < /I I ~I
li lor6 Aurclio Cola Zizueia Traductor dc Canr~ltai del Mcdclo Relucional a1 h(c+rla Oncniado a Objcior
t
de reglas se crea un esquema relacional virtual (el proceso de transformación se describe en el
capítulo 4). El esquema relacional virtual contiene,las clases representadas en forma de tablas
y los atributos en fonna de colurpnas. Las relaciones existentes entre las tablas se representan
mediante otros conceptos equivalentes, por ejeinpio en llaves primarias, relaciones I-m y
11
I I .
relaciones n-m. !?
11 Una vez que existe definido un esquema relacional equivalente, es posible realizar
II consultas por medio del esquema relacional virtual. La técnica utilizada en la tesis considera
I1 11 consultas en SQL que sólo incluyen un subconjunto del estándar de SQL, tomando en cuenta
R solamente las cláusulas SELECT / FROM /WHERE. La consulta recibida se transforma en un
Grafo Relaciona1 mediante la técnica Grafos de Predicados (descrita en el capítulo 5) . I 11
/I
El Grafo Relacional contiene nodos y alistas, los nodos representan cada una de las
tablas participantes dentro de lalconsulta, las aristas representan la relación entre las tablas. La
técnica de traducción utilizada hace énfasis en la Eláusula where, porque es donde se encuentra
la complejidad para represent:; a una consulta 'Leiacional en una consulta objeto. Un grafo
relacional representa a las interacciones entre las tablas de la consulta.
I/
II
,i 11
Con las interacciones entre las tablas, y de acuerdo con la forma en que se obtuvieron
las tablas durante el proceso de transformación de esquemas, es posible representar las tablas
en clases mediante un grafo de ¡objetos (la técnica para convertir un grafo relacional a un g a f o
de objetos se presenta en el capítulo 5). Así el grafo objeto muestra las clases a las cuales se
accederá durante la consulta, por lo tanto a partir, del grafo objeto es posible crear una consulta
e i OQL que represente las interacciones entre los nodos o clases del grafo objeto. Las
consultas en OQL pueden apliiarse al OODBMS', obteniendo los resultados solicitados desde
la consulta en SQL.
I t
/I ' t
li
,I I
:I
@ Cenidet 1999 Página 26
I I/ lorc Aurclio Cola Luucia Tnduclor dc Consultar del Mcdclo Rclacional 81 hlodelo Onenlado a Objclor
Concepto del
Mundo real
Entidad
Tipo de Entidad
Identidad
Relación 1 - m
11 3.1. Traductor de Esquemas
Modelo Modelo 8.
li IOrientado a Objetos Relaciona1
Objeto Tupla
Clase .I Relación 1
OID (iaentificador Único del objeto)
Atributo Complejo y dominio de una clase
Llave primaria
Llave y llave foránea II
Un modelo de datos es un conjwnto de herramientas y conceptos que sirven para modelar
objetos del mundo real. Existe una variedad de modelos y dependiendo del tipo de aplicación,
tipo de manejador, tecnología de hardware y software, son utilizados [4]. El modelo de datos
orientado a objetos modela los aspectos estructurales y de comportaniiento, mientras que el
modelo de datos relacional solamente modela la parte estructural, lo que hace al modelo
orientado a objetos más poderoso y expresivo.
I/
!I 1:
.: 11
Para la transformación de esquemas orientados a' objetos a esquemas relacionales se ;I
desarrolló una herramienta donde únicamente SI consideran los aspectos estructurales, es
decir, no se incluyen los métodos de las clases. Co'mo los modelos son diferentes en estructura,
pero tratan de representar los misino objetos del &undo real, se puede ?acer una equivalencia
de ciertas construcciones que son utilizadas por ambos modelos, como se muestra en la tabla 3 'I ;I
Además de algunas de las diferencias que)/:existen al representar los objetos, también
existen ciertas operaciones o relaciones que no s& puedez representar en el modelo relacional,
por ejemplo, en el modelo orientado a objetos es pennitido tener atributos conjuntos de otras
clases, las cuales representan relaciones de m:m. Los atributos permitidos dentro de los
esquemas de las bases de datos orientadas a objetos para este trabajo son los siguientes:
1. Atributos primitivos o simples. Son aquello,s atributos que tienen dominio de los tipos ;i
básicos del lenguaje de pro&amación que se esta usando para crear las clases de la base de
datos orientada a objetos, por ejemplo los tipo integer, string, flotante, etc. (I
1) Ir
I'
Página 27 il @ Cenidet 1999
'I
'i . 1. Transformar cada clase a una relación. Sea Rel(C) una relación transformada desde la
I clase llamada C. El nombre de la Rel(C) es i g i d al de la clase C.
2. El atributo identificador Único de clases OID de una clase llamada C cuando se
transfonna se convierte en h l lave primaria de,una Rel(C) y es renombrado al nombre C-
OID.
3. Cada atributo de tipo primitivo no-conjunto de una~clase llamada C se convierte en una
columna de la Rel(C) y el dominio de la c o l u h a es igual al del atributo que estaba en la
4. Cada atributo de tipo complejo y no-conjunto ¡de una clase llamada C, el cual tiene como
- Rel(C). El atributo llamado CI-OID de la relación Rel(C) es una llave foránea que hace
I ti
!I
clase llamada C. ~I
dominio a una clase llamada C1, cambia.su II nombre por C1-OID y permanece en la
.!I
'I II
referencia hacia la relación llamada Rel(C1).
5. Si la clase llamada C tiene un atributo A complejo y conjunto con dominio de la clase C:,
entonces se elimina el atributo A de la relación Rel(C) y crea una nueva relación con el
nombre C-CI. C-CI tiene dos atributos C-OID y C1-0ID.- La llave de C-CI consiste de
las dos columnas.
- I/'
'1
11
;I Tabla 4: lReglas de Transformación de Esquemas
I @ Cenidet 1999 Página 28
los i Aurclio Cola Luucta Traductor dc Consuliar del Mcdclo RcIacional al hkdclo Orientado a Objetor
Oficina OID Edificio Cuarto
i! U n esquema objeto está compuesto de una o:más clases que están relacionadas entre si
y que a partir de ellas es posible la creación de objetos que son almacenados de forma II permanente dentro de la base de datos orientada a oftjetos.
<I/ . I!
+---. Profesor +--, Graduado OID OID
Tesis ..-:;:ilpana /I -- Asesor
Las flechas utilizadas dentro de la figura 3!i representan relaciones entre las clases. La
flecha delgada indica que un atributo tiene como dominio a la clase apuntada por la flecha, por
ejemplo el atributo Profesor.ofi&na tiene como 'dominio a la clase Oficina. La flecha gruesa
indica que la clase en el origen de la flecha es unk subclase de la clase apuntada (superclase),
dando por consecuencia que la"subc1ase heredará atributos de la superclase. Por ejemplo: la
11 . .!
11
subclase Profesor hereda los atributos Rfc, Nombre, II Edad de la superclase Persona.
!I
@ Cenidet 1999 Página 29
81 11
11 ,
11 . I1
Jori AurrlioCou k u e i a Tmducior dc Conr~liar del Modclo R~lacianal al Modelo Orientado a Objclor
AI esquema orientado a objetos de ¡a figura'u.2 se le aplicó el algoritmo de I/
transformación de esquemas y las reglas de transformación obteniendo el esquema relaciona1
virtual, que se muestra en la tablal5: I
Columna
Persona-OID,
Rfc, Nombre, Edad
Profesor-OID, Rfc,
Nombre, Edad, Categoria,
Oficina-OID
AIuI~Mo-OID, Rfc,
Nombre, Edad, Grupo
Graduado-,OlD,Rfc,
Nombre,Edad,
Grupo,Te&, Profesor-
OID
la 5. Tablas obtenidas de la
I/
'I
Tabla
Persona
Profesor
Alumno
Graduado
Ti
'1
Tabla
11 Materia
1 ' i
~i Oficina
;.
i
: Aluinno- 'i I ' Materia ~1 Graduado-
~
Materia
tiansformación
Columna
Materia-OID,
Titulo,
Día, Hora
Oficina-OID,
Edificio,
Noficina
Alumno-OID,
Mate:a-OID
Graduado-OID,
Materia-OID
.
e esquemas
El número de tablas resultantes de la transformación de esquemas es diferente al
número de clases, debido a que 1% durante el proceso I1 de transformación de las clases, para /I representar algunos tipos de atributos es necesario crear nuevas tablas. r
En el capítulo 4 se describen detalladdbente el algoritmo y la implantación de la
transformación de esquemas orientados a objetosa esquemas relaciona!ir dentro de! ámbito de
trabajo global. .'j 11
11
@ Cenidet 1999
- _ ~ I/ Página 30
I lore Aurilio Cola Luuela Traductor de Consultar del Modclo Rclacional al Modclo Oncniado a Obictor
3.2. Creación de Grafos Relacionales I/ I
El esquema relacional obtenido en la fase anteno;, contiene varias tablas que representan las
clases que constituyen el esquema objeto. El lenguaje SQL es muy extenso y en este trabajo
no se realiza una implantación completa, solamente se consideran las claúsulas Select, From, y
Where, excluyendo las cláusu1as’:Order By, Group’IBy, etc. debido a que la técnica de grafos de
predicados no las considera dentro de la conve(/iÓn, además de que sus funciones pueden
realizarse mediante un tratamiento posterior al proceso de recuperación de los datos. A partir
de un esquema relacional y de una consulta solicitada por el usuario, se procede a formar el
ga fo relacional. En los párrafos posteriores se describe brevemente cómo se obtiene el grafo
relacional. Un ejemplo de una consulta para el Zsquema relacional presentado en la tabla 5
puede ser la siguiente:
11
I
I1 11 I1
‘1 . 11
, I SELECT Profesor. Nombre, Oficina.
FROM Profesor, Oficina. Graduado. Graduado-Mareria,Mn feria
WHERE Profesor. Categoria =“Tiempo completo” , AND Profesor. Oficina-OlD=Oficina.Oficina-OID AND Oficina. Ed@cio= “Computación 11 AND Profaor. Profesor-OID=Gradirado. Profésor-OlD
AND Graduado. Graduado- OID=Graduado-Materia. Graduado- OID
AND Graduado-Materia.Moreria-OID=~ateria.Maieria-OID
AND Materia. Titulo=“Base de Datos“
11 -
I!
:.
I,
La consulta anterior consta de las cláusuias SELECTIFROWWHERE. Las columnas
que se encuentran en “Select” se procesan hasta el momento de generar la consulta y las de
“From” se recopilan para form’ar los nodos quekomponen ai grafo relacional. El resto de la
consulta es la clausuia “Where” que contiene información acerca de las caractensticas que
deben cumplir los datos para ser seleccionados’ como resultado de la consulta. La cláusula
Where está formada por expresiones (una expresion puede ser una igualdad, una desigualdad,
etc.). Las expresiones pueden representar varias: operaciones conocidas dentro del ámbito de
las bases de datos, por ejemplo la reunión. Unalreunión es un conjunto de resultados que se
obtiene de 2 tablas, unidas mediante una columna en común. Las reuniones se representan
’.!
li
‘L !I. , /I
11 I/
‘I @ Cenidet 1999 Pigiiia 31
'!
Jorf Aurilio Cota &uem Tradwtor de convliar del hkdclo Rclacional al Mdelo Onentado a Ohjetor
11 11 . .
mediante una igualdad y una misma columna de ahbos lados, aunque la tabla sea diferente. A
continuación en la figura 3.2.1 se muestra una reunión: 11 I1
/I
Profesor.OficinajlD=Oficina.Ofic~na-OID 11
\Tab[ . I '1 . Figura 3.2.1. Ejeinplo'de Reunión
(I
I
Para representar una cláusula Where en un grafo relacional se debe hacer una
clasificación de las expresiones'o predicados que contiene. Es decir, se toman las expresiones i;
y si la expresión es una igualdad y la columna es la misma, entonces esa expresión 1 11
corresponde a una arista dentro del grafo relacional. Por ejemplo, la sig;iente expresión no es
una reunión: :I
I'
. I1
11 Profesor. Categoria ="Tiempo completo"
I1 I
1; Una vez determinadas las expresiones que son Reuniones, se procede a extraer los
elementos que constituyen la1 reunión. De esa manera representamos las interrelaciones
existentes entre los datos y las tablas que componen a la consulta de SQL; formando así el
grafo de predicados relaciona1 que se muestra en la figura 3.2.2 11 /I
11
@ Cenidet 1999 Página 32
i :I
Tndwior de Co'nr"liar dcl Modelo Relaciona1 al Modelo Orirnkado a Objctor ,I
lore Aurilio Cota Zarucia
. . 1;
'i /i .~ . Cafegoria=
" Tienipo Conipleio" Profesor
lí
Professor-OID Graduado
I Oficina-01
",,/Grad ado-OID
I1
Materia
Graduado-Materia /, I
Oficina Edificio= "Computación''
Titulo="Base de Datos"
. 'I
Figura 3.2.2. Una cláusu!a Where dentro de?" Grafo de Predicados Relaciona1
3.3 Obtención de Grafos Oriehtados a Objetos''
I
El grafo de predicados relacional muestra directamente las relaciones existentes entre los datos
de las tablas que participan en la consulta. Hasta este punto, aún se tiene un enfoque
relacional, ya que solamente se ha representado) /1 la consulta dentro de un grafo de consulta.
Ahora necesitamos darle un enfoque orientado a objetos, y para lograrlo es necesario que el
g a f o de predicados relacional se represente en un grafo orientado a objetos, que muestre las
relaciones entre las clases de la consulta. Para iokrax la conversión se consideran las reglas ya
mencionadas en la tabla 4.
I¡ 11
II It
11
Generalmente, la creación de grafos (cualquier tipo de grafos) se basa en la unión de
nodos a través de aristas y las aristas pueden Ser dirigidas o no dirigidas. Además, pueden
llevar etiquetas para dar un sentido o significado semántico a la arista. En la creación de los
grafos de predicados relacionalb, se forman los nodos y se unen mediante aristas con etiqueta.
u 11
!I
I
@ Cenidet 1999 Página 33
I1
.i! lost AurclioCota k u c l a Tndurior de Consultar del Modelo Rclarionrl al hicdclo Orirntado a Objctor
En los grafos de predicados relacionales; cada nkdo representa una tabla perteneciente al
esquema relacional consultado. Las aristas representan la relación existente entre una tabla y
otra. Las etiquetas representan las columnas que relacionan las tablas. Hay que tener en cuenta
que el esquema relacional es vifual y que se creo a partir de un esquema objeto mediante !I,
reglas de transformación. f
II
,I
Los atributos pueden cambiar dependiendo'lde su tipo de dato. Los atributos que tienen
un dominio primitivo, permanecen igual, y sólo se crea una columna de ese mismo tipo en el
esquema relacional. Pero cuando se transforma un'atributo que no es de dominio primitivo, su
procesamiento es más complejo; incluso llegan a ,Frearse nuevas tablas adicionales al número
existente. Así que puede darse el caso de que existan tablas que han sido creadas a partir de
I! 'i
algun atributo complejo. I1 . ¡I .
Después de ver el origen de algunas columnas, cuando se realiza la transfonnación de
los grafos de predicados, se toma en cuenta el oriden de las tablas, ya que conocer el origen de
cada tabla pennite saber cómo se relaciona una tabla con otra. Por lo tanto, las columnas que
son utilizadas como etiquetas e; las aristas son examinadas y clasificados dependiendo de su
origen, y pueden caer entre vanos de los siguientes casos. Para la siguiente explicación se
supone que R es una tabla, R -0ID es la llave primaria de la tabla R y C es una clase. Las
reuniones están formadas por R; y R2
I!
11 . II
t
li
Caso 1. Cuando la etiqueta es R I -01D. Signifiia que la tabla Rg fue creada a partir de una
clese y no de un atributo y puede ser que R2 haya sido creada desde una clase o algún atributo I' .
complejo. ' I
Subcaso 1. I . Si la relación R2 es tran'sformada desde una clase, entonces la clase
C(R2) tiene un atributo complejo con dominio de la clase C(R1). Por lo tanto, debe
representarse con una arista desde la,[clase C(R2) hasta la clase C(RJ, etiquetada
con el atributo complejo. I
@ Cenidet 1999 Página 34
'I 11
'I 11 Jor¿ Aurelio Cola &ucU Traductor dc Conrdliar del Mcdclo Rclacional al Mcdclo Onenlado a ObJelor
J Subcaso 1.2. Si R2 esltransformi'.do deide un atributo conjunto complejo (SA) de
una clase C(SA), la clase es diferente C(R1). Entonces, para todas las tablas R
correspondientes a lai' clase C(SA) y .que sea adyacente a R2 en el grafo de
predicados relacional,, se creará una arista dirigida etiquetada con el atributo SA
desde R hasta R2. Si no existen adyacehes, entonces crea una clase nueva CI del 11
tipo de C(SA) y crea una arista dirigida desde la clase CI hasta C(R1) etiquetada I/
con el atributo SA. , ,
!I . /I
I J Subcaso 1.3. Si R2 corresponde a un atributo conjunto complejo de la clase C, la
cual es la misma que la clase C(R,). No se requiere ninguna acción, por lo tanto no
se crea ninguna arista. Solamente se ppsa a analizar otro caso dentro del grafo de
'1 ,I
predicados.
Caso 2. Cuando la etiqueta es R2 -0ID. Se siguen los mismos procedimientos utilizados en el
caso 1, solo que los subcasos 1 y 2 son intercambgados. I /
Llamaremos R "virtuales" a las tablas creadas a partir de atributos conjuntos
complejos. Enseguida se explica el procedimiento'seguido para la transformación de los grafos
de predicados. li I1
Primero se obtienen todas las tablas R que fueron creadas desde clases y se desechan
las virtuales, debido a que, de ahora en adelante estaremos trabajando con el esquema objeto y
las R virtuales no tienen clases'!equivalentes dentro del esquema objeto. Se realiza el proceso
de conversión (descrito en el capítulo 5) y se obtiene un gafo orientado a objetos que tiene
información de clases participantes en la consultay las relaciones entre dichas clases. El grafo
muestra la forma como están relacionadas las clases, por io tanto es posible crear una consulta
para que acceda a la base de datos orientada a objetos. El grafo orientado a objetos equivalente
al grafo relacional de la figura 3.2.2 se muestra efi'la figura 3.3.1:
'! 11
ti !!
I , .
!I / /
;i
@ Cenidet 1999 Página 35
‘i Jori Aurelio Cola Zuucia !I Traductor de Conwltar dcl Modelo Rclacional al Mcdclo Orirnlado a Objcior
Categoría=” Tiempo Completo’’ Profesor . . 11 Graduado
Materia Titulo=’Base de Datos”
I
I1
de la transformación de grafos Figura 3.3.1: Grafo de Predicados orientado a Objetos resultante
~i
Oficina
Edificio= ”Computación”
Los párrafos siguientes tratan acerca de la generación de las consultas a partir del grafo ’/
de predicados orientado a objetos. ’!
Ii
!I 3.4. Generación de Consultas Orientadas a Objetos
Para el desarrollo de este trabajo se utiliza el OO’DBMS llamado POET. El manejador utiliza
como el lenguaje de consultas lei OQL (Lenguaje de consultas estándar para bases de datos
o$entadas a objetos que se rigen por el ODMG). Otra característica del manejador es que
permite almacenar y recuperar objetos creados desde aplicaciones de C++ y Java. En este caso
se está trabajando con el lenguaje Java, por sus!tcaracteristicas importantes de pcr?ahi!ic!ad y
orientación a objetos.
11. il
;I
li
El grafo de predicadosIlorientado a objetos, se compone de nodos y aristas dirigidas
etiquetadas por atributos. Durante la creación del ga fo de predicados orientado a objetos, se
forman secuencias de nodos y aristas, denominadas Rutas de Expresiones que muestran el
camino a seguir para acceder a los datos a través’lde las distintas clases contenidas dentro de la
11
Ii
11
@ Cenidet 1999 ‘f I
Página 36
I!
¡I los+ Aur~l io Cola 7azurla Tndueior dc Conru!iar del Modelo Relaciona1 al hlcdrlo Orientado a Objcior
. . .
ruta de expresión. Las rutas de expresión se utilizk dentro de los OODBMS para el acceso
más eficiente y eficaz de los datos. . . 1 1 ' . .
I 11
Para generar las consultasien OQL se deben'tomar en cuenta las rutas de expresión que 11
contiene el grafo. U n grafo orientado a objetos puede contener varias rutas de expresiones y II
pueden ser: Expresiones simpl&, expresiones dbbles, expresiones con reunión explícita.
(descritas a detalle en la sección 5.3) i!
11
Para cada caso se procede diferente, pero en la parte donde es una ruta de expresión
simple, se crea una estructura que contiene la skuencia de las clases que hay que visitar 11
durante la consulta a la base de datos. Después de un estudio del lenguaje OQL, se determinó
que solaniente hay que hacer un recorrido a tray& del grafo e ir tomando la inforniación
acerca de las condiciones que deben cuinplir los datos de cada una de ekes accedidas.
II
I¡
'.I
@ Cenid,et 1999 Página 31
Transformación
de Egquemas
El capítulo detalla el proceso para la obtención, Al diseño y la transformación de esquemas
orientados a objetos a esquemas relacionales. La,;obtención del esquema orientado a objetos
puede realizarse de dos formas, la primera utilizando una herramienta de diseño de esquemas
y la segunda extrayendo el esquema directamente del archivo de definición de clases de
OODBMS.
I1
jl
01. Modelos de Datos.
Las operaciones de negocios, actividades rutinarias, información acerca de personas y hasta
las reglas de negocio de las empresas son representadas dentro de bases de datos con el fin de
automatizar y eficientar los procesos de las empresas. Del modelo de datos .utilizado para
modelar el sistema, dependerá la forma del diseño del sistema de base de datos. Los modelos
de datos utilizados en el diseño de un sistema de información determinan su flexibilidad, el
tipo de uso y el comportamiento del sistema. En el trabajo de tesis se hace uso de los modelos
de datos relaciónal y orientado a objetos.
11
11
i( I:
@ Cenidet 1999 Página 38 I
i . .
.~ .
' ' ' l'i, 4.1.1. El Modelo Relacionai
. . En el modelo relacional, las entidades se representan en forma de tablas. Una base de datos
relacional se compone de una o más tablas. .Los usuanos de la base de datos ven los datos en
forma tabular. A la definición del conjunto de tablas que constituye una base de datos
relacional se denomina Esquema Relacional. Mediante un lenguaje de consultas los usuarios
obtienen los datos almacenados en las tablas de.la base de datos. El lenguaje estándar utilizado
por el modelo relacional es el SQL y es el más común dentro de las aplicaciones de las
empresas. En la tesis se considera que los usuanos realizarán sus consultas en SQL.
I1 . /I
,I
i i I¡ . 1
\ 4.1.2. El Modelo Orientado a Objetos
, En el modelo orientado a objetos, las entidades se representan en forma de objetos, definidos
por clases. Las clases describen como están formadw los objetos y pueden representar su
comportamiento mediante la inclusión de métodos, que expresan la reacción de los objetos
ante eventos y situaciones. Las bases de datos orientadas a objetos se componen de una o más
clases, a la definición del conjunto de clases se denominan Esquema Orientado a Objetos.
ii
' I
I1
1)
4.2. Transformación de Esquemas Orientados a Objetos a Esquemas Relacionales I
I1 El objetivo principal de la tesis es que los usuarios accedan a una base de datos orientada a
objetos realizando consultas utilizando SQL. Pqa lograrlo, es necesario que el usuario tenga
una representación de los datos en forma de tablas, por 'lo tanto es necesaria la transformación
del esquema orientado a objetos a un esquema relacional equivalente. La transformación
incluye solamente a los esquemas, los datos pennanecen intactos, de tal manera que el
resultado de la transformación es un esquema relacional compuesto de varias tablas virtuales
que el usuario utilizará para realizar sus consultas en SQL.
- !I II
I1
11
I1
@ Cenidet 1999 Página 39
!I ,I
lore Aurelin Cola Zazutla Traductor ae Consuliar dtl Mdt lo Rclacional al Modelo Orientado a Objcior
I¡
11 4.3. Transformación de Atributos
En la tabla 4 se presentaron las reglas para la transformación de las clases en tablas. Las clases
contienen atributos que describen un tipo de datos que compone a la clase. Las reglas de I
transformación se aplican sobre las clases y los atributos. La regla número 1, aplica sobre la
clase, y significa que por cada clase existente se creará una tabla virtual. El resto de las reglas
de transfonnación aplican sobre los atributos contenidos en la clase. A continuación se
muestra una descripción de los tipos de atributos1 utilizados en los esquemas orientados a
objetos:
'I
il /I II
Atributo Simple o Primitivo
t----- Atributo Complejo
Atributo Complejo-Conjunto t----- I
Tabla 6:
Se refiere a los atributos que tienen como dominio a uno de
los tipos básicos del,lenguaje de programación.
Aquellos atributos que tienen como dominio a otra clase.
Son aquellos atribütos que contienen e'n su interior uno o
1: 11
'I
11
más objetos que tienen dominio de diferente clase. I
'ipos de Atributos contenidos en las clases
En la figura 4.3.1 se muestran gráficamente los tipos de atributos presentados en la tabla.
Atributo Simple
String sCadena="txt";
I I
f - !
! !
I
I
I - . . - . . - . . - . . - . . - . . - . . - . . -, . - _.
a) Atributo Simple
Atributo Complejo
Oficina Objetol; Int n0bjeiox;
I
n
- - . . - . . - . . - . - . . - . - . . - - . - - - . ! . -I . . - - :: i Clase Principal
Class I
I
I I I I
I I
Objetol
I ;u I I
1 , . - - . . - . - . . - . . - . . - , . - . . - . . -. . - . . -. . - . . - , . - , . - b)Atributo Complejo
Figura 4.3.1. Representación gráfica de un atributo simple y un atributo complejo. 11
@ Cenidet 1999
I¡ Página 40
1 lost Aurclio Cota L v u r w Tduciar dc Conrulisr del Modclo Rclacional al Modrlo Oncniado a Objcios
Los atributos mostrados en la figura 4.3.1 son más sencillos que el atributo complejo-
conjunto, porque no ocasionan la creación de nuevas tablas adicionales al esquema relaciona1
equivalente. Cada uno de los atributo de los mostrados representa solamente a un objeto, y el
atributo complejo-conjunto puede tener más de un objeto. En la figura 4.3.2 se muestra un
atributo complejo-conjunto, que contiene dentro varios objetos con dominio de diferente clase.
En la tesis se contemplan atributos complejo-conjulo con uno o más objetos con doniinio de
la misma clase.
li
I' 'I ':
' t
Atributo Complejo Conjunto ?
String scadena;
int nObjetox; Materias mObjetos;
. . . - - - -. . - . - . . - . . - . . - . . - . - - . . - - -. . - . . - - . . -
I
I
I
Clase Principal Materia w:
Class Materia
Materia 4. _ _ _. --- niobjetos I
Materia I
Figura 4.3.2 Representación gráficaide , ,I un atributo complejo-conjunto.
Los atributos complejo-conjunto tienen un proceso más complejo de trai&nriacii>n,
debido a que incluyen dentro de la clase a objetos de otras clases. Un atributo coinplejo-
conjunto debido a la característica de inclusión de otras clases, representa una relación de uno
a muchos, y la fonna de representarlo es mediante hcreación de una nueva tabla que contenga
la llave primaria de la clase donde se encuentra ,al atributo complejo-conjunto y la llave
primaria de la clase correspondiente al dominio del atributo complejo-conjunto.
;I
@ Cenidet 1999 ! Página 41
lor¿ Aurelio Coi3 hueb Tradwior dc Conrulias del hlcdrlo Relaciona1 al Modelo Oncniado a ObJrlor
4.4. Herramienta de Transformación de Esquemas Relacionales a Esquemas Orientados i,
a Objetos. !I
1.
Se desarrolló una herramienta de software que permite el diseño de esquemas orientados a
objetos y/o la transformación de los esquemas orientados a objetos en esquemas relacionales.
La herramienta permite recuperar un esquema de!: una base de datos orientado a objetos
existentes y para ello realiza un análisis léxico sobre la definición de esquemas, extrayendo la
infonnación referente a las clases definidas en la bast de datos.
I). I
'I
II
Una base de datos en POET se diseña medi'mte archivos de texto que contienen la
definición de las clases que componen a la base de datos. Además del archivo de definición de
clases existe otro archivo de texto que incluye los notnbres de las clases que se desean incluir
en la base de datos. El analizador léxico toma como &rada de datos &archivo de definición
de clases. El analizador léxico se desarrolló utilizand; la herramienta JavaCC [23]. JavaCC es
un generador de analizadores léxicos y sintácticos qUe genera código en Java. En la figura
4.4.1 se muestra la ventana principal de la herramienta de diseño y transfomiación de
esquemas orientados a objetos:
I1
I\ .
Figura 4.4.1. inierfaz gráfica de la herramienta de diseño y transformación de esquemas orientados a objetos.
1; .I
@ Cenidei 1999 Página 42
11 1 II
lore Aurelio Cota Z u u c i a Traduciordc Consultar dcl Modclo Rrlacional al Modelo Onenlado a Objctor
i( Ij
La ventana muestra campos de texto, áreas de texto y botones de comandos con los
cuales se realizan varias de las tareas tales como lagregar clases y atributos, transfonnar el
esquema , realizar consultas sobre el esquema rela!ional, entre otras. Para extraer el esquema
de una base de datos existente se utiliza el botóni "Ir a BD" e inmediatamente aparece un
cuadro de selección de archivos mostrado en la figura 4.4.2:
1
'I
'I
Figura 4.4.2. Ubicación del archivo de defmición de clases
En el cuadro se selecciona el archivo con la definición del esquema orientado a objetos. El
archivo se toma como entrada para el analizador l!xico que le da el siguiente tratamiento: I!
1. Mediante palabras reservadas y siguiendo una construcción gramatical obtiene los
nombres de las clases y atributos contenidas en el esquema objeto y los agrega a otro
archivo de texto.
2. Se repite el proceso hasta que se detectan todas las clases y atributos del esquema y
finalmente queda un archivo de texto con//la infonnación de la base de datos orientada
a objetos.
,! ,
I \
3. El archivo de texto resultante, se carga dentro del espacio de memoria del programa de transformación de esquemas para su procesamiento II . posterior.
'I
11
@ Cenidet 1999 Página 43
lor6 Aurrlio Cola ZmurU Traducior dc Cenru!iar del hkdclo Rdacional al hiodelo Onenlado a Ohjcior
Cuando no se tiene el archivo de definición del esquema de la base de datos orientada a
objetos, el esquema debe ser diseñado por el, usuario o por una persona que tenga
conocimiento de la estructura de la base de datos. Para diseñar un esquema orientado a objetos
se utiliza la interfaz de la figura 4.4.3. y se utiliza el siguiente procedimiento:
11
I ir
:I I . Introducir el nonibre de la clase dentro del campo de texto etiquetado “Clase” y
II
presionar el boton de coinando “Agrega+ Clase”. ‘I
2. Introducir el nombre del atributo en el campo de texto etiquetado como “Atributo”,
y seleccionar las opciones que coincidan con el dominio del atributo. Presionar el
botón “Agregar Atributo” y el atributoi será agregado a la clase actual. Repetir el
paso 2 hasta que se introduzcan todos los atributos de la clase en construcción. i
3. Repetir los pasos 1 y 2 hasta que se:)complete el esquema con todas las clases
correspondientes.
4. Cuando el esquema está completo, es posible guardarlo eñ un archivo de texto
mediante la opción “Guardar” ubicada en el menú principal .
/I
II
. \
Figura 4.4.3. Un esquema orientado a ObJetoS
El diseño de un esquema orientado a objetos terminado se muestra en una estructura de
árbol en la figura 4.4.3. Los nodos del árbol representan clases y atributos. La transformación
de esquemas se basa en el árbol de clases y atributos 11 (que denominaremos árbol objeto).
@ Cenidet 1999 Página 44
11 lose AurclioCota L v u m Traducior dc Consulpi dcl hícdclo Relaciona1 al Modelo Orientado a Objetor
Ir
Un aspecto importante es el tratamiento de la qerencia dentro de las clases del esquema
orientado a objetos. Una de las características del lenguaje Java es que no soporta la herencia
múltiple y cuando se definen clases que inducen a la herencia múltiple, Java se encarga de
enviar mensajes de error al momento de compilación para que se evite la herencia múltiple.
I I1
i 11
Durante la transfotmación de esquemas orientados a objetos se hace un bamdo a traves de
las clases y cuando alguna clase tiene herencia de btra clase los atributos de la clase padre se
agregan a la clase hija, excepto el atributo que repiesenta el OID de la clase. Una vez que las
clases hijas contienen los atributos heredados de su superclase, se aplican las reglas de
transformación aplicando el siguiente procedimientb de transformación:
'I
11 I!
.I I . Ubicarse sobre un nodo del árbol objeto &e represente una clase que llamaremos C y
obtener el nombre de C. Crear un objeto tabla T y agregarlo a una estructura de árbol
que llamaremos "árbol relacional".
2. Obtener un atributo de C.
NI . . a. Si el atributo representa el OID de C entonces al nombre del atributo se le
antecede el nombre de la clase C: por ejemplo, si el atributo se llama OID,
entonces el nombre será C-OID. Y se agrega a T una columna con el nombre
11
I C-OID.
, l . < .
i
b. Si el atributo es de tipo simple o pnmitivo, entonces se agrega una copia del
atributo a la tabla T. c. Si el atributo es de tipo complejo,! entonces se obtiene su dominio. Ya que el
dominio pertenece a otra clase D,'Se obtiene el nombre del OID de la clase D,
el nombre del atributo complejo sesreeinplaza por D-OID y se agrega a T. !I ,
d. Si el atributo es de tipo complejo;~onjunto, se crea una tabla adicional T2, y las
columnas de T2 son los OID's de las clases involucradas. Primero se obtiene la
llave primaria de T (correspondieyte a C) y se agrega a T2, después se obtiene
el nombre de la clase dominio D del atributo complejo-conjunto'y se agrega el
atributo D-OID a T2.
1
- . .
I/
:I
11 3. Realizar el paso 2 mientras existan atributos en la clase C.
4. Realizar los pasos 1 ,2 y 3 mientras existah clases. il i
I¡ La figura 4.4 muestra un diagrama de flujo con el procedimiento anterior:
@ Cenidet 1999 Pagina 45
lore Aurilia Coi3 Zaruela Traducioi de Conru~iar del Modelo Relaciona1 al Modelo Orientado a Ohjctor
En la figura 4.4.5 se muestra la ventana con el esquema orientado a objetos /I
transformado al esquema relacional equivalente y las tablas obtenidas a partir de las clases del
esquema objeto.
'I Figura 4.4.5. Esquema orientado a objetos transformado al esquema relaciona1 11
En la sección 3.1 se presentó un ejemplo de un esquema orientado a objetos en la /I
figura 3.1 y su esquema relacional equivalente se presentó en la tabla 5.
Hasta este punto del trabajo, existen varias tablas vimiales que representan las clases
del esquema orientado a objetos. Las tablas no contienen información, pero los usuarios ya
pueden realizar consultas sobre las tablas. . ,I
-
@ Cenidet 1999 Página 47
Traducción de . . Consultas
A partir del esquema orientado a objetos se obtieneiun esquema relacional, el cual está
formado por vanas tablas virtuales, mediante las cuales los usuarios del SMD pueden realizar
consultas basándose en el esquema relacional. Las conhltas realizadas por los usuarios son
analizadas y representadas en grafos de predicados relacionales y postenonnente en grafos
orientados a objetos, de los cuales se obtienen las consultfis orientadas a objetos.
I
'I 'I
Una base de datos orientada a objetos manejq su propio lenguaje de consultas, en este caso
la base de datos objeto utiliza OQL, y los usuarios delI;SMD no podrían utilizar SQL para
obtener datos de ella, por lo tanto es necesario que la base de datos orientada a objetos se
muestre de tal forma en la que sea posible realizar consultas utilizando SQL. Para realizar la
traducción de consultas es necesario contar con el esquema relacional equivalente al esquema
orientado a objetos que fue obtenido con la herramienta de'traducción de esquemas presentada
en el capítulo anterior.
11 I1
i!.
t
'1
@ Cenidet 1999 Página 48
. . -. ~
lose Aurrlio Cota k u c t a Tndwtor dc Consultas &I Modelo Rclacional al Modelo Onrniado a Objcior
El conjunto de tablas obte.nidas permite'al uSu)rio construir consultas usando ,SQL. Las
tablas tienen definidas llaves primarias que permiten hacer productos y reuniones entre tablas.
Para realizar una consulta, el usuario analiza las'' tablas y atributos existentes, ya que la
herramienta no proporciona información adicional que permita orientar a los usuarios acerca
de las relaciones entre las tablas. Un ejeniplo de una'bosible consulta se muestra enseguida:
I
SELECTPro/esor.Nonibre. Oficina. *. ' FROM Profesor, Oficina. Graduado, Graduado-Maieria,Maieria
¡I WHERE Profksor. Caregoria = "Tienipo conipleto"
AND Profksor.Oficina-OID=dficino.Oficina-OID AND 0ficina.Edijcio = "Coniputacion " AND Profesor.Proféso~-OlD=Graduado.Prof~or-OlD
AND Graduado. Graduada-OID=Graduado-Maleria. Graduado-OID /I
A N D Graduado-Materia.Uateria-OID=Materin.Mate~ia-OlD
11'.
I
11 0. A N D Mareria. Tirido="Base de Datos" 'I
Tabla 7. Ejemplo de consulta en SQL
La consulta está formada por una cláusula SELECT, en donde se especifican algunas
columnas de la base de datos; la cláusula FROM indica desde qué tablas se obtienen los datos;
finalmente una parte muy importante y fundamental p y a la técnica de grafos de predicados es
la cláusula WHERE que sirve para condicionar los datos que se recuperan desde la base de
datos.
i!
It
I /I
SI
5.1. Grafos Relacionales i
* :
La técnica de grafos de predicados utiliza el contenido de la cláusula WHERE, ya que en era
parte de la consulta se ubican las condiciones que deben cumplir los datos solicitados a partir
de la consulta. Dentro de las condiciones se encuentran predicados que la técnica toma para
darles un procesamiento especial. Los predicados representan a las condiciones que son del
tipo reunión. Una reunión representa un conjunto de datos obtenidos desde 2 tablas mediante
'I !I
I
'i un atributo en común, por ejemplo:
@ Cenidet 1999 Página 49
11 lost AurilioCoia iazuí ia Tmducior de Consuliar del hlcdelo Rclacional al Mcdclo Oniniado a Objcios
Pro/esor.Ojcina-O1D=Ojcina. Ojicina!OID . ' I>,;' I/ '
I
/I
La técnica de grafos de predicados utiliza solamente las reuniones porque a partir de las
reuniones se pueden deducir las relaciones entre las 'tablas, puesto que las tablas se obtuvieron
a partir de clases y sus relaciones en la base de datos onentada a objetos.
11
lil . '::I
Con base en lo anterior, solamente se utilizarán las condiciones que formen una reunión,
y las consultas se basan en esta suposición. En la consulta mostrada en la Tabla 7 se detectan
varias reuniones, que se muestran a continuación:
/:I!
Profisor. Oficina-01D = O/cina.Oficina-OID
Profesor.Profesor-OlD = Graduado.Profesor-OID
Graduado. Graduado-OiD = Graduado-Materia. Graduado-OID
Gi-odirado-Uaterio.,Uateria-OID = Mdteria.Uaieria-OID ' ,
I ,; 111
Aquellas condiciones que no representen a una 1:: reunión, se les llama selecciones, porque l .
solo hacen una comparación entre los datos de una misma tabla, por lo que no es necesario un
procesamiento más complejo para la obtención de esos datos. Las selecciones encontradas
corresponden a una tabla en particular. :t
Cada una de las reuniones mostradas involhcran 2 tablas, lo cual permite conocer
anticipadamente que las clases están relacionadas dentro de la base de datos orientada a
objetos. Las reuniones son representadas en f d m a de grafos. Los predicados para ser
representados dentro de un grafo de predicados relarional, siguen las siguientes convenciones:
'I
'I
11
Las selecciones se encuentran junto ai nodo que representa a la tabla de donde se hace
la selección de datos. ,
Una arista entre dos tablas significa que ambas tablas están relacionadas por medio de
una columna en común contenido dentro de ellas.
* Una etiqueta indica la coluinna que es común a las tablas.
En los grafos relacionales solo existen aristas no dirigidas.
- . Un vértice o nodo representa a una tabla.,
!i
:I
,I
11
@ Cenidet 1999 Página 50
11 , lost Aurrlio Cola Z u u c W Traductor de Consulta? dcl hlcáclo Rclaciotial al h iddo Onentadc a Objetos
11
La consulta mostrada anteriormente contiene Cuatro reuniones representadas en el II 'I g a f o de predicados relacionales de la figura 5.1 . I :
Caregoria= '* Tiempo Completo"
Profesor
Professor-OID Graduado
¿ Graduado-Materia '; TiniW'Base de Datos" . Oficina
Edificio= "Computación"
Figura 5.1.1 Grafo de Predicados Relaciona1
En la figura 5.1.1 se muestran vanos nodos que tienen asociado el nombre ,de la tabla 11
que representan y las selecciones sobre cada una de las tablas. Se muestran las aristas uniendo I!
l a dos tablas, mediante un atributo en común.
Categoria= " Tiempo Completo"
Profesor I
', :I
Profesor-OID , . Graduado
Figura 5.1.2 Reunión formada por la tabla Profesor y Graduado 1
11 Analizando con mayor detalle el subgrafo mostrado en la figura 5.1.2 se muestran las
tablas Profesor y Graduado, se observa que la tabla Profesor está directamente relacionada con
la tabla Graduado mediante la columna ProfesorJOID. La relación que existe entre estas dos
tablas es que el Graduado dentro del esquema objeto contiene un atributo complejo que tiene
11
'I
@ Cenidet 1999 Página 5 I f
lose Aurclio Coi3 iazucia Tnducior de Consultar del !h ie lo Rclacional al Mdclo Oncniado P O b p s
como dominio a la clase llamada Profesor, y la semántica de la relación existente es que “cada
alumno graduado desarrolló una tesis, la cual fue dirigida por un asesor de tesis”. Dentro del
nodo Profesor existe una selección que filtra los regiktros que cumplen con la condición de ser
profesor de tiempo completo.
il II
La herramienta de traducción de consultas analiia cada condición de la consulta mediante
un analizador léxico que permite obtener las tablas participantes junto con el atributo en
común cuando detecta una reunión, y de esa manera crear el gafo de predicados relacionales.
I1 ‘I
5.2 Grafos Orientados a Objetos
. Los grafos relacionales son una representación intermedia de las cons’ultas, ya que pennite
obtener información de las tablas virtuales y de las clases del esquema objeto. Mediante una
serie de pasos es posible transformar el grafo relaciona1 en un grafo orientado a objetos, y de
esta manera acercamos más a la estructura de la base de datos orientada a objetos. El
I!
algoritmo que contiene los pasos utilizados por la I Itécnica de grafos de predicados para la 1,
I conversión de grafos relacionales en grafos orientados a objetos se lista a continuación:
1 .- Obtener los nodos relacionales. Obteneri todos los nodos que representan tablas,
pero con la condición de que las tablas no hayan sido creadas a partir de un atributo
conjunto. Los nodos que cumplan con esa condición, representan a una clase dentro del
ga fo orientado a objetos. Y las selecciones que aplica sobre el nodo que representaba
a la tabla, ahora se aplicarán sobre la da&. I!
2.- Obtener las aristas éntre las tablas. Las aristas.contienen información acerca de la
columna que relaciona a las tablas. En este’paso se analizan las colurhas que son
utilizados corno etiquetas en las aristas y clasi$cados dependiendo de su origen, ya que
pueden caer en uno de los siguientes casos. Para la siguiente explicación se supone que
R es una tabla, R-OID es la llave primaria de, la tabla R, C es una clase y C-OID es el
atributo identificador del objeto.
11
‘I ‘I
@ Cenidet 1999 Página 52 I/
I/ lore Aurílio Cota Zazucta Traduclor dc Consulis del Mdclo Relacional al Md í lo Orientado a Objetor
I!
Caso 1. Cuando la etiqueta del subgrafo corresponde a Ri-OID, significa que la tabla RI fue
creada a partir de una clase y no de un atributo. Puede ser que R2 haya sido creada desde una
clase o algún atributo complejo.
II
!I
/i
!I
!I
Fig. 5.2.1 Subgrafo formado por dos relaciones 'I
il Subcaso 1.1. Si la relación R2 fue transformada desde una clase, entonces la clase
llamada C(R2) (llamada así porque la relación ahora representa una clase) tiene un
atributo complejo con dominio de la clase C(R1) obtenida de la relación RI. Por lo tanto,
se debe representar esto con una arista desde la clase C(R2) hasta la clase C(Rl),
etiquetada con el nombre del atributo complejo, así como se muestra en la siguiente
figura:
'!
/I
Fig. 5.2.2 Subgrafo formado por dos clases I!
Subcaso 1.2. Si la relación R2 se obtiene de'sde un atributo conjunto complejo (AC)
contenido dentro de la clase C(AC), entonces la! clase de R2 es diferente a la clase C(R1)
que se obtendrá desde la relación Ri. Para todas las tablas R obtenidas desde la clase
C(AC) y que sea adyacente a R2 en el ga fo de'predicados relacional, se debe crear una
arista dirigida etiquetada con el atributo AC desde cada clase obtenida de la relación R
hasta cada clase de R2, y si no existen adyacentes, entonces se crea una clase nueva
llamada Ci del tipo de la clase C(AC) y una ansia dirigida desde la clase C1 hasta la clase
C(Ri) etiquetada con el atributo AC. Las dos altdmativas se muestran a continuación en la
figura 5.2.3:
)I
!I
!I I¡ i!
'I
:I
@ Cenidet 1999 Página 53
II
r l José Aurelio Cola .?azueta Tnducior de Conrulq del Modelo Relaciona1 a l Modelo Orientado a Objetor
'I
. orientados a objetos.
.,-
a) Cuando existen nodos adyacentes I b) Cuando se crea una nueva clase /I
Fig. 5.2.3 Alternativas I1
, : : ./ , .'
. , Subcaso 1.3. Si RZ corresponde a un atributo'conjunto complejo de la clase C, la cual
es la misma que la clase C(R1). En este caso no se requiere ninguna acción, por lo tanto
no se crea ninguna arista. Solamente se procede a analizar otro caso dentro del grafo de
predicados.
%I II
'!
Caso 2. Cuando la etiqueta es R2-OID. Se siguen los mismos procedimientos utilizados en el
caso 1, solo que los subcasos 1 y 2 son intercambiados. i
@ Cenidet 1999
:i
!! Página 54
!I
,111
I1 losi Aurclio Cola Zazuci.3 Ttaduztor de Consulins del Modelo Relaccional al Modelo Orientado a Objeior
!I
Categoria=" Tieinpa Completo" Profesor Graduado
O j
0 teria Titulo="Base de Datos"
Oficina Edificio= "Computación" . .
Figura 5.2.4. Grafo de Predicados intermedio II
I!
En el paso 2, se obtienen todas las aristas del grafos de predicados relacionales. Como
ejemplo se tomó el nodo correspondiente a la tabla Graduado-Materia, y aplicando el caso 1
del dominio Materia de la clase
Graduado, entonces siguiendo las indicaciones, se .elimina esa tabla y se crea una arista
dirigida desde la clase Graduado hasta la clase Mateda.
!I
del paso 2, esta tabla fue obtenida desde un atributoiconjunto 11 '
11 . . !I
De esta forma, sometiendo a un análisis cada una de las aristas encontradas dentro del
g a f o de predicados relacionales y siguiendo las reglas indicadas obtenemos el grafo de
predicados orientado a objetos que se muestra en la figura 5.2.5 que se muestra enseguida: II
: ,! , .
@ Cenidet 1999 I/ Página 55
I Jose Aurdio Cola Z y u r a Traductor de Consullas del hlodclo Relacional al Modelo Orientado a Objetor
Categoria=” Tiempo Completo” Profesor Graduhdo
hlateria Titulo=’Base de Datos”
Oficina
Edificio= ”Compuiación
Figura 5.2.5. Grafo de Predicados Objeto resultahe de la transfonnack de grafos li
De esta fonna tenemos a los predicados de la consulta en SQL representados en forma
de grafo de predicados orientados a objetos, queinos lleva a una fácil representación de una
consulta orientada a objetos, ya que cada nodo representa una clase del esquema de la base /I
de datos orientada a objetos. II
5.3. Generación de Consultas Orientadas a Objetos ‘I
Los grafos objeto contienen clases representadas por nodos dentro del grafo y contienen
aristas etiquetadas con atributos. Los grafos pridntados a objetos representan las relaciones ’,. II
existentes entre las clases utilizadas implicitamente en las consultas de SQL, por lo tanto ‘:I las estructuras de los grafos de predicados orientados a objetos representan el acceso a las
clases y la navegación a través de las mismas mediante los atributos que tienen dominio de
las clases. Para obtener las consultas orientad& a objetos desde los grafos de predicados
orientados a objetos, se hace un recorrido a tra!és de todos los nodos, tomando en cuenta
las aristas que entran y que salen a cada nodo; Una arista que sale desde un vértice A y
,I
/I
@ Cenidet 1999 Página 56
¡I
!I Jori Aurelio Cola iazucta Tnduciordc Conrulihr de! Mdelo Relaciona1 al hicdele Orientado a Objetor
. .
entra en un vértice B quiere decir que dentro de 6 existe algun atributo cuyo dominio es la
clase A.
Los subgrafos formados, pueden ser de tres tipi'os diferentes. En las figuras 5.3.1, 5.3.2,
5.3.3 se muestran los tipos de subgrafos que representan a rutas de expresiones, como son:
1)
II 'I
a) ruta de expresión simple,
b) rutas de expresiones dobles y
c) rutas expresiones que fonnan una r e u n i l
Ni
!
Figura 5.3.1. Ruta de espresión simple
6 Figura 5.3 2. Rum de
. Figura 5.3.3. Rum dc
eroresión rimole con reuni6n . ~ . erpltita expresión doble ~
/i
'I 5.4. Lenguajes de consultas OQL y SQL
El lenguaje de consultas SQL y el lenguaje de consultas objeto OQL, son lenguajes utilizados
por las bases de datos. En los modelos de datos existen diferentes formas de representar los
objetos del mundo real, as¡ también los modelos de datos tanto relacional como orientado a
objetos respectivamente, tienen cierta capacidad deliexpresividad para modelar los objetos del
mundo real dentro de una base de datos. La expresividad de un lenguaje se refiere a la
capacidad de acercarse más a la realidad, por ejemplo el modelo orientado a objetos puede
acercarse más a la realidad de un objeto, esto es porque el modelo orientado a objetos puede
guardar además de la estructura el comportamiento mediante el almacenamiento de métodos.
Los métodos son funciones o 'comportamientos que hacen los objetos ante la presentación de
algunos eventos del medio ambiente.
,,I
/I
I1
:I
11
:I !I
I : ,
A pesar de utilizar diferentes formas de ver el mundo real, los modelos poseen algunas
similitudes, por ejemplo una clase representa una entidad, al igual que las tablas del modelo
relacional. Los grafos de predicados orientados a objetos, para poder ser convertidos dentro de
11
@ Cenidet 1999 Página 57
1016 Aurrlio Cota L v u e w Tnducior de Consulta? del Modelo Rrlacional al Modclo Onenlado a Obpor
alguna consulta orieniada a objetos, es necesario "conocer algún lenguaje que maneje el
parecido con el SQL, y el lenguaje indicado es el OQL. II
!I La consulta en OQL que se obtiene del grafo de predicados orientado a objetos
mostrado en la figura 5.2.5 equivalente a la consulta SQL de la tabla 7, se muestra a
continuación:
selecr * f rom GradiradoE.rrenr AS Daros
di ere Datos. Asesor.Rango = "Tiempo Parcial" AND ' I Daros. Asesor. oficina. Edi$cio= "Computation A N D
Daros.marerias. Titulo=''Base de Daros"
. .
@ Cenidet 1999 Página 58
II '. I1
Jorc Aurclio Cola Z;uuca Tmducior de Consultar del h4odclu Rclacional al Modclu Oriiritado a Objcios
. .
!
.
Pruebas Para el desarrollo del traductor de consultas se cr4aron varias herramientas que gradualmente
realizan la traducción de consultas. Dentro del' capitulo se muestra un ejemplo de una
traducción utilizando las herramientas.
6.1 Objetivos de las Pruebas
Una vez teniiinado el desarrollo de los módulos del traductor, fue necesario realizar una sene
de actividades, de tal manera que se probara la, funcionalidad de los módulos. El objetivo
principal de las pruebas del traductor, es probar y validar que la técnica de grafos de
predicados es correcta y que proporciona consultas equivalentes entre los lenguajes de
consulta relacionales y los orientados a objetos.
I
11
I II '
@ Cenidet 1999 11
Página 59
I /
lore A u d i o Cola k u i w Traductor de Consultar drl Modelo Rdaccional al Modelo Oneniado a Objtios
La meta a lograr en el siguiente ejemplo es comprobar y validar que las consultas
realizadas en SQL a las tablas virtuales obtenidas de la transformación del esquema orientado
orientado a objetos, transformarlo a tablas virtuales sobre las cuales los usuarios realicen
consultas en SQL y que las consultas orientadas a objetos obtenidas sean equivalentes.
a objetos, son equivalentes. Las pniebas a realizar ¡I consisten en introducir un esquema
I\
6.2 Descripción del Ambiente de Prueba
El traductor de consultas fue desarrollado e implantado utilizando el lenguaje de programación
orientado a objetos llamado Java y para validar las consultas orientadas que se generan del
proceso de traducción, se utiliza el manejador de bases de datos llamado POET.
¡I 1
'! . . Los esquemas orientados a objetos pueden/,ser diseñados o creados dentro de la
herramienta de transfonnación de esquemas, pero también pueden ser obtenidos desde el
archivo de definición de clases de Java, que es un archivo de texto donde se encuentra el
código fuente que representa a las clases, sus atributos y métodos que la componen.
li I1
II La forma de almacenar objetos dentro de POET es mediante aplicaciones realizadas en
C++ o en Java, Las aplicaciones crean objetos en memona haciendo ejemplares de las clases
ya creadas y las guardan dentro de la base de datos;; Los objetos que son alniacenados no
necesitan de alguna operación especial dentro del objeto para que sea posible almacenarse.
POET utiliza un archivo de configuración dentro del 'Cual se especifican los nombres de las
clases que van a ser persistentes en la base de datos orientada a objetos. Dentro del archivo de
configuración se encuentran los nombres de las clases y con eso las aplicaciones que crean los
objetos utilizan el archivo de cónfiguración y guardan ibs objetos que pertenezcan a las clases
mencionadas dentro del archivo de configuración. El traductor de consultas, durante el
procesamiento genera varios archivos de texto, entre, ellos uno que contiene al .esquema
,orientado a objetos, otro que contiene el esquema relaciona1 y uno más que contiene la
consulta orientada a objetos lista para ser usada sobre POET.
¡I .
I!
:I
II
,I
@ Cenidet 1999
II Página 60
Jose Aurclio Cala Z.uuiW Tnductor 6e Conrulias del Moddo Rrlacional al Moddclo Orientado a Objetos
6.3 OODBMS Poet
,I POET es u n sistema manejador de bases de datos orientadas a objetos que tiene la capacidad
de almacenar objetos creados en diferentes lenguajes de programación orientados a objetos, en
este caso de C++ y Java. El desarrollo del traductor de consultas se realizó en Java, y por lo
tanto se decidió que los objetos que se guardan dentro de las bases de datos serán creados a
partir de clases hechas usando Java. El lenguaje de consultas que utiliza para el acceso a los
datos es OQL. Para una base de datos es muy iniportante utilizar un lenguaje de consultas
adecuado y que no sea muy difícil y sobre todo que sea conocido por los usuarios. En un
principio, cuando se inició la creación bases de datos orientadas a objetos los fabricantes de
ellas utilizaban el lenguaje de consultas que ellos consideraban más adecuado. El lenguaje
estaba muy apegado a las características del lenguaje de programación utilizado para la
creación de las clases y por lo tanto el lenguaje s&ía ser muy dificil aprender. Un tiempo
después surge un organismo que se encargó de establecer un estándar dentro de las bases de
datos orientadas a objetos: Grupo de Administración de Datos Objeto (ODMG por sus siglas
en inglés). El ODMG agrupa a una gran cantidad de fabricantes de bases de datos orientadas a
objetos y de establecer estándares que permitan mlantener una compatibilidad entre diferentes
bases de datos orientadas a objetos, y un ejemplo es la creación del estándar del OQL. POET
utiliza el lenguaje de consultas OQL, solo que noitiene implementado todo el estándar y está
limitado en ciertas operaciones como consultas e ihserción de datos.
i/
1,
'1
!I
81
Ii
!I
!I
!I I
6.4 Esquema de la Base de Datos de Prueba . ,
Los esquemas de las bases de datos muestran la estructura interna en la que serán almacenados
los datos, pero en la tesis se manejan dos tipos de'esqueinas: Esquemas orientados a objetos y
esquemas relacionales virtuales.
@ Cenidet 1999 Página 61
Z9 eu!%d
u03 soiep ap aseq e1 ap etuanbsa 13 .sa.rouaiue s o j e q d ua ?uo!3uaui as anb qpemn8yuo3
ap oA!q3ie la ua sop!ugap q i s a ypuapo3 anb soiarqo ap odg la X '19 ap oiiuap od!i
ouis!tu ns ap so]a[qo S O F A oiiuap ppuai ,olarqo [a leni, 01 iod '13arqQlOiaS ody ap sa 'anb
oinquie un a u q o w n l v asep e t u s y e-p'euosiad asap el ap soinquie sol aiuauileuo!3!pe
ypuai ouuinlv asep e[ anb expu! [en3 01 'euosiad asap e[ apsap epaiaq o u m q v asep
el oiad 'asep eiio eu&u!u ap epaiaq ou anb K saiduiis soinquie S O ~ A aua!iuco anb asep
giln s? o x w a d ase13 e7 'sass13 seiio apsap uepa.raq sasep seun8Ie anb ap seuiape 'so!ii!urop
K sod!i saiuaiaj!p ap soinquie uaua!) s a s d p SEJ 'sopoi?ui iauaiuoa ou o apand acep epw
X 'sasep sei e a3auaUad anb q u a y 08!po:, ehiasqo as oixai ap o y p e lap oiiuaa
I!
!¡
d '
11
I1 '
iii ......... ..
'1 Traductor de Consultas dcl Xfidelo Relacional al Modelo Orientado a Objetos
la que se realizan las pruebas es el mismo que se!,ha utilizado a través del documento de
tesis y se presenta nuevamente en la figura 6.4.1.1 :,' ;I
11
4) 7 Aluinuo I Persoua ID ID Rfc ' Materias - d
Materia ID Titulo
Figura 6.4.1.1 Esquema Orientado a Objetos de prueba I1
Oficina t- ID ID ID Edificio Categoria Tesis Cuarto --Oficina -- Asesor -
6.4.2. Esquema Relaciona1 Virtual.
Siguiendo con el procesamiento de los pasos de la técnica de grafos de predicados, a partir
del esquema orientado a objetos se hace la traducición del esquema objeto hacia un esquema
rélacional virtual el cual contenga un conjunto de tablas que sean equivalentes al esquema
orientado a objetos. Las tablas virtuales no ;icontienen datos, solamente muestran la
estructura que tiene la base de datos orientada a objetos en su base de daros equivalente
reacional. El esquema relaciona1 virtual está formado por una o más tablas las cuales se
obtienen a partir de la transformación de las clases del esquema objeto aplicando reglas de
transformación.
t
il
I/
I
Con base en el esquema relacional, el ysuario ya puede hacer consultas en SQL
usando como referencia las tablas vimales, y usando las columnas puede hacer operaciones r Página63
I
Traductor de Consultas del Modelo Relaciona1 al Modelo Onentado a Objetor ,t
de consultas involucrando una o más tablas dentro de la misma consulta. Una de las
restricciones importantes que hay que tomar en cuenta al momento de formular las
consultas, es que solamente es posible efectuar cknsultas que involucran operaciones de
consultas que no tienen anidación de consultas detitro de la cláusula WHERE. Además que
el tipo de operaciones permitidas tampoco consideran funciones de agregación, como
ORDER BY, GRUP BY, etc.
11
'I
'I
'I
6.5 Contenido Inicial de la Base de Datos /I
El esquema orientado a objetos es solamente una:lrepresentación lógica de la base de datos
y no contiene datos dentro de él. Para efecto de Pruebas, nuestra base de datos orientada a
objetos tendra almacenados los datos de alumnos, profesores y materias, los cuales se
relacionan mediante mecanismos propios del pacadigna orientado a objetos, como son la
herencia y las especializaciones. La carga de los objetos a la base de datos se hace mediante
una aplicación diseñada especialmente para este propósito, y consiste en una pequeña
aplicación que crea ejemplares de las clases de alumno, profesor y materia, les agrega
información a ellos y posteriormente los almacena dentro de la base de datos objeto.
'1
11 . I
I!
1
O cenidet 1999 Página64
. . Traductor PC C.onsultas del hlodclo Relaciona1 al Modelo Orientado a Objetos
6.6. Caso de Prueba
Para efectos de una prueba del traductor de covsultas se toma el siguiente esquema
orientado a objetos como entrada al traductor:
Clase: Persona [OD] O D : Int RFC: String Nonibre: Siring Edad: Inr
Clase: Alunino Hereda de Persona [OID] OID: Int nraierias: Complex Set oJMateria Gnipo: Int
Clase: Materia [OlD] OID: In! Tirulo: String Din: Siring Hora: String
Clase: Oficina [OiD] OID: Int Ed@cio: String Cuarto: inr
Clase: Profesor Hereda de Persona [OID] OID: int Rango: String oficina: Conipler Oficina
Clase: Graduado Hereda de Alunino [C’IDj OID: Int Tesis: Siring Asesor: Complex Profesor
‘I .
O cenidet 1999 PágiiiaóS
/ / Traductor de Consultas.del Modelo Relaciona1 al Modelo Orientado a Objetos
l i
La información que se muestra es el contenido de un archivo.de texto generado por
la herramienta para diseñar esquemas orientados 1 objetos. El archivo de texto mostrado
describe al esquema orientado a objetos que se inuestra en la figura 6.4.1.1. El esquema
muestra seis clases, donde la clase Persona tiene !varios atributos que hereda a las clases
Alumno y Profesor. La clase Profesor contiene un atributo que tiene como dominio a la
clase Oficina. Las clases están relacionadas entre si mediante mecanismos propios del
paradigma orientado a objetos, como son herencia, y especialización. El esquema orientado
a objetos se muestra en la figura 6.6. I .
11
I1
:I
li !I
I ;. . . . ' ,. :.~- ., ~..-.:- . _ , . - . . . . . .
Figura 6.6.1 Carga del esquema orientado a objetos dentro de la herramienta de transformación de '1 esquemas
El esquema orientado -a objetos se procesa por el módulo de transformación de
esquemas y los resultados se muestran en la figura 6.6.2.
O cenidet 1999 Página66
Traductor de Consultas del Modelo Relaciona1 ai Ltodclo Oneniado a O b ~ c i o s I/
objetos a esquema relaciona virtual. 11
I ;
Los resultados obtenidos de la transfohación de esquemas son vanas tablas
virtuales, las cuales indican los atributos que las componen. Los usuarios del sistema /I
pueden hacer consulias con base en 'las tablas vihales . Para efectos de pruebas se hace la
hayan llevado la materia de bases de datos y que'su asesor tenga su oficina en el edificio de
computación y además sea de tiempo completo. Enseguida se muestra la consulta hecha en
SQL:
siguiente consulta, cuyo objetivo es obtener todos It los alumnos que están graduados y que
'I
SELECT Profisor.Non>bre. Wcim.
FROM Pro/esor. @kina, Goduodo. G,aduodo-Mo<pria.MateriB
WHERE Pro/esror. Categorio = T i e n i p completo.
AND P ~ o ~ ~ a ~ . o j i c i ~ a - O / D - O f i ~ i ~ ~ , Oficino-OlB
AND O/icino.Edi/jcio="Conrpoloción"
A,VD P,o/esorProleror-OID=G,ad~,~d~. Profmor-OID
AND Graduado. Groduodo-OID=C~odi~odo.Ma/eno. Groduodo-OID
AND Graduodo-Mof~rio.M~rerio-OiD=M~t~~i~. Morerio-OID
AND Moleria. lhlo="Bnre de Doros"
0 cenidet 1999 Pagina67
Traductor de Coiisultas del Modelo Relaciona1 al Modelo Oneniado a ObJeiOS
La consulta es analizada y procesada por pn analizador léxico y sintáctico que da
como resultado unos grafos: el grafo de predicados relacional y el orientado a objetos que 11
se muestra en la figura 6.6.3.
El gafo de predicados relaciona1 obtenido directamente de la consulta en SQL es
transformado a un grafo de predicados orientado'a objetos, tal como se muestra en la figura
6.6.3 y a partir de ese grafo orientado a objetos se obtiene la consulta en OQL, como se
fiuestra en la figura 6.6.4.
1
11
1;
i I :
O cenidet 1999 Página68
I
Traductor de Consulta? dcl Modelo Rclaciorial al Mdelo Orientado a Objetos
RESULTADOS
Oficina *&Graduado
., .: . .. . . . I i i
Ejecittaij : . ~ . . .
~. .. . Salir
., . . ., . .. . .
l- Fisura 6.6.4 Obtención de la consulta en OQL'ia partir del grafo Orientado a Objetos
!
!I
'!
La consulta que se obtiene finalmente, es validada dentro de POET. Para probar que
esa consulta está correcta, se puede usar la herramienta que proporciona POET denominada
WorkBench, que es una utilena proporcionada que abre una base de datos y permite aplicar
consultas en OQL hacía la base de datos abierta y da como resultado los objetos solicitados
por la consulta. En la figura 6.6.5 se muestra la hplicación y comprobación de la consulta
que se obtuvo en este ejemplo.
0 cenidet 1999
!I Página69
t Traductor de Consultas dyl Modelo Relactonal ai \lodelo Ortentado a Objetos
i
Figura 6.6.5 Resultadoside la Consulta '. 11
LOS resultados que se obtienen de la base de datos orientada a objetos se obtienen t utilizando WorkBench.
0 cenidet 1999. Página70
;i
11 Traduiior de Consuliaj dl1 Modelo Relaciona1 al M d c l o Orientado a Objetos
Conclusiones . . Se mencionan algunas caractensticas del prototiPo obtenido después de realizar el trabajo
de tesis. Además se dan algunas recomendaciones e ideas de trabajos futuros necesarios
para complementar el traductor de consultas y el sistema multibase de datos.
'I I II . il
I 7.1 Conclusiones Generales
Con el trabajo de tesis se permite la integración de bases de datos orientadas a objetos a un
sistema multibase de datos con lenguaje de consultas global SQL, mediante la traducción
de consultas en SQL al lenguaje orientado a objetos OQL utilizando la técnica de Grafos de
Predicados.
¡I (I I/
_ - 7.2. Resultados Obtenidos
I
Uno de los objetivos de la tesis fue llevar a'cabo de manera completa y correcta las
actividades que conducen a la solución del problema de acceso transparente a los datos. El
resultado de la tesis se resume en que ahora es p,osible acceder a bases de datos orientadas a
objetos mediante el uso de un traductor de consultas, que muestra a los usuarios una vista
11
11
O cenidet 1999 Página71
!¡
'1
Traductor de Consultas del Modelo Relaciona1 al Modelo Orientado a Objetos
relacional de los objetos contenidos dentro de la base de datos orientada a objetos, los
módulos obtenidos son:
I1
- Módulo traductor de esquemas: El módulo se encarga de obtener el esquema de la base
de datos orientada a objetos y la traduce a un esquema relacional para que los usuarios
del SMD puedan realizar sus consultas basándose en tablas virtuales equivalentes
I
/I
generadas por el traductor de esquemas.
- Módulo para representar consultas en SQL en grafos de predicados relacionales: El
módulo recibe las consultas en SQL de los us&rios del SMD y las analiza, obteniendo
predicados. Los predicados son las reuniones encontradas dentro de la cláusula WHERE
en la consulta. Los predicados obtenidos de la consulta representan a la relación que
existe entre las tablas involucradas en la reunión mediante una colurnia en común.
II
'I
- Módulo convertidor de grafo relacional a g a f o orientado a objetos: El módulo recibe la
información contenida en el grafo relacional, analiza los nodos y determina las clases y
atributos contenidos, y los introduce dentro de un nuevo grafo, llamado g a f o orientado a
objetos.
I1
r
- Módulo transformador del grafo orientado a objetos a consultas en OQL. En el módulo
se detectan rutas de expresiones contenidas en el g a f o orientado a objetos que forman
subgrafos, las cuales son utilizadas para crear la consulta en OQL.
Los traductores de consultas son parte fundamental en los sistemas multibases de datos, ya
que por cada tipo de base de datos participante, es necesario un traduc!cr de csnsultas que
transfomie las consultas globales al lenguaje de consultas local que utiliza la base de datos
local participante.
1
Los logros obtenidos dentro de esta tesis forman parte de la construcción de un 1
sistema multibase de datos, el cual considera dentro de sus sistemas de bases de datos /I participantes a una base de datos orientada a objetos. 8 1
O cenidet 19% Página72
'I
11 Traductor de Consultas d$l Modelo Relaciona1 ai híodclo Orientado a Objetos
. . .~ .
7.3 Alcances Logrados
Un sistema multibase de datos tiene acceso a diferentes sistemas de información
heterogénea haciendo uso de traductores de consultas. Las operaciones permitidas por el
SMD depende mucho de la complejidad que requiera el sistema. En la tesis el acceso hacia
las bases de datos es solamente para hacer consultas, no considera las operaciones de
borrado, actualización e inserción de datos. Lds mecanismos implantados dentro del
traductor de consultas permiten que los usuarios del SMD puedan acceder a los datos de
una base de datos orientada a objetos mediante ionsultas hechas en SQL. Las consultas
permitidas por el traductor sólo consideran a unisubconjunto del SQL. Las consultas se
formulan contra un esquema relacional, que muestra al usuario la estnJEtura de la base de
datos orientada a objetos en forma de tablas virtua'ies creadas por el mismo traductor.
:i
!I
!I 'I
7.4. Recomendaciones
'1 Para el desarrollo de la tesis se utiliza una técnica de grafos de predicados que toma las
consultas, las analiza y obtiene información. Se utiliza esta técnica encontrada en literatura
de los SMD debido a que la información re$pecto a la interacción entre el modelo
relacional y el modelo orientado a objetos es mub poca. La técnica de grafos de predicados
tiene limitaciones respecto a las operaciones de SQL utilizadas y la implantación del
ttaductor refleja esas limitaciones. Por lo tanto .un punto importante que se recomienda es
tratar de obtener la mayor cantidad de informción'posible, para que de esta manera no
quedar limitado en las operaciones de la herramienta.
8 )
7.5. Trabajos futuros
El traductor de consultas está todavía en una etapa primaria, donde el objetivo es hacer la
traducción básica de consultas hechas en SQL al lenguaje OQL. Los alcances del traductor
Página73
/I
'I i!
Traductor dc Consultas + I Modelo Relaciona1 al Modelo Orientado a Objetos :!
J son realmente corios, ya que por ser de los primeros intentos de implantar un traductor que
incluya a estos lenguajes es limitado. Algunos de los trabajos futuros para este traductor es
ampliar las operaciones de SQL. Por ejemplo hacer que el traductor considere altas,
actualizaciones y borrado de datos.
'1 '1
t
i
!
O cenidet 1999
. .
Página74
Traductor de Consultar del Modelo Rclacional al h4cdclo Ofleiitado a Ohjetos mi
REF.ERENCINS
Won Kim, Modern Database Systems: The Object Model, Interoperability, and Bevoiid, Editorial Addison Wesley.
C.J. Date, Introducción a los Sistenias de Bases de Datos, Volumen I , Sta. Edición, Editorial Addison Wesley.
Luis Joyanes A., C++ A su Alcake: Uti erfo¿pe orieiilado a objetos, Editorial Mc Graw Hill.
Henry F. Korth , et al., Furidamentos de Bases de Datos, Editorial Mc Graw Hill.
1,
8 1
Lucero M. Ayala Lugo, Desarrollo de uti Gateway para un Sistema Multibase de Duros, [Tesis de maestría] Cenidet, Cuemavka Morelos, 1998.
Mario Guillén Rodriguez, Requerimientos de un Sistema Adnrini$rador de Flrgos de Trabajo Traiisacciortal, [Tesis Doctoral en Desarrollo Actualmeiit6] ITESM, Mexico D.F. I
‘I
Hoffman, James: “Introducción al Lenguaje Estructurado de Consultas (SQL)”., http://w3 ,one.net,‘-jhofhadsqltut.htin ‘1
Bany Douglas K., “The True about Object$ Databases”, DATABASE Programming & Design, August 1997, Volumen 10, Numkro 8, Pag. 44-48. http://www.dbpd.com
Francois Bancilhon: “Object, Relational, Object-Relational & Relational-Object.”, htt~://www.sies.com/publications/docs/oc/9604/oc9604.c,bancilhon.ht~nl
I1 [IO] Yu, Clement, et. al., “Translation of 0bject;Oriented Queries to Relational Queries”E
Proceedings o/ the Eleventh Interna~ional~i Cortfereri:e on Data Engineeririg, March 6-10, 1995, Taipei, Taiwan
[ I I ] Poet Software Inc., Archivo de Guía de Programación del OODBMS POET 5.0, <
httD:í/wivw.ooet.com, 1998 ’:
[I21 Lee Juhnyoung, David Forslund, “Coexistence of Relations and Objects in Distributed Object Computing: Multidatabase Systems (through Middleware and Connectivity Tools)”, First ‘ Posted: 1 June, 1995 Iitt~://www.acl.lanl.eov/sunrise/dbms/indeX.html
[ 121 “Página Oficial de Java SUN Microsystem”. http://Java.sun.com, 1998
I1
O cenidet 1999 Página75
Traductor de Consultas del Modelo Relacional al Mdelo Orientado a Obictos
“Página Oficial de ODMG” Iittv://\w~ww.odtn~.org 1993-99
I “Página Oficial de Oracle” h&://www.oracle.com I999
“Página Oficial de Sybase” Iittp://www.svhase.com 1999
“Página Oficial de Informix” httv://ww.inforniix.com 1999
“Página Oficial de microsoft” httv://www.iii icrosoñ .corn 1999
“Página Oficial de Compac-Digital” http://w~\,w.dieital.coin 1999
[ 191 “Página Oficial de Object Store” httv://www.odi.com ‘I
1999
. .
“Página Oficial de Gemstone” httu://www.oenxtone.com ’!
1999 ‘I
Korth Heiuy F., eta!., Mirliidaiabase, Editbnal Mc Graw Hill. 1995
“Página Oficial de JavaCC” I1
- htt~://www.rnetainata.codJavacc I999 , ,
’!
9 9 - 0 6 5 2 O cenidet i s 9
a Pagina76
Top Related