thought i was beginning to understand fan traps 
but looking at the beach universe there appears to be a fan trap
service_line --< Service–<Reservation line
is that correct?
if it is a fan trap shouldnt it be resolved by putting an alias on the service table?
johnwxyz (BOB member since 2008-01-26)
A fan trap only exists if you have measures at different levels. Without measures, there is no fan trap.
Dave Rathbun 
(BOB member since 2002-06-06)
wouldnt service.price and the reservation_line.future_guests qualify as the two measures necessary to create a possible fan trap?
johnwxyz (BOB member since 2008-01-26)
Price is not a measure. Or at least it should not be. Remember, not all measures are numbers, and not all numbers are measures. 
Dave Rathbun (BOB member since 2002-06-06)
okay thanks
i guess more study is required
johnwxyz (BOB member since 2008-01-26)
As a summary: a fan trap is an issue only for measure objects. (A chasm trap is a problem for all types of objects, but that’s different.) A fan trap can be indicated by a series of one-many join cardinalities, but is not realized until you have measures at more than one level.
Please see this post for a summary with some examples. Hope this helps.
Dave Rathbun (BOB member since 2002-06-06)
HI
i’ve been trying to use alias/context to solve the dimension fan trap problem which is detailed in your 2004 zen and art of universe design presentation.
i have added an alias/context as shown, but get mixed results as shown
is it wrong to apply the alias/context approach in this scenario or have i messed something up in its implementation 
ftrap problem.doc (130.0 KB)
johnwxyz (BOB member since 2008-01-26)
anyone shed any light on this
johnwxyz (BOB member since 2008-01-26)
since Order_Line_Number and Quantity are on different context then Total order, combining them together in one query will retrieve cartesian product. From BO side the fan trap is resolved but it doesn’t show much business meaning.
Marfi 
(BOB member since 2006-12-18)