Data Modeling and the BI Server Repository
Three layers of the repository
The RPD is organized into three cooperating layers. The Physical layer describes sources: connections, tables, joins, and keys. The Business Model and Mapping (BMM) layer defines logical tables, columns, and calculations, plus the mappings that translate logical columns into physical expressions. The Presentation layer exposes the model to users with friendly names and hierarchies. Data flows upward through mappings; queries flow downward from presentation to physical.
Dimensional modeling essentials
You must understand logical dimensions (hierarchies of levels), logical facts (measures with aggregation rules), and logical table sources. Aggregation rules - SUM, COUNT, AVG, and the special rules like COUNT DISTINCT - matter because the BI Server uses them to roll up and to pick aggregate tables. Complex joins handle multi-table relationships that a simple foreign key cannot express. Fragmentation splits a logical table across physical tables by value, and aggregate navigation uses pre-aggregated tables to satisfy requests faster.
Traps to watch
A classic trap is confusing the level at which a calculation lives: calculations belong in the BMM layer, while column visibility and naming belong in presentation. Another is the direction of mappings - always from physical to logical, never the reverse. Questions may also test that a logical dimension can span multiple physical tables and that a measure's aggregation rule drives both rollups and aggregate-table selection. Watch for wording that swaps "logical" and "physical" table names.
Worked example
Suppose sales data lives in a monthly fact table plus a separate product dimension. You create physical tables and joins, then a logical fact table mapped to the physical fact with a SUM rule on revenue, and a logical dimension with a product hierarchy. The presentation layer renames columns for users. If asked where the SUM rule belongs, answer: the BMM layer, on the logical column.