Embed Size (px)
Citation preview
S.E.P. S.E.I.T. D.G.I.T.
CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOLÓGICO.
cenidet
"INTECRACIÓN DE ESQUEMAS PARA MULTIBASE DE DATOS DISTRIBUIDAS HETEROGÉNEAS~~
T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN CIENCIAS COMPUTACIONALES P R E S E N T A : LUCERO MARíA AYALA LUG0
DIRECTOR DE TESIS: DR. JOSÉ TORRES JIMÉNEZ
Cuernavaca, Morelos. Enero 1999.
~ 9 s - o o a s
DEDICA TORTA
Primeramente a Dios porque siempre se encuentra
presente en cada paso que doy.
A mis padres porque todo lo que soy
se io debo a ellos, gracias.
Felipa Lug0 Y
Octavio Ayala
A mis hermanos por demostrarme en todo momento su apoyo y amor que nos ha unido siempre.
Carolina Y
Octavio
Por t u amor, paciencia y confianza
que me motiva cada día a ser mejor, gracias mi amor.
Elías
i
AGRADEZCO
Especialmente al Dr. José Torres Jiménez por su apoyo y confianza en el desarrollo de este trabajo de tesis.
A todos mis compañeros de generación.
AI comité de revisión por sus comentarios, críticas y su valiosa cooperación en la revisión de este trabajo, al Dr. Rodolfo Pazos Rangel, al M.C. Mario Guillen Rodríguez y al M.C. Ed¡ Ray Zavaleta Olea.
A mis maestros, a quienes debo mi formación académica.
A todos aquellos que con sus comentarios y críticas me ayudaron a mejorar este trabajo, en especial a Margarita Martínez Leal.
AI M.C. Felipe Alaniz, al Ing. Nadira Rodriguez Damian, al Ing. Juan Carlos Alarcón Rocha y al Ing. Rodolfo Castillo Romero por su amistad e invaluable tiempo que me brindaron.
A todo el personal administrativo y del área de computación de este centro.
AI Centro Nacional de Investigación y Desarrollo Tecnológico, CENIDET y al Consejo Nacional de Ciencia y Tecnología, CONACYT por su apoyo económico.
GRACIAS POR SU APOYO
ii
SISTEMA NACIONAL DE INSTITUTOS TECNOLÓGICOS
Centro Nacional de Investigación y Desarrollo Tecnológico FORMA A3
REVISION DE TESIS
U D SPI’ REV 12/97
Cuernavaca, Morelos a 19 de enero de 1999
M.C. Máximo López Sánchez Presidente de la Academia de Ciencias Computacionales Presente
Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: “INTEGRACION DE ESQUEMAS PARA MULTIBASE DE DATOS DISTRIBUIDAS HETEROGÉNEAS”, realizada por el C. Lucero María Ayala Lugo, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.
Sin otro particular, quedamos de usted.
Atentamente La comisión de revisión de tesis
A. GU.\L-C M.C. Mario Guillen Rodríguez
Asesor de tesis
ccp Dr. Javier Ortiz HernándedJefe del Departamento de Ciencias Co
. . aep. . NACIONAL DE MVESTIGAGI~WC
GUBDIFECCIÓN A C A D ~ I C A Y DESARñOLLO TECNOL&IW
Institutos Tecnológicos 50 años de educación superior tecnológica en México
APARTADO POSTAL 5164 CP62051. CUERNAVACA. MOR MCXICO. TELS (7312 2314.12 7613, FAX (73) 12 2434 - EMAIL cenldetl@infosel net mX
SISTEMA NACIONAL DE INSTITUTOS TECNOLbGICOS
Centro Nacional de investigación y Desarrollo Tecnológico FORMA A4
AUTORJZACION DE IM PRESIÓN DE TESIS REV 12/97
Cuernavaca, Morelos a 19 de enero de 1999
C. Lucero Maria Ayala Lug0 Candidato al grado de Maestro en Ciencias En Ciencias Computacionales Present e
Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: “INTEGRACIÓN DE ESQUEMAS PARA MULTIBASE DE DATOS DlSTRiüUlDAS HETEROGÉNEAS”, me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.
At en t ame
Ortiz Hernández de Ciencias Computacionales
Institutos Tecnológicos 50 años de educación superior tecnológica en México
APARTADOPOCTAL 5-164, CF‘62051. CUEFNAVACA, MOR. M&ICO-TnC. (73)12 2314.12 7 6 1 3 , FAX (73) 12 2434 -EMAIL: osnidel i ~ i n l o s d . n s l . m
Contenido
Lista de Figuras viii
Lista de Tablas X
I INTRODUCCI~N 1
1.1 Clasificación de los sistemas de hases de datos . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Sistema de base de datos centralizada . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Sistemas de basa de datos distribuidas . . . . . . . . . . . . . . . . . . . . 4
1.1.2.1. Sistemas de hases de datos distribuidas homogéneas . . . . . . . . 6
1.1.2.2. Sistemas de hases de datos distribuidas heterogéneas . . . . . . . 6
6
1.3 Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
. 1.2 Objetivo de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Organización por capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 MARCO T E ~ R I C O
2.1 Sistemas multihase de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Esquema global en multibase de datos . . . . . . . . . . . . . . . . . . . . .
2.1.2 Basa de datos federadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Sistema de lenguaje multihase de datos . . . . . . . . . . . . . . . . . . . .
2.1.4 Sistema de lenguaje multihases de datos homogéneas . . . . . . . . . . . . .
2.1.5 Sistemas interoperables . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Areas de invatigaciún en sistemas muli. ihase de datos . . . . . . . . . . . . . . . .
2.3.1 Integración de esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
10
11
12
13
13
14
14
15
31
32
2.3.2 Optimización de consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
33
34
35
35
35
2.3.3 Manejo de transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 A4ultibases de datos orientadas a objetos . . . . . . . . . . . . . . . . . . . .
2.4 Dimensiones de la integración de bases de datos. . . . . . . . . . . . . . . . . . . .
2.4.1 Integración del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Integracióii semántica p del esquema . . . . . . . . . . . . . . . . . . . . . .
3 PLANTEAMIENTO Y ANALISIS DEL PROBLEMA 39
3.1 Planteamiento general del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Definición de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
42
3.3.1 Selección de herramientas de Software . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 Platafornia de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4 Análisis de solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 DEFINICIdN DEL ESQUEMA GLOBAL 49
4.1 Lenguaje de definición de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Gramática del lenguaje de definición de datos . . . . . . . . . . . . . . . . . . . . .
49
50
4.2.1 Información de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Información de enlace con las bases de datos locales 53
4.3 Generación del diccionario de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 54
. . . . . . . . . . . . .
5 Definición de operaciones globaies 57
5.1 Lenguaje de inanipulación de datos . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Gramática del lenguaje de manipulación de datos . . . . . . . . . . . . . . . . . . .
5.3 Generación de código de transacciones locales . . . . . . . . . . . . . . . . . . . . .
57
58
59
iv
5.3.1 Código para la operación SELECT . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.2 Código para la operación INSERT . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.3 Código para la operación DELETE . . . . . . . . . . . . . . . . . . . . . . . 65
5.3.4 Código para la operación UPDATE . . . . . . . . . . . . . . . . . . . . . 69
6 CONEXI6N Y EJECUCI6N DE OPERACIONES EN LAS BASES DE
DATOS LOCALES 75
6.1 Definición de JDBC .. (2 6.2 Ejecución de operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2.1 Ejecución de la operación SELECT . . . . . . . . . . . . . . . . . . . . . . . 85
6.2.2 Ejecución de la operación INSERT . . . . . . . . . . . . . . . . . . . . . . . 87
6.2.3 Ejecución de la operación DELETE . . . . . . . . . . . . . . . . . . . . . . 88
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4 Ejecución de la operación UPDATE . . . . . . . . . . . . . . . . . . . . . . 91
7 INTERFAZ CON EL USUARIO GLOBAL 95
7.1 Editor niultibase de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
98
99
99
7.2 Ejecución del DDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Ejecución del DML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
/ .4 Visualizador de multibase de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . - 8 PRUEBAS 103
8.1 Objetivo de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.2 Descripción del ambiente de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.2.1 Esquema de la base de datos de prueba . . . . . . . . . . . ; . . . . . . . . 106
8 .2 .2 Contenido inicial de Is basa de datos locales de prueba . . . . . . . . . . . 109
8.3 Casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
v
9 CONCLUSIONES 125
9.1 Conclusiones generales , . . , , , , . . . . , , , . . . . . , . . . . . . . . . . . . . . 125
9.2 Resultados obtenidos , , , , , . , , , , , . . , , , , , , . . , , , , . . . . . , , . . . 126
9.3 Alcances logrados , , , , . . . . , , , , . . . . , , . , . . , , , , , . . . . , , , . . . 128
9.4 Recomendaciones . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.5 Trabajos fut,iiros . , , , . . , , , , . . . . , , . , , . . . . , , . . . . . . , . . . . . 130
I ApéndiceA
Archivas para definir hases de datos globales
131
. 132
I1 Apéndice B 137
Archivos generados por los casos de prueba . . . . . . . . . . . . . . . . . . . . . , . . 138
I11 Apéndice C 146
Pseudocódigos para la generación y ejecución de la operaciones globales (SELECT,
INSERT, DELETE y UPDATE). . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
vi
Lista de Figuras
1.1 Esquema simplificado de un sistema de base de datos . . . . . . . . . . . . . . . .
1.2 Esquema de un sistema de bases de datos centralizadas . . . . . . . . . . . . . . .
1.3 Esquema de un sistema de base de datos distribuidas . . . . . . . . . . . . . . . .
2
4
5
3.1 Esquema del ambiente del planteamiento del problema . . . . . . . . . . . . . . . 41
3.2 Esquema a bloques de los módulos de nuestro sistema multibase de datos . . . . 48
4.1 Esquema de los archivos que se crean al definir el diccionario de datos . . . . . . 56
5.1
5.2
5.3
Dirección de la generación de código tipo 1 . . . . . . . . . . . . . . . . . . . . . .
Dirección de la generación de código tipo 2 para una operación SELECT global .
Dirección de la generación de código tipo 2 para una operación DELETE o Up-
60
61
DATE con incompatibilidad de tipos en la cláusula WHERE . . . . . . . . . . . . 61
6.1 Esquema del niodelo de acceso 2-capas . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Esquema del niodelo de acceso 3-capas . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3 Esquema de t. rabajo de JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1 Interfaz del ambiente multibase de datos . . . . . . . . . . . . . . . . . . . . . . . 96
7.2 Selección de accione de la opción File . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3 Selcción de acciones de la opción Edit. . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.4 Ejecución del DDL del ambiente multibase de datos sobre un archivo bien definido . 98
7.5 Ejecución del DML con un archivo que contiene 3 transacciones sobre nna base
de datos global. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.6 Ejecución de la opción VisualMBD donde se introduce el nombre de la base de
datos global a visualizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
vii
7.7
7.8
Se muestra el esquema de la base de datos en forma de árbol.
En esta figura se puede apreciar el contenido de la tabla global TABLA1, la cual
extrae información de las tablas locales pertenecientes una a SQL Server y otra
a mSQL. . . . . . . . , , , , , , , . . . . . , , , , . , , . , . . . , , , , . , . , . . 102
, . . . . . . . . . 101
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
Esquema de la base de datos global basesem. , . . . . . . . . . . . . ,. . . . . . . 106
Esquema de la base de datos definida en el SMBD de SQL Server. . . . . . . . . 107
Esquema de base de datos definida en el SMBD de Oracle. . . . . . . . . . . . . . 108
Esquema definido para la base de datos del SMBD mSQL. . . . . . . . . . . . . . 108
En esta prueba se muestra el contenido de la tabla carreras. . . . . . . . . . . . 118
Muestra la ejecución de la transacción SELECT sobre las tablas globales materias
y planes. . . . . . . . . . . . . . . . . , . . . . . . . . . . . . . . . . . . . . . . . . 119
Muestra la ejecución de las transaccioes UPDATE y SELECT esta última para
verificar si ejecutó correctamente la niodificacióri del UPDATE.
Muestra la ejecución de las transacciones UPDATE, INSERT y SELECT esta ú1-
t ima para verificar si ejecutó correctamente la modificación hecha por el UPDATE
y la insercción hecha por el INSERT.
Muestra la ejecución de las transacciones DELETE y SELECT esta última para
verificar si ejecutó correctamente el borrado realizado por la operación DELETE. 123
. . . . . . . . . 120
. . . . . . . . . . . . . . . . . . . . . . . . 122
viii
Lista de Tablas
2.1
2.2
Clasificación de proyectos multibase de datos con esquema global . . . . . . . . . .
Continuación de la clasificación de proyectos multibase de datos con =quema
global. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Clasificación de proyktos multibase de datos con basa de datos federadas . . . . 18
Clasificación de proyectos multibase de datos con lenguaje multibase de datos . . 19
Clasificación de proyectos multibase de datos con lenguaje multibases de datos
homogéneas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16
2.3
2.4
2.5
8.1 Tabla profesional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.2 Tabla reticula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.3 Tablaestudiaiites . . . . . . : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.4 Tabla carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.5 Tabla catedratico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.6 Tablaclase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Tablagrupm 111
8.8 Tabla licenciatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.9 Tabla convenio 112
8.10 Tabla pupilos 112
8.11 Tabla asigiiat. ura 113
8.12 Tabla maestros 113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.13 Tabla clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.14 Tabla aula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.15 Tabla area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.16 Tabla licenciatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ix
8.17 Tabla ingreso . . . . . . . . . . . . . . . . . . . . . . 1 . . . . . . . . . . . . . . . 115
8.18 Tabla materia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.19 Tabla empleado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.20 Tabla seminario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.21 Tabla sala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
X
Capítulo 1
Los rápidos avances en la tecnología de las redes y en la comunicacióii han cambiado dramáti-
camente la forma de procesar los datos. Hoy en día muchos nsuarios están interesados en la
integración y coiisolidacióu de sus fuentes de datos flsicamente dispersos. Por consiguiente, para
poder obtener los datos a través de la red de compiitadoras se necesii,a un sistema manejador a un
nivel superior sobre los sistemas de bases de datos locales. Tales sistemas son llamados sistemas
manejadores de bases de datos distribuidas heterogéiieas o sistemas miiltibase de datos[l].
Este problema de integración es el tema central del trabajo de tesis. En el desarrollo de
los capítiilos se discuten las soluciones que se han propuesto y se plani,ean los métodos que se
eligieron para diseñar, desarrollar e implementar el sistema multibase de datos con que concliiye
esta investigación.
En este capítulo se presentan la clasificación de los sistemas de bases de datos; el objetivo
de la tesis; se muestran los beneficios que se espera obtener con el desarrollo del presente trabajo
y se describe a grandes rasgos como está organizada la tesis.
1.1 Clasificación de los sistemas de bases de datos
Un sistema de base de datos (SBD) se compone de un software denominado sistema mane-
jador de base de datos (SMBD) y de un conjunto de datos que constituye la base de datos
(BD), los usuarios consultaii los datos mediante algún lenguaje de consiilta(Query Languaje)
proporcionado por el SMBD. Adicionalmente un esquema describe la organización y estructura
de datos reales dentro del sistema [2].
1
Los SBD han adquirido una gran popularidad para el desarrollo de sistemas de información
y actualmente constituyen tecnología madura disponible.
Entre la base de datos física (los datos, tal como se encuentran almacenados) y los usuarios
del sistema existe un nivel de programas, el sistema manejador de la base de datos (SMBD).
El SMBD es una pieza de software que proporciona las facilidades necesarias para definir y
manipular la base de datos. Para la función de definición de los datos proporciona el lenguaje
de definición de datos (DDL) y para la función de manipulación de los datos utiliza el lenguaje
de manipulación de datos (DML). Uii esquema que representa la organización y estructura de
los datos en un sistema de base de datos se puede apreciar en la figura 1.1.
Figura 1.1: Esquema siniplificado de un sistema de base de datos
Inicialineiite con el avance en la comunicación en los equipos de cómputo, primero fueron
diseñados los sistemas de bases de datos centralizadas, donde las bases de datos se encontraban
ubicadas en un solo sitio. Cuando surgieron las redes de cómputo, donde física y operativaniente
se había logrado una comunicación esto presion6 un avance en los sistemas de bases de datos,
éstos fueron los sistemas de bases de datos distribuidos.
2
1.1.1 Sistema de base de datos centralizada
Una de las motivaciones principales detrás de los sistemas de base de datos, es la de integrar
los datas operacionales de una empresa y suministrar un acceso controlado y centralizado a
estos datos. Las sistemas de base de datas centralizada ( SBDC ) en la década de los S O s ,
suministraron este control centralizado, debido a esto diferentes sistemas manejadores de bases
de datos comerciales fueron utilizados ampliamente[3].
Los primeros SBDC tenían que contar con equipo de cúmputo que fuera poderoso y veloz
en su procesamient,o para almacenar en él las bases de datos y el sistema manejador, es aquí
donde nada m& existe un solo usuario en el sistema; después cuando se pudo conectar otras
máquinas de acceso, pero sólo como terminales tontas, a esta máquina central se pudo aumentar
el número de usuarios al sistema, pero el control y el procesamiento de la información seguía
siendo trabajo de una sola máquina.
Un SBDC por tener las bases de datos almacenadas en un solo sitio en la red de computa-
doras, ocasiona una sobre saturación de tráfico al momento de las peticiones de consultas hechas
por los clientes de los programas de aplicación, que se encuentran utilizando la información de
las bases de datos. Se podrá comprender mejor la arquitectura de como trabaja un SBDC en la
figura 1.2.
Todo el procesamiento de ejecución de las peticiones se hace en el sitio donde se encuentran
las bases de datos, de esta nlauera se obtiene un sistema lento. Los usuarios del sistema s610
eniitirían peticiones en su computadora de la red y recibirían la respuesta por parte del sistema
manejador de base de datos, dejando toda la carga de trabajo n la unidad de procesamiento
donde se encuentra la información, desperdiciando el hecho del poder compartir el trabajo entre
todas las unidades de procesamiento que pertcnwen a la red.
3
SMBD
Base de datos
Figura 1.2: Esquema de un sistema de bases de datos centralizadas.
1.1.2. Sistemas de bases de datos distribuidas
Las bases de datos distribuidas (BDD) es una colección de datos distribuidos sobre las
diferentes computadora de una red. Cada sitio de la red tiene capacidad de procesamiento
autónomo y puede realizar aplicaciones locales. Cada sitio taiiibién participa en la ejecución de
al menos, una aplicación global, la cual requiere consultar datos de varios sitios por medio de
u11 subsistema de comunicaciones[4].
La definición de un sistema de base de datos distribuidas (SBDD): es aquel que se coiiipone
de un conjunto de sitios, conectados entre si mediante algún tipo de red de coinunicacioiies
eii el cual: a) cada sitio es un sistema de base de datos en sí niismo, pero I,) los sitios han
convenido eii trabajar juntos ( si es necesario ) con el fin de que un usuario de cualquier sitio
pueda obtener acceso a los datos de cualquier puiito de la red tal como si los propios datos
estuvieran almacenados eri el sitio donde se enciientra el usuario[5).
E n consecuencia, la llamada “base de datos distribuida” es en realidad una especie de objeto
4
virtual, cuyas partes componentes se almacenan flsicamente en varias bases de datos reales. En
la figura 1.3 puede verse un ejemplo.
Figura 1.3: Esquema de un sistema de bases de datos distribuidas.
Adviértase que, como se dijo, cada siti8 es un sistema de bases de datos que pasee derecho
propio, En otras palabras, cada sitio tiene sus propias bass de datos reales locales, sus prm
pios usuarios locales, sus propios SMBD y programas para la administración de transacciones
(incluyendo sus propios programas de bloqueo, bitAcoras, reciiperación etc.), y su propio ad-
ministrador local de comunicaciún de datos. El sistema de bases de datas distribuidas puede
considerarse como una especie de sociedad entre los sistemas manejadorcs de base de datos
individuales locales de todos lm sitios[5].
Debido a esto surgieron dentro de los SRDD dos clasificaciones important,es: los sistemas de
bases de datos distribuidas homogéneas (SBDDHo's) y los sistemas de bases de datos distribuidas
heterogénea (SBDDHe's)[2].
5
1.1.2.1. Sistemas de bases de datos distribuidas homogéneas
Un sistema de bases de datos distribuidas homogéneas se compone de una sola base de datos
lógica, la cual está distribuida fisicamente (BDD) en los diferentes sitios componeiites, y de un
sistema manejador de bases de datos distribuidas que proporciona consultas y actualizaciones
consistentes. Es importante señalar que todos los sistemas nianejadores de bases de datos
distribuidas componentes (residentes en los diferentes sitios) son iguales: poseen un mismo
modelo de datos y iin lenguaje de interrogación específico[6].
1.1.2.2. Sistemas de bases de datos distribuidas heterogéneas
Los sistemas de bases de datos distribuidas heterogéneas, son aquellos en los que sus com-
ponentes físicos corren bajo diferentes sistemas manejadores de bases de datos, su información
puede estar administrada bajo diferentes modelos de datos y lenguajes de consultas, y además
pueden existir diferentes esquemas para el almacenamiento de la información, aun dentro de
estos esquemas podrá haber heterogeneidades sintácticas (diferentes nombres para la misma
entidad, diferentes entidades con el mismo nombre, diferentes tipos de datos, etc.)[’i].
En los SBDDHe’s surgió la necesidad de conjuntar la información que están manejando para
una aplicación global, esto originó la necesidad de integrar todo sin importar las diferencias antes
mencionadas y es así como surge el concepto de multibase de datos.
1.2 Objetivo de la tesis
El objetivo general de este trabajo es diseñar e implementar un sistema de integración de
inforinación en un esquema lógico global de bases dedatos pertenecientes a sistenias inanejadores
de bases de datos distribuidas heterogéneas.
El producto que se obtiene con est,e trabajo de tesis es un programa maestro, que cuenta
con procedimientos de software que operan en conjunto para ofrecer un esquema de integración
de bases de datos distribuidas heterogéneas, perniitiendo a nn usuario global acceder a la infor-
6
mación de manera transparente,
1.3 Beneficios
Las grandes organizaciones tienen acceso a datos y recursos de software que la
interconexión previa de sistemas y aplicaciones aisladas. EI usuario final, en un ambiente de
computación heterogénea, podría ser capaz no únicamente de invocar de aplicación,
sino taiiibiéii de coordinar su interacción y asociación.
Hoy en día, en el niundo de la coniputación, las .ha?= de datos se proponen como una
solución al problema de acceso compartido de recursos heterogéneos. De aquí que podremos
obtener beneficios tales como[i]:
* Tlansparencia de compartir información: esta transparencia será otorgada tanto al usuario
global, como al sistema local, esto se puede lograr de la siguient,e manera: cuando el usuario
global realice una solicitud de información no requerirá de conociiniento previo de cómo el
sistema global realizará las subconsultas a los sistemas locales. De igual forina el sistema local
recibirá la solicitud de información, y la atenderá como si fuera una transacción local
* Fácil desarrollo de aplicaciones: al tener la información integrada en un esquema global
se podrán desarrollar diferentes aplicaciones, utilizando toda la información que contienen los
difereutes sistemas de bases de datos preexistentes.
* Expansión en la evolución del sistema: si se pueden integrar al nienos dos esquenias de
bases de datos heterogéneas, entonces deberían ser aplicables para n.
* La creación de un sistenia de multibase de datos distribuidas: independientemente de
que los sistemas locales estén administrando información para aplicaciones con fines distintaas,
esta información puede ser utilizada y administrada t ambih para una aplicación global que no
qiiehrant,e la consistencia requerida por el sistema local.
* El esquema global es lógico: la información es traducida a un esquema de integración
común, sin necesidad de crear nuevas bases de datos ni, mucho menos, duplicar esta información
i
en los dispositivos de almacenamiento.
Estos beneficios serán palpados siempre y cuando se haya logrado como primera fase la
integración de información de los sistemas de base de datos existentes. La integración de la
información es el principal interés de este proyecto.
1.4 Organizaciún por capítulos
El material que se presenta en esta tesis se encuentra organizado de la manera siguiente:
En el capítulo 2 se introducen los conceptos sobre multibase de datos, y se exponen los
métodos que se han propuesto para lograr un ambiente integrado. También se presentan las
áreas de investigación dentro de multibase de datos y las dimensiones en que se estudia la
integración de bases de datos.
El capítulo 3 tiene como propósito describir la problemática relacionada con esta tesis,
describe las herramientas y plataforma de desarrollo, también se realiza un análisis de la solución
y se propone la arquitectura del sistema.
En el capítulo 4 se describe cómo se construye el esquema global, se expone el lenguaje de
definición de datos global, su gramática y cómo generar el diccionario de datos.
El capítulo 5 describe el lenguaje de manipulación de datos, su gramática y la generación
de código para las transacciones locales.
El capitulo 6 tiene como objetivo mostrar cómo se realiza la conexión y ejecución de las
operaciones SELECT, INSERT, DELETE y UPDATE en las ba- de datos locales.
El capítulo 7 describe cómo interactuar con las funciones de la interfaz del usuario global
las cuales son: el editor inultibase de datos, visualizador de iiiultibase de datos, así como la
ejecución del DDL y DML del sistema multibase de datos.
En el capitulo 8 se muestran las pruebas efectuadas al sistema inultibase de datos, con lo
que se demuestra la integración de la información de las bases de datos locales heterogéneas.
En el capítulo 9 encontramos lw conclusiones obtenidas, algunas recomendaciones y los
8
posibles trabajos futuros que tomen como base este proyecto.
Por últinio: se anexa un apéndice A que contiene los archivos de informaciún que se utilizaron
para realizar las definiciones de las bases de datos globales y un apéndice B que contiene los
archivos que se utilizaron para realizar los casos de prueba.
9
Capítulo 2
MARCO TEÓRICO
Se ha expuesto que existe una probleniática en los sistemas de bases de datos distribuidos
Iieterogéneos, no puede existir un usiiario que envíe peticiones de consultas que englobe la
información de los sistemas de bases de datos locales, ya que se encontraría trabajando con
diferentes lenguajes que se comunican a múltipleU fuentes de información, en diferentes sistemas
operativos, en plataformas distintas, etc.
Es por esta necesidad palpable que surge una nueva línea de investigación dentro del área de
bases de datos distribuidas que ayudará a tener acceso a toda esta información, integrándola y
mostrándosela a un usuario global. .' Los sistemas multibase de datos proveen integridad y acceso
global a sitios autónomos en bases de datos heterogéneas de una manera sencilla, relativamente
una simple petición de consulta " [SI.
La integración de esta información requiere que semánticamente sea similar, aunque se
encuentre en diferentes nodos y con diferente representación de los datos. Los sistenias multibase
de datos siempre integran información preexistente, en un ambiente de bases de datos locales
distribuidas heterogéneas y presentan a los usuarios globales de modo transparente métodos para
usar I s información total de los sistemas locales. Una característica clave es retener la autonomía
individual de las bases de datos locales, sin alterar la consistencia de la información[g].
Los diseñadores de multihase de datos tienen definidos varios métodos para la integración
de información semánticamente igual pero sintádicamente diferente. Sin embargo, todos estos
métodos suponen que los diseñadores de bases de datos o los mismos usuarios pueden identificar
10
datos semánticamente iguales pese a las diferencias en su representación y nombrado[lO].
2.1 Sistemas multibase de datos
Un sistema multibase de datos, como ya se Iia dicho anteriormente, es aquél que nos brinda
la posibilidad de integrar información de bases de datos preexistent- las cuales cuentan con
sistemas manejadores diferentes, de la misma manera, se puede suponer que se encuentren
organizadas con diferentes modelos de datos y lenguajes de consulta, además piicdeii existir
diferencias sintácticas en los esquemas de datos, debido a que la inforniación que se integra en un
sistema multibase de datos debe tener la característica de que semánticamente a t é representando
la misma información.
Las bases de datos ya se encuentran en primera instancia creadas y administradas en un
sistema que denominaremos sistema manejador de bases de datos local (SMBDL), al crear
una aplicaciún de un sistema multibase de datos que necesita tener acceso a la información
administrada por los SMBDL es necesario tomar en cuenta que las operaciones efectuadas por el
sistema multibase de datos deben respetar la autonomía de los sistemas manejadores locales[ll].
El principal objetivo en un sisteiiia multibase de datos es el de lograr la integración de
la infornrnción pese a todas las diferencias que pudiesen existir desde el aspecto físico (equipo
de cómputo) al aspecto lógico (administración y representación de la información en las bases
de datos). Los diseñadores de sistemas multibase de datos para lograr esta integración han
propuesto los siguientes métodos(lZ]:
Esquema global en multibase de datos.
B ~ e s de datos federadas
Sistema de lenguaje multibase de datos.
Sistema de lenguaje multibase de datos homogéneas
Sistemas interoperable.
11
:2.1.1 Esquema global en multibase de datos
un esquema global en una multihase de datos proporciona una capa concePtual que -
representa una vista integrada de todos los datos disponibles de los sistema manejadore locales
para el sistema multibase de datos. Aunque las partes del diseño y creación del esquema son
un proceso que puede estar automatizado, pero lejos de lograrlo, en general estamos tratando
con una tarea que comprende una labor intensiva. Un componente clave del diseño es el de
identificar manualmente las entidades sem8nticameiite iguales. Las entidades iguales no pueden
ser añadidas o generalizadas hasta que son identificadas, y esta identificación puede requerir
un gran conocimiento de los disefios de las bases de datos locales y de las diferencias entre los
datos, como puede ser en su forma de representación, valor y nonibre. Los esquemas globales son
difíciles de crear y mantener, porque se necesita una @an cantidad de conocimiento e información
en cada nodo para identificar a los datos (los diseñadores deberán estar familiarizados con
todos los diseños de las bases de datos locales) y esto podría representar un grave problema de
almacenamiento en los nodos con recursos limitados.
, . . , . i
La estructura del esquema que pertenece al sistema multibase de datos se forma por cada
sistema manejador de bases de datos local que comparte la información de sus esquemas al
sistema global. En cada esquema local, se utiliza una vista que contiene la información del
sistema local que se desea compartir. La vista de cada esquema local es definida en términos del
modelo de datos del sistema manejador de bases de datos local, y su vía de a-O es por medio
del lenguaje de consulta local. El sistema multibase de datos mantiene una capacidad de mapeo
a cada nodo (del esquema global a un esquema equivalente representado por la información de
la vista). El esquema global representa una combinación de la información de t,odas las vistas
creadas en la definición de los esquema locales, sin embargo, este mapeo de información no
podría ser una simple unión. La información contenida en las diferentes bases de dat.os podría
coincidir en parte, esto es, un mismo objeto del mundo real podría ser representado varias veces
con diferentes representaciones de bases de datos. El mapeo desde las vistas locale al esquema
12
global debería resolver estas diferencias, dado que cada entidad del muiido real y cada uno de los
enlaces de las eiitidades modeladas en cualquier lado del sistema tiene una única representación
a nivel global. Además de las vistas locales existe un esquema auxiliar que contiene información
adicional necesaria para las funciones globales.
2.1.2 Bases de datos federadas
Las bases de datos federadas no constan de un solo esquema global, cada sistema local
mantiene una iiiiportación-exportación del esquema local. El esquema exportado es una -
descripción de la información de los nodus locales que forman parte del sistema global. El
esquema importado es una descripción de la información (de la representación y el origen de los
datos) de nodos remotos para poder ser direccionados localmente por parte del usuario global.
Cada esquema iniportado forma un esquema global parcial. De esta forma cada nodo coopera
únicanient,e w n los usuarios globales donde su esquema exportado pertenece al nodo donde se
encuentra el usuario global. Las consultas de los usuarios son restringidas únicamente a los
datos locales y a la representación de los datos que tengan en el esquema de importación local
1121.
Por lo tanto una base de datos federada sólo facilita un diccionario de acceso en cada nodo
local, donde la aplicación global toma esa información para mostrarla al usuario global en un
esquema de importación. Pero esto no implica la identificación de información semánticamente
igual, sólo brinda identificadores de acceso a la información que se desea compartir de esa base
de datos, sin saber si se puede integrar con la información de otras bases de datos, o para qué
aplicaciones globales se van a utilizar.
2.1.3 Sistema de lenguaje multibase de datos
El sistema global soporta todas las funcione de una base de datos global porque provee
una herramienta que es un lenguaje de consulta para integrar la información desde bases de
13
datos separadas. Las consultas del usuario pueden especificar los datos de los esquemas locales
de algún nodo que participa en el sistema. El lenguaje incluye un espacio para el nombre global
y una función principal que mapea la información de diferentes modelos y representaciones a un
modelo significativo para el usuario [13].
Con este tipo de método de integración, en cada transacción a realizar el usuario global no
debe pasar por alto el cómo identificar y direccionar la información de los diferentes sitios, por
lo tanto la forma de trabajo no es transparente. Aunque existe un diccionario global, el usuario
global al momento de consultar debe saber cuántas bases locales participan, para que la función
que mapea la información emita las subconsultas a los sistemas manejadores de bases de datos
locales.
2.1.4 Sistema de lenguaje multibases de datos homogéneas
Los sistemas de lenguaje multibases de datos homogéneas son una degeneración de los
sistemas multibase de datos. Este subconjunto de sistemas es una clase propia porque son
proyectos de multibase de datos que sólo soportan sistemas manejadores de bases de datos locales
homogéneas, estos sistemas se desarrollan para SMBD comerciales. Los productos comerciales
tienden a tener liniitaciones en las funciones de los lenguajes si se comparan con los proyectos
de investigación, por la facilidad de trabajar en un ambiente donde las diferencias a eliminar
son mímimas IS].
2.1.5 Sistemas interoperables
Las funciones globales son limitadas, es un simple intercambio de datos y no soporta todavía
las funciones de las base5 de datos. Se definen protocolos estándar para la comunicación entre
los nodos, porque el sistema global no está orientado a una base de datos, los sistemas locales
pueden incluir diferentes tipos de información, tales como sistemas expertos, archivos de texto o
sistemas de bases de datos de conocimiento. Los sistemas interoperables se encuentran todavía
14
-.
en estado de investigación [12]
2.2 Estado del arte
Existe un estudio hecho en 181 sobre soluciones y prototipos propuestos p a a inulti-
base de datos que comprende desde la década de los 80’s hasta principios de los 90’~. Esta
clasifica los Prototipos según el método que se haya implementado para la integración (esquenia
global en las tablas 2.1 y 2.2, bases de datos federadas en la tabla 2.3, lenguaje multibase de
datos en la tabla 2.4 y lenguaje multibase de datos homogéneos en la tabla 2.5 ) en diferentes
tablas calificando los siguientes puntos: su estado de desarrollo, el modelo de datos global, si
permite ejecutar transacciones de modificaciones globales y si aporta alguna característica clave
que distinga al sistema.
Después de esta clasificación falta por mencionar las publicaciones correspondientes de los
aíios 90’s hasta la fecha sobre investigaciones que atacan la integración de los sistemas heterogé-
neos. Para la presentación de esta información se citará por artículo una breve explicación de
las ideas principales que aporta cada uno de ellos.
En I141 se discute que en un sistema de múltiples bases de datos, un esquema global es creado
por la integración de los esquemas de las bases de datos locales para proveer una interfaz uniforme
y transparencia de localización a un alto nivel, El principal problema para la construcción de
un esqueina global es resolver los conflictos a través de los esquemas que los componen. En
este artículo definen aserciones de correspondencia para los administradores de las bases de
datos de cómo se debe especificar la correspondencia semántica a lo largo de los objetos que
pertenecen a los esquemas locales que componen el esquema global. Las reglas de integración
son diseñadas y basadas sobre estas aserciones, las cuales usan un conjunto de operadores de
integración primitivos para reestructurar los esquemas locales: resolver los conflictos y hacer la
integración. El principio de su estrategia de integración es llevar los datos de las bases de datos
locales al esqiienia global sin perder información. Además, mucha información de las respuestas
15
Nombre del sistema/ Organización ADDS (Amoco D i s tributed Database System) Centro de investigación de Arnnrn
Dataplex Investi- gación de General . Motors DQS (Sistema de consultas dis- tribuidas) CRAI Italia EDDS (Sistema de basede dato: experimental), Uni- versidad de Ulster HD-DBMS ( - Heterogéneos die tribiiidos - DBMS ] UCLA
JDDBS(Sistema de base de datos japones), Ceii- tro de desarrollc y procesamiento de información japonec. Mermaic, Unisys
Multibase, Corpo- ración de computa- doras de Aniérica MukiStar, consor- cio encabezado por CRAI, Italia.
NDMS (Sistema manejador de dahs de red), CKAI, Italia
Estado de desarrollo
Prototipo limitado
Prototipo liniit,ado
Prototipo
Prototipo
Investigación
Prototipo limitado
Prototipo
Prototipo limitado
Prototipo
Protot,ipo
Modelo de dato: global
Relacional extendido
Relacional
Relacional
Relacional
Eiitidnd-relación
Relacional
Relacional
Funcional
Relacional
Relacional
Modificación global
En un futuro próximo
Si
No
Si
Si
No
No
si
Caracteristicas claves
Funciones generales, poderoso uso de inkrfnces, limitantes globales.
Descomposición y optimización de consultas Optimizadón de consultas
Puede unir s i s temas de máquinas pequeñas
Información de en- rutaniiento para acceso global, - vistas externas en múlt,iples modelos de datos Basnda sobre una red de transmisión
Opt,irnización de consult.as Funcioncs generales
Procesamiento de consultas, capaci- dad de enlace a otras multibase de datos Opt,imización de consultas
Tabla 2.1: Clasificación de proyectos multibase de datas con esquema global
16
Nombre del sist,ema/ Organización Preci, Universidad de Aberdeen.
Estado de desarrollo
Prot,eus, Universi- dad de British
Modelo de dalas Modificación global global
Scoop, Universidad de París y Turin
Protoipos limitados
Prototipo
SirusDelta, Inria, Francia
Relacional Si
Conceptual NO
Unibase, Insti- tuto dc ciencia, tecnología e infor- mación económica,
Invest.igación
Prototipo limitado
Investigación
Polonia XNDM(Manejador
Entidad-relación
Relacional
Relacional
de una red de datos experimental), De- partamento na- cional de estandar
Prototipo limitado Relacional si
abstracto 1
Caracteristicas claves
Replicadm de datos, nodos que pueden soportar diferentes nive- les de funciones globales Topología de red est,rella: lenguaje de acceso global rniilt.inle Estudio de - algorítmos de rnapeo entre niveles de sistemas fModelo de dat,os global/lenguaje), traslación delpara un sistema pivote. Limitaciones globales
Traslación de datos, uso de nodos servi- dores para proie- samiento global.
Tabla 2.2: Continuacióii de la clasificación de proyectos multibase de datos con esquema global.
17
Nonibre del sistema/ Organización Heirnbigner, uni- vesidad de colarado
Est,ado de desarrollo
Ingres/Star, Com- pañia de tecnología relacional.
Superdatabase, Universidad de Columbia
Modelo de dntos global
Relaciona1
Modificaciones globales
Si
En un próxhio futuro
Si
Características claves
Soporta un lenguaje para trans formación de datos, negociación de prn- t.ocolos para la creación de esqne- nias de entrada. Puede definir la múltiple ini- portación de esque- mas de un nodo Estructura de un sistema jerdrquico, mntrol concurrente.
Tabla 2.3: Clasificación de proyectos multibase de datos con bases de datos federadas
a las peticiones puede ser derivada de las múltiples bases de datos debido a la in tepc ión de los
esquemas. Las estrategias para procesar las peticiones globales propuestas, usan la información
mapeada proporcionada entre las peticiones del esquema global y los esquemas de las bases de
datos locales para descomponer las peticiones globales en pequeñas subconsultas. Un lenguaje de
control de fliijo es definido entonca para especificar el Ruja de ejecución de las subconsultas para
lograr la integración de los resultados parciales. Algunas técnicas de optimización de consultas
se consideran en la especficaciúii del flujo de ejecución.
En [15] se discute el uso y tratamiento de las restricciones de integridad en el proceso de
diseño de las bases de datos federadas. Considera diferentes situaciones que ocurren freciiente-
mente en el proceso de transformación e integración de esquemas. Basado en esto, se dan las
reglas generales para describir el tratamiento correcto de las restriccioiies de integridad. Otros
trabajos sobre la integración de esquemas no consideran del todo las restricciones de integridad
o se limitan a tipos especiales de restricciones. Por lo tanto, la propuesta de este trabajo puede
ser usada para extender o conipletar las metodologías existentes de integración
En 1161 se presenta un marco de trabajo formal para la combinación de esquemas. El
18
..
Nombre del Estado de Modelo de dat,os Modificaciones sistema/ desarrollo global globales Organización Emprw, Com- Comercial Relacional Si pnñía Rhodiiis.
Sybase, Conipañía Comercial Relacional Sybase
Sist,ema R.2, IRM Protot,ipo Relacional Si
. . . . . !
Características claves
Funciones del lenguaje global limitadns
del Funciones lenguaje global limitadas Optimiznción de consultas
Nombre del sistema/ Organización Calida, Lnborat- rios de investicación GTE Hetero, Felipe Carina, California Linda, Gen- t,ro de investi- gación tkcnica de Finlandia MR.DSM(Multiple almacenamiento de datos relaciona1 Mult,ics) Inria, Francia. Odu, Universidad de Wales
SWIFT( Sociedad de redes amplias de telecomunicaciones de interbancos fi- naeieros), SWIFT Europa VIP- MDBS(Sistema multibace-Prolog integrado . de - Viena), Univer- sidad técnica de Vienna
Estado dc desarrollo
Prototipo
Prototipo
Prototipo limitado
Prototipo
Prototipo limitado
Invest,igaiión
Prototipo
Modelo de datos global
Relacional
Exteniión relaciona1 Relacional
Relacional
Entidad-relación
Relacional
Relacional
Modificaciones globales
Si
Si
si
No
Caract,erísticas Cl?l"eC
Optimización dr consultas, union= implícitas Poderoso uso de interfaces Deja de ser un sis- temn multibase de datos
Funciones generales, carac- terísticas de muchos lenguajes, limita- ciones globales Puede enlazar s i s i.enins de nidauinas pequeñns.
Estruct,iira Y procesamiento de t,rancacciones
El lenguaje global es Prolog
Tahla 2.5: Clasificación de proyectos multihase de datos con lenguaje multihases de datos h e
inogéneas
19
principal identificado es determinar cuándo dos esquemas pueden ser integrados sig-
nificativamente. Otro problema es c6mo mezclar dos esquemas dentro de un e w e n i a integrado
que tenga la misma capacidad de información como la tiene cada uno por separado, es decir,
que el esquema resultante pueda representar cuando menos la misma inforrnación que los esque
nias originales. Muestra que amhos problemas pueden ser resueltos poniendo restricciones sobre
los esquemas a ser integrados. La restricción, llamada libreconflictés, está en que las reglas de
un esquema juntas con un conjunto de aserciones de correspondencia puede no restringir los
modelos del otro esquema. También da resultados complejos para el problema de determinar la
libreconflictés.
En [17] se describe nu método para integrar modelos de información desarrollados sepa-
radamente. Los modelos pueden ser los esquemas de las bases de datos, marcos de sistemas de
bases de conocimiento o modelos de procesos de operaciones de empresas. El método trata de
integrar en el nivel semántico, usando una ontología global para resolver las inconsistencia$. Los
modelos integrados proveen una vista coherente de un gran sistema de información que pone a
disposición sus recursos para tener acceso y poder modificarlos adecuadamente. Presenta algu-
nas heurísticas y pueden ser usadas con una limitada intervención del factor humano para guiar
este proceso.
En [18] se menciona que dos importantes problemas en la integración de vistas son el
identificar y el unir equivalencias semánticas de rriodelos construidos con estructuras diferentes,
Un modo de abordar este problema es estandarizar los esquemas a ser integrados a través
de aplicar un número de transformaciones de esquemas para ellos. Formaliza el concepto de
transformación de esquema en el contexto de una propuesta de modelado basado en la lógica
Introducen varias transformaciones y muestran cómo los esquemas pueden ser usados en el
proceso de integración de vistas.
En [19] se expone que los principales problemas en la integración de esquemas son la iden-
tificación de correspondencias entre diferentes esquenias conceptuales y verificacióii de que las
correspondencias propuestas son consistentes con la semántica de los esquemas. Esto puede
ser eficientemeiite abordado si el esquema conceptual es expresado en un modelado formal con
enriquecimiento semántica. Introducen ei modelado formal como una gran usando
las gramAticas de casos. Muestran que es fácil identificar correspondencias entre esquemas ex-
presados en su formalismo que en esquemas formulados en lenguaje de modelado tradicional,
La razón principal es que la gramática estandariza la terminología en esquemas conceptuales
proveyendo un conjunto significativo y establece etiquetas para relaciones conceptuales.
En [20] se presenta una propuesta específica de integración de sistemas de bases de datos
relacionales dentro de un sistema de bases de datos federadas. El proceso de integración COI]-
siste de tres pasos: primero, los sistemas de hases de datos externos deben estar conectados
al ambiente del sistema de bases datos integrado y los modelos de datos externos han de ser
mapeados dentro de un modelo de datos canónico. &te paso es también llamado transformación
sintáctica qne incluye el enriquecimiento estructural de cada uno de los esquemas de las bases
de datos externas. Segundo, los esquemas resultantes del primer paso son usados para construir
esquemas de exportación y tercero los esquemas exportadas son integrados en esquemas globales,
individuales o como vistas.
En [21] discuten el juego de los metadatos y su soporte para la interoperación de fuentes
de datos lieterogéneas en el DIOM (Distributed Object Model). Describen el papel del DIOM-
IDL como un lenguaje que expresa información de los metadatos y cómo ellos se unen para
resolver el problema de la heterogeneidad para administrar las propiedades USECA (Uiiiform
Acces, Scalability, Evolution, Composability, and Autonomy). Usan la descripción de la in-
formación producida por los productores y consumidores. Diorama (el proyeLto) los compara
dinámicamente. Además, DIOM-IDL describe las interfaces de los agenta intermediarios (Ila-
madm mcdiadores), los cuales contienen conocimiento de dominio específico para facilitar la
conexión entre los productora y consumidores, La principal contribución es un metarnodelo
(el lenguaje DIOM-IDL) suficientemente poderoso para describir los metadat,os necesarios en . .
21
el soporte de las us~C.4 en el ambiente Internet. Muchas de las investigaciones
previas de metadatos se hail concentrado sobre la descripción de datos bajo el esquema global.
DIOM-IDL describe tales datos y describe interfaces abiertas que identifica iguales descripciones
de diferentes esquemas.
El [22] describe al sistema multibases de datos CORDS (Consortium for Research Distributed
Systems) que provee aplicaciones con una vista integrada de una colección de fuentes de datos
heterogéneas y distribuidas. Las aplicaciones son presentadas como una vista relaciona1 de los
datos disponihles y que son capaces de tener acceso a los datos usando operaciones SQL. Las
vistas de las aplicaciones de los datos se definen por un proceso llamado integración de esquemas.
En este reporte técnico se describe el método desarrollado para la integración de esquemas en
el sistema de multibases de datos CORDS y también el conjunto de herramientas que soporta el
método.
En (23) mencionan que son cuidadosos en buscar las asunciones entre el uso de la equivalencia
de la capacidad de información como una medida de correctés para el enjuiciamiento de los es-
quemas transformados en la integración de esquemas y metodologias de traducción. Presentan
una clasificación de integración común y tareas de traducción basadas sobre sus objetivos opera-
cionales y derivan de ellos los relativos requerimientos de capacidad de información del esquema
original y del transformado. Muestran que para muchas tareas, la equivalencia de la capacidad
de información de los esquemas no es estrictamente requerida. Basado en esto, presentan una
nueva definición de corre&% que refleja cada tarea que se emprende. Entonces, exairiinan las
metodologías existentes y muestran cómo las anomalías pueden aparecer cuando se usall aquellas
que no cumplen loc criterios de correctés propuestos.
En 1241 se habla de un trabajo teórico que ofrece medidas de.equivalencia de esquemas
basados sobre la capacidad de información de los esquenias. El trabajo está apoyado en la exis-
tencia de funciones abstractas que satisfacen varias restricciones entre los conjuiitos de todos los
casos de dos esquemas. Se consideran esquemas que son m& o menos prácticos, sin embargo,
22
no está ‘Iaro razonar acerca de la existencia de tales hinciones abstractas, por lo tanto,
estas de equivalencia tienden a ser liberales también en el sentido de que los esquemas
son considerados equivalentes cuando una partición los consideraría diferentes. cómo un resul-
tado, las metodologías prácticas de integración no han ut i l izdo estos fundamentos teóricos y
muchos de ellos han realizado un trabajo ad hoc. Se presentan los resultados que buscan
este hueco. Primero, consideran que el problema de decisión de la capacidad de equivalencia
de información y el dominio de los esquenias que ocurren en la práctica, por ejemplo, aquellos
que expresan herencia y retricciones de integridad simples. Muestran que el problema es in-
definible. Esta indefinición sugiere que, aunada a la excesiva naturaleza liberal de la capacidad
de equivalencia de información, debe de haber una alternativa, con más idéas restrictivas de
equivalencia que puede ser probada efectivamente. Desarrollaron varias pruebas, cada una sirve
como condiciones suficientes para la capacidad equivalente de información o en dominancia.
Cada prueba es caracterizada por un conjunto de transformaciones de esquemas en el siguiente
sentido: una prueba declara que el esquema S1 es dominado por S2 si y sólo si hay una secuencia
de transformaciones que convierte s1 a 52.
En [25] niencioiian que el h i t o de un sistema integrado es la alta dependencia sobre el de-
sarrollo &toso de un modelo de datos global. Cualquier sistema integrado, un almacén de datos,
un mediador o un sistema compuesto. debe ser capaz de manejar niúltiples interpretaciones de
símbolos, conceptos, extensiones e iiitensiones. Este artículo discute la naturaleza bajo fijación
subjetiva de la integración de datos e ilustra el resultado de problemas seniánticos que ocurren.
Las anotaciones son introducidas para extender la habilidad de los modelos para representar la
semántica de las bases de datos que forman el sistema.
En [26] y (271 mencionan que en un sistema de multibases de datos, los conflictos de esque-
mas entre dos objetos son usualmente de inter& sólo cuando las objetos tienen alguna similitud
semántica. Datan de reconciliar las perspectivas semánticas y esquemáticas. Introducen un
formalismo uniforme llamado correspondencias de esquenias para representar las similitudes
23
semánticai entre los objetos. Representan la similitud semántica entre 10s objetos usando el
concepto de proximidad semántica. Proveen una taxonomfa Semántica de modelo de datos in-
dependiente sobre la base de la proximidad semántica definida. Entonces, enumeran Y clasifican
los coiiflictos de datos y de esquemas. La asociación entre las correspondencias de esquemas y
de la proximidad semántica ayuda a representar las posibles similitudes seinánticas entre dos
objetos que tienen conflictos. La representación de la información incierta se integra niediante
el uso de proximidad semántica como hace para ser explorada.
En [28] desarrollaron un prototipo que es un tookit llamado Bellcore Schema Design and
Integration (BERDI). Su objetivo es soportar un pragmático, flexible, rápido y preciso p r e
ceso de diseño de nuevos esquemas (incluyendo las restricciones de integridad del modelo de
datos e información extensible del diccionario) como una mejor manera de adniinistrar esque
mas. El énfasis de BERDI ha sido el análisis, especificación de interdependencia y consecuencias
relacionadas con la integración para manejar múltiples esquemas. BERDI soporta la adminis-
tración de múltiples actividades referentes a esquemas (incluyendo la integración de esquemas)
que pueden ser caracterizadas en cuatro fases: a) fase preintegración soporta el desarrollo de
esquemas que son complejos y consistentes con respecto al modelo de datos ( incluyendo sus
restricciones de integridad ) y la información del diccionario de datos (p.. . metadatos); b) se-
gunda fase del análisis del esquema soporta una única facilidad de consultas gráfica sobre los
esquemas (incluyendo la información del diccionario) para ayudar a identificar los objetos rela-
cionados y la habilidad de definir relaciones en el nivel de atributos e interdependencia en el nivel
de la entidad; c) tercera fase de la integración de esquemas involucra el uso de los resultados del
análisis del esquenia para identificar los objetos candidatos en diferentes esquemas fuentes para
la integ~ación, creando nuevos objetos por la mezcla de objetos de los esquemas originales; d)
cuarta fase soporta la reestructuración del esquema, así como el análisis y docunientación. El
integrador tiene la flexibilidad de aproximarse a diferentes niveles de integración y algunas de
las actividades son opcionales.
24
.-
Con base en lenguajes estandarizados ya existentes, se construyeron lenguajes u>mpIejos
para poder tener acceso a las multibases de datos, tal es el caso de 1241 dande declaran
la administración de un sistema inultibase de datos es complicada por los requeriinientos de
distribiiciÓn, ~utonomía ~ocal,' heterogeneidad estructural y semántica de los iniembros de las
bases de datos. La heterogeneidad semántica, en particular, concierne a las diferencias en el
significado e interpretación de objetos de datos similares a tra\.és de los diferentes sistemas.
Como una consecuencia, los conflictos de heterogeneidad deben ser detallados en el nivel de
aplicación y los lenguajes de acceso a la multibase de datos deben estar equipados con carac-
terísticas especiales para resolver las discrepancias estructurales y semánticas. Ellos proponen
un lenguaje de manipulación de multibases de datos, motivados por el Multidatabase SQL, como
una herramienta para el acceso.de información que contenga la presencia de conflictos de datos
y de esquemas. Se discuten características específicas para tener acceso a funciones externas,
integración parcial de esquemas definidos por el usuario por medio de las clases de atributos,
joins entre bases de datos locales generalizados, además del proceso de integración automática
para los joiiis implícitos locales
El enriquecimiento del esquema es parte de las soluciones reales implantadas al menos
en prototipos. El proyecto más reciente es el de 1291 y (301 que presentan un método que
integra el manejo de datos distribuidos por una variedad de SMBD. Ellos enfatizan un diseño de
infraestriictura para asistir en el modelado de empresas y análisis de requeriniientos. El grupo
de investigación ha desarrollado un método (Enterprise Requirements Analysis - ERA) para
dacribir una estructura a gran escala suministrando un conjunto de metamodelas genéricos.
Estos metamodelos son almacenados en un repositorio semántica (Semantic Indexing System
- SIS). La infraestructura sugerida usa la semántica de la información perteneciente a la base
de datos, la cual es requerida Iior la aplicación de un método de ingenieria inversa de base de
datos y convertida en un modelo especifico de red semántica (TELOS) similar al modelo entidad
relación extendido. Se explica el marco de trabajo y se describen la estructura de la propuesta
25
y los mecanismos que acompañan en la integración de datos. Auguran que la integración
de los metadatos de las bases de datos con la aplicación de la Semántica del dominio
pueden romper las barreras de la heterogeneidad y de la construcción eficiente del manejador
de la base de datos global (o virtual). Finalizan denotando varias formas de heterogeneidad que
obstruyen el intento de unificar bases de datos. Subsecuentemente describen una técnica capaz
de proveer soporte para la heterogeneidad, La idea es iniplementada por un software diseñado
para enfatizar los problemas y proporcionar las bases de la integración.
En [is], al igual que en [31], explican cómo construyen un marco de trabajo para determinar
cuando dos esquemas pueden ser integrados significativamente. En (311 continúa su trabajo al
declarar que! intuitivamente, dos esqueinas pueden ser integrados si las reglas de uno de los
esquemas junto con un conjunto de aserciones de integración no restringen el modelo del otro
esquema. Formaliza el concepto usando la idéa de libreconflidés y muestra cómo puede ser
usada para asegurarse que con la unión de dos esquemas resulta un esquema integrado con
la misma capacidad de información de la original de cada uno de los esquemas. El problenia
de libreconflictés es abordado muy poco y es esbozado por cómo puede ser direccionado por
dominios finitos y determinar sus propiedades complejas en este caso. La propuesta inicia con
el enfoque estático y continúa con los aspectos dinámicos de un esquema, cuando el dinamismo
es modelado por el significado del concepto de evento. Deducen aserciones correspondientes
para los eventos que pueden ser usados para especificar la equivalencia de las combinaciones de
eventos.
E n 1321 mencionan que una parte esencial de un sisteina de multibases de datos es un modelo
que es capaz de incorporar diferentes esquemas de base de datos. Este modelo debe ser capaz
de relacionar los conceptos con los datos locales compartidos. Las relaciones que son incluidas
pueden ser tan confiables y sencillas como una conversión de sintaxis o tan complejas como la
equivalencia de atributos condicionales. Más o nienos, el modelo debe perinitir peticiones para
ser hechas en el nivel local siendo todavía guiadas en el nivel global. Presentan un g a f o orientado
26
a Objetos uno de tales modelos. Los conceptos de las bases de datos locales y los conceptos
de uafos Orientados a objetos son relacionados y enlazados por aristas anotadas, las cuales son
usadas algorítmicamente para transformar una petición local a una serie de otras subpet,iciones
locales. Así, este método de integración provee un método para modelar la correspondencia de
datos a través de una variedad de modelos de datos.
E n 1331 propone un proceso de integración de esquemas investigando el contexto de una
lógica basada en un lenguaje de modelado. Muestra qué información equivalente de diferentes
esquemas conceptuales pueden ser representados por ciertos tipos de expresiones, llamadas aser-
ciones de integración. Dos formas básicas de aserciones de integración son identificadas: aser-
ciones de objetos equivalentes y aserciones de extensión de relación. Se propone un método para
la integración automática de esquemas, basado en un conjunto de aserciones de integración.
En 1341 describen un marco.de trabajo para un modelado orientado a objetos de meta in-
formación y su uso para la integración de bases de datos heterogéneas con el objetivo de su
interoperación. La nietainformación consiste de todos los tipos de información necesaria para
tener acceso e interoperar con las bases de datos participant-. Como parte de la metainfor-
mación modelaron las propiedades comunes y las diferencias de los modelos de varios datos
y sisteinas concretos. Adicionalmente, también incluyen informaciún para el enriquecimiento
seniántico de los esquemas de las bases de datos participantes, proveyendo las pautas para una
traiisformación de esquemas (semi)automática. Describen el enriquecimiento seniántico de un
esquema relacional usando información adicional deducida de su nivel inferior de diseño entidac-
relacióii del esqueina. El enriquecimiento de esquema? relacionales puede ser automáticamente
transformado a esquemas correspondientes en el modelo de datos comiín, el cual, en este caso,
es el modelo orientado a objetos. Las consultas usan el esquema creado orientado a objetos
y pueden ser automáticamente traducidas a subconsultas SQL equivalentes para el esquema
relacional original.
En [35] toman en cuenta que la integración de datos es costosa, debido, en gran parte, a la
27
dificultad de recolectar metadatos relevantes. Observan que una base de datos puede participar
en esfuerzos de integración, y que se requieren muchos de 10s mismos metadatos, Sin
importar qué tipo de esfuerzo está siendo emprendido. Se presenta una P a n oPortl1nidad para
reducir el costo y el tiempo del desarrollo y mantenimiento de las sistemas interoperable, por
obtener los metadatos relevantes sólo una vez y representándolos de un modo que sean accesibles
para su reuso. Presentan estrategias de gestión de metadatos que prometen reutilizar y describir
una visión basada en repositorios para el desarrollo de sistemas interoperable.
En [36] se trabaja sobre las ontologías como una conceptualización estándar en arquitec-
turas distribuidas que tienen algunas bien conocidas desventajas. Es, por ejemplo, la falta de
solución para el problema presente. En este artículo se describe un experimento de aceptación
de estructuras de (múltiples) ontologías Iieterogéneas para su uso en arquitecturas distribuidas.
Después se discuten niodos alternativos para relacionar diferentes ontologías en donde analizan
dentro de una configuración particular (jerárquica) de ontologías heterogéiieas y examinan cómo
la información puede ser pasada entre sistemas individuales que son enlazados por diferentes on-
tologías.
En [37] y 1381 declaran que el crecimiento de Internet ha revitalizado la investigación sobre
la integración de fuentes de información heterogénea. Hacen un esfuerzo para internar fuentes
de información heterogénea llegando a un arregbentre interoperabilidad y heterogeneidad. Los
obstáculos importantes en la integración son alrededor de las diferencias en las ontologías de
varias fuentes del nivel inferior. Se investigan los impedimentos para la integración, tomando en
cuenta las ontologías (contrario a los esquemas de base de datos). En particular, se presenta una
clasificación de las diferencias ontológicas y se discute cómo pueden ser tratados cada uno de
los tipos diferentes. La idea es que conociendo las diferencias ontológicas que son dificultosas de
tratarse, éstas pueden contribuir a buscar un balance entre heterogeneidad e interoperabilidad.
En la siguiente sección se presentan trabajos que eiifatizan la parte teórica, principalmente
el P a n problema que se tiene con la semántica de los datos y su integración. Se abordan los
28
aspectos teóricos sobre la integración de esquemas y diferencias semántica de los datos. Se trata
de definir claramente lo que es un esquema como lo hacen en (391.
I<rislinaniurthy y Naqvi [40] proponen nu lenguaje similar a las cláusulas de Horn que
puede cubrir tanto datos como a metadatos, proporcioiiando variables de orden superior. Este
lenguaje tiene mucho o todo el poder de Prolog y, a diferencia de Prolog, es declarativo. Está
basado en semántica ascendente y funciona reemplazando la unificación de orden superior con
los términos de igualación de operadores. Krishnaniurthy, Litwin y Kent (411 extienden este
lenguaje y demuestran sn capacidad de integración de esquemas relacionalei. Sin embargo, no
proveen un modelo semántico teórico formal para su lenguaje.
I
La segunda tentativa para la integración de esquemas involucra la definición de un lenguaje
de orden superior que pueda expresar peticiones sobre la metainformación correspondiente a
las bases de datas y sus esquemas. Así, el MDC que es definido en la categoría anterior, no se
requiere: el lenguaje de orden superior en cierto sentido, juega el papel de MDC en este caso.
La mayor desventaja asociada con esta solución tentativa es que la declaratividad de ésta deriva
de su fundamento lógico.
Los últimos trabajos relacionados con la integración de datos se dan en proyectos bastante
completos en donde retoman el concepto de enriquecer el esquema con metainformación. Tal es
el caso inicial de [42].
Muchos de los primeros intentos para abordar los problemas de integración de esquemas
han sido ad hoc. El analisis de Batini et al. [43] discute y compara 12 nietodologías para la
integración de =quemas. Se pueden clasificar los métodos de integración de esquemas en dos
grandes categorías [44].
Muchos de los primeros intentos para la integación de esquemas caen en utilizar un lenguaje
multibase de datos. Las bases de datos participantes en la federación son niapeadas a un modelo
de datos común (MDC) (el más común es el modelo 00), el cual actúa como un intérprete
entre los sitios locales. Las similitudes en los contenidos de información de las bases de datos
29
ilidividuales y sus interrelaciones semánticas son capturadas y mapedas al MDC. Con cierta
1% peticiones de 10s usuarios ai MDC usan un lenguaje MDC ~‘usualme*te debe
ser transparente del esquema MDC. En un escenario sotisticado, las vistas que se usan para las
consultas, corresponden al esquema de las bases de datos participantes que son definidas sobre
el MDC, así proveen al usuario una ilusión de que toda la inforniación que se obtiene es de SU
propia base de datos. A esto se le llama integración transparente.
Otra forma de abordar el problema de la integración’de datos, es estudiando el significado
de éstos llegando liasta su ontología.
En [45] muestran una propuesta para eliminar la heterogeneidad semántica de bases de datos
interoperables, autónomas y heterogéneas utilizando el concepto de bases de datos federadas. Un
mecanismo es descrito para identiticar y resolver la heterogeneidad semántica y mientras que, al
niismo tiempo, respetar la autonomía de las bases de datos que la conipoiien y participan en la
base de datos federada. Como mínimo, un modelo de datos común es introducido como la base
para describir la información compartible y una triple facilidad para determinar las relaciones en-
tre las unidades de información (los objetos) s desarrollada. Su propuesta sirve como base para
compartir de conceptos relacionados directamente (parcialmente) con la unificación de esquema
sin la necesidad de una vista global de los datos que son almacenados en diferentes componentes.
El mecanismo presentado aquí puede ser visto en contraste con otras propuestas tradicionales
como bas& de datos integradas o bases de datos distribuidas. Un prototipo experimental ha
sido construido dentro del marco de trabajo del sistema experimental “Remote-Exchange”.
También, se han dado discusiones sobre los elementos y conceptos bases de la semántica de
los datos, tal es el caso de [46], donde habla en un panel durante una sesión de la conferencia DS-6
(Data Semantics), son cuatro panelistas (Leo Mark, Robert Meersman, Sham Nakathe y Arnon
Rosenthal) y abordan preguntas claves relacionadas sobre el tópico de la conferencia, relacionan
SUS Perspectivas sobre qué fue presentado y discutido en la conferencia, las consecuencias de
inv~stigación sugeridas en la semántica de datos que a ellos les gustaría ver abordadas en el
30
futuro. El Panel fue organizado, introducido y moderado por el autor. varios participantes en
]a conferelicia también presentaron alguna párrafos cort,os durante el panel,
Un ejemplo canónico del uso del MDC es el proyecto Pegasus de Ahmed et al. [47] pegasus
define un modelo de objetos común para unificar los modelos de datos de los sistemas de las capas
inferiores. Landers y Rosenberg [48] usan un modelo funcional de DAPLEX como un MDC en SII
proyecto Multibase, mientras Mermaid [49] usan un MDC relaciona1 y permite sólo la integración
de esquemas relacionales. Los usuarias que usan este esquema pueden hacer peticiones usando
SQL. E1 principal problema asociado con este tipo de solución es la gran cantidad de participación
humana requerida para obtener el mapeo al MDC. Los cambios dinámicos en la semántica o en
los esquemas de las bases de datos individuales pueden también dejarse para que sean absorbidos
por el MDC, requiriendo una mayor intervención humana.
Un rápido progreso en la investigación de las bases de datos durante las pasadas dé-
cadas ha dado como resultado una evolución de los diversos ambientes de bases de datos con
datos y programas de aplicación generados específicamente para cada uno de esas ambientes,
pero típicamente incompatibles entre ellos; esto ha producido una inhabilidad para compartir
datos y progamas a través desdiferentes plataformas. Existe tamhién mucha redundancia e
incompatibilidad de datos. Esta administración de redundancia necesaria y reescritura de p r e
gramas de aplicación, involucra un gran esfuerzo de investigación. Esto motiva la necesidad de
las multibaces de datos heterogéneas, capaces de operar sobre una red distribuida y compagi-
nar con una mezcla de sistemas heterogéneos de computadoras, sistemas operativos, enlaces de
comunicación y sistenias de base de datos locales
2.3 Areas de investigación en sistemas multibase de datos
Dada la complejidad de los sistemas miiltibase de datos los investigadores se han enfocado
a atacar diferentes áreas de investigación y aunque el objetivo de este trabajo de tesis es el
manejo de integración de información de tales ambientes, creemas conveniente dar un panorama
31
general de las principales áreas de investigación y sus tendencias actuales. La mayor parte de
los trabajos sobre multibases de datos se concentra en las siguientes áreas: (1) integración de
esquemas, (2) manejo de transacciones, (3) optimización de consultas y (4) inultibace de datos
orientada a objetos [50].
2.3.1 Integración de esquemas
El prableiiia de integración de esquemas en un ambiente de bases de datos lieterogénws
puede ser descrito como un conjunto dado de esquemas de bases de datos locales, donde se puede
crear un esquema integrado de tal forma que cada esquema local pueda ser considerado como
una vista del esquema integrado
Hay dos enfoques básicos a este problema. Uno requiere que el administrador de la base de
datos forme un esquema global para un conjunto de bases de datos locales a ser integradas y a
cada aplicación del usuario se le proporciona su propia vista del esquema global. Este enfoque
es conocido, por lo tanto, como esquema global.
En ambientes heterogénms uno de los principales problemas en la integración de esquemas
es la resolución de inconsistencia de datos que puede existir en diferentes fuentes de datos para
datos semánticamente y sintácticamente idénticos.
El enfoque alternativo a la integración de esquemas no requiere la creación del esquema
global. Para cada aplicación el administrador de la base de datos crea un esquema describiendo
solamente los datos que la aplicación puede accesar en la base de datos local. El esquema es
llamada esquema de importación. El administrador de cada sitio local solamente puede crear
el esquema de los datos que la base de datos tiene acordado compartir con otros sitios. Este
enfoque es conocido como hase de datos federadas.
32
2.3;2 Optimización de consulta
El problema de OPtimiZaCión de consultas en ambientes de base de datos centralizadas y
distribuidas homogéneas ha sido ampliamente estudiado y muchos resultados han aparecido en la
literatura. El problema en ambientes de base de datos heterogéneas ha sido estudiado en menor
grado. Una de las principales dificultades para lograr una optimización de consulta &tosa en
tales ambientes es la inhabilidad del sistema multibase de datos de generar un modelo de costo
estimado que sea realista.
La autonomía y la potencial heterogeneidad de los componentes del sistema crean problemas
en el procesainiento de consultas y especialmente en la optimización de las mismas. El problema
fundamental es la dificultad de la optimización global cuando las funciones de costos de subcon-
sultas locales no son conocidas y los valores de los costos locales no pueden ser comunicados al
sistema niultibase de datos. Una posible solución a este problema es la optimización semántica
ba5ada solamente en lo cualitativo de la información, pero el procesamiento de consultas seiiián-
ticas no ha sido totalmente entendido y aceptado. Pot,encialmente, puede ser factible desarrollar
una jerarqnía de optimizadores de consultas que ejecuten alguna optimización global y dar a
cada sistema local una optimización de una subconsulta local. Este enfoque no proporciona la
solución óptima, pero puede estar cercano a ella.
2.3.3 Manejo de transacciones
La idea básica en el manejo de transacciones en un ambiente de multibase de datos es
garantizar la consistencia global, la inexistencia de interbloqueos globales y la ejecución confiable
de las aplicaciones en el sistema miiltibase de datos, en la presencia de concurrencia y fallas,
incluso en presencia de las transacciones locales de 1%- cuales el sistema multibase de datos no
está consciente.
Las dificultades de esta idea son consecuencia de que cada uno de los SMBD locales opera
en forma autónoma y las transacciones locales se ejecutan fuera del control del sistema multibase
33
de datos. El problema ha sido estudiado ampliamente en dos direcciones básicas: restringiendo
la autonomía del SMBD local y preservando la autonomía total del SMBD local.
Restringiendo la autonomía implica que el SMBD local puede ser modificado para habilitar
y compartir con el sistema multibase de datos sn control de información local. Esta suposición
sin embargo, requiere cambios en el diseño del SMBD local; como resultado, reduce el problema
de la administración de las transacciones en multibase de datos y lo convierte a un problema
similar al de las bases distribuidas homogéneas.
La preservación total de la autonomía local de los SMBD implica que los SMBD locales no
serán modificados y por lo tanto no pueden compartir el control de su información local con el
sistema multibase de datos.
2.3.4 Multibases de datos orientadas a objetos
La investigación en bases de datos orientadas a objetos fue iniciada recientemente y muy
pocos artículos han aparecido sobre este tema. Muclios investigadores han sugerido que el uso
de las tknicss de orientación a objetos facilitará la construcción de los sistemas multibase de
datos. Las técnicas orientadas a objetos, las cuales nacieron en el área de los lenguajes de
programación, han sido ampliamente usadas en todas las áreas de la ciencia de la computación
incluyendo diseño de software, tecnologías de base de datos, inteligencia artificial, y sistemas
distribuidos. Si bien el uso de todas ellas en la construcción de sistemas multibase de datos
parece prometedor, la carencia de una metodología común dificulta cualquier desarrollo nuevo.
Los sistemas multibase de datos orientadas a objetos pueden ser muy importantes y con-
tribuirán a la solución de los problemas de integración de esquemas, administración de transac-
ciones y problemas en optimización de consultas en ambientes de multibase de datos. Sin
embargo, al respecto, es necesario realizar todavía más investigación para evaluar los beneficios
de este enfoque.
34
2.4 Dimensiones de la integraci6n de bases de datos
La información administrada por los sistemas nianejadores de base de datos muestran un
ambiente heterogéneo a un usuario global, su integracióu puede ser visualizada en tres dimen-
siones ['i]:
Integraci6n del sistema: el poder accesar los datos a más de una base de datos,
y mostrarlos como si pertenecieran a una misma base de datos global.
Integración del esquema: es el conceptualizar un esquema global uniforme de las
bases de datos locales heterogéneas.
Integraci6n semhtica: resolver los conflictos que existen entre los datos que
componen el esquema de la base de datos global.
2.4.1 Integración del sistema
La integración de información provee tanto transparencia para el usiiario como de los sis-
temas manejadores de bases de datos locales. Como participan múltiples bases de datos que son
usualmente distribuidas, la multibase de datos podría facilitar la comunicación y permitir a los
usuarios accesar a mtk de una base de datos remota.
2.4.2 Integraci6n semántica y del esquema
La int,egración de los datos es sobre quéllos que semánticamente significan lo mismo pero
se encuentran con inconsistencias entre los diferentes manejadores de bases de datos locales.
Actualmente ésta es un área de investigación activa, con muchas preguntas abiertas todavía
sin responder. Como únicamente pueden integrarse los datos que semánticamente representan
un mismo concepto para el iisario global, el primer paso es determinar qué objetos comparten
un mismo significado semántico. La determinación de d a identificación hasta el momento
sólo puede ser hecha por los mismos diseñadores de las bases de datos locales, de esta manera el
35
disefiador del esquema global determinará los mapem del identifieador global a los identificadores
de las bases de datos locales.
Existe heterogeniedad esquemática [26] entre objetos semánticamente equivalentes por in-
compatibilidades de:
* Definición de dominio
* Definición de entidades
* Valor de los datos
* Nivel de abstracción
* Discrepancia esquemática
En la definiciún de dominios est& clasificados los siguientes problemas:
Nombre:
- Homonimia.- es la representación de diferentes atributos pero tienen el mismo
nombre.
- Sinonimia- es la representación de los mismos atributos pero tienen diferente
nombre.
Representación de los datos: son el mismo atributo pero tienen diferente tipo de
dato.
Escala de los datos: representan el mismo dato usando diferentes unidades y
medidas.
Precisión del dato: representa el mismo atributo usando diferentes precisiones.
Valor por default: el mismo atributo puede tener asignado diferente valor por
default en diferentes bases de datos.
Restricción de la integridad del atributo: representan el mismo atributo pero
es restringido por limitantes distintas que no son consideradas en las bases de datos.
36
En la definición de entidades están clasificados los siguientes problemas:
Identificador de la base de datos: es cuando existen diferencia en la equivalencia
de clave.
Nombre:
- Homonimia.- representa diferente entidad con el mismo nombre
- Sinonimia .- representa la misma entidad pero con nombre diferente.
Incompatibilidad de valores: las mismas entidades pueden tener atributos que
no tienen equivalencia.
Ausencia de atributo: el descriptor de la entidad puede tener diferente número
de atributos
Ausencia de dato con valor implícito: el descriptor de una misma entidad puede
tener la ausencia de un atributo como valor implícito.
En el problenia del valor de dato existen los siguientes conflictos,
Inconsistencia conocida: cuando la fuente de inconsistencia es identificada.
Inconsistencia natural: esto es muchas veces debido a la variable tiempo
Inconsistencia aceptable: dependiendo del tipo de la consulta, la inconsisten-
cia entre los valores desde bases de datos distintas podría ser dentro de un rango
aceptable.
En 1s incornpattihilidad en el nivel de abstracción existen los siguientes problemas:
Generalización: cuando la misma entidad es representada a diferentes niveles de
generalización.
Agregación : cuando una entidad en una base de datos corresponde a un conjunto
de entidades (o alguna otra agregación en otra).
37
En el problema de discrepancias de esquemas existen los siguientes conflictos:
Valor de los datos e n los atr ibutos: cuando el atributo de una clase corresponde
al valor de los atributos en otra.
Entidad-atr ibuto: cuando los atributos de una clase corresponden a entidades en
otra.
Valores de los datos de la entidad: cuando las entidades de una clase correspon-
den a valores de atributos en otra.
38
. . ..
Capítulo 3
PLANTEAMIENTO Y
ANÁLISIS DEL PROBLEMA
En este capítulo se hace un planteamiento general del problema de integración de bases de
datos lieterogénem, se mencionan los alcances del proyecto, se describen los objetivos que se
buscan con este trabajo de investigación, definimos los requerimientos para hacer una selección
adecuada tanto de herramientas como de la plataforma de desarrollo, presentamos el análisis de
la solucióii al problema y se bosqueja la arquitectura del sistema eii módulos para determinar
globalmente las partes que lo componen.
3.1 Planteamiento general del problema
Para lograr un ambiente integrado de multibase de datos es necesario determinar un aspecto
clave en la información administrada en los sistemas manejadores de bases de datos locales: la
detección de conflidos eii la representación de la misma información en diferentes esquemas.
Los problemas que implica el integrar un sistema de bases de datos distribuidas heterogéneas
son (511:
Un sistema multibase de datos combina componente autónomos y heterogénens de sis-
tenias de bases de datos locales a un sistema de b a s e de datos global.
* En un sistema multibase de datos las transacciones globales se dividen en subtransacciones
locales.
. 39
* Cada sistema manejador de bases de datos cuenta con un Sistema de integraCi611 de
información sin tomar en cuenta que esta información podría formar parte de un =quema de
integración global.
* Se necesita un diccionario de datos global, que contenga informacióii adicional a la que
manejan los diccionario comunes.
* Tenemos un ambiente compuesto con diferentes sistemas manejadores de bases de datos
donde cada uno de ellos procesa su información de manera independiente.
* Los sistemas manejadores se encuentran trabajando sobre plat,aformas distintas y por lo
tanto con diferentes sistemas operativos.
* La comunicación que se entabla con los diferentes manejadores será por medio de su
dirección URL(1ocalizador uniforme de recursos), que proporcionan la información necesaria
para localizar un recurso sobre Internet.
Por lo tanto el ambiente del problema está compuesto por: sistemas manejadores heterogé-
neos de los cuales queremos extraer información para integrarla. Para establecer la comunicación
entre los sistemas manejadores que se desean integrar necesitamos que se encuentren trabajando
en una máquina que podamos localizarla dentro de la red de Internet para que de est& manera
tenga asignada una dirección URL (ver figura 3.1 ). El usuario global debe contar con la in-
formación necesaria para definir el diccionario de datos global y así obtener un esquema global
lógico sobre las bases de datos locales.
3.2 Alcance del proyecto
Los alcances del desarrollo de este trabajo son los siguientes:
1.- Eliminar la heterogeneidad semántica correspondiente a los problemas de (el
significado de cada uno de ellos es datallado en el capítulo 2.4.2 ):
Definición de dominios:
- Conflicto de nombre(liomonin1ia y sinonimia)
40
Figura 3.1: Esquema del ambiente del planteamiento del problema
- Conflicto en la representación de los datos
Definición de entidades:
- Conflicto de nombre (homonimia y sinonimia)
- Conflicto en la incompatibilidad de valores.
- Conflicto por ausenchde atributo.
Lo referente a estos dos iiltimos conflictos depende de las necesidades del usuario,
si a él sólo le interesa obtener la información (ignorando en el primer caso los atributos
que no tienen equivalencia y en el segundo los atributos que estén de más en el
descriptor) no existe ningiin problema porque al momento de hacer el esquema global
pueda sólo citar una vista del esquema original de la entidad, no precisamente tal
como se encuentre el esquema local, sino sólo lo que necesita el usuario global.
2.- Sólo se integran sistemas manejadores de bases de datos cuyos datos estaii
organizados con el modelo relacional.
41
3.- El sistema desarrollado opera como minimo con 2 sistemas manejadores de
bases de datos, los cuales están corriendo en diferentes plataformas. ..
4.- El usuario global tiene acceso a la información que le ofrece el esquema de
integmcibn por medio de uiya interfaz y puede realizar operacioiies en SQL estándar
las cual- son: INSERT, DELETE, UPDATE y SELECT. Además el usuario puede
definir el esquema de la base de datos global con una sintaxis casi semejante a la
usada en SQL estándar. Por lo tanto el sistema debe contar para la construcción del
esquenia con un DDL y para realizar las diferentes operaciones con un DML.
3.3 Definici6n de requerimientos
Para desarrollar el proyecto es necgario determinar qué lenguaje utilizar y sobre qué
plataforma se va a trabajar, esta decisióii parte de analizar el ambiente del problema, los alcances
que tiene el proyedo y los recursos con que contamos.
En lo que se refiere al lenguaje a utilizar debe brindarnos las facilidades para:
* Desarrollar intérpretes.
* Entablar una comunicación mediante la dirección URL de la máquina.
* El producto final debe ser transportable.
Por lo tanto la plataforma de desarrollo puede ser cualquier equipo de cómputo que se
encuentre conectado a Internet, y pueda ejecutarse el lenguaje que se elige para este desarrollo.
3.3.1 Selección de herramientas de Software
El lenguaje que cubre los requisitos antes mencionado e el lenguaje Java(Sun Microsys-
terns). Java ofrece toda la funcionalidad de un lenguaje potente. Está diseñado para facilitar
un rdpido y fácil aprendizaje.
Java trabaja con sus datos como objetos y con interfaces a esos objetos. Soporta las tres
características propias del paradigma orientado a objetos: encapsulamiento, herencia y polimor-
42
fismo. Las plantillas de objetos son llamadas, como en C++ c l a w y sus copias, ejemplares,
Java se ha construido con extensas capacidades de TCP/Ip. Existen bibliotecas de rutinas
para acceder e interaduar con protocolos http y ftp. Esto permite a los programadores acceder a
la información a travéc de la red con tanta facilidad como a los archivos locales. Java proporciona
las bibliotecas y herramientas para que los programas puedan ser distribuidos, es decir que se
corran en varias máquinas, interactuando
Para establecer Java como parte integral de la red, el compilador Java compila su código a
un archivo objeto de formato independiente de la arquitectura de la máquina en que se ejecutará.
Las aplicaciones de Java resultan extremadamente seguras, ya que no acceden a zonas
Java no delicadas de memoria o del sistema. con lo cual evitan la interacción de ciertos virus.
posee una semántica específica para modificar la pila de progama, la memoria libre o utilizar
objetos y métodos de un programa sin los privilegios del kernel del sistema operativo. Además,
para evitar modificaciones por parte de los usuarios que sabotean la información de la red,
implementa un método ultraseguro de autentificación por clave pública. El cargador de clases
puede verificar una firma digital antes de realizar un ejemplar de u11 objeto. Por lo tanto,
ningún objeto se crea y almacena en memoria sin que validen sus privilegios de acceso. Es decir,
la seguridad se integra en el momento de compilación, con el nivel de detalle y de privilegio que
sea necesario.
. .
Con una mdquina virtual de Java transportada a cada iina de las arquitecturas de las
plataformas presentes en cualquier organización y una buena biblioteca de clases, las aplicaciones
generadas en Java son transportables para cada una de ellas.
1ntrs.net está creciendo actualmente más r6pido que Internet. Las organizacionts corpo-
rativas están adoptando la metodología Internet para proporcionar soluciones a sus usuarios y
clientes. Java tiene todas las cart& para ser una herramienta de inestimable valor en el desarrollo
de aplicaciones corporativas. .,
Para desarrollar un intérprete con Java existe una herramienta que se llama JavaCC.
43
JavaCC nos genera los analizadores léxico y sintádico para la gramática que le introducimos,
en conjunto con !as reglas sintácticas y semánticas. Al analizar el archivo de entrada el JavaCC
genera una serie de archivos en Java donde se encuentran ya traducidos los analizadores !bX¡CO
y sint&ctico. Estos archivos son compilados con el JDK para generar la clase del intérprete
originalmente introducido al JavaCC. Teniendo de esta manera una forma sencilla, rápida Y
clara para la generación de los analizadores léxico y sintáctico que se necesiten en código Java.
El lenguaje Java ofrece también un API(1nterfaz de progamación de aplicaciones) estánddr
para acceso a bases de datos en aplicaciones Java. conocido como JDBC. Para trabajar con
JDBC es necesario tener manejadores JDBC(drivers) que permitan acceder a las distintas bases
de datos. Muchos de estos manejadores JDBC están como software libre en la red de Internet.
Teniendo el manejador JDBC para cada sistema inanejador de base de datos local podrenios
1 establecer la comunicación.
Los sistemas manejadores disponibles con que contamos son :
* SQL Server 6.0 que corre sobre Windows NT
* mSQL 2.3 que corre en una estación de trabajo de Sun.
Son por lo menos dos sistemas manejadores con los que se trabaja para las pruebas
3.3.2 Plataforma de desarrollo
El lenguaje Java puede ejecutarse sobre distintos sistemas operativos (Solaris 2.x, SunOs
4.1.x, Windows 95, Windows NT, Linux, Iris, Aix, Mac, Apple, etc.). Por lo tanto lo que
necesitamos es sólo un dispositivo físico que pueda trabajar con cualquier sistema operativo que
permita ejecutar el JDK del lenguaje Java.
Contamos en Cenidet con una red de estaciones de trabajo de Sun Microsysteins traba-
jando con el sistema operativo Solaris, también con una red de computadords PC donde corren
Windows 95 y NT. Eytas dos redes estAn conectadas a Internet por lo tanto cada nodo tiene su
número IP esto nos sirve para direccionar la máquina.
44
- 1
Necesitamos que los manejadores de bases de datos locales estén trabajando sobre dispositivos
de cómputo a los cuales podamos acceder a través de una dirección IP. Por lo tanto mSQL se
instala en la red de SUN y el SQL Server se instala en una PC que esté trabajando con el sistema
operativo Windows NT. ,
3.4 Análisis de solución I/
Sabemos que contamos con un ambiente heterogéneo en distintas dimensiones de donde se
va a extraer información que semánticamente, para un objetivo global, significa lo mismo.
La información que nos interesa y que están manejando los sistemas de bases de datos
locales ya se encuentra definida para un objetivo específico y no podemos modificarla porque
es una de las características que respetan los sistemas inultibase de datos: la autonomía de los
sistemm manejadores de bases de datos locales.
En la literatura se menciona que se han propuesto varios métodos para lograr un sistema
multibase de datos, de ellos elegimos para el ambiente multibase de datos de este proyecto que
es conciliar un Esquema Glohal'Lógico~ el cual se eligió por lo siguiente: I
Cuando se hace uso de un lenguaje multibase el usuario global no pierde de vista que existen
datos locales interactuando para lograr la transacción global, sistemas manejadores de bases
porque la misma sintaxis del lenguaje le pide al usuario que haga mención de ellos.
Entonces lo que desamos es tener un diccionario de datos global en el cual se w a tener
definido el esquema y la información necesaria para interactuar con las bases de datos locales.
Por lo tanto con la ayuda del esquema global que se va a encontrar definido por el DDL del
sistema va a auxiliar al DML a generar el código de las subtransacciones que se ejecutarán en
los sistemas de base de datos locales que integran al esquema global.
El DML permite al usuario trabajar de la manera más sencilla y solamente debe conocer
las entidades de la base global y hacer instrucciones en SQL estándar.
Al momento de recibir una instrucción el DML empezará a generar el código necesario para
45
que el módulo de manejo de transacciones locales las ejecute, el cual va a estar trabajando con
JDBC de Java.
Cuando genera el código ahí se detectarán los conflictos de heterogeneidad de tipo, nombre
y designación en las entidades y atributos a consultar localmente y es aquí donde se generará el
código correspondiente para lograr el objetivo.
Cuando es conflicto de nombre se soluciona extrayendo la información del diccionario de
datos, cuando es conflicto de tipo se necesita llevar la iiiformación de las bases de datos locales a
unas tablas temporales que contienen la definiciún global y de estii manera ejecutar la operación
global.
Por lo tanto el ambiente cuenta cm1 varios módulos funcionales muy importantes:
* El usuario global va a interactuar con el DML y el DDL.
* La función del DDL es facilitar la construcción de la estruct-ura del esquema global lógico,
creando con esto el diccionario de datos para la base global que se está definiendo.
* El DML permite al usuario global ejecutar operaciones de SELECT, INSERT, DELETE
y UPDATE sobre el esquema de la base de datos global.
* En el momento en que el usuario emita instrucciones al DML la función de éste es, en
primera instancia, verificar si está bien definida la instrucciún, si esto sucede la operación global
se descompondrá en subtransacciones para las bases de datos locales. El código que se genera
es almacenado en un archivo que es enviado al módulo de ejecución de subtransacciones.
* El módulo de ejecución.de subtransacciones dependiendo del código generado puede eje-
cutar dos tipos de bloques para obtener los resultados deseados:
1.- Cuando la ejecución de las subtransacciones tiene un solo sentido del módulo de ejecución
de subtransacciones a las bases de datos locales.
2.- Cuando se envían transacciones a las bases de datos locales y los resultados obtenidos
se utilizan para crear entidades globales temporales y sobre éstas se ejecuta la operación global
que emite el usuario, el resultado si es de una operación de SELECT se muestra al usuario, si la
46
. I. .- -
operación es UPDATE o DELETE con el resultado se envían a ejecutar de nuevo subtransac-
ciones a las bases de datos locales.
La ejecución de subtransacciones utiliza el API JDBC de .Java, por lo tanto la comiinicación
se entabla con cualquier SMBDL para el cual exista un nianejador JDBC de tipod.
3.5 Arquitectura del sistema I
Para lograr el ambiente multibase de datos sabemos que contamos con los siguientes elc
mentos: en primera instancia en un extremo el iisuario global y en el otro extremo los sistemas
manejadores de bases de datos locales heterogéneas y las partes que componen el ambiente multi-
base de datos para lograr la cÓmunicación de la interacción del usuario global a las bases de
datos locales. Las p a r t s que componen el ambiente niultibase de datos son: los intérpretes DDL
y DML con los cuales el usuario global va a tener contacto directo e internamente un manejador
de subtransacciones locales que serán generadas cada vez que el usuario global invoque al DML.
El manejados de subtransacciones a su vez genera módulos temporales que están encargados de
ejecutar las subtransacciones en cada base de datos local y en el SMBD que se define para la
generación de tablas temporales globales. &to se puede apreciar en la figura 3.2.
47
Interfaz para el
usuario Global
Diccionario Global
I Generación de subtransacciones I locales
I 1
Manejador de subtransacciones locales Msql I
JDBC JDBC JDBC
BD. Local BD. Local BD. Local
Figura 3.2: Esquema a bloques de los módulos de nuestro sistema multibase de datos
48
Capítulo 4
DEFINICIÓN DEL ESQUEMA
En este capítulo se describe la construcción del intérprete para el lenguaje de definición de datos
(DDL) de este sistema multibase de datos; cuál es su gramática, las partes que componen el
cuerpo de la gramática; cómo es la información de conexión y de enlace a las bases de datos
locales, y por último cómo se construye el diccionario de datos al momento de ejecutar el DDL
sobre algiina definición de una base de datos global. 1
4.1 Lenguaje de definición de datos
Un sistema de bases de datos está compuesto por la ba.e de datos física y el software
para administrar y manipular la información. La inforniación de la base de datos física est,&
almacenada dependiendo de la estructura que le definieron, esta est,ructura es el esquema de la
base de datos. A su vez el diseño físico de la base de datos es la definición del esquema. El
esquema de la base de datos global se define en el DDL del sistema.
Para el diseño del intérpretedel DDL del ambiente multihase de datos se eligió la estructura
de la gramática del SQL estándar, añadiendo las características necesarias para definir la conexión
y enlace con las bases de datos locales
La persona que interactúa con el DDL no forzosamente tiene que ser el usuario global si no
que es conocido como el administrador de la base de datos(DBA).
49
Para poder utilizar el DDL, el DBA debe tener conocimientos de cómo están definidos los
esquemas de las bases de datos locales que desea integmr para poder formar el esquema global,
de ellos extraerá la siguiente información :
* Identificar las tablas locales que se quieren extraer e integrar para mapear a la
tabla global.
* Definir el esquema global donde va a especificar el nombre de la base de datos
global y las tablas que lo componen.
* Para la base de datos global necesitamos la definición de información de conexión
con un manejador de base de datos para la creación de tablas temporales en ciertas
operaciones del DML.
* Además necesitamos la información para la conexión con la base de datos local, ésta
es un manajador JDBC de tipo 4 que nos permita conectarnos con el manejador de
base de datos local, la dirección URL de la máquina donde se encuentra el manejadar
de base de datos, el nombre de usuario que tiene asignado en el manejador de la base
de datos local y el password que se le asignó como usuario.
Con la información de cada una de las bases de datos locals, puede el DBA definir el
diseño fisico de la base de datos global. Donde cada tabla global representa un conjunto de
tablas locales.
4.2 Gramática del lenguaje de definición de datos
Se dice que un lenguaje es representado por un conjunto de oraciones con estructura bien
definida. Por lo tanto la gramática de un lenguaje es aquélla que define las secuencias de símbolos
válidas de un lenguaje.
Una gramática (G) es un conjunto de elementos que se conocen como: GN, T, C, P,
donde cada elemento a:
50
T : conjunto de símbolos;termiuales.
N : conjunto de símbolos no terminales
S : símbolo inicial, S E N
P : Conjunto de producciones que definen las clases sintácticas.
A continuación se muestran los elementos que forman cada conjunto de la gamática del
'I
1
I1
DDL.
Terniinales:
CREATE, SCHEMA, AUTHORIZATION, TABLE, char, iiint, int, REAL, real, DRIVER, URL, PASSWORD, USERNAME, "A"-"Z", "a"-"z", "0-"9', +, -, otherthing.
No terminales:
start, definitiondatabase, sentence, scheinaauthonzat,ion, schemaelementlist,, schemaele- ment, authorizationidentifier, t,abledefinition, tablelistelement, tablename, tableelement, columdefinition, eolumnnme, datatype, charactertype, exactnumerictype, aproximatenu- merict,ype, identifier, linkdatabaselocal, listdefinitiondatabase: definitiondatnbase, schemaloc, listschenialoc, tabladefinit,ionlocal, t,ablenamegl, listtable,<bindiog, driver, "rl, password, username, name, letter, digit,, intnum, aproxnum, exponent, char, uiut,, int,, flont.
I
Símbolo inicial :
start,
Producciones: I
start ::= definitiondatabase sent,ence sentence ::= CREATE SCHEMA schemriaiithorizat,ion "( '' scheniaelementlist linkdntahaselocal ")" schemsaiithorizat,ion ::= AUTHORIZATION authorizationidentifier schemaelementlist ::= ( schemaelement )+ sdieniaelement ::= tabledefinition authorizationidentifier ::= identifier tabledefinition ::= CREATETABLE tablename "(" tablelist~element " ) " ";" tnblelistelement ::= ( tableelement ''? )+ tablename ::= identifier ' tableelenient ::= columdefinition columdefinition ::= columname dat,atype columname ::= identifier datatype ::= charactertype I exactnumerictype I aproximatenumerictype charactertype ::= char y(" intnum ")"I exactnumerictype ::= uint I int. aproximRteniimerictype ::= float, ident.ifier ::= name
I
1 51
linkdatabaselocal ::= listdefiriit,ioiidatabase listdefinitiondatabace ::= ("(" definitiondatabase schemaloc")" " Y )+ definitiondatabsse ::= driver url username password ccbemaloc ::= CREATE SCHEMA scbemaauthorization "(" listscbemaloc ")" listscbemaloc ::= ( sdiemaloc )+ schemaloi ::= tabladefinitionlocal tabladefinit,ionlocal ::= CREATE TABLE tablename tablenamegl ''Y listtableelemloc
t,ablenamegl ::= identifier listtableelemloc ::= ( tableelement "=" binding "," )+ binding ::= identifier driver ::= ( DRIVER: ( otbertliirig )*) url ::= (URL jdbc: ( otherthing )*) password ::= (PASSWORD: ( otherthing )*) username ::= (USERNAME: ( otherthing )*) name ::= letter ( letkr I digit )* letter ::= [A-Z,a-z] digit ::= [O-91 intnum ::= ([0.9])+ aproxnum ::= ([C-9])+ "." ([0-9])* [ exponent ] I "." ([O-9])+ [exponent ] I ([O-SI)+ [ exponent ] exponent ::= (E I e)[+ I - ] ([0-9])+ char ::= (CHAR I char) uint, ::= (UWTluint) int ::= (INT I int) íioat ::=( "REAL"J"rea1")
"Y' " Y
4.2.1 Información de conexión
La información de conexión es aquélla que necesita el API JDBC para lograr la comuni-
cación con el sistema manejador de base de datos y de esta manera enviar la ejecución de las
subtransacciones
Hay dos lugares de la gramática donde se pide la información para lograr la conexión con
el sistema de base de datos:
* Al momento de definir una base de datos global la misma estructura de la sintaxis
pide que se introduzca la información correspondiente de un manejador de base de
datos donde exista creada una base de datos para que el manejador de transxion-
pueda utilizar al momento de crear tablas globales temporales, como se muestra en
las siguientes estructuras.
52
start, ::= definitiondatabase sentence definitiondatabase ::= idriver url username password
* Por cada base de datob local que se enlaza en la definición se le pide de la misma
manera la información necesaria para poder conectarse con el manajador de base de
datos local, como se muestra a continuación
sentence ::= CREATE SCHEMA scheniaauthorization "( " schemaelementlist linkdatabaselocal ")" linkdatabaselocal ::= listdeñnitiondatabase list,definitiondatabase ::= ("(" definitiondatabase schemaloc ")" "P )+
La informacih de conexión es utilizada por el DML para generar el código para cada
subtransacción que se genera .
El MANEJADOR JDBC es un conjunto de clases que implementan interfaces
JDBC.
El URL es el identificador,de la computadora donde se encuentra el sistema mane-
jador de base de datos con el que se va a interactuar.
El USERNAME es el nombre de usuario que está dado de alta en el sistema de
base de datos para poder trabajar con la base de datos local.
El PASSWORD es la clave asignada al iisuario en el sistema manejador de base
de datos local.
I
4.2.2 Información de enlace con las bases de datos locales !!
AI momento de definir la base de datos global se va a obtener la información para enlazar
las tablas locales y mostrarla en una sola tabla lógica al usuario global.
Esta información de enlace representa las bases de datos locales que contengan tablas que
se identificaron como semánticamente igual a otras, Las tablas locales que se definen pueden ser
una vista de la tabla local original, porque se da el caso que s610 nos interesen unas columna
de la estructura de la tabla para'nuestra tabla global
53 ',
El orden de las columnas locales debe introducirse en el mismo orden en que se encuentran
declaradas las columnas globales de esa tabla. Ai momento de declarar las tablas locales se pide
que se introduzca enseguida e! nombre de la tabla mapeo, que identifica a la tabla global a la
que se va a transferir la información, las columnas de la tablas después de su definición vienen
seguidas por el signo igual ( = ) y después el nombre de la columna global al que semánticainente
representan.
Cuando se introduce la información al no terminal <tablenamegl > debe corresponder a
un nombre de las tablas que pertenecen al esquema de la base de datos global. De lo contrario
el DDL emitirá un mensaje de error. Otro mensaje de error que puede producirse debido a la
información de este no terminal es, que por cada base de datos loca! a integrar en el esquema
global sólo debe existir una tabla local que mapee a esta tabla global, dicho de otra manera, no
pueden existir dos tablas de una misma base de datos local mapeando a !a misma tabla global.
tabladefinitionlocal ::= CREATE TABLE tablename tablenamegl ” (“ listtableelemloc
tablenamegl ::= identifier > > >I 3, , 1 ;!
En el contenido de la definición de las tablas locales se introduce el nombre de la columna
local más su tipo de dato siguiéndole el signo igual y un símbolo no terminal conocido como
<binding>, en este sínibolo se introducirá el nombre de la columna global que va a representar el
contenido de la información semánticamente igual a la de esta columna local. Está información
que se introduce se verifica que sea igual a un nombre de las columnas de la tabla global a la que
se mapea, y también se prueba que no existan dos columnas de la misma tabla local mapeando
a la misma columna global.
listtableelemloc ::= ( tableelement ”=” binding ”,” )+
4.3 Generación del diccionario de datos
En e! momento en que e! intérprete del DDL de nuestro ambiente global identifica que la
entrada analizada está bien definida, según su gramática, empieza a generar el diccionario de
54
I datos de la siguiente manera:
Genera das archivos principales con el nombre de la base de datos global uno con la atención
.bd, y otro con la exteiición dd.
a).- El archivo baseglobaLbd l contiene los nombres de las tablas globales y con ellos
se va a accesar a la información de las tablas globales.
b).- En el archivo baseglobaLdd se encuentra en primera instancia la información
del üXL, driver, username y el password para trabajar algunas operaciones globales.
le siguen las nombres de las bases de datos locales y con ellos se podra acccsar a la
información del diccionario de las bases de datos locales.
/I
I
I
c).- Con los nombres de lad tablas globales introducidas en el archivo baseglobal.dd
se le añade como extensión el nombre de la base de datos global, obteniendo un
nombre de archivo tablaglobal.baseglobal y se introduce en ese archivo el nombre de
las columnas que pertenecen a esa tabla global con su respectivo tipo de dato. '!
d),. Se toman los nombres de las bases de datos locales introducidos en el archivo
basegloba1,dd también generan igual dos archivos baselocal.hd y baselocal.dd. 11
e).- En el archivo baselocal.bd se encuentran los nombres de las tablas de la base de
datos local que se quieren integrar para formar el contenido de las tablas globales. 18
', f),- El archivo haselocal.dd contiene la información correspondiente para establecer
la conexión con el sistema rnanejador de la base de datos local que es: su driver, el
url, el password y el username
g).- Con el nombre de las tablas de datos locales que se introducen en el archivo
baselocal.bd se generan archivos con el nombre de la tabla local con la extensión que
es el nomhre de la base de datos local a la que pertenecen, el nombre del archivo que
se obtiene es tahlalocal.baseloca1
I1
55
9 Nombre tabla gIoba1,Nombre base global I
Nombre base local. bd
Nombre base local .dd -
- - -
Nombre base local bd
base local dd -
I . .
Nombre tabla local Nombre base local -
7 Nombre tabla local.Nombre base local
Nombre base local bd
Nombre base local dd -
Figura 4.1: Esquema de los archivos que se crean al definir el diccionario de datos
Nombre tabla IocalNombre base local
Nombre tabla local Nombre base local
- - L 7
I
h): En los archivos tablalocal.baselocal se encuentra almacenado, en primera -
instancia, el nombre de la tabla global a la que mapeaii, enseguida el nombre de
las columnas locales con su tipo seguido con el signo igual (=) y después el nombre
de la columna global al que representa la misma información. Un ejemplo de como
se genera el diccionario de datos se puede ver en la figura 4.1
56
! Capítulo 5
Definición de operaciones globales
En este capítulo se hace mención de cómo se creó el intérprete para el DML, y cuál es la gramática
del intérprete. El usuario global tiene contacto con este intérprete cuando introduce como
entrada un archivo de transacciones globales, donde la función del intérprete del DML es analizar
y descomponer las transaccionl del usuario global en subtransacciones locales generando código
de transacciones para las bases de datos locales.
5.1 Lenguaje de manipulación de datos
En el ambiente multibase be datos se necesita de un lenguaje para el que le permita al
usuario hacer operaciones sobre la base global definida. Ast como existe un lenguaje para definir
el esquema de los datos en una base de datos, también existe lenguaje de manipulación de datos
(DML) que permite emitir y e j l u t a r transacciones sobre la información contenida en la base de
datos.
El intérprete para el DML en este ambiente multibase de datos tiene definida una sintaxis
donde el usuario global nada más trabaja con el esquema de la base global sin saber que existe
una serie de bases de datos locales que le brindan la información de su transacciún.
I
El usuario global sólo edita un archivo que contenga operaciones de SELECT, INSERT,
DELETE y UPDATE sobre una base de datos global, el intérprete del DML lo analiza, verifica
que se encuentre definido segiín el diccionario de datos de la base de datos global, si el análisis
fue exitoso, el intérprete del DML genera iin archivo de salida que contiene laq subtransacciones
locales que se necesitan para lograr las operaciones globales emitidas por el usuario. I
! 57
5.2 Gramática del lenguaje de manipulaci6n de datos
Se dice que un lenguaje es reprecentado por un conjunto de oraciones con estrudura bien
definida. Por lo tanto la gramática de un lenguaje es aquélla que define las secuencias de símbolos
válidas de un lenguaje
TJna gramática (G) es un conjunto de elenlentas que se conocen como: GN! T, S, P,
donde cada elemento es:
T : conjunto de símbolos terminales.
N : conjunto de símbolos no terminales.
S : símbolo inicial, S E N
P : Conjunto de producciones que definen las clases sintácticas.
A continuación se muestran los elementos que forman cada conjunto de la gramática del
DML
Terminales:
FROM, INTO, DELETE, WHERE, INSERT, VALUES, SELECT, NULL, UPDATE, SET, AND, OR, ALL; DISSINCT, =, <>, <, >, <=, >=,letras, digitos, e, E.
No Terminales:
start, uselis, database, Isstm, statemenl, deletestm, optwhereclause, whereclause, iusert- stm, optcolumeommalist, columcommalist, valuesorspec, insertatonicoinmelist, insertntom, at,om, literal, number, updat,estni, assignmentcommalist, assignment , scslsrexp, columnref, selectstm, optalldistinc, selection, scalarexpcommaüst, tableexp, hamclause, tablerefeom- malist, searclicond, value, identifier, table, name, letter, digit, iutnum, aproxnum, exponent, chain, compare.
Símbolo inicio:
start
Producciones:
start ::= uselis uselis ::= database Isstm database ::= identifier Icstni ::= ( statement )+ statement ::= ( deletestm I selectstm I insertstm I updetestm )
58
deletestm ::= DELETk FROM table [ optwhereclause] ";» opt,whereclause ::E whereclause whereclause ::= WHERE searchcand insertstm ::= INSERT, INTO table [ optcolumcommaüst ] valuesorspec ''r optcolumcommaiist ::= "(" co~umcomma~ist ")" columcommalist, ::= columnref ( "," columiiref )* vnluesorspec ::= VALUES "(" insertatomcommalist ")" insert,atomcommalist ::= insert,atom ( "1>) insertatom )* insertatom ::= ( atom I NULL ) at,om ::= literal literal ::= ( inhum I aproxnum I tihain ) number ::= ( intniim I aproxnum I name ) updatedm ::= UPDATE table SET assignmentconimalist [ optwhereclause I";" assignmentcominitlist ::=, assignment (" ; assignment )* assignment ::= columnref "=" ( scalarexp I NULL) scalarexp ::=( atom I "(",scelarexp ")" I columnref) columnref ::= name[ ".",,.name ] selectstm ::= SELECT [ optalldist,inc ] selection table-exp ";" optalldistinc ::= ( ALL 1 DISTINCT) selection ::= ( columcommalict~ I "*" ) scalarexpcommaiict ::= scalarexp ("Y scalarexp )* tableexp ::= fromclause [ optwhereclause ] fromclanse ::= FROM tablerefcommalist tablerefcommalist ::= table ("; table )* searchcond ::= columnref compare value ( ( AND I OR ) columnref compare value)' value ::= ( literal I columnref) identifier ::= name table ::= name name ::= letter( leter 1 digit)* letter ::= [A-Z,a-z] digit ::= [C-Q] intnum ::= ([C-Q])+ aproxiium ::= ([C-9])+ 'I." ([0-9])* [ exponent 1 I 'I." ( [ O - Q ] ) + [exponent 1 I ([C-Ql)+
[ exponent ] exponent. ::= ( E I e ) [+,-I ([0-91)+ compare := (= 1 <>I < ( > I <= I >=) chain ::= '(otherthing)* ',,
I
I
I
5.3 Generación de código de transacciones locales
El intérprete del lenguaje de inanipulación de datos analiza el archivo de transacciones
editadas por el usuario de la bde de datos global que, en primera instancia, en este archivo
el usuario especificó el nombre de la base de datos global seguido por las transacciones que
pueden ser SELECT, INSERT, DELETE y UPDATE. Si se obtiene un análisis exitoso se inicia
! 59
la descomposición de cada operación global en subtranswciona que serán ejecutadas en las
bases de datos locales para obtener los resultados deseados por el usuario global.
Dependiendo de la heterogéneidad presente entre las tablas locales y la definición de la tabla
global se generan dos tipos de bloques de código éstos son:
1.- Código directo sobre las tablas de las bases de datos local- al que llamaremos código
tipo 1, ver figura 5.1.
Generación de 8!!&mwxh~s locales
Controlador dehilospara JDBC
Enuna tbo 1 dimcmn.
BD. Local BD. Local BD. Local
Figura 5.1: Dirección de la generación de código tipo 1.
2.- Código que lleva el contenido de las tablas locales a tablas globales temporales, sobre
estas tablas se ejecuta la operación global, y con el resultado se trabaja o hacia el usuario global
(SELECT ver figura 5.2) o de nuevo a emitir subtransacciones a las bases de datos locales
(DELETE y UPDATE ver figura 5.3). A éste código lo llamaremos de tipo 2.
Cuando se habla de tablas globales temporales en el código de tipo 2, éstas se están creando
en el sistema manejador definido para la base de datos global, con su respectiva información de
conexión.
Al momento de generar código por cada subtransacción se emite primero un renglón con la
información necesaria para lograr la conexión con el sistema manejador de base de datos, ya sea
el local o el que se asignó a la base de datos global.
60
CMig, tpo 2 para
SELECT
It
Figura 5.2: Dirección de la generación de código tipo 2 para una operación SELECT global.
I
Coneoiador de 4 4
DELETE d i m c m m .
BD. Local BD. Local UPMTE
Figura 5.3: Dirección de la generación de código tipo 2 para una operación DELETE o UPDATE
con iiicompatibilidad de tipos en'la cláusula WHERE I
61
Todas las subtransacciones que se generan cuentan con un renglón de inforniación para la
conexión con el inanejador de la base de datos y el otro renglón es la transacción a ejecutarse.
El renglón de información de conexión está formado por cuatro cadenas que son: DRIVER,
URL, USERNAME y el PASSWORD que se tiene definido para el sistema manejador al que se
le va a enviar la transacción.
Para facilitar la coniprensión de los ejemplos de generación de código, éstos se basarán en
el esquema global que se encuentra en el apéndice A archivo 1.
5.3.1 Código para la operación SELECT
Cuando se genera el c6digo para la transacción SELECT el bloque de código es de tipo 2 ,
es llevar la información de las tablas locales quc se encuentran mapeando las tabla(s) global(es)
sobre la que se emite la consulta elaborada por el usuario global, a tablas teniporales donde
los conflictos semánticos serán eliminados. El pseudocódigo para la generación de código de la
operación SELECT se encuentra en el apéndice C archivo 1.
Los pasos que se siguen cuando se encuentra analizando una operación SELECT son los
siguientes:
1.- Todo el código a generar está encerrado entre dos banderas que se identifican con el
carácter 1.
2.- Durante el análisis del archivo se elaboró una lista que contiene las tablas del FROM
del SELECT original.
3.- Se recorre la lista y por cada tabla encontrada se genera el siguiente código:
3a.-Se genera un CREATE de la tabla global temporal en el manejador asignado a la base
de datos global.
3b.-Hace una búsqueda en cada base de datos local enlazada a la base global. y examina
las tablas locales para ver si alguna de ellas est6 mapeando a la tabla global, esto lo sabe al
comparar el nombre de la tabla global temporal para la que se va a generar el CREATE contra
62
el nombre almacenado en el nc-terminal <tablenamegl>, si encuentra una tabla local genera el
siguiente código. I
3c.-Un SELECT donde &e extraiga el contenido de la tabla según las columnas definidas
en el esquema global, ya que' esto puede representar una vista de la tabla como se encuentra
definida originalmente en la base de datos local.
3d.-EI resiiltado que se obtendrá en el momento de ejecutar e1,SELECT se almacenará en
un archivo. Cada renglón del archivo representa un registro de la tabla local. /,
3e.-EI siguiente código a generar es un INSERT a la tabla global temporal que se ejecutará
el número de veces que sea igual a la cantidad de registros que se encuentren en el archivo
resultante del SELECT anterior.
El paso número tres lo va a ejecutar por cada tabla global que encuentre en la lista del
FROM y el código que se genera cada vez que se ejecuta este paso es encerrado entre dos
banderas que se identifican con' los caracteres 1.1.
I
I
4.- Despúes de generar código para la creación y llenado de las tablas globales teniporales
se emite la operación de SELECT que el usuario elaboró originalmente,
5.- El resultado que se obkenga será almacenado en un archivo y se mostrará al usuario
global en un browser. i
6.- Por cada tabla global temporal qiie se creó en el paso 3 se generartí un DROP de cada
tabla. ! Ejemplo del código que se genera para un SELECT con la siguiente operación global:
SELECT TABLAZ.nombr& TABI,Al.nombrecli FR.OM TABLAZ, TABLA1 WHER.E TABLA2.numerocli = TABLAl.numerocli; 1 1.1 coni.imaginary.sql.msql.MsqlDriver jdbc:n1sqi://148.208.9Z.l04: Ill4/con1pnny aclmal aclmal Create table TABLA2 ( nombrepro char(lO), nombrecli char(lO), numerocli char(l5), numeropro int ) com.imaginary.sql.msql,MqlDriver jdbc:msql//148.208.92.104~1114/compauy aclmal aclmal select prov, cli, cc, cp from'almacen corn.im~ginary.sql.msql.MsqlDriver jdbc:msq1//148.208.92.104:1114/~onipauy acha l aclmal Iiisert, into TABLA2 valti& ( ' array[O] ? , ' array[l] ' , ' array[Z] ' , array[3] )
! I
connect.microsoSt.MicrosoftDriver jdbc:ff-microsoft://l48.208.92.82:1433/PRUEBA LUCERO LUCERO select proveedor, cliente, clavecli, clavepro from bodega com.imaginary.sq1.msql.MsqlDriver jdbc:insql://148.208.92.104 1114/wmpany aclmal aclmal Insert into TABLA2 values ( ’ array[O] ’ , ’ array[l] ’ , ’ array[2] ’ , array[3] ) 1.1 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Create table TABLAl ( nnmbrecli char(lO), numerocli cbar(i5), tipocli int, ) com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.20X.92.104:1114/wrnpany aclmal aclmsl select nombre, numero, tipo from proye com.imaginary.sql.msql.MsqlDriver jdhc:msq1://14X.208.92.104: 1114/wmpany aclmal aclmal Insert into TABLAl values ( ’ array[O] ’ , ’ array[l] ’ , array[2] ) wnnect,.microsoSt.MicrosoftDriver jdbc:ff-microsoft://148.208.92.82:1433/PRUEBA LUCERO LUCERO select nom, num, tipo from pro1 com.imaginary.cql.msql.MsqlDriver jdbc:n1sql://148.208.92.104:11l4/company aclmal aclmal Insert into TABLAl values ( ’ array[O] ’ ~ ’ arrny[l] 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msql//148.208.92.104:1114/wmpany aclmal aclmal SELECT TABLA2.nombrecii, TABLAl .nombredi FROM TABLA2, TABLA1 WHERE TABLA2.numerocli =TABLAl.numerocli com.imaginary.sql.msql.Msq1Driver jdbc:msqi://148.208.92.104:1114/company aclmal nclmal Drop table TABLA2 com.imaginary.sql.insql.Msq1Driver jdbc:insql//148.208.92.104:1114/campany aclmal aclmal Drop table TABLAl
, array[2] )
I
5.3.2 Código para la operación INSERT
En la transacción INSERT el código que se genera es de tipo 1, sólo se emitirá ejecución de
transacciones hacia las bases de datos locales. En el INSERT sólo existe una tabla global sobre
la que se va ejecutar la transacción, el código a generar es el siguiente:
1.- Todo el código a gcnerar es encerrado entre dos banderas identificadas con el carácter 2.
2.- Se hace un recorrido en cada base de datos local enlazada a la base global, y se examina
en las tablas locales para ver si alguna de ellas está mapeando a la tabla global, esto lo sabe-
mos al comparar el nombre de la tabla global contra el nombre almacenado en el no-terminal
<tablenamegl>, si se encuentra una tabla local geiierá el siguiente código.
* Se emite una operación de INSERT hacia la tabla local, con las datos a insertar formatea-
dos a los tipos de datos de la tabla local.
64
Entonces se generará11 tantas subtransacciones por cada base de datos local que contenga
una tabla local mapeando a la tabla global de la transacción INSERT emitida por el &ario
global. Ejemplo de una operación INSERT:
INSERT INTO TABLA2 (numeropro, numerodi, nombrepro, nombrecli) VALUES ( 90, ’567’,’provl’,’cli4’)1 2 coni.imnginar~.sql.mcqI.MsqlDriver jdbc:msql://148.208.92.104 lll4/company adma1 acimal insert int.o almacen ( cp, cc: prov, di) values ( ‘go’, ,567 , ’provl’: ‘di& ) <nunect.microsoft.MicrosoftD~v~~ jdbc:ff-mierosoft,://148.208.92.82:1433/PR,UEBA LUCERO LUCERO insert into bodcga(clavepro, clavecli, proveedor, cliente) values (90, 567, ’provl’, ‘cli4’ ) 2
El pseudocódigo para la generación de código de la operación INSERT se encuentra en el
apéndice C archivo 2.
5.3.3 Código para la operación DELETE
Existen dos versiones de DELETE con cláusula WHERE o nada m& borrado de la tabla
completa.
Cuando es borrado de la tabla completa sin cláusula WHERE se genera código del tipo 1.
Cuando la operación DELETE contiene la clausula WHERE primero se verifica si coinciden los
tipos de datos de las columnas encontradas en la cláusula it7HERE entre las definiciones de la
tabla global y la tabla local, si es así se genera codigo del tipo 1: de lo contrario se genera código
del tipo 2.
Por lo aiiterior cabe deducir que cuando el usuario global emita una operación DELETE
con cláusula WHERE puede existir generación de los dos tipos de códigos porque, puede darse el
caso, que para una base local los tipos de los datos de la tabla local coincidan con los de la tabla
global, y en otra base de datos local suceda lo contrario. El pseudocódigo para la .generación de
c a i g o de Is operación DELETE se encueiit,ra en el apéndice C archivo 3. Los pasos a seguir en
la generación de código son los siguiente:
65
1.- Todo el código a generar se encontrará encerrado entre dos banderas que se identifican
con el carácter 3
2.- En este paso se analiza si la operación DELETE contiene la cláusula WHERE, si no la
contiene va a generar el código del paso 3, de lo contrario pasaremos al paso 4
3.- Corno nada mác existe una tabla global a la que se va a afectar con la operación DELETE
se hace un recorrido en cada base de datos local enlazada a la base global, y se examina en
las tablas locales para ver si alguna de ellas está rnapeando a la tabla global, esto lo sabe-
mos al comparar el nombre de la tabla global contra el nombre almacenado en el no-terminal
<tablenamegl>, si se encuentra una tabla local generá el siguiente código.
* Se emite una operación de DELETE hacia la tabla local.
Entonces se generarán subtransacciones por cada base de datos local que contenga una
tabla local mapeando a la tabla global de la 1,ransacción DELETE emitida por el usuario global,
y cada una de estas subtransacciones ea encerrada entre las banderas 3.1. El paso número 3 se
ejecutará por cada base de datos local que contenga una tabla local que mapea a la tabla global
de la transacción DELETE. Ejemplo de una subtransacción de tipo 3.1 sin cláusula WHERE.
DELETE FROM TABLAZ; 3 3.1 com.imaginary.sql.msql.MsqlDriver jdbc:insql: //i 48.208.92.104:lll4/company aclmal aclmal DELETE FROM almacen 3.1 3.1 connect.microsoft.MicrosoftDriver jdbc:ff-microsoft://148.208.92.82:1433/PRUEBA LUCERO LUCERO DELETE FROM bodega 3.1 3
4.- Como ya sabemos que existe la cláusula WHERE entonces lo que signe es comparar los
tipos de datos de las columnas que couiponen la condición del WHERE de la tabla global contra
los de la tabla local encontada en las bases de datos locales
66
Los ejemplos de generación de código para una operación DELETE se basan en la siguiente
operación global:
DELETE FROM TABLA2 WHERE numeroprn = 8;
4a. Se hace un recorrido en cada base de datos local enlazada a la base global, y se
examina en las tablas locales para ver si alguna de ellas está mapeando a la tabla global, esto lo
sabemos al comparar el nombre de la tabla global contra el nombre almacenado en el no-terminal
<tahlenamegl>, se hace el siguiente análisis:
- Se comparan los tipos de datos que componen la condición del WHERE de la tabla global
contra los de la tabla local si son iguales continúa en el paso 5, de lo contrario vamos al paso 6 .
5. - Se genera una transacciún de DELETE hacia la tabla local y se sustituyen los nombres
de las columnas que componen la condición WIiERJ? por los nombres equivalentes de la tabla
local. E1 código generado en este paso es encerrado entre las banderas 3.1. Si no se han recorrido
todas las bases de datos locales el control de generación de código retorna ai paso 4a. para seguir
buscando en otra base de datos local una tabla local que mapee a la tabla global. Ejemplo de
una subtraiisacción de tipo 3.1 con WHERE.
3.1 connect.niicrnsnft.MicrosnftDriver jdhc:ff-microinft://148.208.92.82:1433/PRUEBA LUCERO LUCERO DELETE FROM bodega where clavepro =8 3.1
6.- Cuando llegamos a este paso sabemos que el código a generar va a ser de tipo 2 para
ejecut,ar la operación sobre esa tabla en la base de datos local, se va a generar el siguiente código:
* El código que se genera en este paso se encuentra encerrado entre las banderas 3.2.
* Como necesitamos extraer el contenido de la tabla local y formatearlo al de la tabla
global para ejecutar la operación DELETE se genera una parte de código como si estuviéramos
trabajando con la generación de código para una transacción de SELECT global.
6a.- Primero se genera un CREATE de la tabla global temporal en el manejador asignado
G7
a la base de datos global, el nombre de la tabla va a ser el de la tabla global más el de la base
de datos local, pero las columnas siguen siendo las mismas de la tabla global.
Gb.- Se genera código para ejecutar un SELECT donde se extraiga el contenido de la tabla
según las columnas definidas en el esquema global, ya que esto puede representar una vista de
la tabla como se encuentra definida originalmente en la base de datos local.
Gc.- El resultado que se obtenga cuando se ejecute el SELECT se almaceiiará en un archivo.
Cada renglón del archivo representwá un registro de la tabla local.
6d.- El siguiente código a generar es un INSERT a la tabla global temporal que se ejecutará
el número de veces que sea igual a la cantidad de registros que se almacenen en el archivo
resultante del SELECT anterior.
El código generado entre el paso 6a al paso 6d es encerrado entre las banderas 1.1.
6e.- Después que se tiene generado el código para la creación y llenado de la tabla global
temporal con la inforniación de la tabla local, se generará código para una transacción SELECT
con el WHER,E del DELETE emitido por el usuario global.
6f.- El resultado del SELECT anterior será almacenado en un archivo, donde cada renglón
será un registro de la tabla que cumple con la condición del WHERE, por lo tanto son los
registros a eliminar de la tabla local.
Gg.- Por la tabla global teniporal que se creó en el paso 6a se genera un DROP de esa tabla.
Gh.- Por último se genera una subtransacción DELETE hacia la tabla local que se ejecutará
el número de veces que sea igual a la cantidad de registros que se almacenen en el archivo
resultaiite del SELECT anterior. La cláusula WHERE del DELETE va a estar formada con una
condición AND de todas las columnas definidas en la tabla local con los valore que se obtengan
en cada registro del archivo, de esta manera aseguramos que s6io se eliminarán los registros que
cumplieron la condición del DELETE emitaida por el usuario global.
si no se han recorrido todas las bases de datos locales el control de generación de código
retorna al paso 4a. para seguir buscando una tabla local que mapee a la tabla global. Ejemplo
68
de una siibtransacción de tipo 3.2.
3.2 1.1 com.imagiriary.sql.msql.MsqlDriver jdbe:msql://148.208.92.l04: 1114/company adma1 aclmal Create table TABLA2COMPANY(nombrepro char(lO), nombrecli ch~r(10), numerocli char(i5), numeropro int) com.imaginnry.sql.msql.Msq1Driver jdbc:msql://148.208.92.104:1ll4/company aclmal sclmel select prov, cli, cc, cp’from abnacen com.imaginary.sq1.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aelmal insert into TABLA2COMPANY values(’ array[O] ’ , ’ array[l] ’ , ’ array[2] ’ , array[3]) 1.1 com.imaginary.sql.msql.Msq1Driver jdbc:msqi://I48.208.92.104:1114/company aclmal aclmal SELECT DISTINCT nombrepro, nombrecli, numerodi, numeropro from TABLA2COMPANY where numeropro =8 com.imaginary.sql.msq1.MsqlDriver jdbc:msq1//148.208.92.104:1114/~ompany aclmal aclmal Drop table TABLAZCOMPANY com.imaginary.sql.msq1.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal nclmal DELETE FROM almacen WHERE prov = ’ array[O] ’ AND cli = ’ array[l] ’ AND cc = ’ array[2] ’ AND cp = ‘ arrsy[3] ’ 3.2
5.3.4 Código para la operación UPDATE
Existen dos versiones de UPDATE uno con cláusula WHERE o nada más niodificado de
coluiniias en la tabla.
Cuando es modificado de columnas en la tabla sin cláusula WHERE se genera código del
tipo 1. Cuando la operación UPDATE contiene la cláusula WHTjRE primero se verifica si
coinciden los tipos de datos de las columnas encontradas en la condición de la cláusula WHERE
entre las definiciones de la tabla global y la tabla local, si es así se genera código del tipo 1, de
lo contrario se genera código del tipo 2
Por lo anterior cabe deducir que cuando el usuario global emita una operación UPDATE
con cláusula WHERE puede existir generación de los dos tipos de códigos, porque puede darse el
caso que para una base local los tipos de los datos de la tabla local coincidan con los de la tabla
global, y en otra base de datos local suceda lo contario. El pseudocódigo para la generación de
código de la operación UPDATE se encuentra en el apéndice C archivo 4. Los pasos a seguir en
la generación de código son los siguiente:
, ’ 69
El código a generar es el siguiente:
1.- Todo el código a generar se encontrará encerrado entre dos banderas que se identifican
con el carácter 4
2.- En este paso se analiza si la operación UPDATE contiene la cláusula WHERE, si no la
contiene va a generar el c6digo del paso 3, de lo contrario pasaremos al paso 4.
3.- Como nada más existe una tabla global a la que se va a afectar con la operación W-
DATE se hace un recorrido en cada base de datos local enlazada a la base global, y se examina
en las tablas locales para ver si alguna de ellas está mapeando a la tabla global, esto lo sabe-
mos al comparar el nombre de la tabla global contra el nombre almacenado en el no-terminal
<tablenaniegl>, si se encuentra una tabla local genera el siguiente código
* Se emite una operación de UPDATE hacia la tabla local verificando que las columnas de
la cláiisula SET tengan el nombre de las columnas locales correspondiente a los nombres de las
columnas globales, además si el tipo de datos no coinciden se modifica el formato de los valores
a asignar.
Entonces se generarán subtransacciones por cada base de datos local que contenga una
tabla local mapeando a la tabla global de la transacción UPDATE emitida por el usuario global,
y cada una de estas subtransacciones es encerrada entre las banderas 4.1. El paso número 3 se
ejecutará por cada base de datos local que contenga una tabla local que mapea a la tabla global
de la transacción UPDATE. Ejemplo de una subtransacción de tipo 4.1 sin cláusula WHERE.
UPDATE TABLA2 SET nu~neropro = 9; 4 4.1 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclnial aclmal Update almacen set ep = '9' 4.1 4.1 connect.microsoft.MicrosoftDriver jdbc:ñ-microsoft://l48.208.92.82:1433/PRUEBA LUCERO LUCERO Updat,e bodega set clavepro = 9 4.1 4
70
4.- Como ya sabemos que existe la cláusula WHER.E entonccs lo que queda por verificar es
comparar los t,ipos de dato de las columnas que componen la condición del WHERE de la tabla
global contra los de la tabla local encontrada en las bases de datos locales.
Los ejemplos de generación de código para una operación DELETE se basan en la siguiente
operación global:
UPDATE TABLA1 SET numeroili = '78', nombrecli = 'TOMAS' WHERE tipoclk8;
4a. Se hace un recorrido en cada base de datos local enlazada a la base global, y se
examina en las tablas locales para ver si alguna de ellas está mapeando a la tabla global, esto lo
sabemos al comparar el nombre de la tabla global contra el nombre almacenado en el no-terminal
<tahlenamegl>, se hace el siguiente análisis:
- Se comparan los tipos de datos que componen la condición del WHERE de la tabla global
contra los de la tabla local si son iguales continúa en el paso 5 , de lo contrario vamos al paso 6.
5.- Se genera una transacción de UPDATE hacia la tabla local y se sustituyen los nombres
de las columnas que componen la condición WHERE por los nombres equivalentes de la tabla
local, además se verifica que las columnas de la cláusula SET tengan el nombre de las columnas
locales correspondiente a los nombres de las columnas globales, además si el tipo de los datos
no coincide se modifica el formato de los valores a asignar. El código generado en este paso
es encerrado entre las banderas 4.1. Si no se han recorrido todas las bases de datos locales el
control de generación de código retorna al paso 4a para seguir buscando una tabla local que
mapee a la tabla global. Ejemplo de una subtransacción de tipo 4.1 con WHERE.
4.1 connect.microsoft MicrosoftDriver jdbc:ff-microsoft//148.208.92.82:1433/PRüEBA LUCERO LUCERO Update pro1 set num = 78, nom = 'TOMAS' where tipo =E 4.1
6.- Cuando llegamos a este paso sabemos que el c6digo a generar va a ser de tipo 2 para
ejecutar la operación sobre esa tabla en la base de datos local, se va a generar el siguiente código:
71
* El código que se genera en este paso se encuentra encerrado entre las banderas 4.2.
* Como necesitamos extraer el contenido de la tabla local y formatearlo al de la tabla
global para ejecutar la operación UPDATE se genera una parte de código como si estuviéramos
trabajando con la generación de código para una transacción de SELECT global.
6a.- Primero se genera un CREATE de la tabla global temporal en el manejador asignado
a la base de datos global, el nombre de la tabla va a ser el de la tabla global más el de la base
de datos local, pero las columnas siguen siendo las mismas de la tabla global.
6b.- Se genera código para ejecutar un SELECT donde se extraiga el contenido de la tabla
según las columnas definidas en el esquema, ya que esto puede representar una vista de la tabla
como se encuentra definida originalmente en la base de datos local.
6c.- El resultado que se obtenga cuando se ejecute el SELECT se almacenará en un archivo.
Cada renglón del archivo representará un registro de la tabla local.
6d.- El siguiente código a generar es un INSERT a la tabla global temporal que se ejecutará
el número de veces que sea igual a la cantidad de registros que se almacenen en el archivo
resultante del SELECT anterior.
El código generado entre el paso 6a al paso 6d es encerrado entre las banderas 1.1.
6e:Después que se tiene generado el código para la creación y llenado de la tabla global
temporal con la información de la tabla local, se generará código para una transacción SELECT
con el WHERE del WDATE emitido por el usuario global.
6f.- El resultado del SELECT anterior será almacenado en un archivo, donde cada renglón
es un registro de la tabla qiie cumple con la condición del WHERE, por lo tanto son los registros
a modificar de la tabla local.
6g.- Por la tabla global temporal que se creó en el paso 6a se genera un DROP de la tabla.
6h.- De nuevo se genera un CREATE de la tabla global temporal en el manejador asignado
a la base de datos global, el nombre de la tabla va a ser el de la tabla global más el de la base
de datos local, pero las columnas siguen siendo las mismas de la tabla global.
72
' 6i.- El siguiente código a generar es un INSERT a la tabla global temporal que se ejecutará
el número de veces que sea igual a la cantidad de registros que conteiiga el archivo resultante del
SELECT anterior, donde la información a insertar es aquella que nada más se puede modificar
según la condición del UPDATE original.
6j.- Después de que se generó código para la creación y llenado de la tabla con la información
que sólo es candidata a modificar, se genera código de un UPDATE hacia esta tabla temporal
pero con la cláusula SET del UPDATE original.
6k: Por lo tanto la información de esta última tabla se encontrará con los valores que desea
el usuario global a1 emitir el UPDATE. Entonces el siguiente código a generar es un SELECT
sobre esta tabla.
61.- El resultado de cuando se ejecute el SELECT anterior será almacenado en otro archivo,
entonces contaremos con dos archivos, el que contiene la información de la tabla antes de ser
modificada y otro con la información despub de modificarla.
6n1.- Por último se genera una subtransacción UPDATE hacia la tabla local que se ejecutará
el número de veces que sea igual a la cantidad de registros en el archivo resultante del SELECT
anterior. La cláusula WHERE del DELETE va a formar una condición AND con todas las
columnas definidas de la tabla local con los valores obtenidos en cada registro del archivo que
contiene los valores antes de modificarlos, de esta manera aseguramos que sólo se modificarán
los registros que cumplieron la condición del UPDATE emitido por el usuario global y en la
cláusula SET los valores que se le asignarán a cada columna los registros que se encuentran en
el archivo que cmtiene los datas ya modificados.
Si no se han recorrido todas las bases de datos locales el control de generación de código
retorna al paso 4 s para seguir buscando una tabla local que niapee a la tabla global. Ejemplo
de una subtransacción de tipo 4.2.
4 2 1.1 cnm.imagiusry.sql.m~~l.McqlDriver jdhc:mcql://148.208.92.1041114/cnmpany aclmal aclmal
73
Create table TABLAlCOMPANY(nombrec1i &ar(lO), numerocli &ar(l5), tipocli int) com.imaginary.sql.mcql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal select nombre, numero, tipo from proye com.imaginary.sql.msql.McqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Insert into TABLAlCOMPANY values( ’ array[O] ’ , ’ array[l] ’ , array[2] ) 1.1 com.imaginary.cql.msql.MsqlDriver jdbc:msq1://148.208.92.l04:1114/coinpany aclmal ailmal SELECT DISTINCT nombrecli, numerodi, tipodi from TABLAlCOMPANY where tipocii =8 com.imaginary.sql,nisql.MaqlDriver jdbc:msql://148.208.92.104:11i4/compeny aclmal aclmal Drop table TABLAlCOMPANY iom.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.1041114/company aclmal aclnial Create table TABLAlCOMPANY(nombrec1i cbar(iO), numerocli char(l5), tipocli int) com.imaginary.sql.msql.MsqlDrivrr jdbc:msql://148.208.92.1041114/company aclmal aclmal Insert into TABLAlCOMPANY values ( ’ array[O] ’ , ’ array111 ’ , array[2] ) com.imaginary.sql.rnsql.MsqlDriver jdbc:msql//148.208.92.104:1114/company aclmal aclmal UPDATE TABLAlCOMPANY SET numerocli=’78‘, nombrecli=’TOMAS’ com.imaginary.sql.~nsql.MsqlDriver jdbc:msql://148.208.92.104: 1114/company aclmal aclmal select nombrecli, numerocli, tipocli from TABLAlCOMPANY com.imaginary.sql.msql.MsqlDriver jdbc:msq~//148.208.92.104 1114/company aclmal aclmal Update pmye set nombre = ’ array[O] ’ , numero = ‘ array[l] ’ , tipo = ’ array[2] nombre = ’ urray[3] ’ AND numero = ’ array[4] ’ AND tipo = ’ array[5] ’ com.imaginary.sql.msql.MsqlDriver jdbc:mqi://i48.208.92.104 1114/company aclmal aclmal Drop table TABLAlCOMPANY 4.2
where
74
Capítulo 6
CONEXIÓN Y EJECUCIÓN DE
OPERACIONES EN LAS
BASES DE DATOS LOCALES
En este capítulo se analiza qué es un JDBC, cuál es su arquitectura, los diferentes tipos que
existen y en qué forma lo utiliza el ambiente miiltibase de datos, por lo tanto sabremos cómo se
ejecutan las subtransaccione en las bases de datos locales, y se explicará cada una de ellas que
son: SELECT, INSERT, DELETE y UPDATE.
6.1 DeAnici6n de JDBC
JDBC es una API de Java que sirve para ejecutar instrucciones SQL. Consiste en un con-
junto de clases e interfaces escritas en Java, que facilitan la tarea de enviar instrucciones SQL
a cualquier base de datos relaciona1 que soporte este tipo de interfaces. En otras palabras, uti-
lizando la API JDBC no es necesario escribir u n programa para acceder a una base de datos de
Sybase, otro para accesar a una base de datos en Oracle, y otro para una de Informix. Uno puede
escribir un solo programa usando la API JDBC y dicho programa será capaz de comunicarse
con cualquiera de las diferentes bases de datos. Y como Java es niultiplataforma, entonces el
programa escrito se puede ejecutar donde exista una máquina virtual de JAVA.
Se piiode decir que JDBC hace de una manera simple t r e casas muy importantes:
75
Aplicación Java Máquina cliente
Protocolo propio del SMBD
Servidor de base de datos
Figura 6.1: Esquema del modelo de acceso 2-capas
* Ektablece una conexiún con la base de datos.
* Envía instrucciones SQL,
* Procesa los resultados
Existen en la arquitectura del JDBC dos modelos que se establecen para tener acceso a las
bases de datos éstos son: 2-capas y 3-capas [52].
En el modelo 2-capas un applet o una aplicación de Java interactúa directamente con la base
de datos. Esto requiere un manejador JDBC que pueda comunicarse con el sistema inaiiejador de
la base de datos que se accese. A esto le llaman configuración clientefservidor como se muestra
en la figura 6.1.
En el modelo 3-capas, los comandos son enviados a una capa intermedia de servicios, que
envía las instrucciones SQL a la base de datos. La base de datos procesa dichas instrucciones
y envía los resultados de vuelta a la capa intermedia, quien los manda al usuario. Esto es
bueno porque teniendo una capa interniedia podemos mantener control del acceso y del tipo de
actualizaciones que pueden ser realizadas a la información como se muestra en la figura 6.2.
El API JDBC se expresa como una serie de interfaces abstractas en Java que permiten al
programador de aplicaciones abrir conexiones hacia o con bases de datos partículares, ejecutar
instrucciones SQL y procesar los resultados. Se muestra la forma de trabajo en la figura 6.3.
76
Máquina cliente (GUI)
SMBD
HTTP, RMI O COMA Aplicación Server-Java
Máquina servidor
4
Servidor de base de datos
1 Protocolo propio del SMBD
Figura 6.2: Esquema del modelo de accao %capas
1 Driver Managed
Figura 6.3: Esquema de trabajo de dDBC
77
Las interfaces más importantes del JDBC son 1531:
* java.sql.DriverManager: manipula la carga de los manejadora JDBC y provee
soporte para crear nueva conexiones con las bases de datos.
* java.sq1.Connection: ejecuta una conexión toll una base de datos en particular.
* java.sq1.Statement: actúa como un contenedor para ejecutar instrucciones SQL
como una coiiexión determinada.
* java.sql.ResulSet: es la que controla el acceso a la fila de resultados de una deter-
minada instrucción.
La mayoría de los manejadores JDBC de las bases de datos simplemente necesitan proveer
implementaciones de las clases abstractas, proporcionadas por el API JDBC. Específicaniente,
cada manejador JDBC debe proveer implementaciones de java.sql.Connection, java.sql.Statement,
java.sql.PreparedSta tement, java.sql.Ca1lableStatement y java.sql.ResultSet.
Existen cuatro categorías distintas de manejadores JDBC [54]:
1.-Manejadores puentes JDBGODBC: transforman las llamadas JDBC a sus equiva-
lentes en ODBC? lo que supone la existencia en la máquina cliente de binarios ODBC(el gestor
de manejadores JDBC de Microsoft, y el manejador ODBC para la base de datos específica)
y, posiblemente, de código clieiite específico de la base de datos a acceder, de forma que estos
manejadores JDBC resultan apropiados para redes corporativas (con departamentos dedica-
dos al mant,eiiimiento de máquinas clientes) o para servidores Java en arquitectura 3-capas.
Aunqiie ODBC también funciona sobre Mac y algunas plataformas UNIX, el manejador puente
de referencia, desarrollado conjuntamente con JavaSoít e Intersolv, sólo está disponible para
plataforiuas soportadas por Java: Solaris y Win32. Por supuesto se trata de la opción menos
eficaz, pues siniplemente se anade una capa ni& a la estructura de acceso existente mediante
ODBC, pero puede resultar la solución idónea para integrar ducioiies Java en sistemas prehe-
chos.
78
2.- Manejadores para APIs nativos con Java-mix: convierten las llamadas JDBC en
llamadas al API cliente para Oracle, Sybase, Informix, DB2 y otras bases de datos. Usualmente
requieren, como en el caso del puente JDBC-ODBC, la carga de determinados archivos en la
parte clieiite.
3.- Manejadores Puros Java JDBCNet : traducen las llamadas JDBC a un protocolo
de red independiente de las bases de datos, que a su vez será traducido a protocolos nativos
(determinados en cada caso por el fabricante de la base de datos que pret,ende ser accedida) por
otro servidor intermediario, cuya función es conectar a sus clientes Java con diferentes bases de
datos, es el enfoque más flexible.
4.- Manejadores JDBC puros Java para protocolos nativos: convierten las llamadas
JDBC al protocolo de red usado directamente por las bases de datos, permitiendo, en Intranets,
el acceso directo desde clientes a bases de datos en servidores dados. Se trata, en definitiva,
de un caso especial del manejador JDBC-net en que la comunicación se establece directamente
con el servidor de la base de datos mediante un protocolo usualmente propietario (por lo que
serán precisamente los fabricantes de bases de datas los que habrán de proveer este tipo de
manejadores JDBC).
El gestor de manejadores JDBC (Driver manager) representa la capa de JDBC dedicada a la
gestión de los distintos manejadores JDBC del sistema. En breve el gestor de manejadores JDBC
establece una correspondencia entre una URL JDBC y un manejador dDBC concreto. Natural-
mente el gestor necesita saber qué manejadores JDBC debe manejar y dónde están situados, por
lo que surge la necesidad de que, para evitar problemas, sean los mismos manejadores JDBC los
que se registren aut,omáticamente de dos posibles formas:
1.- Mediante la invocación del método Class.forName, pasándole como parámetro
el nombre calificativo (mediante la notación independiente formada por puntos) del
manejador JDBC dado:
79
Class.forName("mi directorio.manejadorJDBC mimnneJadorJDBC");
2 - Por medio de la adición de distintos nombres de manejadores JDBC separados por
punto y comas a la propiedad jdbc.drivers, haciendo uso del método java.lang.System.set
Property o naturalmente, mediante su igual inserción en archivos de inicialización.
El problema con esta estrategia es que el gestor de manejadores JDBC pudo haber
leído ya, como de hecho lo hace al inicializarse, la propiedad jdbc.drivers, de forma
que cada adición no tendría efecto hasta que el gestor se iniciara de nuevo.
,
Con todo, ambos procedimientos requieren que se invoque el método DriverManager.register
Driver, pasándole como parámetro un ejemplar de la clase representativa del manejador JDBC
(se supone que tras el proceso de carga y las niodificaciones antes dichas, el manejador JDBC
creará un ejemplar de sí mismo y la usará aquí como paráinetro).
Las llamadas JDBC (o sea, la invocación de métodos pertenecientes a clases del paquete
java.sq1 ) se pasan a un gestor de manejadores JDBC, el ciial, a su vez, las pasará al manejador
JDBC que pueda manejarlas.
Cuando una aplicación Java requiera del gestor de nianejadores JDBC una conexión con una
base de datos determinada, el gestor revisará primero su lista de manejadores JDBC registrados.
Pero no toda la lista, sino Únicamente la compuesta de los manejadores JDBC válidos ( éstos son
los cargados en la inicialización del gestor) ni& los manejadores JDBC que se hayan registrado
después pero que procedan de la misma URL que el código invocador o que compartan el mismo
cargador de clases (class loader). El gestor de manejadores JDBC intenta la conexión con cada
uno de las manejadores JDBC registrados, en el mismo orden de registro (los manejadores JDBC
detallados en la Property jdbc.drivers son cargados primero, por orden de aparición), y devolverá
un objeto Connection asociado al primer inaiiejador JDBC que entienda la URL de conexión, de
forma que a partir de ese momento se encaminarán por él las subsiguientes instrucciones SQL.
Por lo tanto para establecer unii conexión con un manejador de base de datos debemos
80
proveer un manejador .JDBC que quede registrado en Class.forName("mi directorio.manejador
JDBC.mi nianejador JDBC"); y de ésta manera se registra el manejador JDBC en el gestor
de manejadores JDBC. Por lo tanto, lo que sigue por hacer es establecer la conexión Ila-
marido a! método DriverManager.getConnection y obtener como resultado un objeto Connec-
tion. El método DriverManager.getConnection tiene como entrada tres cadenas de información,
la primera contiene el URL, la segunda el identificador de usuario y la últinia representa la clave
del usuario ejemplo:
Connection con = DriverManager.getConnection( url, idonMcador, clave );
Un URL (localizador uniforme de recursos), provee la información necesaria para localizar
un recurso sobre el Internet. Esto es representado por una dirección, &ta puede ser el nombre del
servidor que representa o el número IP asignado a la máquina. La información que compone el
URL utilizado por el JDBC tiene un formato propio pero utiliza la dirección URL de la máquina
donde se encuentra el SMBD[52].
Un URL JDBC provee una forma para la identificación de una base de datos donde el
manejador JDBC puede reconocer y establecer una conexión con ella. El URL JDBG es usado
con varias consideraciones de los manejadores JDBC, las convenciones son necesariamente muy
flexibles.
1.- Permite a diferentes manejadores JDBC usar diferentes esquemas para nombrar
a la base de datos.
2.- El URL JDBC permite a los desarrolladores de manejadores JDBC codificar toda
la información necesaria para la conexión.
3.- El URL JDRC permite un nivel de indirección. Esto habilita que el URL JDBC
pueda referenciar a un servidor lógico o al nonibre de la base de datos que es dináini-
camente traducido al nombre actual por un sistema de nombre de red. Esto permite
al administrador del sistema evitar especificaciones de servidores particulares como
81
parte del nombre JDBC
La sintaxis estándar para el URL JDBC está formada por tres partes, las cuales están
separadas por los dos puntos(:).
jdbc:<subprotocolo>: <subnombre>
1.- jdbc. contiene el protocolo: en el URL JDBC es siempre jdhc.
2.- <subprotocolo>: representa el nombre del manejador JDBC o el nombre del
niecanisino para conectarse a la base de datos, el cual puede ser soportado por 11110
o m& manejadores JDBC.
3.- <subnonibre>: una forma de identificar la base de datos. El subnombre p u d e
variar, depende del subprotocolo, y éste puede tener un subnombre con alguna siii-
taxis interna elegida por los diseñadores del manejador JDBC. Casi siempre está
formado por el IP de la máquina, el puerto por donde establece la comuriicación el
SMBD y el nombre de la base de datos.
La información de los parámetros de identificador y clave es la que se encuentra asignada
al usuario que se tiene dado de alta en la base de datos del SMBD donde se van a efectuar las
transacciones a través del manejador JDBC.
Hasta este momento sabemos cómo declarar el manejador JDBC y cómo hacer la conccción
sólo resta enviar las transacciona SQL al SMBD y procesar los resultados.
Para enviar transacciones SQL ai SMBD necesitamos crear iin objeto Statement. Hay
actualmente tres tipos de objetos Statement: Statement, Preparedstatement, heredado desde
Statement, y Callablestatement, heredado de Preparedstatement. Estos objetos son especializados
para enviar particularmente instrucciones de tipo SQL: la función de un objeto Statement es
ejecutar instrucciones sin parámetros, un objeto Preparedstatement es usado para ejecutar una
instrucción SQL precompilada con o sin parámetros, y un objeto CallahleStatement es usado
82
para ejecutar instrucciones SQL con parametros de entrada y salida en procedimientos alma-
cenados. De los tres tipos utilizamos en la aplicación del sistema multibme de datos el objeto
Statement.
Un objeto Statement es creado con el método createstatement del objeto Connection, como
se muestra en el siguiente ejemplo:
Connection con = DriverManager.getConnection( url, identiiicador, clave ); Statement stmt = con.CrenteStat,ernent();
La interfaz Statement provee tres diferentes métodos para la ejecución de transacciones
SQL:
1.- El método executequery es diseñado para transacciones que producen un solo
conjunto de resultados, tal como la transacción SELECT.
2.- El método executeupdate es usado para ejecutar transacciones INSERT, UP-
DATE o DELETE y también transacciones SQL del DDL como son CREATE TA-
BLE y DROP TABLE. El efecto de una instrucción DELETE, INSERT o UPDATE
es una modificación en una o más columnas en cero o m4s filas en una tabla. El
valor de retorno de un executeupdate es nu número entero que indica el número de
filas que fueron afectadas, Pard transacciones tales como CR.EATE TABLE O DROP
TABLE, las cuales no operan sobre filas, el valor que retorna el executeupdate es
siempre cero.
3.- El método execute es usado para ejecutar transacciones donde se generan
máz de un conjunto de resultados, o más de un contador de modificaciones, o una
combinación de ambos.
En la ejecución de las subtransacciones a las bases de datos locales solamente utilizamos
los métodos executeQuery y executeupdate, un ejemplo de cómo se envían las transacciones:
stmt.executeQuery(" Transaction "); stmt,.executeUpdate(<' Trnnsaecion " );
83
Al momento de ejecutar la transacción por medio del objeto Statement necesitamos recobrar
el resultado y esto lo podemos lograr por medio del la creación de un objeto Rgultset, el cual
va a contener todas las filas que satisficieron las condiciona de la transaccion SQL. El ResultSet
provee acceso a los datos de las filas obtenidas a través de un conjunto de métodos que permiten
accesar a las diferentes columnas que pertenecen a la fila. Ejemplo de una creación de objeto
ResultSet.
ResultSet r = stmt.executeQueryr transacción ");
Con la información anterior uno puede visualizar cómo está trabajando el API JDBC para
lograr la comunicación e interaccióii con las bases de datos.
Analizando que el ambiente multibase de datos es una aplicación construida totalmente
en JAVA, desde los lenguajes DDL y DML con los que interactúa el usuario global, hasta la
generación de las subtransaciones a las bases de datos locales. Por todo esto se eligió utilizar el
API JDBC de Java para lograr la coniunicación y ejecución de las operaciones. El manejador
JDBC que se utiliza para cada sistema manejador de bases de datos locale es de tipo 4, ya que
es una conexión directa con el sistema manejador de la base de datos.
6.2 Ejecución de operaciones
El código de subtransacciones que genera el DML está hecho para ser ejecutado por una
aplicación que utilice el API de .JDBC. Durante la definición del esquema de la base de datos
global se pide que el DBA introduzca información correspondiente para la conexi6ii con la base
de datos local (MANEJADOR JDBC, URL, USERNAME, CLAVE). Esta información es la que
necesitamos para establecer IR comunicación con el sistema manejador de base de datos con los
métodos del JDBC.
El código de subtransacciona generado por el DML es identificado y ejecutado por el mane-
jador de subtransacciones. El recibe un archivo texto que se llama ejecutable.dat y comienza a
extraer su contenido. AI momento de extraer la primera línea espera enrontrar una bandera de
84
... . "*
identificación que puede ser:
* 1 : significa que es código para una operación de SELECT.
* 2 : significa que es código para una operación de INSERT.
* 3 : significa que es código para una operación de DELETE.
* 4 : significa que es código para una operación de UPDATE.
En cada caso se sigue extrayendo la información del archivo hasta que se encuentre un
renglón con el mismo valor de la bandera con que entró. Toda esta información que se leyó es
almacenada en un nuevo archivo que según sea el caso se va a llamar: select.dat, insekdat ,
de lekdat o update.dat. Estos archivos son enviados a su ni6dulo donde serán ejecutados y
controlado su proceso. Se volverá a extraer información y se seguirá el mismo proceso anterior
hasta que se encuentre el fin del archivo.
Exiten en Java bibliotecas que nos permiten la posibilidad de poder generar módulos de
ejeciición concurrentes. Estas primitivas son la creación de hilos, los cuales representan un
proceso individual ejecutándose en un sistema. En nuestro ambiente multibase de datos por
el hecho de est,ar trabajando con más de un sistema de bases de datos local, muchas veces
se pueden ejecutar bloques de transacciones concurrentemente para obtener más rápidamente
los resultados. La capacidad de tener hilos ejecutándose en forma parelela es conocida como
multihilado. Cada tipo de transaccion en el ambiente multibase de datos cuenta con bloqiies que
se están ejecutando en multihilado [55]. A continuación se explicará la forma en que se están
ejecutando las diferentes subtransacciones para obtener los resultados que se buscan por parte
del usuario global.
6.2.1 Ejecución de la operación SELECT
Para la ejecución del bloque de subtransacciones de la transacción SELECT existe un bloque
de código que se encarga de leer el archivo de entrada y extraer los bloques de código que se van
85
a ejecutar. El pseudocódigo para la ejecucibn de código de la operación SELECT se encuentra
en el apéndice C archivo 5 . El procedimient,o se expondrá en 10s siguientes Pasos:
1.- se lee el primer renglón del archivo de entrada y se espera obtener una bandera que
contenga el valor de 1.1.
2.- Enseguida se extrae el contenido del archivo hasta encontrar de nuevo la bandera 1.1,
toda esta información es almacenada en un archivo nuevo, el cual será enviado a ejecutarse en
un hilo,
3.- De nuevo se extrae un renglón del archivo y si es una bandera 1.1 el control se regresa
al paso 2 para la generación de un nuevo hilo. De lo contrario se espera a que terminen de
ejecutarse los hilos que se habían lanzado en el paso 2 para proseguir en el paso 4. Ejemplo del
código que se envía en el archivo para la ejecución de un hilo:
com.imagiiiary.sql.msql.MsqlDriver jdbc:msql: f fi48.208.92.104 1114/conipany aclmal aclmal Create t,ahle TABLA1 ( nombrecli char(lO), numerocli &ar(l5), tipocli int ) com.imagiiiary.sql.msql.MsqlDriuer jdbc:msq1://148.208.92.104: Ill4/company acimal aclmal select nombre, numero, tipo from proye mm.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal admal Insert into TABLAl values ( ’ array[O] ’ , ’ array[l] ’ , array[2] ) wehlogic.jdbc.mssqIsrver4.Dnver jdbc:~eblogic:inssqlserver4://148.208.92.8~:1433/PRUEBA LUCEROLUCERO select nom, num, tipo from pro1 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Insert into TABLAl values ( ’ array[O] ’ , ’ array[l] ’ , array[2] )
4.- Sabemos que la función de cada hilo era la creación y llenado de las tablas globales
temporales con la información de las tablas locales que se encuentran enlazadas a la tabla global.
Por lo tanto al término de la ejecución de los hilos contamos con las tablas globales que se citaron
en el FROM del SELECT principal, lo siguiente es extraer del archivo de subtransacciones dos
renglones que por lógica se sabe que es la transacción de SELECT que emitió el usuario global,
almacenamos el resultado en un archivo texto el cual va a ser utilizado para mostrarse en un
visualizador . 5.- Lo que sigue es el borrado de las tablas globales. temporales, entonces las siguientes
operaciones que se extraen son DROP TABLE por cada tabla global teniporal que se haya
86
creado.
Las acciones que ejecuta cada hilo lanzado en el paso 2 se explican a continuación,
za).- Se extraen del archivo de entrada dos renglones, uno que representa la información
Para la conexión con el SMBD definido para el esquema global y el otro que representa la
transacción a ejecutar, que se espera sea una operacion CREATE TABLE para una tabla global
temporal.
2b).- Después de ejecutar la transacción anterior se van a extraer los siguientes dos renglones
los cuales representan la información para la conexión con algún sistema de base de datos local
y el otro es la transacción que es un SELECT de toda la información que contiene la tabla local
que est6 mapeando a la tabla global temporal.
2i).- El resultado de la transacción anterior es almacenado en un archivo y va a ser extraído
para llenar la tabla anteriormente creada.
2d).- Sc extraen del archivo de entrada los siguientes dos renglones uno que representa la
conexión con el SMBD definido para el esquema global y el otro es nna transacción INSERT la
cual está generada con un formato donde se van a sustituir los valores que se encuentran alnia-
cenados en cada renglón del archivo de resultados del SELECT anterior, entonces la transacción
INSERT se va a ejecutar por cada renglón que exist,a en el archivo de resultados del SELECT.
Insert into TABLA1 values ( ’ array[O) ’ , ’ array[l] ’ , array[2] )
2e).- Cuando terminen de ejecutarse los INSERT se verifica si estamos al final del archivo
de entrada, si no es así retornamos el control al paso 2, de lo contrario la creación y llenado de
la tabla temporal ha finalizado.
6.2.2 Ejecución de la operación INSERT
En la ejecución de la operación INSERT se generan instrucciones INSERT para cada tabla
local que se encuentre mapeando la tabla global a la que cita la operación. El pseudocódigo
para la ejecución de código de la operación INSERT se encuentra en el apéndice C archivo 6.
87
El archivo que recibe el módulo de INSERT es interpretado de la siguiente forma:
1.- Se extraen dos renglones del archivo, el primero tiene la información necesaria para lograr
la conexión con el sistema de base de datos local, y el segundo es la transacción de INSERT
correspondiente a la tabla local que mapea a la tabla global de la operación emitida por el
usuario.
com.imaginary.sql.msql.MsqlDriver jdb~:m~ql.//148.208.92.104:1114/cornpany aclmal aclmal insert into proye ( nombre, numero, tipo) values ( ‘Octavio’, ’go’, ‘5’ )
2.- Los dos renglones extraídos en el paso 1 se envían a un módulo de ejecución que será
lanzado como un hilo, la siguiente acción a realizar será verificar si estamos al final del archivo de
subtransacciones, si no es así retornamos al paso 1 para extraer una nueva transacción local, de
lo contrario la operación a seguir es esperar que los hilos lanzados para las operaciones INSERT
locales hayan terminado para proseguir con la siguiente operación global.
Por lo tanto van a generarse operaciones de INSERT dependiendo del número de bases de
datos locales que contengan una tabla local mapeando a la tabla global.
6.2.3 Ejecución de la operación DELETE
Cuando el módulo de la operación DELETE recibe el archivo de tramacciones a interpretar
para ejecutar las subtransacciones en las bases de datos locales podemos encontrar dos tipos
de bloques de código. Independientenieute de qué tipo de bloque de código se trate por cada
subtransacción dirigida a una base de datos local ésta será enviada a ejecutarse en un hilo,
porque el borrado en las tablas locales se hace con cada base de datos local. El pseudocódigo
para la ejecución de código de la operación DELETE se encuentra en el apéndice C archivo 7.
3.2 1.1 com.imagina~y.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 11 14/company aclinal aclmd Create table TABLAlCOMPANY(nombrec1i char(lO), numerodi char(ló), tipocli ;it,) u>m.imaginary.sql.msql.MsqlDnver jdbc:mqi://i48.208.92.104:1114/company aclmal aclmd select nombre, numero, tipo from proye corn.imaginery.sql.msql.MsqlDnver jdbc:msql//148.208.92.104:1114/company aclmal aclmal Insert into TABLAlCOMPANY values(’ array[O] ’ , ’ array[l] ’ , array(2))
88
. .
1.1 eom.imnginary.sql.m~ql.MsqlDnver jdbc:msqi://148.208.92.104:1 llii/company admal aclmal SELECT DISTINCT nombrecli, nunierocli, tipocli from TABLAlCOMPANY where tipocli =1 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Drop table TABLAlCOMPANY com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 11 14/eompany achnal aclmal DELETE FROM proye WHERE nombre = ' array[O] ' AND numero = ' array[l] ' AND tipo = ' array[2] ' 3.2 3.1 connect. niicrosoft.MicrosoftDriver jdbcff-microsoft// 148.208.92.821433/PRUEBA LUCERO LUCERO DELETE FROM prol where tipo =1 3.1
Por lo tanto existen dos métodos para la ejecución de cada subtransacción local, uno que
se ejecuta al momento de identificar la etiqueta 3.1 que es un bloque de tipo 1 y otro que se
identifica con la etiqueta 3.2 que es un bloque de tipo 2. A continuación se describe cada método
de ejecución paso por paso.
Cuando estemos trabajando con un bloque de código de tipo 1 los pasos a seguir son los
siguientes:
1.- Se identificará al momento de leer la etiqueta 3.1, y por consiguiente se extrae el contenido
del archivo hasta encontrar de nuevo la misma etiqueta.
2.- Realmente sabemos que el contenido entre las dos etiquetas 3.1 son dos renglones que
representan una subtransacción de DELETE directa a una base de datos local, por lo tanto
se extraen los dos renglones, uno que representa la información de conexión y el segundo la
operación DELETE hacia la tabla local, Un DELETE directo a la tabla de la base de datos
local es emitido cundo no existe cláusula WHERE, o cuando los tipos de las columnas en la
cláusula WHERE sí coinciden con los de la tabla de la base de datos local.
3.1 coniiect.microcoft.Micr~s~ftD~v~r jdbc:ff-microsoft://l48.208.92.82:1433/PRUEBA LUCERO LUCERO DELETE FROM prol where tipo =1 3.1
89
Los pasos a seguir cuando se trate de un código tipo 2 son los siguientes:
1.- Este módulo es identificado cuando se lee la etiqueta 3.2, después de esto, se extrae todo
el contenido del archivo hasta encontrar de nuevo la misma etiqueta.
2.-En el proceso a seguir se va a tener que extraer la información de la tabla local e inser-
tarla en una tabla global temporal, ya que se encuentre toda la información de la tabla local
insertada en la tabla temporal, se selecciona la información que cumpla la cláusula WHERE
de la instrucción emitida por el usuario global, de esta manera se obtiene como resultado un
archivo con la información que sólo cumple la condición del WHERE del DELETE global. El
bloque de subtransacción para lograr este objetivo está diseñado para ejecutarse como si fuera
un SELECT global que solamente extrae la información de la tabla local, por lo tanto del archivo
de transacciones se extraen 12 renglones y son enviados al módulo de SELECT global para que
nos entregue como resultado el archivo con la información que necesitamos borrar de la tabla
local
1.1 cam.imaginary.sql.msq1 MsqlDriver jdhc:rnsql//148.208.92.104: 1114/company aclmal aclmal Create table TABLAlCOMPANY(nomhrec1i ihar(lO), numerocli char(l5), t,ipocli int) com.imaginary.sql.msql.MsqiDriver jdbc:msql://i48.208.92.104 1114/company aclmal aclmal select nombre, nuniero, tipo from proye com.imaginnry.sql.msql.MsqlDriver jdhc:msql://148.208.92.104:1114/company achnal aclmal Insert into TABLAlCOMPANY values(’ array[O] ’ , ’ array[l] ’ , ama$]) 1.1 com.iinaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company achnal aclmal SELECT DISTINCT nomhrecli, numerocli, tipocli from TABLAlCOMPANY where
com.imaginary.sql.msql.~qlDriver jdhc:msql://l48.208.92.104:1114/company achal aclmal Drop table TABLAlCOMPANY
tipocli =1
3.- Después de terminar su ejecución el módulo de SELECT, sabemos si existe por lo nienos
un registro que cumpla la condición del WHERE del DELETE original, si esto sucede se extraen
los dos renglones siguienta del archivo de transacciones, el primero representa la información
necesaria para la conexión a la base de datos local, y el segundo es una transacción DELETE a
la tabla local donde la condición del WHERE fue modificada a una condición AND con todas
las columnas de la tabla local. Para introducir los valores correspondientes a cada coliimiia
90
-.-
local, éstos son tomados de4 archivo que generó el,SELECT global, de esta manera tenemos
la seguridad de que sólo se eliminarán los registros que cumplieron la cláusula WHERE del
DELETE original. Por lo tanto por cada registro encontrado en el archivo generado por el
SELECT global, se emite iina operación de DELETE hacia la tabla local.
com.imaginar~.sql.msql.MsqlDriver jdbc:rnsql://148.208.92.104: Ill4jconipany aclmal ailmal DELETE FROM proye WHERE nombre = ’ array[0] ’ AND mlrnern = ’ array[l] ’ AND tipo = ’ array[2] ’
6.2.4 Ejecución de la operación UPDATE
El módulo de ejecución UPDATE recibe el archivo a ejecutar, pero en él también se pueden
encontrar dos tipos de bloques de códigos que van a estar identificados ya sea por la etiqueta 4.2,
o la 4.1, los cuales también se van a estar ejecutando en hilos diferentes porque la modificación
de las tablas locales se hace con cada base de datos local. Ya identificada la etiqueta se extrae
el contenido del archivo hasta encontrar otra etiqueta igual como la que entró. El pseiidocódigo
para la ejecución de código de la operación UPDATE se encuentra en el apéndice C archivo 8.
Ciiando se trata de un bloque con etiqueta 4.1 los pasos a seguir son los siguient,es:
1.-Sabemos que en este bloque de código sólo vienen dos renglones de información que repre-
sentan una transacción directa a la tabla de la base de datos local. Se dice que estamos tratando
con una operación directa porque no existe cláusula WHERE, o los tipos de las columnas .en la
cláusula WHERE si coinciden con los de la tabla de la base de datos local. Entonces el primer
renglón es la información necesaria para la conexión con la base de datos local, y el segundo
renglón es la operación UPDATE hacia la tabla local.
A l -. - connect.microsoft,.MicrocoltDnver jdbc:ff-rnicrosoft://l48.208.92,82:1433/PR.~BA LUCERO LUCERO Lipdat,e pro1 set num = 78 where t,ipo =8 4.1
Los pasos a seguir cuando se ejecuta un bloque de código tipo 2 son:
91
1,.El código a ejecutar corresponde a una operación global que contiene la cláusula WHERE
y las columnas que están en la condición no coinciden sus tipos con las coluinnas de la tabla
de la bsse de datos local. De nuevo en el código viene un bloque correspondiente a ejecutar U n
SELECT global hacia la tabla local, nada más que le anexan la cláusula WHERE del UPDATE
a la transacción de SELECT. Por lo tanto se extraen 12 renglones del archivo de transacciones Y
son enviados al módulo de SELECT global para obtener como resultado un archivo qne contenga
la información que sólo cumple la condición del WHERE del UPDATE global.
1.1 coin.imaginary.sql.msql.MsqlDriver jdhc:msql//148.208.92.104:1114/~ompany aclmal aclmal Create table TABLAlCOMPANY (nombrecli char(lO), numerocli char(15), tipocli int) com.imaginary.sql.msq1.MsqlDriver jdbc:nisql//148.208.92.10411 14/company aclmal aclmal select nombre, numero, tipo from proye com.iinagines..sql.msql.MsqlDriver jdbc:msql//148.208.92.1041114/company aclmal aclmal insert into TABLAlCOMPANY values ( ’ array[O] ’ , ’ array[l] ’ , array[2] ) 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal SELECT DISTINCT nomhrecli, numerocli, tipocli from TABLAlCOMPANY where tipocli =8 com.~maginary.sql.msql.MsqlDri~~er jdbc:n1sql://148.208.92.104: 1114/coinpauy admal aclnial Drop table TABLAlCOMPANY
2.- AI obtener el archivo de respuesta del SELECT global sabemos si por lo menos existe un
registro en este archivo que cumpla la cláusula WHERE, si es así el siguiente paso es extraer los
siguientes dos renglones del archivo de transacciones donde uno representa la conexión al SMBD
que se definió para el esquema global, y el segundo es una transacci6n de CREATE TABLE que
tiene el formato de la tabla global de la operación del UPDATE emitida por el usuario global.
com.iniaginary.sql.msql.MsqlDriver jdhc:msql://148.208.92.104 11 14/company aclmal aclnial Create table TABLA1COMPANY(nomhrecli char(lO), numerocli cbar(l5), tipocli ;it)
3.- Después de ejecutarse el CREATE TABLE el siguiente paso es extraer los siguientes
dos renglones del archivo de transacciones, el primero es la información para la conexión con
el SMBD definido para el esquema global, y el segundo es un INSERT con el formato para
introducir los valores que se encuentran en el archivo generado anteriormente por el módulo
92
del SELECT global. Por lo tanto la operación INSERT se va a ejecutar por cada registro que
contenga el archivo.
com.imaginani.sql.msql.MsqlDriver jdbc:msqi://i48.208.92.104:1114/company aclmal aclmal Insert int,o TABLAlCOMPANY values( ' array[O] ' , ' array[l] ' , array[Z] )
4.- Después de haber insertado toda la información en la nueva tabla, se extraen otros dos
renglones del archivo de transaccionw donde el primer renglón es la información para la conexión
al SMBD definido en el diccionario de datos a la base de datos global, y el otro renglón es la
transacción UPDATE global dueccionada a la tabla temporal sin el.WHERE, esto es porque la
información que se encuentra insertada ya sabemos que es sólo aquélla que cumplió la cláusula
WHERE del SELECT global
com.iinaginsry.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 1114/compíiny aclmal aclnial UPDATE TABLAlCOMPANY SET numerocIi='78'
5.- Después de aplicar el UPDATE sobre la información de la tabla temporal se extraen del
archivo de transacciones dos renglones, los cuales representa una operación de SELECT sobre
la tabla temporal, la información es almacenada en un archivo, al igual que la información que
se insertó a esta tabla, por lo tanto tenemos en un archivo la información antes de aplicar el
UPDATE, y en otro archivo la información después de aplicar el UPDATE.
com.imaginary.sql.mcql.MsqlDriver jdbc:msq1://148.208.92.104 1114/company aclmal aclmal select nombrecli, numerocli, tipocli from TABLAlCOMPANY
6.-EI siguiente paso es extraer una subtransacción más, la cual es un UPDATE a la base
de datos local, donde tanto la cláusula SET y la condición del WHERE van a hacer uso de la
información que se encuentra en los dos archivos. La información se va extrayendo al mismo
tiempo de los dos archivos registro por registro para formular la instrucción de UPDATE hacia
la tabla de la base de datos local. La información del archivo antes de aplicar el UPDATE a la
tabla temporal es la que forma la condición WHERE, y la información de la cláusula SET es
obtenida del archivo de la información ya modificada. Se van a generar operaciones UPDATE
hacia la tabla local por cada registro que se extrae de ambos archivos.
93
com.imagina~.sql.msql.MsqlDrive~ jdbc:rniql://148.208.92.1041114/company aclmal aclinai Update proye set nombre = ‘ array[O] ’ , numero = ’ array[l] ’ , t,ipo = ’ array(21 ’ where nombre = ’ array[3] ’ AND numero = ’ array[4] ’ AND tipo = ’ array[5] ’
7.- Por último se extraen los últimos dos renglones del archivo de transacciones, éstos
representan nna transacción de DROP TABLE de la tabla global temporal que se creó para
aplicarle el UPDATE global.
com.imaginary.sql.msq1.MsqlDriver jdbc:msqI://l48.208.92.104:1114/company aclmal aclmal Drop table TABLAlCOMPANY
94
Capítulo 7
INTERFAZ CON EL USUARIO
GLOBAL
El ambiente niultibase de datos cuenta con varios múdulos funcionales, éstos son: DDL, DML
y el manejador de ejecución de subtransacciones. El DDL y el DML necesitan de un editor
donde el usuario elabore los archivos de definici6n del esquema y de transacciones a ejecutar
sobre alguna base de datos global, es por esta razón y para tener de una forma mds práctica
la interacción con los lenguajes del ambiente multibase de datos que se optó por construir una
interfaz que permita al usuario editar, cargar o modificar el archivo y cuando decida enviarlo al
DDL o DML solamente tenga que elegir una opción de la int,erfaz para lograr la ejecución de lo
especificado en el archivo. La interfaz del sistema se muestra en la figura 7.1.
Eii IRS secciones de este capítulo se explicará con más detalle el d m o debe el usuario global
interactuar con la interfaz diseñada para el sistema multibase de datos.
7.1 Editor niultibase de datos
Las funciones para la edicián de archivos en la interfaz se encuentran a disposición en dos
opciones del menú principal las cuales son: File y Edit.
LRS actividades del menú File son cinco:
* Editar un archivo nuevo
* Cargar un archivo
95
Figura 7.1: Interfaz del ambiente multibase de datos
* Salvar el archivo que se encuentre cargado
* Salvar con otro nonibre el archivo que se encuentre cargado
* Adem& tiene la opción de terminar con la ejecución de la interfaz al momento de selec-
cionar Quit.
Un ejemplo de cómo se selecciona una acción de la opción File se muestra en la figura 7.2.
Las actividades del menú Edit son trm las cuales trabajan con una selección del texto:
* Copiado de texto
* Cortado de texto
* Pegado de texto
Un ejemplo de cómo se selecciona una acciún de la opción Edit se muestra en la figura 7.3.
Con estas funciones el usuario de la interfaz no necesita de un editor auxiliar para editar
sus arcliivas.
96
Figura 7.2: Selección de acciones de la opción File.
Figura 7.3: Selcción de acciones de la opción Edit
97
7.2 Ejecución del DDL
Existe en las opciones del menú principal la opción RUN la cual cuenta con dos acciones
de trabajo, la primera de ellas es la ejecución del DDL del ambiente multibase de datos. Para
ejecutar el DDL es necesario que exista un archivo donde se encuentre definido el esquema de
una base de datos global. El archivo que analiza el DDL debe encontrarse cargado en el editor
de la interfaz, porque al momento de seleccionar la ejecución del DDL en la opción de RUN este
método toma como entrada el archivo que se encuentra actualmente cargado en la interfaz y
procederá por consiguiente al análisis del mismo. Después de analizarlo va a generar dos tipos
de resultados, si el archivo está correctamente editado según la gramática del DDL va a enviar
un mensaje de análisis exitoso y además la creación del diccionario global de la nueva base
de datos global, de lo contrario si no logró un análisis exitoso envía un mensaje de error por
haber encontrado un error sintáctico o semántico. Un ejemplo de la ejecución del DDL sobre un
archivo perfectamente definido se muestra en la figura 7.4.
Figura 7.4: Ejecución del DDL del ambiente multibase de datos sobre un archivo bien definido.
98
7.3 Ejecución del DML
segunda acción de la opción RUN es la ejecución del DML del ambiente multibase de
datos. necesario por parte del usuario contar con un archivo que contenga la definición de
transacciones (SELECT, INSERT, DELETE y UPDATE) definidas sobre el esquema de iiua
base de datos global. Para la ejecución del DML el archivo que va a analizar y enviar para su
ejecucih al manejador de subtransacciones debe estar cargado en el editor de la interfaz. El
DML toma como entrada el archivo que se encuentra actualmente cargado en el editor de la
interfaz, su función es analizarlo, si no existen errores la siguiente actividad será descomponerlo
en subtransacciones locales y enviarlo para sn ejecución al manejador de subtransacciones donde
al momento de interpretarlas y ejecutarlas enviará los resultados al usuario global, pero si
existieron errores en el archivo ya sean sintádicos o semánticos se envía un mensaje al usuario
global para que los corrija e intente de nuevo. Un ejemplo de la ejecución de un archivo que
contiene m& de una transacción sobre una base de datos global se muestra en la figura 7.5.
7.4 Visualizador de multibase de datos
El ambiente multibase de datos puede tener definidos n esquemas glohales y muchas veces
el usuario global necesita consultarlos de manera general o simplemente desea ver los resultad-
después de realizar alguna transaccion de modificación (INSERT. DELETE y UPDATE) sobre
alguna base de datos global, Pensando en esta necesidad se desarrolló un módulo que permite
al usuario introducir el nombre de la base de datos global de la que desea saber su contenido y
cómo se encuentra definida su estructura como lo muestra la figura 7.6.
Con esta información se consulta el diccionario de datos y se despliega en forma gráfica
un esquema de árbol donde el nodo principal representa la base de datas global y las hojas las
tablas que componen el esquema de definición de esta base de datos global, esto se muestra en
la figura 7.7.
AI momento de seleccionar con el ratón una hoja del árbol, la cual representa una tabla,
99
O01
Figura 7.6: Ejecución de la opción VisualMBD donde se introduce el nombre de la base de datos
global a visualizar.
Figura 7.7: Se muestra el esquema de la base de datos en forma de árbol
101
1
la operación a ejecutar muestra un visualizador con la información integrada que se encuentra
almacenada en las tablas locales que mapean a la tabla global seleccionada. Para habilitar este
método de consulta es necesario , . . " seleccionar del menú principal la opción de VisualMBD. Un
ejemplo del contenido de una . . tabla ,, global se muestra en la figura 7.8. , ,.
Figura 7.8: En esta figura se puede apreciar el contenido de la tabla global TABLA1, la cual
extrae información de las tablas locales pertenecientes una a SQL Server y otra a mSQL.
102
Capítulo 8
PRUEBAS
Las pruebas a realizar en este capítulo consisten en probar archivos que son analizados por
el DDL y el DML en la interfaz creada para el ambiente multibase de datos. Las pruebas
son desarrolladas en un sistema heterogéneo compuesto por tres sistemas manejadores de bases
de datos (OR.ACLE, mSQL y SQL Server) que se encuentran ubicados en sitios diferentes de
Internet y sobre plataformas distiiitas.
8.1 Objetivo de las pruebas
LOS objetivos que se alcazan con estas pruebas son los siguientes:
Por parte del módulo DDL
a).- Verificar que sea capaz de detectar error= léxicos y sintácticos en el archivo que analiza
para generar el diccionario de la base de datos global.
h),- Constatar que el diccionario global sea generado con la información que debe contener
en los diferentes archivos para que el DML pueda consultarlo en la generación de las subtransac-
ciones.
Por parte del DML
a).- Verificar que sea capaz de detectar errores léxicos y sintácticos en el archivo que analiza
para generar las subtransacciones a los SMBD locales.
h): Confirmar que la generación de subtransacciones esté tomando en cuenta a todas las
tablas lorales que integran la tabla global sobre la que se esté generando la transacción del
usuario global.
103
Constatar que en la generacióii de subtransacciones se estén tomando las medidas
necesarias para eliminar los problemas de heterogeneidad entre la información Perteneciente a
las tablas locales.
d).- Revisar que la ejecución de las subtransaccionej se esté efectuando en la secuencia que
se define según sea la transacción global a la que pertenezcan para asegurar que el resultado es
coherente.
e).- Confirmar que los resultados sean correctos con respecto a la solicitud de información
contenida en las tablas locales.
Por parte de la interfaz:
a).- Comprobar que las funciones del editor permitan al usario global 'editar los archivos
que desee analizar con el DDL y DML del sistema multibase de datos.
b).- Verificar que la ejecuci6n del DDL esté analizando y arrojando resultados del archivo
que se encuentre cargado en ese momento en el editor.
c): Revisar que la ejecución del DML esté analizando y arrojando resultados del archivo
que se encuentre cargado en ese momento en el editor.
d).- Confirmar que la función de visualizador de la base de datos global esté mostrando en
forma gráfica el diccionario de la misma.
e).- Revisar que al momento de seleccionar en el árbol una tabla global el resultado obtenido
sea la información contenida en las tablas locales que integran a la tabla global seleccionada.
8.2 Descripción del ambiente de prueba
El ambiente de prueba est4 compuesto por tres SMBD locales que son Oracle, mSQL y SQL
Server. Cada SMBD se encuentra trabajando sobre una plataforma distinta y se puede accesar
a ellos a través de la dirección IP que tiene asignada la máquina donde se encuentra trabajando.
A continuación se enumeran las características que distinguen a cada SMBD local.
El sistema Oracle
104
Su versión 8.0.3
- Sistema operativo: AIX 4.3.1
- Máquina: IBM RS/GOOO Modelo F50 con 2 procesdores
- Driver utilizar: Thin de Oracle
- Dirección IP: 132.254.46.250
El SMBD mSQL
- Su versión 2.0
- Sistema oprativo: SunOS Solaris 2.4
- Miquina : es una estación Sparc IPX, 16MB en RAM.
- Driver: Imaginary
- Dirección IP: 148.208.92.104
El SMBD SQL Server
'
- Su versión 6.0
- Sistema operativo: Windows NT
- Máquina : una P C procesador Pentium con G4M en RAM
- Driver: FastForward, release 3.1.3
- Dirección IP: 148.208.92.82
Para realizar las pruebas del ambiente multibase de datos se diseñó un esquema de base
de datos donde el ambiente del esquema se dirige al concepto de un departamento de servicios
escolares de un sistema educativo a nivel licenciatura. Del mismo modo, en cada SMBD local
se definió un esquema similar representando un departamento de servicios escolares que, por su
naturaleza, está manejando información que semánticamente tiene algo en común, pero debido
a que el diseño de la base de datos fue hecho por DBA distintos, existe heterogeneidad en la
sintaxis de las bases de datos.
105
8.2.1 Esquema de la basc de datos de prueba
A continuación se presenta el esquema de la base de dato global que es definido en el sistema
niultibase de datos en la figura 8.1.
materias
materia: char(25) creditos: char(2) 1
matricula: int .......................... 1 1 carrera: char(4)
clave: int matricula: int
1 : char (3) ' 'o: int
: I L,.,: nombre: char(40) '-4 edad: int
. ............................................................ E
Figura 8.1: Esquema de la base de datos global basesein.
Este esquema está compuesto de siete tablas, a su vez cada una de ellas al momento de ser
consultadas por alguna transacción global extrae la informaLión contenida en las tablas locales
que pertenecen a los diferentes sistemas manejadores que integran el esquema global, que en
este caso son trex SQL Server, Oracle y rnSQL. En cada uno de estos sistemas se encuentra
definida una base de datos y se toman de su esquema las siete tablas que nos intesa que mapeen
a nuestro esquema global. Sabemos que nuestro sistema tiene la capacidad de integrar y extraer
la información de los diferentes SMBD y puede soportar problemas de heterogeneidad en el
esquema:
106
- Homonimias y sinonimias en nombres de tablas y campos.
-Recuperar de igual modo cuando se trate de integrar información de tipo cadena a
o viceversa.
- Tratar con tablas que cuentan con un número niayor de canipos en comparación con la
tabla global.
Estos problemas de heterogeneidad pueden ser detedtados en cada uno de los esquemas de
las bases de datos locales. A continuación se muestran los diseños de las tres basa de datos
locales. El esquema de SQL Server en la figura 8.2, el esquema de Oracle en la figura 8.3 y el
esquema de mSQL en la figura 8.4. El archivo que se editó para la definición del esquema de la
base de datos global se encuentra en el apéndice A archivo 2.
Figura 8.2: Esquema de la base de datos definida en el SMRD de SQL Server.
Figura 8.3: Esquema de base de datos definida en el SMBD de Oracle
Figura 8.4: Esquema definido para la base de datas del SMBD mSQL.
108
8.2.2 Contenido inicial de las bases de datos locales de prueba
Los valores que se muestran en las tablas son los correspondientes a los contenidos de las
tablas de 1m tres esquemas de las bases de datos locales.
Primeramente se muestran los contenidos de las tablas de SQL Server de la tabla 8.1 a la
t abh 8.7, le siguen las tablas de Oracle de la tabla 8.8 a la tabla 8.14 y las tablas de mSQL de
la tabla 8.15 a la tabla 8.21
I clavepro I nombrepro I INDUSTRIAL
MECANICO
ELECTRONIC0
COMPUTACION
LSCA LICENCIADO
Tabla 8.1: Tabla profesional
Tabla 8.2: Tabla reticula
109
claves nomhrest ciavepro edad LEX% 101 PEDRO LSCA 21
1- 110 I RICARDO I IME 1 19
131
I 121 I ABEL I ISCA 1 22
VERONICA LAE 21
clavere riombrecarga valor
1 201 I COMPUTACION-I I 6 I
catedratico
MATEMATICAS-I
Tabla 8.4: Tabla carga
noinbrect edad grado
100 PEDRO 24 MAESTRIA
110
300 LUIS 21 LICENCIATURA
. -
claves ciavect LE 200
300
I 131 1 100
8765
5104
Tabla 8.6: Tabla clase
I ngrupo I capacidad I
Tabla 8.7: Tabla grupos
I clavel I nombre1 1
COMPUTAClON
QUlMICO l k l Tabla 8.8: Tabla licenciatura
111
clavel davecon
IME 231
nocontrol
245
nompupi clavel
Tabla 8.9: Tabla convenio
I 300 I MARCOS I IQ
MARTA
~
I 331 I SOFIA I IQ
Tabla 8.10: Tabla pupilos
19 i 22
112
clavecon nobreacig carga
QUIMICA
BIOLOGIA
nocontrol clavemp clavecon
1 ii 1 PRODUCCION-I1 1 INTEGRALES
IMPUESTOS
228 CONTABILIDAD-I
nnaula
Tabla 8.11: Tabla asignatura
301
I davemp I nombremp I edad I titulo I
410 228 86
I 110 I JOSE I 28 I MAESTRIA I
301 210 251
1 1:: I MANOLO 1 ,D I MAESTRIA I LOURDES MAESTRIA
410 JAVIER DOCTORADO
50
Tabla 8.12: Tabla magtros
Tabla 8.13: Tabla clase
113
86 20
90
Tabla 8.14 Tabla aula
INDUSTRIAL
BIOQUIMICO
I INFORMATICA LiiSA 1 COMPUTACION 1 LICENCIADO
CONTABILIDAD
Tabla 8.15: Tabla area
r - 7 7 clavearea clavelc
Tabla 8.16: Tabla licenciatura
114
431 VERENICE BQ 2 1
Tabla 8.18: Tabla materia
clavelc
201
274
221
258
228
251
271
Tabla 8.19: Tabla empleado
115
nomat carga
COPMPUTACION-I 6
S.O. 16
CONTR.OL-PRO 8
BIOLOGIA-I1 8
INGRESOS 8
IMPUESTOS-I1 8
ORGANICA 6
Tabla 8.20: Tabla seminario
104
Tabla 8.21: Tabla sala
8.3 Casos de prueba
En esta sección se presentan los casos de pruebas iniplemetados para verificar si los resul-
tados presentados por el ambiente multibase de datos son los correctm.
Para cada caso se expone el objetivo, procedimiento y resultados obtenidos de las pruebas.
PRUEBA1
Objetivo : Probar el visualizaror de la base de datos global previamente definida
como basesem. También se verificará que se muestra el contenido de las tablas con
los valores iniciales.
116
Procedimiento: De antemano se debió haber creado el diccionario de la base
de datos global a consultar. Primero se selecciona del menú principal del ambieiite
multibase de datos la opción VisualMBD que sólo contiene la opción de capturar
multibase de datos, al momento de seleccionarla aparece una ventana de petición del
nombre de la base de datos global, al momento de introducir el nombre de la base de
datos global el sistema consulta el diccionario de la base de datos global solicit,ada
y por consecuencia genera en forma gráfica el árbol que representa el esquema de la
base de datos. Si el usuario selecciona cualquiera de las tablas del árbol se desplegará
una nueva ventana mostrando el contenido de la tabla. Ver figura 8.5
Resultados: AI momento de seleccionar la tabla carreras del diagrama se generó el
código (ver apéndice B archivo 1) para extraer la inlormacion de los SMBD oracle,
SQL Server y mSQL. EL resultado que se desplegó son todas las carreras dadas de
altas en los tres SMBD sin repetición.
PRUEBA 2
Objetivo: Probar la ejecución de una transacción de SELECT hecha por el DML.
Procedimiento: El usuario global en el editor tiene cargado un archivo donde hace
referencia a la base de datos global basesem y redada la operación SELECT como
lo puede observar en la siguiente figura 8.6
Resultados: Al niomento de ejecutar la opción de DML del submenií de Run se
analizó que la sintaxis y la semántica de la transacción estuvieran correctas, después
de esto se generó un archivo de subtransacciones (ver apéndice B archivo 2) que ai
inomento de ejecutarse extrajo a todas las materias con valor de 6 créditos y además
mostró las carreras que pertenecían al mismo plan de estudios de la materia.
PRUEBA 3
Objetivo: Probar la ejecución de iina transacción de UPDATE hecha por el DML
117
deccripcion CHAROO),
.............................. ......................................
.......................................
...............................................
. . . . .
Figura 8.5: En esta prueba se muestra el contenido de la tabla carreras.
118
.- .
..................................................................... ............................................................... ................................. I___---
- ................................................................... ...............................................
.- ....................................
Figura 8.6: Muestra la ejecución de la transacción SELECT sobre las tablas globales materias
y planes.
119
Procedimiento: Como se puede percatar en el resultado de la prueba anterior existe
un error en el nombre de la materia COMPUTACION-I por COMPUTACION-1,
es así que podemos hacer la corrección del nombre de la materia desde el usuario
global, eliminando la inconsistencia en esa tabla local. POI lo tanto para realizar
esta corrección el usuario global debe tener cargado en el editor una operación de
UPDATE y una de SELECT para verificar el resultado de la modificación. Ver la
siguiente figura 8.7
DATE materias SET materia='COMPUTACiON-I' HERE materia='COMPUTACION-1 I;
DISTINCT materias.clave. planes.carrera, materias.materia
materias.creditos='fi'AND maIerias.clave=planes.clave;
.................. .
iCOMPUTAClON I
- Figura 8.7: Muestra la ejecución de las transacciog UPDATE y SELECT a t a última para
verificar si ejecutó correctamente la modificación del UPDATE.
Resultados: El DML analizó primero la sintaxis y el significado semántico de cada
transacción generando al mismo tiempo el archivo de subtransaccciones (ver apéndice
120
B archivo 3). El siguiente paso fue enviar a ejecución Ins siibt,ransacciones generadas
a cada uno de los SMBD locales, obteniendo los resultados satisfactorio de cada
transacción mostrando por medio del resultado de la transacción SELECT que la
modificación fue efectuada correctamente.
PRUEBA 4
Objetivo: Probar la ejecución de una transacción de UPDATE hecha por el DML
sobre atributos que se encuentran con heterogeneidad- de tipo y nombre.
Procedimiento: Para esto seguimos trabajando con las tablas plan- y materias,
el tipo de dato del campo clave en el esquema global es tipo INT, en los esquemas
locales lo encontramos como tipo CHAR o tainbién de tipo INT. El usuario global
eniite una transacción de WDATE para modificar el valor del campo clave donde
materia es igual a 'COMPUTACION-I' y su clave es 201 para cainbiar el valor de
clave a 130, además anade una transacción de INSERT que registrará una carrera
en el plan 130 para que de esta manera ejecute el SELECT quc se ha efectuado
en las pruebas anteriores para que nos muestre los resultados de las transacciones
WDATE e INSERT. Esto lo podemos apreciar en la figura 8.8
Resultados: El DML analizó primero la sintaxis y el significado semántico de cada
transacción generando al mismo tiempo el archivo de subtransaccciones (ver apéndice
B archivo 4). El siguiente paso fue enviar a ejecución las subtransacciones generadas
a cada uno de los SMBD locales, obteniendo los resultados satisfactorio. de cada
transacción mostrando por medio del resultado de la transacción SELECT que la
modificación e insección fueron efectuadas correctamente.
PRUEBA 5
Objetivo: Probar la ejecución de una transacción de DELETE hecha por el DML
sobre atributos que se encuentran con heterogeneidades de tipo y nombre.
121
materias SET ciave=l30 HERE materia='COMPUTACIüN-I' AND clave=201;
iINSERT INTO planes VALUES('IBQ', 130); $SELECT DISTINCT materias.clave, planes.carrera, materias.materia
FROM materias, planes \WHERE materias.creditos='6'AND materias.clave=planes.ciave;
Operacion insert satisfactoria Operacion select satisfactoria
_I_
Figura 8.8: Muestra la ejecuci6n de las transacciones WDATE, INSERT y SELECT esta última
para verificar si ejecutó correctamente la modificación hecha por el UPDATE y la inserccióii
hecha por el INSERT.
122
Procedimiento: Para esto seguimos trabajando con las tablas planes y materias,
el tipo de dato del campo clave en el esquema global es tipo INT, en los esquemas
locales lo encontramos como tipo CHAR o también de tipo INT. El usuario global
emite una transacción de DELETE para eliminar la insercción hecha en la prueba
anterior en la tabla planes. De nuevo el usario global ejecuta la transacción de
SELECT que se ha efectuado en las pruebas anteriores para que nos muestre los
resultados de la transacciún DELETE. Esto io podemos apreciar en la figura 8.9
clave=l30; planec.carrera, materias.materia
:'&HERE materias creditos='S AND materias.clave=alanes.clave: . .
' I I
Figura 8.9: Muestra la ejecución de las transacciones DELETE y SELECT esta última para
verificar si ejecutó correctamente el borrado realizado por la operación DELETE.
Resultados: El DML analizó primero la sintaxis y el significado semántico de cada
transacción generando al mismo tiempo el archivo de siibtransaccciona (ver apéndice
123
B archivo 5). El siguiente paso fue enviar a ejecución las subtransacciones generadas
a cada uno de los SMBD locales, obteniendo los resultados satisfactorio de cada
transacción mostrando por niedio del resultado de la transacción SELECT que el
borrado estuvo correctamente ejecutado.
124
Capítulo 9
CONCLUSIONES
En este capítulo se presentan las conclusiones obtenidas con el desarrollo del ambiente multibase
de datos; algunas recomendaciones para poder hacer posibles extensiones o modificaciones a este
trabajo de tesis y, sobre todo, posibles propuestas de trabajos futuros que puedan tomar como
base los logros ya obtenidos en este ambiente multibase de datos.
9.1 Conclusiones generales
La integración de información heterogénea que para un objetivo global tiene un significado
semánticamente equivalente permite a un usuario global poder utilizar información preexistente
en bases de datos, sin necesidad de tener que hacer una réplica de esa información o modificar
sist,enias que están diseñados para un objetivo específico.
Por lo tanto, el diseñar e implementar funciones de software que nos permitan tener acceso
y realizar operaciones sobre información con la que sólo podíamos interactuar individualmente
a través del SMBD que la administra, permite operaciones globales utilizando las bases de
datos preexistente sin necesidad de modificar su sistema de trabajo; esto equivale a respetar la
autonomía que los SMBD locales tienen sobre sus bases de datos.
Para diseñar un esquema global existen desventajas, que marca la literatura, con respecto
a que el DBA necesita tener conocimiento de cada uno de los esquema3 locales que se desean
integrar. Si esta desventaja la analizamos desde el punto de vista práctico, podernos decir que
si el DBA decidió que esas tablas las quiere integrar es porque tienen un significado semántico
con el esquema global. Este proceso no puede ser un 100% automatizado, porque el diseño de
125
un esquema de base de datos es hecho por humanos y cada quien puede reconocer los mismos
objetos en forma distinta.
Mientras que el DBA sea un humano y no exista un patrón universal para repreientar cada
objeto el esquema global de un sistema multibase de datos para poder ser seguro tiene que ser
elaborado por alguien que tenga conocimiento de cómo est6n construidos los esquemas de las
bases de datos locales.
9.2 Resultados obtenidos
Debido al análisis en la literatura existente sobre este tema, que es un área de investigación
donde se han aportado soluciones individuales a los muchos conflictos que surgen al momento de
integrar la información, se desarrolló la propuesta del presente trabajo de tesis y partiendo de
ésta concluimos que todos los puntos especificados en su alcance fueron cubiertos. El objetivo
principal era el de diseñar e implenientar un sistema de integración de información en un es-
quema lógico global de bases de datos pertenecientes a sistemas manejadores de bases de datos
distribuidas heterogéneas, esto se logra con la herramienta de software del sistema multihase
de datos, que cuenta con procedimientos de software que operan en conjunto para ofrecer un
esquema de integración de bases de datos distribuidas heterogéneas, permitiendo a un usuario
global accesar a la información de manera transparente.
A continuación se presentan en resumen cuales fueron los módulos funcionales obtenidos
durante el proyecto de tesis:
1.- Un intérprete para el lenguaje de definición de datos (DDL). Se diseñó la
gramática del DDL del sistema partiendo de la propuesta en el estándar ISO/IEC 9075 más una
extensión que permita al iisuario global enlazar el esquema global a los esquemas de las bases
de datos locales.
2.- Un intérprete para el lenguaje de manipulación de datos (DML). El diseño
de la gramática del DML del sistema tamhibn está basado en el estándar ISO/IEC 9075 y es
126
un subconjuto de las producciones. El usuario global a1 momento de utilizarlo puede realizar
transacciones de SELECT, INSERT, DELETE y UPDATE con sólo dirigirlas hacia el esquema
de la base de datos global sin necesidad de tener conocimiento de las subtransacciones a generar
a los diferentes SMBD locales.
3.- Un generador de subtransacciones. Cuando el usuario emite alguna transacción
sobre un esquema global el DML analiza que esté correcta en sn significado sinthtico y semán-
tico, pero el proceso a seguir es tomar esa transacción y generar el código que será enviado a los
SMBD. El código generado soporta la operación de extraer la información e integrarla pese a la
heterogeneidad que existe entre los diferentes SMBD.
4.- Controlador de ejecución de subtransacciones. La función de este módulo es
ejecutar el código generado por el módulo anterior y transmitir los resultados para el usuario
global.
5.- Editor multibase de datos. Con los cuatro módulos anteriores el ambiente multibase
de datos cumple el objetivo de integrar la información y permitir al usuario emitir transacciones
sobre esta información. Lo que queda por hacer es proporcionar una interfaz que permita al
usuario global trabajar con el DDL y DML del sistema. Lo que se desarrolló para solucionar
esta situación fue una interfaz que permite al usuario editar archivos, y ademác seleccionar
como opciones de trabajo la ejecución del DDL o DML según lo decida. Por lo tanto el editor
multibase de datos permite editar, ejecutar el DDL y DML, y si el resultado del análisis del DML
es exitoso éste manda a generar y ejecutar las subtransacciones correspondientes para lograr la
transacción global emitida por el usuario.
6.- Visualhador de la base de datos global. El editor mnltibase de datos proporciona
una función al usuario global que es la de visualizar un esquema global, con sólo proporcionar el
nombre de la base de datos global, esta función consulta el diccionario global creado previamente
y genera en forma gráfica un árbol cuya ratz reprmenta el nombre de la base de datos global
y sus hojas las tablas globales que la componen, si el usuario global selecciona una tabla ésta
127
muestra la información que se extrae de las tablas locales que mapean a la tabla global.
Todos estos logros son unidos en una sola aplicación que representa el ambiente multibase
de datos que se alcanzó con este trabajo de tesis.
9.3 Alcances logrados
Los alcances logrados con respecto a los propuestos inicialmente fueron cubiertos de la
siguiente manera:
1.- Eliminar las heterogeneidad semántica correspondiente a los problemas de cinoniniias y
homonimias de los nombres de tablas y atributos. Esto lo solucionamos al momento de definir el
esquema de la base de datos global, señalando en los enlaces con las bases de datos locales qué
tablas locales mapean a las tablas globales y, a su vez, dentro de cada tabla local qué atributo
local mapea al atributo perteneciente a la tabla global.
2.- Eliminar las heterogeneidades con respecto a los conflictos de tipo entre los atributos,
sólo se permite integrar tipos númericos (int, uint y real) a tipo carácter (char(1ongitud)) o
viceversa. Estos formatos de tipos son tomados de la gramática del mSQL, que es el SMBD que
pedimos asignen a la base de datos global al momento de definir su esquema.
3.- El sistema multibase de datos puede integrar a todos los SMBD que están organizados
con el modelo relacional. Además debe existir u11 manejador JDBC para entablar la comuni-
cación a través de la dirección de la máquina donde se encuentre trabajando el SMBD.
4.- El usuario tiene acceso a la información definida en el esquema de la base de datos
global por medio de una interfaz (que en un principio se propuso en lenguaje C pero para poder
obtener una aplicación 100% transportable se cambió al lenguaje Java) y realizar operaciones
de SELECT, INSERT, DELETE y UPDATE.
5.- El sistema genera un diccionario del esquema de la base de datos global que representa
una metainformación de las base de datos pertenecientes a los SMBD locales.
6.- La comunicación entre las diferentes plataformas se logró utilizando el API JDBC de
128
Java permitiendo a1 sistema multibase de datos crecer sobre el dominio de Internet.
9.4 Recomendaciones
Para lograr un mejor uso del sistema miiltibase de datos de esta tesis, e5 necesario que al
momento de definir el esquema de la base de datos global se necesita asignar un SMBD a la
base de datos global, para que el generador de subtransacciones locales lo utilice en algunas
transacciones que se uemi te inapear la información de las tablas locales a las tablas globales
temporales, En el SMBD a asignar debe existir una base de datos a donde el usuario tenga
derecho de crear y borrar tablas.
La tabla local a enlazar puede tener un mayor grado de atributos que la tabla global, pero
no lo contrario.
Al momento de realizar alguna operación con el DML debe el usuario tener conocimiento
de que todos los SMBD locales se encuentran activos en la dirección de la máquina que tiene
asignada en el diccionario global, para no generar ningún error.
El sistema puede ser transportado a cualquier plataforma, s61o necesita que se encuentre el
JDK l . l x correspondiente a esa plataforma y las clases swing 1.1 para lograr la ejecución de la
aplicaciún.
Si desean hacer modificaciones sobre los lenguajes DDL y DML necesitan tener conocimiento
de cómo funciona el intérprete JavaCC y lenguaje Java, porque los intérpretes de estos lenguajes
fueron desarrollados en JavaCC y al niomento de interpretarlos genera el cúdigo correspondiente
en Java.
Si las modificaciones se quieren realizar sobre el editor muitibase de datos, es necesario
tener conociniientos del lenguaje Java y la utiliwición del nuevo AWT de Java 1.1, porque la
creación de objetos cambia de las versiones de Java 1.0 al 1.1.
129
9.5 Trabajos futuros
Dentro del contexto de sistemas multibace de datos existen 4 áreas de investigación, éstas
son: integación de esquemas; optimización de consultas; multibase de datos orientadas a objetos
y manejo de transacciones. Dentro de cada una de ellas puede surgir una diversidad de -
propuestas para consolidar un sistema multibase de datos más robusto. A continuación se
proponen algunas ideas que permiten mejorar este trabajo de tesis con respecto al área de
integración de esquemas.
* Aumentar la cantidad de tipos de datos a integrar tomando en cuenta que los pueda
soportar el API JDBC.
* Resolver problemas de integración de esquemas que correspondan a conflictos de valor de
los datos.
* Resolver problemas de integración de esquemas que correspondan a conflictos de nivel de
abstracción.
* Resolver problemas de integración de esquemas que correspondan a conflictos de discrepancia
esquemática
Las soluciones propuestas en la literatura para algunos de los problemas anteriores muchas
veces van a necesitar la ejecución de transacciones de SELECT anidados o cláusulas WHERE
mucho ni& completas que con la que cuenta el sistema multibase actual.
E1 formato actual fue tomado de la sintaxis del mSQL para que formara parte del ambiente
multibase de datos. El mSQL como otros SMBD aún no soportan formatos de transacciones
complejas, pero si los siguientes proyectos proponen que en el ambiente multibase de datos exista
la posibilidad de trabajar con SMBD como mSQL en conjunto con SMBD mucho más robustos
(Oracle, Informix, Sybase y otros) una sugerencia es que deben contemplar la generación de
código para transportar las tablas locales temporalmente a otro SMBD más robusto y realizar
las transacciones emitidas por el usuario global.
130
Parte I
Apéndice A
131
Archivos para definir bases de datos globales
Archivo I
A contuaciún se muestra el archivo que analizo el DDL para genarar el diccioiiario global
de la base de datos baseprueba
DRIVER: con~.imaginary.sql.msql.MsqlDriver URL: jdbc:msql://148.208.92.104:1114/company USERNAME: acimal PASSWORD: aclmal CREATE SCHEMA AUTHORIZATION baseprueba
CREATETABLETABLA1 (nombrecli CHAR(10), numerocli CHAR(15), tipocli INT, ); CREATE TABLE TABLA2 (nombrepro CHAR(10), nombrecli CHAR(lO), numerocli CHAR(15), numeropro INT, );
DRIVER: com.imaginary.sql.msql.MsqiDrivei. URL: jdhc:msql//148.208.92.104: 1114/company USERNAME: aclmal PASSWORD: aelmal CREATE SCHEMA AUTHORIZATION COMPANY
CREATE TABLE proye TABLAl ( nombre CHAR(20)=iiomhrecli, numero CHAR(S)=numerocli, tipo CHAR(lO)=tipocli, ); CREATE TABLE almacen TABLA2 ( prov CHAR(20)=uombrepro, cli CHAR(20)=nombrecli, cc CHAR(Z)=numerocli, cp CHAR(Z)=numeropro, );
(
(
(
)
DRIVER connect.microsoft.MicrosoftDriver URL: jdbc:ff-microsoft//148.208.92.82: 1433/PRUEBA
CREATE SCHEMA AUTHORIZATION PRUEBA
CREATE TABLE pro1 TABLAl ( nom CHAR(25)=nombrecli, num INT=niimerodi, tipo INT=tipocli, ); CREATE TABLE bodega TABLA2
USERNAME: LUCERO PASSWORD: LUCERO
(
132
( proveedor CHAR.(ZO)=nombrepro, cliente CHAR(ZO)=nombrecli, clavecli INT=niimerocli, clavepro INT=numeropro, ); ) ); )
Archivo 2
A contuación se muestra el archivo que analizo el DDL para genarar el diccionario global
de la base de datos basesem
DRIVER: com imaginary.sql.msql.MsqlDriver ' URL: jdbc:rnsql://148.208.92.1041114/company
USERNAME aclmal PASSWORD: aclmal CREATE SCHEMA AUTHORIZATION basesem ( CREATE TABLE carreras ( carrera CHAR(4), descripuon CHAR(30), ); CREATE TABLE planes ( carrera CHAR(4), clave INT, ); CREATE TABLE materias ( clave INT, materia CHAR(%), creditos CHAR(2), ); CREATE TABLE alumnos ( matricula iNT, carrera CHAR(4), nombre CHAR(40), edad INS, );
CREATE TABLE profesores ( nempleado INT, nombre CHAR(20), edad INT, title CHAR(2O), ); CREATE TABLE salones ( salon CHAR(.?), cupo INT, );
( clave INT, matricula INT, nempleado INT, salon CHAR(.?), );
CREATE TABLE grupos
( DRIVER oracle.jdbc.driver.OrRcleDriver
133
URL:jdbc:oracle:thin:@(description=( address=(host=academOl.mor.itesm.m) (protocol=tcp)(port=1521))(connect_data=(sid=Mor))) USERNAME a1372422 PASSWORD: a1372422 CREATE SCHEMA AUTHORIZATION MOR
CREATE TABLE licenciatura carreras (
( clavel CHAR(iO)=carrera , nombre1 CHAR(SO)=descripcion , ); CREATE TABLE convenio planes
( clavel CHAR(10) =carrera, clavecon INT=clave, ); CR.EATE TABLE asignatura materias ( clavecon INT=clave, nomasig CHAR(ZO)=mnteria , carga CHAR(2)=creditos, ); CREATE TABLE pupilos alumnos ( nocontrol CHAR(4)=matricula, clavel CHAR(lO)=carrera , nompupi CHAR(SO)=nombre , ed CHAR(2)=edad, );
CREATE TABLE maestros profesores ( clavemp CHAR.(4)=nempleado, nombremp CHAR (SO)=nombre, edad CHAR(2)=edad, titulo CHAR(30)= title, ); CREATE TABLE aula salones ( noaula CHAR(2) = salon, total CHAR(3) = cupo, );
( noaiiln CHAR(2)=salon, noconbroi CHAR(4)=matricula, clavemp CHAR(4)= nemplendo, clavecon INT= clave, );
CREATE TABLE clase grupos
)
DRIVER com.imaginary.sql.msql.MsqlDriver URL: jdbc:msql://148.208.92.104:1114/admesco USERNAME. aclmal PASSWORD: aclmal CREATE SCHEMA AUTHORIZATION admesco
CREATE TABLE area cnrrerss ( ciavearea CHAR(G)=cnrrera , nombrearea CHAR(45)=desiripcion ~ ); CREATE TABLE licenciatura planes ( ciavearea CHAR(G) =carrera , cinveic CHAR@)=clave, ); CREATE TABLE materia materias ( clavelc CHAR(B)=clave,
(
134
nomst CHAR(30)=rnat,eria , carga INT=creditos, ); CREATE TABLE ingreso alumnos ( claveingreso CHAR(4)=matricda, elavearea CHAR(G)=carrera , nombre CHAR(30)=nombre , edad CHAR(Z)=edad, );
CREATE TABLE empleado profesores ( nocontrol lNT=nempleado, nombre CHAR(40)=nombre, anos CHAR(3)=edad, nivel CHAR(25)= title, ); CREATE TABLE sala salones ( nosals INT = salon, cupo INT = cupo, );
CREATE TABLE seminario grupos ( nosala INT=salon,, claveingreso CHAR(4)=matricula, nocontrol INT= nempleado, clsvelc CHAR@)= clave, ); ) ); (
DRIVER connect,.microsoft.MicrocoftDriver URL: jdbc:ff-microaoft//148.208.92.82: 1433/SERES USERNAME: LUCERO PASSWORD: LUCERO CREATE SCHEMA AUTHORlZATlON SERES ( CREATE TABLE profesional carreras ( ciavepro CHAR(4)=earrera , nombrepro CHAR(30)=descripcion , ); CREATE TABLE reticula planes ( clavepro CHAR(4) =carrera, clavere CHAR,(d)=clnvc, ); CREATE TABLE carga materias ( clavere CHAR.(d)=dnve, nombrecarga CHAR(25)=materia , valor CHAR(Z)=creditos, ); CREATE TABLE estudiantes alumnos ( claves INT=matricula, clavepro CHAR(rl)=carrera' , nombrest, CHAR(dO)=nombre , edad INT=edad, );
CREATE TABLE catedratico profesores ( clavect, INT=nempleado, nonibrect CHAR(ZO)=nombre, anos CHAR(3)=edad, nivel CHAR(25)= title, );
( npgrupo CHAR(3) = salon, capacidad CHAR(3) = cupo, );
CREATE TABLE grupos salana
135
CREATE TABLE calse grupos ( npgriipo CHAR(3)=salon, claves INT=rnatricula, clavect INT= nempleado, clavere CHAR(4)= clave, ); )
136
Parte I1
Apéndice B
137
Archivos generados por los’casos de prueba
Archivo 1
Archivo que se generó al monieiito de ejecutar la prueba 1
1 1.1 com.imaginery.sql.msql.M~qlDri~~er jdbc:msql://148.208.92.104 1114/company aclmal aclmal Create table carreras ( carrera char(4), descripcion char(30) ) oracle.jdbc.driver.OracleD~ver jdbc:oracle:thin:~(description=(address=(host=acadeniOl mor.itesm.~~)(protocol=tcp)(port=1521))(connect_data=(sid=Mor))) a1372422 a1372422 select clavel, nombre1 from licenciatura corn.imaginary.sql.msql.MsqlDriv~~ jdbc:msql://148.208.92.104:1114/company aclmal acimal Insert into carreras values ( ’ array[O] ’ , ’ array[i] ’ ) com.imaginary.sql.msql.MsqlDriver jdbc:msql//148.208.92.104:1114/admesco aclmal aclmal select clavearea, nombrearea from area com.imaginsry.sql.msql.Msq1Driver jdbc:msql://l48.208.92.104: 1114/company aclmal aclmal Insert into carreras values ( ’ array[0] ’ , ’ array[i] ’ ) connect.microsoft.MicrosoftDriver jdbc:ff-microsoft://l48.208.92.82:1433/SERES LUCERO LUCERO select clavepro, nomhrepro from profesional com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104 1114/company aclmal aclmal Insert into carrerss values ( ’ array[D] ’ , ’ array[i] ’ ) 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msql//148.208.92.l04lil4/company aclmal aclmal SELECT DISTINCT cnrreras.carrera, carreras.descripcion FROM earrerss com.imaginary.sql.Insql.MsqlDriver jdbc:msq1//148.208.92.104:1114/company aclmal admal Drop t,able carreras 1
Archivo 2
Archivo que se generó al momeiito de ejecutar la prueba 2
1 1.1 com.imaginary.sql.msql.MsqlDriver jdhc:msql://148.208.92.104 11 14/company aclmal aclmal Create table materias ( clave int, materia char(25), creditos char(2) ) oracle.jdbc.driver.OrncleDriver jdhc:oracle:thin:~(description=(address=(host=academ01 mor.itesm.mx)(protocol=tep)(port=1521))(connect~data=(sid=Mor))) a1372422 a1372422 select davecon, nomssig, carga froni asignatura com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Insert into materias values ( array[O] , ’ array[i] ’ , ’ array[2] ’ ) com.imaginary.sql.msq1.MsqlDriver jdbc:msqi://148.208.92.104 11 14/admesco aclmal aclmal select clavelc, nomat, carga from materia com.imaginnry.sql.msql.Msq1Driver jdbc:msq1://148.208.92.104 1114/company aclmal aclmal Insert int.0 materias values ( array[0] , ’ array[i] ’ , ’ array[2] ’ ) connect.microsoft.MicrosoftDriver jdbc:ff-microsoft://148.208.92.82:1433/SERES LUCERO LUCERO
138
select clavere, nombrecarga, valor from carga com.imaginar~.cql.mcql.MsqlDriver jdbc:msql://148.208.92, 104:i i 1 4 / ~ ~ ~ ~ ~ ~ ~ aclmal aclmal Insert into mat,erias valnes ( array[O] , ' array[i] ' , ' array[2] ' ) 1.1 1.1 com.im~ginar~.sq~.msql.MsqlDriverjdbc:msql://148.208.92. i04:ii14/company aclmal sclmal Create table planes ( carrera cbar(4), clave int ) oracle.jdbc.driver.OracleDnver jdbc:oracle: thin:co(dcscnption=(address=(bost=academOl mor.itesm.mx)(protocol=tc~)(port=1521))(connect~d~ta=(sid=Mo~))) a1372422 a1372422 select clavel, clavecon from convenio com.imaginary.sql.msq1.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Insert into planes value ( ' array[O] ' , arrsy[i] ) com.imaginary.sql.msql.MsqlDriver jdbc:msqi://148.208.92.104 1114/admesco aclmal aclmal select; clavearea, clavelc from licenciatura u>m.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 1114/company acimal ailmal Insert into planes values ( connect.microsoft.MicrosoftDriver jdbc:K-microsoft://l48.208.92.82:1433/SERES LUCERO LUCERO select clavepro, clavere from reticula com.imaginary.sql.msql.Msq1Driver jdbc:msqi://148.208.92.104:1114/company aclmal aclmal Insert into planes values ( ' array[O] ' , array[l] ) 1.1 com.imaginsry.sql.msql.MsqlDrive~ jdbc:msql://148.208.92.1041114/company aclmal aclmal SELECT DISTINCT materias.clave, planes.carrera, materias.materia FROM materias, planes M1HER.E mate&s.creditos ='6' AND materias.clave =planes.clave Lon,.iinaginary.sql.msql,MsqlDriver jdbc:msql://148.208.92.104:1114/CO~P~ ncbnal adma1 Drop table matenas com.ima~nary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/ComPanY ~ l m a l dmR1 Drop table planes 1
array[O] ' , array[i] )
Archivo 3
Archivo que se generó al momento de ejecutar la prueba 3
4 4.1 oracle.jdb<:.driver.OracleDnver jdbc:oracle:tbin:e(description=(add~~=(hnst=a~ademOl mor.item.mx)(protocol=tcp)(port=l52l))(conn~t~dat~=(sid=Mor))) a1372422 a1372422 Update asignat,ura set nomasig = 'COMPUTACION-I' where nomasig = 'COMPUTACION-1' 4.1 4.1 eom.iniaginary.sql.msql.MsqlD>river jdbc:msql://148.208.92.104:1114/admesco aclmal aclmal Update materia set nomat= 'COMPUTACION-I' where nomat,='COMPUTACION-1' 4.1 4.1 eonIiect.inicrosoft.MicrosoltDriver jdbc:ñ-microsoft://148.208.92.82:1433/SER.ES LUCERO LUCERO Update carga set nombrecarga = 'COMPUTACION-I' where nombrecarga =
139
'COMPUTACION-1' 4.1 4 1 1.1 com,imaginary,sq~.m~ql.MsqlDriver jdbc:msql://148.208.92.104:~~~4/CO~PanY aclmal aclmal Create table materias ( clave int, mat,eria char(25), creditos d a r ( 2 ) ) oracle.jdbc.driver.Ora~~~Driver jdbc:oracle:thin:~(descript¡nn=(address=(host=academOl mor.i~esm.mx)(protoco~=tcp)(port=1521))(connect_data=(sid=M~r))) a1372422 a1372422 select clavecon, nomasig, carga from asignatura corn.imaginary.sql.msql.MsqlDrive~ jdbe:msql://l48.208.92.i04:1114/company ailma1 aclmal Insert into materias values ( array[^] , ' array[i] ' , ' array[2] ' ) com.imaginary.sql.msql.~lDriver jdbc:msql://148.208.92.104: 1114/admesco aclmal a c h a l select ciaveic, nomat,, carga from materia com.imaginary.sql.msql.MsqlDriver jdb~:msq1//148.208.92.104:1114/company aclmal aclmal insert into materias values ( array[o] , ' array[i] ' , ' array[2] ' ) conneit.microsoft.MicrosoStDriver jdbc:ff-microsoSt//l48.208.92.82:1433/SERES LUCERO LUCERO select clavere, nombrecargs, valor from carga com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 1114/company aclmal aclmnl Insert into materias values ( array[O] , ' array[i] ' , ' srray[2] ' ) 1.1 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msq1//148.208.92.104 1114/company aclmal aclrnai Create table planes ( carrera &ar(4), clave int ) oracle.jdbc.driver.Orac1eDriver jdbe:oracle:thin:~(deccription=(address=(host=academOl mor.itesm.mx)(prot,ocol=tcp)(port=i 52l))(connect_data=(sid=Mor))) a1372422 a1372422 select clavel, ciavecon from convenio corn.iinaginary.cql.msql.MsqlDriver jdbc:msql://148.208.92.104: 1114/company aclmal aclmal Insert into planes values ( ' array[O] ' , array[i] ) com.imaginary.sql.insql.MsqlDriver jdbc:msql://148.208.92.104:1114/admesco silmal a c h a l select clavearea, clavelc from licenciatura eom.imaginary.sql.msql. MsqlDriver jdbc:rnsql: //148.208.92.104: 1114/company aclmnl aclmal Insert into planes values ( ' array[O] ' , array[i] ) connect.niicrosoft.MicrosoStDriver jdbc:ff-microsoSt://l48.208.92.821433/SERES LUCERO LUCERO select davepro, clavere from reticula com.imaginary.sql.msql.MsqlDriver jdbc:rnsqi://148.208.92.104:1114/company achal aclnid Insert into planes values ( ' army[O] ' , array[i] ) 1.1 ~om.imaginary.sql.msql.MsqlDriver jdbc:msqi://148.208.92.104:1114/company aclmal sdmal SELECT DISTINCT materias.clave, pianes.carrera, materias.materia FROM mateeas, planes WHERE materias.creditos ='6' AND materias.clave =pianes.clave com.iinaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104: 11 14/cornpany m h a l admal Drop table materias com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.l04:lll4/company aclmei aclniai Drop table planes 1
Archivo 4
140
Archivo que se generó al momento de ejecutar la prueba 4
4 4.1
oracle.jdbc.driver.OracleDriver j d b c : o r a ~ e : t h i n : ~ ( d e s c r ~ p ~ ~ o n ~ ( ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ s ~ , ~ ~ c a d ~ m o l ”1or~itesm~mx)(~rotoco~=t~~)(P~~t=~521))(connect~data=(~id=Mor))) a1372422 a1372422 Update asignatiira set clavecon = 130 where davecon =201 4.1 4.2 1.1 com.imaginnry.sql.msq1.MsqlDriver jdbc:msql://148.208.92.104:~ 1 i 4 / ~ ~ ~ ~ ~ ~ ~ aclmal aclmal Create t,able materiasadmesco ( clave int, materia char(25), creditos char(2) ) com.imiiginary.sql.msql.MsqlDriver jdbc:mcql://148.208.92.104: 11 14/admesco aclmal aclmal select clnvelc, nomnt, carga from materia com.imaginary.sql.msql.MsqlDnver jdbc:msql://148.208.92.104:1114/company aclmal aclmal Insert into materiasadmesco vah~es ( array[O] , ’ array[l] ’ , ’ srray[2] ’ ) 1.1 cam .iinaginary.sql.msql.MsqlDnver jdbcmsql: // 148.208.92.104 11 14/company aelmnl aclmal SELECT DISTINCT clave, materia? creditos from materiasadmesco where materia = ‘COMPUTACION-I’ AND clave =201 coni.imaginary.sql.mcql.MEqlDriver jdbc:msql://148.208.92.104l114/company aclinal aclmal Drop t,ahle materiasadmesco com.iniagiiiary.sql.msq1.MsqlDriver jdbc:msql://148.208.92.1041114/company aclmd aclmal Create table materiasadmesco ( clave int, materia &ar(25), creditos diar(2) ) com.iniaginary.sql.msql.MsqlDri,,~~ jdbc:mcql://148.208.92.1041114/company aclmal aclmnl Insert int,o materiasadmesco values ( array[O] , ’ array[l] ’ , ‘ array[Z] ’ ) com.imaginary.cql.msql.MsqlDriver jdbc:msq1//148.208.92.1041114/compnny aclmal aclmal UPDATE materiasadmesco SET ciave=130 com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/con1pnny aclmal aclmal select clave, materia, creditos from materiasadmesco com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.1041114/admesco aclmal aclmal Updat,e materia set clavelc = ’ array[O] ’ , nomat = ’ array111 ’ , carga = array[2] where clavelc = ’ nrray(3j ’ AND nomat = ’ array[4] ’ AND carga = array(51 com.imaginary.sql.msql.MsqlDriv~~ jdbc:msql://148.208.92.104lIl4/company aclmal aclmal Drop table mat,eriasadmesco 4.2 4.2 1.1 com.imsginary.sql.m~l.MsqlDriver jdbc:mcql://148.208.92.104:ll14/company aclmal aclmal Create table materiasSERES ( clave int, mat,eria char(25), creditos char(2) ) connect.microsoft.MicrosoftDriver jdbe:ff-mierosoft://148.208.92.82:1433/SER.ES LUCERO LUCERO select clavere, nombrecarga, valor from carga com.imaginary.sqI.msql.MsqlDrivcr jdbc:msql://148.208.92.104:lll4/company aclmal aclmal Insert into materiasSERES values ( arraylo] , ’ array111 ’ , 1 .I coin.iniagin~~y.sql.msql,MsqlD~iv~~ jdbc:msq1://148.208.92.104: 1114/company aclmal acinial SELECT DISTINCT clave, materia, creditos from materiasSERES where mat,eria = ‘COMPUTACION-I‘ AND clave =201 com.imnginary.sql.msql.MsqlDriver jdbc:msq1//148.208.92.104:1114/company aclinal acimal
=’COI\IpUTACION-I’ AND
array[2] ’ )
141
Drop table materiasSERES com.imeginary.sql.msql.MsqlDriver jdbc:msq1//148.208.9~.104:1114/u>mpany achnal acimni Create table materiasSERES ( clave int, materia char(25), creditas char(2) ) com.imaginary.sql.rnsql.MsqlDriver jdbc:msq1://148.208.92.1041114/company achnal acimal Insert into materiasSERES values ( array[O] , ' array[l] ' , ' array[2] ' ) com.imaeinarv.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclrnal aclmal I " . UPDATE materiasSERES SET clave-130 com,imaginary,sq~.msql.MsqlDriv~r j d b c : m s q l : / / 1 4 8 . 2 0 8 . 9 2 . l ~ ~ ~ ~ ~ ~ / c o n i p ~ ~ ~ aclnial select dave, materia, creditos from matenasSEREs connect,microsoft.~~icrosoftDriver jdl>e:ff-microsoft//148.208.92.82:1433/SERES LUCERO LUCERO Update carga set clavere= ' array[O] ' , nombrecarga= ' array[l] ' , valor= ' array[2] ' where clavere = ' array[3] ' AND nombrecarga = ' array[4] ' AND valor = ' array[5] ' ~om.imaginary.sql.msql.MsqlDriver jdhc:msql://148.208.92.1041114/company achnal aclmal Drop table materiasSERES 4.2 4 2 oraele,jdhc.driver.OracleDr~ver jdhc:oracle:thin:@(description=(address=(host=acad~n~Ol mor.itecm.mx)(~~rotocol=tcp)(port=152l))(connect_data=(sid=Mor))) a1372422 a1372422 insert into convenio ( clavel, clavecon) values ( 'IBQ', 130 ) com.imaginary.sql.msql.MsqlDriver jdhc:msql://148.208.92.104 1114/admesco aclmal aclmal insert into licenciatura ( clavearen, clavelc) values ( 'IBQ', '130' ) connect.microsoft.MicrosoftDriver jdbc:ff-microsoft://l48.208.92.82:1433/SERES LUCERO LUCERO insert into reticula ( clavepro, clavere) values ( 'IBQ', '130' ) 2 1 1.1 ~m.imaginary.cql.msqlql.MsqlDriver jdhc:msqI://148.208.92.104: 11 14/company achnal aclmal Create table materias ( clave int, materia char(25), creditos char(2) ) oracle.jdhc.driver.Orac1eDriver jdbc:oracle:thin:@(description=(addres=(host=academ01 mor.it~esm.n1x)(protocol=tcp)(part=l52l))(~onnect_d~ta=(sid=Mo~))) a1372422 si372422 select clavecon, nornasig, carga from asignatura com.imaginary.sql.mcq1.MsqlDriver jdbc:msql//148.208.92.104:1114/company aclmal aclmal Insert indo materias values ( array(O] , ' array(i] ' , com.imaginary.sql.msql.MsqiDriver jdbc:msql://148.208.92.104:1114/admesco a c h a i ailmal select clavelc, nomat, carga from materia com.imnginary.sql.msql.MsqlDriver jdhc:msql://148.208.92.104: 1114/compsny aclmal aclmal Insert into materias values ( arraylo] , ' array[I] ' , ' array[2] ' ) connect.microsoft.MicrosoftDrive~ jdbc:ff-microsoft//148.208,92.82:1433/SE~S LUCERO LUCER.0 select clavere, nombrecarga, valor from carga rñim.imaginary.sql.msql.MsqlDriver jdbc:rnsql://148.208.92.104:1114/company acimal aclmal Insert into materias values ( array[O] , ' arrny[i] ' , ' arrny[2] 1.1 1.1 com.imaginary.sq1.msql.MsqlDriver jdbc:msq1//148.208.92.1041114/cornpany aclmal admsl Create table planes ( carrera diar(4), clave int ) oracie.jdbc.driver.Orac1eDriver jdbc:oracle:thin:@(description=(address=(hoct=academOl mor.itesm.mx)(protocol=tcp)(port=1521))(eonnect_data=(sid=Mo~))) a1372422 a1372422
array[^] ' )
)
142
select clavel, clavecon from convenio coni.imaginary.sql.nisql.MsqlDriver jdbc:msqi://148.208.92.104:1114/conipany aclmai aclmal Insert into planes values ( ’ array[O] ’ , array[i] ) com.imaginary.sql.msql.Msq1Driver jdbc:mcql://148.208.92.104:1114/admesco aclmal aclmsl select clavearea, clavelc from licenciatura ~~~.~~~~~~ry.~~~.~~~~.~sqlD~i~erjdbc:msql://148.208.92.104:1114/com~any a c h a i aclmal Insert into planes values ( ’ array[O] ’ , array[l] ) connect~.microsoft~.MicrosoftDriverjdbc:ff-microioft://l48.208.92.82:1433/SERES LUCERO LUCERO select clavepro, clavere from reticula com.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104:1114/company aclmsl aclmai Insert into planes values ( ’ array[O] ’ , array[i] ) 1.1 com.imaginary.sq1.msql.MsqlDriver jdbc:nisql://148.208.92.104 lll4/company aclmal aclmsl SELECT DISTINCT materias.clave, planes.carrern, mnter¡as.materia FROM materias, planes WHERE materias.creditos =’6’ AND materias.clave =planes.clave com.imaginary.sql.msql.AfsqlDriver jdbc:msqi://148.208.92.104: 1114/company aclmal aclmal Drop table materias com.iinaginary.sql.msqi.~lDriver jdbc:msql://148.208.92.104 1114/company nclmal aclmal Drop table planes 1
Archivo 5
Archivo que se generó al momento de ejecutar la prueba 5
3 3.1 oracle.jdbc.dr¡ver.OracleDr¡ver jdbcoracle: thin:@(d&cription=(addrffs=(host=academOl mor.itesm.mx)(prot,ocol=tcp)(port=1521))(conneet~data=(aid=Mor))) a1372422 al372422 DELETE FROM convenio where clrivel =’IBQ’ AND elavecon =130 3.1 3.2 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msqi://148.208.92.104 lll4/company aclmal aclmal Create tlible planesadmesco ( carrera cbar(4), clave int ) com.im~ginary.sql.msql.MsqlDriver jdbc:msq1://148.208.92.1041114/admesco aclmal aclmal select clavearea, clavelc from licenciatura com.imaginary.cql.msql.MsqlDriver jdbc:msql://148.208.92.1041114/compan~ aclmal admal Insert into planesadmesco values ( ’ array[O] ’ , arrayll] ) 1.1 com.iniaginary.sql.msql.MsqlDr¡v~r jdbc:msql://148.208.92.104:1114/company aclmal aclmal SELECT DISTINCT carrera, clave from planesadmesco where carrera =’IBQ’ AND clave =130 com.ima~nary.sql.msql.MsqlDriver jdbc:msql://148.208.92.1041114/company aclmal aclmal Drop table planesadmesco com.imaginary.sql.msql.MsqlDriver jdbc:nisql://148.208.92.1041114/admesco aclmal aclmal DELETE FROM licenciatura WHERE clavesrea=’ array[O] ’ AND clavelc=’ array[l] ’ 3.2 3.2
143
1.1 com.imaginary.sql.msql.MsqiDriv~r jdhc:msql://148.208.92.104:1114/company aclmai acimnl Create table pianffiSERES ( carrera char(4), clave int ) eonnect.microsoft.MicrocoftD~ver jdbc:5-microsoft://148.208.92.82:1433/SERES LUCERO LUCER.0
com,ima~nary.sq~.msql.MsqlDriver jdhc:mcql://148.208.92.1041114/comPanY aclmal adma’ Insert illto planesSERES values ( ’ arra~[01 ’ , arraY[ll ) 1.1 coni.imaginary.sqi.ms~l.MsqlDriver jdhc:msql://148.208.92.104:1114/comPanY aclmal SELECT DISTINCT carrera, clave from planesSERES where Carrera =‘IBQ’ AND clave =I30 com.imaginary.sql,msql.MsqiDr¡v~r jdbc:msq1//148.208.92.104 1114/company adma1 admai Drop table planesSERES connect.microsoft.MicrosoftDriver jdhc:ff-microsoft://148.208.92.82:1433/SERES LUCERO LUCERO DELETE FROM reticula WHERE clavepro = ’ array[O] ’ AND clavere = ’ array[l] ’ 3.2 3 1 1.1 coni.imaginary.sql.msql.MsqlDriver jdbc:msql://148.208.92.104 1114/company acimai acimal Create table materias ( clave int, materia die@), creditos diar(2) ) oracle.jdbc.driver.0racieDriver jdbc:orncle: thin:t3(description=(address=(host=academOl mor.itffiin.mx)(protocol=tcp)(port=152l))(connect_data=(sid=Mor))) ai372422 ai372422 select clavecon, nomasig, carga from asignatura com.imaginary.sql.msql.MsqlDriver jdhc:msqi://148.208.92.104:1114/company acimal aclmal Insert into materias values ( array[O] , ’ array[i] ’ , ’ array[^] ’ ) comimagiiiary.sql.nisql.MsqiDriver jdbc:msql://148.208.92.104 1 Il4/admffico aclmal aclmal select claveic, nomat, carga from materia com.imaginary.sqi.msqi.McqlDriverJdhc:msqi://148.208.92.104:1114/compauy achnal aclmai Insert into materias values ( array[O] , ’ array[i] ’ , ’ array[2] ’ ) connect.microsoft.MicrosoftDriver jdbc:5-microsoft://l48.208.92.82:1433/SERES LUCERO LUCERO select davere, nomhrecarga, valor from carga com.imagina~.sqi.msqi.A~sqiDriverjdbc:msqi://148.208.92.104:1114/co~pany sclmai aciinai Insert into materias values ( array[O] , ’ array[^] ’ , ’ array(21 ’ ) 1.1 1.1 com.imaginary.sqi.insql,MsqlDriver jdbc:msql://148.208.92.104: lli4/company a c h s l aclmal Create table planes ( carrera char($), dave int ) oracie.jdbc.driver.OrscleDriver jdhcoracie: thin:(o(dfficription=(address=(host=aclid~mOl mor.it.es1n.mx)(protocol=tcp)(port~=1521))(connect~data=(sid=l\.Ior))) a1372422 a1372422 select clavel, clavecon from convenio com.imaginary.sqi.msql.MsqlDriver jdbcmsqi: //148.208.92.l04:lll4/cornpany aclmal aclmai Insert into planes values ( ’ arrny[O] ’ , array[^] ) com.imaginary.sqi.msql.Msq~riv~r jdhc:msqi://148.208.92.104:lll4/admesco aclmal aciinal select clavearea, ciavelc from licenciatura com.imaginary.sql.msqi.MsqlDriver jdhc:msqi://148.208.92.104 1114/company achnal aclmai Insert into planes values ( ’ array[O] ’ , array[i] ) connect.microsoft.MicrosoftDriver jdbc:ff-microsoft://148.208.92.821433/SERES LUCERO
clavepro, ciavere from reticula
144
LUCERO select clavepro, clavere from ret,icuia com.imagiiiary.sql.msql.MsqlDrives jdbc:msql://148.208.92.104:1114/company aclmal aelmnl Insert into planes values ( ’ array[ü] ’ , array[i] ) 1.1 com.imaginary.sql.msql.MsqlDriver jdbc:msqI://148.208.92.104:1114/company aclmal aelmal SELECT DISTINCT materias.clave, planes.esrrera, materias.materia FROM mnterias, planes WHERE mat,erias.creditoc =’6’ AND materias.clave =plaiies.clave com.imaginary.sql.msql.~qlDriver jdbc:msql://148.208.92.104:1114/company aclmd aclmal Drop table materias com.imaginary.sql.msql.MsqlDriv~~ jdbc:msql://148.208.92.1041114/company adma1 aclnial Drop table planes 1
145
Parte I11
Apéndice C
146
Pseudoc6digos para la generaciún y ejecución de la operaciones
globales (SELECT, INSERT, DELETE y UPDATE).
Archivo 1
de pseudocódigo para la generación de código de la operación SELECT. if transaccibn-global = SELECT
- /* inserta en el archivo la bandera que identifica la operación SELECT*/ - insert in archivo(1); - /*tenemos la lista de tablas globales del FROM*/ - lista-tablas = lista-tablas-FROM; - /*tenenlos la lista de las bases de datos locales del diccioiiario*/ - bass-locales = bases-locales-diccioneno;
- do -- t,abla-global = lista-t.ablas[i]; -- /*se crea la tabla global tempora*/ -- insert in archivo (1.1); _ _ insert in archivo (CREATE de la tabla-global); _- /*se bace una biisqueda en cada base de datos local para saber */ -- /*si euis1.e una tabla local mapeando a la tabla global*/
- - do - -_ base-local = bases-localesb]; - -_ resultado = buscar-tabla-mapeo(base_local, tabla-global); - _ _ if resultado = verdadero
I
- ¡ = O ;
- - j = O ;
insert in archivo (SELECT tabla local); t
I
_-- _ - -_ - _- - insert in archivo (INSERT tabla.global); - _ - - _ - j = j + l ; _- ]while (bases-localsb] != ""); _ _ insert in archivo (1.1): _ _ i = i + l ; - while(lista-t~ablas(i] != ""); - /*El código que se genero anteriormente fue para tener hechas las tablas globales del FROM*/ - /*sobre ellas se enviará a ejecutar la operación SELECT del usuario global*/ - insert in archivo (SELECT original); - / *se genera c6digo pars el borrado de lac tablas globales temporales*/ - do -- tabla-global = lista-tablas[i]; _ _ insert in archivo (DROP tabla-global); -- i = i + 1; - ] while (list,a-tablas[i] = ""); -insert in archivo (1);
1 147
Archivo 2
Bloque de pseudocódigo para la generación de código de la operación INSERT if transacción-global = INSERT
- /' inserta en el archivo la bandera que identifica la operación INSERT*/ - insert in archivo(2); - /*tenemos la lista de las bases de datos locales del diccionario*/ - bases-locales = bases-locales-diccionario; - tabla-global = tabla-INSERT-global; - /'se hace una busqueda en cada base de datos local para saber */ - / *s í existe una tabla local mapeando a la tabla global*/ - j = O ; - do -- base-local = bases-local es^]; -- resultado = buscar-tabla-mapeo(bsse-local, tabla-global);
if resultado = verdadero
- _ - - I
- - 1 insert in archivo (INSERT tabla local); _- -
-- j = j + l ; - while (bases-locsles[i] != ""); -insert in archivo'(2);
Archivo 3
Bloque de pseudo código para la generación de código para la operación DELETE. if transacción-global = DELETE
- /* inserta en el archivo la bandera que identifica la operación DELETE*/ - insert in archivo(3); - tabla-globa = t,abls-global del DELETE - /'tenemos la lista de las bases de datos locales del diccionario*/ - bases-locales = bases-locales-diccionario; - if no existe cláusula WHERE
-- /*se hace una busqueda en cada base de datos local para saber */ - _ /*si existe una tabla local mapeando a la tabla global*/
- - do - -_ base-local = bases-locales[i]; - -_ resuitado = buscar-tabla-mapeo(base_local, tabla-global);
- 1
j = O ; _-
if resiikado = verdadero - _-
insert in archivo (3.1);
insert in archivo (3.1);
1 --- - _ - _ ---_ insert in archivo (DELETE a la tabla local); - - _-
I - -_ j = j + l ; ---
148
-- while (bases-localesb] != "");
- else /*si existe cláusula WHERE*/ -
- I / *se hace Una busqueda en cada base de datos local para saber */ /*si existe una tabla local mapeando B la tabla global*/ j = O
-_ _ _ _ -
do - _ - -_ base-local = bases-localesb]; - _- resultado = biiscar_tabla-mapeo(base_local, tabla-global);
if resultado = verdadero _ _ - _ _- ' I -_- - if tipo-de-datos-globales = tipo-de-datos-locales
- - -__ /*se genera código de tipo l*/
- - - __ insert in archivo (DELETE a la tabla local WHERE columnas locales);
_ - _ _
insert in archivo (3.1);
insert in archivo (3.1);
-----
- - _ _ - 1
----
_ _ _ _ else /* no coinciden los tipos*/
/*se genera código de tipo 2*/ ---- - - -__ - _ _ _ - insert in archivo (3.2); _ _ _ - - insert in archivo (1.1); - _ _ _ - insert in archivo(CREATE a la t,abla-global); __-- - insert in archivo(SELECT B la tabla-local); _ - _ _ - insert in archivo(1NSERT a la tabla-global); _ _ - _ - insert in archivo(l.1); - - _- - insert in archivo(SELECT a la tabla-global WHER.E del DELETE); __- - - insert in archivo(DR0P a la tabla-global); __- - - insert in archivo(DELETE a la tabla-local WHERE condición AND de todas _ - -__ -_ - -_ - las coliirnnas de la tabla local); _-_- - insert in archivo (3.2);
_ - _ - _ _ - j = j + l ; _- while (bases-locslesb] != ""); - insert in nrchivo (3);
1 Archivo 4
BIoque.de pseudo c&iigo para la generaciún de c a i g o para la operación UPDATE. if transacción-global = UPDATE
- /* iiisertn en el archivo la bandera que identifica la operación IJPDATE*/ - insert in arihivo(4); - tabla-globe = tabla-global del UPDATE; - /*tenemos le lista de las bases de datos locales del diccionario*/ - bases-locales = bases-loeeles-diccionario; - if no existe cláusula WHERE
I
, 149
j = j + i ; - _ _ -_ while (bases-localesb] != ""); - insert in archivo (4);
Archivo 5
Bloque de pseudoc6digo para la ejecuci6n de código de la operaci6n SELECT. select_global(arehivo_select) conaux = O;
- renglón = leer archivo(); - do _ _ _ renglón = leer archivo();
if renglón != 1.1
[
_ _ _ [
1
_ _ _ _ _ _ _ insert,ar in archivoaux.conaux(rengl6n) _ _ _
else _- - hilo-crear-tabla-temporal(archivoaux.conaux) ; conaux = conaux + 1;
_ _ _ _ _ _ _ _ _ _ - _ _ _ - rengl6n = leer archivo(); _ _ _ _ ifrenglóii != 1.1
break [
1
_ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ - while(triie); - renglón = leer archivo(); - ejecutar-coneccion(rengl6u); - rengl6n = leer archivo(); - ejecutar-t.ransacci6n-SELECT(rengl6n); - /*en este momento se genero un archivo que contiene el resultado del SELECT global enviado*/ - insertar in resultado.select(resultado del select); _ _ renglón = leer archivo(); - do[ _ _ ejecutar-eoneccion(rengl6n); _ _ rengl6n = leer archivo(); _ _ ejeiut,ar-transscción_DROP(renglón); -_ renglón = leer archivo(); - while (renglón != EOF) /*pseudo código de la función hilo_crear_tahla-temporal(ardiivoaux.cona~);~/ hilo_crear-tabla- temporal(archivoaux.conaiix)
- rengl6n = leer arehivoaux(); - ejeeutnr-caneccion(rengl6n); - renglón = leer archivonux(); - ejecutar- t,rnnsaecióii- CR EATE(rengl6n); - renglón = leer archivoaux();
151
- do _ _ ejecutar-coneccion(rengl6n); _ _ renglón = leer archivoaux(); _ _ ejecutar-transac~i6n-SELECS(renglón); _ _ /*creación de archivo con el resultado del SELECT anterior*/ _ _ insertat in archivo-resul(resspusta del SELECT); _ _ renglón = leer archivoaux(); _ _ ejecutar_coneicion(rengl6n), _ _ renglón-info = leer archivo-red(); _ _ renglón = leer archivoaux();
_ _ _ transaccion = renglon + renglon-info; / s e introduce la información de la fila*/ _ _ _ ejecutar- transacci6n_IRISERT(transacci6~): _ _ _ renglón-info = leer archivo-resul(); _ _ while(renglón-info != EOF) _ _ _ renglón = leer srchivoaux0; - ]while(renglón != EOF);
do _ _
Archivo 6
Bloque de pseudo código para la ejecución de código de la operación INSERT. insert-global() conaux=O
- renglón = leer archivo(); - do - _ insertar in archivoaux.conaux(rengl6n) -_ renglón = leer archivo(); _ _ insertar in archivoaux.conaux(rengión)
I
_ _ hilo-insertar-tabla-local(archivoanx .conaux); conaux = conaux + 1; - _
-_ rengl6n = leer archivo(); - while(reuglón != EOF);
hilo-insertar- tabla-local(archivoaux.conaux)
- renglón = leer ar&ivosux(); - ejeciitar-roneccion(rengl6n); - renglón = leer sr&ivoaux(); - ejecutar-trunsacción-IRIS~RT(~~ngl6n);
Archivo 7
Bloque de pseudo código para la ejecución de código de la operación DELETE. delete-global()
- renglón = leer archivo();
152
- do 1 if renglón =3.1 - _
--1 dot - -_
insertar in archivoaux.conaux(renglón) renglón = leer archivo();
-_- - - -_- --- while(renglón != 3.1);
conaux = conanx + 1; _ _ - hilo-delete-tipo- l(ardiivoaiix.conaiix)
_ _ -
-- I
- -I else --
do1 - _- ---- insertar in archivoaux.conaux(rengl6n) ---_ renglón = leer archivo(); - -_ while(renglón != 3.2);
conanx = conanx + 1; _ _ _ hilo-delete- tipo-2(archivoaux.r.onaux)
_ _ renglón = leer archivo(); - while(renglón != EOF);
- _- - -
1 hilo-delete- tipo-l(archivoaux.conaux)
- renglón = leer archivoaux(); - ejecutar-coneccion(rengl6n); - renglón = leer archivoaux(); - ejecutar- transacción-DELETE(reng1ón);
hilo-delete- t,ipo-2(srchivoaux.consw<)
-for(; = 1; i<=12; i++)
- _ renglón = leer archivoaux();, -_ insertar archivo-select,()
- select,_global(archivo-select) - /* resiiltado.ceiect es el archivo que contiene los registros que solo cumplieron la cláusula - WHERE del DELETE global*/
~ - renglón = leer archivoaux(); - ejecutar-coneccion(renglón); - renglón = leer ar&ivoaiw(); - renglón-info = leer resnltado.select(); - do - _ _ transaccion = renglon + renglon-info; - -_ /*se introduce la información de la fila local a eliminar*/ - _ _ ejecutar-transacción-DELETE(transacci6n); _-- /* la transacción es una operación DELETE tabla local WHERE condición AND de todas - _ _ las columnas de la tabla,local); _- - renglón-info = leer resultado.select(); -- while(renglón-info != EOF)
t
- 1
- 1
153
1 Archivo 8
~l~~~~ de update-global() - renglón = leer archivo(); - do _ _ if renglón =4 .1
código para la ejecución de código de la operación UPDATE.
- -1 do ---
_ _- - insertar in archivoaux.conaux(rengl6n) _ _ - - renglón = leer archivo(); - _ - )while(rengl6n != 3.1);
conaux = conaux + 1; - _ - hilo -update- tipo- l(archivoaux.conaux)
- - else
_ _-
-- )
- - do _ _ -
_ _ _ _ insertar in archivoaux.conaux(renglón) _ _ _ _ renglón = leer archivo(); _ _ - while(renglón != 3.2);
conaux = conaux + 1; _ _ _ hilo_updat,e_tipo_2(archivooaux,conaux)
-_ renglón = leer archivo(); - )while(renglón != EOF);
hilo-update-tipo- l(archivoanx.conaux)
- renglón = leer archivoami(); - ejecutar_coneccion(renglón); - renglón = leer archivoami(); - ejecutar_transacci6n_UPDATE(renglón);
hilo- UPDATE-tipo- 2( archivoaux.conanx)
- for(i = 1; i<=i2; i++)
- _ renglón = leer archivoaux(); _ _ insertar archivo-select()
- select_global(arc~ivo-select) - /* resultado.select es el archivo que contiene los registros que solo cumplieron la cláusula - WHERE del UPDATE global*/ - renglón = leer archivoami(); - ejecutar-coneicion(reng1ón); - renglón = leer archivoaux(); - ejecutar-t,ransacción CREATE(rengl6n);
- _ - - - )
1
-
-
154
- rengl6n = leer archivoaux0; - ejecut~ar-coneccion(rengl6n); - renglón-info = leer resultadoselect(); - renglón = leer archivoaux(); - do [ _- transaccion = renglon + renglon-info; /*se introduce la información de la fila*/ - _ ejecutar- trancacci6n-INSERT(transacci6n); -_ renglón-info = leer archivo-resulo; - while(renglón_info != EOF) - renglón = leer archivoaux(); - ejcciitar-coneccion(rengl6n); - renglóii = leer archivoaux(); - ejecutar-trnnsacei6u~UPDATE(renglón); - /*es el UPDATE global sobre la información que cumplió la condici6n WHERE* f - renglón = leer archivosu(); - ejecutar-coneccion(rengl6n); - renglón = leer archivoaux(); - ejecutar_transacc¡6n_SELECT(rengl6n); - /*se crea un archivo que contiene el resultado de la información ya modificada*/ - insertar srchivo.rnodi(); - rengl6n = leer archivoaux(); - ejecutar-coneccion(rengl6n); - renglón = leer archivoau(); - rengl6n-info = leer resultado.select(); - rengl6n-set = leer archivo.modi(); - do [ -- transnccion = renglon + renglon-info + renglón-set; _ _ /*se introduce la informaci6n de las filas locales a modificar*/ - - ejeeutar~transacci6n_UPDASE(transacci6n); -- /* la transacci6n es una operación UPDATE tabla local SET información de archivo.modi _- WHERE condición AND de todas las columnas de la tabla local con información del -- archivo resultado.select); - -rengl6n_info = leer resultado.celect.(); - while(rengl6n-info != EOF) - renglón = leer archivoaux(); - ejecutar-coneceion(rengl6n); - renglón = leer archivoaux(); - ejeciitar_trancacci6n_DROP(renglón);
155
Referencias
[l] P.Ram, R.Haraty, B.Panda, V. Goli, and S.Kaliappan. Kb-hydro: An heterogeneous distrib- uted knowledge base system, IBM AS/4OO research Grants 3341-IN-R-09233 and 632207, 1993.
[2] A.Maldonado, Hugo Rivero, and .Juan M. Dim. Reporte tecnico: El sktema de traduccion ejecucion msqi. Instztuto Tecnologico Atitonom0 d e Mexico, 1993.
131 Mohan C. Tutorial: Recent advances in distributed database management. IEEE Computer Siciety Presss, 1984.
(41 Ceri Stefano and Gioseppe Pelagatti. Distributed database principles and sy.stem.3. Mc Graw-Hill, 1985.
[5] Date C.J. lntroduccitn a los sistemas de Bases de datos. Addison-Wesley, 1993.
[6] Ching-Yi, Wang David, and L. Spooner. Access control in heterogeneous distributed data- base management system. Sixth Symp. on Reliability in Distriliuted Software and Database Systems, 1987.
(71 Schaller T., Omran A., Bukhre Ahmed, K. Elmagarraid, and Xiangning Liu. The integra- tion of database systems. Universidad de Purdue CSD-TR-93-046, 1993.
(81 A.R.Hursos, M.W.Bright, and S.Pakzad. Multidatabase systems an advanced solution for global information sharing.
[9] A.R.Hursos, M.W.Bright, and S. Pakzad. A taxonomy and current issues in multidatabase systems. IEEE Computer Society Press, 1992.
156
[io] Witold Litwin and Abdelaziz Abdellatif. Multidatahase interoperahility. Computer vol 19 No. 12 IEEE, 1986.
[11] Garcia Molina Hector and Kogan Boris. Node autonomy in distributed system. Proc. Int’l Symp. on Database in Pamllel and Distributed System, 1988.
[12] M.W. Bright, A.R. Hursos, and S. Pakzad. A taxonomy and current ksnes in mnltidatahase system. Computer Vol. 25No. 23 IEEE, 1992.
[13] W. Litwin. From database system to mukidatabase s.ystems: why and how. Proc, Sjsth British Nat’l Conf. on Database, Cambridge University Press, 1988.
[14] Chen Arhee L. P., Koh Jia-Ling, Kuo Tony, and Chih-Chin. Schema integration and query processing for multiple object database. Department of Computer Science Noiional Tsing Hua University, 1994.
[15] Conrad Stefan, Hoding Michael, Gunter Schmitt, and Ingo Turkr Can. Schema integra- tion with integraty constraints. Institut .fur Technische infonations Systeme Otto-von- Guericke-Universitt Magdeburg, 1998.
[16] Ekengerg Love and Johannesson Panl. Conflictfreeness as a hasic for schema integration. Department of computer and systems sciences, Royal Tmtitute of Technology and Stockholm Uniuersity, 1995.
[17] Hiihns Michel, N. Singh, and Munindar P. The semantic integration of information models. Microelectronics and Computer Techmlogy Corpomtion, 1992.
[is] Johannesson Paul. Schema transformations as an aid in view integration. Department of Computer and Systems Sciences Stockholm University, 1993.
[19] Johannesson Paul. Using conceptual graph theory to support schema integration. Depart- ment of Computer and Systems Sciences Stockholm University, 1994.
[ZO] Iílas Wolfgang, Fischer Gisela, and Aherer Karl. Integrating relational and object-oriented database systems using a metaclass concept. Journal of Systems Integration Vol. 4 No. 4 , 1994.
157
[ Z l ] Liu Ling and Pu Calton. Metadata in the interoperation of heterogeneous data sources, Metadata’%, Dept of computer science, University of Alberta and Dept of C.S.E. Oregon graduate Institute, 1996.
[ZZ] Martin Patrick and Powley Wendy. Cords schema integration environment. Queenis Uni- versity at Kingston, 1995.
[23] Miller R.J., Ioannidis Y.E., and Ramakrishnam R. The use of information capacity in schema integration and translation. Proceedings of the 19yh, VLDB Conference Uniu. of Wisconsin-Madison, 1993.
[24] Miller R.J., Ioannidis Y.E., and Ramakrishnam R. Schema equivalence in heterogeneous systems: Bridging theory and practice. EDBT’94 üniu. of Wisconsin-Madison, 1994.
[Z5] Neild Tania and Henschen Larry. Managing subjetivity in data integration. AIS’97, North- western University, Infograte lnc, 1997.
[26] Sheth Amit and Kashyap Vipul. So far (schematically) yet so near (semantically). Proceed- ings of the IFIP TCZ/WGZ. 6 Conference on Semantics of Interoperable Database Systems, 1994.
[27] Cheth Amit and Kashyap Vipul. Schema correspondences between objects with semantic proximity. Department of computer science Rutgem Uniuer.sity, 1994.
[ZS] Sheth Amit, P. Maecus, and Howard. Berdi: A practical toolkit for schema design, analisis and integration. Belicore Communication Research Piscataway NJ., 1994.
[29] Geogalas Nektarios. Integration distributed data over their semantic idenity. AIS’97, In- formation systems group, departument of computation, University of Manchester, 1997.
[30] Geogalas Nektarios and Loucopoulus. Integration of business operational data using a schema integration technique. International conference on data engineering, 1998.
[31] Ekengerg Love and Johannesson Paul. A formal basis for dynamic schema integration. Department of computer and syfitems sciences, Royal Tnstitute of Technology and Stockholm Uniuersity, 1996.
158
[32] Henschen Lawrence, Fernandes Chis, Neild Tania, and Li Wen-Syan. Modeling data corre spondence in multidatabase systems. Northwestern Univer.?ity, 1996.
1331 Johannesson Paul. A logic based approach to schema integration. Department of Computer and Systems Sciences, Stockholm University, 1992.
[34] Keim Daniel, A. Kriegel, Hans-Peter, and Miethsam Andreas. Integration of relational databases in a multidatabase system based on schema enrichenint. Institute of computer science, University of Munich, 1993.
[35] Seligmau Len and Rocenthal Arnol. A metadata resource to promote data integration. Conference on metadata, 1996.
[36] Visser Pepijn R.S. and Cui Zhan. Heterogeneous ontologystructnres for distributed archi- tectures. University o,f Liverpool and BT Laboratories, 1998.
[37] Visser Pepijn R.S., Jones Dean M., Bench-Capon, and T.J.M. Shave. Accessing heterw geneity by classifying ontology mismatches. AAIA '97 Spring Sysmposium on Ontological Engineering at Stanford University, 1997.
(381 Visser Pepijn R.S., Jones Dean M., Bench-Capon, and T..J.M. Shave. An analysis of ontol- ogy mismatches. University of Liverpool, 1997.
[39] Miller R..J., Ioannidis Y.E., and Ramakrishnam R. Understanding schema. RIDEI.93, 1993
[40] Krishnarnurthy R. and Naqvi S. Towards a real horn clause language. PTOC. 14th. VLDB conf pp. 252-263, 1988.
[41] Krishnamurthy, R. Litwin, and W. Kent. Language features for interoperability of database with schematic discrepancies. ACM SIGMOD International conference on management of data pp. 40-49, 1991.
[42] Hall and Filian. Negotiationin database schema integration http://hsb. baylor. edu/ramsower/acis/papers/hall.htm, 1995.
[43] Batini C., Lenzerini M., and Navathe S.B. A comparative analisis of methodologies for database schema integration. ACM Computer Survey.? pp. 323-364, 1986.
159
[44] Lakshmanan, Laks Vis., Sadri F., aiid Subramanian I.N. On the logical foundations of schema integration and evolution in heterogeneous database systems. DOOD’Y3, 1993.
[45] Hammer Joachim and McLeod Dennis. An aproach to resolving semantic heterogeneity in a federation of autinomous, heterogeneous database systems. Computer Science Department University of southern California, 1994.
[46] Scheth A. Datasemantics: what, where and who? Large Scale Distributed information systems Lab, Department of Computer Science University o f Georgia, 1996.
[47] Ahmed R.: Smedt P. Du, Kent W., Ketabchi A,, and Litwin W. The pegasus heterogeneous multidatabase system. IEEE Computer, 1991.
[48] Landers T. and Rosenberg R. An overview of multibase. Distributed Database p p 153-184, 1982.
[49] Templeton M. Et. al. Mermaid: Afront-end to distributed heterogeneous databases. Proc. SEEE 75, 5 pp. 695-708, 1987.
[50] Breitbart Y. Multidatabase interoperability. SIGMOD, 1990.
1511 Schaller T., Omran A , , Bukhres Ahined, K. Elmagarraid, and Jiassan Chen. A taxanomic and analytical survey of muitidatabase systems. Universidad de Purdue, 1993.
[52] Graham Hamilton and Rick Castell. Jdbc: a java sql api. JavaSoft a Sun Microsystems Snc. Business, Version 1.2, 1997.
(531 InterSoft. Jdbc: Un api sal eii java. IEEE Computer, 1998
[54] Ricardo Devis Botella. Todo java (v): acceso a base de datos mediante jdbc. Soluciones avanzadas SSSN 0188-8048 AGO5 No. 49, 1997.
(551 H.M. Deitel and P.J. Deitel. Como programar en Java. Prentice Hall, 1998. . . .: . .. ,. , . . I . , .,
. . . .
160
![RenovarEmpréstimos · Biblio tec Resu 'tad o s Busca Multicampo Acervo Geral Minerva Busca Multibase Lim par Fale Busca Avançada Pedido de EE8 Busca CCL A] uda Busca Simples clique](https://img.document.onl/doc/110x75/5f6fc006f7252d09ef7d20eb/renovaremprstimos-biblio-tec-resu-tad-o-s-busca-multicampo-acervo-geral-minerva.jpg)
