Bases de datos temporales

Temporalidad en bases de
datos

"El mejor profeta del futuro es el pasado"

http://en.wikipedia.org/wiki/Temporal_database

Motivaciones
• La información es “variante en el tiempo” .
• El tiempo es un atributo esencial de la información.
• Convencionalmente las bases de datos representan el
estado de los datos en un solo momento en el tiempo.
• Muchas aplicaciones necesitan representar la
información acerca del pasado.
– financiera(pagos)
– Médicos(historia del paciente)
– Gobierno
• Las bases de datos temporales, es un sistema que
administra los datos considerando la variación en el
tiempo de los mismos.
JOSÉ CUARTAS BASES DE DATOS 2

Motivaciones
• El objetivo de un sistema que administra el tiempo, es
describir la evolución histórica de los datos. Idealmente
de manera que esta descripción sea lo suficientemente
precisa como para ser capaz de justificar o mantener la
trazabilidad de los cambios en la propia información.

“The database is not the database-the log is the database, and the
database is just an optimized access path to the most recent version
of the log.”
B.-M. SCHUELER


Transacciones del tiempo

1 2 4 8 10 15 16 17 25 28 30 33 41 42 45 47 48 51 53

u
b
f
c
d
g

id
p
j
k
i
m
e

La base de datos evoluciona atravez de inserciones y actualizaciones


Comparaciones
• Las DB temporales:
– Mantiene información histórica.
– Los cambios se consideran como adiciones a la información
almacenada en la base de datos.
– Incorpora la noción de tiempo en el Sistema.
– Acceso eficiente a los estados pasados.
• Las DB convencionales:
– Evolucionan a través de transacciones de un estado a otro.
– Los cambios se consideran como modificaciones en el estado.
– No hay información sobre el pasado.
– Es una Instantánea de la empresa.


Bases datos temporales
• Modelos de datos temporales: es una extensión del
modelo relacional mediante la cual se adicionan
atributos temporales a cada relación.

• Lenguaje de consulta temporales: TQUEL, SQL3

• Adicionan métodos temporales de indexación y el
procesamiento de consultas.


Tiempo de validez en las DB
• El tiempo evoluciona continuamente.
• Cada objeto es una línea que representa un intervalo de
tiempo .
• Tiempo valido
• Es el tiempo en que un echo es una realidad.
• Es el periodo para el cual un echo es real.
• Soporte a las operaciones para un intervalo de tiempo:
– Eliminación para cualquier instante de tiempo
– La inserción para cualquier instante de tiempo
– Cambio de valor (modificación) de cualquier instan te de tiempo (sin un
orden predefinido)


Tiempo de validez en las DB
• La eliminación física, no permite saber los estados
anteriores de los datos.
• La noción de “futuro”, “presente” y “pasado” es relativo a
cierto instante(timestamp) del echo que ocurrio.

• Requisitos para los métodos de indexación:
– Almacena la última colección de objetos de un intervalo.
– Soporta cambios de adicionar/ eliminar/ modi en la colección.
– Consulta eficiente de los intervalos de la colección
• Consultas por fecha y hora.
• Consulta por Intervalo (período).


Tiempo de transacción en la DB
• Tiempo de transacción
– Describe el punto en el tiempo cuando la información fue ingresada en
la base de datos.
El tiempo evoluciona de forma discreta, por lo general se
asocia con el número de transacción.
Soporte a las operaciones para un intervalo de tiempo:
– Las actualizaciones pueden hacerse sólo con el estado actual,
el pasado no se puede cambiar
– Se tiene la caracteristica de regressar l estado anterior conocido
como "Rollback"
– La eliminación es lógica (no se elimina físicamente!).


Tiempo de transacción en la DB
Requisitos para los métodos de indexación:

• Almacenamiento lógico de los estados del pasado.
• Soporte para los cambios en los objetos o datos
actuales(adicionar/eliminación/modificación).
• Acceso y consulta eficiente de cualquier estado de la
base de datos.


Taxonomía del tiempo
• Los tiempos de transacción y de validez de una
BD no tienen porqué coincidir para un mismo
hecho:
– El tiempo de transacción viene marcado por el reloj
interno del sistema.
– El tiempo de validez de un hecho puede ser:
• Posterior al tiempo de transacción, lo que se llama actividad
proactiva.
• Anterior al tiempo de transacción, lo que se llama actividad
retroactiva.
• Simultáneo al tiempo de transacción, se llama actividad simultánea.


Bitemporalidad
• Tablas o DB Bi-temporal:
– Soporta ambas nociones del tiempo.
• Una base de datos de transacciones en tiempo,
pero el historial de cada uno es un intervalo
(además de los otros atributos de los registros)
• Mantener la evolución de una colección dinámica
de intervalo de los objetos
• En cada fecha y hora, es una base de datos de
tiempo válido


Bitemporalidad
C(t1) C(t2) C(t3) C(t4) C(t5)

t3 t4 t5 t
t1 t2

v v v v v

Iy Iy Iz Iy Iz Iy Iy
Iw Iw Iw

Ix Ix Ix Ix Ix


Información y cambios de
estado
• Preguntas:
• cómo se relaciona con la estructura de la información y
cómo un cambio de estado afecta a la información?.
• Enfoques :
• Información transitoria:
– la característica principal es que la alteración y
borrado de los registros existentes destruyen
físicamente el contenido previo de la información.
– Este tipo de información se encuentra habitualmente
en los entornos operacionales.


estado
• Información periódica:
– Un registro nunca se borra físicamente ni su
contenido es modificado.
– siempre se añaden nuevos registros para reflejar
actualizaciones o incluso borrados.
– La información periódica, por tanto, contiene un
completo registro de los cambios que han ocurrido.


estado
• Información tipo “snapshot”:
– Snapshot o fotografía representa una vista estable de
la información tal y como existe en un momento dado
del tiempo.
– Es un tipo especial de información periódica.
– Generalmente los “snapshots”:
• Representan la información en un momento concreto del
pasado, utilizado para reporte no modificables.
• Una serie de “snapshots” tomadas en distintos puntos del
tiempo proporcionar una vista de la historia de los datos.


TIPOS DE HISTORIA en la DB
• Historia: se trata de datos históricos almacenados en
tablas de una base de datos relacional.


• Historia reconstruible: datos sobre el estado
pasado de algo, obtenidos restaurando un archivo de
backup y aplicando después las transacciones de
actualización capturadas en un archivo de log del DB.

• Requiere la intervención del personal de TI y por tanto no es
en tiempo real.

• Son copias de respaldo periódicas de archivos o bases de
datos y un log de transacciones

• No existen datos históricos recuperables.


• Historia consultable: datos sobre el estado pasado
de algo, obtenidos mediante una consulta SQL, sin la
necesidad de restaurar archivos de backup y reaplicar
transacciones capturadas en el archivo de log del DB.

– Este tipo de historia puede ser en tiempo real.

– La historia consultable se almacena como un registro de
eventos(Historia de eventos) o como un registro de estados(
Historia de estados).


Historia de eventos: datos sobre eventos que
han alterado el estado de las cosas.
– Estos datos se capturan como transacciones en
tablas.
– Este método consiste en almacenar el estado inicial
de algo y posteriormente almacenar todas las
transacciones que lo van actualizando.


Historia de estados: datos históricos capturados como
copias del estado actual de un objeto, bien periódicamente
o en respuesta a un evento de actualización específico.
– Es un método de gestión de datos temporales que mantiene
todas las inserciones y borrados con sus dos imágenes, anterior
y posterior, para cada modificación.

– Se aplica para todas aquellas datos que tienen estados, es
decir, que pueden cambiar a lo largo del tiempo.

– La historia de estados se puede almacenar bien como
fotografías o como versiones.


• Historia fotografiada: conjunto coordinado de
copias en una base de datos relacional.
– Las fotografías (o snapshots) se toman habitualmente
considerando la base de datos completa, o también a veces
incluyendo únicamente un subconjunto de tablas relacionadas
semánticamente.
– los snapshots pierden cualquier actualización que haya sido
sobrescrita por actualizaciones posteriores del mismo dato
realizadas antes de la siguiente fotografía.
– Es una forma poco eficiente de registrar la historia, ya que se
crean copias de todas las filas, hayan cambiado o no.
– Su mejor característica mantener una copia exacta de cómo
estaban los datos en el momento de tomar la fotografía.

• Historia versionada: son actualizaciones
lógicas de filas individuales, implementadas sin
sobrescribir datos, “retirando” la versión actual
del objeto y reemplazándola con una nueva
versión que contiene los datos actualizados del
objeto.
• registrar la historia, ya que sólo se crean nuevas
filas cuando ocurre un cambio versionable.


METODOS GESTION DEL
TIEMPO
• En estas situaciones, el software no requiere
que los estados anteriores a la actualización se
encuentren disponibles para ser consultados.
Para este tipo de datos y requisitos de software,
la necesidad de los datos históricos es tan poco
• frecuente, que es suficiente la solución de
mantener historia reconstruible.


METODOS GESTIÓN DEL
TIEMPO
• Hay diferentes métodos, cada método satisface un
conjunto de requisitos que se dese almacenar en cuanto
a gestión del tiempo.
• Cuando no se requiere que los estados anteriores a la
actualización se encuentren disponibles para ser
consultados.
– la necesidad de los datos históricos es tan poco frecuente, que es
suficiente la solución de mantener historia reconstruible.


TIEMPO
En diferentes soluciones lo único que se necesita conocer en tiempo real es cómo
son las cosas en el momento actual, por consiguiente, no se requiere que los
estados anteriores a la actualización se encuentren disponibles para ser
consultados.
Generalmente se resuelve agregando La columna fx_alta que es la fecha en que
se insertó la fila. Y la columna fx_ult_act, cuyo valor se debe actualizar cada vez
que se actualiza una fila, es la fecha de última actualización de esa fila en
particular.
Tabla Para tener en la cuenta
atributo_PK (Atributo clave primaria)
No se sabe cuántas veces ha cambiado la
atributo_FK (Atributo clave foránea)
atributo fila.
atributo No se tiene conocimiento de qué columna
… o columnas cambiaron en actualizaciones
(Fecha de la inserción
fx_alta de la fila) anteriores.
(Fecha de la última se ha perdido información de la historia
fx_ult_act actualización de la fila)
consultable, se debe usar la historia
reconstruible

TIEMPO
• Es frecuente que se requiera tener una cantidad mínima de historia
disponible en tiempo. La forma más frecuente de hacerlo es implementar un
borrado lógico en lugar de un borrado físico.
– Aunque el borrado lógico se puede realizar de varias formas, es conveniente generar una
nueva columna para la fecha de borrado, fx_baja con dominio de fecha, la cual preserva y no
sobrescribe la información de metadato de fecha de última actualización,.
– Con esta opción no es necesario el indicador de borrado ya que las filas eliminadas con
borrado lógico son aquellas cuya fecha de borrado no es nula
Tabla
atributo_PK
atributo_FK
(Atributo clave primaria) Para tener en la cuenta
(Atributo clave foránea)
atributo • En la actualización, la fila tal como se insertó
atributo originalmente se pierde.
… • Se pierden todas las actualizaciones excepto
fx_alta de la fila) la última, incluso es imposible saber si hubo
o no actualizaciones previas.
(Fecha de la última La actualización están sobrescribiendo la
fx_ult_act actualización de la fila) información anterior, manteniendo únicamente
(Fecha del borrado
fx_eliminacion lógico de la fila) el último estado o estado actual de los objetos.


TIEMPO
• Para poder mostrar el estado de cualquier objeto tal como era en cualquier
momento de su vida”, es preciso retener el estado de los objetos antes de su
actualización además del estado posterior a la actualización, es decir, es
preciso mantener la historia de los objetos.
• Puesto que un requisito del modelo de gestión del tiempo dice que debe
permitir dar respuesta a las preguntas en tiempo real
• Para tener en la cuenta
• En las tablas normales las filas representan objetos, en las tablas versionadas
las filas representan versiones de objetos.
• Para un sistema versionado se recomienda implementa un modelo bitemporal
– Manja dos tipos de tiempo, el Tiempo de validez de los datos y el Tiempo de transacción de los
datos.
– Con un modelo bitemporal es posible corregir errores dejando constancia de que así ha sido y
permitiendo por tanto reconstruir la situación de la tabla en cualquier instante del tiempo.
– Este es el enfoque de “preservar la evidencia” en la corrección de errores, que no puede ser
abordado con un modelo unitemporal.


TIEMPO
Tabla Para tener en la cuenta
atributo_PK (Atributo clave primaria) Las fechas de validez:
atributo_FK (Atributo clave foránea) • Fecha de inicio de versión (fx_ver_ini): el instante
atributo
atributo en el que esa versión del objeto comienza a ser la
… versión actualmente en vigor.
Fecha de inicio de • Fecha de fin de versión (fx_ver_fin): el instante en
Fx_ver_inicial versión
el que esa versión del objeto deja de estar en vigor.
Fx_ver_final Fecha de fin de versión Las fechas que tiempo de transacción
fx_alta de la fila)
• Fecha de creación (fx_alta): el instante en el que
esa fila fue físicamente insertada en la tabla.
(Fecha de la última • Fecha de borrado lógico (fx_baja): el instante en
fx_ult_act actualización de la fila) el que esa fila deja de considerarse válida.
(Fecha del borrado
fx_eliminacion lógico de la fila)


Para tener en la cuenta
• Las bases de datos temporales y en muchos casos las
tablas bitemporales aunque al parecer conceptualmente
solo es agregar atributos de tiempo de validez y tiempo
de transacción, se debe tener en la cuenta lo siguiente:
• Las restricciones de integridad necesitan desarrollos extras como
procedimientos almacenados para verificar las restricciones temporales.
• Para la consulta se necesitan operadores temporales con el fin de
facilitar la gestión de los datos temporales, esto operadores deben
permitir la granularidad en la consulta, lo cual es la precisión con la que
se representa la información variante en el tiempo .
• Se debe agregan al modelo ER la expresividad necesaria para
representar la semántica de la información que varía con el tiempo.

JOSÉ CUARTAS BASES DE DATOS

Bases de datos temporales

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Bases de datos temporales

Similaire à Bases de datos temporales (20)

Plus de josecuartas

Plus de josecuartas (20)

Dernier

Dernier (20)

Bases de datos temporales