Un modelo para Bases de Datos Temporales basado en secuencias



Descargar 90,63 Kb.
Fecha de conversión24.09.2017
Tamaño90,63 Kb.
Un modelo para Bases de Datos Temporales basado en secuencias
Alejandro Vaisman - Mauricio Minuto Espil

Grupo de Investigación en Bases de Datos

Departamento de Computación

Universidad de Buenos Aires

Director del GIBD : Lic. Juan Ale

e-mail : av2n@dc.uba.ar



Resumen

Las Bases de Datos Temporales,por su estructura,se

prestan para ser tratadas como un conjunto de

secuencias. Esto permite mejorar su performance y

su capacidad expresiva. Presentaremos un modelo

de secuencias a implementar sobre un Sistema

Temporal desarrollado por el GIBD.

Palabras clave: Bases de Datos , Relacionales ,

Temporales ,Secuencias.

1.-Introducción
El GIBD ha trabajado en el desarrollo de un Sistema de Bases de Datos Históricas basado en el modelo presentado por N.L.Sarda[Sa93], al que se le han introducido algunas modificaciones con el propósito de representar a la Base de Datos como un conjunto de secuencias. El uso de secuencias facilita tanto la optimización de las consultas como el planteo de las mismas.Consultas que son difíciles de realizar ( o no realizables) en la extensión temporal al SQL , que llamamos HSQL,serán fácilmente expresadas y resueltas en el lenguaje que aquí proponemos.
Supongamos tener una Base de Datos de empleados de una empresa,

donde se lleva un registro de la carrera de cada uno de ellos. Cada empleado tendrá una historia , que es una secuencia ordenada

temporalmente.Consultas como las siguientes no podrían plantearse en HSQL(o serían totalmente ineficientes) :
"Listar el sueldo que tenía "X" antes de 3 modificaciones"

"Listar aquellas personas cuyo tercer aumento de sueldo fue mayor que

un 10% ".
Presentaremos aquí un modelo que permitirá resolver consultas de este tipo en una manera declarativa y eficiente, agregando al HSQL operadores propios de secuencias. Así , consideraremos al HSQL como compuesto por 3 sublenguajes:
- El SQL standard, que se aplica a tablas no temporales(Snapshots)

- El HSQL con operadores temporales que no involucran secuencias .

Veremos no obstante que algunos operadores se verán beneficiados al

considerar la organización secuencial de los datos para el procesamiento

de las consultas.

- El SHSQL, que permite operar sobre secuencias, que en nuestro caso

serán las historias de cada tupla , y que devuelven sets, bags u otras

secuencias.


El empleo de secuencias para el procesamiento de consultas es propuesto en [SLR94], donde se esboza un modelo de secuencias general y sus posibles aplicaciones. También en [SS93] se plantea un modelo temporal basado en secuencias, aunque sin aplicarlo a ningún modelo de Bases de Datos preexistente. En este caso , creemos que plantear un modelo secuencial en abstracto , si bien importante como idea , ignora los inconvenientes que presenta la implementación de un Sistema de Bases de Datos Temporales,con lo cual el modelo teórico poco tiene que ver con dicha implementación .Un caso típico es que los modelos teóricos

planteados consideran la existencia de un valor NULL cuando un elemento de una secuencia no está definido , hecho que obviamente facilita el tratamiento de los operadores, pero que deberá ser considerado en una etapa posterior.


Para nuestro planteo nos basaremos en el modelo temporal descripto en [MV94],que como ya dijimos es una variante del modelo original de Sarda.

2.-El Modelo
En nuestro modelo, cada tabla de la Base de Datos se compone de dos partes : Una denominada CURRENT , en la cual se almacenan las tuplas actuales,y otra llamada HISTORY, que mantiene la historia de cada tupla. Formalmente,esto es equivalente a considerar a ambas relaciones como subconjuntos de una relación histórica R. La división en dos tablas permitirá en la etapa de procesamiento de las consultas mejorar la performance,ya que en general aquellas hacen referencia a los valores actuales de las relaciones, por lo que sería poco eficiente manejar toda la historia cuando solo se requiere trabajar con una porción de la relación.

En la figura 1 se representa lo antedicho.



Como vemos,cada tupla tiene un campo adicional, que consiste en una

referencia a la tupla que representa el estado anterior del objeto en orden cronológico.
En adelante , excepto cuando se indique expresamente lo contrario ,

denominaremos indistintamente tupla u objeto a un elemento de una

secuencia , independientemente del significado de la palabra "objeto" en otro contexto.
Observemos que el primer elemento de la secuencia es el que representa

el estado más reciente del objeto. Esto facilitará la implementación sin pérdida de generalidad. Nótese también que la Relación Histórica R puede ser percibida como un conjunto de secuencias (que son las historias de cada objeto).


El modelo así planteado presenta 2 características importantes :
a. Podemos mantener la historia de un objeto que ha sido borrado

de la Base de Datos y vuelto a insertar. Para esto creamos la

función REINSERT, que definimos más adelante.
b. También podemos mantener la historia de un objeto en caso de

haber sufrido éste una modificación en una componente de una

clave compuesta.

2.1.-Definiciones
Denominamos secuencia a un mapeo de un subconjunto finito de los

primeros números naturales consecutivos , en tuplas de una relación histórica.


Llamamos Longitud de una secuencia al último número natural que posee imagen en alguna tupla dentro de dicha secuencia.
Llamamos historia de una tupla t ,denotada hist(t), a una secuencia cuya posición 1 es la tupla en cuestión , y dados i y j, posiciones dentro de la secuencia ==>Para todo i>j ti[TO] < tj[FROM], donde FROM y TO son los timestamps de la tupla ([Sa93]) .
hist(t) = {Sn/ Sn(1) = t & Sn(i) = ref (Sn(i-1)) , 2 <= i <= n }
donde ref(t) es una función que va de tuplas a tuplas cuyo perfil es

ref : r --> r .


Además, sea j = i + 1 ==> No existe tk / tj[TO]<= tk[t]<= ti[FROM] donde t es un instante comprendido entre tj[TO] y ti[FROM].Esto es , la secuencia está ordenada cronológicamente. Si entre tj[TO] y ti[FROM] existe una discontinuidad temporal ( medida según la granularidad de la relación) , podríamos considerar que existe en ese intervalo la tupla nula .Esto facilitaría la definición de los operadores(ver sección 3),aunque nos alejaría de nuestro objetivo, que es plantear formalmente operadores que puedan ser implementados en la forma más directa posible a partir del modelo.
Asumiremos en lo sucesivo que cuando hablemos de secuencias , en

realidad nos estaremos refiriendo a historias.


2.2.-Definición de Datos
Es importante definir los operadores que permitirán mantener la Base de Datos en un estado consistente con las definiciones dadas anteriormente.
Estos operadores son los siguientes:
2.2.1.- UPDATE
Una actualización en una Base de Datos Histórica se puede realizar sobre aquellos registros cuyo atributo TO sea igual a NOW ( o en forma teórica ). Es decir aquellos que se encuentren en la sub - relación CURRENT).
Definimos al operador de actualización como UPD(r,tc,vc,tn,vn) ,

donde r = relación a actualizar

tc = tupla a actualizar

vc = valor actual a modificar

tn = tupla a insertar

vn = valor que reemplaza a vc


La operación UPD implica agregar a la relación r una tupla tn , en la cual tn[FROM] = tp y tn[TO] =  ,y vn en los atributos no temporales o visibles. Además,se reemplaza el valor tc[TO]= NOW por el valor inmediatamente anterior a tp según la granularidad de la Relación , es decir tp-1. tp es el tiempo presente,representado por el que marca el reloj del sistema.

La historia de la nueva tupla será


hist(tn) = tn . hist(tc)
donde el operador "." es la concatenación de una tupla con una secuencia, definida así :
Dada la secuencia Sn y un elemento t , definimos S = t . Sn , a una

secuencia S, de n+1 elementos tal que S(1) = t ,y S(i) = Sn(i-1) para todo i, tal que 2 <= i <= n+1.


Una vez insertada,tn referencia a tc por la función ref(tn) = tc
2.2.2.- INSERT
Cuando insertamos una tupla en una Base de Datos Histórica , lo

hacemos para incorporar un objeto que no tiene historia , por lo que la operación INS(t) implica


r := r U t donde := es la asignación de relaciones
t[FROM] = tp t[TO] = ý
hist(t) = t
ref(t) = nil
2.2.3.- DELETE
Denotada DEL(t),consiste en pasar una tupla de la sub-relación CURRENT a la HISTORY,pero la historia de t no sufre modificación alguna.Por lo tanto
hist(t)[1] = t ; t[TO] = tp
2.2.4.- REINSERT
Denotado REINS(t), es el operador que incorporamos a efectos de "revivir"

a un objeto, es decir,volver a incorporar a un objeto que en algún momento sufrió un DEL. Este es un caso muy común en la práctica , como por ejemplo un empleado que renunció y se vuelve a incorporar a la empresa con un nuevo número de legajo. Sin este operador,su historia se "pierde", con lo cual el sistema se haría mas dependiente de los datos.


Se aplica este operador , a secuencias que no son subsecuencias de

ninguna otra,es decir a aquellas secuencias S tales que hist(S(1)) no forme parte de ninguna historia de alguna otra tupla, y que S(1)[TO] ! = NOW .

La operación se define como
r := r U t
t[FROM] = tp ; t[TO] = ý
hist(t) = t. hist(t1) donde t1 es el S(1) antes mencionado.
ref(t) = t(1)
3.-Operadores Simples
Vamos a definir una serie de operadores que se aplican a Conjuntos de Secuencias o bien a secuencias individuales. Nuestra intención no es reemplazar a los operadore s del HSQL sino incorporar otros que hagan más declarativas y sencillas las consultas sobre la Base de Datos, hecho que ocurre para un determinado tipo de consultas.
Vamos a plantear una definición formal para cada operador, pero tratando que su traducción a un lenguaje tipo HSQL sea lo más directa posible. Además,cuanto más directa sea esta traducción, más eficiente será la implementación. También definiremos consultas para ejemplificar el uso de los operadores.Estos ejemplos,salvo cuando se aclare lo contrario, se realizarán sobre una relación histórica de tipo STATE, que representa la historia de las posiciones y sueldos de los empleados de una compañía :
EMP ( E# , NOMBRE , DPTO , SUELDO ,FROM , TO )
Cabe destacar que los atributos FROM y TO no deben ser definidos por el usuario.
3.1. Historia de una tupla.
Definimos hist(t),siendo t una tupla que pertenece a una secuencia S de longitud n ,a una operación que devuelve la historia de la tupla t , si t es distinto de NULL, ó la Secuencia nula, denotada Snull,en caso contrario.
Es necesario mencionar que nosotros no admitimos la tupla NULL como simplificación , pese a lo cual es necesario definirla, ya que se podría presentar como argumento de hist. Por ejemplo , si t surge de una selección,puede ocurrir que ninguna tupla satisfaga el correspondiente predicado . Si no definiéramos la tupla NULL, y el resultado de hist(NULL) se generaría una inconsistencia del lenguaje.
3.2. Historia de un conjunto de tuplas

SET_HIS ( T ) ,donde T es un conjunto de tuplas que cumplen la siguiente propiedad:


T = { t /  ti, tj  T (ti  hist(tj))}
Dada S una secuencia y T un conjunto de tuplas,
SET_HIS(T) = { S /( t  T)(S = hist(t) } ,es decir que SET_HIS(T) devuelve las secuencias que constituyen la historia de cada tupla de T.
Ejemplo 1.
Listar las historias de los empleados que actualmente ganan más de

$1000.00 .

La respuesta será
SET_HIS (  (CURRENT_EMP))

sal > 1000


Nótese que estamos combinando los operadores relacionales con los de secuencias.
3.3. Selección por posición
Denotado SEL_BY_POS( pos , Sn ), Sn es una secuencia y pos una

posición dentro de ella, 1 <= pos <= n ,donde n = longitud de Sn.


SEL_BY_POS ( pos,Sn ) = { t/ Sn(pos) = t } ,es decir devuelve la tupla que ocupa la posición pos dentro de Sn.
Ejemplo 2.
Ej. 2.1. Listar la antepenúltima modificación sufrida por el empleado "X".
SEL_BY_POS ( 3, hist(  (CURRENT_EMP)))

E# = "X"


Notar que E# es clave de cualquier Snapshot de R , luego , lo es de

CURRENT_EMP,por lo que la selección devuelve a lo sumo una tupla .


Ej. 2.2. Listar el antepenúltima salario del empleado "X", si era mayor que

$ 600.
 (  (SEL_BY_POS( 3,  (CURRENT_EMP)))))

sueldo sueldo > 600 E# = "X"
3.4. Selección sobre una secuencia
 SEQ (Sn) .Es otra secuencia Sk,cuyos elementos hacen verdadero el

P predicado P,y que cumplen las 2 siguientes condiciones.


1)  j / P(Sn(j)) = V & ! m, m Sk(1) = Sn(j)
2)  i Sk(i) = Sn(j) & Sk(i+1) = Sn(i+1) &  l > 1 <==>  j ! m,

j <= m <= j+l / P(Sk(m)) = V & P(Sn(j)) = V & P(Sn(j+l) = V


3.5. Selección de una/s secuencia/s en un conjunto.
Si a las secuencias las tratamos como elementos de un conjunto,

podremos aplicarle operaciones análogas a las del Algebra,como la Unión, la Diferencia o la Selección.Los predicados de selección se aplicarán a secuencias completas y no a tuplas.

Sea CS un Conjunto de Secuencias.La Selección de Secuencias,denotada  SET (CS) es el conjunto definido como sigue :

PS
 SET (CS) = { S / S  CS, PS(S) = V }

PS
donde S: secuencia ,PS: predicado sobre una secuencia del conjunto PS será verdadero si la secuencia cumple la condición especificada .En 3.4,el predicado se aplicaba a cada elemento de una secuencia.

Ejemplo 3.
Listar los empleados que antes de tres modificaciones tenían un salario superior a $ 1000.
La respuesta es :
 SET ( SET_HIS ( CURRENT_EMP))

(SEL_BY_POS(3,Si)).sueldo > 1000


Vamos a explicar esta consulta.
Con SET_HIS ,formamos el conjunto de historias de todos los empleados. Sobre este conjunto se aplica SET , para determinar aquellas historias que cumplen con lo pedido.

Para que la respuesta nos dé solo el nombre de los empleados ,y no toda su historia, debemos aplicar una Proyección,operación que explicaremos más adelante. Nótese que aparece como argumento de SEL_BY_POS una variable de secuencia Si,que indica que se aplica a cada elemento del conjunto.Lo hacemos por motivos de claridad en la explicación,ya que de acuerdo al contexto siempre se puede determinar si el operador se apliica a una secuencia simple o a un conjunto.


3.6. Unión y Diferencia de Conjuntos de Secuencias.
De lo visto anteriormente deducimos :
CS1 U CS2 = { S / S  CS1 v S  CS2 }
CS1 - CS2 = { S / S  CS1 & S  CS2 }

3.7. Longitud de una Secuencia
L(Sn) = número de elementos de Sn ,por convención, n.

3.8. Proyección de una Secuencia
 SEQ (Sn) = { Sk / k = n & Sk(i) = Sn(i).X }

X

donde X es un conjunto de atributos.


Esta operación la aplicaremos más adelante a la resolución del ejemplo 3.
3.9. Primer y último elemento de una secuencia
Son dos operadores derivados de otros ya definidos, pero que son útiles a efectos de simplificar la expresión de algunas consultas.
FIRST(Sn) = SEL_BY_POS(1,Sn)
LAST(Sn) = SEL_BY_POS(L(Sn),Sn)
3.10. Operadores sobre todas las secuencias de un Conjunto
Por lo explicado en apartados anteriores , pareciera ser de utilidad poder explicitar cuando un operador se aplica a un Conjunto de Secuencias, y cuando a una Secuencia simple. En el primer caso, lo podemos hacer incorporando un argumento que será la variable de secuencia ya mencionada. La expresión de los operadores sería ,por ejemplo :
SEQ (CS , Si)

P

 SEQ (CS , Si)



X

FIRST(CS , Si) ,etc.


Ahora estamos en condiciones de terminar de resolver el Ejemplo 3.

Si al conjunto obtenido en dicho ejemplo lo denominamos REJ3 y le

aplicamos los siguientes operadores ,obtenemos la respuesta exacta a lo pedido, que estará dada por

 (FIRST(REJ3 , Si))

E#
Ejemplo 4.
¿Qué ocurriría si ahora quisiéramos obtener los 3 primeros sueldos de "X"? Con los operadores que conocemos, la consulta sería muy complicada de plantear, y en algunos casos similares no podría realizarse . Surge claramente entonces la necesidad de contar con un operador que permita obtener una sub-secuencia de la principal. A este operador lo definimos en

en la próxima sección.


3.11. Obtención de una Sub-secuencia .
Dadas 2 secuencias Sn y Sm,de longitudes n y m respectivamente,n < m, decimos que una Sn está incluída en Sm (Sn Sm) Sii
 j, 1 <= j <= m / Sn(1) = Sm(j) & Sn(n) = Sm(j+n-1) &  i , 1 < i < n ,

Sn(i) = Sm(i+j-1)


Dada una secuencia Sn,una posición p dentro de ella, y una longitud l tal que l + p <= n (donde n = L(Sn)), definimos el operador
SUBSEC (Sn ,p ,l) = {S / S  Sn & S(1) = Sn(p) & S(l) = Sn(p + l)}
La consulta del ejemplo 4 se plantea ahora muy fácilmente .

Llamando


H_X = hist (  (CURRENT_EMP)

E# = "X"
Luego, la consulta es


 (SUBSEC ( H_X , L(H_X) - 2, 3) )

E#,SUELDO


Con H_X obtenemos como siempre la historia del empleado "X". A esta secuencia le aplicamos el operador SUBSEC para obtener los 3 primeros elementos de esta secuencia. Finalmente proyectamos sobre los atributos pedidos.

4. Operadores agregados
Podemos considerar a los operadores agregados como compuestos por

una función y un alcance. La función se aplica sobre los elementos de la secuencia comprendidos en el alcance del operador.


Nuestra intención es definir operadores agregados que aprovechen la estructura de secuencia de la Base de Datos. En [SS93] se plantean operadores agregados mediante la sentencia "aggregate" combinada con una sentencia tipo GROUP-BY. Vale la pena decir que las funciones de agrupamiento pueden ser ejecutadas mediante sentencias HSQL ,por lo que no se tratan en este trabajo.Solo nos referiremos a funciones que se apliquen a las historias de cada tupla.
Otra aclaración que conviene realizar es que que consideramos estos operadores no forman parte de un álgebra pura sino de una extensión a ella. De todos modos se los incluye aquí ya que a partir de este modelo poderemos generar directamente un lenguaje tipo SQL que admita operadores sobre secuencias.
También debemos considerar en nuestro desarrollo,que deberá ser factible utilizar las funciones HSQL para generar las relaciones a las cuales aplicarle estos operadores . Por ejemplo , para el uso de operadores agregados , suele ser necesario compatibilizar las granularidades de las distintas relaciones mediante la utilización de las funciones EXPAND_BY COALESCE_ON [Sa93]).
Definiremos a continuación los operadores agregados propuestos.

Dijimos anteriormente que un operador agregado está compuesto por una función ,que denominaremos f, y un alcance a, siendo este el número de posiciones de la secuencia involucradas en el cómputo del resultado.Así,si deseamos obtener a partir de una secuencia ,y para cada posición i, la suma de los 2 últimos valores de un atributo , el alcance del operador en este caso es 2, y la función es la SUMA.


El alcance de un operador puede ser constante o variable para cada posición, pero como nosotros no admitimos la simplificación de trabajar con valores NULL en las secuencias, siempre estaremos en prescencia de alcances constantes.
Por comodidad, para posibilitar la ampliación de la cantidad de operadores agregados, definiremos por extensión un conjunto F de funciones .
F = { SUM, PROD, AVG, MAX, MIN } .El significado de cada función es suficientemente autodescriptivo.
Un operador agregado,aplicado a una secuencia Sn de longitud n, con un alcance a y una función f  F ,se define como
AG_OP(Sn,a,f) = {S/  i,a < = i <= n, S(i)=f(SUBSEC(Sn,i-a+1,a)) }
Obviamente,si quisiéramos aplicar el operador a una secuencia completa, deberíamos hacer a = L(Sn).
Optamos,para que la definición sea correcta, por asignar el valor NULL a los primeros a-1 valores de la secuencia resultante , no obstante lo cual , esto no se aplicaría en una implementación.
Ejemplo 5
Vamos a cambiar ahora la relación que tomamos de base para los

ejemplos anteriores por otra que almacene los aportes impositivos de las personas.


APORTES ( Contribuyente, monto) .
Se pide listar el promedio de lo aportado por "Juan Pérez" entre el 10/9/92 y el 10/8/94. Por claridad volvemos a permitir la asignación de secuencias.
H_APORTES = hist (  (CURRENT_APORTES) )

contribuyente = "Juan Pérez"


Aplicando el operador 4 obtenemos
H_AP_1 = SEQ (H_APORTES)

FROM >= 10/8/94 &

TO <= 10/9/92
Finalmente lo pedido es
AG_SUM ( H_AP_1.monto, L(H_AP_1))
Ejemplo 6.
Volviendo a la relacion EMP ,planteamos la consulta :
Listar los promedios trimestrales de los salarios de "Juan Pérez".

Supondremos que la relación EMP tiene granularidad Date. Debemos, entonces aplicar las funciones HSQL para compatibilizar granularidades

de la relación y la función.
La consulta sería :
AVG_OP( EXPAND_BY_MONTH(hist (  (CURRENT_EMP))), 2)

E# = "Juan Pérez"



5. Composición de secuencias
Hemos cubierto hasta el momento un amplio espectro de operaciones que involucran secuencias,dejando para el final el caso en que se relacionan 2 o más de ellas.Esto se debe a que existen algunas consideraciones que vale la pena realizar.
En general, los trabajos sobre secuencias incorporan un operador especial para componer 2 o más secuencias , que las concatenan elemento a elemento. Esto es posible por la existencia de valores nulos,que garantiza

la "existencia" de valores para cada posición, lo cual , como se s abe , no ocurre en las Bases de Datos Históricas.


Lo que se pretende con la composición es habitualmente relacionar sucesos coincidentes en el tiempo,para lo cual en nuestro modelo original existe el operador Producto Concurrente que permite expresar fácilmente estas consultas.Supongamos, por ejemplo que,además de la tabla EMP, existe en nuestra Base de Datos una tabla COTIZ (moneda,valor) ,que almacena las cotizaciones de distintas monedas a lo largo del tiempo. La consulta " Listar el salario de "X" en dólares a lo largo de su carrera en la empresa " se escribe
SELECT E.sal/C.valor, E.FROM, E.TO

FROM CONCURRENT EMP E, COTIZ C

WHERE E.E# = "X" AND C.moneda = "Dolar"
Como vemos, expresar esta consulta es una tarea sencilla , por lo que el aprovechamiento de la estructura secuencial debería hacerse en la etapa de procesamiento y no al nivel de lenguaje.Nótese que lo que se hace aquí es componer 2 secuencias,una con los valores históricos del dólar, y otra con la historia del empleado.
No obstante lo antedicho , frecuentemente es necesario normalizar un

esquema temporal,si las tasas de variación de sus atributos, con respecto al tiempo difieren mucho entre sí. Por ejemplo, si en la relación APORTES agregamos el domicilio del contribuyente, debemos descomponerla en

DOM_CONT(contribuyente,domicilio)

APORTES(contribuyente,monto)


ya que se supone que las personas se mudan con menor frecuencia que la de los vencimientos impositivos.
Aquí es claro que estamos ante 2 conjuntos de secuencias con igual clave para sus atributos visibles. A menudo será necesario componerlos mediante un operador especial. Definimos entonces al operador COMPONER( S1, S2 ) ,siendo S1 y S2 dos secuencias (pudiendo ser

generalizado para n ),que da por resultado otra secuencia S,como


COMPONER(S1,S2)={ S/ i,j,k, S(i).X = S1(k).X,S(i).Y = S2(j).Y,

S(i).INT = (S1(k).INT ´ S2(j).INT ) ,

S(i).FROM > S(i+1).TO }
INT indica el intervalo de validez de cada tupla.

Análogamente podríamos definir distintos tipos de composiciones con solo modificar las condiciones.


Ejemplo 7.
Listar los aportes de "X" mientras vivió en "Y".
 SEQ(COMPONER( hist (CURRENT_APORTES)),

monto E# ="X"

 SEQ ( hist (  (CURRENT_DOM_CONT)))))

domicilio = "Y" E#="X"



6. Conclusiones y trabajo futuro
Hemos presentado un modelo de secuencias aplicable sobre un

Sistema de Manejo de Bases de Datos Históricas (SMBDH), que permite

expresar fácilmente consultas que no podrían plantearse mediante el HSQL. El SMBDH está siendo desarrollado por el GIBD de la UBA en el Departamento de Computación de la FCEN.
Los pasos siguientes serán : implementar este modelo convirtiendo los operadores en sentencias HSQL,aplicarlo a la etapa de optimización de las consultas de modo de aprovechar durante el procesamiento la estructura de secuencia(incorporando por ejemplo la meta-información que surge de esta) y comparar la performance contra consultas realizadas ignorando la estructura de los datos.
7.Referencias
[MV94] . M.Minuto - A.Vaisman .Un generador de programas para resolver

consultas sobre Bases de Datos Históricas.

Anales de UNIFORUM '95.
[Sa93] . N.L. Sarda . HSQL : A Historical Query Language.

Temporal Databases: Theory , Design and Implementation.

Benjamin/Cummings 1993.
[SS93]. A.Segev - A.Shoshami. A Temporal Data Model Based on Time

Sequences .

Temporal Databases : Theory , Design and impementation.

Benjamin/Cummings 1993.


[SLR94]. Seshadri-Livny-Ramakrishnan. Sequence Query Processing .

SIGMOD 94 . 5/94. Pág. 430 - 441.


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal