After a data integration job, orphan foreign keys spike in a municipal case-management warehouse. What does this primarily indicate?
Select an answer to reveal the explanation.
Short Explanation
When child rows show up without parents after a load, the integration just broke the family tree. Mapping and sequencing mistakes are common DQ failure modes in ETL/ELT. Treat the spike as an integration defect, not a random coincidence.
Full Explanation
Integration mappings and load sequencing can introduce referential data-quality failures during ETL or ELT into civic warehouses. When orphan foreign keys spike in a municipal case-management warehouse after an integration job, the signal primarily indicates that joins, keys, or sequencing broke referential expectations. Claiming integration jobs never affect referential quality outcomes ignores one of the most common warehouse failure modes in multi-system city estates. Interpreting orphans as proof that uniqueness improved because keys no longer match misunderstands both uniqueness and referential integrity and celebrates broken links. Treating orphan keys as solely a BI visualization theme mislabels a structural load defect as a presentation preference. Exam caveat: distinguish true business orphans from late-arriving parents; sometimes the fix is load order or delayed parent extracts, not parent deletion. Operational check: compare pre/post orphan rates for the affected foreign key, inspect the mapping and extract windows, quarantine orphan facts from official case metrics, and repair sequencing or reference feeds. County case-management and warehouse leads should jointly own a referential SLA so civic dashboards do not publish broken case links to directors or courts.