I have discovered lately that I have a chasm trap in my universe. As it is recommended, I used a context for each side of the chasm trap.
The problem is resolved and the amounts are appearing correctly. The prblem is, once I added the two contexts, Web Intelligence is no more accepting some objects from conext one to be added in the same bloc with objects from context two.
actually, the synchronisation is made by the universe as it merge between context1 and contxt2 automatically every time we shoose two objects from the two contexts. So always there are only one query that is created.
You have fixed the problem, and now you want to break it again?
When you have a chasm trap you need to fix it. Once you fix it, you can safely use measure objects from either side of the chasm trap without issues. However, dimensions on either side of the chasm trap (as opposed to those that might be shared by the “central” table) cannot be put together as they have no valid relationship.
Let me explain the data and you will maybe find that it is normal that we want to associate mesures from context2 to objects from context1:
I have matters. Every matter have it’s invoices and it’s players. a Matter have about 4 players every time but he can have so many invoices. Let say that, for one matte, the invoice amount is 3000$ so normally the user would like to see a line like this:
Matter | 3000$
Now he would like to see something like this:
Matter | Player1 | 3000
Matter | Player2 | 3000
Matter | Player3 | 3000
Matter | Player4 | 3000
sum for the matter |3000
the problem is that without contexts this is the info that he will see if he bring the players in the query:
Matter | 12000$
using the players object in the bloc:
Matter | Player1 | 3000
Matter | Player2 | 3000
Matter | Player3 | 3000
Matter | Player4 | 3000
sum for the matter |12000
I then introduced a context for each side and I m getting what I need.
The problem that I m facing now is that ,if I add any other object (invoice currency for example), Web Intelligence will not accept to put this new object in the bloc an will say that they are incompatible.
A matter can have multiple invoices, and a matter can have multiple players. Do I have that right?
Assuming I do, what do you expect to see with this data? I have a single “matter” which has three invoices and two players. Invoice 1 is for player 1, and invoices 2 and 3 are for player 2. Invoice 1 and 2 are in US Dollars and invoice 3 is in Euros. Now show me how you are going to correctly summarize that data in a way that makes sense.
Currency type is only associated with an invoice, and therefore has no relationship to the player. That’s why you’re not able to bring the two together.
I know invoices are linked to matters. You missed my point. What happens if you have multiple invoices with different currency types for the same matter? How will you pick which one to show?
Normally the invoice amount is 3000$. so adding the matter in the bloc should keep it a 3000$. also, adding the players should give 3000$ for each row. It’s normal because ther is no relation between players and invoices. It’s between invoices and matters.
In my opinion, what you are asking for is completely wrong, inaccurate, and misleading. That being said…
You will need to go back and undo your chasm trap fix, which will then allow you to combine the dimension objects that you want to combine. Then create an alias for the invoices table. Make sure that the only objects from the alias are measures. Finally, set up one context that includes the matter, player, and original invoice table. Set up a second context that includes matters and the invoice alias table. Try that, and see if it gets you what you expect to see.
As a matter of opinion, I would never personally sign off on a universe that worked like this. It’s just wrong. It may be what is being requested, but part of the job of the universe designer is - again, in my opinion - to ensure that people get the correct answer, as opposed to the answer they think they want.
Let me chime in since I think I have the same problem as zizou. I also have a chasm trap in my universe. I have three tables Degree >- Alumni -< Gifts. An alum can have more than one degree, they can also have made more than one gift. If I create a separate context for each then I cannot combine dimensions from both degree and alumni with gifts data. So if I want a list of alumni gifts from alums who have an engineering degree I end up with two blocks in my report, one a list of people with engineering degrees, and another of people who have made gifts, neither of which is what I want. What I should be able to get is
Name Major Gift Amount
Bob Baylor EGR $100
Without the context the gift amount is multiplied by the number of degrees the alum has.
Am I thinking about this the wrong way?
I’ld say you ARE thinking the wrong way,
see this example;
What if Bob had another degree and another gift, then what goes where?
Name Major Gift Amount
Bob Baylor EGR $100
Bob Baylor XXX$150
Bob Baylor EGR $150
Bob Baylor XXX $100
That exactly is your chasm trap, so you end up with a cartesian product,
because you don’t know to what Major the gift amount applies!
(Rightly so, because there IS no relation)
I’m sure this is NOT what you want.
What then is valid; two blocks of data (the default like you described) One says
Name Major
Bob Baylor EGR
Bob Baylor XXX
and the other
Name Gift Amount
Bob Baylor $100
Bob Baylor $150
Or a section on Name (the common dimension) and a block per chasm end;
Name Major Gift Amount
Bob Baylor EGR $100
XXX $150
So the Name/Bob Baylor is the section master cell,
the Table Major is positioned to the right of that
and the table Gift Amount to the right of that.
Note that the two tables are independent,
you can have as many lines in either of the tables that are needed.
I’m guessing this IS what you want.
It will total the gift amount per graduate without multiplying,
because you solved the chasm trap using contexts…
(BOB member since 2008-07-31)
(BOB member since 2007-08-02)
(BOB member since 2002-08-15)
(BOB member since 2005-01-06)
you ARE thinking the wrong way,
(BOB member since 2002-08-20)