Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Det bedste grundlag for et kopiregister er et periodeudtræk uden udtræksbetingelser - bortset fra Since Previous betingelsen på et deltaudtræk. Alle andre varianter vil kunne medføre tab af data på forskellig vis og dermed “huller” i kopiregistret.
Det vil være op til anvenderens egen vurdering af den enkelte filtjeneste om tjenesten egner sig som udgangspunkt for et kopiregister for den pågældende anvender, i de tilfælde hvor der ikke findes tjenestespecifik dokumentation herom.
Hvis et deltaudtræk har udtræksbetingelser ud over dem som er indbygget i Datafordeleren (tjek på opdateringer siden sidst), så vil der som regel være risiko for tab af data, og tabte data vil ikke blive fremfundet i senere deltaudtræk.
Et tidsspecifikt udtræk - herunder et aktuelt - vil per definition levere et øjebliksbillede. I modsætning hertil forventes et kopiregister at repræsentere alle tidligere øjeblikke og det aktuelt gældende. Derfor er tidsspecifikke udtræk principielt uegnede som grundlag for kopiregistre.
Samkørte udtræk (join) af tabeller med bitemporale attributter vil sjældent med succes kunne gennemføres som periodeudtræk, og registerejere vil derfor sjældent tilbyde disse som deltafilsudtræk til kopiregistre. De bitemporale egenskaber vil betyde, at enten får man for lidt data udtrukket (specielt afregistreringer vil mangle), eller man får alt for meget redundant data i form af objekter indeholdende attributværdier der egentlig ikke vedrører det samme objekt (det kartesiske produkt). Den nærmere tekniske forklaring er uddybet nedenfor.
Table of Contents |
---|
Sideinformation
Display Metadata | ||
---|---|---|
|
Eksempler på samkøringsproblemer ved periodeudtræk for EJF og EBR
Følgende eksempler vil sammenlagt vise, at samkørte udtræk ikke er velegnede som basis for kopiregistre.
For mange eller for få resultatrækker
I eksemplet her har vi en tabel med pseudodata for en ejendom fra hver af to forskellige registre EJF og EBR. Vi ser på nedenstående dataindhold, idet tidspunkter er angivet som datoer for enkelhedens skyld, og eksemplet i øvrigt er væsentligt forenklet. F.eks. er rækker med status ’Historisk’ udeladt fra tabellen Ejendomsadministrator, da det ikke ændrer på konklusionen.
Tabel Ejendomsadministrator
BFEnr | Status | registreringFra | registreringTil | virkningFra | virkningTil | Navn |
123 | Gældende | 15.02.2013 | 17.07.2020 | 01.03.2013 | NULL | Hans Hansen |
123 | Gældende | 17.07.2020 | NULL | 01.03.2013 | 01.07.2020 | Hans Hansen |
123 | Gældende | 17.07.2020 | NULL | 01.07.2020 | NULL | Jens Jensen |
Tabel Ejendomsbeliggenhed
BFEnr | Status | registreringFra | registreringTil | virkningFra | virkningTil | Betegnelse |
123 | Gældende | 13.05.2010 | 04.10.2015 | 01.06.2010 | NULL | Ukendt Adresse |
123 | Gældende | 04.10.2015 | NULL | 01.06.2010 | 01.11.2015 | Ukendt Adresse |
123 | Gældende | 04.10.2015 | NULL | 01.11.2015 | NULL | Hovedgaden |
Lad os sige, at der foretages en samkøring med denne udtrækslogik med inputparameteren
- @Virkningstid = ’2019-01-01’
Code Block | ||
---|---|---|
| ||
SELECT EJF.BFEnr , EJF.registreringFra, EJF.virkningFra, EJF.Navn , EBR.registreringFra, EBR.virkningFra, EBR.Betegnelse FROM Ejendomsadministrator EJF INNER JOIN Ejendomsbeliggenhed EBR ON EJF.BFEnr = EBR.BFEnr WHERE EJF.registreringTil = NULL AND EJF.virkningFra <= @Virkningstid AND (EJF.virkningTil = NULL OR @Virkningstid < EJF.virkningTil) AND EBR.registreringTil = NULL AND EBR.virkningFra <= @Virkningstid AND (EBR.virkningTil = NULL OR @Virkningstid < EBR.virkningTil) |
Resultatet vil være dette øjebliksbillede:
BFEnr | EJF.registreringFra | EJF.virkningFra | Navn | EBR.registreringFra | EBR.virkningFra | Betegnelse |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.11.2015 | Hovedgaden |
Betragt herefter følgende maksimale periodeudtræk med parametrene
- @virkningFra = ’0001-01-01’
- @virkningTil = ’9999-12-31’
- @registreringFra = ’0001-01-01’
- @registreringTil = ’9999-12-31’
Code Block | ||
---|---|---|
| ||
SELECT EJF.BFEnr , EJF.registreringFra, EJF.virkningFra, EJF.Navn , EBR.registreringFra, EBR.virkningFra, EBR.Betegnelse FROM Ejendomsadministrator EJF INNER JOIN Ejendomsbeliggenhed EBR ON EJF.BFEnr = EBR.BFEnr WHERE EJF.registreringFra <= @registreringTil AND (EJF.registreringTil = NULL OR @registreringFra < EJF.registreringTil) AND EJF.virkningFra <= @virkningTil AND (EJF.virkningTil = NULL OR @virkningFra < EJF.virkningTil) AND EBR.registreringFra <= @registreringTil AND (EBR.registreringTil = NULL OR @registreringFra < EBR.registreringTil) AND EBR.virkningFra <= @virkningTil AND (EBR.virkningTil = NULL OR @virkningFra < EBR.virkningTil) |
Resultatet bliver nu som vist her:
BFEnr | EJF.registreringFra | EJF.virkningFra | Navn | EBR.registreringFra | EBR.virkningFra | Betegnelse |
123 | 15.02.2013 | 01.03.2013 | Hans Hansen | 13.05.2010 | 01.06.2010 | Ukendt Adresse |
123 | 15.02.2013 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.06.2010 | Ukendt Adresse |
123 | 15.02.2013 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.11.2015 | Hovedgaden |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 13.05.2010 | 01.06.2010 | Ukendt Adresse |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.06.2010 | Ukendt Adresse |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.11.2015 | Hovedgaden |
123 | 17.07.2020 | 01.07.2020 | Jens Jensen | 13.05.2010 | 01.06.2010 | Ukendt Adresse |
123 | 17.07.2020 | 01.07.2020 | Jens Jensen | 04.10.2015 | 01.06.2010 | Ukendt Adresse |
123 | 17.07.2020 | 01.07.2020 | Jens Jensen | 04.10.2015 | 01.11.2015 | Hovedgaden |
Ideelt set skulle resultattabellen give en liste over alle mulige og virkelighedstro øjebliksbilleder, men den indeholder også nogle rækker, der ikke afspejler nogen virkelighed (markeret med rødt og blåt) – Jens Jensen har aldrig været administrator for ejendom med Ukendt Adresse.
Den røde række kunne have været undgået med en direkte betingelse i udtrækket mellem virkningsperioderne for de to tabeller, dvs. man kunne tilføje:
Code Block | ||
---|---|---|
| ||
AND EJF.virkningFra < COALESCE (EBR.virkningTil, ’9999-12-31’) |
(I nogle databasesystemer hedder COALESCE også VALUE og returnerer værdien af det første element i listen af argumenter, der ikke er NULL)
Af symmetrigrunde skal vi også have betingelsen:
Code Block | ||
---|---|---|
| ||
AND EBR.virkningFra < COALESCE(EJF.virkningTil, ’9999-12-31’) |
Den blå række skyldes en kunstig kobling mellem den afregistrerede række i EBR og en ikke afregistreret række i EJF. Rækken kan kun fjernes (generisk) med en betingelse som:
Code Block | ||
---|---|---|
| ||
AND EJF.registreringTil = NULL |
Af symmetrigrunde må afregistrerede rækker i EBR også fjernes:
Code Block | ||
---|---|---|
| ||
AND EBR.registreringTil = NULL |
Vi får herefter dette resultat:
BFEnr | EJF.registreringFra | EJF.virkningFra | Navn | EBR.registreringFra | EBR.virkningFra | Betegnelse |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.06.2010 | Ukendt Adresse |
123 | 17.07.2020 | 01.03.2013 | Hans Hansen | 04.10.2015 | 01.11.2015 | Hovedgaden |
123 | 17.07.2020 | 01.07.2020 | Jens Jensen | 04.10.2015 | 01.11.2015 | Hovedgaden |
Resultatet indeholder alle reelle kombinationer af Navn i EJF og Betegnelse i EBR. Bemærk dog, at EJF.registreringFra i række 1 ikke korrekt viser hvornår det blev registreret, at Hans Hansen overtog administrationen af ejendommen med Ukendt Adresse. Det skyldes at afregistreringer er fjernet for at undgå de blå rækker ovenfor.
Træder vi et skridt tilbage, kan vi nu se to udfordringer med samkørte udtræk som udgangspunkt for kopiregistre. For at opnå et retvisende resultat, skal:
- der tilføjes periodebetingelser direkte mellem alle samkørte tabeller. Det kan blive en meget kompleks opgave, idet antal yderligere betingelser bliver n x (n – 1), hvor n er antal samkørte tabeller.
- alle afregistreringer droppes, men så får vi netop ikke et kopiregister!
Mængden af redundant data kan vokse ukontrolleret
En mulig løsning er at man som anvender modtager udtræk med samkørte data inklusive alle kunstigt sammenstillede data (”røde og blå” rækker). Ved modtagelsen kan anvendere i så fald påtage sig at skille data fra hinanden i særskilte tabeller, som anvenderne derefter selv samkører i henhold til det konkrete anvendelsesbehov. Ændring af udtræksbetingelserne i Datafordelerens tjenestelogik fra betingelser på specifikke tidspunkter til perioder ville derved medføre, at anvenderne kunne lave lokale opslag mod de hjemhentede data, hvor kun reelle virkeligheder blev returneret.
I praksis er dette dog ikke muligt da mængden af udtrukne data potentielt vil vokse uoverskueligt i et udtræk af det totale datasæt, til et niveau som er uacceptabelt stort.
Dette har baggrund i, at et samkørt udtræk fremkommer som det kartesiske produkt af rækkerne i de samkørte tabeller givet udtræksbetingelserne. Når man ”løsner” udtræksbetingelserne ved at gå fra specifikt tidspunkt til periode, vokser dette produkt markant – og dermed antal rækker i det samkørte udtræk. Mængden af distinkt information forbliver uændret, men mængden af redundant information vokser betydeligt.
I eksemplet ovenfor med 2 tabeller på hver 3 rækker havde det specifikke udtræk 1 række, mens periodeudtrækket med kunstigt sammenstillede data havde 9 rækker, hvor det ideelle udtræk af det totale datasæt kun ville have 7 rækker (9 rækker minus 2 kunstige rækker). Tendensen i forskellen på antal rækker bliver hurtigt mere udtalt med et stigende antal samkørte tabeller.
Et bedre mål for datamængder end antal resultatrækker er antal dataelementer i resultatet. Dvs. produktet af antal rækker og antal attributter. Betragt nu følgende eksempel.
Vi forestiller os fem tabeller, hvor vi laver individuelle udtræk på en given ID = 123 med denne logik:
Code Block | ||
---|---|---|
| ||
SELECT * FROM X WHERE X.ID = 123 |
hvor x er en af de fem tabeller.
Antal rækker på denne ID og antal attributter er angivet som vist her:
Tabel: | T1 | T2 | T3 | T4 | T5 |
Antal rækker med ID=123 (n): | 3 | 2 | 1 | 2 | 2 |
Antal attributter (a): | 5 | 10 | 12 | 7 | 15 |
Antal dataelementer (d = a x n): | 15 | 20 | 12 | 14 | 30 |
Man kan se ved at sammenlægge tallene for d, at ved udtræk af alle fem tabeller hver for sig, overføres sammenlagt 91 dataelementer.
Vi forstiller os nu et simpelt, samkørt udtræk a la dette:
Code Block | ||
---|---|---|
| ||
SELECT * FROM T1, T2 WHERE T1.ID = T2.ID AND T1.ID = 123 |
I følgende skema er antal resultatrækker og antal dataelementer angivet afhængig af, hvilke tabeller, der indgår i dette udtræk:
Samkørte tabeller: | T1 | T1, T2 | T1, T2, T3 | T1, T2, T3, T4 | T1, T2, T3, T4, T5 |
Antal rækker i resultat: | 3 | 6 | 6 | 12 | 24 |
Antal attributter i resultat: | 5 | 15 | 27 | 34 | 49 |
Antal dataelementer i resultat: | 15 | 90 | 162 | 408 | 1.176 |
Med andre ord vil ét samkørt udtræk af alle fem tabeller i dette eksempel indeholde ca. 13 gange flere dataelementer end et udtræk af hver tabel for sig! Dette misforhold kan være både meget større og meget mindre afhængig af de konkrete data, der udtrækkes.
Konklusionen er altså, at hvis udtræksbetingelserne løsnes i et samkørt udtræk fra at være tidsspecifikke til angivet ved perioder, så vil datamængderne i nogle tilfælde komme så meget ud af kontrol, at det udgør en ikke acceptabel risiko for overbelastning af infrastruktur, uagtet hvad der gøres for at optimere tjenesterne og infrastrukturen bag dem.
Kendt problem med EBR filudtræk som grundlag for kopiregistre
På baggrund af konkrete eksempler er der identificeret problemer med visse filtjenester, der foretager udtræk til kopiregistre. Problemerne opstår, når der for inputparametrene til en tjeneste er angivet eller underforstået et specifikt tidspunkt for registreringstid og/eller virkningstid - i modsætning til en registrerings- og/eller virkningsperiode. Med andre ord:
- Registreringer, der har virkning i fremtiden set i forhold til den eventuelle angivne virkningstid, vil normalt aldrig blive udtrukket i deltaudtræk.
- Registreringer, der er afregistreret før den eventuelle angivne registreringstid, vil ikke blive udtrukket - hverken i delta- eller totaludtræk.
Problemet er identificeret for følgende filtjenester:
- EBR Complete XML
- EBR Complete JSON
- EBR DeltaDaily XML
- EBR DeltaDaily JSON
- EBR Simpel Complete XML
- EBR Simpel Complete JSON
- EBR Simpel DeltaDaily XML
- EBR Simpel DeltaDaily JSON
- Ejendomsbeliggenhed
- EBR Simpel Hist Complete XML
- EBR Simpel Hist Complete JSON
- EBR Simpel Hist DeltaDaily XML
- EBR Simpel Hist DeltaDaily JSON
Eksempel på problem 1
En registrering har følgende felter:
- VirkningFra : 20-03-2021 kl. 0:00:00.
- Modtagelsestid i DAF : 17-03-2021 kl. 12:34:56.
Deltaudtræk for en given filtjeneste foretages ifølge følgende skema:
Modtagelsestid i DAF for seneste udtrukne registrering | Virkningstid angivet i parameter for deltaudtræk | Registrering udtrækkes ikke, fordi |
17-03-2021 kl. 01:23:45 | 18-03-2021 kl. 07:00:00 | Virkningstid er tidligere end registreringens VirkningFra. |
18-03-2021 kl. 05:00:50 | 19-03-2021 kl. 07:00:00 | Virkningstid er tidligere end registreringens VirkningFra, og modtagelsestid i DAF for seneste udtrukne registrering er senere end registreringens egen modtagelsestid i DAF. |
19-03-2021 kl. 06:54:32 | 20-03-2021 kl. 07:00:00 | Modtagelsestid i DAF for seneste udtrukne registrering er senere end registreringens egen modtagelsestid i DAF. |