BusinessObjects Board

Details about Detail Objects

building reports desktopintelligence
#1

Listeners
Listeners:

Dave Wrote:

Your first clue is the word “Desc”. Any description can generally
become a detail.
Dimension objects “define” the cube, meaning they become (essentially)
database keys. If
you have a one - one relationship (each code has exactly one description)
then
the “attributes” of the code (like description) can be set as details.

Then, once you link the CODE object to its matching value from the other
data provider,
you can use the detail (DESC) along with it. The details are associated with
a dimension,
and are valid anywhere that dimension is.>>>>

Me:

Are there any documents on Detail Objects & their usage. ?

I have one more question.

If we Link Code Object to Code object from the other data provider , if we
pull in the detail objects in one data provider , it need not be in the
other data providers?
Am I right?

The problem is that we have some 4 data providers in a particular report .
We have all the dimension in all these data providers.(While some of them
could be “Details”) We are thinking if we make some of those dimensions as
details , could we have them in one of those data providers and remove them
from the other data providers??

r_kishore (BOB member since 2002-08-20)

#2

Yes

Steve Krandel :us: (BOB member since 2002-06-25)

#3

Steve

Thanks

Are there any docs about detail objects , their advantages & use?

r_kishore (BOB member since 2002-08-20)

#4

I have never come accross a good document on Detail objects. Personally, I don’t use them very often. There are a few limited times that they make alot of sense. They are great for descriptions.

Do a search on BOB for detail objects. I think Dave Rathbun has some good insights here.

I’d like them alot more if I could make them be tied to a dimension object, but not be indented underneath the dimension.

Steve Krandel :us: (BOB member since 2002-06-25)

#5

If you never use drilling, and you never use linked data providers, then details are wasted in your universe. :wink:

Details are designed so that you don’t have to do a lot of work defining custom hierarchies if you don’t want to. Any detail objects in your classes won’t be drillable, by definition. So, using Island Resorts as an example, in the Customer class you have Country of Origin, Region, City, and Customer as dimension objects. They define a hierarchy. The customer detail objects Age, Phone Number and Address are automatically not drillable, and probably shouldn’t be. If they weren’t details, you would have to define a custom hierarchy to eliminate those items (like they did for Age Group) and keep them from being drillable.

Details are also designed so that “extra” information doesn’t get in your way when you are using linked data providers. Suppose you like DP1 and DP2 together; every common dimension must be linked, and unlinked dimensions can’t be used.

Suppose you have Customer ID (Dim), Customer Name (Dim), and Customer Phone (Dim) from one data provider. Next, you have Customer ID (Dim) and Address (Dim) from another data provider. For the sake of this example, assume only one address. :wink:

Now you can link Customer ID -> Customer ID, but that’s really the only item in common. Since you can’t link Phone and Address, you can’t use both of them in the same block. You get “Variables are not compatible” instead.

But if Phone is a detail of customer, and Address is a detail of customer, then once you link customer, details are freely usable anywhere. That’s ultimately what details were designed for, I think.

It’s like working with each cube as a miniature database, which is really what it is. Dimensions are keys, and keys must be linked to other keys to avoid a cartesian product. Details are attributes, and once their parent key is linked, they can be joined / used in a common (combined) block without any problems.

Note that some objects may require both; you may want to be able to drill on a date field on one report, and use it as a detail object in another.

As Steve said, there is an extra step required to “reveal” detail objects. If you are using linked data providers, the advantages overwhelm that extra step, in my opinion. Otherwise you have multiple extra steps that are required on the report in order to “demote” a dimension to a detail for use on each report.

I did an entire one-day session on this at the prior user conference. We haven’t posted that material on our web site as we keep thinking we’ll add it to our training curriculum as a one-day addendum to the designer class.

Dave

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

Problem with links between two data providers in a report