We have a warehouse with approx. 70 tables. Tables are grouped into
subject areas (8 of them) with some tables being shared among subject
areas. People will view the tables belonging to their subject area. One of
the subject areas has access to all tables. We are thinking of handling in
this in one of these 2 ways:
Using linked universes. Have the subject area containing all of the
tables be the “master” and derive the others from there. Are there any
problems/things to consider with this feature? Will it end up being more
maintenance to have 8 universes to take care of?
One large universe with folders pertaining to each subject area.
Control security via the folders. If any changes are made to a table, it
will have to be reflected in each folder it is located in. But, will this
end up being less maintenance than #1??
We want this to be usable for the users but maintenance is a high concern.
Cori,
We have developed component universes which are linked as required into
different reporting universes. The idea was to minimize having the same
object defined two different ways and to allow any change to automatically
replicate up to the different reporting universes. The universe structure is
primarily built in the reporting universe.
Some of the things we’ve run into are:
The order of the objects by default is not controllable. You have to add a
parameter setting of CORE_ORDER_PRIORITY=Y to the prm file to compensate for
this. Then the objects match the order in the linked universe.
The objects are restricted to the folder they are created in. You end up
with a folder for each component universe which may not aid the user
interaction in building reports. A way around this would be to hide the
component objects and build visible objects that simply reference the
hidden, at the cost of added work and maintenance.
We ran into one instance where one of the components would not download due
to the local copy getting corrupted somehow. This resulted in
BusinessObjects shutting down without any messages. Deleting the local
universes allowed things to operate again.
Migrating between domains and repositories is proving to be trying but I
haven’t seen this as limited to our linked universe strategy.
Using linked universes. Have the subject area containing all of the
tables be the “master” and derive the others from there. Are there any
problems/things to consider with this feature? Will it end up being more
maintenance to have 8 universes to take care of?
One large universe with folders pertaining to each subject area.
Control security via the folders. If any changes are made to a table, it
will have to be reflected in each folder it is located in. But, will this
end up being less maintenance than #1??
We want this to be usable for the users but maintenance is a high concern.
Hi,
We are trying to build a universe consisting of 2 facts and 10 dimensions. Both the facts share all the dimensions. But the facts do not have a unique join between themselves.
Also the users want to do adhoc query from a single universe on both the facts.
Inorder to avoid creating so many aliases(to overcome the loops) we are planning to have a combined view(union all) of both facts and use that in the universe. Is this a correct design??? The facts have abt 250 million rows… wanted your suggestions for improving on the universe design & performance.
You might want to look into the “Context” feature in designer. You will save a bunch of aliases and duplication of objects if you use them. They work great for database scenarios you have described!
I would not use a view for this data configuration especially with =20 that many rows in the tables. Your queries could run for quite a while. =20
I’m not as nice as Mike. You absolutely need to use contexts for this. This is the only way to accomplish this. Views won’t work well, if at all. You need to run 2 queries to get the right answer when you have 2 fact tables. Contexts make BO do this automatically. You will not need aliases for the common dimensions.
Also, keep in mind that if you build true measures from your fact tables ( sum(fact_table.column) ), BO may actually what you want anyway. In either case, make sure that your dimension objects are retrieving from you dimension tables only.
Thanx Steve…
I did try the context feature … selecting measures from both the facts and two dimensions… As required it runs two SQLs and ends up giving results in two different tables …
Infact a couple of times the query gives results in a single table but if one of the query results in additional rows as compared to the other query , then it does not display these additional rows,(which ofcourse can be made to appear by playing around with the slice & dice panel in a diff table as mentioned above).
Is there any work around to display results from these two queries(due to contexts) appear in a single table??
Kumar,
You still can display the facts in the same table, but they will be calculated on different levels of detail if there is a non-common dimension.