Story Transcript
S.E.P.
S.E.I.T.
D.G.I.T.
CENTRO NACIONAL DE I N V E S T I G A C I ~ 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.
~9s-ooas
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.
G R A C I A S POR SU APOYO ii
SPI’
U D
SISTEMA NACIONAL DE INSTITUTOS TECNOLÓGICOS
Centro Nacional de Investigación y Desarrollo Tecnológico FORMA A3 REVISION DE TESIS
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 Y DESARñOLLOTECNOL&IW GUBDIFECCIÓNA C A D ~ I C A
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@infoselnet 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 Presente
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 ent 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 & I C O - T n C . (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 Sistema de base de datos centralizada
....................
1
.....................
3
....................
4
1.1.2. Sistemas de basa de datos distribuidas
........
6
1.1.2.2. Sistemas de hases de datos distribuidas heterogéneas . . . . . . .
6
1.1.2.1. Sistemas de hases de datos distribuidas homogéneas
. 1.2 Objetivo de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
.........................................
7
...............................
8
1.3 Beneficios
1.4 Organización por capítulos
10
2 MARCO T E ~ R I C O 2.1 Sistemas multihase de datos
...............................
11
.....................
12
.............................
13
....................
13
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
14
.............................
14
......................................
15
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
31 32
............................
33
.............................
33
....................
34
2.3.2 Optimización de consultas 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
..............................
35
......................
35
2.4.2 Integracióii semántica p del esquema
3 PLANTEAMIENTO Y
. . . . . . . . . . . . . . . . . . . 35
ANALISIS DEL PROBLEMA ..........................
39
3.2 Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
...............................
42
3.3.1 Selección de herramientas de Software . . . . . . . . . . . . . . . . . . . . .
42
............................
44
...................................
45
3.5 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.1 Planteamiento general del problema
3.3 Definición de requerimientos
3.3.2 Platafornia de desarrollo 3.4 Análisis de solución
49
4 DEFINICIdN DEL ESQUEMA GLOBAL
.............................
49
4.2 Gramática del lenguaje de definición de datos . . . . . . . . . . . . . . . . . . . . .
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.1 Lenguaje de definición de datos
4.3 Generación del diccionario de datos 5
39
..........................
Definición de operaciones globaies 5.1 Lenguaje de inanipulación de datos
54 57
...........................
5.2 Gramática del lenguaje de manipulación de datos 5.3 Generación de código de transacciones locales iv
...................
.....................
57 58 59
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
...................................
..
................................
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
6.1 Definición de JDBC
6.2 Ejecución de operaciones
7 INTERFAZ CON EL USUARIO GLOBAL
(2
95
................................
95
7.2 Ejecución del DDL
....................................
98
7.3 Ejecución del DML
....................................
99
...........................
99
7.1 Editor niultibase de datos
-
/.4 Visualizador de multibase de datos
8 PRUEBAS
103
8.1 Objetivo de las pruebas
.................................
103
..........................
104
8.2 Descripción del ambiente de prueba
8.2.1 Esquema de la base de datos d e prueba
. . . . . . . . . . .; . . . . . . . .
8.2.2 Contenido inicial de I s basa de datos locales de prueba 8.3 Casos de prueba
. . . . . . . . . . . 109
..................................... v
106
116
9
125
CONCLUSIONES 9.1 Conclusiones generales
9.2 Resultados obtenidos 9.3 Alcances logrados
I
.,
. .
, , , ,
, , , , ,
, , , ,
9.4 Recomendaciones . . 9.5 Trabajos fut,iiros
,
. .
... , ,
,
. .
.
, , , , ,
.., . .
..
. .
, , ,
..
. . .
, , ,
.
....
,
.
.
.
, , , ,
, , , , , ,
.,,.,..
.............
125
.....,,...
126
, , , , ,
.
....................
, , , ,
...
.
, ,
.,
,
. .
..,
,
. . .
...,
.
128
. .
.......
129
..
.
,
, ,
.
. .
...
131
ApéndiceA
.
Archivas para definir hases de datos globales
I1
. 130
132
137
Apéndice B Archivos generados por los casos de prueba
........ ....... ..
. . . .
,
..
I11 Apéndice C
138
146
Pseudocódigos para la generación y ejecución de la operaciones globales (SELECT, INSERT, DELETE y UPDATE).
....
vi
. . . ...
. ........
. . . . .
.
. . 147
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 .
2
..............
4
1.3 Esquema de un sistema de b a s e de datos distribuidas .
...............
5
3.1 Esquema del ambiente del planteamiento del problema
...............
41
....
48
4.1 Esquema de los archivos que se crean al definir el diccionario de datos . . . . . .
56
5.1 Dirección de la generación de código tipo 1.
60
3.2 Esquema a bloques de los módulos de nuestro sistema multibase de datos
.....................
5.2 Dirección de la generación de código tipo 2 para una operación SELECT global . 5.3 Dirección de la generación de código tipo 2 para una operación DELETE o
DATE con incompatibilidad de tipos en la cláusula WHERE .
61
Up-
...........
61
6.1 Esquema del niodelo de acceso 2-capas
........................
76
6.2 Esquema del niodelo de acceso 3-capas
........................
77
.............................
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
6.3 Esquema de t.rabajo de JDBC
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 .
................................ vii
101
7.7 Se muestra el esquema de la base de datos en forma de árbol.
,
.........
101
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. . . .
....,
, , , , , ,
. . . .
.
, , , ,
8.1 Esquema de la base de datos global basesem.
,
.,
.. .
,
.
,
.
.
.
, , , ,
.,.,
. . . . . . . . . ,. .
8.3 Esquema de base de datos definida en el SMBD de Oracle. .
8.4 Esquema definido para la base de datos del SMBD mSQL.
..
106
....
107
. . .
8.2 Esquema de la base de datos definida en el SMBD de SQL Server. . . . .
..........
.........
8.5 En esta prueba se muestra el contenido de la tabla carreras.
. . 102
. . 108
..
108
...........
118
. .
8.6 Muestra la ejecución de la transacción SELECT sobre las tablas globales materias y planes.
......
.. . . . . .. ..
,
.
.......................
119
8.7 Muestra la ejecución de las transaccioes UPDATE y SELECT esta última para verificar si ejecutó correctamente la niodificacióri del UPDATE.
.
. . . . . . . . 120
8.8 Muestra la ejecución de las transacciones UPDATE, INSERT y SELECT esta ú1tima para verificar si ejecutó correctamente la modificación hecha por el UPDATE y la insercción hecha por el INSERT. 8.9
...
. .
........
. .
......
. . . 122
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
viii
Lista de Tablas 2.1 Clasificación de proyectos multibase de datos con esquema global. 2.2
. . . . . . . . . 16
Continuación de la clasificación de proyectos multibase de datos con =quema global.
.........................................
17
....
2.3
Clasificación de proyktos multibase de datos con basa de datos federadas
2.4
Clasificación de proyectos multibase de datos con lenguaje multibase de datos
.
.
18 19
2.5 Clasificación de proyectos multibase de datos con lenguaje multibases de datos
.......................................
19
.....................................
109
......................................
109
. . . . . .: . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
110
........................................
110
....................................
110
........................................
111
8.7 Tablagrupm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
....................................
111
8.9 Tabla convenio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
112
......................................
112
.....................................
113
.....................................
113
.......................................
113
8.14 Tabla aula
........................................
114
8.15 Tabla area
........................................
114
....................................
114
homogéneas
8.1 Tabla profesional 8.2 Tabla reticula
8.3 Tablaestudiaiites 8.4 Tabla carga
8.5 Tabla catedratico 8.6 Tablaclase
8.8 Tabla licenciatura
8.10 Tabla pupilos
8.11 Tabla asigiiat.ura 8.12 Tabla maestros 8.13 Tabla clase
8.16 Tabla licenciatura
ix
. 1 . . . . . . . . . . . . . . . 115
8.17 Tabla ingreso
.....................
8.18 Tabla materia
......................................
115
8.19 Tabla empleado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115
.....................................
116
........................................
116
8.20 Tabla seminario 8.21 Tabla sala
X
Capítulo 1
Los rápidos avances en la tecnología de las redes y en la comunicacióii han cambiado dramáticamente 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 manejador 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 u n 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 u n 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 computadoras, 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 u n 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
convenido
eii
I,) los sitios han
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 administrador 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 componentes 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]. E n 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, e n 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 a m b i h 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.
E n 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 de s 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 i
.
,,
-
..
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. 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. E n 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
Modelo de dato: global
Modificación global
Caracteristicas claves
Prototipo limitado
Relacional extendido
En
Funciones generales, poderoso uso de inkrfnces, limitantes globales.
Dataplex Investigación de General . Motors DQS (Sistema de consultas distribuidas) CRAI Italia EDDS (Sistema de basede dato: experimental), Universidad de Ulster HD-DBMS ( Heterogéneos die tribiiidos - DBMS ] UCLA
Prototipo liniit,ado
Relacional
Si
Prototipo
Relacional
No
Prototipo
Relacional
Si
Investigación
Eiitidnd-relación
JDDBS(Sistema de base de datos japones), Ceiitro de desarrollc y procesamiento de información japonec. Mermaic, Unisys
Prototipo limitado
Relacional
Prototipo
Relacional
Prototipo limitado
Funcional
No
Prototipo
Relacional
No
Protot,ipo
Relacional
si
Nombre del sistema/ Organización ADDS (Amoco D i s tributed Database System) Centro de de investigación
Estado desarrollo
de
Arnnrn
Multibase, Corporación de computadoras de Aniérica MukiStar, consorcio encabezado por CRAI, Italia. NDMS (Sistema manejador de d a h s de red), CKAI, Italia
un
próximo
Si
futuro
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 enrutaniiento 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, capacidad 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 desarrollo
Protoipos limitados
Relacional
Prot,eus, Universidad de British
Prototipo
Conceptual abstracto
Scoop, Universidad de París y Turin
Invest.igación
Entidad-relación
SirusDelta, Inria, Francia
Prototipo limitado
Relacional
Unibase, Instituto dc ciencia, tecnología e información económica, Polonia XNDM(Manejador de una red de datos experimental), Departamento nacional de estandar
Investigación
Relacional
Prototipo limitado
Relacional
de
Modelo de dalas
Modificación global
global
Caracteristicas
claves
Si
1
NO
Replicadm de datos, nodos que pueden soportar diferentes niveles 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
si
Traslación de datos, uso de nodos servidores para proiesamiento global.
Tabla 2.2: Continuacióii de la clasificación d e proyectos multibase de datos con esquema global.
17
Nonibre
del
sistema/ Organización Heirnbigner, univesidad de colarado
Ingres/Star, Compañia de tecnología relacional.
Est,ado desarrollo
de
Modelo de dntos global
Relaciona1
Superdatabase, Universidad de Columbia
Modificaciones globales
Características claves
Si
Soporta un lenguaje para trans formación de datos, negociación de prnt.ocolos para la creación de esqnenias de entrada. Puede definir la múltiple iniportación de esquemas de un nodo Estructura de un sistema jerdrquico, mntrol concurrente.
En un futuro
próxhio
Si
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 i n t e p c 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. E n [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 freciientemente 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 E n 1161 se presenta un marco de trabajo formal para la combinación de esquemas. El
18
..
. . . . !.
Nombre del Estado dc sistema/ desarrollo Organización Calida, LnboratPrototipo rios de investicación GTE Hetero, Felipe Prototipo Carina, California Linda, Gen- Prototipo limitado t,ro de investigación tkcnica de Finlandia MR.DSM(Multiple Prototipo almacenamiento de datos relaciona1 Mult,ics) Inria, Francia. Odu, Universidad Prototipo limitado de Wales
Modelo de datos global
Modificaciones globales
Caract,erísticas Cl?l"eC
Relacional
Si
Exteniión relaciona1 Relacional
Si
Optimización dr consultas, union= implícitas Poderoso uso de interfaces Deja de ser un sistemn multibase de datos
Relacional
si
Entidad-relación
No
SWIFT(Sociedad de redes amplias de telecomunicaciones de interbancos finaeieros), SWIFT Europa VIPMDBS(Sistema multibace-Prolog integrado . de Viena), Universidad técnica de Vienna
Invest,igaiión
Relacional
Prototipo
Relacional
Nombre sistema/ Organización
del
Estado desarrollo
Emprw,
Compnñía Rhodiiis.
Funciones generales, características de muchos lenguajes, limitaciones globales Puede enlazar s i s i.enins de nidauinas pequeñns.
Estruct,iira procesamiento t,rancacciones
Y
de
El lenguaje global es Prolog
Modelo de dat,os global
Modificaciones globales
Características claves
Comercial
Relacional
Si
Sybase, Conipañía
Comercial
Relacional
Sist,ema R.2, IRM
Protot,ipo
Relacional
Funciones del lenguaje global limitadns del Funciones lenguaje global limitadas Optimiznción de consultas
Sybase
de
Si
Tahla 2.5: Clasificación de proyectos multihase d e 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. E n [17] se describe nu método para integrar modelos de información desarrollados separadamente. 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 algunas heurísticas y pueden ser usadas con una limitada intervención del factor humano para guiar este proceso.
E n [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. E n [19] se expone que los principales problemas en la integración de esquemas son la identificació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 entreesquemas expresados 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. E n [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 informació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 (Ilamadm 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.4en
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. E n este reporte técnico se describe el método desarrollado para la integración de esquemas en el sistema de multibases de datos CORDSy también el conjunto de herramientas que soporta el método. E n (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 operacionales 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 existencia 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
estas
razonar acerca de la existencia de tales hinciones abstractas, por lo tanto, 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 utilizdo 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 indefinible. 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 desarrollo &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 esquemas 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
entrelos objetos. Representan la similitud semántica entre 10s objetos usando el
conceptode proximidad semántica. Proveen una taxonomfa Semántica de modelo de datos independiente 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. E n [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 administració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 relacionados 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 l enguajes 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 caracterí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 u n 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 metadatosde 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. E n (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
de
uno de tales modelos. Los conceptos de las bases de datos locales y los conceptos
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 otrassubpet,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 aserciones de integración. Dos formas básicas de aserciones de integración son identificadas: aserciones 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 informació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 metainformació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 entidacrelació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 esfuerzos de integración, y que se requieren muchos de 10s mismos metadatos, Sin
en
importarqué 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 arquitecturas distribuidas que tienen algunas bien conocidas desventajas. Es, por ejemplo, la falta d e 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 ontologías. E n [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). E n 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. E n 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
I
1 ;!, >I 3,
tablenamegl
::= identifier
E n 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 , 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 E n 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
datos de la siguiente manera:
I
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. /I
le siguen las nombres de las bases de datos locales y con ellos se podra acccsar a la I
información del diccionario de las bases de datos locales. 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 11
basegloba1,dd también generan igual dos archivos baselocal.hd y baselocal.dd. e).- En el archivo baselocal.bd se encuentran los nombres de las tablas de la base de 18
datos local que se quieren integrar para formar el contenido de las tablas globales. ',
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 I1
es el nomhre de la base de datos local a la que pertenecen, el nombre del archivo que se obtiene es tahlalocal.baseloca1
55
9
Nombre tabla gIoba1,Nombre base global
Nombre base local. bd Nombre base local .dd
-
-
-
Nombre tabla local Nombre base local
Nombre base local bd
-
base local dd
-
Nombre base local bd
-
Nombre base local dd
I
- Nombre tabla IocalNombre base local
7 L
.
Nombre tabla local Nombre base local
7 Nombre tabla local.Nombre base local I
.
I
Figura 4.1: Esquema de los archivos que se crean al definir el diccionario de datos
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 I
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.
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 I
locales que se necesitan para lograr las operaciones globales emitidas por el usuario.
!
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: G{N! 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 d e 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, iusertstm, optcolumeommalist, columcommalist, valuesorspec, insertatonicoinmelist, insertntom, at,om, literal, number, updat,estni, assignmentcommalist, assignment , scslsrexp, columnref, selectstm, optalldistinc, selection, scalarexpcommaüst, tableexp, hamclause, tablerefeommalist, 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)' I value ::= ( literal I columnref) identifier ::= name I table ::= name name ::= letter( leter 1 digit)* letter ::= [A-Z,a-z] digit ::= [C-Q] I intnum ::= ([C-Q])+ aproxiium ::= ([C-9])+ 'I." ([0-9])* [ exponent 1 I ([O-Q])+ [exponent 1 I ([C-Ql)+ [ exponent ] exponent. ::= ( E I e ) [+,-I ([0-91)+ compare := (= 1 I < ( > I =) chain ::= '(otherthing)* ',, 'I."
5.3 Generación de código de transacciones locales El intérprete del lenguaje d e 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 u n 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
dimcmm
.
UPMTE
BD. Local
BD. Local
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 , si encuentra una tabla local genera el siguiente código.
I
3c.-Un SELECT donde &eextraiga 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 I
FROM y el código que se genera cada vez que se ejecuta este paso es encerrado entre dos I banderas que se identifican con' los caracteres 1.1.
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 I Create table TABLA2 ( nombrepro char(lO), nombrecli char(lO), numerocli char(l5), numeropro int ) com.imaginary.sql.msql,MqlDriverjdbc: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 a c h a l aclmal Iiisert, into TABLA2 valti& ( ' array[O] ? , ' array[l] ' , ' array[Z] ' , array[3] )
connect.microsoSt.MicrosoftDriverjdbc:ff-microsoft://l48.208.92.82:1433/PRUEBA LUCERO
LUCERO select proveedor, cliente, clavecli, clavepro from bodega com.imaginary.sq1.msql.MsqlDriverjdbc:insql://148.208.92.1041114/wmpany aclmal aclmal Insert into TABLA2 values ( ’ array[O] ’ , ’ array[l] ’ , ’ array[2] ’ , array[3] ) 1.1 1.1 com.imaginary.sql.msql.MsqlDriverjdbc:msql://148.208.92.104:1114/companyaclmal 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.MsqlDriverjdhc:msq1://14X.208.92.104: 1114/wmpany aclmal aclmal Insert into TABLAl values ( ’ array[O] ’ , ’ array[l] ’ , array[2] ) wnnect,.microsoSt.MicrosoftDriverjdbc:ff-microsoft://148.208.92.82:1433/PRUEBA LUCERO LUCERO select nom, num, tipo from pro1 com.imaginary.cql.msql.MsqlDriverjdbc:n1sql://148.208.92.104:11l4/company aclmal aclmal Insert into TABLAl values ( ’ array[O] ’ ’ arrny[l] , array[2] ) 1.1 com.imaginary.sql.msql.MsqlDriverjdbc: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.Msq1Driverjdbc:msqi://148.208.92.104:1114/company aclmal nclmal Drop table TABLA2 com.imaginary.sql.insql.Msq1Driverjdbc:insql//148.208.92.104:1114/campanyaclmal aclmal Drop table TABLAl ~
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 u n recorrido en cada base d e 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 , si se encuentra u n a tabla local geiierá el siguiente código.
* Se emite una operación de INSERT hacia la tabla local, con las datos a insertar formateados 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.MsqlDriverjdbc:msql://148.208.92.104lll4/company adma1 acimal insert int.o almacen ( cp, cc: prov, di) values ( ‘go’, , 5 6 7 , ’provl’: ‘di& ) mpany achnal acimni Create table materiasSERES ( clave int, materia char(25), creditas char(2) ) com.imaginary.sql.rnsql.MsqlDriverjdbc: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/companyaclrnal aclmal " . 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 iaclnial p~~~ 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 I
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.MsqlDriverjdhc:msql://148.208.92.104 1114/admesco aclmal aclmal insert into licenciatura ( clavearen, clavelc) values ( 'IBQ', '130' ) connect.microsoft.MicrosoftDriverjdbc: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: 1114/company achnal aclmal Create table materias ( clave int, materia char(25), creditos char(2) ) oracle.jdhc.driver.Orac1eDriverjdbc: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.MsqlDriverjdbc:msql//148.208.92.104:1114/companyaclmal aclmal Insert indo materias values ( array(O] , ' array(i] ' , array[^] ' ) com.imaginary.sql.msql.MsqiDriverjdbc:msql://148.208.92.104:1114/admescoa c h a i ailmal select clavelc, nomat, carga from materia com.imnginary.sql.msql.MsqlDriverjdhc: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.MsqlDriverjdbc:rnsql://148.208.92.104:1114/companyacimal aclmal Insert into materias values ( array[O] , ' arrny[i] ' , ' arrny[2] ) 1.1 1.1 com.imaginary.sq1.msql.MsqlDriverjdbc:msq1//148.208.92.1041114/cornpanyaclmal admsl Create table planes ( carrera diar(4), clave int ) oracie.jdbc.driver.Orac1eDriverjdbc:oracle:thin:@(description=(address=(hoct=academOl mor.itesm.mx)(protocol=tcp)(port=1521))(eonnect_data=(sid=Mo~)))a1372422 a1372422
142
select clavel, clavecon from convenio coni.imaginary.sql.nisql.MsqlDriverjdbc:msqi://148.208.92.104:1114/conipanyaclmai aclmal Insert into planes values ( ’ array[O] ’ , array[i] ) com.imaginary.sql.msql.Msq1Driver jdbc:mcql://148.208.92.104:1114/admescoaclmal aclmsl select clavearea, clavelc from licenciatura
~ ~ ~ . ~ ~ ~ ~ ~ ~ r y . ~ ~ ~ . ~ ~ ~ ~ . ~ s q l D ~ i ~ e r j d b c : m s q l : / / 1 4 8 . 2 0 8a.c 9h 2a i.aclmal 104:1114/com~any 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.MsqlDriverjdbc:msql://148.208.92.104:1114/company aclmsl aclmai Insert into planes values ( ’ array[O] ’ , array[i] )
1.1 com.imaginary.sq1.msql.MsqlDriverjdbc: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.AfsqlDriverjdbc:msqi://148.208.92.104: 1114/company aclmal aclmal Drop table materias com.iinaginary.sql.msqi.~lDriver jdbc:msql://148.208.92.1041114/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¡verjdbcoracle: 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.104lll4/company aclmal aclmal Create tlible planesadmesco ( carrera cbar(4), clave int ) com.im~ginary.sql.msql.MsqlDriver jdbc:msq1://148.208.92.1041114/admescoaclmal aclmal select clavearea, clavelc from licenciatura com.imaginary.cql.msql.MsqlDriverjdbc: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/companyaclmal 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.MsqlDriverjdbc:nisql://148.208.92.1041114/admescoaclmal 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/companyaclmai acimnl Create table pianffiSERES ( carrera char(4), clave int ) eonnect.microsoft.MicrocoftD~verjdbc:5-microsoft://148.208.92.82:1433/SERES LUCERO LUCER.0 clavepro, ciavere from reticula 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.1041114/company adma1 admai Drop table planesSERES connect.microsoft.MicrosoftDriverjdhc: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.MsqlDriverjdbc: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/companyacimal aclmal Insert into materias values ( array[O] , ’ array[i] ’ , ’ array[^] ’ ) comimagiiiary.sql.nisql.MsqiDriverjdbc:msql://148.208.92.104 1Il4/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.MicrosoftDriverjdbc: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,MsqlDriverjdbc:msql://148.208.92.104: lli4/company a c h s l aclmal Create table planes ( carrera char($), dave int ) oracie.jdbc.driver.OrscleDriverjdhcoracie: 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.MsqlDriverjdbcmsqi: //148.208.92.l04:lll4/cornpanyaclmal aclmai Insert into planes values ( ’ arrny[O] ’ , array[^] ) com.imaginary.sqi.msql.Msq~riv~r jdhc:msqi://148.208.92.104:lll4/admescoaclmal aciinal select clavearea, ciavelc from licenciatura com.imaginary.sql.msqi.MsqlDriver jdhc:msqi://148.208.92.1041114/company achnal aclmai Insert into planes values ( ’ array[O] ’ , array[i] ) connect.microsoft.MicrosoftDriverjdbc:ff-microsoft://148.208.92.821433/SERES LUCERO
144
LUCERO select clavepro, clavere from ret,icuia com.imagiiiary.sql.msql.MsqlDrivesjdbc:msql://148.208.92.104:1114/companyaclmal aelmnl Insert into planes values ( ’ array[ü] ’ , array[i] )
1.1 com.imaginary.sql.msql.MsqlDriverjdbc: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/companyadma1 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
I
- /* 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;
-¡=O; - 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*/ --j=O; - - do{ - - _ base-local = bases-localesb]; - - _ resultado = buscar-tabla-mapeo(base_local, tabla-global); if resultado = verdadero
-__
_-- t _ - - _ insert in archivo (SELECT tabla local); - _- -insert in archivo (INSERT tabla.global); -_- I -_- 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); - / * s e 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, - _ if resultado = verdadero
--I
_---1
tabla-global);
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
-1
- - /*se hace una busqueda en cada base de datos local para saber /*si existe una tabla local mapeando a la tabla global*/
-__j=O;
- - do{ - - _ base-local = bases-locales[i]; resuitado = buscar-tabla-mapeo(base_local, - _ -if resiikado = verdadero
--_
tabla-global);
- _ - _ 1 insert in archivo (3.1); ---_ insert in archivo (DELETE a la tabla local); - - _ -insert in archivo (3.1); --_ 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 (3.1);
---__
--__-
1
----
insert in archivo (DELETE a la tabla local WHERE columnas locales); insert in archivo (3.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 p a r a la operación UPDATE. if transacción-global = UPDATE
I
- /* 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 ,
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 ___[
_ _ _ _ insert,ar in archivoaux.conaux(rengl6n) ___1 _- -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(); _ _ do { _ _ _ transaccion = renglon + renglon-info; / s e introduce la información _ _ _ ejecutar- transacci6n_IRISERT(transacci6~): _ _ _ renglón-info = leer archivo-resul();
_ _ }while(renglón-info
de la fila*/
!= EOF)
_ _ _ renglón = leer srchivoaux0;
- ]while(renglón
!= EOF);
Archivo 6 Bloque de pseudo código para la ejecución de código de la operación insert-global() conaux=O
INSERT.
I
- renglón = leer archivo(); - do { insertar in archivoaux.conaux(rengl6n) - _ renglón = leer archivo(); _ _ insertar in archivoaux.conaux(rengión)
-_
_ _ hilo-insertar-tabla-local(archivoanx - _ conaux = conaux + 1;
-_
.conaux);
rengl6n = leer archivo(); != EOF);
- }while(reuglón }
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 --
else
- -I
- _ -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);
}
hilo-delete- tipo-l(archivoaux.conaux)
1
- renglón = leer archivoaux(); - ejecutar-coneccion(rengl6n); - renglón = leer archivoaux(); - ejecutar- transacción-DELETE(reng1ón);
}
hilo-delete- t,ipo-2(srchivoaux.consw