What industry did you work at a large firm? My experience has been that large firms fragment into product lines/business units, but Sales and Purchasing would have a lot of interest in each other’s data within each product line/business unit. I would guess that the iPod people at Apple probably rarely look at iPhone or Mac data, but the iPod Purchasing and Sales people would be constantly looking at each other’s data.
It has been my experience that executives rarely use BI tools directly. Usually, they want dashboards or spreadsheets or powerpoints prepared from the BI tools. Executives are the most technophobic people I encounter at companies.
To me, what makes a universe big is the number of classes/objects the users have to navigate. Putting less used objects/classes into a details class makes a universe seem smaller because the user doesn’t have to navigate through them most of the time. So a class with 120 objects looks a lot bigger than a class that has the 20 most used objects and 200 objects in logically laid out subclasses.
What do you mean by “I’d look to reduce complexity by eliminating snowflaked aliases and the need for derived tables”? I don’t follow how that would impact how big the universe seems to the users.
[quote:c17c0cb47f=“Dennis W. Disney”]What industry did you work at a large firm? My experience has been that large firms fragment into product lines/business units, but Sales and Purchasing would have a lot of interest in each other’s data within each product line/business unit. I would guess that the iPod people at Apple probably rarely look at iPhone or Mac data, but the iPod Purchasing and Sales people would be constantly looking at each other’s data.
[/quote]
I’ve worked mostly in the banking industry - the sales/purchasing example may not have been the best. To use an example from the financial services field, the guys in commercial loans may not have much interest in what’s going on with consumer checking, and if they’re the only users, integrating that data into a single large Universe may not make much sense. Which I think is pretty much what you were saying.
That’s true, but they usually have staff that do use the tools to provide them with analysis and reporting. It usually pays to keep those users very happy - and those users often want / need to look across the various business silos. In many firms, they represent the primary users of BI - or at least, certainly the most visible.
I think we’re talking about two different things here. One is how big the Universe looks to the users, the other is how large and complex it is to build, support, modify and expand. You could in theory have a Universe comprised of a single simple star schema that had over 500 objects, or a Universe based on multiple snowflakes, with complex derived tables, many contexts and aliases, but only a hundred or so objects. The first one’s going to be a challenge from a user experience standpoint - you’ll probably need to carefully arrange all those objects to avoid user confusion. The other Universe is going to be more challenging from a developer’s standpoint - it’s probably going to be harder to build, harder to debug, and harder to modify and expand.
I guess the takeaway is just because a Universe has lots of tables - or lots of objects - does not mean it’ll necessarily be all that complex from either a user or a developer standpoint. I’ve seen “small” Universes which had a lot more complexity than their larger kin.
I’ve been using linked universes since we implemented XIr2 over our data warehouse and have had no problems. I have half a dozen little universes dealing with “People” or “Locations” or “Vehicles” and a few bigger ones that link them all together. Maintenance is much easier as is testing for source-system upgrades.
From my experience the number of tables adds to the design problem. As I designed a production - distribution - sales - purchasing - financial - payroll universe for a smaller company the main requirement was to have it all in one place.
What made this easy was that I developed it alone, had the full knowledge of all tables involved and in the end I went for multiple universes, one for distribution, one for payroll and one for the rest.
Then taught the users how to use multiple data providers.
Linked universes have one drawback in updating each other. Especially at the start when nobody knows which reports will come out of the DW the constant updates / changes / reworks make linked universe prone to failure. I tried it and in the fast environment as the only developer for about 20 users it was pretty impossible to keep a linked universe up to date in the main universe.
That’s the design problem as there were about 200 tables involved and the information came from linking all the parts together.
From what I know now it would have been better to organise all the data along the silo lines (production, distribution, sales & purchase, finance) and put the common objects (products, customers, suppliers) into their own universe to be linked into the silo universes.
Chances are that the common object universes, if properly designed (whatever might be needed is in the universe) can become quite static which makes them good candidates to be universes that link into others.
The more volatile silo universes can then be easier designed, faster rolled out and tested by users. It is also easier to just scrap them in case the development goes the wrong way (often does as users are so fickle).
Me and a buddy of mine came to the same conclusion IIRC while trying to fix a data warehouse at a former employer, where the consultants had tinkered away for 2 years with nothing that worked to show for it.
The problem I’ve encountered is getting users to understand how to link multiple data providers in Webi (or even Deski). If you can get them to do it then multiple Universes are a legitimate solution. If you can’t, and if the users want to see “everything”, you’re sorta stuck.
I know its been a few months since this post was really active, but I thought seeing I had just built a series of Oracle Financials universe that I would put in my 2 cents worth.
Backgroud first. The reason that I created the universes was because we were retiring Oracle Discoverer which had End User Layers mapped over each functional area. GL, AP, FA, SOF, HR
I took a design approach of my customer who said they wanted to see all objects in one universe, but instead of building one universe, I built every one of these individually then created a Master Linked universe containing all the sub-ordinates. The Master universe then contains all the joins between the sub-ordinates and the contexts required and any generic dimensions like dates.
The universe has now been live for a couple of weeks and touch wood, there have been not issues from the customer perspective. I have one on a technical side, but I have put that in a different post and hope someone maybe able to answer this for me. You’ll find that post here
I can see advantages to that approach. Once you have several modules in the universe, doing integrity checks becomes problematic. This way, the users get all of the objects they want, but the universes stay a more manageable size.
Arjan, did you implement any type of row level security? I have a client who is interested in doing so using the set up information in Oracle EBS and I have been struggling on how to do so.
Not in Oracle Financials, but I did do one in an HR universe (with an Oracle database) that I built last year and I have to say that this one and probably still is one of my best pieces of work ever
Basically we have a table based on position numbers and the positions that report to that position, be directly or indirectly and whereever you fall in that food chain will allow you to see yourself and anybody that report to you either directly or indirectly. We then also created an override table that is used for those that require more access then their default. eg the PA of the CEO has no reports direct or indirect and therefore in the normal world would only be able to see there own data, but as the PA to the CEO, they need to be able to run the reports for the CEO, cause lets face it, how many CEO’s do you know that run their own daily reports
Now bearing in mind the Oracle EBS contains the CRM, my guess is that it will also have some sort of table that contains the Org structure of the organisation and if so, then my solution above will work perfectly for you.
The only painful parts about the process are:
a. finding the correct entry point to add the security. There could be multiples.
b. having to add the security table to every dimension that you want to restrict.
If this is the sort of thing your after, let me know and I will elaborate more.
I think there are going to be lots of painful parts of the process. As you said, there are multiple places where the security could be in Oracle and I have to work with the customer to determine just where I need to look for the data. I was thinking I would have to create a some groups in supervisor, one for each segment they want to restrict. A user who can look at data for a whole business unit would go in the Business Unit group, where as a user restricted to a department would go in the Department group. Then I have to see how the performance is impacted. It is going to be a challenge.
Yes, that is right, it will be painful, if you are making Supervisor/CMC groups, then you may find you actually need to set up many more groups than you think resulting in a lot of maintenance worries for the system administrator.
Basically the security that I setup does that by default, every person that I have in the org structure is in a Directorate/Branch/Cost Centre/Section & Subsection hierarchy, with the CEO sitting across the lot.
If the person is a Cost Centre manager, then all they can see from the data is their Cost Centres information being themselves and all staff that are in that same Cost Centre even though they are in different teams.
But if for example, you have a person that is merely a Purchasing Officer, they are considered to be at the bottom of the chain. They can run a report and see only their information.
Based on what you have said, I think my model will work for what you are trying to achieve. But you must have a table with Oracle that contains the Org structure.
Our intention is to have common dimensions on our universes based from our DW once built. How do we ensure the universes are in sync to allow for the merging of data from multiple universes. Are there certain BO architecture principles that you follow that you can share ? We wont always know up from what the next universe is going to be but when the time comes we want to be sure it aligns with what we already have. Appreciate any guidance you can provide on this subject.
I’m not a massive fan of linked universes, however I appreciate that it would provide the type of conformity and ease of maintenance you are after.
This is extremely important and when developing against a dimensional warehouse it has always been on the forefront of my mind.
There are limitations, these need to be carefully considered to see that they will not hinder the answers, to your requirements, although others have had good results by doing it this way…
I guess this is the best approach as we are following this approach. Just kidding.
Truely speaking it would be easier (maintenance wise, as well as debugging wise) if you create separate universes. Like we have 15 universes -
One for Invoice Module
One for Order Module
One for Purchasing Module
One for Account/Allocation Module
Sometimes we get a request wherein we need to merge two data providers to fulfill the requirement, so I think that is less time consuming than creating a single universe and maintaining it throughout the project life and even after that.
That may be true, but the point of the universes isn’t to make your life easy.
My guess is that your company’s users stick to simple reports because that is all the reporting solution you have provided will support. Any complex analysis they are doing by running multiple reports, throwing the data into Excel then slicing and dicing.
To me, I want my power users to have all the options they can handle in BusinessObjects, because if they can’t get the answer they want with BusinessObjects then they will use Excel.
I have to agree with Dennis. Users can be a fickel bunch and not providing them all the options can limit what they create.
Aniketp, your example of 15 universes really is not logical, Yes you can create multiple DP’s to get the data, but have you ever tried creating sections in your report on items from your DP’s that aren’t linked? Generally doesn’t work well and you need to be pretty good at report to resolve the problem.
Vikram, I really would like to know more about your problem, can you give me a bit more detail?
some qus comes in mind when if we go with large universe…something like 1000 table.
1)normally in 40 to 50 tables universe more then 500 objects created.so in this universe then something 10000 objects.is it good for a user?
2)and tables upto 3NF.means many fact tables may be used.something like 50…it means something 50 context.then how to know a user which context that will be use in the report?
3)what about performance?
I am new to this organization and have no idea what the users want. This requirement came from the Project Manager. I have gone over this debate more than 10 times and am still confused. I will gather all the information from this forum, create a document and give it to the PM. This way he can decide for himself the chosen path. Will post the doc here to.
(BOB member since 2003-09-17)
To use an example from the financial services field, the guys in commercial loans may not have much interest in what’s going on with consumer checking, and if they’re the only users, integrating that data into a single large Universe may not make much sense. Which I think is pretty much what you were saying.
(BOB member since 2005-03-01)
(BOB member since 2004-03-22)
(BOB member since 2009-08-26)
(BOB member since 2002-06-20)