THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

SQLBI - Marco Russo

SQLBI is a blog dedicated to building Business Intelligence solutions with SQL Server.
You can follow me on Twitter: @marcorus

The Cumulative Total #dax pattern

The first pattern published on www.daxpatterns.com is the Cumulative Total. Another common name of this calculation is Running Total, but the reason why we named the pattern in this way is that we identify all those scenarios in which you want to obtain a value, at a certain date, that corresponds to the result of a number of transactions executed in the past. Usually, this scenario is implemented using snapshot tables in the classical Kimball modeling. With a columnar table, you can afford avoiding the snapshot table even with a relatively large dataset.

You might want to implement the Cumulative Total pattern to reduce the volume of data stored in memory, transforming snapshot tables into dynamic calculation in DAX. The examples shown in the article represent an implementation of the Inventory Valuation at any point in time. Remember, I am not saying snapshot tables can be avoided in Tabular, but you have to consider the alternative, especially when the size of snapshot table is an order of magnitude (or more) larger than the original transactions table. Do some benchmark and find the better solution for your model!

Published Thursday, February 20, 2014 3:29 PM by Marco Russo (SQLBI)
Filed under: , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Rockey said:

Hi ,

thanks for share this information,

I have one question..

I am able to get cumulative value by using mentioned DAX measure... but its give me slow performance...

and my other measure also gives slow performance beacuse those measures are dependent on this cumulative measure...

have you any other idea..

March 4, 2015 5:56 AM
 

Marco Russo (SQLBI) said:

As usually, it depends. You might evaluate how to created aggregated data that speed-up access time by filtering only one date - the point is that the convenience between this traditional approach and the continuous calculation depends entirely on data distribution. Also consider possible optimizations of your DAX code and performance of the hardware you have. The right combination might depend on all of these factors.

March 4, 2015 6:04 AM
 

Germane said:

Hi Marco,

I have a table with 3 columns (Employee number / Date Worked / Hours worked). People have 10-day shifts and it is important for me to know on what day of each shift the person is (from 1 to 10). I do not need a running total of the hours worked.

Let's say that my columns are EmployeeNum and Date and HoursWorked, is there a calculated column to keep that order within the work hitch? The key is that when they go time off, the clock gets reset for that individual and starts counting again from 1 when he gets back to work after the 7 day rest period.

I am very familiar with the EARLIER function but outside of using it to know if the person worked on the day prior, I do not see how it can get me out of the bind?

Am I asking too much from PowerPivot and should look for my solution in SQL?

Thank you.

April 1, 2015 10:24 PM
 

Ben said:

Anyone know how to make this work with dynamic date arguments to get a rolling total for the past three months?

test:=calculate([RejectCount],DATESBETWEEN(DimDate[FullDate],"3/1/2015","3/31/2015"))

April 9, 2015 6:04 PM
 

Marco Russo (SQLBI) said:

Germane, I'm not sure about your requirements. I think you can do what you need in DAX, maybe that you

should use CALCULATE applying a correct filter argument to consider only the previous rows from the

same EmployeeNum and Date less than the current one. Something like:

CALCULATE ( SUM ( t[HoursWorked] ), ALLEXCEPT ( t, t[EmployeeNum] ),

    FILTER ( ALL ( t[Date] ), t[Date] < EARLIER ( t[Date] ) )

)

More logic should be added in order to identify when you want to reset the sum after the rest period.

I hope it helps.

April 10, 2015 7:11 AM
 

Marco Russo (SQLBI) said:

Ben: look at the Moving Annual Total in http://www.daxpatterns.com/time-patterns/ (just use 3 months instead of 1 year)

April 10, 2015 7:13 AM

Leave a Comment

(required) 
(required) 
Submit

About Marco Russo (SQLBI)

Marco Russo is a consultant, writer and trainer specialized in Business Intelligence with Microsoft technologies. He runs the SQLBI.COM website, which is dedicated to distribute resources useful for BI developers, like Integration Services components, Analysis Services models, tools, technical information and so on. Marco is certified as MCT, MCDBA, MCSD.NET, MCSA, MCSE+I.

This Blog

Syndication

Archives

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement