cancel
Showing results for 
Search instead for 
Did you mean: 

Single Universe vs. Multiple Universes

former_member184594
Active Contributor
0 Kudos

Hello all,

One of our customers wants to build ONLY one universe in BO and create the all reports on top of that SINGLE universe. However, this one universe will be very very large. It will contain so many objects, folders, contexts, tables etc.

So far, in most of my projects, we constructed multiple universes instead of one because the maintenance is easier. However, they are thinking that maintaining one universe is better and if somethings change in the backend like in DB, they just have to update one universe instead of multiple universes.

It is usually suggested that the universe should have around 500 objects. I am sure that when we create a single universe, there will be much more objects. And also, it will be hard to detect contexts and loops in that universe. These are the ones that comes to my mind first.

What are the pros and cons of single and multiple universes? What strategy should be used? Single or Multiple? I have done some research and couldn't find something that really answers this question.

Thanks to you all.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

The simple, unhelpful answer is, it depends!

But what does it depend on, you ask.

Well, the key that I've always been taught is to sit yourself in the user's position. Would you want to report on objects together. Why should I have to create two data queries from different universes in my report if I can drag a smaller number of objects from one data query over one universe and let contexts resolve the problem.

So, on ot our best friend contexts and your concern with them. If you have a standard multi star schema (multidimensional model) then contexts are easy - there's a general rule (for 99.5% of all star schemas) that there should be one context per fact table.Whether you have 5 or 35 fact tables doesn't matter - you will simply have 5 or 35 contexts. Detection is easy if you have added cardinalities to all your joins.

Anyway, back to the problem at hand. The key is usability. While a user may like all their objects in one place, how many users can you add until there are too many objects because of a requirements overlap? That's the crux of the matter - you need to be clear on who the universe is for and that will drive what is in it. Finance and accounting teams won't care able sales leads and opportunities for example. Ask yourself simple questions:

- Can the users build the reports they want from just this universe?

- What benefit would the users get from having two universes?

- Can objects be found easily enough?

- Are they grouped logically?

- Are they named as the user would expect to call them?

- Do you have duplicate objects just because people may find them in two places when it should be more obvious where they belong?

- Are date objects stored with the transactions that they provide the timestamp to?

This will better tell you if there are problems with the amount of objects you have created.

former_member184594
Active Contributor
0 Kudos

Thanks for your answer.

Acutally my biggest concern is the possibility of cartesian products in the universe. Because, if we put everything in one unvierse, we will have unrelated tables for sure. Considering our huge volume of data, if a user tries to create a report on 2 unrelated tables, they will have a cartesian. This will give haedaches to BO and DB.

Former Member
0 Kudos

You can manage those - either prohibit cartesian products or warn about them (in advanced reporting, you would sometimes want to create a cartesian product). Anyone wanting to report on the number of doors on a bicycle should be taking a good look at themselves!

All your joins will (or should) be managed by contexts and incompatible objects wouldn't be allowed to be selected.

former_member184594
Active Contributor
0 Kudos

The thing is, we are using BO 4.0 Information Design Tool, and this tool does not support "Warn" or "Prevent" options for Cartesian Products.

Anyways. They need to train their users well not to have this kind of problems.

Thanks again.

Former Member
0 Kudos

You have to amend the cartesian restrictions in the data foundation in IDT, along with the query and multiple SQL statement options. The rest are in the business layer.

former_member184594
Active Contributor
0 Kudos

I didn't really understand how you can set the cartesian restrictions inside data foundation.

Would please tell me how? And could you please post a screenshot if possible? I have been using IDT for quite some time and I have been searching what you said, but I couldn't find anything.

Thanks.

Former Member
0 Kudos

In IDT, you change the allow cartesian and multiple sql statements for each context at the foundation layer.

Click on the particular foundation in the Data Foundation tab and in the other pane there are four tabs - first is Properties where you will find the parameters as per an XI3 universe (e.g. ANSI92, BEGIN_SQL, etc.) and second is SQL Options, which is the one that you want.


Answers (2)

Answers (2)

Former Member
0 Kudos


Hi Zahid..

Not sure if you found an answer to your questions but one possible good approach would be to use >1 business views in one big universe. You can create multiple views and restrict the tables that can be there in each view. You can hide the master and then user can't see all the tables in one view. The feature is available in IDT.

Regards,

Sainath Chalamcharla.

former_member184594
Active Contributor
0 Kudos

We ended up creating only one universe instead of multi universes. We already used data foundation views and business layer views to make things less complex for the users.

Thank you for reply though.

Have nice day.

Zahid.

Former Member
0 Kudos

Hi Zahid,

I appreciate the fact that you started this topic. We have the exact same requirement at the client I am presently working at. One universe and multiple reports ontop of this one universe. Can you please share how you resolved yours?

Former Member
0 Kudos

Hi,

Using Single Universe instead of Multiple Universe may not support complex row level/object level restrictions.

For Example:

User A has access only to view data for only one division of the company and not other division of the company. But, the report has some complex calculations which needs some data that is restricted for that user.

In such situations, Applying Authentication may not be possible with single universe i guess.

Please correct me if i'm wrong here.

Thanks.