What Is a Hub in Data Vault?

Every data warehouse has to answer one question before any other: what are the things this business talks about, and how does it tell them apart? In Data Vault, the answer is a hub.

What a hub is

A hub represents one Core Business Concept: customer, product, account, contract. It is not a copy of a source system table. The customer hub holds every customer key the warehouse has ever received, from any source, each exactly once.

A hub stores identity, not state. It says nothing about the customer: name, address and status live in satellites, and the customer’s orders and contracts are connected through links. The hub only records that this key exists, when the warehouse first saw it, and where it came from.

If you know classical data modeling, you already know the hub

Data Vault does not replace what you learned about data modeling. It reuses it. Start from the conceptual model you would draw anyway: the business concepts and how they relate. Each concept, each entity in your ER diagram, becomes a hub.

Take a classic Customer table in third normal form:

Nothing is lost and nothing new is invented. The entity is split along lines you already know: what identifies it, what describes it, and what it relates to. The hub is the first of those three, which is why the work of finding hubs is the work you would do for any good conceptual model: agree on the business concepts and on how each one is identified.

The anatomy of a hub

A hub has four columns, and no more:

• Hash key. The primary key: a deterministic surrogate, computed as a hash (MD5 or SHA-256) of the business key, plus an optional collision code where two sources could use the same key for different things. In Datavault Builder that collision code is called the Business Key Prefix. Every table that references the hub computes the same value without a lookup.
• Business key. The key that identifies the entity in the business world: a customer number, a VIN, an IBAN. One column, or several for a composite key such as company code plus customer number.
• Load date. When the business key was first registered in the Data Vault.
• Record source. Which operational system delivered the key first.

The Business Key Prefix: same number, different order

The Swiss and the German subsidiary both run their own ERP, and both have an order 1018. They are two different orders, placed by different customers. Hashed on the order number alone, they would land on the same hub row, and everything the two systems know about them would be mixed.

The Business Key Prefix keeps them apart. Each source adds its prefix before the key is hashed, CH|1018 and DE|1018, so the order hub holds two rows, as it should. Use it only where the same key really can mean different things. Where two systems share a key with the same meaning, such as a group-wide customer number, they should map to the same hub row without a prefix.

Why we do not trim or upper-case the business key

A common recommendation is to trim and upper-case the business key before hashing it. We do not recommend that. It makes c-10442 and C-10442 the same customer, and a trailing space disappears too, even when the difference is a typo in the source. The vault then folds two entries and their relationships into one without anyone noticing. The hub should keep what the source delivered; deciding that two keys mean the same thing is a business rule, and it belongs in a visible place such as a same-as link.

Write once, never update

Hubs are append-only. Each load compares the incoming keys with the keys already in the hub and inserts the new ones. Once a business key is in, it stays forever: no updates, no deletes.

That rule has two consequences. A hub load depends on nothing else in the model, so all hubs can load at the same time. And a failed load can simply run again, because inserting the same new keys twice is not possible.

Where source system silos collapse

The hub is the integration point of the model. If the CRM and the ERP both identify a customer by the same real-world business key, both map to the same hub row, and everything the two systems know about that customer meets there.

That is why the business key is the real design decision. A key the business uses across systems is the best choice. It is not always available in a useful form: a source may only carry its own technical ID, or a key that is reused, formatted differently or missing for older records. How to handle that is the subject of a separate article in this series: technical versus business keys. Where two systems use different keys for the same customer, a same-as link records that they belong together.

What never belongs in a hub

• Descriptive context. Names, addresses, statuses and amounts go into satellites. A hub that collects attributes is a satellite in disguise, and it stops being stable.
• Foreign keys. A Store_ID inside the customer hub is a relationship, and relationships belong in links.
• Attributes posing as concepts. A status, a category or a currency code describes something; it is not a business concept of its own. Transactions are different: in Datavault Builder an order line or a payment gets its own grain hub, which the article on links explains.
• One hub per source. Three customer hubs, one each for the CRM, the ERP and the web shop, rebuild the silos the warehouse was meant to remove.
• Source system surrogate keys, where you can avoid them. An IDENTITY or AUTO_INCREMENT value from one database means nothing in the next system, so leave it out if a business key exists. Sometimes it is the best key there is, for example for the versions of a table the source has already historized, or for the lowest grain of a transaction that nothing else references. There it can be the right choice. The article on technical versus business keys covers when.

What changes with Datavault Builder

In Datavault Builder you define the concept once and map every source to it by defining its business key. The table, the key handling and the loading code are generated from that and run natively on your database, whether that is Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle or PostgreSQL.

• The key is a model decision, not a code pattern. You decide what identifies a customer. Writing the hash calculation and the insert logic is not part of that decision.
• New sources map to the same hub. Adding the web shop means mapping its customer number to the existing customer hub, not building a new one.
• The pattern is the same every time. A hand-written hub load gets copied, adjusted and slightly changed with every new source; a generated one does not drift.

What to decide

List the five to ten business concepts your reports actually talk about, and for each one write down the key the business uses to identify it. Where two departments give you different answers, or a source has no usable key at all, you have found the most valuable integration work in the project.