This article was originally published on BusinessObjects Expert

Organizations typically consist of numerous departments and business areas, all of which have their own requirements for reporting and analysis of data. Multiple business areas (e.g., accounting, finance, sales, operations) use BusinessObjects to generate their reports and conduct their data analysis. Subsequently, BusinessObjects universes need to be designed and developed to meet the needs of these separate and unique business areas. You can satisfy the reporting needs of these business areas in two ways:

• With the development of a single comprehensive universe that incorporates the reporting needs for all business areas. This technique incorporates all the organization’s fact and dimension tables.
• With the development of smaller subject-area-based universes that incorporate the reporting needs for just one business area. This technique incorporates the minimum number of fact and dimension tables needed for one business area.

The universe model must consider and incorporate common tables of data that all business areas require access to. These common tables of data are referred to as conformed dimensions and are applicable to both single comprehensive and the subject-area-based universes. Common examples of conformed dimensions include date, customer, vendor, employee, and product.

Single comprehensive universes can incorporate multiple instances of a conformed dimension with the use of aliases (e.g., a conformed dimension customer can exist multiple times in a universe). In contrast, however, the subject-area-based universes contain only a single instance of a conformed dimension, with instances of the conformed dimension being repeated among multiple universes (e.g., a conformed dimension customer exists once in a universe, but can exist in multiple universes).

The Single Comprehensive Universe Technique

This universe design technique is characterized by including every fact and dimension table that exists within an entire organization. With this technique, the universe can be become very large and complex (i.e., the universe contains a large number of classes, objects, tables, aliases, joins, and contexts), but can also incorporate a high degree of reuse of components. In addition, multiple star schemas and conformed dimensions can exist within the same universe. Star schemas are simple data modeling techniques that consist of one or more fact tables referencing any number of dimension tables. Conformed dimensions are common and repeatedly used dimensions that relate and are joined to multiple facts. Comprehensive BusinessObjects universes are not required to use dimensional modeling techniques with dimensions and facts. However, it is best practice within the universe to follow the modeling technique that is used in the source database, and source databases for reporting typically use dimensional modeling.

To include repeated conformed dimensions within the universe, each conformed dimension is given an alias. An alias is an exact duplicate of a universe table, but with a different name. The data in the table is exactly the same as the original table, but the different name allows the universe to accept the same table into its structure and identify the referenced instance of the table. This universe concept uses numerous aliases so that a conformed dimension table can be joined with multiple fact tables.

Figure 1 shows a single comprehensive BusinessObjects universe. It includes multiple fact tables with surrounding dimension tables (i.e., stars), with a conformed dimension (customer) included multiple times as aliases 1, 2, and 3. In addition, the conformed dimension joins to multiple fact tables.

Figure 1

An example of a single comprehensive universe

A single comprehensive universe can yield the following results:

• Universe consistency. The organization includes only one universe, and all business areas use the same universe for reporting and analysis. Thus, each business area receives the same results from queries and analysis.
• Reuse of components. Objects within the universe need to be designed and developed only once, and then multiple business areas can use them over and over.
• Simplified metadata management. Metadata within a universe includes the characteristics of tables and fields, including name, source, class, and object type. Because all the fields and tables exist within the same universe, you can easily track and document metadata characteristics for every table and field.

Challenges associated with a single comprehensive universe include the following:

• Complex structure. The comprehensive universe can become large, as it can include a large number of tables and fields. In addition, the universe can contain numerous aliases, contexts, loops, and chasm and fan traps. Subsequently, the universe structure can be elaborate and difficult to understand and maintain.
• Incompatible objects. Because multiple stars (i.e., fact tables surrounded by dimension tables) could exist in the universe, fields that cannot be incorporated into the same query could exist within the same universe.
• A single universe design professional for the entire universe. Universes are typically designed and developed by one universe design professional at a time because the old Universe Designer and the new Information Design Tool are both meant for single-developer updates. Consequently, one universe design professional is responsible for development and maintenance of a potentially large universe that the entire organization uses. 
• Unclear meaning of fields. The universe may contain similar objects with names and properties that are alike and difficult to comprehend without comprehensive documentation and training.
• Long project and update cycles. The development and incorporation of every table and field within an entire organization can be lengthy and arduous. Moreover, comprehensive universes require large data warehouses to already exist in an organization. In addition, when changes occur to the universe, the entire universe needs to have a sizable regression test to verify that no faults are introduced with the changes.

Subject-Area-Based Universes

Subject areas within a data warehouse are physical tables that:

• Are grouped together in a dimensional model or star schema
• Reflect general data or business categories

Consequently, subject-area-based universes incorporate only those fact and dimension tables needed to conduct business intelligence for a particular area. Within this type of model, each universe typically contains a single star schema with a single fact table and only a small number of dimension tables. In addition, conformed dimension tables are duplicated within each universe. Aliases are not needed to reference conformed dimensions as these dimensions consist only once in each universe. 

Figure 2 shows multiple subject-area-based BusinessObjects universes. Each universe contains a single fact table and its related dimension tables (i.e., stars). The customer conformed dimension is included only once in each universe, and the conformed dimension is duplicated between universes. 

Figure 2

Examples of subject-area-based universes

Potential benefits associated with subject-area-based universes include the following:

• Simple and intuitive structure. A subject-area-based universe typically contains one dimensional star and only the fact and dimension tables related to one business area. Thus, the universe contains a limited number of tables and fields, and it likely does not contain any aliases, contexts, loops, or traps.
• Rapid deployments and quick updates. You can quickly design and develop a subject-area-based universe — it can be small and does not require a large data warehouse to have already been built. Instead, it just requires a small data mart or an individual star schema built in the source database.
• Highly manageable and easy to maintain. The universe is modified and tested because of its limited scope. In addition, changes to one universe only affect the reports and dashboards connected to that particular universe, and they do not alter the enterprise. You can quickly perform regression testing because the size and scope of the universe are limited.
• Developer accountability. Subject-area-based universes can be assigned to and developed by a single universe design professional, and each universe within an organization can be assigned to different universe design professionals. Thus, there is distribution of work among the universe design professionals within an organization.

Challenges associated with subject-area-based universes include the following:

• Numerous universes within an organization. As subject-area-based universes are limited in scope, you must create and maintain separate universes for each business area.
• Possible inconsistency of data fields among universes. Although subject-area-based universes are physically separate from each other, they may contain tables and fields that are contained in universes. Fields may become out of sync through universe changes and may not bring back the same results.
• Multiple occurrences of conformed dimensions. Conformed dimensions relate and are joined to multiple facts, and, therefore, are included in numerous subject-area-based universes in an organization. However, to be accurate, conformed dimensions need to be identical in every universe in which they are incorporated. Subsequently, ongoing maintenance is necessary to keep conformed dimensions consistent among numerous universes.