| 1. Introducción Es popularmente aceptado que un modelo de datos posea entre sus principales componentes unas clases de entidades, con sus atributos y las relaciones existentes entre ellas. En este artículo, se pretende presentar algunos principios básicos y patrones de diseño de las estructuras de los datos cuando cada uno de los mencionados componentes del modelo se ven afectados por variaciones en el tiempo.
Pocos aspectos del modelamiento de datos se prestan a tanta confusión como el manejo de los datos relacionados con el tiempo o dependientes de él. Tan es así, que dependiendo del tratamiento que se dé al problema, conscientemente o no, se podrán obtener los mismos reportes pero con resultados diferentes.
El tema adquiere especial relevancia cuando se trata de modelar el repositorio de una bodega de datos, y ha sido objeto de muchos debates entre los modeladores y diseñadores de bases de datos. En primer lugar, el modelamiento de un repositorio para una bodega de datos es muy diferente al modelamiento de una base de datos operacional o transaccional, ya que los requerimientos que necesitan satisfacer tienen propósitos diferentes y muy específicos.
Otra diferencia básica radica en que la conservación de la información histórica es una de las características más importantes de una bodega de datos. Por ello, el reto de modelar datos que puedan conservar su valor en un momento del tiempo y registrar los cambios a través de éste (datos dependientes del tiempo), es mayor en una bodega que en una base de datos operacional.
Las técnicas de modelamiento de un repositorio de una bodega de datos son relativamente nuevas y aún en proceso de desarrollo. Mucho habrá de escribirse sobre el tema. El presente artículo ha sido la recopilación de los temas estudiados por el grupo de trabajo del DANE encargado de la difusión de los datos del Censo General 2005, y el cual tiene como tarea el diseño de un repositorio de información básica1.
Uno de los principales objetivos del Censo General 2005 es consolidar una plataforma de información básica, a partir de los datos obtenidos sobre la población, las viviendas, los hogares, las unidades económicas de industria, de comercio y de servicios, así como de las unidades agropecuarias.
De manera que el reto es diseñar y construir un repositorio de información básica que al partir de los datos censales, pudiera contener datos de censos anteriores, futuros, datos de diferentes registros administrativos y en general de otras operaciones estadísticas del DANE o de cualquier otra entidad productora de información básica, y que además pudiera desarrollarse e implementarse por incrementos.
Es decir, el objetivo es darle continuidad al Censo General 2005, o como lo afirma el Dr. Ernesto Rojas2, “Puede, en consecuencia, esperarse que más temprano que tarde los censos dejen de ser un sustituto de los registros para convertirse en su complemento”.
Para citar algunos ejemplos prácticos de los asuntos por resolver, podríamos preguntar:
·¿Cómo modelar las características o categorías de la vivienda de manera que al cambiar en el tiempo, se registrara su historia en el repositorio?
· ¿Qué pasa cuando algún o algunos miembros del hogar conforman un nuevo hogar?
· ¿Cómo registrar el cambio de hogar de una persona en el tiempo?
· ¿Cómo registrar el cambio de estado civil de una persona?
· ¿Cómo conservar históricamente la identificación de las divisiones geográficas utilizadas durante un evento de recolección de información, y cómo hacer que los datos asociados sean comparables con los de otro evento de recolección?.
· ¿Qué características del entorno urbanístico son variables en el tiempo?
Si bien es cierto que algunos de los atributos observados en el Censo son estáticos, la mayoría de ellos se ven afectados por cambios a través del tiempo, no sólo al nivel de las características individuales de las unidades investigadas, sino también de las relaciones entre ellas.
Con este artículo, se espera contribuir al entendimiento de la problemática a resolver y por demostrar que para registrar la historia, no es suficiente con adicionar una fecha de actualización a las características de una unidad de observación, como generalmente se acostumbra en los sistemas transaccionales.
2. El Problema
A manera de ejercicio práctico, el siguiente modelo multidimensional3 muestra para diferentes escenarios, las formas de interpretación de los resultados de un reporte por parte de los usuarios, cuando la diferencia en dichos resultados es ocasionada por el tratamiento que se da a los cambios de un atributo en el tiempo.
Para presentar el ejemplo, hemos querido evitar las falsas interpretaciones que hubieran podido originarse al utilizar datos estadísticos del DANE, y, por lo tanto, trataremos de explicar el problema con datos -no reales- sobre materiales vendidos en momentos diferentes.
En el ejemplo de la ilustración4, se debe producir un reporte de las ventas del mes de febrero, comparadas con las del mes de enero, clasificadas por grupo de material. Se debe considerar que entre enero y febrero el grupo de material BBB cambió de bebida a limpieza y que además se creó un nuevo material de limpieza EEE.
Datos de soporte: Para simplificar nuestro ejemplo, sólo consideraremos en el diseño, la tabla factual de Ventas con la dimensión Tiempo y la dimensión Material que son las que intervienen para la producción del reporte requerido.
ESCENARIO No.1.- Cualquiera que sea el grupo de material, lo único que importa es lo que registra la tabla al momento de correr el reporte. Es decir, usa la tabla actualizada de febrero.
La tabla de febrero muestra que el material BBB ya no pertenece a un grupo de bebida, sino a uno de limpieza. En este escenario es importante notar que el registro número 2 se ha modificado reescribiéndolo. Además, en febrero aparece un nuevo material EEE en el grupo de limpieza.
El reporte producido es:
ESCENARIO No.2.- Cálculos basados en los datos del grupo de material existentes al momento de la transacción de ventas; la verdad histórica. Es decir, en enero usa la tabla de enero y en febrero la de febrero.
Observe que la información se conserva en la tabla de enero, y en la de febrero el registro de material número 2 ha sido eliminado y además se han creado dos nuevos registros, ambos de limpieza.
El reporte produce resultados diferentes al escenario anterior, como se muestra a continuación:
ESCENARIO No. 3.- Se desea poder definir “un punto en el tiempo” y obtener el reporte basado en el grupo de material a ese punto.
En este escenario, el registro de materiales está diseñado para conservar un grupo anterior y un grupo actual con su fecha efectiva. Por lo tanto, en el mes de febrero se cambia el registro número 2 y se adiciona el registro número 5.
La tabla factual de ventas es la misma del escenario No.1.
El reporte deseado debe ahora comparar, en la tabla de febrero, la fecha de efecto con un punto en el tiempo para escoger entre el grupo de material anterior o el actual. El resultado dependerá de la fecha escogida para el punto, así:
Cuando el reporte a febrero, se quiere para los grupos de material vigentes a 15 de enero de 2006 (punto en el tiempo), los resultados producidos son:
Pero cuando el reporte a febrero se quiere para los grupos de material vigentes a 15 de febrero del 2006 (nuevo punto en el tiempo), los resultados producidos son:
En este escenario, ambos resultados son diferentes a los de los escenarios anteriores.
ESCENARIO No.4.- El reporte debe mostrar las ventas comparativas de aquellos materiales que no han cambiado, y existieron en ambos períodos para analizar tendencias sin confundirse con los cambios, la verdadera comparación.
En este escenario, el registro de materiales está diseñado para especificar la fecha_desde y la fecha_hasta la cual un material conserva sus características. Es así como, en el mes de febrero, se cambia la fecha_hasta del registro número 2 y se adicionan los registros números 5 y 6. Observe que ahora, el material BBB conserva la historia manteniendo los dos registros, el anterior y el actual con sus respectivas fechas de vigencia.
La tabla factual de ventas es la misma del escenario No.2.
El reporte deseado debe ahora comparar el período de meses a reportar (enero -límite inferior- y febrero -límite superior-) con el intervalo de tiempo entre fecha_desde y fecha_hasta para excluir aquellos materiales que han tenido cambio en dicho período.
Nuevamente, el reporte producido es diferente a cualquiera de los escenarios anteriores:
3. Alternativas de diseño
En un modelo de datos, algunos de los atributos de las entidades pueden cambiar con el tiempo. Como el modelo de datos5 del repositorio de una bodega de datos debe representar correctamente el estado de los cambios en la historia, se hace necesario registrar dichos cambios en forma adecuada. Lo mismo ocurre con las dimensiones en un modelo multidimensional.
3.1 Manejo del cambio en la misma entidad
Aunque algunos atributos son constantes en el tiempo, existen otros que son más o menos cambiantes, como por ejemplo, los definidos para productos, clientes, agencias, etc., sobre los cuales debemos tomar una de las siguientes decisiones de diseño según el atributo en consideración.
Cada una de estas alternativas ha sido denominada por Ralph Kimbal como cambios de Tipo Uno, Tipo Dos y Tipo Tres y se refieren al tratamiento de los cambios dentro de la misma entidad, como se describe a continuación.
Tipo Uno.- Cuando cambia un atributo sobre el cual no se necesita mantener la historia, simplemente se actualiza el registro de la entidad. El valor anterior del atributo se pierde al escribir el nuevo valor y como consecuencia no queda registrada la historia del cambio.
En este caso, hemos decidido racionalmente que no vale la pena guardar el valor anterior, porque no es importante, o porque no se requiere, o porque simplemente estaba errado (ver escenarios números 1 y 2).
Tipo Dos.- Al momento del cambio, se crea un nuevo registro en la entidad con el nuevo valor del atributo. Por tanto, la historia queda partida automáticamente, ya que registra el nuevo valor y el valor anterior.
El uso del Tipo Dos de cambios requiere de la creación y mantenimiento de llaves sustitutas6, cuando no se desea incluir la fecha del cambio como parte de la llave primaria.
En un modelo multidimensional, si la fecha de actualización existe en la dimensión, ésta no debe ser restricción para la consulta del usuario. En este caso se pueden permitir una fecha_desde y una fecha_hasta en el registro pero tienen un significado diferente a la llave foránea de fecha en la tabla factual.
También se debe ser cuidadoso en el uso de estas fechas si existen varios atributos en la entidad que puedan ser actualizados. Cuando ello ocurra, se debe crear un nuevo registro por cada atributo actualizado, introduciendo un nuevo campo para la descripción del tipo de actualización, o para la vigencia del registro (ver escenario número 4).
Finalmente, se deben considerar tanto la periodicidad del cambio (baja, media, alta) como el tamaño (número de atributos) de la entidad y cuando sea del caso, partirla en subtipos.
Tipo Tres.- Se crean dos atributos en el mismo registro de la entidad para llevar el valor actual y el valor anterior del atributo cambiante. La historia del cambio se describe en un solo registro.
En este caso, tiene sentido contar con un atributo que registre la fecha efectiva del cambio o la fecha de actualización (ver escenario número 3).
Como la tabla factual de un modelo multidimensional ve un solo valor para la llave del registro, la única manera de registrar la historia del cambio, es usando el campo de la fecha.
En éste tipo de tratamiento, se recomienda manejar solamente un valor actual y uno anterior para el atributo afectado. Los valores intermedios se pierden en la historia. Cuando hay necesidad de mantener varios valores en el tiempo, es mejor usar el cambio Tipo Dos.
Durante el diseño lógico de los modelos de datos, se deben identificar los atributos constantes y los dependientes del tiempo especificando para cada atributo en cada entidad, el tratamiento que debe darse al cambio y la opción escogida.
3.2. Manejo del cambio con entidades relacionadas
A diferencia del numeral anterior, la historia de los cambios no se registra en la misma entidad, sino en otras entidades relacionadas con la principal.
En las alternativas siguientes, se puede llevar no sólo la historia de los cambios, sino los eventos que la generan. Su estructura básica se presenta a continuación:
La entidad actual (Ent_Actual) no sólo contiene los valores corrientes o actuales de los atributos cambiantes, sino que es el único lugar para almacenar los valores estáticos.7
Esta estructura básica puede tener variaciones particulares:
· Evento es una clase de entidad general, pero podría tener subtipos8 o componentes que reflejen subconjuntos de atributos y sus procesos asociados.
· En algunas circunstancias, puede no requerirse la tabla de eventos, en cuyo caso sus atributos pueden estar contenidos en la tabla que registra los cambios Ent_Cambio, en la figura-.
· En otras variaciones, el evento puede generar un solo cambio, o siempre el mismo, en cuyo caso sería obligatorio9 (no opcional). Por tanto, se podría unir con Ent_Cambio.
· Ent_Cambio también podría tener subtipos para cada atributo cambiante, especialmente si son pocos.
· Ent_Actual podría tener los valores iniciales en lugar de los corrientes. Los procedimientos de actualización y consulta serían otros, en este caso. Las actualizaciones serían más simples, pero a expensas de las consultas.
· Al tener en cuenta que la entidad Evento no puede registrar sus propios cambios, o al menos no queremos guardar la historia de sus cambios, debe definirse un procedimiento para cuando se cometan errores al introducir cambios. Dicho procedimiento puede ser uno de los siguientes: a) corregir el dato sin guardar historia de los cambios; b) mantener una historia separada del cambio de los cambios; c) permitir un evento de corrección o de reversa que origina otro registro del cambio. · Los atributos cambiantes pueden ser cualitativos o cuantitativos pero su tratamiento para el manejo es lo mismo. En los cuantitativos siempre existe la opción de registrar el valor anterior o la variación del valor inicial.
·Ent_Cambio puede registrar los cambios o la historia de los valores anteriores; en este caso, podría muy bien llamarse Historia_Cambio. Es importante observar que los cambios son creados pero nunca actualizados ni borrados. Por ello, a veces se hace necesario incluir un indicador de obsoleto para marcar en Historia_Cambio aquella instancia que existió en algún momento y que aún se puede usar en ciertas transacciones.
·Los atributos dependientes del tiempo no sólo se tratarán con una fecha del cambio; sus reglas pueden igualmente aplicarse a un número de versión o a uno de secuencia.
3.2 Relaciones dependientes del tiempo Ahora y para completar el panorama, supongamos que la Ent_Actual (A) está relacionada con otra entidad (B), y dicha relación es o puede ser temporal, es decir, la relación varía con el tiempo.
¿Cómo modelar la historia del cambio entre dos o más entidades relacionadas?
Antes de responder, debemos considerar que una relación entre entidades puede ser transferible o intransferible.
En los ejemplos anteriores, estamos ante una relación transferible cuando un agente puede atender a uno o más clientes, y un cliente debe ser atendido por uno y sólo un agente. Si observamos lo que sucede en el tiempo cuando a un cliente se le asigna otro agente -evento que podría suceder-, la regla expresada por dicha relación ya no es válida.
Por otro lado, un pasaporte asignado a una y sólo una persona presenta un ejemplo de relación intransferible, ya que nunca se le podrá asignar a otra persona, al menos legalmente.
El problema con las relaciones transferibles es que la llave primaria de la entidad dependiente10 no es estable.
A continuación, mostraremos la estructura de los modelos para representar la historia del cambio en ambos casos, considerando, en primer lugar, una relación de uno a muchos. Dicha estructura utiliza y amplía el patrón discutido en el numeral anterior.
a) Estructura básica para relaciones intransferibles.
En este caso, basta con dividir las entidades A y B relacionadas, en una parte fija y en otra variable que registra las respectivas historias de los cambios. Ahora la relación entre las partes fijas no tiene problemas de estabilidad, ya que son intransferibles. El resto de la estructura del modelo sigue el mismo patrón explicado anteriormente. Observe que un evento ahora puede actualizar la historia de A o la de B o las de ambas.
b) Estructura básica para relaciones transferibles. Al ser transferibles, las partes fijas dependen del tiempo y su relación debemos transformarla en un atributo de la historia de B. Es decir, la entidad Historia_B hace las veces de entidad de intersección entre las partes fijas de A y B. El resto de la estructura del modelo se mantiene como en el caso anterior.
c) Historia del cambio para relaciones muchos a muchos.
Las relaciones de muchos a muchos se pueden transformar en otras de uno a muchos, al adicionar una entidad asociativa o de intersección.
En el caso más simple, cuando la entidad intersección no contiene otros atributos diferentes de las llaves, sólo necesitamos registrar el período para el cual la relación existe, utilizando una de las siguientes opciones:
Opción 1:
RESPONSABILIDAD [Id_Empleado, Id_Equipo, Fecha_Efectiva, Indicador_Vigencia]
Opción 2:
RESPONSABILIDAD [Id_Empleado, Id_Equipo, Fecha_Desde, Fecha_Hasta]
Para la opción 1, es importante anotar que nos permite consultar fácilmente las responsabilidades actuales de un empleado, mientras que para lograr lo mismo en una fecha pasada requiere de una programación más compleja. En cuanto a la opción 2, ésta soporta ambos tipos de consulta con programación relativamente fácil. Queda en manos del lector hacer el correspondiente ejercicio.
1Se define como básica la información de carácter estadístico o geográfico, resultante de procesar bases de datos conformadas a partir de registros administrativos, censos, encuestas y observaciones, siempre que sea estratégica o relevante para describir la realidad nacional.
2ROJAS MORALES, Ernesto. Algunas Reflexiones sobre el Censo 2005 en Colombia.
3Un modelo multidimensional consta de una tabla factual y de varias dimensiones. Ralph Kimbal, The Data Warehouse Toolkit.44
4Un rectángulo representa una entidad y una flecha, el símbolo de relación de uno a muchos entre entidades.
5Ver W. H. Inmon, Building The Data Warehouse.
6Identificador entero y único que reemplaza la llave primaria del registro
7Los valores estáticos son aquellos que no cambian con el tiempo.
8La entidad es subdividida en varias entidades.
9El anillo simboliza convencionalmente una relación opcional. La relación obligatoria no tiene anillo.
10En una relación, siempre existe una entidad principal y una dependiente. La llave primaria de la dependiente está compuesta por cada una de las llaves primarias de dichas entidades.
Bibliografía
Ralph Kimball (2001) The Data Warehouse Toolkit, John Wiley & Sons.
W. H. Inmon (2000) Building The Data Warehouse, John Wiley & Sons.
Chris Date, H. Darwen, Nikos Lorentzo (2003) Temporal Data and the Relational Model, Morgan Kaufmann.
Business Information Warehouse (2003) OLTP Extraction, SAP A.G.
Business Information Warehouse (2003) System Configuration, SAP A.G.
G. Simsion and G. Witt (2005) Data Modeling Essentials, Morgan Kaufmann.
Rojas Morales Ernesto (2006) Plan Estratégico de Información Básica Planib-, DANE, Bogotá.
Rojas Morales Ernesto (2006) Algunas Reflexiones sobre el Censo 2005 en Colombia, DANE, Bogota
|
