What is a universe?

A universe is a file that contains the following: Connection parameters for one or more database middleware. SQL structures called objects that map to actual SQL structures in the database such as columns, tables, and database functions. Objects are grouped into classes. Objects and classes are both visible to Web Intelligence users. A schema of the tables and joins used in the database. Objects are built from the database structures that you include in your schema. The schema is only available to Designer users. It is not visible to Web Intelligence and Desktop Intelligence users. Web Intelligence users connect to a universe, and run queries against a database. They can do data analysis and create reports using the objects in a universe, without seeing, or having to know anything about, the underlying data structures in the database

What is the role of a universe?

The role of a universe is to provide an easy to use and understand interface for non technical Web Intelligence users to run queries against a database to create reports and perform data analysis. As the universe designer, you use Designer to create objects that represent database structures, for example columns and database functions, that users need to access and query, to get the information necessary to meet their business requirements. The objects that you create in the universe must be relevant to the end user business environment and vocabulary. Their role is to present a business focussed front end to the SQL structures in the database.

What does a universe contain?

A universe contains the following structures: Classes Objects

Classes
A class is a logical grouping of objects within a universe. It represents a category of objects. The name of a class should indicate the category of the objects that it contains. A class can be divided hierarchically into subclasses.

Objects
An object is a named component that maps to data or a derivation of data in the database. The name of an object should be drawn from the business vocabulary of the targeted user group. For example, objects used in a universe used by a product manager could be Product, Life Cycle, or Release Date. A universe used by a financial analyst could contain objects such as Profit Margin, and Return on Investment.

Types of objects
In Designer, objects are qualified as one of three types: dimension, detail, or measure. Object type Description Dimension - Parameters for analysis. Dimensions typically relate to a hierarchy such as geography, product, or time. For example Last Name and City_Id Detail - Provide a description of a dimension, but are not the focus for analysis. For example Phone Number Measure - Convey numeric information which is used to quantify a dimension object. For example Sales Revenue

Understanding the cardinaltity of a join

Cardinalities further describe a join between 2 tables by stating how many rows in one table will match rows in another. This is very important for detecting join problems and creating contexts to correct the limitations of a target RDBMS structure

What cardinalities can be set for a join?

You can set the following cardinalities for a join: one-to-one (1,1) - For every row in table 1, expect one and only one row in table 2 one-to-many (1,N) - For every row in table 1, expect one or many rows in table 2 many-to-one (N,1) - Same as for one-to-many (1,N), but the direction for the row match is opposite. many-to-many (N,N) - For each one or multiple rows in table 1, expect one or multiple rows in table 2. Many-to-many cardinalities are rare in relational databases and will return duplicate rows, causing slower performance and potentially inaccurate results. If you have (N,N) cardinalities, you should re-check the concerned joins, and ensure that you understand the relationship between the tables.

Defining specific types of joins

You can define the following types of joins in Designer

Equi-Joins - (includes complex equijoins) Link tables based on the equality between the values in the column of one table and the values in the column of another. Because the same column is present in both tables, the join synchronizes the two tables. You can also create complex equi-joins, where one join links multiple columns between two tables. Theta Joins - (conditional joins) Link tables based on a relationship other than equality between two columns. Outer Joins - Link two tables, one of which has rows that do not match those in the common column of the other table. Shortcut Joins - Join providing an alternative path between two tables,bypassing intermediate tables, leading to the same result,regardless of direction. Optimizes query time by cutting long join paths as short as possible.

Self restricting joins - Single table join used to set a restriction on the table.

What is a Lookup Table

A lookup (or dimension) table contains information associated with a particular entity or subject. For example, a lookup table can hold geographical information on customers such as their names, telephone numbers as well as the cities and countries in which they reside. In Designer, dimension and detail objects are typically derived from lookup tables. A lookup table has the following join cardinality structure:

What is a Fact Table

A fact table contains statistical information about transactions. For example, it may contain figures such as Sales Revenue or Profit. In a universe, most but not all, measures are defined from fact tables. A fact table is characterized by the following join cardinality structure:

What is a join path problem

A join path is a series of joins that a query can use to access data in the tables linked by the joins. Join path problems can arise from the limited way that lookup and fact tables are related in a relational database. The three major join path problems that you encounter when designing a schema are the following: loops chasm traps fan traps You can solve all these problems by creating aliases (a copy of a base table), contexts (a defined join path), and using features available in Designer to separate queries on measures or contexts.

What Types of Join Paths Return Incorrect Results?

Queries can return incorrect results due to the limitations in the way that joins are performed in relational databases. Depending on how the lookup and fact tables in your table schema are related, join paths can produce instances where a query returns too few, or too many rows.

Type of Join Path Loop

Converging many to one joins

Returns
Too few rows Too many rows

Description
Joins form multiple paths between lookup tables. Many to one joins from two fact tables converge on a single lookup table. This type of join convergence can lead to a join path problem called a chasm trap.

Serial many to one Joins

Too many rows

A one to many join links a table which is in turn linked by a one to many join. This type of fanning out of one to many joins can lead to a join path problem called a fan trap.

Defining aliases
Aliases are references to existing tables in a schema. An Alias is a table that is an exact duplicate of the original table (base table), with a different name. The data in the table is exactly the same as the original table, but the different name "tricks" the SQL of a query to accept that you are using two different tables.

Defining contexts
Contexts are a collection of joins which provide a valid query path for Web Intelligence to generate SQL.

How are Contexts Used in a Schema?

You can use contexts in a universe schema for the following purposes: Solving loops. Solving chasm traps. Assisting in some solutions for fan traps. Assisting in detecting incompatibility for objects using aggregate Awareness

What is a Loop?
A loop is a set of joins that defines a closed path through a set of tables in a schema. Loops occur when joins form multiple paths between lookup tables. An example of a loop is shown below.

What is a Chasm Trap?

A chasm trap is a type of join path between three tables when two many-to one joins converge on a single table, and there is no context in place that separates the converging join paths. The example below shows a part of the Beach universe schema. The three tables have been separated from the rest of the schema to illustrate thechasm trap. It uses the same

Club connection for data.

Resolving a Chasm Trap

To resolve a chasm trap you need to make two separate queries and then combine the results. Depending on the type of objects defined for the fact tables, and the type of end user environment, you can use the following methods to resolve a chasm trap:

Create a context for each fact table. This solution works in all cases. Modify the SQL parameters for the universe so you can generate
separate SQL queries for each measure. This solution only works for measure objects. It does not generate separate queries for dimension or detail objects. Each of these methods is described in the following sections.

Using contexts to resolve chasm traps

You can define a context for each table at the many end of the joins. In our example you could define a context from SERVICE to RESERVATION_LINE and from SERVICE to INVOICE_LINE. When you run a query which includes objects from both contexts, this creates two Select statements that are synchronized to produce two separate tables in Web Intelligence, avoiding the creation of a Cartesian product.

When do you use contexts?

Creating contexts will always solve a chasm trap in a universe. When you have dimension objects in one or both fact tables, you should always use

What is a Fan Trap?

A fan trap is a type of join path between three tables when a one-to-many join links a table which is in turn linked by another one-to-many join. The fanning out effect of one-to-many joins can cause incorrect results to be returned when a query includes objects based on both tables.

How Do You Resolve a Fan Trap?

There are two ways to solve a fan trap problem.

Create an alias for the table containing the initial aggregation, then use
Detect Contexts (Tools > Detect Contexts) to detect and propose a context for the alias table and a context for the original table. This is the most effective way to solve the fan trap problem.

Altering the SQL parameters for the universe. This only works for
measure objects.