Konverteringsbeslutningslog, 1005.17.58 Dagpengetællere

1

History-tabeller? Skal data fra history-tabellerne i fact-tabellen?

Svar, Knud og Jesper: Kun én række til Fact-tabellen. Alle andre skrives i history.

2025-01-21

2

Der etableres ikke en ResponsibleAuthority-tabel i YdelsesUdstilling?

2025-01-21

3

Skal data for døde borgere (og andre cpr-typer udover aktive) konverteres

2025-01-21

4

Sattelit-tabeller arver metadata fra række i hoved-tabellen

2025-01-21

5

Kolonnen Operation (1,2,3) i History-tabeller?

Svar, Knud og Jesper: Kun én række til Fact-tabellen. Alle andre skrives i history.

2025-01-21

6

Knud nævnte, at forretningen eventuelt kan nøjes med at der konverteres således at den seneste række før 1. januar 2024 (og senere) og rækker før det (for hver borger) kan filtreres fra.

Afklaret med TD S2501-1886:

CreatedDateTime benyttes.

“der konverteres således at den seneste række før 1. januar 2024 og senere rækker konverteres, og rækker før det (for hver borger) filtreres fra”

NB: Der bortfilteres historiske rækker hvis den yngste række i fact-tabellen er dateret før 2024-01-01.

2025-01-22

7

RowValidFrom, RowValidTo kan konstrueres fra CreateDateTime alene. Det skyldes at:

1. Den yngste CreatedDatetime optræder altid i fact-tabellen.

2. CreatedDateTime er altid lig med UpdateDateTime. Der er en lille håndfuld mærkelige registreringer med meget små forskelle, der rettes ved konvertering.

8

Heltals-identens nøgle er uklar i forbindelse med versionering. I det eksisterende system er eksempelvis Grading-tabellen designet således at en ny række skrives komplet hver gang, det vil sige at BenefitGradingIdentifier er unik henover fact. og history-tabellen.

9

Vedr Enrollments

Andreas har aftalt med Kim at vi loader alle tilmeldinger fra VisiteringOgStatus. I praksis betyder det at vi kopierer temporal fact til fact, og temporal history til history. Vi har ikke et isLatest-flag i target, og vi tager rækker med uagtet deres isLatest-status