Page 220 - Data Architecture
P. 220

Chapter 6.2: Introduction to Data Vault Modeling
           Chapter 6.2



           Introduction to Data Vault Modeling



           Abstract



           One of the most important components of the end-state architecture is that of the data
           vault. The data vault exists to satisfy the need for rock-solid data integrity. Like all other
           components of the end-state architecture, the data vault has gone through its own
           evolution. And like all components of the end-state architecture, data vault will continue

           to evolve.


           Keywords


           Business context; Source system restructuring; Data vault model; Dimensional modelling;

           Data warehouse; Lean initiative; Satellite; Relationship table; Precaching; Hash keys;
           Business keys


           What Is a Data Vault Model Concept?



           From a conceptual level, the data vault model (DVM) is a hub-and-spoke-based model,
           designed to focus its integration patterns around business keys. These business keys are

           the keys to the information stored across multiple systems (hopefully the master keys),
           utilized to locate and uniquely identify records or data. At a conceptual level, these
           business keys are stand-alone, meaning they don’t rely on other information to exist.


           The concepts are derived from business context (or business ontologies), elements that
           make sense to the business from a master data perspective like customer, product, and
           service. These concepts are business drivers at the lowest level of grain. The DVM is built
           to house data at the level of granularity of the source systems.


           The DVM should never be simply designed as a “source system restructuring.” If there is
           no integration by business keys, then there is no point in building a DVM. Business keys
           need to reflect the concepts as they are defined within the business taxonomy. These
           taxonomy hierarchies define the context where the business keys live, along with their
           granularity.


                                                                                                               220
   215   216   217   218   219   220   221   222   223   224   225