"Average" aggregation of sparsely populated percentage values - ssas

I have cost center allocation data that is currently fully populated, one record per day, each with one cost center dimension key. The cube has a head count measure (the data is set to "1"), and the aggregate function is set to "LastChild". This means that a head count report will count a person only once in a cost center in any given time period.
Introducing partial allocations - a new measure will have a percentage value for the allocation, allowing for multiple concurrent cost centers where the allocation should add up to 100% (with "day" being the granular level). I am trying to figure out how to configure the aggregation over other time periods. I thought that "Average" should work just fine, i.e. a person who is allocated to a cost center at 50% for half the time period will be reported at 25% for that period.
The problem that I see is that my facts are not populated for days where the allocation to a cost center was 0%. To illustrate:
Employee1 CostCenterA 1/1/2013 50%
Employee1 CostCenterB 1/1/2013 50%
Employee1 CostCenterA 1/2/2013 100%
Employee1 CostCenterA 1/3/2013 100%
... etc with 100% in CostCenterA for all days
The above data on a report by month shows 50% for the allocation to CostCenterB, even though the person was only allocated for one day, and the average percentage on a monthly basis should be 1.6%.
I suppose I could generate the 0%-allocations in the data, but my fact table would explode as a result, so I'd much rather change how the "average" aggregation treats percentage values in facts that are sparsely populated, i.e. the average should be calculated based on the number of granular units in the reporting period (days in the month, in this case 0.5/31), not the number of rows in the fact table (0.5/1). Can this be done in SSAS?

If the measure with the average allocation is off by a factor that is proportional to the "sparseness" of my facts, i.e. the ratio of days in a period and actual fact rows, then it can be corrected as follows:
adjusted average allocation =
(calculated average allocation) * (fact count)/(number of days in period)
I created two new hidden measures, one named [Fact Count] for the fact count (a measure using the AggregateFunction "Count") and a calculated measure named [Days In Period Count] for the number of days, using the expression
COUNT(Descendants([Date].[Calendar].CurrentMember,5),INCLUDEEMPTY)
with [Calendar] being the name of the hierarchy in my Date dimension.
Finally, I added a calculated measure that implements the corrective formula:
[Measures].[Allocative Head Count]/
(
[Measures].[Days In Period Count]/[Measures].[Fact Count]
)
and named it [Adjusted Average Allocation]. This I can now use in reports and it appears to somewhat approximate the average cost center allocation over longer periods.
The formular for [Days In Period Count] btw does not work for the row totals when filters are involved. I opened another question for this.

Related

SSAS MDX Calculation - Sum based off a group value

I work for a hotel company and I have set up a fact table with the granularity of a stay night for each guest, e.g. if a guest stays for 3 nights, there would be a row for each night of the stay.
What I am trying to do is create a measure for the occupancy percentage (rooms booked divided by available rooms).
I have a column in the fact table that says how many rooms the hotel has, but just summing up that value doesn't work because then it is just multiplying the number of rooms by the number of guests. So I need to sum up the total guests and then divide by the number of rooms that that particular hotel has. Does this make sense?
[Measures].[On The Books] / [Measures].[Rooms Available]
The SQL for this would this:
SELECT stay.PropertyKey, prop.RoomsAvailable, stay.StayDateKey, COUNT(stay.Confirmation) AS Confirmation,
CAST(COUNT(stay.Confirmation) AS DECIMAL(13,9)) / CAST(prop.RoomsAvailable AS DECIMAL(13,9)) AS OccupancyPercentage
FROM dbo.FactStayNight stay
INNER JOIN
(
SELECT DISTINCT PropertyKey, RoomsAvailable
FROM dbo.FactStayNight
) prop
ON stay.PropertyKey = prop.PropertyKey
GROUP BY stay.PropertyKey, stay.StayDateKey, prop.RoomsAvailable
Your fact table is good, apart from the column with total number of rooms. The fact row is at the granularity level "Room", but the total number of rooms is at granularity level "Entire Hotel".
(You can imagine a "Real estate assets" hierarchy dimension, assuming you don't have one:
Hotel
Floor
Room
)
Possible solutions:
Add a "number of rooms" available in your Date dimension, at the Day level (strictly, "Night" level). This will sum commensurably with COUNT(Guests staying on that day). You could even adjust this number to reflect e.g. rooms under repair in particular periods.
You could implement a Room dimension, with each guest's Fact_NightStayed assigned to a Room. Then make what is technically called a "headcount" table, just like your Fact_NightStayed. But this table would be a "roomcount" table: a row indicates that a room exists on a particular day (or, if you decide, that a room exists and is usable i.e. not broken/being repaired). Pre-populate this table with one row per room per date, into the future up to a date you decide (this would be an annual refresh process). Then, joining Fact_NightStayed to Fact_RoomCount, your measure would be COUNT(NightStayed)/COUNT(RoomCount).
Watch out for aggregating this measure (however you implement it) over time: the aggregation function itself from the Day leaf level up the Date hierarchy should be AVG rather than SUM.

Webi SAP BO Sum in block depending on two dimensions

I am trying to sum every line in a table summarizing it by two fields in webi.
I have a table with the following columns:
Risk, Year, AssessedBy, Weight, Value.
I have filtered the table by Year = 2018 and Risk = "01". Thus, I only have the info for that year and that risk.
Each person assessing has a different weight in the final valuation by risk and year. What I have done is divide the assessing person's weight by the total sum of every Weight in the table [ sum(weight) in block ].
The problem is that when I delete the filter, the in block clause makes that the total sum of the weights changes to the total sum of the weights for every year in the table.
I would need something to calculate the total sum for each year and risk.
Just solved it! Just see Sumal Kunir answer: http://www.forumtopics.com/busobj/viewtopic.php?p=971131
=sum([Var_a] for each(Dimension;dimension)) In (Demension)
where var_a is the measure, foreach defines a background to base in and in defines the level at which you want to aggregate.

Distinctcount - suppliers for departments over a period of time - slow performance

In a model that contains the following dimensions:
- Time - granularity month - 5 years - 20 quarters - 60 months
- Suppliers- 6000 suppliers at lowest level
- departments - 500 departments on lowest level
I need to have the distinct count of the suppliers for each department.
I use the function:
with member [measures].[#suppliers] as
distinctcount(([Supplier].[Supplier].[supplier].members
,[Measures].[amount]))
)
select [Measures].[#suppliers] on 0
, order([Department].[Department].[department].members, [#suppliers], BDESC) on 1
from [cube]
where [Time].[Time].[2017 10]:[Time].[Time].[2018 01]
The time component may vary, as the dashboard user is free to choose a reporting period.
But the MDX is very slow. It takes about 38ms to calculate the measure for each row. I want to use this measure to rank the departments and to calculate a cumulative % and assign scores to these values. As you can imagine performance will not improve.
I have tried to use functions and cache the result, but results - for me - got worse (according to the log 2x as bad).
What can I do to improve the performance?
To go fast adding a measure that calculates de Distinct Count on the Supplier ID of the table associated to[Measures].[Amount] will help. In the Schema definition.
The other ones are not scalable as Supplier is growing.
Nonetheless, why did you use DistinctCount instead of Count(NonEmpty())) ?
DistinctCount is mainly for calculating the number of members/tuples that are different in a set. It only makes sense if it's possible to have two same members in a set. As our initial members have no duplicated, it's useless.
Count(NonEmpty()) filters the set whith the nonempty and counts the number of items in the set. This can be easily calculated in parallel

SSAS custom total for rates (weighting average)

I need to change the total of an interest rate column. I mean, the total in the rate column is summarizing and I need the weighting average instead of the total. for example:
amount..........rate
450000..........8.75
390000..........8
15000...........2
855000(total)...8.29 (weighting average)
I'm trying to do it in the CALCULATIONS tab of the SSAS, but I cannot identify the total level for each group.
Please some ideas, point me to the right direction...
Thanks
JA
I would add a calculation to your source SQL views or DSV to calculate e.g. rate weight = rate * amount. I would then add that as a normal measure, Sum aggregation, hidden once you have finished testing.
Then the SSAS calculation becomes: rate weight / amount (wrapped in the typical Iif function to avoid dividing by zero).
At the leaf levels this returns weight. At any summary level it will return weighted average.

Predictive Ordering Logic

I have a problem and was wondering if anyone could help or if it is even possible to have an algorithm for something like this.
I need to create a predictive ordering wizard. So based on previous sales, we will determine that that a certain amount of an item is required. E.g 31 apples. Now i need to work out the number of cases that needs to be ordered. If the cases come in say 60, 30, 15, 10 apples, the order should be a case of 30 and a case of 10 apples.
The number of items that need to be ordered change in each row of the result set. The case sizes could also change for each item. So some items may have an option of 5 different cases and some items may land up with an option of only one case.
Other examples would be i need 39 cans of coke and the cases come in only 24 per case. Therefore needing 2 cases. I need 2 shots of baileys and the bottle of baileys come in 50cl or 70cl. Therefore i need the 50cl.
The results sets columns are ItemName, ItemSize, QuantityRequired, PackSize and PackSizeMultiple.
The ItemName is the item to be ordered. ItemSize is the size the item is used in eg. can of coke. QuantityRequired how man of the item, in this case cans of coke, need to be ordered. PackSize is the size of the case. PackSizeMultiple is the number to multiply the item with to work out how many of the items are in the case.
ps. this will be a query in SQL Server 2008
Sounds like you need a UOM (Unit of Measure) table and a function to calc co-pack measure count and and unit count measure qty. with UOM type based on time between orders. You would also need to create a cron cycle and freeze table managed by week/time interval in order to create a freeze view of the current qty sold each week and the number of units since last order. Based on the 2 previous orders to your prior order you would set the current prediction based on min time between the last 2 freeze cycles containing an order and the duration of days between them. based on the average time between orders and the unit qty in each order, you can create a unit decay ratio percentage based on days and store it in each slice forward. Based on a reference to this data you will be able to create a prediction that will allow you to trigger a notice to sales or a message to the client to reorder. In addition, if you engage response data from sales based on unit count feedback from the client, you can reference an actual and tune your decay rate against your prediction. You should also consider managing and rolling up these freezes by month, so that you can view historical trending and forecast revenue based on velocity of reorder and same period last year. Basically this is similar to sales forcasting and we are switching out your opportunity percentage of close with Predicted Remaining Qty. percentage remaining.