Receive: fact carries business key
Placeholder: unresolved member
Load: fact links to placeholder
Enrich: master data arrives
Audit: impact and recomputation
Preserve the fact, then complete its context
Streaming transactions, retries, and batch delays can place an order ahead of customer or product master data. Rejecting it loses activity; one global unknown loses the matching clue.
Create a placeholder dimension member tied to the source business key.
Make placeholders distinguishable
Store source, first-seen time, unresolved state, and one placeholder per unknown business key.
A fact with no business key should use a generic unknown member because it represents a different quality issue.
Choose an enrichment strategy
When identity is certain, enrich the same surrogate member so facts need no rewrite. Ambiguous or wrong matches require merge, split, or reassignment.
For slowly changing dimensions, decide whether attributes apply from fact time or master arrival time.
Expose completeness downstream
Reports should show unresolved fact count and value so users do not mistake unknown for a business category.
After enrichment, identify aggregates, caches, and exports that require recomputation and version material changes.
Accept with out-of-order events
Simulate fact-first, dimension-first, duplicates, bad keys, entity merge, and next-day enrichment, checking idempotency, uniqueness, history, and recomputation.
BuildTable can be evaluated for model governance; placeholder creation, entity matching, impact analysis, and orchestration require confirmation.
Public references
Build an AI-ready data foundation
Contact us to discuss your data modeling scenario and access BuildTable Desktop.
Contact us