¿Qué es una business key en Data Vault?
Una business key es el identificador que sus empleados y clientes utilizan realmente: el número de cliente, el número de factura, el ID del contrato. Es estable, se comparte entre sistemas y es la base sobre la que se construye cada hub de un Data Vault.
La plataforma de automatización de data warehouse en la que confían equipos de datos de todos los sectores
¿Le suena familiar?
- El modelo se diseñó a partir del esquema de la base de datos, y el negocio no reconoce en él ni una sola clave.
- Tras la migración del ERP, cada cliente tiene un ID nuevo, y el historial ya no se puede relacionar.
- Dos sistemas contienen los mismos clientes, y el data warehouse no sabe qué registros se corresponden.
Un hub vale lo que vale la clave sobre la que se construye. En Data Vault, la clave del éxito es la business key.
Qué es una business key
Una business key es el identificador que utiliza el propio negocio: el número de cliente que figura en una carta, el número de factura que un cliente indica por teléfono, el ID del contrato en un correo electrónico. Empleados y clientes conocen estas claves, y por eso son estables. Un sistema puede renumerar sus filas internas; lo que no puede hacer fácilmente es cambiar un número impreso en diez mil facturas.
En términos de modelado de datos clásico, la business key es la clave natural, una de las claves candidatas de la entidad, a diferencia de la clave sustituta que una base de datos genera para sus propios fines. Si alguna vez ha elegido una clave primaria para un modelo conceptual, ya ha hecho este trabajo.
Cómo encontrarlas: el truco de la factura en papel
Muchos ingenieros de datos y modeladores dudan antes de preguntar a los usuarios de negocio por las claves. La pregunta suena técnica, y las respuestas acaban en nombres de tablas. Un ejercicio sencillo lo evita:
- Pida a los usuarios de negocio que impriman algunos documentos reales: un pedido, una factura, una nota de entrega.
- Pregúnteles: “Si un cliente le llama por este documento, ¿qué le dirá para que usted pueda encontrarlo?”
- Marque lo que señalen.
Esos identificadores marcados son sus business keys. La misma hoja de papel le muestra los conceptos que los rodean (cliente, pedido, producto) y cómo se relacionan entre sí, y ese es el punto de partida del modelo.
Por qué Data Vault se basa en business keys
- Integración pasiva. Las business keys se comparten entre sistemas de origen. Cuando tanto el
CRM como el ERP cargan el cliente
C-10442en el mismo hub, sus datos quedan conectados sin ninguna lógica de integración manual: la clave compartida y nuestra automatización hacen el trabajo. - Migraciones de sistemas de origen. Cuando se sustituye un sistema de origen, sus claves técnicas cambian. Sus business keys no, de modo que el historial anterior y posterior a la migración sigue coincidiendo.
- Generaciones de data warehouse. Lo mismo vale para el propio data warehouse. Cuando una nueva solución de integración de datos o de DWH tiene que hacerse cargo de los datos de la anterior, las business keys conectan ambas, porque también son estables entre versiones del DWH.
Cuando la misma clave significa cosas distintas en sistemas distintos, como el pedido 1018 en
los ERP suizo y alemán, el Business Key Prefix los mantiene separados.
Cuando una clave consta de varias partes, como el código de sociedad más el número de cliente,
la business key es simplemente compuesta.
El inconveniente
La mayoría de los sistemas de origen guardan la business key en la entidad que define: el número de cliente está en la tabla de clientes. Las relaciones, en cambio, utilizan claves técnicas. Una fila de pedido contiene el ID interno del cliente en el sistema, no el número de cliente. Cómo pasar de ahí a un modelo basado en business keys es el tema del siguiente artículo de esta serie, claves técnicas frente a claves de negocio.
Qué cambia con Datavault Builder
En Datavault Builder, el concepto se define una sola vez. Después, cada fuente se mapea a él definiendo qué columnas forman la business key, y Datavault Builder hace todo lo necesario para que la integración tenga lugar: el hub, la gestión de claves y el código de carga se generan. El esfuerzo se dedica a la conversación con el negocio, no a escribir lógica de carga.
Véalo funcionando con una de sus fuentes de datos
Reserve una demo gratuita y traiga el conector que más le cuesta, en dinero o en tiempo.
Tres pasos para encontrar sus business keys
-
Imprimir los documentos
Pida a los usuarios de negocio que traigan a la primera sesión pedidos, facturas y notas de entrega reales.
-
Hacer una sola pregunta
Si un cliente llama por este documento, ¿qué le dice para identificarlo?
-
Marcar la respuesta
Cada identificador que señalen es una business key. Los documentos muestran también los conceptos y cómo se relacionan.
Cómo Datavault Builder elimina las fricciones en la ingesta
-
La ingesta viene integrada
Cargas batch, delta y CDC desde bases de datos, archivos, APIs REST, fuentes NoSQL y Python, recibiendo flujos como Kafka en micro-batches. La misma plataforma que genera el warehouse, sin una segunda factura.
-
Su propio esquema, no el del proveedor
Las tablas de origen se mapean a un modelo Data Vault 2.0 diseñado por usted. Una nueva columna o una tabla renombrada modifica un mapeo, no una cadena de scripts post-carga.
-
Solo se mueven los deltas
Los hubs, links y satélites cargan lo que ha cambiado. Las recargas completas permanecen en staging en lugar de reprocesarse aguas abajo cada noche.
-
El historial se conserva por diseño
Cada cambio se retiene según llega, por lo que el reporting histórico funciona incluso cuando el origen sobrescribe sus propios registros.
-
Código que nunca tendrá que escribir a mano
La carga, historización y linaje se generan desde el modelo en tiempo real y se ejecutan de forma nativa en Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle o PostgreSQL.
-
Una plataforma, hasta nueve herramientas menos
Modelado, ETL, CI/CD, documentación y linaje en un solo lugar. Eso es lo que hace posible pasar del requerimiento a producción en 14,7 minutos.
Reconocido por BARC en The Data Fabric Survey 26
Hable con nuestro experto
Veinte minutos con nuestro Sales Director y una respuesta honesta sobre si esto encaja con su arquitectura.
Matt Collett
Sales Director
Perfecto, elija un horario que le venga bien:
Otros problemas que cubre esta serie
-
Claves técnicas frente a claves de negocio en Data Vault
Los sistemas de origen guardan la business key en el registro maestro, pero todas las relaciones se basan en claves técnicas. Cuatro formas de abordarlo, lo que cuesta cada una y el patrón que utilizamos: un PSA hub para las claves técnicas, mapeado al hub de la business key.
-
¿Qué es un satélite en Data Vault?
Un satélite contiene todo lo que describe a un hub: nombres, estados, importes y cada uno de sus cambios, que se añaden y nunca se actualizan. Es una Slowly Changing Dimension de tipo 2 sin UPDATE, con un registro de auditoría completo incorporado.
-
¿Qué es un link en Data Vault?
Un link registra una relación entre business keys: este pedido pertenece a este cliente. Datavault Builder cubre el link clásico de Data Vault y añade un link de transacción anclado en un grain hub, que fija la granularidad de una transacción y permite relacionar transacciones entre sí.
-
¿Qué es un hub en Data Vault?
Un hub representa un concepto de negocio central, como cliente, producto o cuenta, en forma de lista de sus claves: todas las que el data warehouse ha recibido alguna vez, cada una exactamente una vez. Almacena la identidad, no el estado, y esa sobriedad lo convierte en el punto donde desaparecen los silos de los sistemas de origen.
Preguntas y respuestas
- Dan Linstedt. Desarrolló el método en los años noventa y lo publicó hacia el año 2000. Data Vault 2.0, que añade al modelo hash keys, una metodología y una arquitectura, llegó en 2013.
- La obra de referencia es Building a Scalable Data Warehouse with Data Vault 2.0, de Dan Linstedt y Michael Olschimke (Morgan Kaufmann, 2015).
- No. Bill Inmon considera Data Vault una evolución de su visión del enterprise data warehouse en tercera forma normal, no un enfoque rival.
- No. A menudo, una salida dimensional forma parte de una implementación de Data Vault: el vault conserva el historial integrado, y sobre él se construyen los esquemas en estrella para el reporting. El mismo vault puede entregar también tablas planas o un Unified Star Schema.
- Con automatización, una vista en tercera forma normal sobre un Data Vault puede generarse de forma totalmente determinista. El vault contiene los datos una sola vez, y la capa 3FN se deriva del modelo. Cómo funciona.
- Intentarlo sin automatización. Data Vault se basa en un conjunto reducido de patrones estrictos y repetitivos, y eso es precisamente lo que lo hace tedioso y propenso a errores cuando se escribe a mano, y sencillo de generar. Por eso conviene utilizar Datavault Builder.
- Sí. Separar claves, relaciones e historial en hubs, links y satélites da lugar a más tablas que un modelo normalizado o dimensional. Por eso la capa física debería abstraerse mediante un enfoque basado en modelos como Datavault Builder, en el que usted trabaja sobre el modelo de negocio y las tablas se generan.
- Solicite una demo y vea un Data Vault construido sobre sus propias fuentes, o pida un entorno de formación y pruébelo usted mismo.
- Aquí. Datavault Builder es una solución de automatización de Data Vault: consulte los precios o solicite una demo.
- Datavault Builder se licencia anualmente para su uso. Las licencias perpetuas están disponibles bajo petición. Las ediciones y lo que incluyen figuran en la página de precios.