A very quick post on Analysis Services Data Source views!
Data Source Views (DSV) have been introduced in SQL Server Analysis Services (SSAS) 2005. A DSV is a metadata layer between the cube and the underlying data source that allows us to build our cubes without being connected to the underlying source. A DSV is a little bit like a Business Objects (BO) universe for the guys that come from that particular area of expertese.
I'm using SSAS 2005 (and hence a DSV) on my current project. The project currently uses the afore-mentioned BO XI as its report delivery and analysis tool but we are implementing SSAS side-by-side because there is functionality available in SSAS that suits a particular part of the business (that's another blog post).
We have followed best practice and created a series of views on our data warehouse that abstract the reporting and analysis tools away from the underlying data. Some people may wonder if this is really necassary given that we are using a BO universe and a SSAS DSV as an extra metadata layer but believe me there are legitimate reasons for doing it (and that's another blog post as well).
What I really wanted to point out was the value of the introductions of DSVs. We have a had a situation today where the underlying view names have had to be shortened because apparently BO can't handle object names greater than 32 characters (don't anyone flame me for saying that - I am only the messenger). In SSAS2000 this would have created huge problems but in SSAS2005 we simply have to change the DSV metadata to accomodate the changes. The cubes and dimensions are not affected. That is a huge huge advancement in SSAS2005 and can't really be understated. Making these changes in SSAS2000 would have been painstaking!
One thing I will say is that this is made easier by using named queries rather than named tables in the DSV. As a pointer to best practice I would recommend that you always use named queries in your DSV.
-Jamie