I have 1 big Oracle database. And 1 Universe. Many users cannot find their way (easily) through this Universe, because it hase so many objects. Maintenance on this Universe with BO Designer is not very easy for the same reason.
Suggestions have been made to change this, and split our Universe into several smaller (dedicated to the needs of groups of users) ones.
If we do this, we have to revise all our documents as well. And we will have more maintenance (because some of the objects wil be shown more than only once in different Us)
In other words: on which moment do you decide to split yout Universe(s) ?
Is there anybody here who has experience on this issue ? Done the same thing ? Says: don’t ?
You ahve different Universe dependent on the subject Area & the report it supports.
Say we have two subject areas Sales & the other one is HR.
In such case it is not feasible to have a singlke Universe because there is no relation between the Universes.
If you make a single Universe there will be no common Objects & will be of no use.
So in such cases we can for different Universes.
Can you tell us more about you Universe & subject Areas.
Moreover if you go for different Universe, it will require more maintainance…
@ranjul
We have diferent sources (financial, hrm, real estate) databases and they communicate through ETL to the big DWH-database 1 am refering to. So all information is (if possible, through ETL) related. We use Informatica for this proces.
When this (BO, some years ago) was implemented here it was thougt to be efficient to put it all in 1 great Universe. I think also because it was not possible to combine queries on different Universes in only one (web)document.
But now this is different, and I personally think that it could maybe be a good choice to split the Universe into smaller parts (like your “subject areas”).
I would like to know some experience from others with this before we decide what to do.
If we have separate subject areas then its better to go for separate Universes. Even in my applications I try to make separate universes If there is no common information sharing between the different subject areas.
Moreover, making separate Universes also gives you the secure information.
We had this design debate here. Most people on this board will recommend splitting the universe into as many small universes as possible. I develop big universes for Oracle E-Business Suite (aka Oracle Financials aka Oracle Apps) and my clients are happy with them, but I have learned over the years how to build a big universe that is fairly easy to navigate and maintain.
The problem with a big “one fits all” universe is that it will be come very inefficient over time as more tables, aliases, joins etc are added to it.
Then there is the security aspect: do you want users from say Sales to be able to create reports from one universe that contains classes and objects relating to HR and Finance? Yes you can use object-level security, but this is additional admin and manpower, and again isn’t very efficient.
Plus if you end up with a huge universe and the Designer-author leaves the company it will be quite hard for his replacement to figure out how this universe works without documentation.
We have found building specific universes for specific users is far more efficient, more secure and easier to manage. Yes there is the matter of additional administration, but any changes that are required to a universe will only be specific to that universe and its dependent reports. Whereas if you make a change to a big universe or you accidently delete an object/table/modify a join relationship and export, then it has the potentional to damage many many dependent reports.
It depends on your definition of “inefficient”. For one client, I have built a universe that covers GL, AP, AR, Order Managment, Purchasing, Inventory, WIP, Pricing, Bills of Materials, Requisitions, Employees, Labor Hours, Item Costing, Receipts and Service Equipment. 166 tables, 698 aliases, 3122 objects. Works great for them.
Do I want power users from Sales figuring out the profitability of products and product lines? Do I want them looking at PO’s or shop orders for items that they are trying to sell to a customer on the phone? YES! Stovepiping makes life simple, but keeps vital information away from decision makers.
At a very, very big company that both Dave Rathbun and I worked at, they had a bunch of small universes. What happened is that power users kept asking for access to an additional universe. Then they wrote reports that they shared with other users, who in turn needed access to those universes. The Business Objects team was wasting huge amounts of time refereeing who could have access to what. Eventually, the very, very big company threw their hands in the air and made all but a few universes available to all Business Objects users.
This is a problem. My experience has been that developers have a hard time working with my universes because (1) they have no OLTP universe development experience and (2) they have no understanding of the underlying OLTP system. The size of the universe is immaterial.
You have to find whatever works for you. For my OLTP universes, big seems to work just fine for my clients.
So it is not just a choice between black and white (as often) !
I’ve also been looking through some previous posts mentioned here.
This all gives me a good perspective; we have some researching en thinking to do before we really decide which direction to take.
What works for someone else, may not work for you.
They are not giving you the full picture of their set up.
There are a whole load of factors that need considering, including (but not limited to):
[list]
Ability of users - basic report writers and runners or “slice and dicers” who understand ranking, conditional filters, etc?
Demographic of users, i.e. do you have a dedicated reporting team who are all good, solid report writers or an individual report builder in each business area, or do you write the reports yourselves and disseminate to users?
Business functions - do you have distinct areas of process or might, as Dennis says, some need access to multiple areas? The only data that shouldn’t be open to all is sensitive data that you wouldn’t want in the public domain - typically staff related data and what you pay suppliers for your products (even then, some of that information comes with an implicit trust when passed to a wider audience within your organisation.
[/list]
We found that putting more related info into one big universe is excellent from end user point of view in that it makes it easier for users to consolidate data from different related areas. With many small universes they have to build separate queries to do the same and ensure same dimension objects are chosen in each query. This was a big headache in one scenario where users were asking for dimension objects with Arabic only, Enlgish only, Arabic and English together, with IDs etc etc. From the other angle, it adds and at the same time reduces the maintenance headache for Universe developers. The additional headache is when you are maintaining same dimensions in all universes as mentioned in above scenario. With many small universes you have to keep all Universes as consistent as possible for them to leverage as much flexible drilling across. With one big universe the restrictions can become very compex.
However for us the most important factor was to make it as easy as possible for end users so we in normal cases end up with very big universes with lots and lots of tables.
I believe something like this may work if the users have an inherent way to ‘delineate’ the various subjects areas of the universe that a designer could implement. You may choose to design such universe with say 14 main (Subject area focused) classes, based on your example that service each individual subject area of interest for your users. While technically still a large universe, it may also be considered by some to be a collection of 14 smaller universes in one universe file.
Users would need to understand that while to total number of objects a the universe is very high, since they are so well organized (by class) into much smaller subject based groups it would be more similar to the smaller universe design others (including myself) tend to advocate. Universes designed in this way may in fact offer some benefits that most developers normally dont consider (and some risks).
Im not sure that there is one universe design that suits all environments. Small or large universes may work equally well based on the deployment environment and users base. All risks and benefits should be carefully weighed before initiating design of a universe.
I found this topic quite interesting, and hope this is the right place to post my query,
We use a Dimensional data model which has about 15 different models based on Subject areas. Eg: Billing, Claims, Eligibility, etc. Each model has its own Fact table linked to Dimensions, some of which are Conformed dimensions which is present in multiple models. We want to build Universes on top of this model and expose it to the Business Users to create WebI reports through InfoView.
The Client already has 15 Universes one for each Subject area.
We have 15 Universes, each has 1 fact table and many Conformed dimensions with some junk dimensions. When a Report needs data from more than one Universe, we have to link the different Universe queries at Report.
Major drawback with this approach is change management. As our data model will be expanded in future, which in turn makes me to update multiple Universes when, say a Conformed dimension changes; since the Conformed dimension table will be present in multiple Universes.
Now we are considering the below options as alternative solutions,
Creating a master Universe for the Dimension tables(here there may be a effort to modify data model to suit linking Dimension tables together). Then to create derived Universes for each Fact table. These derived Universes will be linked back to common dimension Universe.
Maintenance will be easier in this approach, as whenever a Dimension changes I need not update multiple Universes, but as I am linking Universes at Designer level as Master and derived Universes, I am concerned about the Report development if the report needs data from multiple Universes. Then I would be linking multiple Linked Universe queries at Report.
The other option I have is to combine multiple dimension models(Subject areas) into one Universe. By this we will create minimal number of Universes as possible. May be end up creating 5 or 6 Universes, but we will have tough time in maintaining Security of data elements. For instance, at high level a Universe may have Billing and Eligibility data, where I have to maintain strict Security for the User groups, and let only specific users to see/ use all data elements (objects).
Hope I have summarized my question well, any inputs from you on the approach you are aware of/ pros and cons of it in terms of time it takes to build, whther it is worth building the Universes in different approach, and the performance of Report(creating WebI reports through InfoView) is appreciated !!
We want to see which approach makes it better in Architecture and when it reaches Business Users who has little patience waiting for a Report and needs best possible interface
It sounds like your semantic layer was written by someone with contextophobia.
Universes should be written to deliver data either on a subject matter basis or an audience basis, driven by various factors including security, usability of universe (number of objects, etc.)
How about creating one big universe and then using security to restrict the objects that users can see? A member of the billing user group would only see the objects in the Billing Facts class and no other facts class. Your power users would be able to see all of the fact classes. I haven’t tried to do something like this, but I think it is possible.
(BOB member since 2008-06-03)
(BOB member since 2008-10-16)
(BOB member since 2003-09-17)
(BOB member since 2007-01-18)
(BOB member since 2003-09-17)
(BOB member since 2007-07-11)
