S.E.P. S.E.I.T. D.G.I.T.
CENTRO DE ENFORMACION
CENTRO NACIONAL, DE INVESTIGACIÓN Y DESARROLLO TECNOLÓGICO
cenidet
DETECCIÓN Y REGISTRO DE EVENTOS RELEVANTES PARA EL DISEÑO ADAPTABLE
DE BASES DE DATOS DISTRIBUIDAS EMPLEANDO REGLAS ECA
T E S I S QUE PARA OBTENER EL GRADO DE:
MAESTRO EN CIENCIAS EN CIENCIAS COMPUTACIONALES
P R E S E N T A : ROCIO ALEJANDRA KAUFFMANN MIRELES
CUERNAVACA, MORELOS FEBRERO 2000
Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C3
REVISION DE TESIS
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: Detección y Registro de ,Eventos Relevantes para el Diseño Adaptable de Bases de Datos Distribuidas Empleando Reglas ECA, realizada por la C. Rocío Alejandra Kauffmann Mireles, 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
H. &c' (L'L
M .C Mario Guillén Rodriguez
, Dr. Joaíjíh Pérez Ortega
Director de tesis
C.C.P. Dr. Javier Ortiz HernándezíJefe del Departamento de Ciencias Computacionales
INTERIOR INTERNADO PALMIRA S/N. CUERNAVACA. MOR. MÉXICO APARTADO POSTAL 5-164 CP 62050. CUERNAVACA. TELS.173112 2314.12 7 6 1 3 . 1 8 7741 ,FAX(73)12 2434 EMAIL O m caddetedu.mx
Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C4
AUTORIZACION DE IMPRESIÓN DE TESIS
C. Rocio Alejandra Kauffmann Mireles Candidata 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: Detección y Registro de Eventos Relevantes para el Diseño Adaptable de Bases de Datos Distribuidas Empleando Reglas ECA, 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.
Atentamente /
INTERIOR INTERNADO PALMIRA S/N, CUERNAVACA. MOR. MÉXICO APARTADO POSTAL 5-164 CP 62050, CUERNAVACA. TELS.(73)12 2314.12 7613 ,18 7741,FAX(73) 12 2434 C L A A H nrii7fiArpnirlnt nrlii my
Agradecimientos Gracias Padre por permitirme conocerte más en este tiempo,
realmente has sido mi roca.. . A mi familia, por ser el aliento para realizar este esfuerzo.
Gracias por su apoyo y su amor, por tener confianza en mi.
A mi asesor, Dr. Joaquín Pérez, por el tiempo dedicado, por su ayuda e interés en el desarrollo de este trabajo.
Al Centro Nacional de Investigación y Desarrollo Tecnológico por brindarme la oportunidad de realizar mis estudios de maestría.
A m i s revisores de tesis, Dr. Rodolfo A. Pazos, Dr. Javier Ortiz, M.C. Mario Guillén y M.C. Humberto Hemández. Gracias por sus valiosos comentarios para el
mejoramiento de la misma.
A todos mis maestros por transmitirme conocimientos que me hicieron mejor. Gracias maestro José Luis Alcántara.
A las personas que compartieron momentos especiales conmigo y que me brindaron su amistad, de manera especial a Sofía Ruiz, Nadira Rodriguez, Nancy Vizako, Claudia
Ibarra, Sinuhé Ramírez, Armando Ruu y Gustavo Alarcón ... ya saben cuanto los quiero.
Gracias Alex por hacer especiales muchos momentos.
Al pastor Raymundo y a su esposa Vicky, quienes me brindaron su amistad y se preocuparon por mí.
A la Sra. Lili Vázquez y a Flor Morales, por abrirme las puertas de su casa ... gracias por su confianza.
Fernando, gracias por apoyarme y darme tu amor.., por enseñarme a crecer como persona.
A mis amigos de siempre Gaby Martínez, Ana Ilián Muñoz, Usler Román, Joel Martínez, O h i a Fernández, Oscar Ibarra, Pablo Cano, Alfred0 Adriano, Manuel
Gomáiez y Rodolfo Luna, que a pesar de la distancia stguen a mi lado.
A todos m i s compañeros de generación: Sofía, Nadira, Roger, Paty, Fabi, Isaac, Santiago, May, Javier, Magda, Alberto, Agustín, José y Edson ... de cada uno aprendí aigo para bien. Gracias por las experiencias compartidas y por las muestras de afecto
que no cambio por nada.
Que Dios los bendiga a todos1
11
TABLA DE CONTENIDO
páp .CAPITULO 1 INTRODUCCI~N ...................................................................................... 1
1.1MetodologÍa Tradicional de Diseño de BDD's ............................. 2 1.1.1 Análisis de Requerimientos 4
1.1.1.1 Análisis de Requerimientos de Distribución ................... 4 1.1.2 Diseño Conceptual Global ........................................................ 4 1.1.3 Diseño Lógico Global ............................................................... 5 I . 1.4 Diseño de la Distribucibn ........ ; 1.1.5 Diseño Físico
1.2 El Diseño de la Distribución .. ......................................................... 6 1.2.1 Fragmentación ..... 1.2.2 Problema de Ubic ....................
_ . . 1.3 Motivación .: : ........................................................................................ 8
1.4 Descripción del Problema ............... : .............................................. 10
1.5 Objetivo .............................................................................................. 14
1.6 Propuesta de Solncion ..................................................................... 15
1.7 Alcances ............................................................................................. 15
. I
1.8 Organización del Documento ........................................................ 16
CAPITULO 2 .BASES DE DATOS ACTIVAS ............................................................... 19
2.1 Historia ............................................................................................. 21
2.2 Enfoques Alternos .......................................................................... 22 2.2.1 Modificación del Código ............... ............................ 22 2.2.2 Verificación Periódica .................. ............... 23
2.3 Reglas ECA ...................................................................................... 23
2.4 Estado del Arte ................................................................................ 26 2.4.1 ARIEL 2.4.2 MARIPOSA 2.4.3 Chimera ................................................................................... 31
... 111
2.4.4 SAMOS!.;. ....; .... : ............. ; ....................................... : ................. 32 . . . , . r 5% ,! ,"s ). , ;$e , ' . , . ,
CAPITULO 3 LENGUAJE DE REGLAS ECA ............................................................. 35 3.1 Gramática del Lenguaje de Reglas ECA ........................................ 37
3.1.1 RegiaECA 3.1.2 Eventos ..... 3.1.3 Condicione ...................................... 38 3.1.4 Acciones ._._.! ............................................................................ 39 3.1.5 Variables ................................................................................... 39
3.1:7 Elementos C,omunes 3.1.8 Val , - Co1umn.a 3.1.9 Valor-Where. 3.1.1O~Valor-Ti
3.2.1 Acciones Se 3.2.2 Acciones Se
I
'3:1.6 Operadores .... ............. .............. . . . . . . . . . .
3.2 Acciones Semánticas ...........
CAPITULO 4 W L E M E N T A C I O
4.1 Diseiio General del Sistema de Reglas ....................................... 63
4.2 Tipos de Datos ................................................................................. 64
4.3 Enfoque Orientado a Objetos ...................................................... 64
4.4 Precompilador ................................................................................. 66 4:4.i 'Interface01 " .................................... 66
. . . . . . . , c ,
. .
. ,
, .
................................... 73
, 4.5 Intérprete .................................................................................... 73 4.5.1 Detector de Evento
. , . 4.5.1.1 EventosDete
~ 4.5.2 Procesador de Reg1 4.5.1.2 Integración con el SiMBaDD ......
.
4.5.3 Módulo Trdnsformador de Consu1tas.a Forma Canónica .. 79 4.5.4 Integrad ................................... 81 4.5.5 Base de .................................................. 4.5.6 Base de Consultas: ................... :..'._._: 4.5.7 Datos Estadísticos de Explotación ....................................... 83 4.5.8 Módulo Identi ficador de Consultac' Básicas.. ...... 4.5.9 Interfaz de Consulta .....
84 ............................... 85
, . .
iv
CAPITULO 5 PRUEBAS ................................................................................................. 87
5.1 Objetivo de las Pruebas ................................................................. 87
5.2 Lista de Pruebas .............................................................................. 87
5.3 Descripción del Ambiente de Pruebas ........................................ 88 5.3.1 Esquema Relaciona1 de la Base de Datos de Prueba .......... 89 5.3.2 Herramientas Auxiliares ........................................................ 89
5.4 Resultados Obtenidos .................................................................... 90 5.4.1 Prueba 1: Altas y Bajas de Reglas ECA ... 5.4.2 Prueba 2: Definición de Reglas ECA .... 5.4.3 Prueba 3: Definición de la Condición de la Regla ECA ..'.. 92 5.4.4 Prueba 4: Registro de Datos Estadísticos de Explotación . 94 5.4.5 Prueba 5: Incremento de Frecuencia ......... 5.4.6 Prueba 6: Distintos Clientes .................................................. 97 5.4.7 Prueba 7: Control de Concurrencia ...................................... 97 5.4.8 Prueba 8: Equivalencia Semántica de Consultas 98 5.4.8 Prueba 9: Integración de Datos Estadísticos y
Obtención de Archivo de Datos .......................... 98
CAPITULO 6 CONCLUSIONES .................................................................................. 103
6.1 Trabajos Futuros .............................................................................. 104
6.2 Beneficios ........................................................................................... 104
REFERENCIAS ............................................................................................................... 107 APENDICE A ESTANDARES EN BDA .................................................. : ................... 111
A.l Restricciones de Integridad en el Estándar SQL-92 ............ 112
A.2 Aserciones y Disparadores en SQL3 ......................................... 114
APENDICE B CARACTERISTICAS ACTIVAS DEL MODULO IMPLEMENTADO .................................................. 117
B1 . Caracterrsticas ................................................................................. 117
B.2 Comparación con Algunos Prototipos .......................................... 121
B.3 Comparación con los Disparadores de Estándar SQL3 .............. 125
. .
APENDICE C PUBLICACIONES RECOMENDADAS ............................................. 129
V
LISTA DE FIGURAS
'li
;í
Figura 1-7: Migración de'Datos - Tabla 11 A
Figura 1-1: Metodología Tradicional de:Diseño deBDDs Figura 1-2: Automatización del Proceso'de Diseño de Distribución de Datos Figura 1-3: Sitios de la Red Figura 1-4: Esquema de Distribución de:!los Datos Figura 1-5: Patrones Originales de Explotación de los Datos Figura 1-6: Nuevos Patrones de Explotación de los Datos
Figura 1-8: Migración de Datos - Tabla B Figura 1-9: Esquema de Distribución de IoSDatos Adaptado a Patrones de
Figura 2-1: Taxonomía deBases de Daios , . en Cuanto a su Capacidad Activa Figura 2-2: Origen de las Bases de Datos Activas Figura 2-3: Algoritmo de Procesamiento de Reglas en L4 Figura 2-4: Algoritmo de Procesamiento' de Reglas ECA
Figura 2-6: Arquitectura de Mariposa Figura 2-7: Arquitectura de SAMOS Figura 3-1: Acciones Semánticas al Tiempo de Definición y Procesamiento de
Figura 3-2: Flujo de Control del Procesamiento de las Reglas ECA Figura 3-3: Generación de Acciones Sedánticas Figura 4-1: Diseño General del ~. Sistema ,. de . Reglas Figura 4-2: Arquitectura del P~écompilador Figura 4-3: Componentes de la Interfaz para la Definición de Reglas ECA Figura 4-4: Autómata para la Gramática'idel Valor Where Figura 4-5: Autómata para , el . . Análisis . . . . Léxico del Valor Tiempo Figura 4-6: Pseudocódigo para la Validación del Valor Tiempo Figura 4-7: Arquitectura del Intérprete I/: Figura 4-8: Autómata para el Reconocimiento de los Argumentos Referentes a
Figura 4-9: Interacción entre el SiMBaDD y el Módulo de Detección y
Figura 4-10: Generación de Procesos de Atención a Eventos
;I Explotación
Figura 2-5: Arquitectura de ~. Ariel , I . ,. >.
il
. . Reglas ECA .I
un Evento Detectado ' '
Registro de Eventos Relevantes I
Pág. 3 10 11 11 11 11 12 12
12 20 24 24 25 27 29 34
36 37 42 63 65 66 70 71 72 74
75
78 79
Figura 4-11: Ejemplo de Conversión de Consultas a Forma Canónica Figura 4-12: Tareas del Módulo Integrador Figura 5-1: Esquema de Distribución del Sistema Figura 5-2: Esquema Relaciona1 de la BD de Prueba
81 82 88 89
LISTA DE TABLAS
Tabla 3-1: Nombre de los Parámetros para Cada Evento Tabla 4-1: Tipos de Datos Correspondientes a las Variables ‘Definidas Tabla 4-2: Ejemplos de Condiciones, Tabla 6 3 : Ejemplos de Cláusulas Where Tabla 4-4: Eventos y Argumentos Tabla 4-5: Ejemplos de Reglas ECA Tabla 4-6: Información que se Almacena como Datos Estadísticos de
Explotación Tabla 5-1: Reglas ECA Aceptadas y!Almacenadas Tabla 5-2: Condiciones de Reglas Definidas y Resulta de Validación Tabla 5-3: Consultas de la Prueba 4 Tabla 5-4 Datos Estadísticos de Explotación en el sitio cad12 Tabla 5-5: Datos Estadísticos de Explotación en el sitio cad13 Tabla 5-6: Datos Estadísticos de Explotación en el sitio cad14
‘1
Pág. 52 64 69 71 76 83
84 92 93 95 95 95 96
Tabla 5-7: Datos Estadísticos de Explotación para la misma Consulta desde Distinto Cliente 97
Tabla B-1: Tabla Comparativa sobre las Características de Prototipos de 122 11 Sistemas Administradorfs de Bases de Datos Activas
Tabla E-2: Tabla Comparativa del Lenguaje de Reglas ECA y Disparadores 126
LISTA DE ABREVIATURAS
ABD BD BDA DD DML ECA FURD 1A SABDA SABDD SD SiMBaDD SQL SR WAN
Administrador de la Base de Datos Base de Datos Bases de Datos Activas Diccionario de Datos Lenguaje de Manipulación de Datos (Data Manipulation Language) Evento-Condición- Acción Fragmentación Ubicación y Reubicación Dinámica Inteligencia Artificial Sistema Administrador de Bases de Datos Activas Sistema Administrador de Bases de Datos Distribuidas Sistema Distribuido Sistema Manejador de Bases de Datos Distribuidas Lenguaje Estructurado de Consultas (Structure Queiy Language) Sistema de Reglas Red de Area Amplia (Wide Area Network)
ix
Resumen
Este trabajo de tesis es uno I i de varios esfuerzos encaminados hacia la
I explotación de los datos.
Capítulo 1 Introducción
Capítulo 1
Actualmente la tendencia en cuanto a la administración y almacenamiento de la
información en las grandes organizaciones son los sistemas distribuidos. Cada vez
son más los organismos que a partir de su naturaleza descentralizada, aplican el
esquema distribuido a través de oficinas y lugares de trabajo geográficamente
dispersos. Factores que han propiciado este hecho son los avances en la tecnología
de comunicaciones y el uso, cada vez más generalizado, de las redes de
computadoras.
,~
Algunas de las empresas más grandes de México, como Petróleos Mexicanos y
Comisión Federal de Electricidad, tienen este patrón de organización, y demandan
para sus procesos de toma de decisiones el intercambio eficiente de información
entre las unidades de la corporación. Esto obedece a nuevos conceptos
administrativos que exigen una disponibilidad de los datos que cumpla con la
siguiente premisa: “la persona adecuada debe recibir la información adecuada en el
momento adecuado”.
Es importante que en un sistema cuya información se encuentra distribuida, el
desempeño no se vea afectado por causa de los accesos remotos a la información.
Para lograr lo anterior se debe mantener una adecuada relación entre el esquema de
distribución de los datos y los patrones de explotación en el sistema. Éste es un
1
introducción I Capitulo 1
proceso innovador conocido como diseño adaptable y forma parte del proceso de
diseño de una base de datos.
Hasta la fecha, es tarea del administrador de la base de datos mantener un diseño
de la distribución de los datos corresbondiente a los patrones de explotación. Para la
realización de esta tarea, el administrador se basa en la experiencia que tiene sobre
la explotación de los datos, debido a que no existe un SABDD que genere la
información estadística necesarial'para la determinación del diseño de la distribución.
Este trabajo es una contribución al diseño adaptable de bases de datos
distribuidas, ya que mediante el empleo de principios de bases de datos activas, se
añade a un SABDD la capacidad activa de obtener la información estadística sobre
el uso de los datos para el establecimiento de esquemas de distribución apropiados.
11
!. ' . . . I1
!i
2 ,
Dado que el trabajo de tesis tiene como marco contextual el diseño de la
disfribución de una base de datos, kn la siguiente sección se presentan ,las fases
correspondientes a un proceso más general: el diseño de una base de datos I/
distribuida. :I, I.
I
1.1 Metodología Tradicional de Diseño de BDDs /I
El diseño de la distribuci,Ón ((es aún un problema presente en SABDDs
comerciales. Su objetivo es determinar las unidades de datos adecuadas para
almacenar, ya sean fragmentos o relaciones completas; y su ubicación a través de los
nodos, en este mismo orden. Dado que los accesos a los datos en una BDD,
representan costos de transmisión defiendientes de la ubicación física de los mismos,
el diseño de la distribución es un factor relevante en el desempeño de los sistemas
distribuidos, ya que influye directamente en la eficiencia del procesamiento de las
consultas. Pero el diseño de la diktribución es sólo una parte del diseño de Úna BDD.
SI
L
I I
Esquema Conceptual
Global
i
Definrción de Transacciones
Globales
Tablas de 0 Tablas de Frecuencia Esquema ugico GIobal Criierios de Acceso
Lógico Fragmentación
FRAGMENTACI~N HORIZONTAL
FRAGMENT ACIÓN
I
UBICACI~N Y REPLIC ACIÓN
DISENO DE DISENO LÓGICO LA DISllUBUCI6N
e ‘0” 9 5 E 8 U
4 Distribución del Esquema Global de Daios en Esquemas Lógicos Globales
DISENO FISICO LOCAL 1 Implantación del Esquema
Figura 1-1 Merodologia Tradicional de Diseño de BDDs
3
Introducción Capítulo 1
1 El proceso de diseño de una base de datos centralizada incluye análisis de
requerimientos, diseño conceptual, diseño lógico y diseño físico. Este proceso es la
plataforma para la realización del diseño de una base de datos distribuida mediante
la adición de dos fases: análisis de 'requerimientos histribuidos y diseño de la
distribución. A continuación se desbribe cada una de las fases de la metodología
tradicional de diseño incluyendo el diseño de la distribución.
i1 . "
'1 En la Figura 1-1 se presenta de manera esquemática la ubicación del trabajo que
se presenta,'en el contexto del proceso de diseño de bases de datos distribuidas', así
como su interacción con la fase de diseño de la distribución.
1
4
~. 1.1.1 Análisis de Requerimientos II En esta fase se lleva a cabo la recolección de los requerimientos del usuario, es
decir, se obtiene la información referente a las expectativas del usuario. Se analizan
los objetivos estratégicos de la orga(nización, con base en ellos se determinan los
requerimientos de información que los satisfagan, y posteriormente se determinan
los sistemas necesarios que proporcionen dicha información. li
I . 1.1.1 Análisis de Requerimientos de Distribución
. . I/
¡I '.
,
En esta fase se obtiene la frecuendia con la que las aplicaciones se ejecutan desde
cada uno de los sitios, y se recolecta,la información necesaria para la determinación
de la fragmentación sobre la base de datos. i
ii
1.1.2 Diseño Conceptual Global
El objetivo de esta fase es traslahar los requerimientos del usuario a un modelo
formal, independiente del SABD empleado. En esta fase se integran los
I Para mayor detalle consultar [Vé197] i
4
I
Capítulo 1 introducción
requerimientos de transacciones globales que describen operaciones que el sistema
ejecuta sobre los datos, así como información estadística sobre estas operaciones’.
Como resultado se obtiene el esquema conceptual global y el esquema de
transacciones globales.
1.1.3 Diseño Lógico Global
En esta fase se lleva a cabo el mapeo del esquema conceptual global hacia el
SABD empleado, ya sea relacional, de red o jerárquico. Se realiza la normalización
del modelo de datos, se definen todas las restricciones de integridad, se optimiza el
esquema de datos para soportar las transacciones más importantes y críticas, y se
especifican las consultas que soporta el SABD. Su salida es el esquema de datos
lógico y el acceso lógico a tablas.
1.1.4 Diseño de la Distribución
En esta fase se determinan las unidades de información en que se dividirá la base
de datos (fragmentos), así como la ubicación de cada una de ellas a través de los
sitios. Esta fase se ha desarrollado normalmente en dos pasos seriados: la
fragmentación y la ubicación de fragmentos. En la Figura 1-1 se puede apreciar que
esta fase recibe una entrada a partir de la base de datos operando. La entrada
consiste en información estadística sobre el uso de los datos, la cual es obtenida por
medio del Módulo de Detección y Registro de Eventos Relevantes, presentado en
este documento.
1.1.5 Diseño Físico
En esta fase se establece el mapeo de los esquemas locales al almacenamiento
La información estadística hace referencia a la ffecuencia de ejecución de las aplicaciones y al volumen de información requerida por estas.
5
Introducción Capítulo 1
físico disponible en el sitio, tomando en cuenta las características y capacidades del
SABD empleado. Se definen las estructuras físicas para la implementación de la
base de datos y su salida es el lenguaje de definición de datos.
1
1.2 El Diseño de la Distribución I En esta sección se presentan con mayor detalle los aspectos referentes a las
etapas, que de manera separada, dan lugar al diseño de la distribución, es decir,
fragmentación y ubicación de fragmentos.
1.2.1 Fragmentación 'I
La fragmentación de los dates se ha sugerido en la bibliografía como una forma
de mejorar el desempeño de los sistemas administradores de bases de datos. Se
argumenta que una relación compieta no es una unidad de distribución de datos
adecuada considerando que (1) generalmente las aplicaciones están definidas sobre
sólo una parte de la relación y (2) cuando se accede a una misma relación desde
diferentes sitios pueden suceder dos cosas. Por un lado, todos los sitios que realicen
el acceso, excepto el que almacenafla relación, pueden generar un gran volumen de
transferencia de datos (el caso extremo es la transferencia de la relación completa).
Por otro lado, se puede replicar la relación completa dando lugar a un gran volumen
de datos adicionales (aquellos que no son requeridos por la aplicación). Con la
finalidad de obtener las unidades de datos adecuadas para su distribución, las
relaciones se pueden dividir de manera horizontal o de manera vertical.
J
I En el caso de la fragmentación horizontal la relación R se divide en varios
subconjuntos rl, r2, ,.., r,, donde cada subconjunto tiene el esquema de la
relación original, es decir, cada fragmento tiene los mismos atributos que la
relación original R. Los fragmentos se determinan con base en un predicado que
11
6 I/
introducción Capitulo 1
distingue a las tuplas del fragmento, asignándoles el máximo potencial de
localidad con respecto a las aplicaciones, es decir, cada fragmento contiene las
tuplas más explotadas en el sitio de almacenamiento
I En la fragmentación vertical, también llamada partición de atributos, la relación
R es dividida en varios subconjuntos R I , R2, ..., R,, donde cada fragmento’ es
resultado de una proyección sobre la relación original. En este caso, cada
fragmento debe incluir la llave primaria de la relación original. El objetivo de
este tipo de fragmentación es agrupar aquellos atributos que son utilizados juntos
con frecuencia.
I Existe un tercer tipo de fragmentación, la fragmentación mixta. En este caso se
realizan n fragmentos, donde cada uno se obtiene alternando la fragmentación
horizontal y vertical sobre la relación original o sobre un fragmento previo.
1.2.2 Problema de Ubicación de Datos
La segunda etapa en el diseño de la distribución es la ubicación de los datos. Esta
etapa implica el siguiente problema: si se tiene un conjunto de fragmentos F = Fl ,
F2, ..., F n , y una red de comunicaciones con un conjunto de sitios S = SI, S2, .,.,
S, y un conjunto de aplicaciones Q = Ql, Q2, ..., en, cuál es la ubicación óptima
de F e n S de manera que el procesamiento de las consultas Q sea más eficiente.
La ubicación de datos es un problema complejo y su solución no es trivial debido
al número de parámetros que intervienen en el modelado y a la complejidad de la
solución, ya que el espacio de soluciones es muy amplio aún para problemas de
tamaño pequeño. Es decir, si no se considera el hecho de que pueden existir réplicas
de los fragmentos, el número de ubicaciones posibles paraffragmentos en s sitios
está dado por d mientras que si se considera la replicación, el número de
Introducción Capítulo 1 'I
posibilidades se incrementa considerhblemente a ($)/,".
11 Se ha presentado el contexto de desarrollo de la tesis. En la siguiente sección se
I1 procede a la exposición de los aspectos que lo motivaron.
,' .
il
1.3 Motivación .I1
A la fecha, los SABDs comerciales existentes son capaces de generar
información estadística, tal e s el caso de Sybase [Syb97a][Syb97b] y Oracle
[Ora99a][Ora99b]. Sin embargo, dicha información estadística no es útil para la
determinación del diseño de la distribución, o bien, no es suficiente. En el caso de
SQL Server 7.0 de Microsof, la inkormación estadística se genera en las etapas de
análisis y optimización de la consulta. En la etapa de análisis, las estadísticas se
refieren al número de exploraciones (iteraciones), número de lecturas lógicas (a
memoria caché), número de lecturas físicas (almacenamiento físico) y número de
lecturas anticipadas. En la etapa de optimización se mantiene un registro estadístico
sobre la distribución de datos,dentro de una columna, la cual puede o no ser índice.
Esta información es utilizada por el optimizador para elegir una columna índice, por
medio de la cual se optimice el procesamiento de la consulta. Otras estadísticas son
el tiempo de CPU total y el tiempo de ejecución de la consulta, así como la
selectividad y el número real de ejecuciones de cada paso en su procesamiento
[BM99].
'1
'1
.:. ,
'1
11
/I
1 Ili. ,.!
:I
't
0
11,
$1 'ill
La información anterior no es suficiente para determinar un esquema de
distribución de los datos, considerando que la selectividad si es un dato Útil pero no
suficiente. Por ejemplo, no se sabe cuál es el sitio que realiza la consulta, o bien, la
frecuencia de procesamiento de las consultas. I 1: ,
I '
11 Por otra parte, en la gran 'mayoría de los trabajos de investigación referentes al
il
8
Capítulo 1 Introducción
diseño de la distribución, la información sobre el uso de los datos, se proporciona
con base en la experiencia o en el conocimiento de la aplicación3 [MR95], [CPW87],
[NCW84]. Sin embargo, hasta ahora los datos no han sido obtenidos con base en la
explotación real de un SABDD. Esto presenta desventajas evidentes, como el hecho
de que los esquemas obtenidos de distribución de los datos no sean correspondientes
con la realidad, y en consecuencia el establecimiento de un esquema de distribución
inadecuado puede propiciar la degradación en el desempeño del sistema en lugar de
optimizarlo.
Una de las finalidades de este trabajo es llegar a conocer de forma cuantitativa
los patrones de uso de una base de datos en explotación, de tal manera que se pueda
obtener información estadística útil en la determinación del diseño de la distribución
de los datos.
El trabajo de tesis es uno de varios esfuerzos encaminados hacia la
automatización del diseño de la distribución en una base de datos distribuida, basada
en la utilización de un modelo de programación lineal entera 0-1 denominado FURD
(Fragmentación Ubicación y Reubicación Dinámica). Con este modelo se optimiza
el diseño de la fragmentación vertical y la ubicación de los fragmentos a través de la
base de datos distribuida [PPR98].
Hasta ahora la información requerida por el modelo para la determinación del
diseño de la distribución, había sido obtenida de manera aislada al sistema en
explotación y basada en la experiencia. En particular, el trabajo presentado consiste
en la automatización del proceso de captura de la información estadística requerida
por el modelo FURD. Dicha información estadística representa patrones de
’ En el primer caso, a través del tiempo el administrador ha adquirido la experiencia para determinar de forma aproximada los patrones de explotación. En el segundo caso, conoce la aplicación y en consecuencia puede conocer su comportamiento.
9
introducción Capítulo 1
I!
explotación de los datos a partir de las consultas relevantes en el sistema. En la
Figura 1-2 se muestra la interacción que tiene esta tesis con otros trabajos cuyo
objetivo, en conjunto, es la automatlzación del proceso de diseño de la distribución,
en particular con el modelo matemático FURD.
't
Obtentión Automatizada de "Información Estadística sobre el uso de los Datos
información Estadística
Distribución
Figura 1-2 Automatización del Proceso de Disefio de Distribución de Datos
11 1.4 Descripción del Problema
11
El siguiente ejemplo muestra gráficamente el proceso de diseño adaptable para
una BDD. En la Figura 1-3 se presenta un sistema formado por tres sitios. Para
efectos de este trabajo, no es relevante conocer la topología de la red, y es suficiente
conocer que los sitios están interconectados. El esquema de distribución de los datos
inicial está dado de la siguiente manera: Se almacena la Tabla A en el sitio SI y la
Tabla B en el sitio SZ (ver Figura i-4). Una vez que el sistema entra en operación, se
pueden identificar los patrones de acceso a los datos (ver Figura 1-5). Como se
observa, el esquema inicial de distribución de los datos tiene correspondencia con
los patrones de explotación iniciales, es decir, los datos están almacenados en los
sitios donde. su-explotación ,. , es,,mayor.
il
t
¡I
/I
I1
;/ :I
./I !I
10
II
Capítulo 1 Introducción
Tabla B
I I
r------
1 1 1
Figura 1-3 Siiios de la Red Figura 1-4 Esquema de Distribución de los Datos
Figura 1-5 Patrones Iniciales de Exploiación de los Daios
I Figum 1-6 Nuevos Patrones de Explotación de los Daios
A través del tiempo los patrones de explotación se van modificando según los
requerimientos de información desde los distintos sitios (ver Figura 1-6).
0 0 - 0 0 5 6
1 1
Capítulo 1 Introduccion I1
'1
Figura 1-7 Migración de Dalos - Tabla A
1 I
Figura I!8 Migración de Daios - Tabla B
1 Figura 1-9 Esquema de Dishi8ucidn de los Datos Adaptado a Pairones de Explotación
.I
Ante estos cambios en los patfones de acceso a los datos, un sistema ideal debe
evitar la degradación en su desempeño, modificando el esquema de distribución de iJ
Introducción Capitulo 1
los datos, adaptándolo a los nuevos requerimientos de información. En la Figura 1-7
se muestra la migración esperada de la información referente a los datos de la Tabla
A , de tal forma que los datos se lleven al sitio donde son más solicitados. Podemos
suponer que el mismo proceso se repite para los datos de la Tabla B (Figura 1-8).
introducción Capítulo 1
!!
!I cambios en los requerimientos de la información, podemos afirmar que el proceso de
diseño de una BDD se ha convertido en una tarea difícil para el administrador de la
base de datos y por lo tanto, se puede pensar, que el mismo sistema tuviera la
capacidad de realizar todo el proceso 'de forma dinámica.
. .,
I!
El problema particular de este'trabajo de tesis consiste en lo siguiente: I¡ '
I Determinar la frecuencia de procesamiento de las consultas, en un mismo
sitio del sistema y por un mismo cliente. Se debe obtener información
adicional, Útil para determinar el diseño de la distribución de los datos. Esta ,/
información incluye lo siguiente: cliente emisor de la consulta, selectividad
promedio de la consulta procesada, columnas . y tablas involucrados en la
1
0
consulta y predicado4. I/ Ill
Por otro lado, también es necesario identificar aquellas consultas con
diferencias sintácticas. El lenguaje de consulta SQL es flexible, por lo que
permite definir una misma consulta de variadas maneras, es decir, se puede
obtener el mismo resultado mediante consultas que aparentemente son
diferentes. Para .efectos de este trabajo, es necesario identificar este tipo de
consultas, ya que sólo así se podrá mantener un registro real de la frecuencia
de procesamiento de las consultas.
' I1 ,
1)
Il:
!j
/I 1 ,
1.5 Objetivo
El objetivo del trabajo de tesis consiste en desarrollar un módulo que obtenga
de manera automatizada información estadística de la explotación de una base de
datos distribuida mediante el uso ,de trincipios de bases de datos activas. 'I
dl
I1
Cabe mencionar que a lo largo del documento se hará mención a la frecuencia, como el número de veces que 4
una consulta es detectada en el sistema, esto es, dentro del periodo fijado por el ABD para realizar el monitoreo. En el caso de la selectividad, ésta se refiere al número de tuplas de una relación.
14
Introducción Capítulo 1
I 1.6 Propuesta de Solución
Para obtener'la información estadística sobre el uso de los datos, es necesario
monitorear el desempeño del sistema, así cuando se procesa una consulta, el sistema
puede detectarla y registrar la in formhón correspondiente a dicha consulta. I
Mediante el enfoque de bases de,datos activas se realizó un módulo que forma
parte del SABDD utilizado, añadiendo así la capacidad activa al mismo. Este I
módulo consta de dos partes: un Precomprlador útil en la definición de las Reglas
ECA, las cuales son el mecanismo mediante el cual se define el comportamiento
activo y, un Intérprete encargado del procesamiento de dichas reglas.
La implementación de los submódulos antes mencionados, fue especificada
formalmente mediante una gramática libre de contexto correspondiente a la
definición de un Lenguaje de Reglas ,ECA. En dicha gramática se especifican tanto
las acciones semánticas al tiempo de interpretación como al tiempo de 71
precompiiación. II
1.7 Alcances : 4
Como alcance de este trabajo se establecieron los siguientes puntos:
I implementar un módulo computacional para monitorear el desempeño del
sistema en cuanto a la explotación que se hace de los datos. Esto es con la
finalidad de registrar la información estadística requerida para la
determinación del diseño de la'distribución de los datos. Dicho módulo se
integró a un SABDD experimental denominado SiMBaDD.
La información estadística generada es la requerida por el modelo matemático
FURD descrito en [PPR98]: i,
!! 'I,
I,
i l l
\ I
1
Capítulo 1 .. > II
Introducción
. I , ,
1 I Nodos desde los cuales se.realiza$a consulta. . : , * , , , . I I
t. 1 II ' ,~ /I1 I Columnas accedidos.
I Tablas accedidas. 1 '4 I1
4 I Frecuencia de ejecución de las cdnsultas. . , , . (1) '; I , , . . . / I ,
I Selectividad promedio por consulta. I " I
Se consideran sólo operaciones de consulta para el registro deillos datos .>., .
!
111
En el trabajo de tesis no se desarrollarái,la ejecución del modelo matemático,
ni la ubicación dinámica de los/ datos. El objetivo del trabajo propuesto es
hacer disponible la información estadística nepesaria para reali'zar dichos
II II
II 11
. . dl . . I 8 1 .~
procesos. li
Para dar solución a la problemát,ica que'se presenta, se emplean los principios
de bases de datos activas. Esto permite dotar de 'la propiedad de dinamismo al 'li I1
II módulo de generación de inform'ación estadística. i).
,I 1 1.8 Organización del Documento I
El Capítulo 2 aborda los aspectos a los principios de Bases de Datos I
Activas. Se presenta desde:la historia,ldel enfoque activo, pasando por e¡ ,I estado del
arte correspondiente .a los prototipos1 que utilizan ,esta metodología, así como lo il 11 referente al mecanismo de Reglas ECA en el que se basan las BDAs.
I!
1 1
11 Ill ill i il
En el Capítulo 3 se presentan, los requerimientos para la implementación
computacional que da solución al problema que se aborda. Dichos requerimientos se
presentan en el sentido de una gramática independiente de contexto correspondiente II II
al Lenguaje de Reglas ECA diseñado, para el establecimiento del comportamiento
't
il
I! '!
Capitulo 1 Introducción
activo. Dicha gramática incluye las acciones semánticas al tiempo de definición y de
procesamiento.
La implementación del Lenguaje de Reglas ECA diseñado, se muestra en el
Capítulo 4. Primero se presenta la arquitectura del Precompilador empleado para la
definición de las Reglas ECA, y finalmente la parte correspondiente al Intérprete
que procesa dichas reglas.
En el Capítulo 5 se presentan las pruebas realizadas al módulo de Detección y
Registro de Eventos Relevantes, así como los resultados obtenidos.
Finalmente, en el Capítulo 6 se presentan las conclusiones del trabajo de tesis,
incluyendo la propuesta de trabajos futuros relacionados y los beneficios obtenidos.
El Apéndice A aborda los esfuerzos realizados por estandarizar el mecanismo de
disparadores, empleado en la mayoría de los SABDs comerciales de manera poco
uniforme.
Las características referentes a las bases de datos activas se presentan en el
Apéndice B. Así mismo se incluyen dos tablas comparativas de dichas
características entre el trabajo presentado en este documento y (1) otros SABDAs, y
(2) la definición del estándar SQW.
En el Apéndice C se presenta una lista de publicaciones recomendadas en el área
de BDA.
i 'I 17
Capítulo 2 Bases de Datos Activas
Capítulo 2
BASES DE D A ' ~ O S ACTIVAS
. , !I
Puesto que las bases de datos activas! son una tecnología emergente, los
investigadores aún no han llegadoba un consenso en cuanto a la definición de un
concepto claro y uniforme para un sistema que pueda ser considerado a ~ t i v o . ~ '!
'I Por esta razón, dentro del contexto de este documento, basaremos el concepto de
capacidad activa de un SABD en e1"conjunto .de Eventos y Acciones con que cuente
el sistema. En esta sección sólo se delimitará el concepto de un sistema de bases de
datos activas así como el de un sistyma de bases de datos convencional o pasivo. En
secciones posteriores se abordará 18 referente a las Reglas ECA, incluyendo eventos
y acciones.
11
,'I
1
Después de analizar distintas definiciones referentes a un sistema activo, se
determinó el siguiente concepto deiun sistema de bases de datos activas: sistema
que por s í mismo es capaz de lidesarrollar operaciones automiíticamente, en
respuesta a la ocurrencia de ciertos eventos o al cumplimiento de ciertas
condiciones. Tanto Eventos como Acciones van más allá de las operaciones de
manipulación de daios. aunque también las incluyen.
81 11.
;I
d l Ahora bien, un sistema de base de datos convencional puede contar con algunas
propiedades de los sistemas activos, es decir, puede o no tener la capacidad de
presentar un comportamiento reactivo ante ciertos eventos o ante el cumplimiento de
t
Algunas de estas definiciones se pueden encontrar en PGG951, PHW951. 5
I 19
I I
Bases de Datos Activas Capítulo 2
I i
I! . .
!I 11 'I
I . ciertas condiciones. En este caso, Eventos y Acciones están limitados a operaciones
de manipulación de datos. Bajo la definicibn anterior, queda clarojl que un
subconjunto del total de los sistemas convencionales, también llamados pasivos,
presentan cierto grado de capacidad activa, la cual está limitada. Este suhonjunto
.,I.
'I I/ I/
está dado por los sistemas de bases de datos con mecanismo de disparadores, los
cuales sólo responden a eventos de manjpulacion de datos y reaccionan midiante la
ejecución de operaciones del mismo tipo. La Figura 2-1 ejemplifica la taxonomía
determinada por el umbral de operaciones descrito.
i II n !I .
It
Mayor Capacidzd
Activa
U
Menor Capacidad
Activa
Figura 2-1 Taxonomía de Bases de Datos en cuanto a su CapacidadAcfiva
I¡ I
11
II I1 Una vez presentados los conceptos básicos se enumeran algunas ventajas de los
sistemas activos sobre los pasivos6: ,( 111 I1
!I . t
111 ' 'I( 'I
(1) Pueden desarrollar funciones que en SABDs pasivos deben ser codificadas en
aplicaciones, por ejemplo restricciones de integridad general y disparadores.
(2) Facilitan el desarrollo de aplicaciones pertenecientes al alcance de los propios
Para mayor detalle de las funciones involucradas en cada uno de los puntos ver [wC96]. , . ,
. .
20
~~ .- . . . . .. . .., .. . ._ - ... .. .
Bases de Datos Activas Capítulo 2
SABDs pasivos, como son manejo de “workflow” y sistemas expertos para
cantidades masivas de datos.
(3) Pueden desempeñar tareas que requieran subsistemas de propósito especial en
SABDs pasivos: restriccionej de integridad simple, autorización, generación
de estadísticas y vistas materializadas. I \
En la siguiente sección se presentan los primeros indicios del enfoque activo y .I
cómo se fueron sentando las bases para los sistemas activos.
2.1 Antecedentes
El área de las BDAs fue realmente reconocida hasta mediados de los 80s con la
aparición del. primer sistema administrador de BDAs: el proyecto HiPAC. Sin
embargo, algunas características dei este enfoque fueron apareciendo desde los 70s
[WC96].
.I
I,!
A inicios de los 70s aparece un lenguaje de manipulación de datos (CODASYL)
que incluía un mecanismo para la invocación automática de procedimientos en
respuesta a operaciones específicas sobre la BD. La sintaxis empleada es la
siguiente: ON <command list > CAhL <procedure> I
8 1
El símbolo <procedure> especifica el procedimiento especifico y <command
list> especifica uno o más de los’iomandos INSERT, REMOVE, FIND, STORE,
DELETE, MODIFY y GET. I1
A mediados de los 70s aparde un QBE (Query-by-Example) que incluía la .I . . . facilidad de los disparadores para la verificación de restricciones de integridad.
~
Finalmente, a finales de los 70s, el Sistema R sugirió un subsistema de
SEP CEWIIDET. DGlT CENTRO DE lNFORMACION
I 1 21 i I 1
Bases de Datos Activas Capitulo 2
i I
disparadores, sin llegar a ser implementado-en sds productos. /I 'I I
2.2 Enfoques Alternos II 'I/! ili El empleo de BDA permite monitorear deterpinados eventos de interés. Con la
8 1
finalidad de comparar las ventajas de las I Bases de Datos Activas, en esta sección se ¡I 3 ¡I
periódicamente el estado del sistema. '11 I1 !I i(
describen métodos alternos, por medio de los cuales se puede realizar el rionitoreo
en sistemas pasivos: modificando el Código de las aplicaciones o verificando
I
2.2.1 Modificación del Código II
En el primer método, el desarrollaaor incluye condiciones de monhoreo en
lugares apropiados en el código de los programas, es decir, en los lugares donde
existe la posibilidad de ejecutarse un evento de interés. Esta solución'result: fácil de
implementar y no implica modificar el SABD.
I 11
Los principales problemas que se presentan 11. son Y los siguientes: iJl, 'I , I 'i I .
II ' . . /I !I i) El desarrollador de la aplicación :tiene que conocer y tomar en cuenta las
condiciones ha ser monitorear y entonces,,codificarlas como parte de la aplicación.
~
!
ii) El código de las condiciones de monitoreo ,no es mantenido o manejado por el
propio SABD y por lo tanto no puede ser compartido por otras aplicaciones, es por
ello que dicho código se repite en cada una de ellas.
I/ II 11
!
II iii) El software de mantenimiento de?los programas de aplicación del SABD es
muy complicado debido a la falta de modularidad y reusabilidad de código [Cha92]. 111, !
It I1
22
I
i
i
i i
! I
I I I 1 i i
Capítulo 2 Bases de Datos Activas
It 2.2.2 Verificación Periódica
Si se realiza la verificación periódica del estado del sistema, cada condición es
verificada temporalmente, y si dicha condición se cumple entonces se ejecutan las
acciones apropiadas. Sin embargo, la frecuencia de verificación debe ser
determinada considerando la complejidad de las condiciones. En general, esto puede
ser una carga para el administrador de la base de datos, ya que tiene que indicar
explícitamente la frecuencia de verificación.
I !i
;I !I .(I
I): . Esta técnica no es apropiada para sistemas con restricciones de tiempo, debido a
que si la frecuencia de la verificación es alta, entonces el desempeño del sistema se
ve afectado, ya que debe detener su ejecución para dar paso a la aplicación que
realizará la verificación. Por el contrario, si la frecuencia de verificación es baja, no
podemos detectar todos los eventos a tiempo. De ahí las desventajas de este método
de solución.
4L
I1
!I I!. ,i.
I ti.
!! 2.3 Reglas ECA
Las Reglas ECA son el mecanisino mediante el cual se define el comportamiento
activo en BDA. Los lenguajes de reglas ECA tienen su origen en los lenguajes de
reglas de producción de Inteligencia Artificial. Dicho paradigma ha sido adaptado al
contexto de BDAs, de tal forma que las reglas puedan responder a las operaciones
propias de un sistema de bases de datos (ver Figura 2-2).
t i
11
La forma general de las reglas en IA es la siguiente: Patrón-tAcción. Estas
reglas son llamadas basudus en parrones. Su procesamiento se basa en un ciclo (Ver
el algoritmo en la Figura 2-3). La fase de correspondencia identifica las reglas cuya
condición se cumple sobre el estado de la base de datos, y las agrega al conjunto de .I/
conflicto, representado por una cola del conjunto de reglas disparadas.
. 'P
II
23 il
Bases de Datos Activas 11 i! Capitulo 2
I I \\I
Inteligencia Artificial
I¡
I I' II
'I/ ,v d
di Ill I' it
¡I i/ 11.
li Ill
Figura 2-2 Origen de ?as Bares &e Aciivas 'I 'I
La fase de resolución del conflicto selecdiona una regla del conjunto de reilas en la
cola del conjunto de conflicto para ser procesada, y en la fase acción, se ejecuta la I1
parte de la acción de la regla 'se¡eccionada. El patrón' puede ser un predicaho o una
condición. En este tipo de reglas el evento está implícito, y esta dado por el cambio
en los valores de los datos en la memoria de trabajo, una vez que éstos enbuentran
correspondencia con el patrón definido en la regla [HW93].
. .
t 8 ,
correspondencia mientras (el conjunto de cahflicto no este vacio) hacer
jC j/ solución del conflicto acción correspondencia
fin-wbile I1 ~~
I/ Figura 2-3 Algoritmo de l+&samlento de Reglas en IA
ic La diferencia principal entre el lengdje de reglas de IA y el lenguaje de reglas
de bases de datos es la definición explícita en el último caso del evento. +a forma general de estas reglas es la siguiente: li, Ill il
,e
I On evento ,If condición Then acción '11 'li
Esta forma permite que las reglas sea; disparadas por eventos en el sistema, por
ejemplo, operaciones sobre la base de datos. Cuando un evento de interés ;curre, la s1, 11
I
I
Capítulo 2 Bases de Datos Activas
condición es evaluada contra la base de datos; si la condición se cumple, se ejecuta
la parte de la acción de la regla. Ver el algoritmo en la Figura 2-4. Ir
I mientras (haya reglas disparadas) hacer evalúa la condición de la regla si (la con&ción es verdadera) hacer
ejecuta la acción de la regla fin-mientras
Figura 2-4 AIgori&o de Procesamienio de Reglas ECA II
El evento representa cualquier vsituación . de interés, capaz de disparar alguna
regla ECA. Los eventos pueden set primitivos o compuestos. Ejemplos de eventos .'1 primitivos son modificación de datos, recuperación de datos, eventos de tiempo, y I! eventos indicados por una aplicación. It ' 1
La cláusula if especifica la condición a ser evaluada una vez que la regla ha sido
seleccionada. Se considera que la cbndición representa el contexto dentro del cual el
evento es detectado.
I
I!
La cláusula then especifica una o más acciones a ejecutar cuando la condición en
la regla se cumple.
En cuanto a las ventajas de emplear este mecanismo podemos mencionar las
siguientes [SHP96]: II
it I Las reglas tienen una descripción declarativa, la cual incluye la condición
donde se usa la regla.
I Las reglas tienen una descripción modular. Cada regia representa una parte de
la extensión.
il.
I/i
Como se puede apreciar, los principios de bases activas se apegan a la naturaleza
dinámica del problema que se aborda en esta'tesis y facilitan su implementación.
Bases de Datos Activas Capítulo 2 ~
II I1 i:
I1 !
i
I .
2.4 Estado del Arte
Actualmente existen varios SABDAS 111, tanto experimentales 11 (POSTGRES!'[SJG90], I
Ariel [Han91], Starburst [Wid92], SAh4OS [GGJb95], Mariposa [SAP97], Ffamboise
[FGD98], Sentinel [CKT94], etc.) ~ coho comerciales (Oracle [Ora99]; Sybase
[Syb97], Ingres [WC96], etc.).
'11 I/
li 4 '
,I llil I)
'11
La capacidad activa se considera un mecanismo que soporta un gran numero de
I/ :I1
funciones del mismo SABD, .tales como :I mantenimiento de seguridad e . in.fegridad,
mantenimiento de vistas materializadas, manejo de restricciones e inferenci. basada
en reglas. Pero a la fecha ninguno de los SkBDs mencionados anteriormente
aprovechan su capacidad activa para la generación de información estadística útil
para el diseño de [a distribución de los datos en el sistema.
:I! 1 ll I
nii
' : I , !/I lib ' '' JL A continuación se presenta una breve descripción de la arquitectura del algunos
I/ I1 .
de estos SABDAs con la finalidad de visualizar los distintos aspectos que han Y
I
implementado en su parte activa. ii I1 ,I
.,
2.4.1 ARIEL
Este SABD fue desarrollado en la Uniuersidad;jde Florida por el investigaclor Eric
N. Hanson. La parte más relevante de la arquitectura en Ariel es un módulo que I1 .
genera una Red de Discriminación, mecanismo empleado para la evaluación de la !I ' .I/ .
condición de la regla. Dicho mecanismo se considera eficiente dado que mantiene en
memoria una parte de los resultados de ?a condición procesada, 'agilizando así su
/I
I/
II \ procesamiento. ij
I
II /I Los componentes de la arquitectura de Ariel ''[Han911 son los siguientes: Lado
Frontal (Analizador Léxico, Analizadhr Sintactico, Analizador Semá;ntico y
Optimizador de Consultas); Lado Posterior (Ejecutor del Plan de Consulta); 1 1
26 il I
Bases de Datos Activas Capítulo 2
Discriminación
Sistema de Reglas (Catálogo de ;Reglas, Red de Discriminación, Monitor de
Ejecución y Planificador de la Acción de las Reglas).
Léxico / Sintáctico Arbol
Sintáctico
A continuación se presenta la descripción de los componentes, del Sistema de
Activación 11 de la Regia
Reglas de Ariel:
Catálogo de Procesador de Reglas Consultas
4
!I
Monitor de Ejecución de
Regias
Comandos en SOL , IActualización
de tupias
Regia ~ Planeador de *'+ la Acción de
I' la Regla
Red de Discriminación: Ariel ¡cuenta con una red para la evaluación de las
condiciones de las reglas, la cuál está diseñada para aumentar la velocidad en el
procesamiento de las reglas en un ambiente de bases de datos y para reducir los
requerimientos de almacenamiento de la misma red. La Red de Discriminación
permite seleccionar la forma de evaluación de la condición, según convenga.
Y j i
F
Bases de Datos Activas 6 fi 1 Capítulo2
! II II; .
I
Monitor de Ejecución de Reglas: Mantiene !ma agenda de reglas por prioridades I !I l8 11 I1 1
y está basado en tres métodos:
addRule. Llamado por la Red de Discriminación. Agrega una regla a la agenda,
si no está ya incluida, cuando la condición de la misma se cumple, indicando que I1 I1 li
I1 dicha regla se encuentra activada,, I en este momento se genera la red de
I1
discriminación. También se almacenan las tuplas que cumplen la condición en
una estructura temporal p-nodo. 11, ; I II
, I
removeRule. Llamado por la Red de Discriminación. Elimina la regla de la I, I/
agenda cuando la condición ya no se cumple.
runRules. Llamado por el ejecutor. de consultas al final de una transición, para
disparar la última regla activada de mayoq prioridad a ser ejecutada por el
II 11
1 I
Planeador de Acción de Reglas. I
il /I I! III
Pianeador de la Acción de la Regla:, ste módulo se encarga de realizar el plan
de consulta para obtener las tuplas involucradas en la parte de la acción della regla.
Tiene dos opciones para hacerlo: por uh lado, cuando en la acción aparece una
r" I
variable tupla que también aparece, i en la condición, recorre la4 tuplas
correspondientes sobre la estructura temporal (p-nodo) que ya las contiede; de lo
contrario se emplea un indice para actuar sobre la relación directamente. . , 'Ir. lib '111
! 4 II
Autonomía Implementada: El tiempo en el que se construye el plan del'consulta
es muy importante para el desempefio dkl sistema, y Ariel soporta sobre 'SU parte
activa una técnica llamada "reoptimiza siempre" con la que el plan de consulta se
genera en el momento de disparo de la regla.
*I ;I\. '11 111
.i/ .It 4 ..
li I !
',
Capítulo 2 Bases de Datos Activas
2.4.2 MARIPOSA it
Mariposa [SAP97, SAD941 es un SABDD para redes WAN, en el que cada sitio
es autónomo. Este proyecto se encuentra bajo la dirección de Michael Stonebracker
en la Universidad de Berkeley.
Jil
Ili
111;
4s
11
Todos los sitios tienen una cuenta con el banco de la red. Un usuario proporciona
un presupuesto en la moneda del banco a cada consulta. De esta manera cada sitio
Mariposa realiza decisiones para comprar o vender un fragmento de información.
INTERMEDIARIO
Fragmentador
Agente
Coordinador ,'I
MODULO DE EJECUCIÓN
LOCAL
Parte activa
Figura 2-6 Arquitecíura de Mariposa [SAP971 4
La arquitectura del SABD es como sigue:
INTERMEDIARIO "k
Analizador Sintáctico: Maneja ia consulta en forma de árbol sintáctico. Elige el
servidor más adecuado para cada 'tabla invoiucrada basándose en los precios que
ofrecen los servidores, el presupuesto disponible y algún sistema de reglas definido
'I
11 29
II I!
Bases de Datos Activas ~ , Capítulo 2 I1 I 11
localmente que asigne prioridades a estos 'I factores. , ' l j :
II I/ II
íl 11
'I I/ il !I
. , I !
1 I1 /I
.~
Optimizador de' Sitio Único: Genera un plan de ejecución para la consulta i 1 ill! , ' 1) .I/. suponiendo que todos los fragmentos están almacenados en el sitio local.
I*
Fragmentador: Descompone el plan producido por el módulo anterior en un plan
de consúlta fragmentada. El resultado es una consulta por cada fragmento:/referido.
Se agrupan las consultas que se pueden realizar en paralelo para mejorar el
desempeño. ' ! I
Agente: Toma los planes de la consulta fragmentada y envía los requerimientos a
los distintos servidores para'recibir de ellos sus ofertas, notificando a los que hayan
sido aceptados. Finalmente se encarga de que io; resultados de las consulta& lleguen
al Coordinador.
dk
II. !I
I i:
Coordinador: Ensambla los resultados de las consultas parciales y regresa el II I¡ I
resultado al proceso usuario.
ll 'I
M ~ D U L O DE E J E C U C I ~ N LOCAL ;I /j
Postor: Es el módulo encargado de formular su oferta en respueda a los II requerimientos recibidos por parte de otro servidor. Para ,proporcionar su ;espuesta I 1 I1
se basa en los recursos locales (CPU, almacenamiento disponible, disco, etc.). Si no
cuenta con el fragmento solicitado puedellrechazar la petición o intentar comprarlo a otro sitio. I1 i
II I1
Ejecutor: Cada sito Mariposa tiene un número de módulos de ejecución local
que controla el grado de multiprocesami'ento. Ai cada ejecutor ocioso se . . le asigna 'I una subconsulta y después envía el resultado al sitio que procesará la siguiente
parte, o bien, al Coordinador.
. .
iII ./I '.
'I I
I!
Bases de Datos Activas Capitulo 2
Administrador de Almacenamiento: Determina la renta generada por los
fragmentos almacenados. Basado en espacio y consideraciones de renta, este módulo
!I
I.
negocia con otros sitios la compra y venta de fragmentos. ',
Autonomía Implementada: Los tres componentes del Ejecutor Local (Postor,
Ejecutor y Administrador de Almacenamiento) están codificados sobre la parte
activa de Mariposa, por lo que la autonomía del SABD está orientada
principalmente al manejo óptimo del almacenamiento de los fragmentos.
,'I . ..
Además Mariposa cuenta con una serie de Eventos Definidos para restricciones
de procesamiento, balance de cargalen el sistema y restricciones de dependencia de
datos. También cuenta con Acciones Construidas para enviar y recibir un fragmento,
para contactar un determinado sitiory solicitar un fragmento o para liberar un evento
a una serie de sitios (empleado pantrabajo cooperativo).
1,
i)
,'I
2.4.3 Chimera
Chimera (Politécnico de M i l a d , Stefan0 Ceri) es el nombre de un modelo de
datos conceptual orientado a objetos (Chimera Model, CM) y del sublenguaje de
base de datos correspondiente (Chimera Language, CL). Este último provee
definición de datos, consultas declarativas, primitivas para la manipulación de la '1
base de datos, así como varias formas de regias y restricciones [CM93a].
Los componentes de su arquitectura son los siguientes:
lade: Herramienta CASE que recolecta las especificaciones del esquema.
Produce como salida dos archivos Chimera: definición del esquema de restricciones
y disparadores para mantener la integridad del esquema.
.I1
'i
11
Argonaut: Soporta la generación de reglas activas provenientes de la
I3 1 Bases de Datos Activas Capitulo 2
I I II I1 II
especificación de las restricciones de intkgridad y vistas. . . . i/: I1 i1 Jj
II! 111 Ill
, .: , , . , . , '. . . Arachne.. Analiza la terminación del tiempo de compilación' de un conjunto de
,
reglas activas de Chimera. Determina las causas que originan ejecuciones infinitas. I I 41 11, 111
Algres: Es el ambiente de ejecución para un prototipo rápido1 de una especificación de diseño Chimera. '11 11 .I1
I I I1
di '1 ,I
Pandora: Traduce una aplicación Chimera a Oracle 7.2 I
II I1 I, Autonomía Implementada: Bajo Chimera los disparadores son conciderados
como reglas activas y las implementacidnes que se han desarrollado con ellos son
II 'I1 II los siguientes:
I 11 !I Verificación de restricciones de infegridad estática, es decir, a través de
disparadores se mantiene la integridad de la base. de datos al final ide cada
transición.
Verificación de restricciones, de integridad dinámica. Se determina si,l algunas
secuencias de eventos pueden violar .la integiidad, aún cuando separados no lo
I! i t
I1 .I
: I1 I, ii I/
'I
hagan.
1 I1 11
Materialización de vistas o de datos \derivados mediante reglas que se activan
inmediatamente. li 1
I
2.4.4 SAMOS ii il
'I Los eventos que maneja'SAMUS, SABD desarrollado en la Universidad de
Zurich por Stela Gatziu, pueden ser primitivos o compuestos. Dentro! de los
primitivos se tienen eventos de tiempo (los cuales ocurren en un punto específico en
el tiempo o periódicamente), eventos de/envio úe mensajes (ocurren al in/'cio o al
11, II :ll
I1 I1 .I/
'!
32
I!
'I
Bases de Datos Activas Capítulo 2
final de la ejecución de un método), eventos.de valor (ocurren al inicio o final de
una operación de modificación de datos), eventos de transacción (ocurren antes O
después de una operación de transacción) o eventos abstractos (los cuales no son
detectados por SAMOS pero han sido señalados explícitamente por una aplicación o
por un usuario). Los eventos compuqstos se construyen a partir de eventosprimitivos
o por otros eventos compuestos.
21.
9)
8 : '
El prototipo está constituido porbtres bloques: (a) un SABD orientado a objetos
llamado ObjectStore, (b) una capa sobre el SABD que representa la capacidad activa
formada por una serie de componentes como el Administrador de Reglas, el
Detector de Eventos Compuestos y:.un Componente de Ejecución, y ( c ) un conjunto
de herramientas compuesto por un compilador, un analizador, un editor y un
visuolizador de reglas.
!l.
.I1
il
iI
i!
Para comprender el funcionamiento de la arquitectura de SAMOS [Gat971
veremos cómo se realiza el procesamiento de las reglas:
Fase de Señalamiento: Después de haber recibido un mensaje de evento
sucedido por parte del Detector de Eventos Primitivos, se recupera el objeto del
evento apropiado y se mantiene su historial (registros de las ocurrencias del .evento).
El Administrador de Reglas verifica si el evento pertenece a uno compuesto, de ser
así se informa al Detector de Eventos Compuestos.
I
'I.
Fase de Disparo: Se procesa la historia del evento, es decir, se disparan las
reglas asociadas a los eventos señalados en la fase anterior. Finalmente se determina
un conjunto de reglas disparadas. I)
't Fase de Planeación: Una regla se selecciona del conjunto de reglas disparadas.
Las reglas se seleccionan en el o!den en que sus eventos fueron insertados en la
Bases de Datos Activas !I , I1 1 Capitulo 2 I
I! I! 1 historia del evento compuesto. Cuando Npe dispara miis :de una regla paravpl mismo
II
li 4 Señalamiento de eventos
.......... * Recuperación y almacenamiento de eventos y reglas 61. Ejecución de réglgias 'b - ,
'/I I Figura 2- 7 ArquiteduLa de S@OS rGat97J
Fuse de Ejecucidn: En esta fase se kjecuta 'bada .regla seleccionada durante la
fase anterior. Otros eventos se pueden s&aIar ptoduciendo una ejecución de reglas
anidadas. En este caso.se interrumpe la djecución de la acción hasta que se ' Y termina
la ejecución de las reglas anidadas. I/ 4
'I I!
'I
II '11 Autonomía Implementada: Una característica relevante de este SABD es que
cuenta con un poderoso detector de evehtos compuestos basado en el modelo de
Redes de Petri. Cada clase de constructor ,de un evento compuesto define una Red de
Petri. El empleo de esta técnica permite el manej8 de eventos compuestos de manera
sencilla, ya que cada evento primitivo est'a representado por una plaza de la Red de '1
Petri.
1)
/I 1 I,
~
I¡ I1 11
II .I
3.4 !I
..... ~~. . ~ ~ . .
Capítulo 3 Lenguaje de Reglas ECA
Capítulo 3
LENGUAJE DE REGLAS ECA (1 it.
Tradicionalmente se ha tratado la parte referente al lenguaje de definición de las
Reglas ECA de manera informal como en [Wid92], [Gat971 y [Han91]. Sólo en el
caso de algunos SABDAs se representa formalmente el lenguaje de definición de las
Reglas ECA empleado, tal es el CASO de Chimera [CM93], Framboise [FGD98] y
Snoop [CM93b].
11
Ill
'r r
11
En la mayoría de los SABDAs el lenguaje de definición empleado es una
extensión del lenguaje propio del. sistema, como puede ser SQL'. A manera de
ejemplo están Postgres y Ariel que extienden el lenguaje de consultas POSTQUEL,
o bien, Starburst que extiende el SQL. En particular, el lenguaje definido en este
trabajo es independiente de SQL, aunque en trabajos futuros se puede ampliar para
incluir predicados o consultas en dicho lenguaje, como parte de la definición de la
condición o de la acción en la regla.
i
!I
41 La importancia del lenguaje de Reglas ECA radica en que por medio de él se
define el comportamiento activo del sistema ante determinados eventos. La
especificación del lenguaje definido en este trabajo, se basa en los requerimientos de
procesamiento y definición de las Reglas ECA necesarias para la obtención de
nuestro objetivo: monitorear el desempeño del sistema.
' Este también es el caso de los SABD comerciales con mecanismo de disparadores que, aunque los consideramos patie de SABD convencionales? cuentan con una capacidad activa limitada.
ii I I
fJ
1,
li 35
1
II I/ 1
Lenguaje de Reglas ECA ' Capítulo 3 II !! I1
I I Como se mostró en el Capítulo 2, el ecanismo activo requiere de doslaspectos:
( I ) Un mecanismo que permita la especificación del comportamiento activo y (2) Un , . .:/I !
mecanismo orientado al procesamiento de las Reglas ECA definidas: En la' Figura /I I1
I 3-1 se presentan las fases por medio I Ide las llcuales se define e implementa el !
comportamiento.activo antes mencionadb., Esta figura representa la semántica 'para
lenguaje definido, la cual se presenta en mayor detalle en secciones posteriores
mediante acciones semánticas asociadas
6 .-I11 .¡l. I1
las reglas sintacticas.
'I
I 'lb Correspondan al Evento I
Mientras haya Reglas que !/I
Even
II
I AI
)(I 0 Procesamiento ~
pj Definición I/!
'11 81
Figura 3-1 Acciones Semánticas al Tiempo 'de Definición y Procesamiento de Reglas ECA
En la Figura 3-2 se muestra un diagrama de flujo 1 de control en el que se ,' puede
apreciar la secuencia en que se disparan'i los eventos de interés, es decir, la figura ¡I
muestra una parte del aspecto activo del Módulo he Detección y Registro de' Eventos
11 I/ I,
Relevantes al tiempo de ejecución. PrimLro se detecta un evento Consulta (Qry,). II 1) I1
Considerando que es la primera vez pue se procesa se señalan los eventos
AltaConsulta, AltaEstadísticas y Tiempo.11 Si poshormente se generara otro evento !I
It 11
II I1 c 1
sobre la misma consulta, y dado que ya se ha procesado, se señalan los eventos
IncrementaFrecuencia, y Tiempo, En la fiigura se emplean los símbolos granlaticales ,I I!
de la primera regla sintáctica, la cual define la forma general de las Reglas E,CA.
.! 36
.
Capítulo 3 Lenguaje de Reglas ECA
Evento-AltaConsulta Condición-AltaConsulta Acción-AltaConsulta
,
Figura 3-2 Flujo de Control del Procesamienio de las Reglas ECA
En este trabajo se formalizó el lenguaje de Regglas ECA, mediante la definición
de su gramática. En la sección siguiente se presenta la gramática a través del empleo
de la notación Bakus Naur Form (BNF). 'I
3.1 Gramática del Lenguaje de Regias ECA :I1
La notación empleada para la definición de la gramática es BNF extendida. La
extensión consiste de los símbolos y que denotan cero o más ocurrencias de
determinada unidad Iéxica. Además los símbolos no terminales se escribirán en
minúsculas y los terminales con mayúsculas.
I'
'!
3.1.1 Regia ECA
Función: Especifica las distintas Reglas ECA que se pueden definir a partir de los
conjuntos de eventos, condiciones acciones.
ReglaECA : := Evento-IncrementoFrecuencia Condición - Numérica Acción-Numérica !I
I/ i!
Lenguaje de Reglas ECA ,I ! Capítulo 3
!I I I!
1 ,- 4
I1 . . t I
I Evento - Consulta True Acción Consulta
, I! 1 Evento - AltaConsulta Condición-AltaConsulta Acción-AltaConsulta 1 Evento AitaEstadisticas Condición-Ihnérica Acción-Numérica 1
I/ .I
I Evento - . Tiempo Condición -. l;Tiempo kcción-Tiempo !I 'I
- .I1
' t
3.1.2 Eventos Ill I1 I1 . I
Los siguientes símbolos gramaticales especifican el conjunto de eventos. lI I1 ,I/
Evento - IncrementoFrecuencia : := INCRE¡&NTO-DE-FRECUENCIA Evento-Consulta ::= CONSULTA ,ii. 111 111
! II
'). I Evento - Tiempo ::= TIEMPO
Evento-Altaconsulta : := ALTA-BASE-DE-CONSdTAS ' '
Evento - AltaEstadísticas ::= ALTA-DATOS~ES?ADISTICOS-DE-EXPLOTACI6N Ili I1
3.1.3 Condiciones
Los siguientes símbolos gramaticales esdecifican' conjuntos de condiciones %on base
en el tipo de los valores involucrados. 1 I1 Ir
II I Condición-Numérica * . : . ( I y, I
Función: Especifica Condición de tipo numérica.
Condición-Numérica ::=' V&able-Num Op Valir-Num I TRUE Ill' ill
. . , ' I 11 !I
li
I Condición-Tiempo II Función: Especifica Condición de tipo tiempo.
1 Condición-Tiempo : := Variable-Tiempo Op Valor-Tiempo
II
I I Condición-AltaConsulta
lj.
Función: Especifica Condición de tipo alfanumérica. I/ 11 I! Condición-Aifanumérica ::= Variable-Id Op Valor-Num
I Ill I / 'I;
Lenguaje de Reglas ECA 11 Capítu'03
1 Vaiable-Tabla Op Tabla I Variable-Columna Op Valor - Columna I Vanable-Where Op Valor-Where 1 Variable-Cliente Op Valor - Alfanum
I
I TRUE
I, " 1 3.1.4 Acciones
Los siguientes símbolos gramaticales 'constituyen el conjunto de acciones.
Acción - Numérica ::= PASA-QRY-A-RELEVANTES 1 AVISA-DBA I ' I
# , I: '1 EJECUTA-INTEGRADOR
Acción - Consulta ::= LLEVA-ESTADISTICAS I AVISA-DBA
Acción-Tiempo ::= AVISA-DBA 1 EJECmA-INTEGRADOR Acción Altaconsulta ::= AVISA-DBA u -
\ 3.1.5 Variables
Los siguientes símbolos gramaticales conforman el conjunto de variables.
1 Variable-Nun ::= IDENTIFICADOR 1 FRECUENCIA I SELECTIVIDAD
!I Variable-Tabla ::= TABLA 1 Variable-Colma ::= COLUMNA I I Variable-Where ::= WHERE 1 Variable - Cliente ::=CLIENTE I Variable-Identificador ::= IDENTIFICADOR 1,
Variable-Tiempo ::= TIEMPO ,I
:i I\
I
t .
1 3.1.6 Operadores
1 Los siguientes símbolos gramaticales especifican operadores.
II II 39
1 !I l Capítulo3 Lenguaje de Reglas ECA , ,I
I! I/
I :
3.1.7 Elementos Comunes
Valor-Nun ::= Dígito Dígito 1
Dígito::= 1 1 2 1 3 1 4 1 5 ( 6 / 7 1 8 1 9 / 0 , :,
Valor - Alfanum ::= letra letra I dígito 11 letra ::= letra-minúscula I letra-mayfwuia'
1 1
I1
I1 I¡
'. 111 .I1 :I1 , , ti
!I . , 1
::. .' Ib 4 * iL
, . . , .,
3.1.8 Val-Columna. I
Función: Especificación de Valor-Coiumna dl II
Valor-Columna ::= Tabla. Columna Tabla ::= Valor-Alfanum Columna ::= Valor-Alfanum ' . t
!I II
I 'i 3.1.9 Valor - Where
, I II Función: Especificación de Valor-Wliere
1' !i 4 II
I .
Valor-Where ::= Valor-Columna Op Valor-Nd ;l. . .
I Valor-columna o p VJor-Mfanum
4 II !!
3.1.10 Valor-Tiempo I li
'b Función: Especificación de Valor-Tiempo . ,
Valor-Tiempo : := Constante-Año,Constante-Mds,Constante-Día, li
1 ? . * '
I1
I Constante-Hora,Constante-Minuto
'I/ I / , , I . " Constante-Día ::= Valor-Nun I1 !I Constante - Hora ::= Valor-Nun
Constante - Año ::= Valor-Num Constante-Mes := Valor-Num
I
. . . . . . . ,I ~ .,,.
Capitulo 3 Lenguaje de Reglas ECA
111 Constante-Minuto = Valor-Num
TERMINALES = INCREMENTO-DE-FRECUENCIA, CONSULTA, TEMPO, ALTA-BASE-DE-CONSULTAS, ALTA-DATOS-ESTAD~STICOS-DE-
WEGRADOR, LLEVA-ESTADISTI~AS, IDENTIFICADOR, FRECUENCIA,
I\
EXF'LOTACIÓN, TRUE, PASA-QRY'A-RELEVANTES, AVISA-DBA, EJECUTA-
SELECTIVDAD, TIEMPO, TABLA, COLUMNA, WHERE, CLIENTE, =, <, >, O, <=,
>=, 1 ,2 ,3 ,4 ,5 ,6 ,7 , 8,9, O, a, b, c, d, e, f, g, h, i,j, k, I, m, n, o, P, es s, t, u,v, w, x, Y, 2, A, B, C,D,E, F, G,H, I, J, K, L,M,N,'O,P, Q,R, S, T, U, V, W, X, Y, Z)
3.2 Acciones Semánticas 4 . En esta sección se indican las acciones semánticas asociadas a la sintaxis del
Lenguaje de Reglas ECA. Una p ide de estas acciones se ejecuta al tiempo de
definición de las Reglas ECA y 1a.otra al tiempo de procesamiento de las mismas . (ver Figura 3-3). 1
3.2.1 Acciones Semánticas ai Tiempo de Definición 11
,l. Las acciones semánticas de esta etapa están enfocadas a la validación en la
definición de las Reglas ECA. A este tipo de validaciones se le denomina
verificación estática. [I
#I . .
I/
Las validaciones al tiempo de definición son las siguientes:
a) Verificar que el tipo de los valores asignados en una condición sean
correctos; por ejemplo, que ,para la variable Identificador de la gramática el
valor asignado sea del tipo numérico. 11
b) Verificar que los valores "de variables correspondientes a elementos del
diccionario de datos, tales como tablas, columnas y clientes sean válidos, es
decir, que realmente .. formeniparte del sistema.
Lenguaje de Reglas ECA 1 Capitulo 3 I II I1 1
Verificar que el valor definido por el administrador de la base de datos no sea II 11
I
11 I
'1
Constatar ;que el,, formato del ,ralor Fzempo sea correcto, así ,licorno los
parámetros asignados a la parte del a@, r e s , día, hora y minuto. I/.
I,\.
I 1, I 1
'~1
I ENTRADA I SALIDA II I 1
'I Figura 3-3 Generation de Acciones Semániicns
I( I/
Los errores que se .generen a partir/de Jas ,,yalidaciones ,antes mencionadas se
manejan a través de mensajes al administrador que indican el error detectado. .!I: Como II. lb
resultado de estas acciones semánticas no se permite el almacenamiento de alguna /I 'Ii 1
regla que no cumpla con las validaciones manejadas. I1 :r
Enseguida se presentan las acciones semánticas asociadas a la gramática, 111 Y! 'I"
correspondientes al tiempo de definición de las Reglas ECA. Cabe mencionar que se li ha empleado la siguiente convención: "
j ! il I
il
q? .I1 ? I
. . II , .
El símbolo ::= representa una asignación al igual que en la gramática IBNF.
La extensión .val hace referencia! ai valor de una variable utilizada en la
acción semántica.
Los símbolos entre comillas son cdkstanteskasignadas al valor de un simbolo.
I.
11. 'I ..
. < < i1 I! .il , . . ' ! I , I
111.
II I1
42 I1 I1
I I
2. ConvierteACanÓnica(Va1or~ Where). Esta función aplica la función de
conversión a forma canónica al ValorWhere definido.
3 . DiuValidoParaMes(Constanrepia, Constante-Mes). Este método valida
que el número de día definido sea permitido para el mes definido. I
3.2.1.1 Regla ECA Función: Especifica l a s distintas Reglas E C A que se pueden definir a partir de los conjuntos de eventos, condiciones y acciones
I EventoConsulta True Acción-Consulta
I EventoTiempo Condición-Tiempo AcciónTiempo
Evento-IncrementoFrecuencia Condición-Numérica Acción-Numérica
GenCod (ReglaECAval + “\n”)
ReglaECA.val : := Evento-Consulta.val 1‘‘*”11 TRUE I/’”’’ll Acción-Consulta.va1
GenCod (ReglaECA.val + “W)
ReglaECA.val ::= Evento-Tiempo.va1 \“*”I/ Condición-Tiempo.val111<*”/1
Acción-Tiempo.va1
Evento-1ncrementoFrecuencia.val I(LL*”II Condición-Numerica.vaI
I‘‘*”ll Acción-Numérica.val
- - -. ~.
_= ~~ -- ~~~ ~ ~
1 EventoAltaConsulta Condición-AltaConsulta Acción-AltaConsulta
- .. ._ .. . - .. .- . - -.
I EventoAltaEstadistics Condición-Numérica Acción-Numérica
. . - -. .- ~~. GenCod.(ReglaECA.vaI+ ‘W) ~~.
ReglaECAval ::= Evento_AltaConsulta.valI1<L*”ll Condición-AltaConsulta.val -~
/‘‘*’‘I1 Acción-AltaConsulta.val ~=~ . -- .- I
~ ~ . . = ‘i.-=’. . GenCod (ReglaEKval + “\n”) ReglaECA.val : := Evento-AltaEstadísticas.val (‘‘*”/I Condición-Numerica.val Il“*’’/
Acción-Numérica.va1
GenCod (ReglaECA.val + “\n”)
Evento-Consulta : := CONSULTA
EventoTiempo ::= TIEMPO Evento-Altaconsulta ::= ALTA-BASE-DE-CONSULTAS
3.2.1.2 Eventos Los siguientes símbolos gramaticales especifican el conjunto de eventos.
EventoConsulta.va1 : := ‘Consulta’
EventoTiempo.val : := ‘Tiempo’
Evento-AltaConsulta.va1 : := ‘ AltaBaseDeConsultas’
. ~~ - __ __ - , - ~ __=~ 7~ - -7~ ~
. ~ .. . _--- =~ _I I Evento-AltaEstadisticas : := ALTA-DATOS-ESTADISTICOS-DE- I Evento-AltaEstadisticas.va1 ::= ' AltaDatosEstadísticsDeExplotación'
Variable-Id Op Valor-Num I Variable-Tabla Op Tabla 1 Variable-Columna Op Valor-Columna
I Variable-Where Op Valor-Where
I EXPLOTACI~N I I
Condición-AltaConsulta.val ::= Variable-1d.val Ir "11 0p.val Ir "11 Valor-Nurn.val
Condición-AltaConsulta.val ::= Variable-Tabla.val111< "I/ Op.val111< ''11 Tabla.val Condición-AltaConsulta.va1 ::= Variable-Columna.val 1111 ''11 Op.val /Ijl ''11
Valor-Columna.val
Condición-AltaConsulta.val ::= Variable-Where.val 1'' ''11 Op.val 1111 ''11
3.2.1.3 Condiciones
3.2.1.3.1 Condición-Numirica Función: Especifica Condición de tipo numérica
3.2.1.3.2 Condición-Tiempo Función: Especifica Condición de tipo tiempo. ~~~ ~
~ ~ - ~~~ ~~~ .~
~ - ~ - p_ --'- - ~~ ~~
- -
3.2.1.3.3 Condición-AliaConsulta Función: Especifica Condición de tipo alfanumérica.
I I Valor-Where. val I
I Variable-Cliente Op Valor-Alfanum
I TRUE
________--- ___. . ':: , . <. Acciones Semanticas' :
= 'Identifiador'
Condición-AltaConsulta.val ::= Variable-Cliente.val Ir "11 0p.val (I" "(1 Valor-Cliente.val
Condición-AltaConsulta.val : := 'True'
I FRECUENCIA 1 SELECTiVIDAD
- -~ - %riable-Tiempo ::=-TIEMPO~ = .-
Variable Tabla ::= TABLA Variable Columna ::= COLUMNA
Var¡able.val= 'Columna'
Variable-Num.val : := 'Frecuencia'
Variable-Num.vai ::= 'Selectividad'
Variable-Tiempo.val ::= 'Tiempo' Variable-Tabla.val : := 'Tabla' Variable-Columna.val : := 'Columna'
- - -~ ~~
~~
~ -. - - ~~ .- ~~
Variable Where ::= WHERE
Variable Cliente ::=CLIENTE
Variable -Identiticador ::= DENTIFICADOR
3.2.1.6 Operadores Los siguientes símbolos gramaticales especifican operadores.
Variable-Where.val ::= ‘Where’ Vanable.val = ‘Where’ Variable-Cliente.val : := ‘Cliente’ Variable.va1 = ‘Cliente’ Var-Identificador.va1 ::= ‘Identificador’ Variabkvai = ‘Identiticador’
“P ::= = 0p.val ::= ‘=’
I < 0p.val ::=Y’
I’ 0p.val ::=‘Y
10 0p.val ::= ‘0’
I <= 0p.val ::= ‘<=’ 1 % 0p.val ::= ‘<=’
-
3.2.1.7 Elementos Comunes
Dígito ::= 1
... 19
Si (Valor-Num.val< O) entonces ERROR(“Va1or inválido”) Dígito.va1 ::= ‘I’
...
Dígito val ::= ‘9’
10
Si (Variable.val = ‘Cliente’) OR (Variable.va1 = ‘Tabla’) Si (Val-Alfanum val no existe en el Diccionario de Datos) entonces
ERROR (‘Variable.val no existe”)
Digito.val ::= ‘O’
letra ::= letra-minúscula I ietra.vai ::= ietra-minúscuia.vai
- ...
12
I
1 letra mayúscula 1 ietra.vai ::= ietra-mayúscuia.vai
... letra-minúscula.va1 : := ‘2’
.. . .-.. . . - . I
letra minúscula ::=a I ietra-minúscuia.vai ::= ‘a’
letra-mayúscula ::= A
... I Z
letra- mayúscula.val ::= ‘A‘
...
letra-mayúscula.val ::= ‘Z’
.-
3.2.1.8 Val - Columna Función: . . Especificación del Valor-Columna
1 Columna ::E Vai-Aifmum I Coiumna.vai :: = Vai-Aifanum.vai Si (Columna.val no existe en el Diccionario de Datos) entonces
ERROR (Tolurnna inválido”)
3.2.1.9 Valor- Where Función: Especificación de Valor-Where
I Valor-Columna Op Valor-Aifanum
Si (Valor-Num.tipo i= Valor-Columna.tipo) entonces
ERROR(“E1 valor asignado no corresponde al tipo de dato de la columna”) Sino ConvierteACanónica (Valor-Where.val)
Valor-Where.val ::= Valor-Colurnna.valII 0p.val 11 Valor-Alfanumval Si (Valor-Alfanum.tipo j= Valor-Columna.tipo) entonces
ERRORCEI valor asignado no corresponde al tipo de dato de la columna”) Sino ConvierteACanónica (Valor Where.va1)
3.2. I . I O Valor- Tiempo Función: Especificación de Valor-Tiempo
Constante-Día,Constante-Hora, Constante-Día.val111>.”11 Constante-Hora.va1 111>.”11 Constante-Minuto.val Constante-Minuto
Si (Constante-Aao.val > 9999) OR (Constante-Año.val< 1800) entonces ERRORC‘Año fuera de rango”)
- Constante-Mes : := Valor-Num Constante-Mes.val ::= Valor-Num.val
Si (Constante-Mes.val >12) OR (Constante-Mes.val< 01) entonces
ERROR("Mes fuera de rango")
I I Si (iDiaValidoParaMes(Constante-Dia.val, Constante-Mes.val )) entonces
- Constante-Día ::= Valor-Num Constante-Dia.val : := Valor-Num.val
Si (Constante-Día.val>3 I) OR (Constante-Día.val < 01) entonces
ERROR("E1 .. . . día no se puede asignar,al - mes seleccionado") 1 ERRORkDia fuera de rango")
Constante-Minuto : := Valor-Num
I 1 Constante-Hora.va1 ::= Valor-Num.val Constante-Hora ::= Valor-Num Si (Constante-Hora.val > 23) OR (Constante-Hora.val < 00) entonces
ERRORcHora fuera de rango")
Constante-Minuto.val : := Valor-Num.val
Si (Constante-Minuto.val > 59) OR (Constante-Minuto.vaI< 00) entonces ERROR("Minut0 fuera de rango")
Capitulo 3 tenguaje de Reglas ECA
3.2.2 Acciones Semánticas al Tiempo de Procesamiento
Mientras el SABDD se encuentra en ejecución, el Procesador de Reglas ECA
realiza el procesamiento de todas las reglas asociadas con los eventos presentados en
el sistema. Cuando una regla es disparada, se ejecutan una serie de acciones
semánticas relacionadas can la evaluación de la condición, con la ejecución de la
acción y con el maneja de los errores.
El conjunto de acciones semánticas indicadas explícitamente por las reglas son
las siguientes:
LPevaEstadisticas: Realiza el registro de los datos estadísticos cuando se detecta
una consulta procesada en el sitio local. Los parámetros que maneja son el nombre
del archivo que contiene la consulta, el nombre del archivo que contiene el resultado
de la consulta y el nombre del archivo que contiene el nombre cliente que emitió la
consulta.
AvisaDBA: Presenta un aviso al administrador de la base de datos. El aviso
indica la información referente al evento detectado como son el nombre del evento,
la fecha y hora en que se presentó, y cuál fue el contexto en el que se presentó dicho
evento, es decir, cuál fue la condición que se cumplió.
RegistraQryEnRelevantes: Registra los datos estadísticos de explotación
correspondientes a determinada consulta que el administrador de la base de datos
considera relevante. Para ello el administrador especifica por medio de una Regla
ECA las condiciones que debe cumplir dicha consulta.
Ejecutalntegrador: lniegra los datos estadísticos de explotación de los distintos
sitios del sistema en un solo sitio, generando un archivo de datos que es la entrada al
51
I 'I I Capítulo 3 Lenguaje de Regias ECA ii !I
'I con los patrones de explotación identificados.
11 I
.!b
1 I Jli
II
I!'
t
I ParámetroTablas
ParámetroCoiumnas ParámetroWhere I/
11 Tabla 3-1 Nombres de los Parametros para Cada Evento ?I Valores Asignados II Evento
-___ .I
INCREMENTO-DE-FRECUENCl A
CONSULTA
ParámetroIdentificador ParámetroFrecuencia
Parámetrociiente ParámetroSelectividad
Parám'etrociiente /¡ ParámetroConsulta ParámetroSelectividad 4
I jl I I .I!
~~
!I 11. EVENTO representa el nombre del evento disparado. /I I
I
Lenguaje de Reglas ECA Capitulo 3
111.
IV.
V.
VI.
VI1
Acción se refiere a la acción indicada en la Regla que se procesa
Parámetros es una variable de tipo arreglo que almacena los datos requeridos
para la ejecución de la acción. Dichos datos se obtienen al momento de
detección del evento.
Reglaseñalada es una variable que indica si la regla seleccionada
corresponde al evento disparado.
ValorAITiempoDeEjecuciÓn se utiliza para evaluar la condición de la regla
disparada. Almacena el valor de uno de los parámetros en la detección del
evento que corresponde a la variable definida en la parte de la condición de la
regla.
Para implementar las acciones seinánticas se emplearon las siguientes
funciones:
1 . EvalúaCondiciónNumérica (ValorAITiempoDeEjecuciÓn~ Operador,
ValorEnLaRegla). Esta función realiza la evaluación de la parte de la
condición de la regla y se aplica a condiciones sobre valores numéricos.
2. EvalúaCondiciónTiempo (ValorAITiempoDeEjecuciÓn, Operador,
VaIorEnLaRegla). Esta función realiza la evaluación de la parte de la
condición de la regla y se aplica a condiciones sobre valores de tipo tiempo.
3. EvalúaCondición (ValorAlliempoDeEjecución, Operador,
VaIorEnLaRegla). Esta función realiza la evaluación de la parte de la
condición de la regla y se aplica a condiciones sobre valores de tipo
alfanuméricos.
4. EjecutaAcción (Acción, Parámetros). Esta función ejecuta la parte de la
Lenguaje de Reglas ECA I , Capítulo 3
5. LeeSiguienteRegla(.). Lee ' la siguiente!
Cuando esta función se ejecuta, se inicia cbn
semánticas.
i
acción de la regla disparada
Regla ECA de la base de reglas.
el procesamiento de lasiacciones I/ . .
VIII.
asignado a la variable Res. :ji
3.2.2.1 Regla ECA Función: Especifica las distintas Reglas ECA que se pueden definir a partir de los conjuntos de eventos, condiciones y acciones
Evento-IncrementoFreniencia Condición-Numérica Acción-Numérica
I Evento-Consulta True Acción-Consulta [ Evento-Tiempo Condición-Tiempo Acción-Tiempo
I Evento-AltaConsulta Condición-AitaConsulta Acción-AltaConsulta
I Evento-AltaEstadisticas Condición_"mérica Acción Numérica
3.2.2.2 Eventos Los siguientes símbolos gramaticales especifican el conjunto de eventos.
Evento-Consulta : := CONSULTA
Evento-Tiempo ::=TIEMPO
Evento-AltaConsulta : := ALTA-BASE-DE-CONSULTAS
Evento-AltaEstadísticas ::= ALTA-DATOS-ESTADISTICOS-DE,
ReglaSeñalada.va1 = 1 Sino ReglaSeñalada.va1 = O
Si (Evento- Consulta.val = EVENTO.val) entonces ReglaSeñalada.va1 = 1
Sino ReglaSeñalada.va1 = O
Si (Evento- Tiempo.val = EVENTO.vd) entonces RegiaSeñalada.val = 1
Sino ReglaSeñalada.va1 = O
Si (Evento- AltaConsulta.val = EVENTO.val) entonces ReglaSeñalada.va1 = 1
Sino Reglaseñalada val = O
Si (Evento- AltaEstadísticas.va1 = EVENTO.val) entonces
EXPLOTACION Sino ReglaSeñalada.va1 = O
3.2.2.3 Condiciones
ReglaSeñalada.va1 = 1
3.2.2.3. I Condición-Numérica Función: Especifica Condición de tipo numérica.
I TRUE
Res.va1 = EvalúaCondiciónNuméca (ValorAlTiempoDeEjecución.val , Op.val, Valor-Nurn.val)
Si (Res.val = 1) EjecutaAcción (Acción.val, Parhetros.val)
LeeSiguienteRegla( )
Condición.val ::= ‘‘ ” EjecutaAcción (Acción.va1, Parametros.val)
LeeSiguienteRegla( )
i2.2:3.> CondicGn-Tiempo Función: Especifica Condición de tipo tiempo.
Valor-Tiempo.val
Res.val = EvalÚaCondiciónTiempo (Op.val, Valor-Tiempo.val )
Si (Res.val = I) EjecutaAcción (Acción.val, Parámetros.val)
3.2.2.3.3 Condición-AltaConsulta Función: Especifica Condición de tipo alfanumérica.
Variable-Id Op Valor-Nun
I Variable-Tabla Op Tabla
I Variable-Columna Op Valor-Columna
I Variable-Where Op Valor-Where
I Variable-Cliente Op Valor-Alfanum
Res.val = EvalúaCondiciónNuméca (ValorAITiempoDeEjecuciÓn.val, Op.val, Valor-Tiempo.val )
Si (Res.val = 1) EjecutaAcción (Acción.val, Parámetros.val) LeeSiguienteRegla( )
Condición.val ::= Variable-Tabla.val1111"l1 Op.val I(LL ''11 Tabla.val Res.val = EvalúaCondición (ValorAlTiempoDeEjec¡Ón.val, Op.val, Tabla.val) Si (Res.val = I) EjecutaAcción (Acción.val, Parámetros.val) LeeSiyienteRegla( )
Condición.val ::= Variable-Columna.val lllj ''11 0p.val /y ''11 Valor-Columna.val Res.val = EvalúaCondición (ValorAiTiempoDeEjecución.val, Op.val,
Valor-Columna.val) Si (Res.val = I) EjecutaAcción (Acción.val, Parámetros.val) LeeSiguienteRegla( )
Condición.val ::= Variable-Where.val II<L ''11 Op.val11" "11 Valor-Where.val Res.val EvalúaCondición (ValorAlTiempoDeEjecución.val, Op.val,
Valor-Where.val )
Si (Res.val = 1) EjecutaAcción (Acción.val, Parámetros.val) LeeSiguieníeRegla( )
Condición.val ::= Variable-Cliente.val I/" "11 0p.val Res.val = EvalúaCondición (ValorAlTiempoDeEjecución.val, Op.val,
''11 Valor-Cliente.val
Valor-Cliente.val) Si (Res.val = I ) EjecutaAcción (Acción.val, Parámetros.val) LeeSiguienteRegia( )
I TRUE
3.2.2.4 Acciones Los siguientes símbolos gramaticales constituyen el conjunto de acciones.
Condición.val ::= “ ”
EjecutaAcción (Acción.val, Parámetros.val) LeeSiguienteRegla( )
Parámetros[O] : := ParámetroIdentificador Parámetros[ 11 ::= ParámetroFrecuencia P%áiiiSos[2] : := PaiámetToCiiente Parámetros[3] : := ParámetroSelectividad
- ~ ~- .. ... - - . . ._ ~~
- ~ ~ -
~
~ - __
I AVISA-DBA Acción.val ::= ‘AvisaDBA’ Parámetros[O] : := EVENTO.va1 Parámetros[ I ] ::= Condición.val Acción.val : := ‘EjecutaIntegrador’ Acción.val ::= ‘LlevaEstadisticas’
I EJECUTA-INTEGRADOR Acción-Consulta: := LLEVA-ESTADISTICAS
- .... .
Parámetros[Z] ::= ParámetroSelectividad
I AVISA-DBA
Acción-Tiempo::= AVISA-DBA
Acción.val ::= ' AvisaDBA' Parámetros[O] ::= EVENTO.va1 Parámetros[l] : := Condición.vai Acción.val ::= 'AvisaDBA' Parámetros[OJ ::= EVENTO.val
Parámetros[O] : := EVENTO.val Parámetros[ 11 ::= Condición.val
I EJECUTA-INTEGRADOR Acción-AltaConsulta: := AVISA-DBA
3.2.2.5 Variables -tos siguientes símbolos gramaticales constituyen el conjunto de variables. ~
- ~
-
Parámetros[ 1 1 ::= Condición.val
Acción-val ::= 'Ejecutaintegrador' Acción.va1 ::= 'AvisaDBA'
I.V... ,-. . . = ParámetroSelectividad.va1
Variable-Tabla ::= TABLA Variable-Columna ::= COLUMNA Variable-Where ::=WHERE Variable-Cliente ::= CLIENTE Variable-Identificador ::= IDENTEFICADOR
ValorAlTiernpoDeEjecución.val : := ParámetroTabla .val ValorAlTiempoDeEjecución.val : := ParámetroColumna.va1
ValorAlTiempoDeEjecución.val ::= ParámetroWhere.val ValorAlTiempoDeEjecución.val : := ParámetroCiiente.vai VaiorAlTiempoDeEjecución.va1 : := ParámetroIdentificador.va1
op ::= =
I < I’ , ’
10
I <=
I >=
. .
3.2.2.7 Elementos Comunes
0p.val ::= ‘=’
0p.val ::= ‘<’
0p.val ::= ‘>’
0p.val ::=‘o’
0p.val ::= ‘<=’ Op.val ::= ‘<=’
Si (Valor-Num.val < O) entonces ERROR(“Va1or invalido”)
Diaito ::= 1 1 Digito.val ::= ‘ I ’
I ... I
... ...
I Z I ietra-mayúscuia.vai ::= ‘z’
3.2.2.8 Val - Columna Función: Especificación de Valor-Columna
Tabla ::= Val-Aifanum
Columna : := Val-Alfanurn
Valor Columna.tipo ::= OhtenTipoColurnna(Va1-Colurnna.val) //usado en Valor-Where Tahla.val ::= Val- Aifanurn.val Si (Tabla.va1 no existe en el Diccionario de Datos) entonces
ERROR (“Tabla inválida”) Coiumna.val :: = Val- Aifanurn.val Si (Columna.val no existe en el Diccionario de Datos) entonces
ERROR (“Columna inválido”)
__ -3.2.2.9-Valor- m e r e - ~~
- Función: Especificación de V a l o r w h e r e
3.2.2.10 Valor - Tiempo Función: Especificación de Valor-Tiempo
Constante-Dia,Constante-Hora, )y,”)) Constante-Hora.va1 JI<L,”/I Constante-Minuto.va1 Constante-Minuto
Capítulo 4 I Implementación del Sistema de Reglas
Capítulo 4
IMPLEMENTACION DEL SISTEMA'DE REGLAS
. .
En este capítulo se presentan la implementación y la arquitectura de los módulos
necesarios para la definición y el procesamiento de las Reglas ECA definidas a
partir del Lenguaje de Definición de Reglas ECA presentado en el capítulo anterior.
El conjunto de dichos módulos constituye lo que llamaremos el Sistema de Reglas
(SR) del SABD, es decir, la parte activa del mismo..
I
. .
i
*
, . , ! 4.1 Diseño General del Sistema de Reglas
. ,
En la Figura 4-1 se presenta el diseño general del Sistema de Reglas
implemeniado. Éste está construido por un precompilador y un iniérprefe. Las
acciones semánticas definidas en el 'Capítulo 3 correspondientes al tiempo de
definición, son ejecutadas por'el módulo precompilador, y las correspondientes al
tiempo de procesamiento son ejecutadas por el módulo intérprete.
Figura 4-1 Diseño Genejal del Sistema de Reglar
Implementación del Sistema de Reglas ,i Capítulo 4 'i
I( 4.4 Precompilador , ri
./I I(
.I1
Un precompilador es un programa de software que recibe como entrada un
código fuente en determinado lenguaje y lo traduce a un lenguaje semánti'camente
equivalente [ASUSS]. La salida del precompilador es código de alto nivel. En la
Figura 4-2 se muestran las clases y métodos.im@ementados para soportar"1a tarea
del precompilador en este trabajo.
11
11
4.4.1 Interface01 . !I / j
Es el constructor de la clase InterfaceOl. En este constructor se &atiza la
definición de todos los componentes de 1a.interfaz gráfica. En la Figura 4-3 se :e
I, I
presenta el diseño de dicha interfaz. llr ,i *. I
~ . , . . "...
ReglasECADelinIdas' .
". ". .'k Opciones de Acciones
Figura 4-3 Componentes de la Inierfaz para la Defrnicidn de Reglas ECA 1
2. ,I!? /I - La interfaz está disefiada para permitir al ahministrador de la base de datos la
selección de la mayoría de los componentes de ida Regla ECA definida, esto se hace
mediante objetos de la clase Choice aplicados a la selección de Eventos, Variables,
Signos y Acciones. El único componente de la'regla que el ABD define es el valor
de la condición, es decir, el operando derecho de la misma. Esto lo hace mediante un
objeto TextField, que captura el valor definido,por el ABD. En un objeto de la clase
4 ./I
'I
I
Implementacibn del Sistema de Reglas I Capitulo 4 1
I
I
Lrst se muestran las Reglas ECA ya definidas y finalmente mediante ejemplos de la
clase bottom se presenta al ABD la opción de “Salir” de la interfaz, “Borrar” una
regla y “Aceptar” una regla definida
4.4.2 Clase Action
En esta clase se realiza toda la fase de análisis de las Reglas ECA definidas. A
continuación se muestran las clases implementadas y sus métodos respectivos.
4.4.2.1 Clase AccedeDD Esta clase contiene 10s métodos necesarios correspondientes a las acciones
semánticas, para la validación de valores en la parte de la condición de la regla que
hagan referencia a información del DD. Dicha información corresponde a clientes,
tablas, columnas y tipos de datos de las columnas. A continuación se presentan los
metodos que componen esta clase. Se indica la entrada y salida de cada uno de ellos.
4.4.2.1.1 Método ObtieneNodos
Entrada: Ninguna. Salida: Vector de nodos del sistema.
Obtiene un vector con el nombre de los nodos en el sistema, mediante el acceso al
archivo NODOS.BD1 del diccionario de datos, el cual mantiene la definición de los
nodos dados de alta en el sistema.
4.4.2.1.2 Método ObtieneRutas
Entrada: Vector de nodos del sistema. Salida: Vector de rutas correspondientes a los nodos.
Obtiene las rutas correspondientes a los nodos que constituyen el sistema, mediante
Capítulo 4 Implementación del Sistema de Reglas
'I 1
el acceso al archivo NODOS.BDI.
4.4.2.1.3 Método ObtieneAttsDeTabla
I
Entrada: Nombre de la tabla, ruta del nodo que
Salida: Vector de las columnas de la tabla.
Accede al DD para obtener las columnas de una tabla. JI !I I 4.4.2.1.4 Mitodo EvisteTabla
Entrada: Nombre de la tabla, vector de rutas de nodoh del sistema,
Salida: Ruta donde se encontró la tabla, en caso regresa null.
Busca una tabla en el diccionario de datos.
4.4.2.i.5 Mitodo Existe&
Entrada: Nombre de la tabla, nombre de la columna, ru\a del sitio de la tabla.
Salida: Tipo de dato de la columna, si la columna no exjste regresa -1.
',
'I!
'I li; Busca una columna determinada conociendo la rutdmque almacena la ,tabla allla
' Y t
Y1
que pertenece y obtiene el tipo de dato de dicha columna. I
4.4.2.2 Clase Utilerías 1 li 1 En esta clase se han definido una serie de métodoskpara la precompilación del I¡,
Lenguaje de Reglas ECA. Cabe mencionar que algunos métodos no participan en el I ,
proceso de precompilación, pero son necesarios para el funcionamiento de la
interfaz. A continuación se presenta cada uno de los métodos indicando la fase de ,J
.I\
¡I It
'4,
11
precompilación que ejecuta.
4.4.2.2.1 Mérodo MuestraRegIm
Entrada: Ninguna.
Capítulo 4 Implementación del Sistema de Reglas
Salida: Ninguna.
Método encargado de la actualización de la interfaz en cuanto al objeto List que
muestra las reglas definidas. Se ejecuta cada vez que se crea una Regla ECA.
4.4.2.2.2 Método AltaReglaECA
Entrada: Regla ECA. Salida: Ninguna.
Este método tiene la función de almacenar la Regla ECA definida correctamente
en una extensión al DD. Corresponde a la fase de generación de código del
precopilador. Cuando la variable elegida en la parte de la condición es Where, se
verifica que el predicado correspondiente se almacene bajo una forma canónica
basada en el ordenamiento alfabético de sus operandos. En los demás casos de
variables, la transformación consiste en convertir el valor de la condición a
mayúsculas cuando el tipo de dato de la variable es Alfanumérico. La Tabla 4-2
muestra ejemplos de transformaciones de condiciones a una forma canónica.
Tabla 4-2 Ejemplos de Condiciones
Condición Condición en Forma Canónica Tabla=sp Tabla = SP
Clienteecad 12 Cliente 0 CAD12 Where = p a r k 0 s.city Where = S.CITY 0 PARIS
4.4.2.2.3 Método BajaReglaEcA
Entrada: Regla ECA seleccionada por el ABD.
Salida: ninguna.
Realiza la eliminación de la regla seleccionada de la Base de Reglas en el
Diccionario de Datos.
69
Implementación del Sistema de Reglas ¡I Capítulo 4 /I II
Entrada: Valor tipo Where. !(I Salida: 1 si el predicado es correcto. En casolde indica. 1
,/l.
error regresa el mensaje que 10
I1
I verificando su validez.
'I i
1:
I/ ! '
validar la existencia de la columna y de la tabla. 1 1
! i '
Capítulo 4 Irnplementación del Sistema de Reglas
En la Tabla 4-3 se muestran dos ejemplos donde se pueden apreciar los errores
que el algoritmo verifica.
Tabla 4-3 Ejemplos de Cláumlm Where
Cláusula Válida Cláusula Inválida %City < ‘Paris’
P.Pno = 100 %City < 104
P.Pno = Londres
En ambos casos se asigna un valor cuyo tipo de dato es diferente al definido en el
diccionario de datos para la columna.
4.4.2.2.5 Método VuliduTiempo
Entrada: Valor tipo Tiempo. Salida: 1 si el valor es correcto. En caso de error regresa el mensaje que lo indica.
En el caso del valor Tiempo, se debe reconocer la secuencia de caracteres
mostrada en el autómata de la Figura 4-5. En dicha figura se muestra el análisis
basta la parte del mes, posteriormente se repite el análisis para la parte del día, hora
y minuto, es decir, cada uno está formado por dos dígitos, excepto el año.
La Figura 4-6, presenta el pseudocódigo requerido para la validación del valor
correspondiente a la variable Tiempo. Se consideran los rangos referentes a cada
componente de la variable, es decir, año, mes, día, hora, minuto.
... Figura 4-5 Automata para el Análisis Léxico del Valor Tiempo
71
Implementación del Sistema de Reglas
,. , . /I Si ((año >= 1800) y (año <= 9999)) entona
Si ((mes >= I) y (mes <= 12)) entonce I / Según el número de días de cada I irsi ((dia es permitido para mes)) ento
Si ((hora >=O) y (hora <= 23)) en Si ((minuto >= O) y (minuto
regresa verdadero; sino regresa falso;
sino regresa falso; sino regresa falso;
sino regresa falso; sino regresa falso; .
Figura 4-6 Pseud#códig#paru la Vu1
4.4.2.2.6 Método Validdtt
Entrada: Columna. Salida: El tipo de dato de la columna. En ca indica.
Éste método "terifica l a ' existencia en el
definida en la condición.
4.4.2.2.7 Método ValidaNumérico
Entrada: Valor tipo numérico. Salida: 1 si es correcto, O en caso de error.
.~
Verifica que el valor sea numérico, no ne
ejecuta cuando 'la variable seleccionada pa
Identificador, Frecuencia o Selectividad.
',I
4.4.2.2.8 Método Validdlfanumérico
Entrada: Valor tipo alfanumérico. Salida: 1 si es correcto, O en caso de error.
Verifica que el valor sea alfanuméric
Caoitulo 4
S ces 9)) entonces
cion del Valor Tiempo
.i iII . de error regresa el mensaje que lo
li ccionario d& datos de la columna
:,I
11 tivo o igual a cero. Estd método se
la definición de la condicibn es All1
Ill
,It
y se ejecuta cuando variable
Capítulo 4 Implementación del Sistema de Reglas
seleccionada es Tabla o Cliente.
4.4.2.3 CIase SimpIeDiaIogError
Entrada: Mensaje de Error. Salida: Ninguna.
En el precompilador, el manejo de los errores consiste básicamente en el envío
de mensajes al administrador, indicando el error en la definición de la Regla ECA,
principalmente en cuanto a tipos de datos.
4.4.3 Clase handleEvent
Esta clase presenta una función de salida que la clase Frame entiende.
Específicamente, maneja el evento de destrucción de la ventana de manera normal.
4.5 Intérprete
La siguiente es la definición de un intérprete: Herramienta de software que
ejecuta las operaciones indicadas por el código fuente recibido. Para el caso en
particular de este trabajo, mediante el intérprete del lenguaje de Reglas ECA se
llevan a cabo un conjunto de acciones semánticas cuya finalidad básica es el
procesamiento de las Reglas ECA. Dicho módulo es activado por los eventos
detectados cuando el sistema se encuentra en explotación. Este intérprete ejecuta las
acciones semánticas señaladas en las Regla ECA que procesa y no contiene en sus
etapas la generación de código, a diferencia de un precompilador. k
En términos de BDA, las etapas que componen el proceso de interpretación para
el lenguaje de Reglas ECA, han sido implementadas en este trabajo mediante un
módulo Procesador de Reglas ECA y otros módulos complementarios, los cuales son
necesarios para añadir al SABDD la capacidad activa.
I/ I/
1,
I! Implementación del Sistema de Reglas Capítulo 4
Enseguida se trata a detalle la referente a la betapa de
desarrollados para tal interpretación mediante una serie de
fin. En la Figura 4-7 se presenta la
la cual aparece la parte antes ir (Interfaz de Definición de Reglas ECA). !i
Modelo PURü I
............. ........................ ......
Sitios Remotos
Sistema Loca! 'I _ .......................................... Figuro 4-7 Arquit~chdra del Intérprete
¡)I Ir
4.5.1 Detector de Eventos ,j 1/1
Salida: Ninguna. II
Entrada: Identificador del evento presentado, argumentos necesarios para el procesamiento del evento. 11 !I
('1 11
, !ill '!
I
Este módulo detecta la activación de los' eqentos asociados con las Reglas ECA, y
I 74 ; !
~~
I . -,: ..._. . .
Capítulo 4 implementación del Sistema de Regias
señala al Procesador de Reglas la ocurrencia de los mismos. Cuando un evento de
interés es detectado por el sistema, la información necesaria para su procesamiento,
así como el identificador del evento, son enviados al Procesador de Reglas, para lo
cual, se analiza la información recibida en formato cadena, con la finalidad de
almacenarla en una estructura que facilite su manejo. El autómata de la Figura 4-8
muestra este proceso de reconocimiento de los parámetros correspondientes a cada
evento de interés. El número de argumentos varía con respecto al evento detectado.
1 O Evenio 1 @ 2 Arg, # ...
Figuru 4-8 Automara para el Reconocimiento de los Argumentos Referentes a un Evento Detectado
4.5.1.1 Eventos Detectables
Los eventos se detectan por medio de un proceso cliente que es un ejemplar dela
clase ClienteProcesador. Este cliente se comunica con un proceso servidor (clase
ServidorProcesador) que se encuentra en espera de la notificación de los eventos
ocurridos para iniciar el procesamiento de las Reglas ECA.
Se han implementado cinco eventos de interés, los cuales se muestran en la Tabla
4-4. También se presentan los argumentos respectivos a cada uno de ellos, indicando
el orden en que son reconocidos por el ServidorProcesador.
En el caso del evento Consulta, el módulo toma como entrada una consulta
definida originalmente en SQL. El resto de los eventos de interés es generado a
partir de éste, así, el evento Incremento de Frecuencia se presenta cuando una
consulta ya se ha procesado con anterioridad en el sitio.
1 5
Implementación del Sistema de Reglas Capitulo 4
I Tabla 4-4 Eventos y Argtrmenios
Evento Identificador - __.- AW 4 Arg4
c Archivo Cliente , Archivo !i
.I/
' Ir Incremento IF Identificador Nodo Selectividad Frecuencia , .
Consulta
Alta Base de AüDC ldentiíicador 1 Tabla Columna Where
Ilk Consultas I
1
Alta Datos ADEE Identificador Frecuencia Nodo ISelectividad Estadísticos de
Explotación ;I li
I¡
Tiempo T - 11 - - i'
Los eventos Alia de Datos Estadístico: de Explotación y Altalen Base de
Consultas, se presentan cuando no existe l,un registro previo sobre la consulta
detectada, por lo que se realiza el redistro de la información estadística
correspondiente a dicha consulta, así como de la definición de la misma (columnas,
!I I
!I i.
tablas involucradas y predicado). 1 I!
i, Otro evento útil, es el evento Tiempo, mediante el cual, el admikstrador de la
base de datos tiene la herramienta para poder tomar decisiones con base en el
cumplimiento, de una fecha determinada. Este evento puede servirle al administrador
para realizar la integración de la información estadística,de los distintos sitios del
sistema, con la finalidad de verificar si, en un momento dado en':el tiempo, los
patrones de explotación corresponden al esquema de distribución actual de los datos.
En todos los casos, la información que :;acompaña al nombre del evento, es la que
se tiene disponible al momento de la detección y es útil para el procksamiento de las
Reglas ECA, es decir, la evaluación de la condición y la ejecución de la acción.
I(
Ij !I l.
,I I1
:I 111
li. SI . .
I( !I
1111 I I
'1
I
1
Capitulo 4 Implernentación del Sistema de Regias
4.5.1.2 Integración con el SiMBaDD , <
El Sistema de Reglas fue implementado sobre un SABDD experimental
denominado SiMBaDD. En lo que se refiere al intérprete (procesamiento de Regias
ECA), dentro de las BDAs, el tipo de integración realizada se denomina construído-
en, lo cual implica que se tiene acceso al código del SABD y que éste puede ser
modificado con la finalidad de integrar la parte activa.
Una vez que se inicia el servidor de consultas del SiMBaDD, se ejecuta un
servidor denominado ServidorProcesador. Dicho servidor permanece en espera de
los eventos que se presentan en el sistema, con la finalidad de antenderlos mediante
el procesamiento de las Reglas ECA definidas.
Una segunda interacción entre el Módulo de Detección y Registro de Eventos y el
SiMBaDD, se realiza después de que el servidor de consultas del SABD ha
procesado exitosamente una consulta (ver Figura 4-9). Es entonces cuando se ejecuta
un proceso cliente que emite el señalamiento de la ocurrencia del evento consulta a
un módulo encargado del procesamiento de las Reglas ECA definidas en el sistema.
Sólo el evento consulta genera la comunicación entre el servidor de consultas del
SiMBaDD y el Módulo de Detección y Registro de Eventos Relevantes. El resto de
los eventos se generan a partir de la obtención de la información estadística sobre el
uso de los datos.
Ante el señalamiento del evento consulta, el proceso cliente que avisa de la
ocurrencia del evento es el encargado del envio de la información referente a la
consulta, dicha información hace referencia a la consulta presentada, a su
selectividad y al cliente emisor de la consulta.
77
11 , Capitulo4 Implementación del Sistema de Reglas
I1 Figura 4-9 Iníeracción entre el SiMBaDD y elM&lo de Detección y Regisho de Evenios Relevantes
II 'I I
,381 I 4.5.2 Procesador de Reglas ECA ¡I Nr
Entrada: Identificador del evento y argumentos necesarios para eI procesamiento del evento. Salida: Ninguna.
.I1 1
I*
/I Este módulo coordina la activación y procesamiento de las Reglas ECA asociadas It
con los eventos que las disparan, es deci;, selecciona las reglas relacionadas con el il evento dado en el sistema, evalúa la :I parte de la condicibn: de cada regla
4 1 1 I1
seleccionada, y cuando ésta se cumple manda ejecutar la acción correspondiente a la
regla procesada. /I# ocurrido, se genera un ejemplar del Cuando se recibe una señalización
I1 . módulo Procesador de Reglas de ECA mediante la clase ServidorProcesador. Dicho 11
ejemplar se ejecuta sobre un proceso hilo. La clase ServidorProcesador se encarga /I
Capítulo 4 Implementación del Sistema de Reglas
- Detecfor Proceso
del Evento ServidorProcesador
de generar los procesos hilos necesarios, es decir, uno por cada evento detectado. De
esta forma se atienden de manera concurrente los eventos detectados en un sitio (ver
Figura 4-10).
Evento Consulta,
Evento Tiempo
Evento Consultal
Atiende el Evento Consulta, . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .
Y Ejemplares del
Procewdor de Reglas ECA 1
Figura 4-1 O Generación de Procesos de Aiencidn a Eventos
En este sentido se presenta una ventaja, el proceso de selección de las reglas
relacionadas con el evento detectado, así como el procesamiento de las mismas, se
agiliza mediante la generación procesos ligeros que realizan la misma tarea de
manera concurrente. De otra forma, el procesamiento secuenciai de los eventos
detectados retrasaría el tiempo de atención a los mismos.
4.5.3 Módulo Transformador de Consultas a Forma Can6nica
Entrada: Consulta procesada. Salida: Consulta en Forma Canbnica.
La frecuencia con la que se presenta una consulta es un factor determinante para
efectuar el diseño de la distribución en el sistema. Esto se debe a que el costo de la
consulta, aunado a su frecuencia de procesamiento desde un mismo cliente,
79
Implementación del Sistema de Reglas 1 Capítulo 4
1
/I
permitirá determinar si.la reubicación es o no conveniente, es decir, aún &ando el
I' costo de procesamiento de una consulta sea elevado, 11
l. su frecuencia de procesamiento
/ será un factor que determine si los datos solicitados se reubican o no.
!J
I Por lo anterior, es necesario establecer la uni,cidad semántica entre consultas que
sintácticamente son distintas. A este respecto se,presenta un problema mayor, ya que
el análisis semántico de consultas tiene ya, por sí solo, su propia probllmática, la
cual está relacionada con la optimización de consultas.
'I ¡I
J i I1 I'
il 'I I
// !I /I ¡I
:I/ I "
'1
.,I
8 ;
El Módulo de Conversión de Consultas u Forma Canónica, es el encargado de
establecer la unicidad semántica entre las consultas procesadas. Los siguientes son
los aspectos considerados para este'efecto:
I El análisis se encuentra limitado a un subconjunto de la gramátiia del SQL.
Se determina la unicidad semántica entre consultas que involucran en la parte
del predicado algún operador de compa%ación.
I En la cláusula selecf se puede contar
I En la cláu;isula>iom se puede contar coti n tablas.
En el caso de la cláusula select, cuando en la definición de la conshta se utiliza
el operador *, en la forma canónica resultante se incluyen todas las columnas de la
tablaaccedida: ' ' ' .
11
I 'I 1:
n columnas o con el operador *.
(11 ?I
11 y; * 'I
iJ
~1 ii! I
'11 Ill
V i l
I
1' I
I i , Cuando se presentan varias columnas o iitablas en la 'cláusula select o from, se
emplea un algoritmo de ordenación léxica, para realizar el establecimiento de la (Y unicidad semántica entre consultas. ,Iii *
En la cláusula where también se emplea'iun algoritmo de ordenación Iéxica sobre
ambos operadores de la cláusula. En la Fgura 4-11 se muestra unmaejemplo de la . ,y . :If
c
Capitulo 4 Impiementación del Sistema de Reglas
forma canónica resultante para dos consultas con estas diferencias sintácticas
Forma Canónica para Consultal y Consulta2
Select SCity, SSname, S.Sno, S.status
Where Londres = S.City;
Figura 4-11 Ejemplo de Conversión de Consulías a Forma Canónica
Como se puede apreciar, en la cláusula where de la consulta, se ha aplicado la
ordenación léxica para los dos operandos del predicado.
4.5.4 Integrador
Entrada: Archivos necesarios para realizar la migración. Salida: Ninguna.
Es el encargado de reunir la información estadística de los distintos nodos del
sistema y de almacenarla localmente en el nodo en el que se disparó la regla cuya
acción genera la ejecución de este módulo.
Este módulo accede al diccionario de datos para obtener la información necesaria
sobre la configuración del sistema, es decir, sitios que componen el sistema, rutas de
acceso a dichos sitios, tablas que componen la base de datos, así como atributos de
cada tabla. Mediante el acceso al diccionario de datos se puede adaptar fácilmente
este proceso a cualquier configuración del sistema o a otra base de datos.
Además de migrar la información al sitio que procesó la regla, se realiza un
81
ii
/I Implementación del Sistema de Reglas I1 1Capítuio 4
It I/
1 por la implementación computacional del modelo
I
proceso de homogeneización de la información reunida. /I Este último paso se refiere a 11
I.
matemático que determinará el
4.5.5 Base de Reglas '!
En la Base de RegZas están almacenadas todas las TReglas ECA por medio de las
cuales, el administrador de la base de datos determina &l tratamiento que le desea, dar
a eventos de interés, asímismo, puede establecer el ,contexto dentro del cual se
considerará el evento detectado, es decir, la condición. La definición de las Reglas
!I
I1
! I!!
1 1
!I
'U . .
82
' -
_. - . ~ .. .._~_.. .
Capítulo 4 Implementación del Sistema de Reglas
ECA se realiza mediante el proceso de precompilación presentado en la Sección 4.3.
En la Tabla 4-5 se muestran algunos de ejemplos de Reglas ECA que se pueden
definir.
En la parte de la condición, se tiene la opción de definir una no-condición, es
decir, se tiene la opción de ejecutar determinada acción ante un evento, sin importar
su contexto. El operador True se utiliza para este fin y se puede emplear en la
definición de cualquier regla.
Tabla 4-5 Ejemplos de Reglas ECA
Evento Condición Acción
Consulta True LlevaEstadísticas incremento de Frecuencia Frecuencia > 500 RegistraEnRelevantes Tiempo Tiempo >= 99sep27 AvisaDBA
4.5.6 Base de Consultas
La Base de Consultas es una relación de las consultas que se han ejecutado por lo
menos una vez en el sistema local. Almacena la siguiente información referente a
una Consulta, como identificador Único, tablas y columnas involucradas, así como la
condición de la cláusula Where en su forma canónica.
I 4.5.7 Datos Estadísticos de Explotación
Esta información hace referencia a los patrones de explotación de los datos que
el modelo matemático requiere de entrada. Uno de los parámetros que se almacena
es el identificador único de la consulta detectada, con lo que se mantiene la relación
con la Base de Consultas. La información que se almacena se muestra en la Tabla I
I 4-6.
83
Implementación del Sistema de Reglas 'I ,Capítulo 4
11 I
Id
fk
N
s k
.,,' .'r Identificador de consulta relevante detectada al menos una vez
I1 Frecuencia de emisión de la consulta k
)I
'1
Nodo que originó la consulta k
Selegtividad promedio de la consulta'!
111 4
I
!
I l(1 ' II
4.5.8 Módulo Identificador de Consultas Básicas .. '11.
(I I
~ i li II II 41.
11
,I
Entrada: Consulta procesada. Salida: 1 si la consulta es aceptada, O en caso contrario.
!I
Este módulo &aliza un proceso de filtrado de consultas, ion la finalidad de
registrar sólo aquellas consultas que pueden ser reconocidas por el Convertidor de
Consulras a Forma Canónica. Recibe todas las consultas que se procesan en el 7 8 1
SABDD y realiza un análisis sobre ellas con 1 la finalidad de identificar las que
cumplan con el subconjunto de definiciones de la gramática del SQL conliderada en
este trabajo. ' /
1:
# i Se consideran aquellas consultas que tienen en la cláusula where un predicado
i;L con una sola comparación sobre alguna columnh. La ventaja de este enfoque se basa
111. ' . . & I , A en la estrategia de procesamiento del SABGD, la cual consiste en 'analizar la
consulta original y dividirla en subconsultas, siempre que sea posible, d l tal manera
que se generen consultas sencillas, como las ,que se identifican con este módulo.
Dichas subconsultas son procesadas independientemente en el sitio queicontiene la
información involucrada. Es por esta razón, que el hecho de que ¡a consulta original
II
fi I ( I ' '
' 4': ,,
I r 11 #I
1 1 I/ I
1 I .!I
I( 81
/I) 1,
sea tan compleja .I como se desee no representatmayor 4 problema para el propósito de
este trabajo.
Cabe mencionar que algunas definiciones de consultas originales nb se pueden
dividir en subconsultas. Esto Io determina la ,misma definición de la consulta, pero
84
se considera que son procesadas con menor frecuencia.
4.5.9 Interfaz de Consulta
También se ha integrado como parte de este prototipo una interfaz que permita al
administrador de la base de datos verificar los cambios en el registro de los Datos
Emdísticos de Explotación y, si el ABD lo especifica, las consultas relevantes ad
hoc.
t
i
Capítulo 5 Pniebas
Capítulo 5
PRUEB~AS
En este capítulo se presentan los resultados obtenidos con la aplicación de un
conjunto de pruebas al Sistema de Reglas implementado
. . 5.1 Objetivo de las Pruebas
I .. El objetivo del conjunto de pruebas que se presentan en las secciones sucesivas,
es demostrar que el Sistema de Reglas implementado cumple con los requerimientos,
esto es, que a partir del Lenguaje de Reglas ECA se ejecuta un conjunto de acciones
semánticas equivalentes.
5.2 Lista de Pruebas
Pruebas al Precompilador:
1. Altas y Bajas de Reglas ECA
2. Definición de Reglas ECA.
3. Asignación de valores a las variables en la parte de la condición.
Pruebas al Intérprete
4. Registro del cliente y la selectividad correctos, así como de la frecuencia inicial.
81
Pruebas
5 . Incremento adecuado de la frecuencia de 1
6 . Registro correcto en el caso de emisión clientes.
7. Control de concurrencia.
8. Establecimiento de la equivalencia semái sintácticas
9. Integración correcta de la información de
10. Correspondencia entre el archivo de matemático y la información estadística e
1, - ,, ,
5.3 Descripción del Ambiente de PI 2 . ' .,¡I
Las. pruebas fueron realizadas sobre una, rec
sistema operativo ,+Solaris 2.4. En la Figuri
distribución de las tablas a través del sistema.
, . ,
Siüo A
Figura 5-1 Esquema de Dishib* !'I, , A
88
capítulo 5
.esamiento. "I
la misma consulta por distintos '
I
11
!I . * , i entre consultas con diferencias
os los nodos.
tos obtenido para el modelo rada por el SABDD. ,;
I/ 1 1
'1 .
, . *. :, : [Ii;; I , . ' . P
3
-1,
'I 1, i :bas
.I
: estaciones ,de trabajo SUN con
-1 se muestra el esquema de . :
! i .,
. 1,
. .
del Sistema
Capitulo 5 Pruebas
El administrador de la base de datos es el encargado de ejecutar el servidor de
consultas del SiMüaDD en cada sitio que contenga al menos una tabla almacenada,
para que dicho sitio pueda fungir como servidor. También es necesario tener
instalada la versión 1.16 del JDK en cada sitio del sistema.
5.3.1 Esquema Relaciona1 de la Base de Datos de Prueba
Con la finalidad de comprobar el correcto funcionamiento del módulo
desarrollado, se utilizó la base de datos que aparece en [Dat95]. En la Figura 5-2 se
muestra el esquema relaciona] de dicha base de datos compuesta por las tablas de
Proveedores, Partes y Embarques.
SZ JAIMES 10 PARIS S3 BERNAL 30 PARIS S4 CORONA 20 LONDRES C5 ALDANA 30 ATENAS
P - :?W ;:PNOMBRE;'CüiOR .PESO ..,;ClWAO?,; ,.., :.:<.J.'.:. , I.. :,. ..,. . , , ; - L . ,..~.~.~~.., PI TUERCA RCl.0 12 LOhDRES P2 PERNO VERDE 17 PARIS P3 BIRLO AZUL 10 ROMA P4 BIRLO ROJO 14 LONDRES P5 LEVA AZUL 12 PARIS PB ENGFlANE ROJO 18 LONDRES
SP
$1 P2 m s1 P3 400 s1 P4 m s1 P5 1W S1 P6 1 O0 sz Pl 3w
52 I P2 400. 5 1 P 2 m s4 P2 m s4 P4 m s 4 P 5 400
Figum 5-2 Esquema Relacionalde la BD de Prueba
. . 5.3.2 Herramientas Auxiliares
Para la ejecución de pruebas en las que era necesario ejecutar una serie de
consultas desde distintos sitios, se implementó un programa en lenguaje C, el cual
realiza una serie de llamadas System, cada una realiza una petición de consulta a un
sitio determinado. En cada sitio' se ejecuta uno de estos programas con consultas
89
I
I diferentes y hacia diferentes clientes. "I
para verificar el resultado de la prueba. I ' , '. iI' 1
I
AI ejecutar el servidor aparece un
botón en pantalla con la leyenda "Visualizar Estadística" y otro con la
leyenda "Visualizar Consultas obtiene las consultas
registradas como consultas ,
I! correctamente sobre la Base de Reglas. ; '
'I Procedimiento: Se definió una Regla ECAfly
'1
1 ACEPTAR. La regla definida fue la siguiente:
_ . 5.4 Resultados.Obtenidos ,. . , ...
Enseguida se presentan las pruebas indicando el objetivo, el
I
después se presionó el botón
la interfaz, y se presionó el botón BORRAR.'. 1 , , ' I I
,I
Capítulo 5 Pruebas
Resultado: Satisfactorio. Se verificó que, aparte de que la regla apareciera en la
lista de reglas definidas de la interfaz de Edición de Reglas ECA, también existiera
en la Base de Reglas. Después de dar de alta la regla definida y de haberla
eliminado, se comprobó que no existiera en la Base de Reglas, tampoco aparece más
como una regla definida.
5.4.2 Prueba 2: Definición de Reglas ECA
Objetivo: Comprobar que las reglas definidas con base en el Lenguaje de Reglas
ECA sean reconocidas y almacenadas. 1
Procedimiento: Para realizar el proceso de validación se definió un conjunto de
reglas que fueran una muestra representativa de las que se pueden definir mediante
el Lenguaje de Reglas ECA.
Haciendo uso de la Interfaz de Edición de Reglas ECA se procedió a la definición
del conjunto representativo de reglas.
Resultado: Satisfactorio. Durante el proceso de selección de eventos, variables y
acciones, la interfaz guía al administrador en la selección de sólo componentes
válidos, por lo que sólo se aceptan Reglas ECA definidas correctamente. Eso se debe
a que, ante la selección de un evento, se hace disponible el conjunto de variables y
acciones permitidas para dicho evento, y el administrador sÓ10 puede seleccionar de
las opciones presentadas. La Tabla 5-1 muestra los resultados.
'I Pruebas . . 11 Capítulo 5
I . :.
!i Resultado
True LlevgEstadísticas Aceptada Consulta IncrementoFrecuencia Frecuencia > 1000 PasaQiy ARelevantes Aceptada
Aceptada AltaBaseDeConsultas Tabla = 'S'
1 Tabla 5-1 Reglas ECA Aceptadas y Almacenadas
Evento Condici6n , ,; 11 Acción
' , !I IF
'I) AvisaDBA 1
AltaDatosEstadísticos Cliente <> 'cadl2' AvisbBA DeExplotaciÓn 'i
: I ' Tiempo = 2000,01,01, .! Ejecutahtegrador Tiempo ., . 00,oo
IncrementoFrecuencia Selectividad > 200 .: AvisaDBA ,I
Aceptada
Aceptada ~
, >
Aceptada AltaBaseDeConsultas Where = S.sno = 'sl ' l AviSaDBA Aceptada
Aceptada IncrementoFrecuencia Identificador = 293 PasaQry ARelevantes 11
5.4.3 Prueba 3: Definición de la Condición de la Regla ECA' ,I I/ Objetivo: Comprobar que la definición de:la condición de las Reglas ECA se
II ,I I il
I ! i
encuentre validada.
I / / Las validaciones consideradas en esta prueba, se refieren a la parte de la
condición de las reglas, no importando el evento o acción involucrados, ya que
están validados desde la propia Interfaz de Edición @ Reglas ECA.
Procedimiento: Se definieron Reglas ECA.con las condiciones que aparecen en
la Tabla 5-2. Después de haber definido cada regla se presionó el botón "Aceptar"
para que el preprocesador iniciara las validaciones pertinentes en cada caso,
i1. I1
Capítulo 5 Pruebas
Tabla 5-2 Condiciones de Reglas Definidas y Resultado de la Valiaizción
Condición de la Regla ECA Resul tad0
Variable Tiempo
Tiempo
Tabla
Where
Identificador
Selectividad
Frecuencia
Cliente
Valor 1999,13,iZ,OO,OO
1999-12-03
‘Usuarios.BD1’
S.Sname >= 1000
Uno
-1
Asd
‘Cad156’
Error en la definición del valor Tiempo
Error en la definición del valor Tiempo. El Formato debe ser aaaa.mm.dd.hh.mm
La Tabla no existe en el DD
Error en la definición del valor Where. El Valor no corresponde
al tipo de dato de la columna Valor inválido
Valor inválido
Valor inválido
El Cliente no existe en el DD
Resultado: Satisfactorio. Una vez que se aceptó la Regla ECA definida, los
mensajes de manejo de errores se presentaron mediante una ventana de aviso
indicando el tipo de error. Ninguna regla fue aceptada. Los mensajes
correspondientes a cada definición aparecen también en la Tabla 5-2 y son
explicados a continuación para cada caso:
1. En este caso, la validación corresponde a la semántica del valor Tiempo. El
rango para el mes es de 1 a 12.
2. El formato utilizado para el valor del tiempo es incorrecto.
3. Cuando se definen condiciones sobre elementos del diccionario de datos, se
valida su existencia. En este caso, la condición de la Regla ECA se hizo sobre
una tabla que no forma parte del sistema.
4. En el caso de la variable Where, el administrador de la base de datos define
93
I 1
Frecuencia.
6 . La Selectividad, así como Identificador y
I 7. Es el mismo error que en el caso (5).
sistema.
Frecbencia no pueden ser negativos.
correctamente. 1' I I.
Capítulo 5 Pruebas
Tabla 5-3 Consultas de ia Prueba 4 '
id I Consulta Cliente Servidor Original Original
1 Select S.City, S.Sname Cad12 Cadi3 From S Where S.Ciiy = 'Paris';
2 Select SP. PNo, SP.Qiy Cad13 Cad 12 From SP Where SP. SNo = 'S2';
3 Select * From P;
Cad12 Cad14
4 Select P. Weight Cad13 Cad12 From P Where P.Pname = 'Tuerca';
5 Select P.Pname From P Where P.Color = 'Rojo';
Cad14 Cad13
Resultado: Satisfactorio. Luego de ejecutar repetidas veces el mismo conjunto
de consultas, los Datos Estadísticos de Explotación obtenidos en cada sitio son los
presentados en las Tablas 5-4, 5-5 y 5-6.
Tabla 5-4 Datos Estadísticos de Explofación en el sitio cadi2
Id Cliente Frecuencia Selectividad
1 Cad13 1 3 _-
Tabla 5-5 Datos Estadísticos de Explotación en el sitio cadI3
Id Cliente Frecuencia Selectividad
3 Cad14 1 3 4 Cad12 1 6 ' 5 Cad14 1 3
95
I/ Pruebas I Capítulo 5
! petición original.
Ij Tublu 5-6 Datos Estadísticos de Explotacion en el sitio cad14
~~ ~ ~~ ~
I ' " ' Ciiente Frecuencia! Selectividad - Id
2 Cad14 1 4 5 11
5.4.5 Prueba 5: Incremento de Frecuencia. 'I ;i
Objetivo: Verificar que la actualización he los Datos Estadísticos de
Exploiación se realiza de forma adecuada.
!I Procedimiento: Se ejecutaron las consultas de la Tabla 5-3 de manera repetitiva.
Resultado: Satisfactorio. Se verificó que a través de cada corrida el registro de la ' 1 I
selectividad se fuera'manteniendo en el promedio. ?I Respecto a la frecuencia, ésta se 11
'I incrementó en cada corrida sobre el registro 'de cada consulta y el cliente registrado
se mantuvo adecuadamente.
Capítulo 5 Pruebas
5.4.6 Prueba 6: Distintos Clientes
Objetivo: Comprobar que se genera un registro estadístico diferente para la
misma consulta desde distinto cliente.
Procedimiento: Se emitió la misma consulta (consulta 1 de la Tabla 5-3) desde
dos clientes hacia el servidor en cad12 con diferente frecuencia: 3 veces desde el
sitio cadi4 y 2 veces desde el sitio cadi3.
Resultado: Satisfactorio. El registro de los Datos Estadísticos de i%plolación en
el sitio cadi2 fue el siguiente:
Tabla 5-7Datos Estadisticos de Exploiaciónpara la Mima Constrlta I desde Disiinia Cliente
Id Cliente Frecuencia Selectividad
1 cad14 3 3 1 Cad13 2 3
. .
Como se muestra en la Tabla 5-7, se generó un registro para el cliente que emitió
la misma consulta. El promedio de selectividad se mantiene puesto que no hubo
actualizaciones a la Tabla S y el registro de la frecuencia fue correcto
5.4.7 Prueba 7: Control de Concurrencia
Objetivo: Comprobar que no existe colisión en el ServidorProcesador cuando
recibe múltiples señalamientos de eventos de manera simultánea, y que éstas son
atendidas en forma concurrente. La prueba se basó en los eventos implementados.
Procedimiento: Empleando el esquema de distribución de datos y sitios
presentado en la Figura 5-2, se emitieron consultas desde los tres sitios hacia el
servidor cadi2.
Resultado: Satisfactorio. Dado que el servidor de consultas en cad12 recibió las
97
Pruebas '1 Capitulo 5
~
" 1 también fueron atendidos de forma concurrente. I
El orden en que el servidorProcesador recibio los I
/señalamientos varió de corrida I '
, ,
Objetivo: Comprobar que se establece unicidad!'
II Procedimiento: Se emitieron dos consultas hacia el mismo servidor de consultas,
según lo siguiente:
semántica sobre las consultas
From s 1 Where s.sname = 'JIMENEZ'
2 Select * From S Where 'Jirnenez' = s.sname
I
'I 98
:'
Capítulo 5 Pruebas
incremento en la frecuencia de procesamiento. La forma canónica generada para la
consulta es la siguiente:
Select S.CITY, S.NAME, S.SNO, S.STATUS From S Where ‘JIMENEZ’ =
S.SNAME
5.4.9 Prueba 9: Integración de Datos Estadísticos y Obtención del Archivo de Datos para el Modelo Matemático
Objetivo: Comprobar que el proceso de integración de los datos estadísticos, así
como la generación de los archivos de datos, requeridos por el modelo matemático
FURD, se realiza correctamente. Se considera que la información estadística ya ha
sido migrada al sitio local.
Procedimiento: Esta prueba se realiza en un solo paso mediante la ejecución de la
acción Ejecutuintegrudor por medio de la definición de una regla ECA, la cuál se
puede definir sobre un evento de tiempo. Sin embargo, la prueba será dividida en
dos partes con la finalidad de analizar los resultados obtenidos, primero la parte de
integración de datos y después la obtención de los archivos de datos.
PARTE 1: En cuanto a la integración, al momento de disparo de la regla que
ejecuta la acción de integración, la información estadística en los distintos nodos es
la siguiente:
NODO cad12
332 S S.CITY S.SNAME PARIS = S.CITY 333 s S .CITY BERN= = S.NAME 334 s S.CITY S.SNAME LONDRES = S.CITY
332 cad14 1 2 333 cad13 2 2 333 cad14 2 2 334 cad12 3 6
99
Pruebas - 1 Capítulo 5
I/
J 180 cad13 5 2 18 1' cad14 5 2 ,)I
I '~
NODO cad14 I
1 SP 'SP.PNO .. i' S21;= SP. QTY I S1'= 2 SP
3. ' ~ S P ' .b..CP.PNO SP.QTY 2 Cl!
,I 1 . . cad14 7 .2 2 cad13 8 4 3 cad12 9 , 5 2 ~ ' cad12 8 4
'' ! !;I,
. .
#
II
SP.SNO SP.SN0
= SP.CNO
1 I. < . Datos Integrados
1 ' S ' 2 S 3 C 4 P 5 P 6 SP 7 CP 8 SP
S.CITY C.SNAME S.CITY S.CITY S.SNAME P.CITY P.WEIGHT
SP.QTY SP.PNO SP.QTY
SP . PNO t
PGIS = S.CITY BERNAL = C.NAME LONDRES = S.CITY PYIS = P.CITY 20 = P.WEIGHT C2 = SP.SON S1 = SP.SON S1' = SP.SN0
I I/
1 cad14 1 2 I1 2 cad13 2 2 2 cad14 2 2 3 cad12 3 6 4 cad13 5 2 5 cad14 5 2 6 cadí4 7 2 7 cad13 8 4 7 cad12 8 4
i 8 cad12 9 5 I
I
/I ' O 0 I I
Capítulo 5 Pruebas
PARTE 2: Respecto a la obtención del archivo de datos, se parte de la
información integrada en la primera parte de la prueba. Como se mencionó, la
misma acción realiza de manera sucesiva ambas partes.
Es importante mencionar que el formato de los archivos que el modelo
matemático recibe, contienen la información estadística sobre una tabla a la vez.
Resultado Parte 2: Satisfactorio. A continuación se presentan los archivos de datos
resultantes de la integración. En cuanto al formato de dichos archivos, se trata
básicamente de matrices. En cuanto al tipo de consultas, el valor asignado es el O en
todos los casos de las consultas registradas.
La matriz de uso de atributos tiene por columnas los atributos de la tabla
correspondiente en el orden en que son definidos en el diccionario de datos, los
renglones son las consultas procesadas. En cuanto a la matriz de frecuencias, las
columnas representan los sitios en el sistema y los renglones siguen siendo las
consultas. Finalmente, cada elemento en el vector de selectividades corresponde a
cada consulta registrada
Archivo de D a t o s para T a b l a P //Tipo de las consultas O o, o //Matriz de uso de atributos o, o, o, o, 1 o, o, o, 1, o //Matriz de frecuencias 0 , 5 , 0 O, O , 5 //Vector de Selectividades 2,2
Archivo de Datos para T a b l a SP //Tipo de las consultas o, o, o //Matriz de uso de atributos o, 1,1 0,1,0 o, o, 1 //Matriz de frecuencias 7 , o, o 888 , O 9, o, o //Vector de Selectividades 2,4,5
Archivo de D a t o s p a r a T a b l a S //Tipo de las consultas O o, o, 0 //Matriz de uso de atributos o, 1, o, 1 0,0,0,1 o, 1, o, 1 //Matriz de frecuencias o, o, 1 o, 2,2 3, O, O //Vector de Selectividades 2,2,6
Capítulo 6 Conclusiones
Capítulo 6
CONCLUSIONES
Este trabajo consiste en la automatización del proceso de captura de información
estadística requerida para el establecimiento de esquemas de distribución de los
datos en un sistema de bases de datos distribuidas. Dicha información representa
patrones de explotación de los datos a partir de las consultas relevantes en el
sistema.
A continuación se describen los resultados obtenidos a partir del desarrollo del
presente trabajo:
I Se muestra, cómo mediante el empleo de principios de Bases de Datos Activas, es factible determinar cuantitativamente patrones de frecuencia sobre el uso de los datos en un SABDD.
I Se presenta un enfoque innovador, Buses de Datos Activas, para la obtención
de Datos Estadísticos de Explotación, de manera automatizada.
I El prototipo desarrollado puede formar parte de un módulo en un SABDD, cuya función principal sea la ubicación de datos de forma optimizada, ante los cambios en los patrones de explotación.
I En este trabajo se exploró el problema de unicidad semántica de las consultas definidas en SQL. Como resultado se propone un método para la identificación de consultas equivalentes, basado en un subconjunto de la gramática del SQL.
103
Conclusiones I Capítulo 6
I Al incorporar este trabajo como parte de un sistema administrador de bases de datos experimental, se validó la factibilidadl de automatizar el proceso de
diseño adaptable de bases de datos distribuidas!
I Mediante un conjunto de pruebas se pudo comprobar la funcionalidad del
I I I
11 ,I
'I 1 las más importantes:
módulo implementado.
6.1 Trabajos Futuros
I1
i Procesador de Reglas ECA.
t
:
I
I
I
I I
I
restricciones o integridad de datos. ~ 11
'!
Incrementar el número de tipos de acciones.
6.2 Beneficios 1!
'I
41 Y
La obtención del objetivo fijado para esta tesis, es decir, la obtención de la I¡
104
Capítulo 6 Conclusiones
información estadística sobre el uso de los datos de manera automática, permite
contribuir a la automatización del proceso de diseño de la distribución de los datos.
De lo anterior se deriva el hecho de que la realización de este trabajo permitió
avanzar y obtener experiencia en el diseño automatizado de bases de datos
distribuidas.
Por otra parte, la utilización del lenguaje de programación Java para el desarrollo
de este trabajo, permite la integración del módulo sobre distintas plataformas
computacionales. Esto es aplicable dado que se cuenta con dos versiones del sistema
administrador utilizado (SiMBaDD), plataforma unix y Windows.
Finalmente, la integración de los principios de BDA, constituye la plataforma a
partir de la cual, se pueden soportar otras funciones propias del manejador,
aprovechando las ventajas de este enfoque. Una de dichas ventajas es que la
funcionalidad del módulo implementado se puede extender con facilidad, ya que las
extensiones se realizan de forma modular mediante la definición de Reglas ECA,
facilitando el mantenimiento del sistema.
105
Referencias
REFERENCIAS
[PPR98] Joaquín Pérez, Rodolfo A. Pazos, Guillermo Rodriguez O., Juan Fraustro S., Sandra Ramirez P. y F. Reyes S., “Un Modelo para la Fragmentación Vertical y Reubicación Dinámica de Bases de Datos Distribuidas”. VI Convención y Feria Internacional INFORMATICA ’98, La Habana, Cuba, 1998.
[Han911 Eric N. Hanson, “The Design and Implementation of the Ariel Active Database Rule System”, Technical Report UF-CIS-TR-92- 018, University of Florida, September 1992.
[CM93a] Stefan0 Ceri, Rainer Manthey, “Consolidated Specification of Chimera (CM and CL)”, Technical Report IDEA.DD2P.004, Politécnico di Milano, June 1993.
[Gat971 Stella Gatziu, “The SAMOS Active DBMS Prototype”, Switzerland, 6Ih Hellenic Conference in Informatics, Athens Greece, December 1997.
[Dat95] C. J. Date. An Introduction to Database Systems. Vol 1, 6‘h ed.; The Systems Programming Series; E.U.A.: Addison Wesley Publishing Company, 1995.
[HW93] Eric N. Hanson, Jennifer Widom, “An Overview of Produccion Rules in Databases Systems”, The Knowledge Engineering Revrew, Vol. 8 , No. 2, 1993.
[WC96] J. Widom, S. Ceri, Active Database Systems, la ed.; Sn. Francisco California: Morgan Kaufmann Publishers, inc., 1996)
~
Referencias
[PD99]
[SAP971
[SAD941
[SHP96]
[Cha92]
[PDW94]
[SJG90]
[FGD98]
Norman W. Paton, O. Díaz, ‘:Actiye !I Database Systems”, ÁCM Computing Surveys, Vol. 31, NÓ.l, 1999.
NI
M. Stonebraker, A Wide-Area International Conference on 1997.
I/
M.Stonbraker, “Mariposa: A New IEEE IOth International Conference on February 1994.
M. Stonebraker, E. Hanson and S. Potamianos, “The Postgres Rule
No. 7, 1996. Manager”, IEEE Transactions Engineering, Vol. 14,
S. Chakravarthy, Techniques for Active Databases: UF-CIS-TR- 92-041, University of Florida, 1992.
N. Paton, O. Díaz, M. H. et. al., “Dimensions of Active Behavior”, Is‘ on Rules in Database Systems, 1994.
M. Stonebraker, A. Goh, and S. Potaminos. “On Rules, Procedures, Views in Database Systems”, ACMSIGMOND International Conference of Data, May 1990.
,’; 4)
H. Fritschi, S. Gatziu, K. Dittrikh, “FRAMBOISE- an Approach to Framework-based Active Ibatabases Management System ~onstruction”, Proc. 7Ih Interdktionaí Conference on Information and Knowledge Managemen¡:’ (CIKM ‘98), Washington, D.C., November 1998. di
;i , I /
li
- ~
Referencias
[CM9 3 b]
[CKT94]
[DGG95]
[GGD95]
[Wid921
[Vé197]
tMR951
[CPW87]
S. Chakravarthy, D. Mishra, “Snoop: An Expressive Event Specification Language for Active Databases”, Technical Report UF-CIS-TR-93-007, Universidad de Florida, E.U.A., 1993.
S. Chakravarthy, V. Krishnaprasad, A. Tamizuddin, R. H. Badani, “ECA Rules Integration into an OODBMS: Architecture and Implementation”. Technical Report UF-CIS-TR-94-023, Universidad de Florida, E.U.A., 1994.
K. Dittrich, S. Gatziu, A. Gepert, “The ADBMS Manifesto: A Rulebase of ADBMS Features”, Proc. 2”d Workshop on Rules in Databases (RIDS), Athens, Greece, September 1995.
A. Geppert, S. Gatziu, K. R. Dittrich, “Rulebase Evolution in Active Object-Oriented Database Systems: Adapting the Past to Future Needs”. Technical Report 95.13, Universidad Zurich, 1995.
J. Widom, “The Starburst Rule System: Language Design, Implementation and Applications”, IEEE Boletín del Comité Técnico de Ingeniería de Dalos, Vol. 15 No.1-4, 1992.
Ana Vélez Chong, “Ubicación Optima de Datos en Aplicaciones de Bases de Datos Distribuidas”, Maestría en Ciencias en Ciencias Computacionales, Cuernavaca, Mor. Centro Nacional de Investigación y Desarrollo Tecnológico, 1997.
S. T. March, S. Rho. “Allocating Data and Operations on Nodes in Distributed Database Design”, Transactions on Knowledge and Dura Enginnering, Vol. 7, No. 2, 1995.
S. Ceri, B. Pernici, y G. Wiederhold. “Distributed Database Design Methodologies”, Proceeding IEEE, Vol. 75, No. 5, 1987.
109
Referencias ,‘I j
: [ASU88] ~ A. V. Aho, ~ R. Principles,
[NCW84] S . Navathe, S. J. Dou, “Vertical
Techniques and .Tools,
’ . Partitioning~ Algorithms for D a t a b l e Design’’, ACM Trans. On Database Systems, Vol. 9,. No.’ 4, 1984.
, :.
[POP971 Joaquín Pérez, Miguel Rodolfo A. Pazos, “Procesamiento en Paralelo de Consultas en SQL en Bases de Datos ‘Distribuidas”, Memorias de la Conferencia Internacional CIMAF:97, La Habana, Cuba. 1997.
. . . : ,; : . .
. ,: I I ,I I i
-
Apéndice A Estándares en BDA
Apéndice A
ESTANDARES EN BDA
En este apéndice se presentan los esfuerzos realizados por atacar uno de los
problemas importantes en los SABDA comerciales, que es la falta de
estandarización tanto en el aspecto de sintaxis como en lo referente a su semántica
de ejecución.
Algunos SABD comerciales soportan reglas de BDA, y hacen referencia a ellas
como disparadores. Su funcionalidad es muy limitada en comparación con los
prototipos de investigación desarrollados (Ver Capítulo 2), y sin embargo, es
suficiente para proveerles de un comportamiento activo relativamente complejo. Las
principales carencias de los SABDA comerciales respecto a los prototipos son las
siguientes:
1. Falta de estandarización en cuanto la sintaxis y a la semántica de ejecución de
los disparadores. Esto dificulta el uso de disparadores a través de distintos
SABDA comerciales.
2. Falta de una definición clara de la semántica de ejecución.
3. Falta de características avanzadas que los prototipos sí proporcionan (P.e.
eventos compuestos, eventos de aplicación específica).
4. Incorporan un número de restricciones (número de disparadores definidos).
111
Estándares en BDA Apéndice A
" I I Enseguida se presentan los avances obtenidos en la,'iestandarización respecto a los
disparadores por parte de IS0 y ANSI. Primeramente, cabe mencionar que los
disparadores no son integrados sino hasta el Último estándar SQL3, tomando como
base las restricciones de integridad del SQL-92. Así 'que en las siguientes secciones
se abordarán primero las restricciones de integridad en SQL-92 y después los
'i li 1
¡I
disparadores en SQL3. 1 I
I
A.l Restricciones de Integridad en eliEstándar SQL-92 i
1
La contribución más importante del estándar SQL-92 es la definición de una gran
cantidad de restricciones de integridad. Estas se,;clasifican en: restricciones sobre
tabla, de integridad referencia1 y aserciones genkrales. Se explica brevemente cada
tipo de restricción ya que son el marco de referenlia para los disparadores en SQL3.
y :I
'\
1 . Restricciones sobre Tabla: Permite establecer valores determinados sobre
los datos de una tabla mediante un CREATE TABLE. Incluye modificadores
como UNIQUE y NOT NULL para llaves primarias, así como la cláusula
CHECK, mediante la cual se especifica una condición que involucra una
columna cuyos valores son restringidos y la restricción es válida si la
condición resulta verdadera para cada tqpla de la tabla.
2. Restricciones de Integridad Refereneial: La definición de este tipo de
restricciones involucra dos tablas: una; tabla que hace referencia y una tabla
que es referenciada. La cláusula empleada es FOREIGN KEY en la sentencia
CREATE TABLE. En este caso, la restricción es violada por una tupla en la
tabla que hace referencia cuando las 'columnas de tupla representan un valor
que no aparece también en las columiias respectivas de la tabla referenciada
Un aspecto importante en este estándar, es que las actualizaciones y
'i ' Y / I1 11
1 I
:' I iI i . . I
i " fl
I 'I ir
1 12 !I . . !I - . . ~.
Apéndice A Estándares en BDA
eliminaciones sobre la tabla referenciada, son manejadas por medio de
“acciones de trigger referencia]”. La siguiente es su sintaxis: , I -
.I. *‘<foreign key action> ::= <event> <action> 8 ,
I <event> ::= ON UPDATE I ON DELETE .
’ <action> ::= CASCADE I SET DEFAULT I SET NCJLL 1 NO ACTION ., I . .
Como se puede observar, la definición anterior se ubica dentro del paradigma .: . .
evento-condición-acción de BDA. El evento es el que causa la violación de - .. . . ” . ’ .
integridad, la condición es la restricción misma y la acción es la encargada de
reparar la violación de la restricción.
Respecto a las acciones, CASCADE propaga la actualización o la eliminación
de las columnas de la tabla referenciada hacia las llaves foráneas o tuplas (en
el caso de eliminación),correspondientes ‘de todas las tablas que r e f e r d a h .
.. SET NüLL.pone a nulo el valor de las llaves foráneas.de las tuplas cuyo
valor sea menor que su correspondiente en la tabla referenciada. .SET
DEFAULT tiene la misma función que SET NULL, sólo que pone los valores
‘de las llave; foráneas su vaior p i r default. NO ACTION deshabiiita las
eliminaciones o actualizaciones hacia la tabla referenciada que causa la
violación de . integridad referencial.
+ I , ; f .
. ‘
I . -
0 ;
I , . . ! >i . , L
3. Aserciones: Permiten definir restricciones general& sobre múltiples I .
tablas. Su sintaxis es la siguiente:
<SQL92 assertion> ::= CREATE ASSERTION <constraint name> .. ,: ,
CHECK (<condition>) - < , _ .
[<constraint evaluation>] -
<constraint evaluation> ::= [NOT] DEFERRABLE ,
t I I
Características Activas del Módulo Implementado Apéndice B
'$ 11
semántica de ejecución: I/ 1 I,/ B
'; --I/ . Ya que se tiene ahora un panorama general con relación a las características de
otros prototipos de investigación, a continuac:ión se presentan las ventajas que
proporciona el Lenguaje de Reglas ECA implementado en esta tesis, así como su
.I/
,!,
I En cuanto a las fuentes que originan los e?/entos, el Sislemo de Reglas
implementado soporta operaciones sobre estructura (SELECT), tiempo absoluto I
' 'I
I .#., . y abstracto. . I
',< .í/ I En cuanto a la definición de la condiciónFse emplea el enfoque de opcional. En
todos lo SABDA relacionales se presentgla misma opción y sólo'en el caso de
los SABDA orientados a objetos se obliga a definir una condición. Nuestro
lenguaje tiene la flexibilidad de permitir al 'ABD definir reglas ECA con una condición True, es decir, no condición. " 11
a li I La política de ciclo empleada es de tipo recursivo, y la ventaja que presenta es
que las reglas asociadas a los eventos señalados son procesadas de forma
inmediata, es decir, una vez que se presenta el evento la regla es procesada.
I En cuanto a la planificación de varias reglaiECA disparadas al.mismo tiempo, el
modelo de ejecución del trabajo presentado,, implementa la ejecución en paralelo
de dichas reglas, a diferencia del procesamiento secuencia1 que se presenta en la
mayoría de los prototipos presentados en la Tabla B-l. En este aspecto se
aprovecharon las facilidades del lenguaje empleado en la implementación (Java),
ya que mediante la utilización del mecanismo de hilos cada regla es ejecutada de . #/I
manera paralela sobre procesos ligeros
Para la definición de las Reglas ECA en este trabajo, se emplea el lenguaje de
programación definido en el Capitulo 3.:Una ventaja del lenguaje es que permite
I. '1
I / .
/I ,I:
I
I 124
, ‘T‘
Apéndice A Estándares en BDA
I eliminaciones sobre la tabla referenciada, son manejadas por medio de
“acciones de trigger referencial”. La siguiente es su sintaxis:
<foreign key action> ::= <event> <action>
<event> ::= ON UPDATE I ON DELETE
<action> ::= CASCADE I SET DEFAULT I SET NULL I NO ACTION
Como se puede observar, la definición anterior se ubica dentro del paradigma
evento-condición-acción de BDA. El evento es el que causa la violación de
integridad, la condición es la restricción misma y la acción es la encargada de
reparar la violación de la restricción
Respecto a las acciones, CASCADE propaga la actualización o la eliminación
de las columnas de la tabla referenciada hacia las llaves foráneas o tuplas (en
el caso de eliminación) correspondientes de todas las tablas que referencían.
SET NULL pone a nulo el valor de las llaves foráneas de las tuplas cuyo
valor sea menor que su correspondiente en la tabla referenciada. SET
DEFAULT tiene la misma función que SET NULL, sólo que pone los valores
de las llaves foráieas a su valor por default. NO ACTION deshabilita las
eliminaciones o actualizaciones hacia la tabla referenciada que causa la
violación de integridad referencial.
3. Aserciones: Permiten definir restricciones generales sobre múltiples
tablas. Su sintaxis es la siguiente:
4 Q L 9 2 assertion> ::= CREATE ASSERTION <constraint name>
CHECK (<condition>)
I [<constraint evaluation>]
<constraint evaluation> ::= [NOT] DEFERRABLE ,
Estándares en BDA Apéndice A
1 evaluación diferida). ,111
t .; I
. . ,
1 ,
[INITIALL~ DEFERRED I 1: I\
1 1
!! .I¡
generales del SQL-92 son: +
INMEDIATE]
1 1 disparadores del mismo estándar y su sintaxis es:.
En este caso la aserción se satisface si '!a condición en la cláusula CHECK
resulta verdadera. La evaluación de la restricción es inmediata si se evalúa
después de cada sentencia SQL que puede violar la restricción, y es diferida si
la restricción se verifica hasta que la transacción ha efectuado el commit. A
diferencia de los tip& de restricciones 'anteriores, las aserciones permiten
I,i II, I
11. . It
diferir la evaluación de la restricción. Cuando la aserción es violada, se
de la restricción.
2. Introducción de la evaluación en el ámbito de tupla, es decir, la restricción se
evalúa para cada tupla modificada de la tabla dada, en lugar de para la tabla vi II
completa
1/ 1 114
Apéndice A Estándares en BDA
CHECK (<condition>)
[FOR [EACH ROW OF] <table name>]
<constraint evaluation>
<assertion event> ::= INSERT 1 DELETE I UPDATE [OF <colum names>]
ON <table name>
En SQL3 cada trigger reacciona ante operaciones específicas de modificación de
datos sobre tablas específicas. Los disparadores siguen el paradigma evento-
condición-acción de BDA, como se muestra en su sintaxis:
G Q L 3 trigger> ::= CREATE TRIGGER <trigger name>
BEFORE 1 AFTER I INSTEAD OF <trigger event>
ON <table name>
[ORDER corder value>]
[REFERENCING <references>]
WHEN (<condition>)
<SQL procedure statement>
FOR EACH ROW I STATEMENT j
i itrigger event> ::= INSERT 1 DELETE I UPDATE [OF <column name>]
<reference> ::= OLD AS <old value tuple name> I !
NEW AS <new value tuple name> 1 OLD-TABLE AS <old value table name> j
NEW - TABLE AS <new value table name>
I ,
En esta definición se puede observar que existe la posibilidad de definir el
tiempo de ejecución de un trigger, ya sea antes, después o en lugar de la operación
I 115 I
Estándares en BDA il Apéndice A
4 Para hacer referencia a los va1ores"de 10,s datos antes y después de la operación 4
. , Id
! d . . .
disparadora se emplean los valores old y new de la cláusula REFERENCING. '\
Además se cuenta con la cláusula ORDER, por medio de la cual se especifica el
orden en que se ejecutan dos o más disparadores que se disparan al mismo tiempo y
que están definidos sobre la misma tabla. Si 'no se especifica un orden, entonces la
secuencia de ejecución se basa en el tiempo de definición de los disparadores. 1
;i Finalmente, la definición de SQL3 para los disparadores, también proporciona
1: \I . ,
una sentencia para la eliminación de los disparidores:
! ~ '
5
<drop trigger> ::= DROP TRIGGER <trigger name> 1
Apéndice B Caractensticas Activas del M6dulo Implementado
Apéndice B
CARACTERISTICAS ACTIVAS DEL MODULO IMPLEMENTADO
En este Apéndice se presentan las propiedades que caracterizan a un SABDA.
Posteriormente se expone una comparación entre las características del Módulo de
Detección y Registro de Eventos Relevantes implementado y algunos prototipos, así
como con el estándar SQL3.
B.l Características
Las características de los SABDAs se agrupan bajo tres aspectos: El modelo de
conocimiento, el modelo de ejecución y la administración de las reglas. En las
siguientes secciones se presentan de manera general las características referentes a
cada aspecto.
B.l. l Modelo de Conocimiento
El modelo de conocimiento de un sistema activo abarca todo lo que se puede
decir acerca de las Reglas ECA. A continuación se presentan los atributos
correspondientes a cada parte de la regla.
Características Activas del Módulo Implementado I\ Apéndice B
B.1.I.I Evento
Fuente: Es la generadora del evento. Una fuente puede ser una operación sobre
las estructuras de la base de datos (insert, update, select), la invocación de un
comportarnienfo (operaciones indicada por el usuario), una transacción (por
~ '1
ejemplo: el señalamiento explícito
de un evento desde una excepción, de reloj
presentado es señalado por un suceso ? , .! .,
(un punto en el.tiempo), externa (el
externo al sistema).
Granuiaridad del Evento: Indica es definido sobre un conjunto, un ¡I i],
" \\, . miembro especifico o un subconjunto. Por ejemplo, un evento puede ser
detectado sólo cuando actúe sobre un svbconjunto de las tuplas de una relación.
Tipo: Los eventos pueden ser primitivosio compuestos. Los primitivos son
disparados por las fuentes antes presentadas, y los compuestos por
I 1 combinaciones de los primitivos. a
:I il Rol: Indica si el evento es obligatorio, opcion,al o si no se especrfica en la regla.
B.1.1.2 Condición :I
Rol: Indica si la condición es obligatoriaj opclonal o si no se especifica.
Contexto: Se refiere al estado de la base de' datos en el que la condición es
evaluada. Por ejemplo, al inicio de una'transacción o al .momento en que se
¡\
il d
presentó el evento
B.1.1.3 Acción
a
Opción: Se refiere al tipo de acciones que se implementar: invocación de
comportamiento, llamada externa, un administrador, aborto de
Apéndice B Características Activas del Módulo lmplementado
i
i I i I
i I i ~
I
transacción o una operación usando un comando hacer-en-lugar-de.
Contexto: Al igual que en la condición, se trata del estado en el que se encuentra
la base de datos al momento en que se ejecuta la acción.
B.1.2 Modelo de Ejecución
El modelo de ejecución se refiere a como son tratadas las regias al tiempo de
ejecución. Las siguientes son las características que corresponden a este aspecto.
Modo de Acoplamiento: Se refiere a los modos de acoplamiento entre el evento
y la condición, y entre la condición y la acción, es decir, en que momento se
evalúa la condición con respecto al evento, y en que momento se ejecuta la
acción con respecto a la condición. Los modos se determinan con respecto a la
transacción y pueden ser: inmediato (en la misma transacción de manera
inmediata), diferido (misma transacción, pero no de manera inmediata) o aislado
(en distinta transacción).
Granularidad de la Transición: Indica si la relación entre los eventos ocurridos
y las instancias de reglas disparadas es 1:l o muchos:l. Puede ser a nivel tuplu
cuando la ocurrencia de cada evento dispara una regla, o bien, a nivel conjunto
cuando un grupo de eventos dispara una sola regla.
Política de Efecto Neto: Indica si se considera el efecto neto de varias
ocurrencias de un mismo evento, o si cada ocurrencia se considera de manera
aislada. Por ejemplo, el efecto neto de varias actualizaciones sobre un mismo
dato es una actualización.
Política de Ciclo: Indica el tipo de algoritmo que se sigue cuando un evento es
señalado a partir de la evaluación de la condición o de la ejecución de la acción
119
j
Características Activas del Módulo Implementado 4 Apéndice B 1 'h de la regla. En un ciclo irerativo el ''procesamiento de la Condición o de la acción
nunca se suspende, es decir, los eventos disparados durante estas actividades son
atendidos hasta que dichas actividades I finalizan. En un ciclo recursivo los
eventos presentados provocan que dichas actividades sean suspendidas dando
lugar al procesamiento inmediato de las reglas correspondientes.
I . :~ J
1 1 . ¡I
I\ Prioridades: Cuando se disparan varias reglas al mismo tiempo, la elección de
cuál regla se ejecutará, se puede basarjen un criterio de prioridades. Las
prioridades pueden ser dinámicas (basadas en el tiempo de ocurrencia del
evento), numéricas (valores absolutos), relativas (con relación a la ejecución de
otras reglas), o bien, ninguna (no tiene impacto el orden de ejecución).
Calendarización: Especifica la for+ es que se procesan varias reglas
disparadas a la vez. Las opciones son: secuencralmente, en paralelo, algunas
reglas antes que cualquier otra o disparar sÓ1; algunas de todas reglas,
Manejo de Errores: La mayoría de los sistemas abortan la transacción ante la
'l. . \
i. ¡I
I ~ '1
11
'\
'I
presencia de errores al momento de ejecución. 1 ,Otros mecanismos son: ignorar la 1 l .
! ': 1s
regla que produce el error, deshacer las modificaciones, o manejar un mecanismo
de contingencia para la recuperación del error piesentado.
I' f B.1.3 Administración de las Reglas ' '1
Las características bajo este aspecto se refieren a las facilidades que proporciona
el sistema para el manejo de las reglas.
Descripción: Se refiere a la forma como son expresadas las Reglas ECA, es
decir, por medio de un lenguaje de programación, utilizando un lenguaje de
consultas o por medio de objetos. Estas categorías:no son exclusivas.
1 I\
Apéndice E Caractensti,cas Activas del Módulo Implementado
Operaciones: La operación obligatoria que se aplica a las reglas es la de
creación. Otras operaciones opcionales son: activación, desactivación (permite al
ABD inhabilitar el procesamiento de reglas, sin eliminarlas de la base de reglas)
y sefiaiamienio (se refiere a eventos externos señalados por la aplicación).
Adaptabilidad: Esta característica depende del procedimiento que se tiene que
seguir para que las reglas definidas puedan ser consideradas o reconocidas por el
sistema. La opción de compilación se utiliza cuando es necesaria la compilación
de la aplicación para el reconocimiento del comportamiento definido por medio
de las reglas. AI contrario de esta opción se tiene la denominada al tiempo de
corrida, bajo la cuál no es necesaria la compilación de la aplicación.
Modelo de Datos: Este es el modelo con el que el sistema activo es asociado y
puede ser: Relacional, Relacional Extendido, Deductivo u Orientado a Objetos.
B.2 Comparación con Algunos Prototipos
En la Tabla B-1 se muestran algunas de las características tanto de SABDAs
relacionales como orientados a objetos [PDW94]. Todos son prototipos de
investigación. Así mismo, se pueden observar las diferencias entre el ambiente
activo implementado en esta tesis con respecto a los SABDAs incluidos en la misma
I 1 I
i Tabla.
Cabe mencionar que algunos de los sistemas incluidos también aparecen en el
estudio del estado del arte realizado, el cuál aparece en el Capítulo 2.
I 121
Tabla E1 Tabla Comparativa sobre las Caracterislicas de Prototipos de Sisiemas Administradores de Bases de Datos Activas [PD99]
~ ~-
Apéndice B Características Activas del Módulo Implementado :\
5 . 1 Ya que se tiene ahora un panorama'. general con relación a las características de
otros prototipos de investigación, a continuación se presentan las ventajas que
proporciona el Lenguaje de Reglas ECA implementado en esta tesis, así como su
f I\ 1
" , \ \
¡\
1
semántica de ejecución: ,
I En cuanto a las fuentes que originan "los eventos, el Sistema de Reglas
implementado soporta operaciones sobre estructura (SELECT), tiempo absoluto
y abstracto.
En cuanto a la definición de la condicih;se, emplea el enfoque de opcional. En
todos lo SABDA relacionales se presenta lalimisma opción y sólo en el caso de
los SABDA orientados a objetos se obliga', a definir. una condición. Nuestro
lenguaje tiene la flexibilidad de .permitir al !ABD definir reglas ECA con una
condición True, es decir, no condición.
La política de ciclo empleada es de tipo recwsivo, y la ventaja que presenta es
que las reglas asociadas a los eventos señalados son procesadas de forma
inmediata, es decir, una vez que se presenta el evento la regla es procesada.
En cuanto a la planificación de varias regla ECA disparadas al mismo tiempo, el
modelo de ejecución del trabajo presentado,' implementa la ejecución en paralelo
de dichas reglas, a diferencia del procesamiento secuencia1 que se presenta en la
mayoría de los prototipos 'presentados en la Tabla B-l. En este aspecto se
aprovecharon las facilidades del lenguaje empleado en la implementación (Java),
\ , .
I ~ \\
1 1
I 21 1.
" 1 \I i1 11 I1
! \ I
ya que mediante la utilización del mecanismo cada regla es ejecutada de
manera paralela sobre procesos ligeros.
l. I Para la definición de las Reglas ECA en este trabajo, se emplea el lenguaje de
programación definido en el Capítulo 3 . Una lenguaje es que permite
Apéndice B Caractensticas Activas del Módulo implementado
añadir eventos o acciones definidas como métodos. De esta manera se pueden
incluir componentes para la definición de las reglas con la sola restricción de que
dichos componentes sean un método que pueda ser llamado.
I Respecto a las herramientas proporcionadas por el trabajo realizado, para la
administración de las Reglas ECA, se cuenta con una interfaz gráfica que permite
visualizar las reglas definidas al momento. El resto de los sistemas relacionales
de la tabla no presentan ninguna facilidad.
B.3 Comparación con los Disparadores de Estándar SQL3
En esta sección sólo se mencionarán las diferencias entre el lenguaje de
definición de reglas ECA implementado y los disparadores. Para ver la definición
formal de los disparadores, del estándar más reciente a la fecha, consultar el
Apéndice A.
En la Tabla B-2 aparece la relación de las características correspondientes al
comportamiento activo del SQL3 y el módulo activo implementado.
Una ventaja importante se presenta en cuanto a la fuente del evento. La
definición del SQL3 sólo detecta como eventos las operaciones de actualización
sobre la base de datos (UPDATE, DELETE e INSERT), en cambio el lenguaje
definido en este trabajo soporta una mayor gama de eventos: Recuperación de datos,
eventos de tiempo y actualización de datos (estadísticas).
~
! I
Debido a que se emplea un lenguaje de programación para la definición de las
reglas ECA y no una extensión al lenguaje de consultas SQL, es posible integrar
como acciones definidas métodos de programación. Con esto se puede definir una
amplia gama de acciones.
I 125 1
Características Activas del Módulo Implementado '1 Apéndice B
\I . Tabla B-2 Tabla Comparativa del Lenguaje de Reglas ECA y Disparadores'
c ~ I\
1 iI 'I
La planificación de las Reglas ECA disparadas a la vez, en el caso de este
trabajo, se realiza de forma paralela. El ..estándar SQL3 utiliza el tipo de
planificación secuencia] que presenta desventajas obvias. Por ejemplo, si se
considera que la acción de una regla involucra uno o más procesos extensos, el
procesamiento de las regias sucesivas se podría ver afectado '> 11:
d La información contenida en esta tabla, referente al SQL3, ha sido extraída de VD991 9
I/
Apéndice B Características Activas del Módulo Implementado
Finalmente, en este trabajo se proporciona una herramienta gráfica que le permite
al ABD la consulta de las reglas ECA definidas en el sistema.
Como se puede apreciar en la Tabla B-2. el estándar SQL3 cuenta en su
definición con muchas características que los prototipos de investigación han
implementado como parte de su comportamiento activo. Sin embargo, los SABDA
comerciales que se basan en el mecanismo de disparadores han implementado sólo
algunas capacidades de las definidas en el estándar SQL3.
Apéndice C Publicaciones Recomendadas
Apéndice C
PUBLICACIONES RECOMENDADAS
Es este apéndice se presenta una relación de las publicaciones más relevantes en
el área de las bases de datos activas. También se da una breve explicación del
contenido de cada referencia.
I S. Ceri, R. Manthey, “Consolidated Specijication of Chimera (CM and CL) ”,
Reporte Técnico IDEA.DD2P. 004, Politécnico di Milano, Italy. Junio I993
Este reporte técnico contiene la especificación del lenguaje conceptual
Chimera, perteneciente al proyecto IDEA, es decir, especificación de valores,
objetos, restricciones, vistas, disparadores, reglas pasivas, reglas activas,
consultas, actualizaciones, transacciones, así como la gramática completa del
lenguaje.
I Norman W. Paton, O. Díaz, “Active Database Systems”. ACM Computing
Surveys, Vol. 31, Ntím. I , Marzo 1999
Este artículo presenta un enfoque muy completo sobre las BDAs. Incluye la
descripción de las características fundamentales de los sistemas activos, un
panorama general de varios SABDAs, algunos aspectos referentes a la
arquitectura y finalmente avances actuales en el desarrollo de herramientas
129
Publicaciones Recomendadas Apéndice C
1 il útiles para el diseño de aplicaciones activas.
U. Jaeger, J. C. Freytag, “Annotate,d Bibliograpiy on, Active Databases”,
Alemania 1996
Representa un concentrado de laibiblibgrafía disponible sobre bases de datos
activas y SABDAs
li 1
‘ I ; .. i “i\ ’ ~
M. Stonebraker, “The Integration of Rule Systems and Database Systems”,
IEEE Transactions on Knowledge and Data Engineering, 4(5):415-423,
Octubre 1992
En este artícu1o’:se abordan los aspectos de integración de un sistema de
reglas y un sistema de bases de datos.
K. Dittrich, S. ‘Gatziu, A. Gepert, “The ADBMS Manifesto: A Rulebase of
ADBMS Features”. University of Zurich, Proc. 2nd Workshop on Rules in
Databases (RIDS)), Atenas, Grecia, Septiembre 1995
La funcionalidad que un SABD debe soportar para ser considerado activo, así
como aquellas características’ deseables son aspecto presentados ‘en este
artículo.
S. Gatziu, “The SAMOS Active DBMS Prototype ”, Departament of Computer
Science, Universidad de Zurich, ’ Suiza, 6th Hellenic Conference in
informatics, Atenas Grecia, Diciembie 29917
I 1
” 1, 1
’: \
1 I1
4 ’I 9
‘1 i r
‘I. il.
El artículo presenta una’ descripción acerca del prototipo SAMOS de
la Universidad de Zurich.
J. Widom, S. Ceri, ‘Yctive Systems”, Morgan Kaufmann
Apéndice C Publicaciones Recomendadas
Publishers, inc., Sn. Francisco California 1996, ISBN 1-55860-304-2
Este libro es un compendio amplio acerca de los sistemas de bases de datos
activas. Se presentan todos los aspectos relacionados al diseño y la
implementación de los SABDAs. También se abordan de manera general
tanto los prototipos de investigación como SABDs comerciales que soportan
mecanismos de disparadores. Otro aspecto importante que se incluye en este
libro es la parte referente a las aplicaciones soportadas por los sistemas de
este tipo.
I S. Ceri, P. Fraternali, “Designing Database Applications with Objects and
Rules”, Addison- Wesley, ISBN 0-201-40369 2, 1997
Este libro trata de la metodología IDEA, la cual abarca componentes para
análisis, diseño, prototipo e implementación en sistemas de bases de datos.
Una parte importante de esta metodología es Chimera, un lenguaje conceptual
para la definición del modelo dinámico, es decir, de reglas activas.
I C. Bauzer Medeiros, M. J. Andrade, “Implementing Integrity Control in
Active Data Bases”, Journal Systems Sofmare, Campinas, Brazil, 1994
Se presenta una metodología para convertir restricciones sobre la base de
datos en reglas de producción, bajo el enfoque de bases de datos activas.
I K. R. Dittrich, A. M. Kotz, J. A. Mulle, ‘An EveniiTrigger Mechanism to
Enforce Complex Consistency Constraints in Design Databases”, SIGMOND
RECORD Vol. 15. No. 3, Septiembre 1986
El artículo contiene los aspectos de implementación de un mecanismo basado
en disparadores para controlar las restricciones en el diseño de bases de datos.