tecnol~gi$o · 2014-02-13 · 'i lists de figuras .. figura: 2.2.1 esquema de un sistema...

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

mailto:[email protected]

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


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


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


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/


!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;


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


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


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


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


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


'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


‘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


!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


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).


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

-


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


. . -. ~

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:


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


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


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


¡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


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"

. .


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.


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.


http://archivo.de

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 :


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


!¡

'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


http://w3

http://www.dbpd.com

http://httD:/wivw.ooet.com

http://Java.sun.com

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

http://h&://www.oracle.com

http://Iittp://www.svhase.com

http://httv://ww.inforniix.com

http://httv://www.odi.com

http://httu://www.oenxtone.com

tecnol~gi$o · 2014-02-13 · 'i lists de figuras .. figura: 2.2.1 esquema de un sistema...

Documents