A loan-tracking fact row arrives referencing a newly acquired object that has not yet been fully catalogued, so no matching row exists in the object dimension. Rejecting the fact would delay reporting on the loan until cataloguing finishes days later. Which loading pattern handles this kind of late-arriving dimension gap?

The inferred member, or placeholder dimension, pattern handles late-arriving dimension data by inserting a minimal dimension row, often with just the business key and default or unknown attribute values, at the moment a fact references a dimension member that doesn't exist yet. This lets the fact load and participate in reporting immediately rather than waiting on an unrelated process, and the placeholder row gets updated with full attributes once the real data, here the completed catalogue record, becomes available. Rejecting and discarding the fact permanently loses real business activity, the loan genuinely happened, over what is ultimately a timing issue in a downstream cataloguing workflow, and that data can never be recovered once discarded. Delaying all other unrelated fact loads until one object is catalogued needlessly blocks unrelated reporting on a single record's administrative backlog, which doesn't scale as more objects arrive faster than they can be catalogued. Storing the object's identifier only in the fact table with no dimension row at all breaks referential integrity in the dimensional model and typically causes the fact to silently disappear from any report that inner-joins to the dimension, understating loan activity without any visible error. When applying this pattern, make sure the ETL process that later completes cataloguing knows to update the existing placeholder row in place rather than inserting a second, duplicate dimension row for the same object.