Tabular Model doesn’t support Data Mining

“BI Semantic Tabular Model doesn’t support data mining”. If you want to implement data mining same as Multidimensional Model (SSAS). . . . here is a break . . . this is not possible. Reason for this is Multidimensional Model (SSAS) and Data Mining model is work on OLAP (Online Analytical Processing) architecture but if you deal with Tabular Model, it is same old relational modeling (just termed as In-Memory and DirectQuery).

Hope, Tabular Model will capture Data Mining as one of it’s assets in next release. Increasing popularity of Tabular Model need to have this additional feature to run in a long term.

Along with Data Mining, there are few other features provided in Multidimensional Model but lacking in Tabular Model solutions under Visual Studio 2010 interface.

Few popular ones are:

1. Actions: Additional tab in Multidimensional Cube designer, which allows few triggers in cube development. Tabular model doesn’t have this feature. 😦
2. Aggregations: Tab in Multidimensional Cube designer, which allows additional aggregations to the cube database. Tabular Model lags in this feature.
3. Custom Assemblies: We can add reference of custom assemblies in Multidimensional Cube but Tabular Model doesn’t have this flexibility.
4. Many to Many Relationships: We have direct option for adding many to many relationships in Dimensions and Facts for Multidimensional Cube design. This is one of the option but in Tabular Model we need to do some DAX manipulation for this implementation else no direct way.
5. Translations: Again a direct option in Multidimensional Cube designer but lack in Tabular Model designer solutions.

Cube Browsing

Most of the time Cube Browsing is imagined as a Hi-Fi Technical stuff. Well, for the people from BI background takes it as nothing but still for people who are new to BI, it’s difficult to understand all the parts of Cube Browsing. Browsing is always easy with some drag and drop stuff as per the requirements. But different terms used for fields and items present in browsing page is difficult to remember. Let us make a note of important items in Cube Browsing.

Different Areas in Cube Browsing:

1. Object Explorer:
   • It is your Object browser, where we can see different multidimensional databases available. It keeps the connection from different servers and databases. Basically we right click on any multidimensional database here and select Browse option to see other areas.
2. Metadata Pane:
   • A place where whole architecture of a Cube can be viewed (and used for browsing). Metadata pane lists different items required for cube browsing. At a time we can see one Cube in Metadata pane.
3. Browsing Area:
   • This is the place where actual fields from Metadata are dragged and dropped to visualize different measures w.r.t. dimensions.  We can drag Attributes, Hierarchies, Attribute Hierarchies, Measures, KPI (explained below) in this area for viewing data.
4. Filter Area:
   • While browsing the cube fields we always need some filter, some parameters to introduce slicing of data browsed. We can drag Members here or else follow below steps to filter data:
     1. Add a dimension under Dimension section
     2. Select Attribute Hierarchy to be used in dimension
     3. Specify Operator (Equal, Not Equal, In etc.)
     4. Select member from the list of members in this Attribute Hierarchy
5. Calculated Members Area:
   • We can create some explicit calculation on the fly while browsing the cube and we use Calculated Members Area for same. Here we give a name and formula for the calculation using MDX expressions.

Now let’s see what are different Items dragged from Metadata:

0. Cube:
   • Always first important member of Metadata is cube. It cannot be dragged or dropped, its just to show what is model name of the cube or simply say cube name.
1. Measures:
   • This is a classification which symbolize group of items which accommodate measures/facts in complete cube.
2. Measure Group:
   • It symbolizes set of similar measures. Basically this set of measures is nothing but different calculations for same kind of information. For example, in this diagram we have Internet Sales which cover different measures related in sales though and Reseller Sales measure group for sales done by re-sellers.
3. Measures:
   • These are actual facts or say data that we want to see while browsing. Measures involve real calculations which are done on cube for final viewing in reports. Please look for post Dimensions and Facts on detail definitions of measures.
4. KPIs:
   • A classification which symbolizes group of all the KPI created in cube
5. KPI:
   • Key Performance Indicators, which are actually few calculation done in cube to display health of the business. Basically these calculations involve:
     1.  Status: if the goal is achieved or not, or it’s just neutral. In other terms comparison of Actual and Target values.
     2. Trend: on a timely comparison (let’s say by quarter, year, semester etc.), are we doing good or bad. It’s a comparison of current and previous values based on parameter of time.
6. Dimension:
   • These are real Dimension of the cubes. By definition dimensions are different perspectives on which data can categorized in a Cube. For more detailed theory on dimensions look for the post Dimensions and Facts.
   • 
7. Attribute Hierarchy:
   • Cube creates a hierarchy for each of the Attribute in a dimension. This attribute hierarchy stores all the distinct members of column from dimension table and along with that one additional All member. It depend upon  the design of cube, if we don’t opt for the Attribute hierarchy it will not come else it comes by default.
8.  ‘All’ Member:
   • All member is member in each attribute. As we know cube aggregates the data, basically this All member stores the data at overall level of Attribute i.e. sum of values of measures where this whole column is not considered. For example in set theory (x1, y1, 0) says we are not considering data at z axis and similar is situation of All member as 0 for this dimensional attribute. Again name and existence of All member for attributes is optional.
9. Members (in level):
   • These are possible members of an attribute. Basically these are distinct values in the column of dimension table while creating the cube. In this example these members appear after the All member in a hierarchical structure.
10. Attribute:
    • These are attributes of a dimension and are generated by visible Columns from Dimension table while creating the cube.
11. Members:
    • Same as members explained above, only difference is these members are not child of All member. They have their own identity inside the Attribute (so not in attribute hierarchy).
    • 
12. Hierarchy:
    • This a user defined Hierarchy (not as Attribute Hierarchy), created explicitly in cube to provide hierarchical view of different attributes (which are part of this hierarchy) while browsing the cube.
13. Level (L1, L2 and L3):
    • Hierarchy is based on different levels (as per laymen words), and we can observe different levels of the Geography hierarchy by red squares drawn in the example above. First level is Country Region and represented by one Dot, level 2 State Province by two Dots and level 3 City by three Dots.
14. Members (of level):
    • We can see the members of any attribute, in the Attribute itself under Metadata pane. Same members of an Attribute are available in hierarchy, when we expand the level.

So here we covered all possible items required in cube browsing. Go on and start browsing the cube. Please let me know if anything is confusing.