Hi Folks, I'd like your opinion on best practices and design patterns, here.
Consider a buncha commingled data . . . you know the kind of thing . . . there's a main table with numbers and strings, and several lookup tables.
Some of the lookup tables only have a few entries, and maybe a single code/value pair. Indeed, in the main table, there are a number of strings thatcould be changed into codes, and externalised as lookup code/value tables. As this modelling process proceeds, we would end up with a main table containing numbers (going to be our Fact Table), some lookup tables that have a lot of entries and are clearly candidates for building hierarchical Dimensions, and some other stuff such as (say) sex, marital status, ethnic, and other code/value pairs.
Now, in a Kimball relational modelling scenario, I'd likely build a junk dimension to hold the non-associated code-value pairs . . . I don' wanna build no centipede after all! But is that valid for SSAS? After all, a 'cube' is actually the sparse intersection of numerous attribute hierarchy coordinates.
1. I could build many little dimension tables, put the codes into the main Fact table, build many little dimensions in SSAS, then and trust in SSAS to bring it all together for me. That would give me many little dimensions.
2. I could just forget about the code/value pair business, and translate all codes to strings (say 'Male', Female') right there in the main fact table (essentially considering them to be collapsed dimensions), and let SSAS create attribute hierarchies in a Fact Dimension created from the main table, with the numbers populating an associated Measure Group. That would give me one big Fact Dimension with a buncha sliceable, diceable, and sortable attributes.
What do you think? Do you prefer 1 or 2? Or is there a 3?
What do you think is best practice?
Donna Kelly