Los hubs representan los conceptos de negocio y los links las interacciones entre estos conceptos, en la ejecución de los procesos y actividades de la empresa. Estos conceptos y relaciones suceden en contextos de fechas, clasificaciones, tipos, etc. Estos context attributes se almacenan en entidades llamadas satellites (sat).
Estas entidades solamente deben estar asociadas a una única entidad padre, sea un hub o link. Se entiende que los datos contenidos serán contextuales a la entidad asociada. La estructura fundamental de este tipo de entidades recuerda a la funcionalidad de una slow changing dimension type 2, que provee un rastreo de cambios históricos. Por tanto, algo importante a entender es la temporalidad con que un dato mantiene su validez, que será desde el momento en que es cargado en el data warehouse hasta que un nuevo valor lo sustituye. La llave primaria de este tipo de objeto es el hash key de la entidad padre y la fecha de carga hacia el data warehouse (load datetime).
El data warehouse es un sistema informático encargado de integrar múltiples fuentes de datos, reconociendo el valor que está vigente en cada momento de la historia. Los valores tienen fechas de inicio y fin, marcando el período en que un conjunto de datos se presentaba en los sistemas de información. Una aclaración importante es que las fechas mencionadas son propias del sistema data warehouse y NO relacionadas a las provistas por los sistemas de información empresariales. La fecha en que inicia la validez de un dato es llamado load datetime.
Entre las ventajas de la definición de load datetime:
- Integración de datos que provienen desde múltiples zonas horarias, unificadas por el punto central donde se integran.
- Reducir el riesgo de cambios al desacoplar la integración del formato de los datos. Se entiende que la integración no depende la interfaz, estructura, volumen, etc. en que se proveen los datos. Se tienen protocolos y estándares de carga.
Es necesario establecer criterios claros en la identificación de los satellites que deben ser creados y asociados a una entidad. Entre los criterios sugeridos están:
- Un satellite solamente tiene una fuente de información (una sola tabla, archivo, servicio web, etc)
- Distintos satellite para distintas clasificaciones de sensibilidad: prohibited, restricted, confidential, public
- Frecuencias de cambio
- Calendarizado: hourly, daily, weekly, monthly, etc
- Volatilidad: low, medium, high
- Velocidad: very low, low, medium, fast, very fast
En la construcción de los satellites existen otras características importantes a tener en cuenta, que se abordan a continuación:
Zero / Ghosts records
Zero / Ghosts records
Entre los estándares es deseable tener consultas de alto desempeño, con estructuras semejantes a fin de promover la auto-generación de las mismas. Para estos propósitos se agregan registros tontos que permitan representar la inexistencia de datos y así realizar un inner join sin perder registros. Además en los satellites habilita tener un registro habilitado para cada momento del tiempo. También mejora de forma considerable el desempeño de las consultas a base de datos.
El ghost record por otro lado pretende entregar un registro válido para cada momento, incluso para aquellos momentos anteriores a la propia existencia del business key. Por cada valor en la lista de business key de un hub se agrega un registro con un load datetime lo más antigua posible (por ejemplo 1900-01-01) de forma que al consultar cualquier fecha entre load datetime y load end datetime siempre devuelva un registro. Esto significa que este ghost record será el válido desde 1900-01-01 hasta la fecha en que en realidad se carga el primer registro sobre el mencionado business key en un satellite.
*Por efecto de simpleza la precisión de las fechas está en días.
En el caso de los ghost records existe otra posible solución para su implementación, pues si el hub contiene millones de registros, serán millones de registros nuevos agregados al sat, y esto podría impactar de forma negativa el desempeño de las consultas. Esta solución se basa en el uso de otra entidad de data vault llamada point-in-time. El esquema de esta solución será incorporado en el post sobre <incluir el enlace a modelado de pit>.
End dating
Fecha que establece el fin de la validez de un conjunto de datos para un concepto o relación de negocio. Habilita la consulta de datos correspondientes a fechas particulares validando si la fecha está en el rango de load datetime y load end datetime.
Usualemente las fechas deben estar en millis, micros o nano segundos y el end datetime corresponder al siguiente load datetime menos una unidad temporal.
Se observa que el segundo registro inicia un milisegundo después que finaliza el registro anterior.
Unique datetimes
Al realizar la integración de múltiples CDC en una sola ejecución, es posible que el load datetime sea exactamente igual entre múltiples cambios. Este escenario hace necesario incluir un nuevo atributo que asegure una secuencia temporal correcta. Con este propósito es posible agregar el atributo "source row id" del staging que representa un secuencial apropiada. Entre las posibles soluciones está el incluir el atributo como parte de la llave primaria o adicionar esas unidades temporales a los load datetime.
Multi-active
En ocasiones te encontrarás que no existe una única información válida en un momento del tiempo, como por ejemplo el número de teléfono. En este caso sabemos que un cliente puede tener más de un único número de contacto y es necesario establecer todos como válidos.
Para estos casos debemos seleccionar un atributo candidato para ser incluido en la llave primaria del satellite y así habilitar varios registros válidos para un mismo momento.
Driving key
Esta característica en realidad se define para un link, pero impacta la construcción de sus satellites. Este satellite establece la validez de un hub (pivote) con respecto a otro hub. Si consideramos el ejemplo de la relación entre un promotor de negocio y un cliente, es posible que a través del tiempo el cliente se encuentre asignado a distintos promotores y esto lo modelemos con un link, pues este tipo de satellite nos delimita los tiempos que cada relación está vigente.
Existen variantes en los satellites:
- Overloaded: Consiste en un satellite que es cargado desde múltiples fuentes, esto a pesar que la recomendación sea el utilizar un única fuente por satellite. En ocasiones esta opción puede ser necesario, sin embargo, se debe tener en cuenta los distintos problemas que esta opción conlleva. Entre los riesgos están: distintos tipos de datos desde las distintas fuentes, valores no conocidos, determinar el registro actual, distintas fuentes proveen información sobre el mismo hash key, etc.
- Status Tracking: Es utilizado para establecer rastros de auditoria a las cargas. Esta entidad registra las operaciones SCRUD en los sistemas de información.
- Effectivity: Rastrea en el contexto temporal la validez de una relación. Esta fecha debe ser provista por el sistema de información. Adicional a los campos load datetime y load end datetime es necesario agregar begin date y end date que representen las fechas de validez de la relación desde una perspectiva de negocio.
- Record Tracking: Entidad que permite el rastreo de los sistemas de información que proveen información sobre determinadas llaves de negocio.
- Computed: Agregados a los computed links para contener la información contextual calculada.
Siguiente: Modelado - References | Indice
Saludos,
Brian Estrada