1. Sql Saturday 575 sponsors

2. Frontline Analytics | Brett Powell
Ssas tabular 2016
Frontline Analytics | Brett Powell
12/10/2016

3. About Owner, BI Consultant at Frontline Analytics Blogger: Community:
FrontlineAnalytics.net
Blogger:
InsightsQuest.com
Community:
Boston BI User Group
New England SQL Server
Power BI User Groups
@BrettPowell76

4. Goals for this session Maximize SSAS Tabular 2016 Information Delivery
45 minutes for concepts
15 minutes for examples
See the larger picture of SSAS Tabular 2016
Compare to Multidimensional, New Features, Roadmap
New Use Cases: Power BI, Direct Query, SSRS, Azure SSAS
Hands On Practical Knowledge
Upgrade Considerations: Servers, Models, Features
Bi-Directional Relationships, New DAX Functions, Scripting
Areas to Target for Max ROI; Latest SP1 Features

5. agenda Overview of SSAS Tabular 2016 Top New Features
Brief history recap: from SQL Server 2008R2 to Today
Tabular vs. Multidimensional Feature Matrix
SSAS Tabular in context of MSBI and Power BI
Top New Features
Enhanced DirectQuery Mode
Azure Analysis Services (Preview)
Bi-directional Relationships
‘Super DAX’ Performance
New Functions and Variables; Use in Reporting Services
Tabular Object Model and Tabular Model Scripting Language (TMSL)
Processing and Manageability: Parallel Partitions and Extended Events
Upgrading to Tabular 2016
to 1200 Compatibility Level
NUMA Awareness and Hardware
May require more than one slide

6. Ssas tabular and the bI semantic model
The semantic layer (data or not) between BI client tools and data sources
Simplified Model (Tables & Columns, Relationships), Built Into Power BI and Excel Data Models
Optimized for DAX Clients (Power BI); Enhanced Support for MDX (Excel, 3rd Party)

7. SSAS Tabular 2016 Architecture
Formula and Storage Engine work together to resolve queries from client reporting tools
Formula Engine
“The Brains”
Produce Query Plans
Requests data from SE
Evaluates Complex Logic
Only Single-Threaded
Storage Engine
“The Muscle”
Return data caches to FE
Query Results Cache
Simple queries only
Multi-Threaded
Request
Data Caches
Vertipaq Mode (Default) stores data in a compressed, columnar format upon processing from source
Different query plans and performance depending on client tool (MDX or DAX); Power BI is optimal
Prior DirectQuery version was very limited: DAX clients only, SQL Server only, poor performance
Query performance is generally improved via greater utilization and compression of storage engine

8. Inside the ssas tabular model
Models make data usable for analysis; representations of business processes and events
Tables
Relationships
Measures
Hierarchies
Metadata
Table Partitions
Security Roles
Perspectives
KPIs
Display Folders
Model and metrics abstract away complexity
to provide ‘it just works’ experience for users
User only sees relevant content
Usage respects:
Model relationships
Metric definitions
Security rules
Metadata, formatting

9. Historical RECAP OF SSAS TABULAR
SQL Server 2008R2
PowerPivot for Excel 2010
PowerPivot for SharePoint 2010
SQL Server
SSAS Tabular ( )
Excel Data Model 2013
PowerPivot for SharePoint 2013
SQL Server 2016
SSAS Tabular 1200
Power BI Desktop, Excel 2016
PowerPivot for SharePoint 2016
BI Semantic Model
Partitions, Role Security
DAX Language v2
Limited Direct Query Mode
On-Premise Only
Enhanced Modeling and Scale
Power BI Desktop & Service
Super DAX & Variables
Enhanced Direct Query
SSAS Azure Preview
Free add-in for Excel 2010
Power Pivot for SharePoint
DAX Language v1.0
Import Mode Only
On-Premise Only

10. tabular or multidimensional (2012-14)?
In general, SSAS Tabular was limited to small to mid-sized projects
Significant effort and complexity required to work around performance and functionality limitations
Reasons to Adopt Tabular
Rapid, agile modeling relative to MOLAP
Easier to learn language (DAX vs MDX)
In-Memory, Columnar Performance
Migrate Self-Service Models to Server
Align with MSBI Roadmap (Power BI)
Options to Mitigate Limitations
DAX for Many to Many Relationships
DAX for Role Playing; Semi-Additive
Affinitize to single NUMA node
Add-Ins: BIDS Helper, DAX Studio, DAX Editor, OLAP Pivot Extensions
Model and DAX Design Tuning
Reasons to not adopt Tabular
Scale: Need Multiple NUMA nodes
Experienced MOLAP BI professionals
International Users: Multiple languages
Complex Models
Many to Many Relationships
4-5+ Fact Tables, 15+ Dimensions
Multi-Column Relationships
Scoped Assignments, Unary Operator
Parent-Child Hierarchies
ROLAP Option for Real-time Access
Limited Manageability Options (XMLA)
Inefficient DAX Query Plans
Out-of-the-box Features; avoid add-ins
Display folders, Drillthrough, Actions

11. tabular or multidimensional (2016)?
SSAS Tabular 2016 is capable of meeting scale and complexity requirements for large enterprise deployments
Valid reasons remain to use Multidimensional; effective multidimensional models don’t need to be migrated
Reasons to Adopt Tabular 2016
Prior Reasons Still Valid:
Rapid, agile modeling
In-Memory, Columnar Performance
Align with MSBI Roadmap (Power BI)
Easier to learn language (DAX vs MDX)
Migrate Self-Service Models to Server
Scalability
NUMA Scheduler in SP1
Parallel Partition Processing
Improved DAX Query Engine
Support for Complex Models
Bi-Directional cross-filtering (M2M+)
Tabular Model Explorer, Display Folders
Viable Direct Query Option
New DAX Functions (50+) and Variables
Translations
Cloud Deployment Option
Manageability: Object Model and TMSL
Reasons to not adopt Tabular
Experienced MDX/MOLAP BI professionals
Complex Models
Multi-Column Relationships
Scoped Assignments, Unary Operator
Parent-Child Hierarchies
Out-of-the Box Features
Report Actions
Drillthrough Behavior

12. Upgrading to ssas Tabular 2016
Several top features of Tabular 2016 are available out-of-the box
NUMA Awareness (SP1)
Memory Allocation (SP1)
New DAX Functions and Variables
In-Memory Mode Query Performance
Parallel Partition Processing
DBCC
DirectQuery Mode Performance
Extended Events GUI
New DirectQuery
Data Sources
Several other features depend on upgrading models to 1200 compatibility level
This implies changes to refresh/processing scripts for the new object model
Existing add-ins (e.g. BIDS Helper) not supported in new object model;
Bidirectional Cross-filtering
Tabular Object Model (TOM)
Tabular Model Scripting Language (TMSL)
Display Folders
Translations
Calculated Tables
Improved design experience (SSDT)
Row Level Security for DirectQuery Models
Calculated Columns in DirectQuery Models

13. Bi on your terms: SSAS Tabular in MSBI
Cloud or On-Premises Reporting and Visualization:
Power BI Desktop (.PBIX) is published to Power BI Service or SSRS (vNext) On-Premises
Corporate or Self-Service BI:
Corporate: SSAS Tabular as source for Excel, Power BI Desktop, Reporting Services, 3rd Parties
Self-Service and Pilots: Modeling with Power BI Desktop or Power Pivot for Excel (Built-in Tabular)
Model in Power Pivot for Excel is imported to Power BI Desktop or SSAS Tabular

14. Azure analysis Services Preview
Platform-as-a-service (PaaS)
SSAS Tabular Models Only Currently
Import and Direct Query
1200 Compatibility Level Only
Familiar Development & Admin Tools
Azure Active Directory for Role Security
SSDT to Dev & Deploy Model to Azure
SSMS and SQL Profiler to Manage
On-Premises or Cloud Data Sources
On-Premises Data Gateway
Benefits of Azure Analysis Services
Avoid Managing and Maintaining BI Infrastructure
Elastic Scale: Match Resources to Demand (Available at GA, Not in Preview)
Pay for Use, Pause (pay nothing)/Resume
Speed of BI Delivery: New Instance Within Seconds
High Availability Built-In
Always use latest version of SSAS
Preview Announcement:

15. Azure Analysis Services Use Cases & Roadmap
Predictable Workloads
Schedule High QPU for Peak Query Times
Cloud Data Sources
Azure SQL Database, SQL Data Warehouse
DirectQuery to Cloud Source for Real-Time
Upsize Power BI Desktop Model
Add Partitions, Granular Refresh Control
Scale Up
Use Service Tiers Instead of Performance Tuning
New SSAS Features Available in Service First
Move Gateway Usage to Process Window
Avoid performance impact of gateway on query usage
GA and Future Enhancements
Automated Scale Up/Down, Pause (Started)
Backup & Restore (Started)
Scale Out Azure AS Servers (Planned)
Migrate Power Pivot or PBI Desktop (Planned)
Geo Replication
Under Review
Multidimensional Models
Additional Pricing Tiers
Unified Gateway for reuse by AS instances
Azure SSAS Product Page:

16. Azure Analysis Services Setup
Azure – New – Intelligence & Analytics (or search Marketplace)
Specify Settings
Deploy Tabular model from SSDT
Configure On-Premise Gateway if on-premise source
Connect from SSMS and Power BI Desktop like on-premises SSAS Instances
Create Azure Analysis Services:

17. enhanced directquery mode
Performance
Fewer and much more efficient SQL Queries generated
Benefits from ‘Super DAX’ – Redundant Join Elimination
Partial Cache in SSAS
New Data Sources Supported
Oracle, Teradata, APS, Azure Sources
MDX and Client Tool Support
Excel, 3rd Party Tools
Full DAX function Support
Not all Functions Optimized
Create Row Level Security Roles (1200 CL Only)
Calculated Columns in Model (1200 CL Only)
Option to Configure Referential Integrity Property
Ref Integrity = True: Inner Join SQL Queries
Ref Integrity = False (Default): Outer Join SQL Queries

18. DirectQuery or in-memory?
Choosing In-Memory (Default) vs DirectQuery mode depends on many factors and priorities
Benefits: Real time access to source, eliminate extra data layer and movement
Cost: Not as optimized for performance and analytics, more limited MDX client support
See attached paper and links below
In-Memory: Pros
Compressed, Columnar Data Store
Option to apply logic in data load
More Data Sources Supported
DB2, ODBC/OLE DB, Excel, Access, more
Option for multiple data sources per model
Full DAX Functions and MDX Client Support
Calculated Tables
DirectQuery: Pros
Leverage relational data warehouse
Columnstore Index, MPP Appliance
Data Freshness and Version Control
Latest transactions reflected
Avoid Overhead and Admin Costs
Security Options: Data Source or Model
In-Memory: Cons
Hardware Requirements
Partition Design and Processing
Server Admin & Monitoring
Version Control
Data Freshness
xVelocity knowledge required
DirectQuery: Cons
Limited Data Sources
Single Data Source
One relational database per model
Performance Dependent on Source DB
Some DAX functions not optimized
User Hierarchies not visible in Excel (MDX)
SSAS DirectQuery Mode:
DAX Function Compatibility in DirectQuery:

19. Top Import vs Directquery questions
Do we have an optimized and supported data source?
Columnstore index, Analytics Platform System, Teradata
Do we have a usable data warehouse?
De-Normalized, Conformed dimensions; Star Schemas
Is significant additional logic applied at the cube or reporting layer?
Do we need or currently use non-optimized DAX Functions?
Many common DAX functions not optimized for DirectQuery
See attached list of non-optimized functions
How valuable is data freshness/update?
What is the refresh ‘lag’?
How will fresh data be used?
How complex/costly is maintaining import mode?
Can this be improved (PowerShell, TMSL)?
Potential DirectQuery Use Cases
Early Stage of BI Project
Get started quickly; POC
Data profiling
Operational Analytics
In-Memory, Columnar OLTP
‘Right now’ Decision Support
Disparate or Temporary Source
Not likely to be integrated to data warehouse
Alternative to LOB reporting and ad hoc queries
Primary Analytical Source
Leverage DW Investment
Replace import cubes
Drive version control
See DirectQuery Restrictions:
DAX Function Compatibility in DirectQuery:

20. Super dax: it’s just faster now
SSAS Tabular 2016 will dramatically outperform prior versions out-of-the-box (Super DAX Details)
Enhancements applicable to Import and DirectQuery Modes
Power BI generates optimal queries; same query will generally require fewer storage engine scans
Implication: No model or query tuning needed to see performance benefit.
Note: Still value in sound modeling and query design, see sample results
Measure Fusion: Single storage engine query for many measures from same table
Implication: Safely use tooltip feature in Power BI; Multi-Measure DAX queries generally
Strict Evaluation: Only true branches
Implication: Safely use IF and SWITCH Only true condition results in storage engine queries
Grouping Sets: Single query at bottom level of grain is used to support higher level
Implication: Hierarchy-based queries are less expensive than prior versions
Join Orders: Evaluation uses most restrictive intermediate table first
Implication: Not necessary to re-factor query to drive optimal order of filtering
Redundant Join Elimination: Single storage engine query returns columns and measures

21. Performance improvement Example
Upgrading an existing 2012 Tabular model to 2016 resulted in a 50% reduction in duration
V versus V2 2016
Modifying the Model resulted in dramatic improvement for 2012 and 2016
V2 re-design focused on column compression, segment elimination, and relationships
No further changes in model granularity or query, 1103 Compatibility (No bidirectional)
Query #4 Fact Table was outside of scope of v2
V1 included DAX query optimizations.
See blog post:
Takeaway: 2016 can significantly improve performance but model and query design still matters
V Q1
V Q1
V Q1
2016 generates fewer storage queries to return same result set

22. new dax functions and variables
Exclusive to Power BI, SSAS Tabular 2016, and Excel 2016
Used by Power BI visuals to drive greater performance
See Demo (.DAX File)
VARIABLES
Store scalar value or table in a variable and reference in expression
Leverage single evaluation multiple times to improve performance
Set Based Functions:
INTERSECT, EXCEPT, UNION
Query Language:
SUMMARIZECOLUMNS
NATURALINNERJOIN, NATURALLEFTOUTERJOIN
DATEDIFF
ISEMPTY
New STATS Functions
New MATH Functions
New Functions:

23. Reporting services integration
New DAX table functions and variables make SSRS integration more feasible
Reporting Services GUI still generates MDX queries; can pass DAX from DMX Editor
Can leverage enhanced parameters in SSRS 2016 with DAX variables in SSAS Tabular 2016
See sample datasets in demo and .DAX file

24. Bidirectional cross-filtering
Bidirectional cross-filtering enables filter context to flow to both sides of a relationship
Removes complexity and performance penalty of DAX-based approach to Many-to-Many
Provides additional analysis capabilities, see whitepaper by Kasper de Jonge
Currently exclusive to SSAS Tabular and Power BI Desktop; Power Pivot may support in future
Model must maintain single, unambiguous filter path
Exclusive to 1200 Compatibility Level Models
See Demo
Recommended Practices
Implement Bidirectional Relationships Selectively
Not Default, Not for all relationships
Never apply with date dimension
Can use CROSSFILTER() function per measure to control filter propagation

25. Tabular object model and scripting (TMSL)
For new or upgraded 1200 Compatibility Level Tabular Models:
Tabular Object Model replaces multidimensional taxonomy (ie tables instead of dimensions)
Tabular Model Scripting Language (JSON) replaces XML-based Analysis Services Scripting Language
Can continue to use XMLA in SSAS 2016 for Models
Upgraded Model
Benefits of new object model and scripting language:
Simplified scripting and development tasks
Very fast model update operations (ie new metrics)
Simple code merges
New Tabular Object Model
API, part of AMO
Database
Model
DataSources
Tables
Partitions
Relationships
Roles

26. Parallel partition processing
SSAS 2016 Tabular Server Instances process model partitions in parallel
Default behavior; optionally configure custom parallelism with TMSL (1200) or XMLA ( )
Support for 1100 and 1103 Models
Reduces processing/refresh times and/or process more data in same window
See TMSL Samples in Demo
Performance Tips
Avoid ‘Over-Partitioning’:
Each partition has its own segment(s)
1 CPU Core per Segment
8M Rows per Segment (Default Setting)
Over-partitioning reduces compression and increases cost of aggregating Thread Results
Sort Partitions by Common Relationship Column(s)
Can improve compression of sorted columns
Fewer segments scanned for common queries
Examples: SalesDateKey, StoreID

27. Options for implementing tmsl
PowerShell Scripts
Existing and new cmdlets for Tabular 1200
Invoke-ProcessASDatabase
RefreshType for 1200 CL models
Invoke-ProcessTable excusive to 1200 CL Only
SQL Server Integration Services (SSIS)
SSAS Execute DDL Task accepts TMSL Commands
SQL Server Agent Services Jobs
Store TMSL commands in XMLA Files
TMSL Command Reference
Sequence command to control batches of operations
maxParallelism property to control sequential or parallel

28. Calculated tables
DAX table functions to compute and persist a model table based on other table(s) in the model
Use Calculated Tables like any other table: Relationships, Metrics, Hierarchies
Possible Use Cases
Role Playing Dimensions (ie Date)
Simplify support for complex metrics
Pre-Aggregated Table for improved performance
Exclusive to 1200 Compatibility Level
Like calculated columns, calculated tables should be used very selectively
SQL-based approach usually available, more sustainable option
May have M/Power Query option for SSAS in next release (
Test to confirm performance

29. Display folders
Display Folders to logically consolidate metrics and columns
Simplify browsing experience for large, complex models
Create folders and subfolders (Folder\Subfolder)
Column folders alongside hierarchies
Exclusive to 1200 Compatibility Level
Replace dependency on BIDS Helper Add-In (if used)

30. Tools for ssas tabular 2016

31. SQL Server Data Tools for Visual STudios
SSDT for Visual Studio (and SSMS) now separate download
Updated Monthly with New Features
Metric authoring improvements
Rich Intellisense, Comments, Formula Fixup
Alternative to measure grid coming in future release
Tabular Model Explorer (1200 Models Only)
Model hierarchy to easily browse objects
Display Folders (1200 Models Only)
Logically group metrics and/or columns into folders l
Integrated Workspace Server
Avoid dependency on workspace SSAS server
Internal instance of SSAS (64-bit) in VS
Workspace Retention: Unload from Memory
Download SSDT for VS 2015:

32. SQL Server Management studio
SSMS now a separate download from SQL Server
Updated monthly like SSDT for Visual Studio
Manage 1200 and Prior Models
Script TMSL for 1200 Models
Processing and DDL Commands Supported
Save as XMLA files and use/modify in other tools
Access new Extended Events Interface
Minimal DAX Authoring Support Currently
Write DAX in MDX files, Minimal Intellisense
Browse GUI still Multidimensional
Download SSMS:

33. SQL Server Profiler and extended events
Extended Events GUI Available for SSAS Instances
Additional events supported beyond SQL Server Profiler
Lightweight alternative to SQL Server Profiler
Three storage targets for xEvent data:
Event_Stream: Live event data streaming
Ring_Buffer: In-Memory of SSAS Server
Event_file: XEL file on disk
XEvents Instead of Profiler (for SSAS)?
Maybe
Need to run trace sessions against prod?
Comfortable with XEL files, XML Functions
Align with Product Roadmap
Maybe Not (Yet)
Profiler still officially supported for SSAS
Extra events of limited value
Can’t stop XEvent session; have to delete
Avoid XML; save to SQL table from Profiler
Can limit # of events traced, apply filters
SSAS Team Blog:

34. DAX Studio Full DAX Authoring Experience: Model Connectivity:
Intellisense, DAX Formatter, DAX Function Library
Model Metadata and Dynamic Management Views (DMVs)
Model Connectivity:
Connect to SSAS Server, PBI Desktop and Power Pivot Models
Direct Query Mode Supported – View SQL Queries sent to sources
Performance Tuning: Trace Events and Analysis Built-In
Currently individual .DAX files
Not Solutions/Projects
Download DAX Studio:

35. Appendix: ssas tabular Modeling and dax

36. WHAT IS dax? Functional Programming Language
Functions return scalar values and tables from data models
Used by Power BI, SSAS Tabular, and Power Pivot for Excel
Analysis Language; Read Only
Metrics and Queries Evaluated at Query Time
Optionally persist DAX tables & columns at Process Time
Primary Objectives for Developing DAX:
Accuracy: Expected Behavior in all contexts
Speed & Scale: Efficient use of model & engine
Sustainable: Standard patterns, readability
Five High Level Questions:
Are we using DAX for analysis work? (not ETL)
How will the expressions be evaluated?
Self-Service, Local Query, User or Role Specific
What Storage Engine will service our queries?
Relational Database, SSAS Tabular?
Are our critical metrics and queries efficient and scalable?
Is our DAX Sustainable?

37. DAX Architecture: Query Evaluation Process
Formula Engine:
Main Function: Generate Efficient Query Plans
Single Threaded but fully functional – can handle all DAX functions
Storage Engine
Main Function: Produce Data Caches for the Formula Engine (Quickly)
Stores cache of previous query result sets
Multi-Threaded but limited to simple functions and relationships in the model
DAX Query Evaluation Process: Import Mode or Direct Query Mode
Received by the Formula Engine from Client Tool
FE Generates Logical and Physical Query Plan
FE Checks if Required Data is Stored in Cache; Retrieve from cache if available
Sends Requests to Storage Engine – either SQL Statement or SQLml
Storage Engine Dispatches CPU Thread per Segment Needed (if available on CPU)
Data Cache is Returned to Formula Engine for final processing

38. Before dax: Model and hardware
In-Memory Mode Model
Careful selection of row granularity and column cardinality
Analysis of compression and partitioning (8M row default)
Analysis of memory settings and optimal sort order
Direct Query Model
Referential Integrity to Support Inner Join Queries
Simple Views of Source Data for Query Plans
High Performance Source:
Massive Parallel Processing (MPP) Appliance: APS, Teradata, Oracle; SQL Server with Columnstore Index or optimized schema?
Scaling Up and Out:
Preferred In Memory Hardware: 3Ghz+ Clock, 2133 Mhz+ RAM, large L3 cache
Scale Up: More memory and CPU cores to accommodate larger models with more segments
Scale Out: Load balance multiple SSAS Query Servers to address concurrency

39. Build dax on a sound foundation
Sound models and hardware simplify DAX development and tuning efforts
Migrate logic from DAX to Model and from Model to Source System when possible
Leverage storage engine
Leverage efficient/selective filter conditions
Minimize materialization of temporary tables
DAX
Model
Hardware
Limit iterating functions
Avoid FILTER() if possible
Operate on columns
Minimal columns required
Minimal row grain required
Minimal data type precision
Optimize priority columns
Build star schema(s)
Avoid Calculated Columns
Analyze Compression and Partioning
If DirectQuery Mode:
Evaluate hardware and performance of source (Teradata, Oracle, SQL, APS)
If In-Memory Mode:
Consider speed of CPU and RAM, # of Cores if large models, NUMA Awareness on VM

40. Think in terms of column segments
For Import Mode models, data is stored in compressed column segments
1 column segment per CPU Core; 8M rows per column segment (default)
Memory Size of segments and # of segments used in queries drives performance
Model Processing Process
Unique Values of column are encoded, stored in dictionary
Integer columns may be Value Encoded
Sort Order Determined by Model; limited by Timebox setting
Run Length Encoding is performed by segment to compress data
Repeating values are compressed
Each Partition has independent segements
Hierarchy and relationship structures stored and updated separately
Calculated columns are computed; not compressed
Cardinality and distribution of values primarily drive segment size
Can improve compression by increasing segment size; (at expense of longer processing times)
Can drive optimal compression and segment elimination via Order By

41. Ssas tabular model Red lights!
Out of Memory
Over Memory Limits
Queries and processing paging to disk
Model source queries pointed directly to source tables
Processing will fail when source table changes
Disparate Data Types Used for Relationship Columns
Example: Text to Integer can cause failure, errors
Dimension Tables with Duplicate Keys (or potential for dupes)
Relationships require distinct values on one side
NUMA Awareness: SSAS Tabular Not Numa Aware
Mixed Granularity of Fact Table Rows
Will significantly add to complexity of mode and DAX

42. Ssas tabular model: Yellow lights
Calculated Columns on (large) Fact Tables
Unnecessary columns loaded to model
Decimal Data Type when Currency/Fixed Decimal suffices
Model Table Source SQL used as ETL layer
Layers of views on views, complex logic, CTEs, Unions, etc
Snowflake Schema or Fact to Fact relationships
Limited Tabular Experience, Hubris
Accidental BI, Power User, MOLAP Pro
“It’s in memory, it should be fast”
No knowledge of top/critical queries and columns
Inefficient Partition Sizes reducing compression
Lack of Support for Early Arriving Facts
Silo Model: Different definitions used in other models or reports
FILTER() used inappropriately
Wide ‘Extract Report’ Requirements

43. WHY LEARN DAX?
DAX is now the primary analysis language of Microsoft BI
Author in SSAS, Power BI Desktop and Power Pivot for Excel
Enhanced SSAS Tabular 2016, New DAX Functions and Variables
Azure Analysis Services (Preview, Currently Tabular Only)
Models Are Needed, with or without the data
Simplified Interface, Platform for Self-Service and BI Development
Version Control, Security, Performance, Custom Requirements
Direct Query Now a Viable Option; Leverage DW/Relational Sources
Reasonable Learning Curve
Simpler than MDX; Can benefit from SQL and Excel experience
Target core concepts and functions for accelerated growth
‘Composable’ Functional Language becomes easier to author and understand

44. HOW TO LEARN DAX and ssas tabular?
Write It:
Free Dev Instance
Development at work
Experiment, Test
Analyze It
Explain results
Explain performance
Study It
Start with PowerPivotPro, then upgrade
Read and write blogs
Concepts to Focus on:
Evaluation Context: “Which rows are active to be evaluated?”
Filter Context and Row Contenxt
Context Transition: Row Context to Filter Context
New DAX Functions and Variables

45. Model Design Considerations
DAX Data Types
Two Main Types: Numeric and Not Numeric
Numeric: Can apply DAX functions
Whole Number: 19 Digits of Precision
Fixed Decimal Number: 19 Precision, Scale of 4 (19,4)
‘Currency’ in SSAS Tabular and Power Pivot
Decimal Number: 15 Digits of Precision
Floating point; Approximate
Date: Internally stored as floating point
Integer Part: # of Days after 12/30/1899
Decimal Part: Fraction of day in seconds (1 / (24*60*60))
True/False (Boolean): TRUE = 1, False = 0
Non Numeric:
Text: Unicode String, Case Insensitive
Binary/BLOB: Not Accessible by DAX
Model Design Considerations
Whole Numbers for optimal performance
Value Encoding and Compression
Fixed Decimal instead of Decimal Number if sufficient precision
Avoid rounding errors
Support for larger numbers
Better performance than Decimal
Avoid Implicit Type Conversions
Errors and Performance Degraded
Date Relationships
Ensure all date values or use YYYYMMDD Integer

46. DAX Syntax and operators
Table with spaces: ‘the table’[column]
Table without spaces: thetable[column]
Measure: [My Measure]
Define Measure: TableName[My New Measure]
Column from result set table: [The Column Name]
Type
Symbol
Use
Parenthesis ()
Precedence Order
Grouping Arguments
Arithmetic
+, -, *,/
Basic Arithmetic
Logical
&&, ||
And, Or conditions
Text Concatenate
&
Concatenation of strings
Comparison
=, <>, >=, <, <=,>
Equal, not equal, greater or less than

47. Calculate: most powerful function in Dax
Most powerful, useful, and complex functions in DAX
Same rules and behavior: CALCULATE and CALCULETABLE
Only functions that provide filter context modification:
Add to existing filter context if no conflict with existing
Overwrite existing filter context if conflict
Ignore an existing filter if it exist
See samples in demo
Calculate(<expression>,<filter1>,<filter2>…)
Only <expression> is required
Rules for both functions:
Filters can operate on a single column only or single table
Product[Color] = “White”, Product[Price] > 5
All(Product)
Simple operators only, not measures
Filters evaluated independently; combined in logical AND
Expression is evaluated in the newly created filter context

48. Core Functions to build around
Basic Aggregates
Sum, Min, Max, Average
Countrows, DistinctCount, Divide
VALUES
Return a single column table of distinct values
FILTER
Add an additional filter to the existing filter context
FILTER(<table>,<filter expression>, <filter expression> )
ALL
Return a table AND Remove filters from the given table/columns
See different versions in sample code

49. Level Two Functions RELATED and RELATEDTABLE Date Time Intelligence
Traverse relationship from Many to One side and vice versa
Date Time Intelligence
Dedicated DAX Date/Time functions for standard calendar
Compose Functions to work with Custom/Financial Calendar– FILTER and ALL
‘X’ Iterators
SUM(X) – apply aggregation over a row-by-by calculation
Conditional Logic:
IF, SWITCH, AND, OR
HASONEVALUE

50. filter context in context
What is Filter Context?
“What rows are ‘active’? given….
Table Relationships
(Many to One, Bi-Directional?)
Report Filters at Client Level?
FILTER() or ALL() applied?
Steps of Evaluation Context (Run Time)
Initial filter selections applied to tables (slicers, rows/columns, filters)
CALCULATE alters initial filter context if applicable (add/remove/modify)
Each table is reduced to a set of active rows
The active rows traverse relationships to filter other tables
Arithmetic of the measure is evaluated against this final set of rows