RPDbeginner

Physical Layer Joins & Connection Pools

Understand how physical table joins, keys, and connection pools are configured to enable correct and efficient query generation.

The Physical layer is where the RPD grounds itself in reality — every join here must reflect an actual, valid relationship in the source database, because the BI Server trusts these joins completely when generating physical SQL. Getting a physical join wrong doesn't just produce a wrong report; it can silently multiply rows (fan-out) or drop rows (unintended inner join) with no obvious error.

Physical joins are like the actual plumbing between rooms in a house — you can't just declare two rooms connected on a floor plan (BMM) if there's no real pipe between them. Connection pools are like separate water lines for the kitchen versus the sprinkler system, so watering the lawn doesn't cut off the kitchen's water pressure.

Key Concepts

1
Physical joins are typically defined as complex joins in the Physical Diagram — expressed as an equality condition between physical columns, with a join type (inner, left/right/full outer). Unlike BMM logical joins, physical joins should match the actual foreign-key relationships in the source schema; the Administration Tool can even import keys and generate suggested joins automatically from database metadata during the initial physical layer import.
complex joins
2
Connection pools define how the BI Server actually connects to a physical database: the data source name/connect string, credentials (or pass-through authentication), the number of concurrent connections allowed, and call-interface/isolation level settings. Multiple connection pools against the same database are common — one for interactive queries (lower timeout, fewer connections) and a separate one for batch/scheduled reports (higher timeout, dedicated connections) so that a runaway scheduled report doesn't starve interactive dashboard users of connections.
Connection pools
3
Interviewers like to probe the difference between pass-through authentication (each user's own DB credentials are used, enforcing native DB-level security) versus a shared service account (simpler, but all row-level security must then be enforced entirely in the RPD, since the database sees only one connecting user).
pass-through authenticationshared service account