Missing out on SSAS Data Source Views

We usually don’t give much importance to the Data Source Views (DSV). But if we work on it properly, it makes your life very easy.

Refer to few of the following notes on DSV, which might help in making it more useful for your project.

1. Its only DSV where you can pull multiple data sources tables. This is the only place where you bring multiple data sources table in 1 DSV and later use in cube. how else ?? 😛
2. While creating manual DSV (New Diagram), you can pull one table only and then add related tables one by one (option is Right Click–> Show related tables). So you for example you can literally pull a fact table and call related tables for related dimensions. Also for those dimension call related tables for snow flake tables and in the end get one good quality Diagram without much hassle.
3. You also get to see original name of column even if you change to Friendly  Name for it (doesn’t work for table though). Following is the screenshot of how column name appears after renaming it. Table is also renamed from original DimGeography but only new name appear.
4. you might want to see only original name, to avoid any confusion with table or column or may be just want to know what came from source. Right Click –> un-check option Show Friendly Names.
5. You cannot delete a column just by Click–>Delete on DSV. Change the table to Named Query and remove the column from list of SELECT is your option.
6. DSV always warn you for incorrect relationships. For example, where it should be Many to one or one to many, Matching data type warning etc. Always listed to these warning. This is your practice ground for dimension usage relationships.
7. Did you use Zoom –> To Fit option ? If not then try it thank me later.
8. You can also manipulate values in Explore Data. Like select random or top sorted sample. Even increase/decrease the number of sample rows, by default its 5000. To achieve this, Explore Data for a table and in window with sample click on Setting option and manipulate as your choice (Don’t forget to click on refresh button to sample, all highlighted in following screenshot).
9. If you are new to SSAS DSV or tutoring, use Name Matching Criteria for quick relationships from tables pulled from data source. Click anywhere on DSV and look at properties with NameMatchingCriteria.

I could talk about some more interesting DSV related things, but length of the post is a concern. Let me know if you need details on these or anything more under comments section.

Analysis on performance comparison between DAX and MDX

Once I was asked to find out reason for difference in Performance for DAX and MDX on Tabular Model. For that i went through many links, post and ebook materials. Below are the consolidated observations.

Query Execution of DAX and MDX:

1. We need to understand high level query execution plan first for DAX or MDX in Tabular Model. Below screenshot explain the same (for any query on Tabular Model):
2. We cannot find any difference for the MDX and DAX query execution as per above figure.
3. Difference starts with transform of query from In-Memory Query mode to xVelocity Engine. Below screenshot shows how:Note: MDX is not working on DirectQuery mode.
4. Execution of queries is done as explained below:
   1. When a DAX query is sent to a Tabular Model, it generate DAX query plan and that is transformed into commands sent to xVelocity Engine.
   2. MDX query is analysed by the MDX Formula Engine, which calls the DAX Formula Engine to solve DAX measures (calculated measures in Tabular model) and generates a query plan that performs requests to the xVelocity Storage Engine.
5. Thus, MDX query is not converted into an equivalent DAX query, it generates one or more commands to the DAX Formula Engine and then to the xVelocity Storage Engine in order to retrieve values and evaluate the DAX measures it require.
6. So even when same result is given by DAX and MDX (i.e. when we call it DAX equivalent to MDX), different internal operations can be performed with different performances.
7. About the query plan, each time when the DAX Formula Engine is called to evaluate a DAX expression, a pair of DAX Query Plan events are generated (i.e. a logical plan event and a physical plan event, but let not discuss this in detail. Detailed information can be viewed here).
   But an MDX query may produce any number of pairs of events depending on how many times the MDX Formula Engine has to call into the DAX Formula Engine (for DAX measure as explained above).
8. Both MDX and DAX Formula engine perform single threaded operations
9. xVelocity engine can work on multi-threaded operation. So from above two points, it’s clear to push as much as request on xVelocity engine rather than Formula Engines. I think it will increase performance and it depends upon simpler queries. As the complexity of queries will increase, Formula Engine will be more busy than xVelocity.

From above discussion points, I tried to consolidate it as:

1. There is no direct way to say completely that DAX is better than MDX in performance or vice versa.
2. As MDX query uses DAX Formula engine to solve DAX measures, it may effect performance in any of two scenarios:
   1. If measure involve complex logic
   2. If many measures are called together (Refer point 6)
3. Huge data will not matter in performance, it will be time of converting DAX measure for MDX query by DAX Formula Engine. (Refer point 10)