XREF Tables with History

Have you ever wondered what should be / could be and what shouldn’t be an XREF (cross-reference/lookup) table?  Have you ever sat and pondered the nature of these tables, and how they should interact with the Data Vault?  Have you considered storing history in the cross-references but weren’t sure why or how?  Well, I’ll try to answer some of these questions in this post.

What could/should be an XREF, and what shouldn’t?

Well, this one is mostly simple.  A cross-reference table in the Data Vault really is a table that stands alone, but more than that – it’s business key is used to describe transactions and other business keys.  In other words an easy hit would be something like: “type code” or “code / description”.  Codes / type-codes are basically role playing descriptors for other information.  They describe the status, state, or type of information that is related to another business key.  This classification of information really garners itself well to becomming (and should be) a cross-reference table.  The key by itself has no context within business.  The key is independent.  For instance a type code of “AB” is meaningless in it’s own context.  Let’s assume it’s a blood type – meaning “AB+”  well, ok – it still is descriptive in nature.  AB+ type code is absolutely meaningless unless we know the “marked bag of blood” that it is associated to.

In data modeling this is commonly referred to as: “dependent child” – however it’s not a dependent child from this perspective.  Why?  Because it’s a dependent descriptor…  AB+ really describes the type of blood that it is associated with.   So being descriptive data, IT CAN CHANGE OVER TIME (especially if someone makes a mistake, and tomorrow needs to change the type code of the blood because of lab analysis results).  Keep in mind that “each bag of blood is generally marked with a unique business key or bar-code”.

Now, these kinds of data really belong in cross-reference tables.  Why? Because in order to understand the full description, we should look it up.  We shouldn’t be storing the full description (replicating it) along side the type code in every Satellite historical record.  It’s simply non-sensical. It affects performance, multiplies the space needed to store satellite records, etc..  (of course I’m referring to the full description).

But the bottom line is: the type code with it’s description play a role in describing another business key.  Again, “AB+” is meaningless unless it is associated with some other context.

What is the nature of these tables, and how should they interact with the Data Vault?
Have you considered storing history in the cross-references but weren’t sure why or how?

The nature of these tables takes two forms: pure or current XREF (much like a standared 3nf OLTP lookup table – with no history), OR a Data Vault style: HUB + SATELLITE.  In the case of the blood product that I was discussing above, I would suggest the following:

XHUB_BLOOD_TYPE (blood_type_code PK & BK) ->
XSAT_BLOOD_TYPE_DESC ([blood_type_cd,blood_type_cd_load_date]PK,
  blood_type_cd_load_end_date, blood_type_code_desc)

** the “X” prefix stands for Cross-Reference in this case, it makes it clear to the data modelers and people reading the schema **

This allows you to store/capture the history of changes to the blood_type_code.  In this manner, you can tie the correct description in history to the correct data in the Satellite.  Yes, the Satellite in this case maintains the blood_type_code – in what appears to be a foreign key…  wow – I thought there were no foreign keys in Satellites… Right!  There shouldn’t be!  This one is there only logically – never implemented physically because blood_type_code by itself has no meaning to the business without additional context. 

It’s confusing, I know – but this is the nature of the business.  HOWEVER – in a table with column compression, or a database that is column based, you might choose to experiment with embedding the full description in the satellite along side the type code.  Why?  This is where it REALLY belongs.  Also, because column compression would supress the millions of “duplicate row entries” you would get, and help performance – and the column based database performs column compression for you automatically.

Hmmm, so we are really truly NOT breaking the rule of no foreign keys in satellites?

Correct – because of the real-application, and where the description is supposed to be/live we would not be breaking that rule at all.

What is the benefit of having XHUB, and XSAT then if they should be combined/absorbed?

Well, when the data is pulled from the Vault to the Data Marts, sometimes the dimesnions and facts want ONLY the latest description – they don’t need and don’t care about the historical description, so rather than “updating thousands or millions of Satellite rows” or “running some funky query to determine what the latest blood type is”, it is an easy task to query XHUB/XSAT combination to get this information.  Other data marts want/need the historical description – so again, XHUB/XSAT makes it easy to get.

Have you used Cross-References in your vault?  How did they turn out?  What issues did you run into?  Let me hear from you….

Dan Linstedt
DanL@DanLinstedt.com

Tags: , , , , ,

2 Responses to “XREF Tables with History”

  1. Cesar Vinas 2017/02/22 at 3:30 pm #

    Hi Dan. I have a Person Satellite with a Gender attribute. From source systems the values for this attribute can be: F, M, FEMALE, or MALE. Which of the two following approaches is the correct one:

    1. Store data in Gender as it comes from sources and in the Business Vault or Data Marts standardize the values to FEMALE and MALE only
    2. Create a cross-reference table to map out F to FEMALE and M to MALE, while loading the Person Satellite, transform F to FEMALE and M to MALE using the cross-reference table.

    I’m using Amazon Redshift that does support column compression.

    Thanks,
    Cesar Vinas

  2. Dan Linstedt 2017/02/27 at 1:54 pm #

    Hi Ceasar,

    Always store the data as it arrives in order to ensure auditability. Translate the data on the way out to the business vault. This keeps the audit trails in place, and allows you to change the rules when the business changes.

    Hope this helps,
    Dan

Leave a Reply

*