# OBIEE - Dimension (Logical Table)

A dimension logical table is typically joined to a fact logical table that will contain measures.

Every logical dimension table should have a dimensional hierarchy associated with it. This rule holds true even if the hierarchy has only one level, such as a scenario dimension {actual, forecast, plan}.

## Tips

• Separate mini-dimensions from large dimensions as different logical tables – keeping options open on deleting large dimensions
• If multiple calendars and time comparisons for both are required (e.g. fiscal and gregorian), then consider separating them into different logical dimension tables – simplifies calendar table construction
• Each dimension logical table must correspond to one and only one dimension object.

## Glossary: conformed dimension

A conformed dimension is a dimension that have relationships with many fact tables (not only one).

## Documentation / Reference

Discover More
OBIEE - (Fragment|ation) (Partitioning)

The fragmentation (known also as partitioning) is the most powerful feature of OBIEE. You can fragment (or partition) any logical table (fact table as dimension table) in more than one logical table source...

The aggregate navigation capability of the Oracle BI Server allows queries to use the information stored in aggregate tables automatically. When users request information at a high “grain” of aggregation,...
OBIEE - Defining a Non-Aggregated Measure (Baseline column) of a Fact Table

If requirements exist to use fields without aggregation on a fact table, the fields should be defined in a dimension logical table using the following guidelines: Determine if there is a dimension logical...
OBIEE - Densification with the fact-based fragmentation capabilities

You may want to view the data in dense form, with rows for all combination of dimension values displayed even when no fact data exist for them. The preservation of the dimensions is is also well known...
OBIEE - Fact table (of logical fact table)

Dimension tables are expected to store columns that cannot be aggregated whereas fact tables are expected to store measure columns that can be aggregated. As a general rule: don’t include...
OBIEE - Logical level

The Logical level or level are the key level of the hierarchy and defines the grain of each table (logical table) (Fact as Dim) when set in the content tab. The level key: defines the unique...
OBIEE - Repository Aggregation rules based on dimension (dimension-specific aggregate)

Obiee offer the possibility to have differents measure aggregation rule based on the dimension. This functionality is really tied to the last and first function (in order to define its grain ?) ...
OBIEE - Repository Design

... .. A consideration to take when designing a subject area is to pay attention at the final user. Do you design for a user:OBIEE Analytics/Reporting...
OBIEE - The Business Model and Mapping (BMM)

The Business Model and Mapping layer (known also as Business Model): is the layer in the middle of the logical business model. permit to model logical dimensional models which are a reorganization...
OBIEE - [39008] Logical dimension table does not join to any fact source

When you perform a consistent check, you can get this business model warning: This problem can occurs when a fact table (such as a stock table) is only valid for a defined aggregation grain. You then...