¿Diseño de base de datos para una "instantánea" puntual de los datos?

Question

Cómo diseñar una base de datos que admita una función que permita al usuario de la aplicación crear una instantánea de sus datos en un momento dado, un poco como el control de versiones.

Le daría al usuario la capacidad de volver atrás y ver cómo eran sus datos en el pasado.

Supongamos que los datos que se "fotografian" son complejos e incluyen combinaciones de varias tablas.

Estoy buscando una manera de dar a cada usuario de la aplicación la capacidad de hacer una instantánea de sus datos y volver a ella. Las instantáneas de bases de datos completas no son lo que estoy buscando.

EDIT: Gracias por sus respuestas. La respuesta de 6NF es convincente, como lo es la sugerencia de desnormalizar los datos de instantáneas debido a su simplicidad.

Aclaración: esta no es una pregunta sobre el almacenamiento de datos, ni es una pregunta sobre la copia de seguridad y restauración de la base de datos; se trata de cómo crear un esquema que nos permita capturar el estado de un conjunto específico de datos relacionados en un momento determinado. Las instantáneas son generadas por los usuarios de la aplicación cuando lo consideran apropiado. Los usuarios no snapshot toda la base de datos, sólo el objeto de datos que les interesa.

Answer 1

Hicimos esto una vez por la creación de tablas de bases de datos separadas que contenían los datos que queríamos instantánea, pero sin normalizar, es decir, cada registro contiene todos los datos necesarios para dar sentido, no referencias de identificación que puede más de largo o puede no existen. También agregó una fecha a cada fila.

Luego generamos activadores para inserciones o actualizaciones específicas que se unieron en todas las tablas afectadas, y las insertamos en las tablas de instantáneas.

De esta manera sería trivial escribir algo que restaure los datos de los usuarios a un punto en el tiempo.

Si tiene una tabla:

usuario:

id, firstname, lastname, department_id 

departamento:

id, name, departmenthead_id 

la instantánea de la tabla de usuario podría tener este aspecto:

user_id, user_firstname, user_lastname, department_id, department_name, deparmenthead_id, deparmenthead_firstname, departmenthead_lastname, snapshot_date 

y una consulta algo l ike

INSERT INTO usersnapshot 
SELECT user.id AS user_id, user.firstname AS user_firstname, user.lastname AS user_lastname, 
department.id AS department_id, department.name AS department_name 
departmenthead.id AS departmenthead_id, departmenthead.firstname AS departmenthead_firstname, departmenthead.lastname AS departmenthead_lastname, 
GETDATE() AS snapshot_date 
FROM user 
INNER JOIN department ON user.department_id = department.id 
INNER JOIN user departmenthead ON department.departmenthead_id = departmenthead.id 

Esto asegura que cada fila en la instantánea es cierto para ese momento en el tiempo, aunque departamento o jefe de departamento ha cambiado desde entonces.

Answer 2

SQL Server 2005 (en adelante) Enterprise Edition tiene la capacidad de crear Database snapshots

Answer 3

Oracle desde la versión 9i tener la tecnología Flashback, que está en Oracle 10g y 11g han mejorado mucho y puedes ver el estado de tu base de datos en cualquier punto dado de la historia, siempre que habilites el flashback.

Comprobar este documento: Flashback Overview

Answer 4

Usted puede utilizar los registros generados por el RDBMS para obtener instantáneas de los datos. Normalmente, los registros se utilizan para proporcionar recuperación de la base de datos. Sin embargo, también se pueden usar para replicar los datos en varias instancias de RDBMS o para obtener instantáneas de los datos.

Para obtener una instantánea de sus datos, simplemente tenga en cuenta todos los registros producidos antes del momento deseado en el tiempo. Luego "reproduce" esos registros para obtener la base de datos real con sus datos restaurados.

Cómo acceder y reproducir los registros depende del producto concreto RDBMS que utilice.

Otra posibilidad es utilizar bases de datos temporales. Tienen aspectos de tiempo incorporados y permiten "retroceder en el tiempo". Busque "Tecnología Flashback de Oracle", por ejemplo. http://www.stanford.edu/dept/itss/docs/oracle/10g/appdev.101/b10795/adfns_fl.htm#ADFNS1008

Answer 5

Esto no es fácil.

Básicamente está solicitando una Base de Datos Temporal (Lo que Christopher Date llama Sexta Forma Normal, o 6NF).

Para ser 6NF, un esquema también debe ser 5NF, y, básicamente, para cada dato, debe adjuntar un rango de tiempo para el cual el dato en ese valor es aplicable. Luego, en uniones, la unión debe incluir solo las filas que están dentro del rango de tiempo considerado.

El modelado temporal es difícil, es lo que hace la sexta forma normal de direcciones, y no es bien soportado en los RDBMS actuales.

El problema es la granularidad. La 6ª Forma Normal (según la entiendo) admite el modelado temporal haciendo que cada no clave (no clave :, es decir, cualquier cosa "activada" en la entidad que puede cambiar sin que la entidad pierda su identidad) sea una relación separada. A esto, agrega una marca de tiempo o intervalo de tiempo o número de versión. Hacer que todo sea una unión resuelve el problema de granularidad, pero también significa que sus consultas serán más complicadas y lentas. También requiere descubrir todas las claves y atributos no clave; esto tiende a ser un gran esfuerzo.

Básicamente, todo el mundo que tienen una relación ("Ted posee el certificado de acciones de GM con id 789") se agrega una vez: "Ted posee el certificado de acciones de GM con id 789 ahora" de manera que se puede decir al mismo tiempo, "Fred posee el certificado de acciones de GM con ID 789 desde el 3 de febrero de 2000 hasta ayer". Obviamente, estas relaciones son de muchos a muchos, (ted puede poseer más de un certificado ahora, y más de uno a lo largo de su vida, también, y fred puede haber sido el propietario del certificado ahora).

Así que tenemos una tabla de propietarios, una tabla de certificados de acciones y una tabla de muchos a muchos que relaciona a los propietarios y certificados por identificación. En la tabla de muchos a muchos, agregamos un start_date y un end_date.

Ahora imagine que cada estado/provincia/tierra grava los dividendos de los certificados de acciones, por lo que a efectos fiscales registrar el estado de residencia del propietario del certificado de acciones.

Donde el propietario reside, obviamente, puede cambiar de forma independiente con la posesión de acciones; Ted puede vivir en Nebraska, comprar 10 acciones, obtener un dividendo que Nebraska grava, mudarse a Nevada, vender 5 acciones a Fred, comprar 10 acciones más.

Pero para nosotros, es ted puede mover a Nebraska en algún momento, comprar 10 acciones en algún momento, obtener un dividendo en algún momento, que grava Nebraska, mover a Neveda en algún momento , vende 5 acciones a fred en algún momento, compra 10 acciones más en algún momento.

Necesitamos todo eso si queremos calcular qué impuestos debe pagar en Nebraska y en Nevada, uniéndonos a los rangos de fechas coincidentes/superpuestos en person_stockcertificate y person_address. La dirección de una persona ya no es uno a uno, es de uno a muchos porque es la dirección durante el intervalo de tiempo.

Si ted compra diez acciones, ¿modelamos un evento de compra con una sola fecha de compra, o agregamos una fecha_comprimida a cada acción? Depende de la pregunta que necesitamos que responda el modelo.

Answer 6

Con SQL Server al menos, puede utilizar el registro completo y mantener los registros de transacciones entre cada conjunto de copia de seguridad.

Luego puede hacer una copia de seguridad en un momento dado.

Esa es una solución pobre.

¿Qué quiere exactamente su cliente? ¿Es para fines analíticos (es decir, las preguntas son como cuántas órdenes tuvimos hace dos semanas)? Porque ese es exactamente el problema que resuelve un datawarehouse.

Answer 7

Tener instantáneas y/o una pista de auditoría es un requisito de base de datos común. Para muchas aplicaciones, la creación de 'shadow' o tablas de auditoría es una tarea fácil y directa. Si bien las copias de seguridad de nivel de base de datos y los registros de transacciones son buenas, no son un sistema de control de versiones.

Básicamente, debe crear una tabla oculta con todas las mismas columnas que la tabla base y luego configurar desencadenantes en la tabla base para colocar una copia de la fila en la tabla oculta siempre que se actualice o elimine.

A través de alguna lógica, puede recrear cómo se veían los datos en un momento determinado. Para una manera fácil de configurar esto en Sybase, vea: http://www.theeggeadventure.com/wikimedia/index.php/Sybase_Tips#create_.27audit.27_columns

Si necesita hacer muchas instantáneas históricas, puede mantener los datos en la misma tabla. Básicamente, crea dos columnas: una columna agregada y eliminada. La desventaja es que para cada consulta debe agregar una cláusula where. Por supuesto, puede crear una vista, que muestra solo los registros activos. Esto se vuelve un poco más complicado si tiene una base de datos normalizada con varias tablas, todas con historial.

Sin embargo, funciona. Simplemente tiene las columnas 'agregado' y 'eliminado' en cada tabla, y luego su consulta tiene el punto en el momento de su interés. Siempre que se modifiquen los datos, debe copiar la fila actual y marcarla como eliminada.

Answer 8

Uso Log Triggers

Todos los datos se capturan los cambios, dando la posibilidad de consultar como si en cualquier punto en el tiempo.

Answer 9

Quizás considere usar una solución NoSql como MongoDB para agregar todos sus datos relacionales en un solo documento, luego almacene ese documento con una marca de tiempo o número de versión. Soluciones como Kafka-Connect u Oracle Golden Gate simplifican la conexión de datos relacionales en las tiendas NoSql.