Hi Mike, thanks, that’s really helpful. Some background on our approach: we ingest into the ODS from the landing layer, but we don’t use the tables the lake builds there. Any logic applied in landing, we replicate within the ODS from the raw source file. For address, that file is GMS_BDPRCNAK1 (member records).
Following your example, our logic would be: when the same member (case number + member number) arrives in a later file with a different address, we end-date the old address the day before that file’s date and start the new address from that date. We’d note that these dates show when GMS first held the address rather than when the member actually moved, so a correction like your 123 → 132 would also create a new row.
Does that look right to you?
-
Subscribe
Subscribed
Have a WordPress.com account? Log in now.
