A team implementing a Type 2 slowly changing dimension for museum branches needs the loan fact table to always join to the exact version of a branch's attributes that was current when each loan occurred. What must the fact table reference to make this work correctly?

In a Type 2 slowly changing dimension, a single real-world branch can be represented by multiple rows over time, each version carrying its own surrogate key and its own effective date range. For the loan fact table to reflect history accurately, it must store the surrogate key of the specific version that was active on the date the loan occurred, which is assigned during the ETL process by matching the loan's date against each candidate version's effective range. The natural business key, such as the branch's name or code, is shared across every historical version of that branch, so joining on it would match the fact row to whichever version happens to be current at query time rather than the version that was actually in effect when the loan happened, defeating the entire purpose of Type 2 history. The source-system's internal row identifier belongs to the operational system's own record-keeping and typically doesn't even distinguish between the analytics model's separate historical versions, so relying on it ignores the Type 2 design altogether. A random identifier unrelated to which version was active provides no mechanism for correct historical joins at all and would produce arbitrary, meaningless results. When validating this design, spot-check a handful of loans against known historical branch attribute changes to confirm the fact rows are binding to the version whose effective date range actually contains the loan's date, not simply the newest version present in the dimension.