Los PITs son una entidad que facilita el acceso a los datos contenidos en los distintos sats de un hub o link. Con el entendido que cada sat varia sus datos en distintas frecuencias, esta entidad optimiza la construcción de consultas a base de datos al establecer las asociaciones correctas entre los distintos satellites.
Combinar las distintas fechas de los objetos para generar la base temporal y generar la combinación de todos los satellites, observaremos que los primeros cuatro registros aportaron de a poco la información removiendo nulls a medida que cada satN sobrepase la fecha.
Dependiendo de la frecuencia en que se cargan los objetos, los satellites pueden llegar a contener gran cantidad de cambios en tiempos muy pequeños (ej: 5 cambios por minuto) y desde la perspectiva de negocio ese nivel de detalle puede ser irrelevante. Por el contrario, es posible incluso que solamente se quiera saber el último cambio al final del día.
Los PITs son entidades capaces de implementar los mecanismos de time-condensing. Consiste en reducir la información que sí son cambios pero no es de interés para el negocio observar los cambios a tanto detalle en función del tiempo.
Los mecanismos de time-condensing son:
Continuos gap condensing
Estas entidades forman parte del área business data vault. Nos permiten representar todo el histórico de cambios, de forma que proporciona las combinaciones correctas de llaves primarias existentes en los distintos satellites que participan en un entidad de este tipo. La frecuencia con que este objeto presenta la información está definida por las necesidades del usuario de negocio.
Debido al propio funcionamiento técnico de las cargas desacopladas, el hub y sus distintos satellites pueden llevar a distintas secuencias de aparición en función del load datetime. Para determinar la base temporal se incluyen entonces todas esas fechas con pequeñas diferencias generando varios registros iniciales hasta sincronizar la primera carga completa en todos los satellites.
Debido al propio funcionamiento técnico de las cargas desacopladas, el hub y sus distintos satellites pueden llevar a distintas secuencias de aparición en función del load datetime. Para determinar la base temporal se incluyen entonces todas esas fechas con pequeñas diferencias generando varios registros iniciales hasta sincronizar la primera carga completa en todos los satellites.
Combinar las distintas fechas de los objetos para generar la base temporal y generar la combinación de todos los satellites, observaremos que los primeros cuatro registros aportaron de a poco la información removiendo nulls a medida que cada satN sobrepase la fecha.
Dependiendo de la frecuencia en que se cargan los objetos, los satellites pueden llegar a contener gran cantidad de cambios en tiempos muy pequeños (ej: 5 cambios por minuto) y desde la perspectiva de negocio ese nivel de detalle puede ser irrelevante. Por el contrario, es posible incluso que solamente se quiera saber el último cambio al final del día.
Los PITs son entidades capaces de implementar los mecanismos de time-condensing. Consiste en reducir la información que sí son cambios pero no es de interés para el negocio observar los cambios a tanto detalle en función del tiempo.
Los mecanismos de time-condensing son:
- Every change
- Frecuency Condensing
- Continuos Gap Condensing
En general, la construcción de estos objetos inicia con establecer la base temporal de cambios que deseamos presentar, aplicando un filtro con la frecuencia solicitada. Este objeto cuenta con el atributo snapshot_datetime que supone ser el punto del tiempo en el que una combinación de "load dateitme" de los satellites es válida.
Definamos las frecuencias y como seria su implementación:
Every change
Esto significa que la base de temporal contiene todos los cambios que han sucedido en todos y cada uno de los satellites que conforman el PIT, osea que es no-time-condensing. Suele ser que este mecanismo genera más cambios de lo necesario y el crecimiento de la tabla se debe mantener en constante monitoreo.
Every change
Esto significa que la base de temporal contiene todos los cambios que han sucedido en todos y cada uno de los satellites que conforman el PIT, osea que es no-time-condensing. Suele ser que este mecanismo genera más cambios de lo necesario y el crecimiento de la tabla se debe mantener en constante monitoreo.
Frecuency condensing
En este método el usuario de negocio debe indicar la ventana de tiempo que desea registrar. Por ejemplo, el negocio quiere restrigir a máximo un cambio por minuto o hora o por día. No significa que registraremos la información minuto a minuto. Con esto establecemos bordes temporales fijos hacía los cual se debe asignar la información.
Entre las horas aportadas de load datetime se tienen 12:05:17 y 12:05:48, entonces una frecuencia de minuto solamente nos mostrará un cambio en load datetime igual a 12:05:00 y presentará la información de las 12:05:48.
Continuos gap condensing
En este mecanismo en lugar de definir bordes temporales fijos, definimos gaps de tiempo que deberán ser unificados. Por ejemplo, a los usuarios de negocio les interesa que de los cambios que se encuentrán separados cada 5 minutos, solamente se obtenga el último cambio.
Para este ejemplo teniendo eventos en 12:05:17, 12:07:08, 12:10:05 y 12:30:00, solamente se mostrarían como resultado 12:10:05 y 12:30:00.
Es de notar que con el uso de esta aproximación resulta muy fácil el modelo para construir distintos PITs en función de la necesidad, e incluso cambiar el time-condensing de un PIT existente sin tener un impacto en la estructura de datos.
PIT Window
La cantidad de registros dentro de una entidad de este tipo se vuelve insostenible, sobre todo si se registran cambios segundo a segundo, en unos pocos meses se tendrá una desmejora del rendimiento considerable. Para estos casos es deseable establecer una ventana de tiempo en que se guardará esta información, que además es conveniente que sea escalonada. Por ejemplo, se define que durante el último mes se almacenaran todos los cambios, pero antes de eso momento y hasta tres años atrás será un registro semanal, y antes de eso hasta 25 años atrás será un registro mensual.
La cantidad de registros dentro de una entidad de este tipo se vuelve insostenible, sobre todo si se registran cambios segundo a segundo, en unos pocos meses se tendrá una desmejora del rendimiento considerable. Para estos casos es deseable establecer una ventana de tiempo en que se guardará esta información, que además es conveniente que sea escalonada. Por ejemplo, se define que durante el último mes se almacenaran todos los cambios, pero antes de eso momento y hasta tres años atrás será un registro semanal, y antes de eso hasta 25 años atrás será un registro mensual.
Siguiente: Modelado - Bridge | Indice
Saludos,
Brian Estrada