on 09-27-2013 6:49 PM
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.