Es posible plantear dos tipos de preguntas a un histórico:
Tipo 1: ¿Cómo era tal elemento a una fecha dada? o ¿Cómo es hoy un elemento cuyo atributo a una fecha dada era tal?
Para responder a este tipo de pregunta es necesario mantener todos los estados por los que atraviesa un elemento, almacenando fechas, usuario y referencia a los eventos de cambio que los mueven.
Tipo 2: ¿Qué cambios ha sufrido un determinado elemento? Concretando un poco más se podría preguntar ¿Qué tipo de cambios físicos ha sufrido una subparcela? ¿Qué cambiós jurídicos (transmisiones) ha sufrido una unidad urbana? (es a lo que estamos acostumbrados en catastro).
Para responder a estas preguntas parece necesario llevar un registro de las operaciones que se realizan sobre los distintos elementos del modelo de datos que se quieran trazar.
En este apartado son de especial interes las transmisiones (de quien a quien, grupos...), los cambios de referencia y el linaje (segregaciones, agragaciones, etc.).
Además hay que responder a distintos niveles, pudiendo agrupar unos a otros (qué ha pasado en una parcela implica responder qué ha pasado en las unidades que contiene).
En el caso de las transmisiones se podría intentar su reconstrucción a partir de una tabla de log (cruzando la tabla consigo misma), pero habría que tener cuidado con las fechas (expiry=effective, siendo distintos para cada transmisión encadenada). Otra posibilidad sería la de presentar la historia de la titularidad como la sucesión de estados, ya que cada cambio de estado implica una transmisión (mismo problema con los rangos de fechas, ya que son las que determinan los estados).
Para que la información no esté sujeta a posibles incosistencias, sería necesario por tanto almacenar explícitamente las transmisiones (identificando cada transmisión) de manera similar a como se podría resolver una relación de linaje.
Tuesday, January 04, 2005
Histórico, expedientes y documentos
En la gestión de histórico es necesario mantener la referencia al evento de cambio que ha producido una determinada modificación. En la mayoría de los sistemas que manejamos suele tratarse de un documento (escritura, etc.).
Otra posibilidad es la de asociar los cambios a un expediente. Tiene la ventaja de ser más versátil, portable y fácil de manejar. Es ideal cuando el expediente tiene un sólo documento que produce todos los cambios que se han de realizar. Ya que entonces basta con hacer referencia al expediente.
De lo contrario, si en un mismo expediente existen distintos eventos de cambio que deben quedar registrados en el sistema, además del expediente será necesario hacer referencia a dichos eventos de cambio (documentos, etc.), desde las entidades a las que afectan.
Otra posibilidad es la de asociar los cambios a un expediente. Tiene la ventaja de ser más versátil, portable y fácil de manejar. Es ideal cuando el expediente tiene un sólo documento que produce todos los cambios que se han de realizar. Ya que entonces basta con hacer referencia al expediente.
De lo contrario, si en un mismo expediente existen distintos eventos de cambio que deben quedar registrados en el sistema, además del expediente será necesario hacer referencia a dichos eventos de cambio (documentos, etc.), desde las entidades a las que afectan.
Histórico y corrección de errores
Dentro del problema del histórico, surge el tema de la corrección de errores.
¿Qué pasa cuando se detecta que un cambio realizado estaba mal hecho?
En la base de datos a veces esto se da y se suele "deshacer" el cambio de manera que no quede rastro de él (como si nunca se hubiese producido), lo cual no es del todo correcto ya que aunque si que la base de datos refleja la historia de la realidad (se elimina aquello que en la realidad no fue cierto), se pierde la información que soporta el hecho de que en la base de datos la información sí que tuvo el error (que puede haber dejado rastros imborrables como cédulas emitidas, salvados anuales, estadísticas, etc.).
Esto está directamente relacionado además con los tiempos transaccionales (cuando las cosas se registran en el sistema-fecha grabación-) y los tiempos reales (cuando las cosas pasan en el mundo real-fecha escritura-).
La idea es poder dejar registro de las dos cosas:
Opción 1:
Crear un histórico a medida que esté siempre libre de errores (los arreglos se harían tanto en la vista actual como en la histórica).
Tener además un log automático de todo lo que va sucediendo en la BD.
Opción 2:
Mantener un único log histórico, en el que los registros que respondan a modificaciones erróneas estén marcados de alguna manera (pudiendo tenerlos o no en cuenta en la explotación del histórico).
Precisión: Realidad vs Realidad Registrada
Un sistema no tiene porqué recoger todos los estados de la realidad, y puede que le basten con determinados estados intermedios (en un documento de aceptación de herencia y compraventa, podría ser suficiente con recoger la transmisión general, sin tener en cuenta la transmisión intermedia).
¿Qué pasa cuando se detecta que un cambio realizado estaba mal hecho?
En la base de datos a veces esto se da y se suele "deshacer" el cambio de manera que no quede rastro de él (como si nunca se hubiese producido), lo cual no es del todo correcto ya que aunque si que la base de datos refleja la historia de la realidad (se elimina aquello que en la realidad no fue cierto), se pierde la información que soporta el hecho de que en la base de datos la información sí que tuvo el error (que puede haber dejado rastros imborrables como cédulas emitidas, salvados anuales, estadísticas, etc.).
Esto está directamente relacionado además con los tiempos transaccionales (cuando las cosas se registran en el sistema-fecha grabación-) y los tiempos reales (cuando las cosas pasan en el mundo real-fecha escritura-).
La idea es poder dejar registro de las dos cosas:
Opción 1:
Crear un histórico a medida que esté siempre libre de errores (los arreglos se harían tanto en la vista actual como en la histórica).
Tener además un log automático de todo lo que va sucediendo en la BD.
Opción 2:
Mantener un único log histórico, en el que los registros que respondan a modificaciones erróneas estén marcados de alguna manera (pudiendo tenerlos o no en cuenta en la explotación del histórico).
Precisión: Realidad vs Realidad Registrada
Un sistema no tiene porqué recoger todos los estados de la realidad, y puede que le basten con determinados estados intermedios (en un documento de aceptación de herencia y compraventa, podría ser suficiente con recoger la transmisión general, sin tener en cuenta la transmisión intermedia).