BUSINESS OBJECTS TUTORIALS

BusinessObjects is a powerful ad hoc reporting and analysis tool. The single greatest component of BusinessObjects that will make your implementation succeed or fail is the universe. A universe is a business representation of your data warehouse or transaction database. It shields users from the underlying complexities of the database schema. BusinessObjects often refers to this as the semantic or metadata layer. In all your development efforts, you must stay focused on that purpose: business representation. If your universe becomes a glorified entity relationship model, your project will fail. If your universe includes every data element any user may possibly want from now to eternity, your project will fail.




Universes can become unwieldy for end users. Poorly defined joins will result in unnecessarily slow queries. The universe is the most important component to get right.

Keep It Simple
This universe was difficult for the administrator to maintain and was overwhelming even to expert BusinessObjects users. The result? End users often created invalid queries and blamed the data warehouse for bad data. Casual users would ask an IT expert to create MS Access data marts that were easier for them to use, thus defeating the flexibility and empowerment offered by an ad hoc query tool and causing unnecessary data reconciliation.

To build a successful universe, keep it simple. The universe should be useful for a clearly defined group of users and should not have much more than 200 objects in it. Bigger universes are technically feasible but not user friendly. Having more universes to build and maintain may result in slightly higher maintenance costs but will significantly increase end-user productivity and satisfaction. As your target user group expands, constantly ask yourself if the needs are distinct enough to justify a separate universe. If some users need only a handful of additional objects, keep it in the same universe. However, if they need many additional objects, create a separate universe.

Figure illustrates how different user groups will need access to different information. Human resources is one group of users that needs access to salary details but does not need product sales and order information. Therefore, a Salary universe will only have information from this one fact table. Marketing people may need information on sales but will rarely need information on the individual order numbers that customer service representatives need; however, customer service representatives need both order detail and summary sales. This is an example in which it may make sense to have one universe that meets the needs of both user groups (marketing and customer service representatives). A director of the marketing group is most likely a people manager and may need salary and employee details; the director would use two universes, as including three subject areas in one big universe would potentially be overwhelming for the majority of users who don't need this information.