Probable Script Logic error

Question

Hi,
I am trying to create a simple demo with the following business process:
sales unit * sales price = total sales
salesunit + inventory unit = produced unit
produced unit * labor per unit = total hours
for "sales unit x sales price = total sales", i have created a script logic called "sales.lgf" as follow:
*xdim_memberset account = salesunit,salesprice
*when account
*is salesunit
  rec(account="totalsales",factor=-1(get(account="salesprice")))
*endwhen
*commit
for "salesunit + inventory unit = produced unit", i am using dimension logic of salesunit + inventory unit in the formula column of produced unit
for "produced unit x labor per unit = total hours", i have created another script logic called "production.lgf" as follow:
*xdim_memberset account = producedunit,laborperunit
*when account
*is producedunit
  *rec(account="totalhrs",factor=(get(account="laborperunit")))
*endwhen
*commit
in my default.lgf, i have *include sales and *include production
The results are satisfactory for all of "totalsales" and "producedunit".
But for "totalhrs", it appears as if some results are correct for some but wrong for the others.
any idea on this?
cheers

Answer 1

Dimension formulas are evaluated in the cube, when you query that particular member on which you placed the formula. Aggregated members (parents) are pretty much the same story. (MSAS does some caching & pre-aggregation of things but don't get hung up on this; it's DB technical stuff.) The key point is, the result of a member formula isn't stored in the fact tables.
The big performance gains come from minimizing the number of unnecessary commits -- not so much by minimizing the # of members in your xdim_memberset.
In your first example, this still can be written in one commit. Think of the algebra in the second commit, and break down the components until you get to the source data that you have available before you start the calc.
*xdim_memberset account = salesunit,salesprice,inventoryunit, laborperunit,laborcostperhour
*when account
*is salesprice
*rec(account="totalsales",factor=-1*(get(account="salesunit")))
*is salesunit, inventoryunit
*rec(account="totalhrs",factor=-1*(get(account="laborperunit")))
// not exactly intuitive, but it should work
*rec(account="totallaborcost",factor=-1*(get(account="laborperunit")) * (get(account="laborcostperhr"))
*endwhen
*commit
I wouldn't go through the effort of doing this when you first start writing SQL logic, because it makes it very hard to follow, and debug. If the logic takes 15 seconds to run with 2 commits, and it is legible, that's fine. Only if you find your logic takes 5 minutes or 30 minutes to run, then it's worth getting into this kind of optimization.
It's also key to consider everything that you want to calculate in one batch, from start to finish. Sometimes by organizing things in certain orders, you can minimize the total number of commits, by expanding the source data region to include an extra 5% or 10 or 50% of records, beyond what you need in your calcs -- but this may be acceptable. The only real way to know is to test a few different approaches (on a reasonable set of production data, not dummy data in dev) and see which works better.