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.

Følgende eksempler vil sammenlagt vise, at samkørte udtræk ikke er velegnede som basis for kopiregistre.

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.

Lad os sige, at der foretages en samkøring med denne udtrækslogik med inputparameteren

• @Virkningstid = ’2019-01-01’

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)

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’

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)

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:

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:

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:

AND EJF.registreringTil = NULL

Af symmetrigrunde må afregistrerede rækker i EBR også fjernes:

AND EBR.registreringTil = NULL

Vi får herefter dette resultat:

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! 

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:

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:

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:

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:

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:

1. Registreringer, der har virkning i fremtiden set i forhold til den eventuelle angivne virkningstid, vil normalt aldrig blive udtrukket i deltaudtræk.
2. 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: