Comments on: Do I Have a Fan Trap?

By: Dave Rathbun

Dave Rathbun — Wed, 11 Aug 2010 18:57:17 +0000

You have hit on the main problem with the alias + context solution for fan traps; condition propagation. I have been working on a blog post with some ideas but it’s nowhere near ready for publication yet. However, your description doesn’t fit what I would expect to see. Conditions at the distribution level should roll up find to the header level. It’s conditions as the header level that don’t roll down to the distribution level that’s typically the problem.

By: Kerry Green

Kerry Green — Tue, 10 Aug 2010 19:07:55 +0000

I have a fan trap using PO header, PO lines and PO distributions which has been resolved using alias tables. The problem I am having is applying conditions at the PO distribution level. Since BO is creating multiple queries for header and distribution data, the condition on distribution will not be applied to the header query. I have read about using predefined conditions in a derived table, but this is not an option due to too many dimensions which required for filtering. Wondering if there is another solution I have missed. Thanks!

By: Dave Rathbun

Dave Rathbun — Fri, 07 May 2010 19:27:28 +0000

If you only have one fact table you do not have a fan trap. Your challenge is that you don’t have a clean hierarchy, so your week-date relationship might need to be in one context and your year-quarter-month-date relationships might need to be in another. You also can’t really use @Aggregate_Aware() in this situation because your tables are not a hierarchy…

By: thlZ

thlZ — Fri, 07 May 2010 11:06:39 +0000

My scenario is that my fact is at the week level.
My time dimension is a star schema(Calender table).month to week is many to many..so i broke up the table into snowflake…
My time dimension is Year-

If i want to c my data in the fact at quarter level it shd agg. accordingly…. but it is not happening..
How shd my context be….

By: Shiva

Shiva — Mon, 24 Aug 2009 13:03:23 +0000

Thankyou very much for the Reply.

Best Regards,
Shiva

By: Dave Rathbun

Dave Rathbun — Mon, 24 Aug 2009 12:42:27 +0000

Unless you have measures from your bridge table you have no fan traps.

By: Shiva

Shiva — Mon, 24 Aug 2009 05:08:08 +0000

Thanks for the quick response Dave.

Yeah i got it. Thankyou very much for the explaination. One more point if you could please explain the second question of my post ….. I’ll be grateful to you.

Regards,
Shiva

By: Dave Rathbun

Dave Rathbun — Sun, 23 Aug 2009 03:48:02 +0000

Tamir, if you are talking about the example in my post, it would not be solved by an average projection since the data would be wrong coming from the database.

Shiva, the “multiple” is not the quanty of items but rather the count of rows in the items table. If there is one line per header everything is fine. If there are two lines for a specific order, then the budget number for that order will be doubled (multiply by 2). If there are three lines for a given order then the budget for that order will be tripled, and so on. It has nothing to do with the number (quantity) of items ordered on each line. I hope that clears it up.

By: Tamir Bar-Netzer

Tamir Bar-Netzer — Sat, 22 Aug 2009 22:07:52 +0000

Hi,

One of the best ways of solving the example listed above would use Average projection on ‘Total Order Budget’. This is provided that users normally retreive data and not fool around with it (e.g., slice and dice)

Cheers,

Tamir

By: Shiva

Shiva — Fri, 21 Aug 2009 12:28:06 +0000

Hey Dave i’ve a couple of questions for you.

1. I’m not clear with the following part.
By Dave:
select orders.order_id
, sum(orders.order_budget)
, sum(order_lines.order_qty)
from orders
, order_lines
where orders.order_id = order_lines.order_id
group by orders.order_id

The issue is that the line item total (sum) is correct, but the header total budget (also a sum) is way too high. If you look back at the raw data shown earlier, you might notice that the budget amount has been multiplied by the number of line items in the second table.

I tried a similar query in my database it gave me the same answer. now when you are summing the total order qty and total order budget and grouping it,…. it is taking the total qty sold =65 and total budget =2000 for order 1 which i feel is correct….. had it got multiplied then it should have been 32500 under “total order budget” column.

Assuming you have a budget of 500 for each…. 10 pair of shoes, 10 t-shirts, 20 plastic combs and 25 pencils. So that makes your total budget to 2000 for all the item…..

I hope my question is clear.

2. If my datamodel has m:m cardinality between the fact and dimension table… and i happen to use the Bridge table(DW concept) then i get a fan trap as per your first statement which is correct.
Now to resolve this i think i can use context or alias. (please confirm) If yes.. IF i have to choose one among the two (alias /context) which one whould i choose in this scenario… As i feel having alias will increase thenumber of joins in my Universe schema structure.. (the more number of joins the slow may be the performance …) So is it better to use context here or there is any other way to it.

Thanks for the patience in reading it
Cheers,
Shiva