SSAS Compiling Data Before Processing Into Cube

Question

Working on my first SSAS project from scratch and hoping for some guidance. I have seen different approaches to bringing data into a cube and wondering which is the preferred if any.

Most of the examples i go through simply point to the tables/schemas (say 7 or 8 particular sales related tables) in a particular database, define measures and dimensions, and process based on those. However i have also seen some production systems that run one or more SP to compile the data from the 7 or 8 sales related tables tables into one or two that match closer to the required Fact tables. Then the cube data views are based on these.

Is there a particular approach that is recommended etc?

Thanks in advance.

Answer 1

Typically we have some sort of an ETL (Extract, Transform, Load) process built either with sp-s, or in SSIS, which reads from the source, does manipulations and then writes the data in a dedicated datamart star-like schema.

There are advantages to this approach and the only disadvantage is the effort, time and cost associated with it. For example, you can take care of data quality issues in the ETL, assign proper surrogate dimension keys (eg int keys) and model things like M2M relationships, etc.

Having said that, I also see many shops building cubes on top of their normalised schema. You can do this either as you mentioned - by using multiple tables in SSAS, or by building views, which mash up everything in a star-like schema and then use those views in the DSV and subsequently in SSAS. I would typically recommend this approach for proof of concept projects, or for things which really do not require their own schema to build as the normalised tables already have the data in a suitable format.

If you are building a proper SSAS solution and you have the time and skills to do it - you should definitely go for the first approach. However, if these factors are somewhat uncertain and you are just trying it out, playing with it, etc - you can start with views and later on replace them with a proper schema. This way you can learn how to do it without having to maintain a complex ETL (ie you are more flexible). Keep in mind that SSAS does prefer the data in a certain format and just building views, or using straight tables constrain you somewhat - when you feel the need you should create your own schema.