OP asked,
This audit dimension is actually used on enterprise environments? The big companies uses it on their datawarehouse projects?
Short answer is: yes, sometimes
Long answer is, Audit dimension is used when it is really required. Audit dimensions are supposed to store ETL metadata information. And some of these metadata can be directly stored in fact table itself. Data such as, load date
, loading batch number
, job name
, user name
etc. you could directly store in your fact table.
But as a matter of fact, when you decide to store these information in fact table itself, you soon realize that many of these information are actually going to be same for a large number of records of the fact table.
For example, if you load 100K records in your fact table per day, the loading job name
, source file name
, user who executed the job
, batch number
etc. are going to be same for all these 100K records. So, it does make sense if you remove these information from your fact table, and maintain it in a separate table and refer the surrogate key
of that separate table to your fact. This reduces data redundancy, space requirement and may improve loading speed. Normal data normalization techniques, you know.
Off course, there are some information that you should not put in your audit dimension. Say, load date-time
of the records. This will be unique for all the records in your fact - so obviously if you are to put this information in your audit dimension, your audit table will be as big as your fact. Instead, you should put such information in your fact table itself.
I have personally seen / worked in some of the world's largest data warehouses in retail and telecom sector and have witnessed some kind of audit dimension in those data warehouses.