I began to ponder this question after I noticed a system that I had been asked to work on had a cube based entirely off of views. I noticed that those views all joined in other tables/views and the views also had logic coded into them (if, case statements aswell as convert statements, concatation etc.). This all seemed horrible to me, but it made me wonder if one should ever base their datasource for a cube off of views?
To me tables make more sense. It prevents expensive joins in the datasource, and also isn’t prone to errors that could occur due to conversions performed by a view. However, I still see many people using views as datasources for cubes. Is there a best practice here? Am I perhaps missing some advantages that views give when used as a datasource?
Views are an important layer to insulate SSAS from the tables – not from column changes so much as from unwanted rows. Without a view SSAS will always process every row in the table. A classic case of this is a dimension table with SCD type 2 rows, where the cube only needs the “current” row. Other common cases are for limiting test data or feeding SSAS partitions.
These views are best kept simple i.e. no complex joins, CTEs, calculated columns etc. Those requirements are best tackled in the ETL layer – they are painful to test/debug/support in the SSAS layer.