When Designing a BI Start Schema, Should Dimension Tables Use Only User-Friendly Attribute Values?

Question

I am designing the Dimension tables for my BI Start schema. I have already observed the value of user-friendly attribute values associated with each Dimension value, as these can be used quite readily and effectively in reporting.

I would like to know, is there ever any benefit to include/expose the encoded values of the source system (not including the source system's unique key, of course)?

For example, if I have an attribute called Color, whose native code values in the source system are: x2, x7, x9 for Red, Blue, Green respectively - is there any value in maintaining 2 columns in the Dimension table: one for the source system code value (e.g. x2) and one for the user-friendly value (e.g. Red)?

Is it common in BI reporting (we're currently using Cognos atop our star schema) to join back to the source system to get other attributes?

Should these "other" attributes always be surfaced to the BI schema, thus never joining back to the source system?

Answer 1

I find it worthwhile to expose the codes in the final (presentation) layer... inevitably, there is a group of users who go by the codes rather than descriptions (say, those in data entry, or the "export data to excel and merge with some other data source" types). Additionally, it helps for debugging and traceability. You can organize them all in their own folder or QS, keeping them separate from the business names as well. Thanks and good luck.