What is BI Semantic Tabular Model

What is BI Semantic Model?

Mostly everyone confuse this term with BI Semantic Tabular Model. People take both as same, which is wrong.

BI Semantic Model is not a Software or Tool. It is a part of the SQL Server 2012 RTM which creates semantic layer on data for analysis. We already know SSAS Cubes, similar to that BI Semantic Model provides ways of creating Multidimensional databases for Analytic Processing.

This semantic layer can be created using any of the three technologies:
So from now onward, Analysis Service in SQL Server will be called as BI Semantic Model.  Power Pivot is called as a plus to BISM, otherwise it covers BI Semantic Tabular Model (Tabular Model) and Multidimensional Model (SSAS Cubes).

What is BI Semantic Tabular Model (mostly known as Tabular Model)?

As discussed above, this is a new approach of creating Multidimensional Database introduced with SQL Server 2012 RTM.

For the people who doesn’t know PowerPivot:

Tabular Model is technology for creating a multidimensional database out of tables (no concept of Dimensions and Measures). Same as old fashioned cubes, it consume data from different sources and give a cube to slice and dice the data for different aggregations.

Process of creating a Tabular Model involve:

1. Create a new Project on Visual Studio 2010 (added with SQL Server 2012 SQL Server Data Tools). Same as BIDS for multidimensional cubes.
2. Add all the tables required for analysis. We can use different types of data sources and can customize incoming data by query editors. No pain of creating separate Dimension and Fact tables like SSAS Cube.
3.  Relate the tables inside Tabular Model. We have multiple options of creating relationships among tables. My favorite is drag and drop of Unique-ids in Diagram View of Tabular Model.
4. Deploy Tabular Model solution to a SQL Server Analysis Services (Tabular Instance). Same as SSAS cube deployment on Analysis Services.

For the people who know Power Pivot:

I’ll say, BI Semantic Tabular Model w.r.t. Power Pivot is like Ferrari against Maruti 800 ;). In a correct way, Tabular Model is advanced version of Power Pivot. This advancement can be highlighted in number of ways:

1. A better Visual Studio environment for development instead of old Excel interface
2. Got new server for keeping Tabular Model cubes instead of need for SharePoint Power Pivot Gallery
3. Now get full functionality of a multidimensional cube like Roles and Security

I believe this was a good introduction for the BI Semantic Tabular Model, please comment. We will discuss more about its architecture and benefits over other technologies, in later posts.

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)