Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs datamodel CPR leverer data i form af udtræk. Først leveres et statussudtræk, som indeholder det komplette datasæt. Efterfølgende leveres næsten-daglige deltaudtræk, som indeholder de records som er opstået eller ændret i CPR-systemet siden sidste udtræk. Deltaudtrækkene leveres med varierende tidsintervaller. Der leveres ikke i weekenden og på helligdage, men der leveres normalt på hverdage. Det gør det vanskeligt at overvåge præcist hvornår et deltaudtræk er forsinket. Temporale data CPRs datamodel er en temporal model. CPR-systemet indeholder altså historiske data. Ændringer i CPR-data kan ske både forud og tilbage i tid, eksempelvis er det muligt at registrere både tidligere og kommende adresser for en person. I temporale systemer arbejder man som regel med to tidsbegreber: Valid time og transaction time. Valid time angiver gyldighedsintervaller, dvs. den tidsperiode som data-record er gyldige i. Valid time tidsbegrebet afspejler altså, hvordan eksempelvis en persons adresse har ændret sig over tid. Transaction time angiver transaktionstidpunkter, dvs. hvor en data-record blev registreret af systemet. Bogen Developing Time-oriented Database Applications in SQL kapitel 2 giver en fin introduktion til disse to tidsbegreber og kan hentes gratis her: http://www.cs.arizona.edu/people/rts/tdbbook.pdf. CPR-systemet indeholder valid-time historik på mange records, men ikke alle. I CPRdokumentationen er det angivet ud for hver enkelt felttype om den eksisterer kun i aktuelle records, i aktuelle og historiske records, eller kun i historiske records. For visse felttyper leveres ikke historiske data af juridiske årsager - eksempelvis i forbindelse med adoptioner. For andre felttyper virker det som en arbitrær beslutning - eksempelvis er der ikke historik på en persons adresseringsnavn.
Et væsentligt aspekt ved CPRs temporale data er hvordan data er grupperet i forhold til tidshistorik. CPR har grupperet data om en person i forskellige tabeller, og når en tabel udstyres med historik udtaler gyldighedsintervallet for en record sig om hele den pågældende record. Derfor vil det være vanskeligt at gemme historiske CPR-data med et andet tabellayout end det CPR anvender. Opdelingen i historiske og aktuelle records er afspejlet i udtrækkene, hvor historiske data leveres i andre, men lignende records, som de aktuelle data. Problemet med denne opdeling er at den ikke forholder sig særlig godt til fremtidige records. Spørgsmålet er, om en fremtidig record (eksempelvis en ny adresse) leveres som en aktuel record, som en historisk record, eller om den slet ikke leveres før den bliver aktuel. Vi formoder at fremtidige records leveres som aktuelle records, bare med en fremtidig gyldighedsdato. Det fremgår at CPRs dokumentation (http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270) præcist hvilke felter der har historik. Det bør dog bemærkes at den ikke er opdateret. Eksempelvis leverer CPR historiske oplysninger om folkekirkeoplysninger, selvom det fremgår af dokumentationen at CPR ikke har historiske folkekirkeoplysninger. CPR-udtræk Det er intentionen, at replikeringstjenestens data til enhver tid afspejler CPR-systemets data, dvs. at replikeringstjenestens data er korrekte. Desværre lider CPR-udtræk af nogle uhensigtsmæssigheder, som gør at det er vanskeligt at sikre at data altid er 100% korrekte. Manglende identifikation af records Det største problem med CPRs udtræk er, at CPR ikke identificerer records unikt. Det betyder, at når vi modtager en record fra CPR, så har vi ikke nogen generel metode til at afgøre, om der er tale om en ny record, eller om der er tale om en ændring af en eksisterende record. Hvis vi har modtaget to records af samme type fra CPR for en given person, så har vi altså ingen generel måde at afgøre, om begge records er gyldige, eller den ene har erstattet den anden. For mange recordtyper er der netop én record for hvert personnummer, og i dette tilfælde erstatter den sidst tilkomne record den første (under hensyntagen til gyldighedsperiode). I andre tilfælde er der et variabelt antal records for hvert personnummer. I dette tilfælde kan man lave et kvalificeret gæt. Er der eksempelvis tale om en record af type 4 (Beskyttelse), så er det rimeligt at benytte beskyttelsestypen og personnummeret som nøgle til at afgøre, om der er tale om en ændring eller erstatning af en eksisterende record, eller om der er tale om en ny record. Men dette er ikke nødvendigvis 100% skudsikkert, det kan være at en beskyttelse er registreret med den forkerte beskyttelsestype, og at CPR derfor har ændret beskyttelsestypen for recorden og sendt den igen. Det vil vi aldrig kunne skelne fra en ny record.
Sletning af records CPRs udtræk indeholder ikke information om slettede records på en generel måde. De fleste recordtyper indeholder en slettedato (også for aktuelle records), men nogle recordtyper gør desværre ikke. Det drejer sig om recordtype 5 (aktuelle udrejseoplysninger), recordtype 7 (forsvindingsoplysninger), recordtype 13 (separation). For recordtype 5 kan det udledes fra personens status, om recorden skal slettes (dvs. gøres historisk), da det kun er udrejste personer som har en aktuel record af denne type. Det samme løsning er mulig for recordtype 7. For recordtype 13 kan det formentlig udledes ud fra personens civilstand, hvor der er en henvisning til den aktuelle separation, som formentlig fjernes hvis separationen slettes eller personen bliver skilt. Andre recordtyper der ikke indeholder slettedato opfylder, at der altid er netop én record af den pågældende type (eksempelvis recordtype 8, aktuelle navneoplysninger). Sådanne records slettes ikke med mindre de erstattes af en ny, og dermed er der ikke noget problem. Hændelser CPRs udtræk indeholder også hændelser, som er koder der beskriver hvilke processer en person er gennemgået. Disse hændelseskoder kan muligvis anvendes til at afgøre om records skal slettes eller rettes. Problemet er, at CPR tager stærkt forbehold for at disse hændelseskoder anvendes, da de forbeholder sig ret til at ændre dem uden varsel. Alligevel kan det være værd at undersøge om hændelseskoderne kan anvendes, såfremt der ikke er andre måder. Anbefalinger Anbefaling: Bitemporal datamodel med fuld valid-time og transactiontime historik Det anbefales, at der anvendes en bitemporal datamodel med fuld historik, som beskrevet i bogen Developing Time-oriented Database Applications in SQL kapitel 10. Det betyder, at hver tabel har fire kolonner med tidsstempler, to som angiver valid time og to som angiver transaction time. Anvendelsen af en bitemporal datamodel vil have følgende fordele: Fuld sporbarhed: For en hvilken som helst record i databasen er registreret, hvornår record en blev oprettet. Det gør det muligt at finde ud af hvilken CPR-udtræksfil der er kilde til den pågældende record. Simplere replikering: Indholdet af records ændrer sig ikke. Det kan afgøres alene ud fra recordens transaktionstidsstempler om de skal sendes til en klient eller ej. Det er simplere for klienten at vedligeholde en lokal kopi af data, da records ikke ændrer sig, de invalideres kun. Der er efter vores opfattelse ingen væsentlige ulemper ved at skifte til en bitemporal datamodel.
Anbefaling: Den fysiske datamodel skal afspejle CPRs udtræksmodel Det anbefales, at datamodellen ændres, så den fysiske (SQL) datamodel præcist afspejler CPRs udtræksmodel. Dvs. det anbefales, at der oprettes netop én tabel for hver recordtype, og at felterne i tabellen afspejler felterne i CPRs udtræk præcist. Dog gemmes aktuelle og historiske records i samme tabel, jvf. den bitemporale modellering beskrevet ovenfor. Dette vil have følgende fordele: Simplere implementation: Der skal ikke konverteres til en ny datamodel. Det giver en simplere løsning. Mulighed for korrekt historik: Da historikken i CPRs data følger CPRs datamodel vil det være vanskeligt at vedligeholde en korrekt historik på data med mindre CPRs datamodel følges. Stabil datamodel: Det må formodes, at formatet for CPRs udtræk er meget stabilt, da det må formodes at der er mange klientsystemer der afhænger af dette format. Muligt at implementere CPR-direkte relativt nemt: CPR-direkte benytter samme model som CPRs ændringsudtræk. Det gør det nemmere både at anvende CPR-direkte til onlineopslag (hvis det ønskes), samt at udstille CPR-direkte til systemer som er kodet til at anvende denne snitflade. Anbefaling: De views der udstilles via replikeringstjenesten afspejler fuldstændigt den underliggende fysiske model (og dermed CPRs udtræksmodel). Dermed vil der være præcist et view for hver recordtype i CPRs udtræk. Dog skal der være den forskel, at hver record unikt identificeres, samt at de alle fire tidsstempler udstilles. Dette har følgende fordele: Simplere implementation: Der skal ikke konverteres til en ny datamodel. Det giver en simplere løsning. Klientsystemer kan modtage korrekt historik: Hvis klientsystemerne skal holde styr på historikken skal modellen følge CPRs. Stabil datamodel: Det må formodes, at formatet for CPRs udtræk er meget stabilt, da det må formodes at der er mange klientsystemer der afhænger af dette format. Anbefaling: Der udføres fuldstændig kvalitetskontrol på data Det anbefales, at der jævnligt udføres en fuldstændig og automatiseret kvalitetskontrol af data. Det skal ske ved at der bestilles et nyt totaludtræk, som sammenlignes med indholdet i databasen. Alle afvigelser i dataindhold rapporteres og analyseres. Hvis de ovenstående anbefalinger følges vil det være nemt at sammenligne totaludtrækket med indholdet i databasen, da modellen er ens. Desuden vil det være muligt at føre evt. uoverensstemmelser tilbage til de relevante udtræksfiler, da der er fuld historik på alle data.
Kvalitetskontrollen skal munde ud i, at bugs som forårsager forkerte data kan findes og rettes. Er der tale om datafejl, som ikke skyldes fejl i systemet men derimod mangler i CPRs udtræksformat er det måske muligt at detektere disse fejl når de opstår og korrigere dem ved opslag mod CPRs online-service. Er der tale om datafejl som er helt uundgåelige på grund af mangler i CPRs udtræksformat, er det stadig relevant for klientsystemer at vide hvilke omstændigheder sådanne fejl kan opstå under og hvor tit de sker. Dermed kan man tage stilling til om man vil anvende CPRs online services hvor man sikres helt opdaterede data. Anbefaling: Replikering direkte til klientsystemets database Det anbefales, at der udvikles en komponent, som kan replikere data direkte ned i klientsystemets database. Datamodellen, som komponenten anvender, skal selvfølgelig være identisk med replikeringsservicens SQL-model. Komponenten kan evt. udvides, så den også kan vedligeholde tabeller hvor der kun er aktuelle data, så klientsystemet slet ikke behøver at forholde sig til det temporale aspekt af dataene. Disse tabeller med aktuelle data kan evt. være normaliseret. Fordele: Klientsystemet behøver ikke selv implementere den logik der skal til for at hente, gemme og vedligeholde en lokal kopi af CPR-data. Klientsystemet behøver ikke forholde sig det temporale aspekt af data, hvis klienten ikke har behov for historiske oplysninger Meget lavere barriere og implementationstid for at benytte replikeringstjenesten Kan tjene som demoapplikation for udviklere af klienter som ikke ønsker at benytte komponenten og i stedet ønsker at udvikle egen integration. Anbefaling: Opslagskomponent uden Person Part Det anbefales, at der også laves laves en opslagskomponent, som ikke anvender Person Part formatet. En opslagskomponent, der leverer data med historik, bør anvende samme datamodel som replikeringstjenesten (dvs. samme model som CPRs udtræk har). En opslagskomponent, som leverer data uden historik kan evt. anvende en normaliseret datamodel. I så fald ville det være naturligt at vælge den samme datamodel som anvendes ved replikering direkte til klientsystemers database, som beskrevet ovenfor. Fordele: Enkel og billig at implementere, da data ikke skal konverteres til en ny model Enklere format, som er nemmere for klienten at aftage (dvs. kortere udviklingstid for at tilpasse klientsystemer). Dette gør sig især gældende hvis klienten i forvejen anvender eller forstår CPRs model, eksempelvis fordi klienten i forvejen benytter CPR direkte eller CPR-udtræk. Mindre risiko for fejl, da data ikke først skal konverteres til et komplekst format som ikke er særlig hensigtsmæssigt til at repræsentere CPR-data Historik kan repræsenteres præcist og hensigtsmæssigt Alle data er med
Anbefaling: Klient til opslagskomponent Det anbefales, at der udvikles en klient til opslagskomponenten, som kan gemme data i en database med samme schema-layout som vi selv anvender. Denne komponent kan integreres i klientsystemer, og kan tjene som demoapplikation. Denne bør være enkel at udvikle, da datamodellen er den samme. Anbefaling: Online-opslag Hvis der implementeres funktionalitet til online-opslag af CPR-data, så anbefales det, at resultatet af disse online-opslag kan gemmes i samme database som replikeringstjenesten anvender, sådan at klienter der benytter sig af replikeringsmekanismen til at hente data kan modtage evt. opdaterede eller korrigerede data med det samme. For at kunne diagnosticere evt. kilder til fejl i data i forbindelse med kvalitetskontrol er det nødvendigt, der holdes styr på om en række er opstået på baggrund af en udtræksfil eller på baggrund af et online-opslag.