views:

28

answers:

1

I must first admit that I'm new to Analysis Services but now must extend an existing complex cube with a new dimension. So its even difficult to tell where my problem is without saying that i dont even have a plan how to start. Ok, i will try to tell what i want to achieve.

Given is a Datasourceview with a named calculation 'Returns'. Its expression is:

CASE WHEN fimaxActionCode IN (1, 2, 3, 4, 5, 8, 9, 12, 14, 17, 18, 20, 21, 22, 23, 24, 25, 30, 31, 32, 35) THEN
 'yes'
ELSE
 'no'
END

fiMaxActionCode is a Foreignkey and the old Rule for 'Returns' was that a Claim(main measuregroup) is a Return when its maxActionCode is one of the above. The new Rule is that a claim is a Return when its maxActioncode is one of the above but without having a previous Claim with fimaxActionCode IN (8, 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37). A previous claim is the TOP(1) claim with the same SSN_Number and with a Repair_Completion_date < this claim. Now my question(hoping that anybody has understood what i mean): How to create this new Dimension? My first idea was to create a new named query 'PreviousClaim':

  SELECT     TOP (1) claim.iddata as ClaimID,PreviousClaim.idData as prevClaimID, PreviousClaim.fimaxActionCode, Claim.Repair_Completion_Date as ClaimRepDate, PreviousClaim.Repair_Completion_Date as PrevClaimRepDate
FROM         tabData AS PreviousClaim LEFT OUTER JOIN
                      tabData AS Claim ON PreviousClaim.idData <> Claim.idData
WHERE     (PreviousClaim.fimaxActionCode IN (8, 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37)) AND (PreviousClaim.fiClaimStatus IN (1, 4, 254, 255, 6)) 
                      AND (PreviousClaim.SSN_Number = Claim.SSN_Number) AND (PreviousClaim.Repair_Completion_Date < Claim.Repair_Completion_Date)
ORDER BY PreviousClaim.Repair_Completion_Date DESC;

Then i wanted to create a new Named Calculation in the Claim-Table-Datasourceview which checks if it has an "irregular-previous claim". Is this the way to go or am i on the completely wrong track??

EDIT: another question: how would i query this named query? Can i define parameter variables f.e.:

AND (Claim.iddata=@ClaimID)

Regards, Tim

+1  A: 

How is this data loaded into the actual Claim dimension (or whatever it's name may be)? The reason I ask is, this task may be better solved by adding this rule during the load process rather than writing an MDX calculated member.

Since you'd have to go back through the data to determine whether the unit has had a previous claim with the fimaxActionCode, which could get nasty with MDX, you could easily separate these out during load time and split them accordingly (i.e., if it has had a previous claim OR has not had a previous claim and falls into one of those listed codes: 8, 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37). Essentially you would be creating a slowly-changing dimension of some sorts since I probably assume these claims also have some sort of time relationship, when did this claim happen if it did, etc, etc.

By tackling the problem through the way I suggested you could utilize the same dimension and just add the additional fields that would denote whether the item was a claim or not and if it did not fall into the "new" Return criteria you would simply leave the record alone.

Make sense?

ajdams
What do you mean with "load process"? The processing of the cube or the process of inserting new rows into the relational database?The database import is a windows service which runs every night, it would be possible to extend it with this functionality. Furthermore there is a stored procedure which is executed every morning before the cube is being rebuilded. That would be a nice place, wouldn't it? Btw, the old Dimension should not be modified and must coexist.Thanks anyway.
Tim Schmelter
@Tim: I would probably say the stored procedure would be the easiest place to make these changes rather than altering the windows service. Since you cannot alter the current dimension (not sure why) then you must add a new key to your FACT table to point to the new dimension populated given the new rules stated in your post.
ajdams
@Ajdams: The old Returns-Dimension should still exist to be able to compare the new return-Rule with the old.I will give the stored procedure approach a try. But that means it would have to update the whole table every Morning(>10Mio Claims)?! Thanks for the hint with the new key in my fact table because i'm stuck with basics in ssas sometimes ;)
Tim Schmelter
I think i will make this Column like a ReturnState(interim return,conclusive return,no return) so i have to check only the "interim returns" in the stored procedure and update them to conclusive return on closing-date(one per month).
Tim Schmelter
@Tim: If there is > 10 Mil rows I would make sure to only update those that have changed. So if that means doing a separate update then do that because that will really slow down the procedure if you just update everything.
ajdams