A business key is not a technical key
A business key is the identifier a business user says out loud: a contract number, a staff number, an IBAN, an item code. It exists independently of the system that stores it.
A technical key — an auto-incrementing ID, an application GUID, a replication key — belongs to the system. It disappears the day the system is replaced. Building hubs on technical keys is like anchoring your warehouse to an ERP you'll change in five years.
The Three Questions to Ask Before Freezing a Key
- Does the business recognize it without translation? If a lookup table is needed to explain it, it is not a business key.
- Is it still valid if the source system is replaced tomorrow? If not, it's technical.
- Does it identify the same real-world object across all systems that handle it? If not, a composite key or a correspondence reference is needed.
The case of multi-source keys
The same customer often exists under three different identifiers in three systems. The temptation is to pick the “master system” and ignore the rest. That's a bet on the organization, not on the data — and organizations change.
The Data Vault answer is a same-as link: each source keeps its key in the hub, and the matching link carries the reconciliation decision. That decision remains revisable without destroying history, and you can always demonstrate on what basis two records were treated as the same customer.
Composite keys and collision perimeter
An invoice number is only unique within a legal entity; a product code is only unique within a catalog. Omitting scope produces silent collisions that surface months later as incorrect aggregates.
The practical rule: integrate the scope into the business key as soon as two sources can produce the same value for two different objects. The cost is zero during modeling; it is considerable after production deployment.
Hash keys: determinism and hygiene
Hash keys make loads parallelizable and independent of lookups. They only add value if the normalization applied before hashing is strictly identical everywhere: case, spacing, separators, null values.
Divergent normalization between two pipelines produces two different hashes for the same business key — hence two hub lines for the same client. This is exactly the type of rule that should be centralized rather than documented.
What beVault locks in for you
In beVault, business key definitions are driven by the model and applied during generation: normalization, hashing, and scope management are consistent across all loads, by design.
The benefit shows up exactly when it matters: when a source system is replaced, the warehouse absorbs the new source without replaying history or renegotiating identifiers.