Sobre Links

Petr Beles, 2150 GmbH 2017-02-11 Links que representan transacciones en Data Vault

En este artículo solo discuto links que representan transacciones. Excluyo deliberadamente los links que representan relaciones (es decir, relaciones de master data — dando contexto a un objeto como el link entre una ciudad y un municipio).

Una fila en un link convencional en Data Vault se define por una combinación única de relaciones (representada por el hash de los BKs compuestos de todos los hubs implicados) más, potencialmente, un dependent child key. (Building a scalable DWH with DV 2.0 — Linstedt & Olschimke 4.4.5)

En el mundo real las transacciones tienen a menudo business keys únicas (el número que se comunica al cliente — no la clave técnica). Tomemos un pedido como ejemplo: un pedido tiene un número de pedido y cada línea de ese pedido tiene un número de línea. Aunque el número de línea por sí solo es una weak entity, es identificable de forma única combinando el id de transacción con el número de línea.

Esto significa que la hash key depende de relaciones identificadoras como la que va a la transacción (si se modela explícitamente) y el dependent child key como el número de línea de pedido. El problema es que también se usan partes no identificadoras como la relación cliente o producto para construir la hash key para una fila en la tabla link. En otras palabras, la hash key que representa la combinación de todas las business keys más el dependent child es de hecho una hashdiff key y no un identificador de transacción.

No hay nada de malo en eso. Una hashdiff key puede ser una herramienta muy potente para determinar si una fila debe insertarse o no. Si las relaciones no identificadoras de una transacción nunca cambian después de que la transacción se haya enviado al Data Vault, el grano del link es incluso el mismo que el grano de las transacciones.

El problema es: en muchas industrias, las relaciones no identificadoras de una transacción pueden cambiar o llegar después de que se haya enviado al Vault. Ambos procesos de negocio válidos llevan a una segunda entrada en el link Data Vault convencional.

Entonces, ¿por qué cambiar algo que funciona?

Sinceramente, porque nunca entendí el grano de la tabla link: una transacción tiene inicialmente una fila cuando llega por primera vez. Si el cliente de un pedido cambia como se ha descrito arriba, se añade una nueva fila. Así que ahora tenemos dos filas en la tabla link para la misma transacción. Si el pedido vuelve al primer cliente, sigue teniendo dos filas.

Y el segundo problema, más importante, es lógico: los link a link links tienen que omitirse porque no solo rompería sus procesos ágiles debido a las dependencias, sino que también enlazaría versiones de su transacción entre sí en lugar de la transacción misma.

Entonces, ¿qué cambios podrían mejorar la situación en mi opinión personal?

• Crear un hub que represente siempre el grano más fino de su transacción. En el ejemplo anterior: sales order line con una BK de order id combinado con el número de línea

• Incluir el link a este hub en su transacción. Deshacerse del dependent child key en el link, ya que no es necesario

• Conectar todos los atributos de contexto de su transacción al hub como satélite normal en lugar de conectarlo al link

• Conectar los tracking satellites que comprueban claves faltantes en la fuente a este hub en lugar del link

• Decidir si su transacción puede cambiar después de haberse enviado al Data Vault

  • Si sí: cargue su link como SCD Type 2 load basado en este hub conductor — puede crear una vista SCD Type 1 virtual o materializada sobre este link particionando por la keyed-instance hub key

  • Si no: cargue su link como SCD Type 0 load basado en este hub conductor

• Si el rendimiento es un problema, aún puede usar el enfoque hashdiff para cargar la tabla link SCD type 2

• Si necesita enlazar dos transacciones, simplemente cree un link entre los dos keyed-instance hubs basado en el grano correcto de esas transacciones

Lo curioso es, cuando observa lo que necesita hacer técnicamente, hace exactamente lo mismo que para cargar un satélite: compara atributos (hash keys enlazados) basándose en la hash key del hub.

Adicionalmente, añadir partes de link no identificadoras se vuelve absolutamente ágil porque simplemente se conectan al mismo hub y pueden unirse al link existente de forma sin pérdidas.

Y como último punto, puede poner partes opcionales de un link en una tabla separada poco poblada. Con el hub manteniendo el grano correcto de la transacción, puede reunir las partes obligatorias y opcionales. Solo aplique el mismo patrón que al combinar distintos satélites.

¿Esto se opone al estándar Data Vault?

Sinceramente, en la mayoría de las partes creo que no:

• Nada debería impedirle crear un hub en el grano más bajo de una transacción y llamarlo hub «keyed-instance».

• ¿Almacenar atributos dependientes de una hub key como satélite frente a un satélite link? Tampoco veo problema.

• ¿Es posible implementar links que estén realmente identificados por todos los objetos enlazados? Sí, es posible combinando todas las claves en el hub.

• ¿Puede reproducirse todo lo entregado a partir de los datos almacenados? Sí

• ¿Está garantizada la losslessness (Verbundtreue)? Sí

Hay un pero: implementar el link como SCD type 2 load basado en el keyed instance hub cambia la cantidad de filas en la tabla link. En mi ejemplo con un pedido que pasa del cliente A a B y vuelve, habría solo 2 filas en el patrón original. En el nuevo diseño tiene ahora 3 filas. La PK no es la hashdiff key basada en todas las partes, sino la keyed instance hub hash key + el load time.

Así que sí, hay una pequeña desviación del estándar que en mi opinión tiene sentido porque hace mucho más sencillo consultar la tabla: si quiere obtener la última versión de la transacción, simplemente particiónela por la driving hub key y tome la última load date.

No es necesario unir más tablas para encontrar la última versión como tendría que hacer en el diseño original. Lo mismo para crear una historia completa de la transacción: simplemente particionar por la driving hub key. Y lo más importante, el grano queda definido de nuevo: cada versión de la transacción en el tiempo tiene su propia fila.

Entonces, ¿debería usarlo?

Depende de usted. Pero estoy convencido de que el patrón funciona como se describe y lo hemos probado en escenarios del mundo real incluyendo procesamiento casi en tiempo real, y me gustan los beneficios que conlleva. Entonces, ¿lo uso para todos los links? ¡No! Pero lo uso para todos los links que representan transacciones. Los links entre master data que representan contexto son otra historia que discutiré por separado.