Data Vault 2.0 — Modelado — Hard Rules

Las hard rules son reglas de negocio que se aplican con el propósito de mitigar escenarios que introduzcan errores técnicos presentes e inherentes a los distintos procesos de construcción y carga de los objetos en el data warehouse.

Estas reglas se aplican al momento de realizar la ingesta de los datos hacía la plataforma de inteligencia de negocios, sea hacía el staging si estás cargando en batch o directamente al data warehouse si estás cargando en tiempo real.

Incluso algunas reglas es posible posponerlas hasta el procesos de carga de data warehouse a fin de limitar el impacto en stage. Un contra seguramente será el desempeño, pues un business key pospuesto deberá ser calculado en cada carga de las entidades del data warehouse en lugar de una única vez en la carga hacía el stage.

Al aplicar estas reglas debemos tener el cuidado que solamente realicemos transformaciones con propósitos de compatibilidad técnica y evitemos cambios a la interpretación o sentido de los datos. Por ejemplo: hay bases que pueden almacenar la expresión 0000–00–00 en un campo de tipo fecha, y es posible que nuestra base de datos de data warehouse no sea compatible, por tanto establecemos una regla que transforme esas fechas a null. Hemos cambiado el valor de la fecha, pero mantenemos el sentido de desconocer la fecha.

Las reglas las podemos clasificar en las siguientes categorías:

Deductivas

Establecen reglas para mapear nombres, tipos o valores desde la fuente hacía el destino en la plataforma de inteligencia de negocios.

• Rename: Poco recomendado cuando se utiliza stage. Procura mantener los nombres originales de la fuente, y en caso de tener un archivos sin headers, procura obtener los nombres originales del sistema donde se extrajo el archivo. Por otro lado, recomiendo renombrar en data warehouse los atributos para que reflejen de mejor manera el lenguaje de negocio.
• Retype: Entre distintas herramientas de almacenamiento se manejan distintos tipos. Por ejemplo, el timestamp de sql server representa una versión del registro mientras que en la mayoría de dbms representa una fecha de estilo unix. Otro caso es que soporten distintas precisiones, por ejemplo una base soporta nano-segundos y el data warehouse solamente micro-segundos.
• Reformat: Establece el protocolo a seguir cuando el valor no está con la estructurada deseada. Entre los casos están (pero no limitados a estos):
• Un sistema te entrega el valor 18679 mientras que otro 0018679. Puedes decidir que los ceros a la izquierda sean removidos (siempre y cuando no tengan un particular valor para el negocio).
• El formato de las fechas que debe probar para intentar parsear la fecha
• Número que no tiene la suficiente precisión
• Business Keys: Declara la expresión de la llave de negocio. Esta expresión pretender normalizar los más posible un valor para ser compatible entre múltiples sistemas y definir smart keys de ser necesario (alcance de la llave de negocio).
• Relations: Relaciones de llaves foráneas de las tablas en las bases de datos de los sistemas fuentes.
• Hash Difference: Un nombre más descriptivo podría ser Hash Record. La regla expresa los atributos que participan en el cálculo y el carácter separador al concatenar todos los atributos. Además es posible agregar que todos se trasladen a mayúsculas, redondear números, etc. Lo negativo de agregar estas reglas es que te puedes perder cambios importantes como tildes, nombres corregidos en mayúsculas entre otros.

Con business key y hash difference en los siguientes posts entenderás la utilidad de este tipo de reglas de forma más detallada.

Restrictivas

Delimitan la información que debe ser ingresada a la solución de inteligencia de negocios. Estas reglas resultarán en condicionales al momento de la selección de los datos extraídos desde los sistemas fuente.

• Casos de prueba: Durante el desarrollo o pruebas de configuración el negocio ejecuta pruebas en los sistemas de información, por lo que varios casos resultan en datos inconsistentes y no relevantes para ser cargados al data warehouse. Una regla que los identifique para ser excluidos es apropiado.
• Cargas parciales: Por temas de desempeño, cuando no es posible cargar toda la información de la tabla fuente se selecciona solamente información parcial, por ejemplo en tablas transaccionales solamente cargamos las transacciones de los últimos 5 días.

Alertas

Reglas que establecen cómo se debe registrar y notificar los eventos sucedidos en el data warehouse.

• Logs: Formato y nivel de detalle que se debe registrar en log de los procesos de carga. Además también aplica para la base de datos.
• Error: En caso de presentarse un error en los procesos de carga, bajo que circunstancias y hacía que correos hay que notificar ese particular error.

Estas son algunas reglas que he identificado pero sin duda no son las únicas, por si se tienes algunas reglas adicionales agrégalo a los comentarios para editar el post e incluirlas.

Desde ya adelanto que todas las definiciones que realices, incluyendo estas reglas es necesario que sean documentadas y de ser posible cargados a un gestor de metadatos para que puedan ser utilizados por los administradores. Al llegar a los posts sobre implementación, hablaremos sobre que campos debieras almacenar.

Serie: Data Vault 2.0

Este es un repost de mi sitio original escrito en el 2017.