Audit dimension for a dimension?

[kskistad]

The books describe how to create a useful audit dimension for the fact table rows, but what about the dimension table rows? Why isn't that mentioned in the books? Isn't the data quality and lineage also important for dimensions?

Would you create a Audit dimension outrigger with a foreign key in the associated dimension table? Would this be the same Audit dimension as the fact table audit dimension, so all data is in one table?

Or would you simply add audit fields to each of your dimension tables and keep it there? The downside to that is the data is all over the place and would have to be collected or union'd to get a global picture?

[BoxesAndLines]

Kimball has a more comprehensive Error event fact table for handling errors and transformation enrichment (e.g. address cleansing). Here's a link, Data Quality Architecture

[Joy]

Yikes! The 2008 SSIS packages used to be up on the book's website, but I don't see them there now. I'll get them up there and post here when they're available. Expect them in a day or two. Sorry about that.

The 2008 version of the packages don't match the originals. Instead, they implement better practices. The audit dimension is one place they differ... the new version (which I can hardly call "new" any more) is even simpler than the version described in the 2005 book. My goal for the design of this audit dimension is to set the bar so low that you can have no excuse to not implement some sort of auditing. Clearly nowhere near as comprehensive as the version described in Ralph's article referenced in the previous post, nor other auditing and data quality screening described in The Data Warehouse ETL Toolkit.

[Sponsored content]