RPDadvanced

Logical Table Sources & Fragmentation

Explain how fragmentation content rules split logical fact/dimension data across multiple physical sources (e.g., by region or date range) for query efficiency.

Fragmentation is aggregate navigation's close cousin, but instead of splitting data by *grain* (detail vs. summary), it splits data by *content* — different subsets of the same logical entity living in different physical tables or databases, often for historical, regulatory, or partitioning reasons. This is a more advanced RPD topic that separates intermediate from senior candidates.

It's like a library that keeps this year's newspapers at the front desk for quick access but ships everything older than a year to an off-site archive — a librarian (the BI Server) knows exactly where to look based on the date you ask for, and can even combine both sources if your request spans the boundary.

Key Concepts

1
A common real-world scenario: a company keeps the current year's sales in a fast, frequently-updated OLTP-adjacent table, but archives prior years into a separate historical table (possibly on a different, cheaper storage tier or even a different database entirely). Rather than forcing report authors to know and pick the right table, you configure two logical table sources on the same logical fact table, each with a fragmentation content rule — a WHERE-clause-like condition declaring which subset of data that LTS covers (e.g., Year >= 2025 for the current table, Year < 2025 for the archive). The BI Server's navigator uses these rules to route (and sometimes split and union) queries across the correct physical source(s) automatically, including transparently querying both and unioning results if a request spans the boundary (e.g., a report covering 2024–2025).
two logical table sourcesfragmentation content ruleYear >= 2025Year < 2025
2
Fragmentation can be combined with aggregate navigation (a fragmented aggregate is possible) and is also the mechanism behind geographically partitioned data (e.g., EMEA sales in one regional database, APAC sales in another, unified into one logical "Sales" fact for global reporting).
3
A key interview nuance: fragmentation content rules must be mutually exclusive and collectively exhaustive for correctness — gaps mean missing data for some queries, and overlaps mean double-counting when the server unions fragments.
mutually exclusive and collectively exhaustive