The Data Vault Handbook - Concepts and Applications

Alternatively, a standard Satellite using a JSON payload could be employed to capture the details of multiple treatments. This approach stores all con- current treatments for a patient in a single record as a structured JSON ob- ject, simplifying the satellite design. However, this method may require ad- ditional processing to parse and analyze the JSON data during queries. 3.2.3. REFERENCE DATA ENTITIES Reference Tables store data that exists within the context of other informa- tion but doesn’t qualify as business keys since they don’t directly reference business objects. A common example of reference data is country ISO codes (e.g., DE for Germany, US for the United States). While these codes don’t rep- resent business objects, they are relevant when linked to other data, such as in a sales transaction. Typically, reference data includes a readable code (like the ISO code) and additional descriptive attributes (such as the country name, capital city, etc.). As in the example above, these kinds of codes are typically presented in a fixed-length format. This inherent characteristic eliminates the need for hashing since the primary advantage of hashing—producing a fixed-size out- put—is already achieved.

There are two approaches to modeling Reference Tables in Data Vault.

— Without Tracking Changes: In this approach, reference data is modeled as a simple flat table, where the reference codes (e.g., the ISO code) serves as the Primary Key, and the descriptive attributes depend on this key. This is ideal when there is no need to track the history of the data or when changes are rare. It keeps the design simple and performs well for static or infrequently changing reference data.