bases de datos temporales - clase 01

BASES DE DATOS TEMPORALES

Bases de Datos AvanzadasFacultad de Ciencia y Tecnología – UADER

-2013 -

Bases de Datos Temporales

Una BASE DE DATOS TEMPORAL es aquella que contiene datos históricos en vez (o además) de datos actuales. (C.J. Date).

Bases de Datos TemporalesIntroducción

La posición extrema es que los datos de estas bases de datos sólo son insertados y nunca son eliminados ni actualizados y en este caso, la base de datos contiene solamente datos históricos.

El otro extremo es la base de datos “instantánea” que contiene solamente datos actuales, y los datos son eliminados o actualizados cuando los hechos representados por éstos dejan de ser ciertos (en otras palabras, una base de datos “instantánea” es simplemente una base de datos como la entendemos comúnmente y no una base de datos temporal).


A manera de ejemplo, considere la base de datos de proveedores y partes de la figura.


Esta base de datos es por supuesto una base de datos de instantánea y muestra entre otras cosas que el status del proveedor V1 es 20.

Una versión temporal de esta base de datos podría mostrar no sólo que el status es actualmente 20, sino también que ha sido 20 desde el 1 de julio y que tal vez era 15 desde el 5 de abril hasta el 30 de junio, y así sucesivamente.

En una base de datos de instantánea, el tiempo de la instantánea es tomado generalmente como "ahora" (es decir, el momento en el cual se está inspeccionando en realidad a la base de datos).


La característica distintiva de una base de datos temporal es, por supuesto, el tiempo mismo.


DATOS TEMPORALES

Si los datos son una representación codificada de los hechos, entonces los datos temporales son una representación codificada de hechos con marcas de tiempo.

En una base de datos temporal (de acuerdo a la interpretación extrema de este término) todos los datos son temporales, lo que significa que cada hecho registrado tiene una marca de tiempo. De esto se desprende que una relación temporal es aquella en la cual cada tupla incluye al menos una marca de tiempo (es decir, el encabezado incluye al menos un atributo de algún tipo de marca de tiempo).


DATOS TEMPORALES

Podemos decir entonces que una base de datos temporal (relacional) es aquella en la cual todas las relaciones son temporales.

Esta es una definición razonablemente precisa del concepto "base de datos temporal" (en su forma extrema).

Ahora descartamos ese concepto. Lo descartamos debido a que aunque las relaciones originales en la base de datos sean todas temporales, muchas relaciones que pueden derivarse de esa base de datos (como los resultados de consultas) no son temporales.


DATOS TEMPORALES

Por ejemplo, la respuesta a la consulta "obtener los nombres de todas las personas que hemos empleado alguna vez" obtenida a partir de alguna base de datos temporal, no es una relación temporal en sí misma. Y seria un poco extraño que un DBMS nos permitiera obtener resultados que por sí mismos que no pudieran ser conservados en la base de datos.

Por lo tanto, tomamos a una base de datos temporal como una base de datos que incluye algunos datos temporales, pero que no está limitada simplemente a los datos temporales.


Una BASE DE DATOS TEMPORAL es aquella que contiene datos históricos y datos actuales.


ALGUNOS CONCEPTOS Y CUESTIONES BASICAS

1. El proveedor V1 fue nombrado (es decir, colocado bajo contrato) en el 1 de julio de 1999.

2. El proveedor V1 ha sido un proveedor contratado a partir del 1 de julio de 1999.

3. El proveedor V1 fue un proveedor contratado durante el periodo que va del 1 de julio de 1999 hasta el día actual.



Cada una de estas declaraciones es una interpretación posible de una tupla que contiene el número de proveedor "V1" y la marca de tiempo "1 de julio de 1999", y cada una de éstas podría ser adecuada para esa tupla si apareciera en una base de datos “instantánea” que representara la situación actual en alguna empresa.Las preposiciones en negritas en, a partir y durante caracterizan las diferentes interpretaciones.

RELACION X[ atributo 1 (V1), …, atributo n (01/07/1999) ]



Podemos argumentar que las declaraciones 1, 2 y 3 en realidad están diciendo lo mismo en forma ligeramente diferente. De hecho, tomamos como equivalentes a las declaraciones 2 y 3, aunque no a la 1 y la 2 (ni la 1 y la 3).

Consideramos:

- La declaración 1 establece claramente que V1 no fue un proveedor contratado en la fecha (30 de junio de 1999) que precede a la fecha de nombramiento especificada; la declaracion 2 no establece ese hecho ni lo implica.



- Suponga que hoy ("el día actual") es el 25 de septiembre del 2000. Entonces la declaración 2 establece claramente que V1 fue un proveedor contratado en cada uno de los días que van desde el 1 de julio de 1999 hasta el 25 de septiembre del 2000 (inclusive); la declaración 1 ni establece ese hecho ni lo implica.

Por lo tanto, las declaraciones 1 y 2 no son equivalentes y ninguna de ellas implica a la otra.



Una vez dicho esto, las tuplas en una base de datos “instantánea” con frecuencia incluyen atributos como "fecha de nombramiento", hay que analizar cuidadosamente la interpretación pretendida.



Obsérvese que la declaración 1 expresa un tiempo en el cual se realizó determinado evento y en cambio, las declaraciones 2 y 3 expresan un intervalo de tiempo durante el cual persistió un estado determinado.

Las bases de datos clásicas (“instantáneas”) pueden manejar razonablemente bien los instantes de tiempo (los tiempos en los cuales suceden los eventos), pero no manejan muy bien los intervalos de tiempo (periodos durante los cuales persisten los estados).



Observe a continuación que aunque las declaraciones 2 y 3 son lógicamente equivalentes, su forma es significativamente diferente. Para ser más específicos, la forma de la declaración 2 no puede ser usada para registros históricos, mientras que la declaración 3 sí (siempre y cuando la frase "el día actual" sea reemplazada en esa declaración con alguna fecha explícita, digamos 25 de septiembre del 2000).

Esto es porque necesito el inicio y el fin del periodo de tiempo para considerarlo histórico.



Concluimos que el concepto "durante" es muy importante para registros históricos; al menos para los datos de estado aunque no para los datos de evento.

Notar que a pesar del uso de términos como "registros históricos", las bases de datos temporales también pueden contener información que se refiere al futuro.Por ejemplo, tal vez queramos registrar el hecho de que el proveedor V1 será un proveedor contratado durante el periodo desde a hasta b (donde a y b son fechas en el futuro).


TERMINOLOGIA

A los tiempos en los cuales sucedió determinado evento (o al intervalo durante el cual persistió determinado estado) se les conoce a veces como tiempo válido. El tiempo de validez se define como el tiempo en el cual un hecho es cierto en el mundo real.

Es diferente al tiempo de transacción, el cual es el conjunto de tiempos en los que estuvo un hecho representado en la base de datos como verdadera.


TERMINOLOGIA

Los tiempos válidos pueden ser actualizados pero los tiempos de transacción no; es decir, los tiempos de transacción son mantenidos completamente por el sistema y no está permitido que los usuarios los cambien, (están generalmente grabados, explícita o implícitamente, en la bitácora de transacciones, log, diario, etc.).


TERMINOLOGIA

Nota: Las referencias a intervalos y conjuntos de tiempos presentan una idea simple, pero fundamental, de que un intervalo que tiene un tiempo inicial s y un tiempo de terminación e, denota de hecho el conjunto de todos los tiempos t tales que s < t < e.

Donde "<" significa "antes que".


PREGUNTAS Y RESPUESTAS

Pregunta:

¿ Acaso la expresión "todos los tiempos t tales que s < t < e" no presenta el espectro de los conjuntos infinitos y las dificultades conceptuales y computacionales que sufren estos conjuntos ?.



Respuesta:

Sí. Pero descartamos el espectro y sorteamos las dificultades adoptando la suposición de que la "línea de tiempo" consiste en una secuencia finita de unidades de tiempo (crono, chronon, quantum) independientes e indivisibles. El intervalo con tiempo inicial s y tiempo final e involucra por lo tanto una cantidad finita de tales unidades.



Pregunta:

Las declaraciones 1, 2 y 3 parecen suponer que las unidades de tiempo (los cronos, chronon, quantum de tiempo) son días, pero con seguridad el sistema soporta precisiones de tiempo de hasta pequeñas fracciones de segundo. Si V1 fue un proveedor el 1 de julio de 1999 pero no el 30 de junio de 1999, ¿qué va hacer con el periodo que supuestamente hay entre el inicio del 1 de julio hasta el preciso instante del nombramiento, y durante el cual V1 todavía no estaba oficialmente contratado?



Respuesta:

Necesitamos distinguir cuidadosamente entre los quantum de tiempo como tales, que son la unidad de tiempo más pequeña que el sistema puede representar, y las unidades de tiempo útiles para algún propósito en particular, y que pueden ser años, meses, días, semanas, etcétera.

A estas unidades útiles de tiempo las llamamos puntos de tiempo (las abreviamos como puntos) para enfatizar el hecho de que para lo que estamos haciendo, también los consideramos indivisibles.



Respuesta:

Ahora podríamos decir informalmente que un punto de tiempo es "una sección en la línea del tiempo" - es decir, el conjunto de quantum de tiempo - que se alarga desde un quantum "límite" al siguiente (por ejemplo, desde la media noche de un día hasta la media noche del día siguiente).

Por lo tanto, podríamos decir (de nuevo informalmente) que los puntos de tiempo tienen una duración, que en nuestro ejemplo es de un día. Sin embargo, formalmente los puntos de tiempo son (repitiendo) indivisibles y el concepto estricto de duración no puede ser aplicado.



Respuesta:

Utilizamos el término (informal) granularidad, la cual definimos (otra vez informalmente) como la duración del punto de tiempo aplicable.Por lo tanto, podemos decir que en nuestro ejemplo la granularidad es de un día, para indicar que dejamos a un lado - en este contexto - nuestra noción usual de que un día está compuesto de horas, que a su vez están compuestas de minutos, etcétera, (tales nociones pueden ser expresadas sólo recurriendo a niveles más finos de granularidad).



Respuesta:

La confusión sobre si quantums y gránulos son intervalos procede de una confusión entre la intuición y el formalismo. Una creencia intuitiva acerca de la manera en que funciona el mundo es una cosa; un modelo formal es algo completamente diferente. En particular, podemos creer que la línea de tiempo es continua e infinita, pero la modelamos - para efectos de cálculos en particular - como independiente y finita.



Pregunta:

Tomando en cuenta entonces que la línea de tiempo es básicamente una secuencia de puntos de tiempo (de alguna granularidad), podemos referirnos sin confusión al "tiempo inmediatamente subsiguiente" (o precedente) de cualquier punto dado. ¿Está correcto?



Respuesta:

Sí. Con respecto a lo que nos interesa, el inicio del tiempo es un punto de tiempo que no tiene predecesor y el final del tiempo es un punto de tiempo que no tiene sucesor.


PROBLEMAS

Modificamos el ejemplo, en primer lugar eliminamos la relación P de partes. Segundo, modificamos la relación VP de envíos descartando el atributo CANT (y dejando solamente V# y P#) e interpretamos esa relación VP modificada como:

"El proveedor V# es actualmente capaz de proporcionar la parte P#“En otras palabras, en vez de referirnos a los envíos reales de partes hechos por los proveedores, ahora la relación se refiere solamente a envíos potenciales; es decir, a la capacidad de los proveedores para proporcionar partes.


PROBLEMAS

La figura es una versión modificada del ejemplo anterior. Observe cuidadosamente que la base de datos sigue siendo instantánea; aún no incluye ningún aspecto temporal.


PROBLEMAS

Veamos algunas restricciones y consultas simples para esta base de datos. Posteriormente consideraremos lo que les sucede a estas restricciones y consultas cuando la base de datos es extendida para incluir diversas características temporales.


PROBLEMAS

Restricciones (base de datos de instantánea actual). Las únicas restricciones que queremos considerar son las restricciones de clave. (PK y FK)

Sólo para recordarlo, {V#} y {V#, P#} son las claves primarias de V y VP respectivamente, y {V#} es una clave externa en VP que hace referencia a la clave primaria de V (ignoramos la clave externa {P#}, eliminamos la relación P).

NO ENCONTRAMOS NINGUNA DIFICULTAD EN ESTO.


PROBLEMAS

Consultas (base de datos de instantánea actual). Consideramos solamente dos consultas, ambas muy simples:

Consulta 1.1: Obtener los números de proveedor de los proveedores que pueden proporcionar actualmente alguna parte.

VP { V# }

Proyección simple de V# en VP.


PROBLEMAS

Consulta 1.2: Obtener los números de proveedor de los proveedores que no pueden proporcionar actualmente ninguna parte.

V { V# } MINUS VP { V# }

Diferencia entre dos proyecciones.

NO ENCONTRAMOS NINGUNA DIFICULTAD EN ESTAS CONSULTAS.


PROBLEMAS

Tratamiento "semitemporal" de proveedores y envíos

Para continuar, nuestro siguiente paso es tratar en forma "semitemporal" (por decirlo así) a las relaciones V y VP añadiendo un atributo de marca de tiempo, A_PARTIR_DE, a cada una y renombrándolas adecuadamente. Renombramos a V como V_ A_PARTIR_DE y a VP como VP_ A_PARTIR_DE.


PROBLEMAS

La versión modificada del ejemplo anterior es,


PROBLEMAS

Para simplificar, no mostramos las marcas de tiempo auténticas; en su lugar, usamos símbolos de la forma dO1, dO2, etcétera, donde la "d" puede pronunciarse adecuadamente como "día", una convención a la cual nos adherimos para este ejemplo. Por lo tanto, nuestros ejemplos hacen uso de puntos de tiempo que son específicamente días. Suponemos que el día 1 precede inmediatamente al día 2, el día 2 precede inmediatamente al día 3 y así sucesivamente.


PROBLEMAS

El predicado para V_A_PARTIR_DE es: "el proveedor V# ha sido nombrado PROVEEDOR, ha tenido el status STATUS, ha estado ubicado en la ciudad CIUDAD y ha estado contratado a partir del día A_PARTIR_DE".

El predicado para VP_A_PARTIR_DE es:"el proveedor V# ha podido proporcionar la parte P# a partir del día A_PARTIR_DE".


PROBLEMAS

Restricciones (base de datos semitemporal). Las claves primaria y externa para esta base de datos "semitemporal" son las mismas que antes.

Sin embargo, necesitamos una restricción adicional, que puede ser vista como un aumento a la restricción de clave externa de VP_A_PARTIR_DE hacia V_A_PARTIR_DE, para expresar el hecho de que ningún proveedor puede proporcionar parte alguna antes de estar contratado.En otras palabras, si la tupla vp en VP_A_PARTIR_DE hace referencia a la tupla v en V_A_PARTIR_DE, el valor de A_PARTIR_DE en vp no debe ser menor que el que está en v.


PROBLEMAS

Formulamos la siguiente restricción:CONSTRAINT AUM_VP_TO_V_FK IS_EMPTY ( ( ( V_A_PARTIR_DE RENAME A_PARTIR_DE AS VA ) JOIN ( VP_A_PARTIR_DE RENAME A_PARTIR_DE AS VPA ) ) WHERE VPA < VA );

Con este ejemplo comenzamos a vislumbrar el problema. Tomando una base de datos "semitemporal", como la de la figura, probablemente tendremos que establecer muchas restricciones de "clave externa aumentada" como ésta, y pronto comenzaremos a desear poder contar con alguna facilidad adecuada para este propósito.


PROBLEMAS

Consultas (base de datos semitemporal). Ahora consideramos las versiones "semitemporales" de las consultas 1.1 y 1.2.

Consulta 2.1: Obtener los números de los proveedores que actualmente pueden proporcionar alguna parte, mostrando en cada caso la fecha desde la cual han podido hacerlo.

Si el proveedor Vx puede proporcionar actualmente varias partes, entonces Vx ha podido proporcionar alguna parte desde la fecha A_PARTIR_DE más temprana mostrada para Vx en VP_A_PARTIR_DE (por ejemplo, si Vx es V1, esa fecha A_PARTIR_DE más temprana es dO4).


PROBLEMAS

Por lo tanto:

RESOLVER EN SQL, ENCONTRAR EL A_PARTIR_DE MINIMO DE VP_A_PARTIR_DE PARA UN MISMO V#.

Resultado:


PROBLEMAS

Consulta 2.2: Obtener los números de proveedor que no pueden proporcionar actualmente cualquier parte en absoluto, mostrando en cada caso la fecha a partir de la cual no han podido hacerlo.

En nuestros datos de ejemplo, sólo hay un proveedor que no puede proporcionar actualmente parte alguna, el proveedor V5. Sin embargo, no podemos deducir la fecha a partir de la cual V5 ha estado contratado pero sin poder proporcionar alguna parte, debido a que no hay la información suficiente en la base de datos (la base de datos es todavía sólo "semitemporal").


PROBLEMAS

Por ejemplo, suponga que d10 es el día actual. Entonces podría ser que V5 hubiera podido proporcionar al menos alguna parte desde hace algún tiempo como d02, cuando V5 fue contratado por primera vez, hasta algún tiempo después d09; o si nos vamos al otro extremo, podría ser que V5 nunca hubiera podido proporcionar en absoluto parte alguna.Para tener alguna esperanza de responder la consulta 2.2 debemos terminar el tratamiento "temporal" de nuestra base de datos, o al menos la parte VP de ella. Para ser más precisos, debemos mantener registros históricos en la base de datos que muestren cuáles proveedores pudieron proporcionar cuáles partes y en qué momento. (Recordar que para ser “histórico” debo saber el “inicio” y el “fin”).


PROBLEMAS

Tratamiento "temporal" de proveedores y envíos


PROBLEMAS

La figura muestra una versión temporal de proveedores y envíos. Observe que los atributos A_PARTIR_DE se han convertido en atributos DESDE, y cada relación ha adquirido un atributo adicional de marca de tiempo llamado HASTA. Los atributos DESDE y HASTA juntos expresan la noción de un intervalo de tiempo durante el cual algo es verdadero; por esa razón, reemplazamos A_PARTIR_DE por DESDE_HASTA en los nombres de las relaciones.Puesto que ahora estamos llevando registros históricos, hay más tuplas en esta base de datos que las que había en sus predecesoras. Para ser más claros, vamos a dar por hecho que la fecha actual es d10 y por lo tanto, d10 aparece como el valor HASTA para cada tupla que se refiere al estado actual de las cosas.


PROBLEMAS

Observe que la base de datos temporal de la figura incluye toda la información de la base semitemporal de la figura anterior, junto con información histórica que se refiere a un periodo anterior (desde d02 hasta d04), durante el cual el proveedor V2 estuvo contratado.

El predicado para V_DESDE_HASTA es: "el proveedor V# fue nombrado PROVEEDOR, tuvo status STATUS, estuvo ubicado en la ciudad CIUDAD y estuvo contratado desde el día DESDE (y no en el día inmediatamente anterior a DESDE) hasta el día HASTA (y no en el día inmediatamente posterior a HASTA)".El predicado para VP_DESDE_HASTA es similar.


PROBLEMAS

Restricciones (primera base de datos temporal).En primer lugar necesitamos protegernos contra el absurdo de un par DESDE-HASTA en el cual el punto de tiempo de HASTA sea anterior al punto de tiempo de DESDE:

CONSTRAINT V_DESDE_HASTA_OKIS_EMPTY ( V_DESDE_HASTA WHERE HASTA < DESDE ) ;

CONSTRAINT VP_DESDE_HASTA_OKIS_EMPTY ( VP_DESDE_HASTA WHERE HASTA < DESDE ) ;


PROBLEMAS

Observemos las claves primarias, debemos incluir el atributo DESDE en la clave primaria para V_DESDE_HASTA y VP_DESDE_HASTA.

La clave primaria de V_DESDE_HASTA obviamente no puede ser sólo {V#}, porque entonces no podríamos tener al mismo proveedor contratado por más de un periodo continuo. Una observación similar se aplica a VP_DESDE_HASTA.


PROBLEMAS

Sin embargo, estas claves primarias no capturan por sí mismas todas las restricciones que quisiéramos. Considere por ejemplo a la relación V_DESDE_HASTA. Debe quedar claro que si hay una tupla para el proveedor Vx en esa relación con el valor s en DESDE y el valor t en HASTA, entonces queremos que no haya una tupla para el proveedor Vx en esa relación que indique que Vx estaba contratado en el día inmediatamente anterior a s o en el día inmediatamente posterior a t.


PROBLEMAS

Por ejemplo, considere al proveedor V1 para el que sólo tenemos una tupla V_DESDE_HASTA con DESDE = d04 y HASTA = d10. El simple hecho que (V#, DESDE) sea la clave primaria para esta relación es claramente insuficiente para impedir la aparición de una tupla V1 adicional "que se superponga" con (digamos) DESDE = d02 y HASTA = d06; lo que indica, entre otras cosas, que V1 estuvo contratado el día inmediatamente anterior a d04. Queda claro que lo que nos gustaría es que estas dos tuplas de V1 se fundieran en una sola tupla con DESDE = d02 y HASTA = d10.


PROBLEMAS

El hecho de que {V#, DESDE} sea la clave primaria de V_DESDE_HASTA también es insuficiente para impedir la aparición de una tupla V1 "contigua" con (digamos) DESDE = d02 y HASTA = d03, que indique de nuevo que V1 estuvo contratado en el día inmediato anterior a d04. Igual que antes, lo que nos gustaría es que las tuplas se fundieran en una sola tupla.


PROBLEMAS

Esta es una restricción que prohíbe dicha superposición y contigüidad:CONSTRAINT AUM_V_DESDE_HASTA_PKIS_EMPTY ( ( ( V_DESDE_HASTA RENAME DESDE AS D1, HASTA AS H1 ) JOIN ( V_DESDE_HASTA RENAME DESDE AS D2, HASTA AS H2 ) ) WHERE ( H1 > D2 AND H2 > D1 ) OR ( D2 « H1+1 OR D1 = H2+1 ) ) ;

¡Expresión muy complicada!, sin mencionar que nos hemos tomado la gran libertad de escribir (por ejemplo) "H1 + 1" para designar al sucesor inmediato del día indicado por H1.


PROBLEMAS

Obsérvese cuidadosamente que la combinación de atributos {V#, DESDE} en la relación VP_DESDE_HASTA no es una clave externa de VP_DESDE_HASTA a V_DESDE_HASTA (aunque involucre a los mismos atributos de la clave primaria de V_DESDE_HASTA).

Sin embargo, necesitamos asegurarnos que si un determinado proveedor aparece en VP_DESDE_HASTA, entonces el mismo proveedor también debe aparecer en V_DESDE_HASTA.


PROBLEMAS

CONSTRAINT AUM_VP_HASTA_V_FK_AGAIN1VP_DESDE_HASTA { V# } < V_DESDE_HASTA { V# } ;

Usamos "<" con el significado "es un subconjunto de".

Pero la restricción AUM_VP_HASTA_V_FK_AGAIN1 no es suficiente por sí misma; también necesitamos asegurarnos que, aunque se hayan realizado todas las fusiones deseadas de tuplas, si VP_DESDE_HASTA muestra a algún proveedor como capaz de proporcionar alguna parte durante algún intervalo de tiempo, entonces V_DESDE_HASTA muestra a ese mismo proveedor como contratado durante ese mismo intervalo de tiempo.


PROBLEMAS

Podemos intentar lo siguiente:

CONSTRAINT AUM_VP_HASTA_V_FK_AGAIN2IS_EMPTY ( ( ( V_DESDE_HASTA RENAME DESDE AS

VD, HASTA AS VH ) JOIN ( VP_DESDE_HASTA RENAME DESDE AS VPD, HASTA AS VPH ) ) WHERE VPD < VD OR VPH > VH ) ;

Sin embargo, esta especificación es incorrecta.


PROBLEMAS

Para ver por qué, hagamos que V_DESDE_HASTA sea como se muestra en la figura y que VP_DESDE_HASTA incluya una tupla para el proveedor V2 con (digamos) DESDE = d03 y HASTA = d04. Tal arreglo es claramente consistente y aun así la restricción AUM_VP_HASTA_V_FK_AGAIN2, como está establecida, en realidad lo prohíbe.No vamos a resolver este problema aquí, sino mas adelante.


PROBLEMAS

Consultas (primera base de datos temporal). Éstas son ahora las versiones completamente temporales de las consultas 1.1 y 1.2:

Consulta 3.1: Obtener V#-DESDE-HASTA para los proveedores que hayan podido proporcionar alguna parte en algún tiempo; donde DESDE y HASTA juntos indican un periodo continuo máximo durante el cual el proveedor V# pudo de hecho proporcionar alguna parte.

Nota: Aquí usamos el término "máximo" como una abreviatura conveniente para que signifique (en este caso) que el proveedor V# no pudo proporcionar parte alguna en el día inmediato anterior a DESDE o posterior a HASTA.


PROBLEMAS

Consulta 3.2: Obtener V#-DESDE-HASTA para los proveedores que no hayan podido proporcionar en absoluto ninguna parte en algún tiempo; donde DESDE y HASTA juntos indican un periodo continuo máximo durante el cual el proveedor V# no pudo de hecho proporcionar parte alguna.


PROBLEMAS

Bien, tal vez quiera hacer una pausa para convencerse de que, en realidad preferirá ni siquiera intentar estas consultas. Sin embargo, si lo intenta, se encontrará con que pueden ser expresadas (aunque en forma extremadamente laboriosa).

Por lo tanto, en pocas palabras, el problema de los datos temporales es que nos conducen hacia restricciones y consultas que son irracionalmente complejas de especificar; a menos que el sistema proporcione algunas “facilidades” bien diseñadas, lo cual (hasta donde sabemos) no hacen los DBMS comerciales actuales.


CLASIFICACION SEGÚN R. T. SNODGRASS

Las DBMS comerciales almacenan sólo un estado del mundo real, usualmente el estado más reciente. Aquellas bases de datos usualmente son llamadas “instantáneas” cuyo contexto de tiempo valido y tiempo de transacción es “ahora” mostrado en la siguiente figura:



R. T. Snodgrass clasifica las bases de datos en estáticas, históricas, rollback o bitemporales, según como se contemplen, o no, los conceptos anteriores dentro del esquema.

Las bases de datos estáticas no contemplan ni el tiempo de validez ni de transacción, no almacenan ninguna de estas referencias temporales en el modelo que emplean



Las bases de datos históricas contemplan únicamente el tiempo de validez, almacenan la información que conocemos como válida, tanto presente como pasada o futura, pero los cambios producidos en la información (como ha sido la evolución de las actualizaciones que se han realizado) no quedan almacenados.



Las bases de datos rollback, en cambio, contienen exclusivamente tiempo de transacción, nos permiten devolver la base de datos a un estado anterior en caso de que sea necesario, pero no permiten conocer durante que intervalo de tiempo ha permanecido como valida una determinada información.



Por último, las bitemporales soportan tanto el tiempo de transacción como el de validez, por lo que nos dan una visión más precisa de la evolución que ha sufrido la información tanto sobre sus intervalos de validez como de sus actualizaciones, al contemplar los diferentes estados por los que pasó la información, y permitir su recuperación.



Los estados almacenados en una Base de Datos bitemporal están representados en la siguiente figura:

bases de datos temporales - clase 01

Documents