BusinessObjects Board

multiplying measure values => always fan/chasm trap??

building semantic layer
#1

Dear,

I’m suffering a problem in my universe…I freshly created it and it’s based on an RDB model, not a star-scheme unfortunatelly.

I defined some contexts and alias’ed some tables in order to provide clean operation of the universe.

Today I started creating some reports and all went fine untill the measure (yes, ther’s only 1 numeric in the entire report) started multiplying its value from the moment I started adding more tables to the query… :expressionless:

So in the beginning I started from a quite simple query which only contained a table or 3-4…everything ok. Then I added more objects to the query that come from other tables… the dimension objects in the report remain perfect, it’s just the measure that multiplies :crazy_face:

I looked around here and on the net and all I can find is that this seems related to chasm/fan trap…unfortunatelly I don’t see this trap in my universe…so my questions is => is this always related to a chasm/fan trap issue in the universe or can something else be responsible for my weird query behaviour? :hb:

MichM3 (BOB member since 2005-06-07)

Report requires data from 2 fact tables
question regarding fan trap....
Fan trap
#2

I can’t immediately think of a reason for a measure to multiply other than a fan or chasm trap… unless you have a cartesian product. In that case, you would see a warning when you generate the SQL.

Dave Rathbun :us: (BOB member since 2002-06-06)

#3

…read some more info about fan/chasm… if I understand correct, you need at least 2 measures in order to create such issue… I have only 1 measure :?

MichM3 (BOB member since 2005-06-07)

#4

Not really. You can have a fan trap even with 1 measure. Imagine 3 tables, A, B, C:

A --< B --< C

If you have a measure from B and dimensions from A, C in the query then the measure is multiplied as many times as many occurrences of a key from the table B are present in the table C (assuming the join B.key=C.key)

Marek Chladny :slovakia: (BOB member since 2003-11-27)

#5

ok I see… thanks, will do a universe check then :wink:

MichM3 (BOB member since 2005-06-07)

#6

So to avoid fan traps, measures should always be created from the last table in the 1:N, 1:N, 1:N … path/chain of joins.

Setting cardinalities in the universe will help you identify traps more easily.

Marek Chladny :slovakia: (BOB member since 2003-11-27)

#7

In the example Andreas gives above, you would create an alias of B and have two contexts:
A -< B -< Alias_B
A -< B -< C

For objects coming from B, take measures from Alias_B and dimensions/details from B

#8

thanks guys…indeed, there were 2 fan tras in the universe…I solved it by defining a separate context and now the query is split into 2parts.

works fine 8) …measure remains stable

MichM3 (BOB member since 2005-06-07)