incompatible objects

Thomas Ehret@CHEDSZURICH
01.02.2000 13:47

I want to link two data providers (two selects from the same universe) over one dimension object (article-nr.). But in the slice&dice panel I can only put the measure objects to display not the dimension objects. The documentation from BO writes something about incompatible objects. My questions are:

What objects are incompatible ?

What means ‘incompatible’ ?

How can I make incompatible objects compatible ?

Thomas Ehret.


Listserv Archives (BOB member since 2002-06-25)

In a message dated 00-02-01 07:50:47 EST, you write:

[ snip ]

What objects are incompatible ?

Dimension objects that are not linked.
Detail objects that belong to dimension objects that are not linked.

What means ‘incompatible’ ?

The answer to the somewhat depends on your data. Dimension objects are often “keys”. If you do not link or join the keys, then a cartesion product could result. Imagine the following two data sets:

Resort, Service Line, Revenue

Resort, Year, Number of Guests

BusObj knows to automatically link the Resort since it is the same object in both cases. But the Service Line and the Year are incompatible with each other. They have nothing in common, and therefore cannot be used on the same report.

You can combine Revenue and Number of Guests since they are linked by Resort. Busobj can “roll up” the values to an appropriate sum.

How can I make incompatible objects compatible ?

Sometimes you can’t. Sometimes you can. It depends on the data.

Imagine the following set of objects from two different queries:

Resort ID, Resort Name, Revenue

Resort ID, Resort Address, Revenue

If both the Resort Name and the Resort Address are Dimensions, then busobj treats them as “keys” and they have to be linked or they will be imcompatible. Based on the data, it would be impossible to link these two values.

However, research should show that each resort has only one name and only one address. In other words, linking on the Resort ID is sufficient. The Resort Name goes along with the Resort ID, as does the Resort Address.

Since Resort Name and Resort Address are supporting information for the Resort ID, then those two objects could be changed to details instead of dimensions. After that they are no longer required to be linked, and are no longer incompatible.

In your universe you need to evaluate your objects. If you need to combine data from different queries, you need to be careful which object type is assigned to each value. Many designers use only dimensions and measures because they do not understand (or do not need) this feature.

Key fields, information that can stand alone and should be linked should be dimensions.

Supporting fields, information that does not have meaning on its own should be details.

Numeric fields (for analysis) should be measures.

Each object needs to be evaluated. Hopefully this will give you some ideas.

Regards,
Dave Rathbun
Integra Solutions
www.islink.com


Listserv Archives (BOB member since 2002-06-25)

I bet this is caused by one of the following:

  1. You have 2 contexts. 1 for Inventory, 1 for receipts. You can’t have a measure that crosses contexts.

  2. Inventory comes from 1 table and Receipts comes from another. The SQL Control box (Universe Parameters) is set to “Multiple SQL statements for each measure.” These are "poor man’s contexts. Uncheck the box and the problem will go away.

How many queries are being generated?

Steve


Listserv Archives (BOB member since 2002-06-25)

I ran a test in full client BO and got the correct results. So, I exported the new universe and attempted to run the report that includes the objects that I tested and got the message “incompatible combination of objects”. How can the exact same objects produce valid results in BO and bomb in WebI?

Diane M. Reese
Sr. Business Analyst
Onyx Acceptance Corporation
Tel: (949) 465-3901
Fax: (949) 465-8625
E-Mail: diane.reese@onyxco.com


Listserv Archives (BOB member since 2002-06-25)

Do you have contexts explicity defined?


Listserv Archives (BOB member since 2002-06-25)