In SQL Server Analysis Services 2005 you can use different methods to map your source data into your Analysis Services Database’s Data Source Views. You can map your data source model one-on-one onto your physical tables in your (dimensional) database or you can map it on database views. Needless to say, the latter provides an extra level of abstraction. Which is almost always a good thing, imo. You could also use named queries to map your data (the queries reside in your SSAS project) but then you’d lose the abstraction layer again: If the underlying data model changes you’d have to change the SSAS database too while if you base your data sources on views you’d just have to alter those instead.
Now, if you want to enable partition write-backs (which I think is a very interesting feature for forecasting and what-if analysis scenarios) you can only do that on measure groups containing measures of which the AggregateFunction is set to SUM (additive measures). So this can be a problem when your fact table contains both additive and semi-additive measures. As I said, you won’t be able to use write-backs on the semi-additive ones but if you’ve mapped your facts one-on-one you cannot enable them on the additive ones either since they will be in the same measure group (nope, you can’t create multiple measure groups on the same fact table in your data source views). Using database views or named queries you can easily get around this restriction.
But the views still provide a greater level of abstraction than the named queries…
