DAR 0.9 Systembeskrivelse Version 1.0

Transkript

1 DAR 0.9 Systembeskrivelse Version 1.0

2 Versionsoversigt Version Dato Beskrivelse Initialer Version 0.0 oprettet som kopi af arkitekturbeskrivelsen JWT Version 1.0 sendt til KOMBIT JWT DAR 0.9 Systembeskrivelse Side 2 af 52 Version 1.0

3 Indholdsfortegnelse 1 Indledning Systemarkitektur Præsentationslag ADK Klient OIO snitflade Applikationslag Service Interface Lag Batch Lag Forretnings Lag Data Access Lag Datalag Dataudveksling med andre systemer Snitflader, som DAR udstiller Snitflade til BBR (DAR udstiller, BBR kalder) Eksterne ajourføringsservices til 3. part Snitflade til AWS suiten Udtræk som DAR leverer Levering af totaludtræk til AWS Specifikation af CSV format Data, som modtages og indlæses i DAR Indlæsning af data fra CPR Snitflader, som DAR kalder Snitflade til GST Snitflade til certificeringscenter Snitflade til BBR (BBR udstiller, DAR kalder) Datamodel Den logiske datamodel Adgangspunkt Husnummer Adresse Sagsreference Den fysiske datamodel Nøgler Entiteter med historik (Adgangspunkt, husnummer, adresse, sagsreference) Transaktioner og timestamps Tegning af databasemodellen Andre systemtabeller i den fysiske datamodel Tabeller til CPR data Bitemporale egenskaber Konvertering fra BBR adresser til DAR Forretningslogik Matrikel-adresse relation Adresseforekomsters liv Krav om vejkode og husnummer, samt CPR vejstykke Tilknytning af adresser til entiteter i BBR Statusværdier DAR 0.9 Systembeskrivelse Side 3 af 52 Version 1.0

4 5.6 Sammenhæng mellem statusværdier Adressernes entydighed Diverse valideringsregler på entitetsniveau Adgangspunkt Husnummer Adresse Sikkerhed og brugeradgang Brugeradministration Adgang til webservices Adgang til ADK klienten Samtidighedsaspekter Eksempel 1: Adresseanvendelse i DAR Eksempel 2: BBRs mulighed for at oprette og slette adresser i DAR Logning Produktions- og demomiljø Produktionsmiljø Demomiljø Dokumentation Brugervejledninger Brugervejledning til ADK klienten Snitfladebeskrivelser Snitfladebeskrivelse til AddressV Installationsvejledning DAR 0.9 Systembeskrivelse Side 4 af 52 Version 1.0

5 1 Indledning Dette dokument indeholder systemdokumentation for DAR 0.9, som er det nye officielle register over alle adresser i Danmark. Hidtil har BBR - Bygnings- og Boligregistret - været Danmarks officielle adresseregister. Det ændrer sig i maj 2015, hvor adressedelen udskilles fra BBR og lægges over i et nyt selvstændigt register - DAR (Danmarks AdresseRegister). Udviklingen af DAR er et led i Grunddataprogrammets målsætning om, at alle data kun skal registreres et sted og at adgangen til dem skal være sikker, enkel og effektiv. Det nye adresseregister skal på længere sigt ikke kun være autoritativt grunddataregister for adresser, men også for navngivne vejnavne, supplerende bynavne m.m. DAR 0.9 kan benyttes til at vedligeholde følgende adressedata: Adgangspunkter, Husnumre og Adresser. DAR kan tilgås via Adresseklienten ADK samt et sæt OIO snitflader, som 3. parts systemer kan benytte. Systemdokumentation indeholder i alt 7 kapitler, som kort beskrives i det følgende. Kapitel 2: Systemarkitektur Kapitlet giver et overblik over DAR 0.9s overordnede løsningsarkitektur, dvs. løsningens væsentlige komponenter og deres indbyrdes sammenhænge. Kapitlet beskriver således præsentationslaget, applikationslaget og datalaget i systemet. Kapitel 3: Dataudveksling med andre systemer I kapitlet beskrives overordnet de relationer og interaktioner, som findes mellem DAR og dets omgivelser. Kapitel 4: Datamodel I kapitlet beskrives DARs logiske og fysiske datamodel samt implementering af bitemporale egenskaber. Kapitel 5: Forretningslogik I kapitlet beskrives DARs forretningslogik, herunder eksisterende forretningsregler samt valideringer. Kapitel 6: Sikkerhed og brugeradgang I kapitlet beskrives, hvordan sikkerhed og brugeradgang håndteres i DAR 0.9 samt Adresseklienten ADK og OIO snitfladerne. Kapitel 7: Samtidighedsaspekter I kapitlet beskrives samtidighedsaspekter i systemet, specielt i forhold til samspillet mellem BBR og DAR. Kapitel 8: Logning I kapitlet beskrives logning samt fejllogning i systemet. Kapitel 9: Produktions- og demomiljø DAR 0.9 Systembeskrivelse Side 5 af 52 Version 1.0

6 Kapitlet giver et overblik over løsningens teknologiarkitektur, dvs. der beskrives hvordan de enkelte komponenter i løsningen er fordelt på fysiske servere, både i løsningens produktions- og demomiljø. Kapitel 10: Dokumentation/vejledning/hjælp I kapitlet beskrives kort, hvilken yderligere dokumentation der er udarbejdet i forbindelse med levering af DAR 0.9. DAR 0.9 Systembeskrivelse Side 6 af 52 Version 1.0

7 2 Systemarkitektur I dette afsnit beskrives DARs systemarkitektur. Beskrivelsen er givet ud fra et logisk synspunkt og tager ikke stilling til, hvordan de enkelte komponenter er fordelt på fysiske maskiner og databaser. Denne fordeling er beskrevet i kapitel 9 Produktions- og demomiljø. Systemarkitekturen (et overblik) for DAR fremgår af nedenstående figur. DAR Autentifikation ASP.NET MVC Website ADK 0.9 OIO XML Service Gateway Service Agenter Service Agenter DAR Service Interface Lag Batch Service Contract Service Adapter Windows Services/Scheduled tasks Forretnings Lag Forretnings Logik Forretnings Entiteter Data Access Lag Data Access Logik Service Agenter Enitity framework SQL Server DAR Kald til andre systemer - BBR -GST Figur 1 Systemarkitektur DAR 0.9 DAR 0.9 Systembeskrivelse Side 7 af 52 Version 1.0

8 Overordnet består DAR af følgende 3 lag, som er beskrevet nedenfor: Præsentationslag Applikationslag Datalag 2.1 Præsentationslag Præsentationslaget udstiller en browserbaseret brugergrænseflade, ADK klienten, og en webservicebaseret snitflade til 3. parts systemer, baseret på OIOXML ADK Klient ADK er én måde at tilgå DAR 0.9 på. ADK giver mulighed for at oprette og vedligeholde adgangspunkter, husnumre og adresser. En mere detaljeret beskrivelse af ADK findes i brugervejledning for ADK Adresseklient (afsnit Brugervejledning til ADK klienten). ADK Adresseklienten er bygget på Microsofts ASP.NET MVC 4 og følger Microsofts standard skabelon for MVC projekter. Applikationen er opbygget efter SPA princippet (Single Page Application). Model/View/Controller Klient projektets model-lag udgøres af et sæt viewmodels. Hovedparten af disse er bygget på baggrund af de entiteter, der er defineret i forretningslaget og indeholder alle de samme data. Derudover har de enkelte viewmodels egenskaber og metoder der kun bruges til at generere views i klienten. Kommunikation mellem klienten og forretningslaget foregår via WCF webservices og disse benytter sig af forretningslagets entiteter til at strukturere og lagre data til transport. Når der skal indlæses en entitet fra forretningslaget skal denne omformes til klientens viewmodels og når de indberettede data skal lagres skal klientens viewmodels omformes tilbage til noget forretningslaget kan bruge. Til automatisering af denne proces benyttes en open-source komponent kaldet Automapper (ref. automapper.org). Klienten benytter én enkelt master page (/shared/_layout.cshtml) som ramme til alle views. Alle generelle scripts og applikationens stylesheets bliver lagt ind på denne side, mens viewspecifikke scripts bliver koblet til på de underliggende views der bruger dem med erklæring. Hvert område i klienten har sine egne controller, og alle controller er bygget over en base class controller (/Controllers/BaseController.cs), der definerer et minimum af funktionalitet der er tilgængeligt alle steder i applikationen, f.eks. generel fejlhåndtering. Caching Når klient applikationen starter op gemmes udvalgte data i en cache for at undgå stor belastning af båndbredden. Alle elementer i cachen har en levetid på 12 timer og fornyes herefter. Derfor vil eksempelvis en rettelse til et tooltip først slå igennem når cachens levetid er nået eller hvis webhomet genstartes via IIS en (Internet Information Services) DAR 0.9 Systembeskrivelse Side 8 af 52 Version 1.0

9 2.1.2 OIO snitflade OIO snitfladen er den anden måde at tilgå DAR 0.9 på. 3. parts systemer kan benytte en OIO snitflade til at opdatere adressedata. BBR benytter ligeledes en OIO snitflade til at kalde DAR. Hvis en adresseanvender kun har behov for at læse adressedata, henvises den til AWS suiten. OIO snitfladen er udarbejdet efter OWSA Model T standarden (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Modellen bygger på SOAP, HTTPS, OCES certifikater og OIOXML. Se afsnit 3.1 Snitflader, som DAR udstillerfor yderligere detaljer for de udstillede OIO snitflader. 2.2 Applikationslag Applikationslaget er baseret på Microsoft.NET platform. Applikationslaget er implementeret som en serviceorienteret arkitektur og udstiller forretningslogikken som services Service Interface Lag De udstillede services er Windows Communication Foundation Services (WCF). WCF er Microsofts framework til at bygge service-orienterede applikationer. Både ADK adresseklienten, OIOXML snitfladerne og de interne services mellem BBR og DAR benytter de samme WCF services Batch Lag For at indlæse data fra CPR eller danne totaludtræk til AWS benyttes Windows service hhv. scheduled tasks som tilgår DARs Data Access Lag Forretnings Lag Forretningslaget definerer forrentningsobjekter og alt forretningslogik. Se afsnit 4.1 Den logiske datamodel for en detaljeret beskrivelse af forretningsobjekterne samt kapitel 5 Forretningslogik for en beskrivelse af forretningslogikken inkl. valideringsreglerne Data Access Lag Data Access komponenten sørger for mapningen mellem database objekter og forretningslagets business objekter. DARs Data Access Logik bruger Entity Framework til at mappe database tabeller til business objekter, ligeledes foregår kommunikationen mellem DARs Data Access Logik og databasen igennem Entity Framework. 2.3 Datalag Datalaget er ligesom resten af systemet bygget på Microsoft teknologier og kører derfor på Windows Server med SQL Server. DAR 0.9 Systembeskrivelse Side 9 af 52 Version 1.0

10 3 Dataudveksling med andre systemer Dette afsnit ser på hvordan DAR på overordnet niveau interagerer med andre systemer. Nedenstående figur viser et overblik over DARs sammenhæng med forskellige andre systemer. De blå cirkler symboliserer hver et system, som DAR har en afhængighed til Pilene i tegningen symboliser dataflowet mellem DAR og disse systemer. Det kan forekomme, at DAR har flere snitflader til et system. CPR GST Koordinater til adresser Vejstykker mm. Ekstern OIO snitflade Ajourføringsservices(OIO) DAR AWS Adresse data i ny datamodel BBR DAR interne services(oio) BBR Hent certifikater Certificeringsce nter Figur 2 Kontekstdiagram for DAR I de følgende afsnit er hver enkelt snitflade listet. Afsnit Snitflader som DAR udstiller lister alle snitflader, som DAR udstiller og som således kan kaldes af andre systemer. DAR 0.9 Systembeskrivelse Side 10 af 52 Version 1.0

11 Afsnit Udtræk som DAR leverer lister alle udtræk, som DAR leverer. Afsnit Data som modtages og indlæses i DAR lister alle snitflader, hvor der indlæses dataudtræk fra andre systemer. Afsnit Snitflader som DAR kalder lister alle snitflader, som DAR kalder online. 3.1 Snitflader, som DAR udstiller System Intern OIO snitflade til BBR OIO snitflade til 3. part Snitflade til AWS BBR kan oprette og slette adresser i DAR. 3. part kan benytte OIO snitfladen til at opdatere adressedata. AWS kan kalde en snitflade for at hente adresseopdateringer Snitflade til BBR (DAR udstiller, BBR kalder) Denne interne snitflade mellem BBR og DAR bestå af et antal helt specifikke services, som udelukkende benyttes af BBR/DAR. Disse services udstilles ikke til andre. Disse services er udarbejdet som sikre webservices baseret på TLS og certifikater, så BBR 1.7 og DAR 0.9 kan driftsafvikles i separate miljøer. Disse services er udarbejdet efter OWSA Model T (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Når enheder slettes i BBR med en enhedsadresse, som ikke benyttes på andre BBR entiteter, slettes adressen i DAR, hvis det ikke er den sidste enhedsadresse til en adgangsadresse. Når enheder oprettes i BBR med en enhedsadresse, som ikke findes i forvejen, bliver adressen automatisk oprettet i DAR, hvis brugeren har den nødvendige rolle. Der er således identificeret følgende interne services som DAR udstiller til BBR: AdresseOpret AdresseSlet Der oprettes en bruger i BBR, som foretager alle kaldene for alle kommuner til den interne snitflade i DAR. Brugeren skal som den eneste have tilknyttet rollen DARKaldfraBBR, som giver BBR lov til at kalde DARs interne services. Det er denne BBR bruger, som kommer til at stå som bruger for disse opdateringer i DAR, dvs. i DAR vil man ikke kunne identificere den enkelte kommunale bruger Eksterne ajourføringsservices til 3. part I DAR 0.9 implementeres nye ajourføringsservices baseret på den del af den ny informationsmodel, som implementeres i DAR 0.9 dvs. entiteterne Adgangspunkt, Husnummer og Adresse. Disse services udarbejdes efter OWSA Model T standarden. Der er i DAR 0.9 ikke implementeret ajourføringsservices til sagsreferencer, idet sagsreferencebegrebet i DAR 0.9 ikke svarer til det kommende sagsreferencebegreb i DAR 1.0. Følgende services er udarbejdet: AccessPointCreate DAR 0.9 Systembeskrivelse Side 11 af 52 Version 1.0

12 AccessPointDelete AccessPointGetById AccessPointUpdate HouseNumberCreate HouseNumberDelete HouseNumberGetById HouseNumberUpdate AddressCreate AddressDelete AddressGetById AddressUpdate Der er valgt at udarbejde simple services med CRUD funktionerne, som forventes at understøtte behovet for services. En mere detaljeret beskrivelse findes ved at findes i snitfladebskrivelsen (afsnit Snitfladebeskrivelse til AddressV1) Snitflade til AWS suiten DAR 0.9 skal levere adresser til AWS i henhold til den nye datamodel med adgangspunkter, husnumre og adresser. AWS mapper efterfølgende fra den nye model til den gamle adresse datamodel og leverer efterfølgende adresser i den gamle datamodel til BBR. Der findes to snitflader mellem DAR 0.9 og AWS: Webservice til Realtidsopdatering af adresser fra DAR 0.9 til AWS Fuldstændigt adresseudtræk fra DAR 0.9 til AWS Webservicen er beskrevet nedenfor, mens totaludtrækket er beskrevet i afsnit Levering af totaludtræk til AWS. Webservice til AWS Interfacet til AWS implementeres som en webservice som DAR udstiller til AWS. AWS henter således selv opdateringer til Adgangspunkter, Husnumre og Adresser. Udover dette hentes ændringer til vejnavne via DAR (vejnavnene vedligeholdes dog i et register der vedligeholdes af CPR). For at modtage ændringer til adgangspunkter kalder AWS webservicen med parametrene dato fra og dato til. F.eks. http(s)://dar-kommune.dk/services/hentadgangspunkt?fra= :10:50&til= :09:50. Webservicen er beskyttet ved hjælp af IP-begrænsning. Webservicen som udstiller adresseoplysninger til AWS indeholder følgende 4 metoder: HentAdresse(DateTime datefra, DateTime til); HentHusnummer(DateTime datefra, DateTime til); HentAdgangspunkt(DateTime datefra, DateTime til); DAR 0.9 Systembeskrivelse Side 12 af 52 Version 1.0

13 HentVejnavn(DateTime datefra, DateTime til); Levering af hændelser Hændelser levereres via HTTP protokollen og der anvendes JSON som transportformat. Hændelser leveres ved at DAR udstiller en webservice som AWS kalder med et HTTP Get request til en angiven URL, f.eks. http(s)://dar-kommune.dk/services/hentadresse?fra=x&til=x. Leveringen af hændelser skal overholde følgende: Overførslen af hændelser beskyttes ved hjælp af IP-begrænsning Hvert request indeholder en liste af hændelser for hver entitetstype (adgangspunkt, adresse etc.). Der vil højest kunne returneres entiteter i en forespørgsel. Hvis resultatet indeholder mere end entiteter returneres de første entiteter i en ordnet rækkefølge efter opdateret timestamp. DAR garanterer at der maksimalt findes entiteter med samme timestamp i databasen. DAR garanterer at data vil være tilgængelig for AWS minimum 60 sekunder efter at data er oprettet i DAR. Der er ikke krav til at entiteter som hører sammen sendes i samme transaktion. Hverken med hensyn til foreign key constraints mellem typer eller relationer mellem versioner inden for samme type. Metode og struktur Interfacet til AWS implementeres som en Webservice som DAR udstiller til AWS. For at modtage ændringer til adgangspunkter kalder AWS webservisen med parametrene dato fra og dato til. Fx http(s)://dar-kommune.dk/services/hentadgangspunkt?fra= t12:16: :00&til= t12:16: :00. Metoderne og deres struktur er beskrevet for de enkeltvis nedenfor. I modsætning til den nuværende service, fortæller den nye service ikke hvad der skal ske med entiteten. I stedet medsendes en statuskode svarende til status i DAR og det vil så være op til AWS at håndtere hvad der skal ske med entiteten ud fra dens status. Fx Hvis et adgangspunkt har statuskode 2 (Nedlagt) betyder dette at entiteten skal slettes mens statuskode 1 (Gældende) betyder at der skal foretages en ændring eller at entiteten skal oprettes hvis den ikke allerede findes hos AWS. DAR 0.9 Systembeskrivelse Side 13 af 52 Version 1.0

14 HentAdresse Metoden HentAdresse returnerer en liste over adresser, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over adresser med følgende struktur: (JSON)[{ 'versionid':'4e3df510-1e3e-408c-b389-c72b3f93ccfd', 'id':'0a3f50b b8-e ba298018', 'husnummerid':'0a3f5088-ec8b-32b8-e ba298018', 'statuskode':'1', 'etagebetegnelse':'st', 'doerbetegnelse':'', 'esdhreference':'', 'journalnummer':'e ba298018', 'kildekode':'1', 'ikrafttraedelsesdato': ' T12:16: :00', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut:'', }, ] Statuskoden angiver om adressen er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentHusnummer Metoden HentHusnummer returnerer en liste af husnumre, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over husnumre med følgende struktur: (JSON)[{ 'versionid':'b0a5468e-777d-4d97-8c25-325fbdc66c94', 'id':'0a3f5088-ec87-32b8-e ba298018', 'adgangspunktid':'0a3f5088-ec87-32b8-e ba298018', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut':'', 'vejkode':'11', 'husnummer':'003', 'statuskode':'1', 'kildekode':'1', 'ikrafttraedelsesdato': ' T12:16: :00', 'vejnavn':'a.p. Rasmussens Allé', 'postnummer':'5210', 'postdistrikt':'odense NV', 'bynavn':'paarup', }, ] Statuskoden angiver om husnummeret er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentAdgangspunkt Metoden HentAdgangspunkt returnerer en liste af adgangspunkter, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over adgangspunkter med følgende struktur: (JSON)[{ 'versionid':'7c13ace4-1d a9ae-50fbcead300b', 'id':'0a3f5088-ec87-32b8-e ba298018', 'statuskode':'1', 'kildekode':'5', 'nord':' ', 'oest':' ', DAR 0.9 Systembeskrivelse Side 14 af 52 Version 1.0

15 'tekniskstandard':'tk', 'noejagtighedsklasse':'a', 'retning':'234', 'placering':'5', 'kommunenummer':'461', 'esdhreference':'', 'journalnummer':'', 'revisionsdato': ' T12:16: :00', 'registreringstart': ' T12:16: :00', 'registreringslut':'', 'virkningstart': ' T12:16: :00', 'virkningslut':'', }, ] Statuskoden angiver om adgangspunktet er Gældende (1), Nedlagt (2), Foreløbig (3) eller Henlagt (4). HentVejnavn Metoden HentVejnavn returnerer en liste af vejnavne, som er ændret i perioden mellem fra og til. Metoden returnerer en liste over vejnavne med følgende struktur: (JSON)[{ 'kommunekode':'101', 'vejkode':'1010', 'navn':'niels Bohrs Alle', 'adresseringsnavn':'niels Bohrs Alle', 'oprettimastamp': ' T12:16: :00', 'aendringstimestamp': ' T12:16: :00', 'ophoerttimestamp': ' T12:16: :00' }, ] DAR 0.9 skal ikke levere ejendomsnummer til AWS. AWS skal have oplysninger om ejendomsnummer og matrikeloplysninger fra OIS eller GST. Formatering Datoformatet for snitfladen mellem DAR og AWS er ISO8601 med roundtrip formatspecifier (Ex T12:16: :00) Felter med værdien null, angives også som null i json formatet. For decimaltal anvendes punktun som decimal separator. Prefixede foranstående 0 og foranstående samt efterstillede white-space fjernes. 3.2 Udtræk som DAR leverer System AWS - totaludtræk Data DAR leverer en gang i døgnet et totaludtræk til AWS en Levering af totaludtræk til AWS DAR 0.9 leverer fuldstændige adresseudtræk til AWS efter samme principper som BBR i dag leverer fuldstændige adresseudtræk til AWS. Dannelse af udtrækket sker via en scheduled task. DAR 0.9 Systembeskrivelse Side 15 af 52 Version 1.0

16 DAR sender entiteter med alle statusser til AWS. DAR 0.9 leverer adresser til AWS i henhold til den nye datamodel med adgangspunkter, husnumre, adresser samt vejnavne. AWS mapper fra den nye til den gamle adresse datamodel og leverer efterfølgende adresser i den gamle datamodel til BBR. AWS Udtræks-scheduler Udtræks-scheduleren leverer et komplet udtræk af samtlige adresser, husnumre, adgangspunkter og vejnavne. Udtrækkene leveres komplet i en fil for hver entitetstype (Adresse, Husnummer, Adgangspunkt og Vejnavn) og pakkes herefter til en zip-fil (AWS_dato.zip fx AWS_ zip). Zip-filen uploades efterfølgende til den nuværende FTP server. Inden upload ryddes alt indhold i den pågældende mappe. De enkelte filer vil blive gemt med følgende filnavn: Adresse.csv Husnummer.csv Adgangspunkt.csv Vejnavn.csv Strukturen for de enkelte fil-typer vises på de følgende sider Adresse 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'husnummerid [uniqueidentifier]'; 'statuskode [tinyint]'; 'etagebetegnelse [char(2)]'; 'doerbetegnelse [char(4)]'; 'esdhreference [varchar(200)]'; 'journalnummer [varchar(60)]'; 'kildekode [tinyint, null]'; 'ikrafttraedelsesdato [datetime, nul]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]'; Husnummer 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'adgangspunktid [uniqueidentifier]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]'; 'vejkode [smallint]'; 'husnummer [varchar(4)]'; 'statuskode [tinyint]'; 'kildekode [tinyint]'; 'ikrafttraedelsesdato [datetime, null]'; 'vejnavn [varchar(40)]'; 'postnummer [smallint]'; 'postdistrikt [varchar(20)]'; 'bynavn [varchar(50)]' DAR 0.9 Systembeskrivelse Side 16 af 52 Version 1.0

17 Adgangspunkt 'versionid [uniqueidentifier]'; 'id [uniqueidentifier]'; 'statuskode [tinyint]'; 'kildekode [tinyint]'; 'nord [decimal(18,2)]'; 'oest [decimal(18,2)]'; 'tekniskstandard [char(2)]'; 'noejagtighedsklasse [char(1)]'; 'retning [decimal(18,2)]'; 'placering [tinyint, null]'; 'kommunenummer [smallint]'; 'esdhreference [varchar(200)]'; 'journalnummer [varchar(60)]'; 'revisionsdato [datetime, null]'; 'registreringstart [datetime]'; 'registreringslut [datetime, null]'; 'virkningstart [datetime, null]'; 'virkningslut [datetime, null]' Vejnavn 'kommunekode [smallint]'; 'vejkode [smallint]'; 'navn [varchar(40)]'; 'adresseringsnavn [varchar(20)]'; 'oprettimestamp [datetime, null]'; 'aendringstimestamp [datetime]'; 'ophoerttimestamp [datetime, null]' Specifikation af CSV format Alt data pakkes ind i qoutes, hvis data i forvejen indeholder qoutes, escapes disse med karakteren \. Prefixede foranstående 0 og foranstående samt efterstillede white-space fjernes. Special-karakterer som newline og carriage return fjernes fra csv-filen. Hvis felter indeholder null-værdier angives der ingen karakterer. CSV filen leveres i formatet UTF-8. For decimaltal anvendes punktun som decimal separator. 3.3 Data, som modtages og indlæses i DAR System CPR veje, vejstykker, vejnavne m.m. Data DAR indlæser data, som modtages fra CPR (en gang dagligt) Indlæsning af data fra CPR Der indlæses dagligt opdateringer fra CPR omkring veje, vejstykker, postdistrikter, bynavne og lokalitet i DAR 0.9. DAR 0.9 Systembeskrivelse Side 17 af 52 Version 1.0

18 Opdatering sker ved at hente ajourføringsudtræk fra CPR og opdatere relevante tabeller i DAR, herunder attributter på Husnummer tabellen. Indlæsningen sker via en Windows service. 3.4 Snitflader, som DAR kalder System GST geodata til Bygninger, Teknisk anlæg og Adresser Certificeringscenter BBR Data DAR implementeres henter geodata for adresser i GST: - DAR henter koordinater til en matrikel - DAR henter matrikel til givne koordinater - DAR tjekker om en koordinat ligger indenfor kommunegrænsen - DAR henter matrikler ud fra et ejendomsnummer - DAR henter ejendomsnummeret ud fra en matrikel Denne snitflade bruges i forbindelse med autentifikation af brugere ved logon med certifikat (medarbejder-, funktions- og virksomhedscertifikater). DAR kalder BBR for at - Tjekke om en adresse hhv. et husnummer er i brug i BBR - Autentificere brugeren Snitflade til GST Snitflade i DAR, som henter geodata for Adresser: DAR henter koordinater til en matrikel DAR henter matrikel til givne koordinater DAR verificerer om et angivet punkt ligger inden for kommunens grænser. DAR henter matrikler ud fra et ejendomsnummer DAR henter ejendomsnummeret ud fra en matrikel Snitflade til certificeringscenter DAR autentificerer brugere ved logon med certifikat (medarbejder-, funktions- og virksomhedscertifikater) Snitflade til BBR (BBR udstiller, DAR kalder) DAR benytter BBRs brugere og BBRs brugeradministration til at oprette brugere og tildele dem roller. DAR skal autentificere brugere ved at kalde en intern snitflade i BBR 1.7. Hvis oplysninger kan godkendes, returneres brugerens roller til DAR. Idet BBR skal håndtere brugeradministration for DAR, skal der implementeres en snitflade, som gør det muligt for DAR at hente brugerrettigheder i BBR. Se afsnit Sikkerhed og brugeradgang for yderligere detaljer. DAR 0.9 Systembeskrivelse Side 18 af 52 Version 1.0

19 En adgangsadresse/enhedsadresse kan ikke slettes, hvis den benyttes i bygning/bolig delen i BBR. På adressefanen er der et flueben, som angiver, om en adgangsadresse/enhedsadresse benyttes i bygning/bolig delen i BBR Der er således identificeret følgende interne services som BBR udstiller: AdresseIBrug HusnummerIBrug Services til autentifikation og autorisation af en bruger Disse services udarbejdes som sikre webservices baseret på TLS og certifikater, så BBR 1.7 og DAR 0.9 kan driftsafvikles i separate miljøer. Disse services udarbejdes efter OWSA Model T (OIO Web Service Arkitektur model Transportbaseret sikkerhed). Der oprettes en bruger i DAR, som foretager alle kaldene for alle kommuner til den interne snitflade i BBR. Brugeren skal som den eneste have tilknyttet rollen BBRKaldfraDAR, som giver DAR lov til at kalde BBRs interne services. 4 Datamodel I dette kapitel beskrives informationsarkitekturen i løsningen. I afsnit 4.1 beskrives den logiske datamodel. I afsnit 4.2 beskrives den fysiske datamodel. I afsnit 4.3 beskrives kort den gennemførte konvertering af adressedata fra BBR til DAR Den logiske datamodel I dette afsnit beskrives løsningens logiske datamodel. Nedenstående figur viser DAR 0.9s informationsmodel, dvs. modellens entiteter og deres indbyrdes relationer set ud fra et logisk synspunkt Se afsnit til for en oversigt over alle felter for de vigtigste entiteter i den logiske datamodel. DAR 0.9 Systembeskrivelse Side 19 af 52 Version 1.0

20 Figur 3 Informationsmodel for DAR 0.9 DAR 0.9 Systembeskrivelse Side 20 af 52 Version 1.0

21 Den logiske datamodel har følgende entiteter: Adgangspunkt: Et adgangspunkt er defineret som et geografisk punkt i terrænplan, som udpeger en særskilt adgang fra en navngiven vej og ind på et areal eller ind i en BBR-bygning. Adgangspunktet svarer til geometripunktet i den hidtidige BBR Adresse model. Adresse: En adresse er defineret som en struktureret betegnelse, der angiver en særskilt adgang til et areal, en bygning eller en del af en bygning efter reglerne i adressebekendtgørelsen. I en bygning kan flere adresser (med forskellig etage og dørbetegnelse) dele det samme adgangspunkt. Husnummer: Alle adresser, som ligger under et adgangspunkt, deler husnummeret. Husnummeret indgår således i den samlede og fuldstændige adressebetegnelse for hver af disse. Husnummerbetegnelsen består af et tal 1-999, som evt. kan være efterfulgt af et stort bogstav A..Z. På grund af risikoen for forveksling må bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Husnummeret svarer til adgangsadressen i den hidtidige BBR Adresse model. Sagsreference: En sagsreference er en samling af adresseobjekter, der berøres af den samme opdatering af adresseregisteret. En sagsreference er således en slags paraply, som samler referencer til et antal entiteter, og en sagsreference giver på den måde et samlet overblik over de adresseobjekter, der indgår i en opdatering af adressedata. Man kan forestille sig det på den måde, at det er referencen, men ikke selve entiteten, der ligger i sagen. Det betyder også, at hvis entiteten ændres udenom sagen, vil det være synligt i sagen. Ud over at en sagsreference samler adresseobjekter, giver sagsreferencen mulighed for at registrere oplysninger på sagsniveau. Det er f.eks. sagsnummer, titel, et dokument, en kommentar fra ejeren eller en kommentar fra sagsbehandleren. Både foreløbige og gældende adgangspunkter kan ligge i en sag. Adgangspunktsagsreference: For hvert adgangspunkt i en sag kan der tilknyttes nogle sagsrelevante oplysninger, dvs. oplysninger, som kun er relevante i forbindelse med sagen, men ikke efterfølgende, når sagen er afsluttet. Det kan f.eks. være en angivelse af, hvilken slags anvendelse adgangspunktet har, et dokument som viser beliggenheden eller en kommentar fra ejeren. Dokument: Der kan knyttes dokumenter til en sagsreference og til en adgangspunktsagsreference. Husnummersagsreference: I DAR 0.9 kan du kun knytte adgangspunkter til en sagsreference og denne entitet benyttes derfor ikke endnu. Adressesagsreference: I DAR 0.9 kan du kun knytte adgangspunkter til en sagsreference og denne entitet benyttes derfor ikke endnu. De følgende afsnit beskriver de enkelte attributter på entiteterne adgangspunkt, husnummer, adresse og sagsreference. Desuden beskrives forretningsregler for de enkelte felter. DAR 0.9 Systembeskrivelse Side 21 af 52 Version 1.0

22 4.1.1 Adgangspunkt Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. Status Status Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Kommunenummer ESDH-ref Journal nr. Ejendomsnummer Kommunenummer ESDH Reference til kommunens eget ESDH system (max 200 tegn) Journalnummer (max 60 tegn) Ejendomsnummer Feltet er ikke en del af den fysiske datamodel. Data hentes fra GST ud fra koordinaterne. Matrikel Matrikel (Landsejerlav og matrikelnummer) Felterne er ikke en del af den fysiske datamodel. Data hentes fra GST ud fra koordinaterne. Oprettelsesdato Oprettelsesdato for adgangspunkt. Feltet sættes automatisk af systemet. Senest ændret dato Seneste ændringsdato for adgangspunkt. Feltet sættes automatisk af systemet. Information udledes af Registreringstid. Revisionsdato Revisionsdato Dato for seneste revision (godkendelse eller ændring) af geometridata (felterne x-koordinat, y-koordinat, retning). Placering Placering af husnummer i forhold til indsætningspunktet i kortet. Placeringskode (tekstjustering) af husnr.; kodesæt 1-9, jf. DSFL Kilde Kilde til geometri Kodeværdier: DAR 0.9 Systembeskrivelse Side 22 af 52 Version 1.0

23 1 - Oprettet maskinelt på baggrund af teknisk kort 2 - Oprettet maskinelt på baggrund af matrikelnummer tyngdepunkt 3 - Eksternt indberettet af konsulent på vegne af kommunen 4 - Eksternt indberettet af kommunes GIS- eller kortkontor o.l. 5 - Oprettet af kommunens BBR- eller adresseansvarlige (teknisk forvaltning) Teknisk standard Kode for teknisk standard for geometridata Kodeværdier: TD - Husnummer placeres 3 meter inde i bygningen ved det sted hvor indgangsdør e.l. skønnes placeret, eventuelt med en retningsvinkel der er orienteret i forhold til den adressegivende vejs vejmidte TK - Udtrykkelig TK-standard: 3 meter inde i bygning, midt for længste side mod vej og roteret TN - Alm. teknisk standard: bygningstyngdepunkt eller blot i bygning og roteret UF - Uspecificeret/foreløbig; ikke nødvendigvis placeret i bygning, ikke nødvendigvis roteret Nøjagtighedsklasse Nøjagtighedsklasse for adressens koordinater Kodeværdier: Adgangspunktretning Retningsvinkel A - Absolutte adressekoordinater - stedfæstelsen bør pege på det rigtige objekt, jf. specifik f. teknisk kort B - Beregnet koordinatsæt, foreløbig, omtrentlig stedfæstelse U - Adresse uden koordinater - stedfæstelse ukendt Retningsvinkel for tekst i gon, jf. TK-standard: Koordinat (x) X-koordinat i UTM ETRS89 Zone 32 Koordinat (y) Y-koordinat i UTM ETRS89 Zone 32 FindesDARsag Boolean True hvis adgangspunktet ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. Virkningstid Registreringstid Se afsnit Bitemporale egenskaber Se afsnit Bitemporale egenskaber DAR 0.9 Systembeskrivelse Side 23 af 52 Version 1.0

24 4.1.2 Husnummer Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. AdgangspunktId Status Id for adgangspunktet som husnummeret referer til Status Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Oprettelsesdato Oprettelsesdato for husnummeret. Datoen sættes automatisk. Senest ændret dato Seneste ændringsdato for husnummeret. Datoen sættes automatisk. Information udledes af Registreringstid. Ikrafttrædelsesdato Dato for husnummerets ikrafttrædelse. Ikrafttrædelsesdato sættes automatisk til den dato, hvor husnummeret ændrer status fra Foreløbig til Gældende. Vejkode + vejnavn Vejkoden vises med fire cifre, altså evt. med foranstillede 0. Husnummer + bogstav Postnummer Husnummerbetegnelse. Et husnummer består af indtil fire tegn. Et husnummer består altid af et tal i intervallet fra 1 til 999 som eventuelt kan være suppleret af ét stort bogstav fra A til Z. På grund af risikoen for forveksling må bogstaverne I, J, O og Q dog ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Postnummer Feltet opdateres automatisk ud fra vejkode og husnummeret. Postdistrikt/navn Postdistrikt Feltet opdateres automatisk ud fra vejkode og husnummeret. Suppl. bynavn Supplerende bynavn Feltet opdateres automatisk ud fra vejkode og husnummeret. DAR 0.9 Systembeskrivelse Side 24 af 52 Version 1.0

25 Kilde Kilde til husnummeret Kodeværdier: 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l Oplysning fra anden kilde FindesDARsag Boolean True hvis husnummeret ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. IBrugIBBR Boolean True hvis husnummeret (adgangsadressen) benyttes i BBR. Feltet findes ikke i den fysiske database, men bliver beregnet. Virkningstid Registreringstid Se afsnit Bitemporale egenskaber Se afsnit Bitemporale egenskaber Adresse Felt Id Beskrivelse UUID Feltet sættes automatisk af systemet. HusnummerId Status Husnummeret som adressen referer til. Status Kodeværdier: 1- Gældende 2- Nedlagt 3- Foreløbig 4- Henlagt Etagebetegnelse Korrekte etagebetegnelse kan være følgende BLANK DAR 0.9 Systembeskrivelse Side 25 af 52 Version 1.0

26 ST Stuen KL Kælder Dørbetegnelse Side/dørnummer kan indeholde: BLANK TV, MF, TH, , bogstaver,kombinationer af bogstaver (A-Z) og tal, samt tegnene skråstreg og bindestreg. ESDH reference Journal Kilde ESDH Reference til kommunens eget ESDH system (max 200 tegn) Journalnummer (max 60 tegn) Kilde til adressen Kodeværdier: Ikrafttrædelsesdato Ikrafttrædelsesdato 1 - Oprettet af kommunen iht. adressecirkulæret 2 - Oplysning fra ejer 3 - Oplysning fra teknisk kort 4 - Oplysning fra KRR Manuel 5 - Oplysning fra KRR Administrativ 6 - Oplysning fra ESR 7 - Oplysning fra CPR 8 - Oplysning fra CVR 9 - Oplysning fra post 10 - Oplysning fra 112 o.l Oplysning fra anden kilde Ikrafttrædelsesdato sættes automatisk til den dato, hvor adressen ændrer status fra Foreløbig til Gældende. Oprettelsesdato Oprettelsesdato Datoen sættes automatisk. Senest ændret dato Seneste ændringsdato Datoen sættes automatisk. Information udledes af Registreringstid. FindesDARsag Boolean True hvis adressen ligger i en sagsreference. Feltet findes ikke i den fysiske database, men bliver beregnet. IBrugIBBR Boolean True hvis adressen (enhedsadressen) benyttes i BBR. DAR 0.9 Systembeskrivelse Side 26 af 52 Version 1.0

27 Feltet findes ikke i den fysiske database, men bliver beregnet. Virkningstid Registreringstid Se afsnit Bitemporale egenskaber Se afsnit Bitemporale egenskaber Sagsreference Felt Status Sagsnummer Beskrivelse Status angiver om sagen stadig er aktiv eller om den er nedlagt. Sagsnummer Sagsnummer skal være entydigt. Oprettelsesdato Oprettelsesdato Feltet opdateres automatisk af systemet. Titel Max-X Max-Y Min-X Max-X Titel på sagen Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Feltet opdateres automatisk af systemet ud fra det område det markeres på kort. Kommentar fra ejer Kommentar fra ejer Kommentar fra sagsbeh. Dokumenter Kommentar fra sagsbehandler Det er muligt at uploade dokumenter til en sag. Dokumenter skal være af typen.docx eller.pdf. DAR 0.9 Systembeskrivelse Side 27 af 52 Version 1.0

28 4.2 Den fysiske datamodel Den fysiske datamodel er lavet på baggrund af den logiske datamodel. Nogle felter fra den logiske datamodel er dog beregnede og er derfor ikke en del af den fysiske datamodel: Matrikel (felterne landsejerlavskode, matrikelnummer), oplysning findes i GST Ejendomsnummeret, oplysning findes i GST IBrugIBBR (er adressen i brug i BBR) FindesDARSag (ligger entiteten i en DAR sag) Nøgler Primærnøgler i databasen er implementeret som integer, som automatisk tælles et op. Entiteternes unikke identifier (UUID) angives med præfiks BK_ Fremmednøgler har i databasen præfiks FK_ Entiteter med historik (Adgangspunkt, husnummer, adresse, sagsreference) Den fysiske datamodel består for hver entitet (som har historik) af en hovedtabel og en versionstabel. Disse tabeller er lavet for at håndtere historik (bitemporale egenskaber). Se afsnit Bitemporale egenskaber for yderligere detaljer vedrørende bitemporale egenskaber i DAR. De to implementerede tabeller hedder f.eks. Adresse og AdresseVersion. Den ene tabel (f.eks. Adresse) håndterer relationer til øvrige entiteter. Den anden tabel (f.eks. AdresseVersion) indeholder alle tidligere samt de aktuelle versioner. Der oprettes desuden 3. tabel per entitet (f.eks. AdresseAktuelt), som kun indeholder den aktuelle gældende version af en entitet. Årsagen til denne implementering er performancehensyn. Nedenstående figur viser den fysiske database for de tre entiteter Adgangspunkt, Husnummer of Adresse (dog uden tabellerne AdresseAktuelt, HusnummerAktuelt og AdgangspunktAktuelt), DAR 0.9 Systembeskrivelse Side 28 af 52 Version 1.0

29 4.2.3 Transaktioner og timestamps Der er indført en tabel Transaktion for at kunne sammenknytte rækker der er blevet opdateret som følge af en sammenhængende opdatering af relaterede entiteter i en transaktion. Ved indsættelsen af en række i f.eks. Adgangspunkt sættes FK_RegistreringStartTransaktion_id til den transaktion der forårsager indsættelsen og det vil være igennem denne transaktion at logiske felter som RegistreringStart, OpretBruger og AendretFunktion udledes. DAR 0.9 Systembeskrivelse Side 29 af 52 Version 1.0

30 DBRegistreringStartTimestamp er det faktiske tidspunkt hvor rækken blev indsat i tabellen og er ikke det samme som RegistreringStart da RegistreringStart er delt på tværs af alle entiteter der er blevet opdateret samlet. DBRegistreringStartTimestamp er udelukkende tænkt til intern brug i systemet i forbindelse med f.eks. fejlsøgning men bliver måske også nødvendig i forbindelse med udtrækkene til AWS, for at sikre at en oprettelse og en nedlæggelse der kommer i forbindelse med samme transaktion vil komme i den rigtige rækkefølge i opdateringerne til AWS. DAR 0.9 Systembeskrivelse Side 30 af 52 Version 1.0

31 Hovedtabel Hver række i hovedtabellen bliver kun rørt 1 gang, når den oprettes. DBIndsaetTimestamp: Faktiske tidspunkt for hvornår entiteten blev oprettet. FK_RegistreringStartTransaktion_id: Transaktion, som har oprettet rækken i databasen. Versionstabel Hver række i Versionstabellen bliver kun rørt 2 gange: når den oprettes og når der sættes Registeringsslut tidspunktet. DBRegistreringStartTimestamp: Faktiske tidspunkt for hvornår entiteten blev oprettet. DBRegistreringSlutTimestamp: Fatiske tidspunkt for hvornår entiteten blev opdateret. Desuden referer hver række i Versionstabellen til to transaktioner, som gemmes i en Transaktion tabel: FK_RegistreringStartTransaktion_id: peger på den transaktion, som har oprettet rækken i databasen, RegistreringTimestamp i den transaktion svarer til RegsitreringStart tidspunktet. FK_OpdatererTransaktion_id: peger på den transaktion, som har opdateret rækken i databasen. RegistreringTimestamp i den transaktion svarer til RegsitreringSlut tidspunktet. Transaktiontabel Her findes oplysninger om - Tidspunkt for transaktionen (RegistreringTimestamp) - Brugeren som udførte transaktionen - Den funktion i programmerne som udførte transaktionen En fuldstændig oversigt over den fysiske database kan først leveres på et senere tidspunkt Tegning af databasemodellen Datamodellen for DAR 0.9 ser ud som vist på de to nedenstående tegninger. Første tegning er uden sagsreference tabellerne, mens 2. tegning viser sagsreference tabellerne. Bemærk: Implementering af den fysiske database er i skrivende stund ikke afsluttet og der forventes at der kommer justeringer i udviklingsforløbet. DAR 0.9 Systembeskrivelse Side 31 af 52 Version 1.0

32 Figur 4: Den fysiske datamodel for DAR 0.9 (uden sagsreferencer) Adgangspunkt Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTransakti... DBRegistreringStartTimestamp AdgangspunktAktuelt Adgangspunkt_id FK_AdgangspunktVersion... BK_Adgangspunkt_id StatusKode KildeKode Nord Oest TekniskStandard Noejagtighedsklasse Retning Placering KommuneNummer ESDHReference Journalnummer Revisionsdato VirkningStart VirkningSlut FoersteRegistreringStart BK_FoersteRegistreringS... RegistreringStart BK_RegistreringStart_Ak... RegistreringSlut AdgangspunktVersion AdgangspunktVersion_id FK_Adgangspunkt_id StatusKode KildeKode Nord Oest TekniskStandard Noejagtighedsklasse Retning Placering KommuneNummer ESDHReference Journalnummer Revisionsdato VirkningStart VirkningSlut DBRegistreringStartTime... FK_RegistreringStartTra... DBRegistreringSlutTimes... FK_RegistreringSlutTran... Adresse Adresse_id BK_Adresse_id FK_RegistreringStartTransakti... DBRegistreringStartTimestamp AdresseAktuelt Adresse_id FK_AdresseVersion_id FK_Husnummer_id StatusKode ESDHReference Journalnummer KildeKode IKrafttraedelsesDato Doerbetegnelse Etagebetegnelse VirkningStart VirkningSlut BK_OpretAktoer_id OpretTimestamp BK_AendretAktoer_id AendretTimestamp AdresseVersion AdresseVersion_id FK_Adresse_id FK_Husnummer_id StatusKode ESDHReference Journalnummer KildeKode IKrafttraedelsesDato Doerbetegnelse Etagebetegnelse VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransakti... DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktio... Husnummer Husnummer_id BK_Husnummer_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp HusnummerAktuelt Husnummer_id FK_HusnummerVersion_id FK_Adgangspunkt_id Vejkode Husnummer StatusKode KildeKode Vejnavn Postnummer Postdistrikt Bynavn IKrafttraedelsesDato VirkningStart VirkningSlut BK_OpretAktoer_id OpretTimestamp BK_AendretAktoer_id AendretTimestamp HusnummerVersion HusnummerVersion_id FK_Husnummer_id FK_Adgangspunkt_id Vejkode Husnummer StatusKode KildeKode Vejnavn Postnummer Postdistrikt Bynavn IKrafttraedelsesDato VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id DarLog DarLog_id BK_DarLog_id FK_Transaktion_id CategoryID EventID Priority SeverityID Title LogTimestamp MachineName ProcessName HandlingInstanceID FK_Bruger_id ElapsedTime ExternalElapsedTime ServiceName Action Message FormattedMessage ResultID ClientType LogXml KommuneKode Felt Felt_id Entitetnavn Feltnavn Kraevet OpretTimestamp AendretTimestamp AendretFunktion FK_AktoerOpret_id FK_AktoerAendret_id OphoertTimestamp Transaktion Transaktion_id BK_Aktoer_id RegistreringTimestamp Funktion DBRegistreringStartTim... Valideringsfejl Valideringsfejl_id Kode Tekst OpretTimestamp AendretTimestamp AendretFunktion FK_AktoerOpret_id FK_AktoerAendret_id OphoertTimestamp

33 DAR 0.9 Systembeskrivelse Side 33 af 52 Version 1.0 Figur5: Den fysiske datamodel: Sagsreferencer Adgangspunkt Adgangspunkt_id BK_Adgangspunkt_id FK_RegistreringStartTrans... DBRegistreringStartTimest... AdgangspunktSagsreference AdgangspunktSagsreference_id BK_AdgangspunktSagsreference_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp AdgangspunktSagsreferenceAktuelt AdgangspunktSagsreference_id FK_AdgangspunktSagsreferenceVersion_id FK_Sagsreference_id FK_Adgangspunkt_id AdgangspunktAnvendelseKode Etageadgang KommentarSagsbehandler KommentarEkstern VirkningStart VirkningSlut BK_OpretAktoer_id OpretTimestamp BK_AendretAktoer_id AendretTimestamp AdgangspunktSagsreferenceVersion AdgangspunktSagsreferenceVersion_id FK_AdgangspunktSagsreference_id FK_Sagsreference_id FK_Adgangspunkt_id AdgangspunktAnvendelseKode Etageadgang KommentarSagsbehandler KommentarEkstern VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id Adresse Adresse_id BK_Adresse_id FK_RegistreringStartTrans... AdresseSagsreference AdresseSagsreferen... BK_AdresseSagsref... FK_RegistreringStar... DBRegistreringStart... AdresseSagsreferenceAktuelt AdresseSagsreference_id FK_AdresseSagsreferenceVersion_id FK_Sagsreference_id FK_Adresse_id VirkningStart VirkningSlut BK_OpretAktoer_id OpretTimestamp BK_AendretAktoer_id AendretTimestamp AdresseSagsreferenceVersion AdresseSagsreferenceVersion_id FK_AdresseSagsreference_id FK_Sagsreference_id FK_Adresse_id VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktio... DBRegistreringSlutTimestamp Husnummer Husnummer_id BK_Husnummer_id FK_RegistreringStartTrans... HusnummerSagsreference HusnummerSagsreference_id BK_HusnummerSagsreference_id FK_RegistreringStartTransaktion_id DBRegistreringStartTimestamp HusnummerSagsreferenceAktuelt HusnummerSagsreference_id FK_HusnummerSagsreferenceVersion_id FK_Sagsreference_id FK_Husnummer_id VirkningStart VirkningSlut BK_OpretAktoer_id OpretTimestamp BK_AendretAktoer_id AendretTimestamp HusnummerSagsreferenceVersion HusnummerSagsreferenceVersion_id FK_HusnummerSagsreference_id FK_Sagsreference_id FK_Husnummer_id VirkningStart VirkningSlut DBRegistreringStartTimestamp FK_RegistreringStartTransaktion_id DBRegistreringSlutTimestamp FK_RegistreringSlutTransaktion_id Sagsreference Sagsreference_id BK_Sagsreference_id FK_RegistreringStartTrans... DBRegistreringStartTimesta... SagsreferenceAktuelt Sagsreference_id FK_SagsreferenceV... Kommunenummer Sagsnummer Titel Sagsbehandler MinX MaxX MinY MaxY DybtLink KommentarSagsbeh... KommentarEkstern StatusKode VirkningStart VirkningSlut BK_OpretAktoer_id SagsreferenceVersion SagsreferenceVersi... FK_Sagsreference_id Kommunenummer Sagsnummer Titel Sagsbehandler MinX MaxX MinY MaxY DybtLink KommentarSagsbeh... KommentarEkstern StatusKode VirkningStart VirkningSlut DBRegistreringStart...

34 4.2.5 Andre systemtabeller i den fysiske datamodel Endvidere er der i den fysiske datamodel tilføjet nogle systemtabeller som benyttes internt i DAR 0.9 og som ikke har en logisk pendant. Valideringsfejl Tabellen Valideringsfejl benyttes til at gemme alle valideringsbeskeder som findes i DAR. Darlog Tabellen Darlog benyttes til at gemme logninger. (se også kapitel 0

35 Logning). Felt Tabellen Felt indeholder alle felter, som findes, sammen med den entitet de ligger på og sammen med angivelse af, om felterne er krævede (attribut Kraevet ) Tabeller til CPR data Følgende tabeller vedligeholdes ved indlæsning af data fra CPR. Vej Vejstykke Postdistrikt By Bitemporale egenskaber I DAR er implementeret dobbelthistorik ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter virkningstid og registreringstid håndteres i sammenhæng. Alle entiteter repræsenteres fysisk i to tabeller - en hovedtabel, som indeholder id/nøgle, og en versionstabel, som indeholder entitetens attributter i en eller flere versioner. Hver gang der foretages en opdatering af en entitet, indsættes en ny række i versionstabellen. Alle versioner betragtes som dele af stamdataobjektet, og har den samme identifikation. Ændres en enkelt attributværdi, betragtes dataobjektet som ændret og dermed versioneret. Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. OBS: Vær opmærksom på, at selv om modellen understøtter bitemporale egenskaber så der i nuværende version ikke er muligt at håndtere/benytte flere virkningstider igennem OIO snitfladerne eller igennem ADK adresseklienten. Når data rettes, gemmes den gamle version med RegisteringsSlut og der oprettes to nye versioner i Version tabellen. DAR Systembeskrivelse Side 35 af 52 Version 1.0

36 Eksempel for et adresselivsforløb I det følgende beskrives et livsforløb for en adresse i DAR 0.9: Adressen oprettes Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Adressen ændres til gældende reel ændring Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Foreløbig ST TV Gældende ST TV Adressen nedlægges Status Etagebetegnelse Side/dør Reg start Reg Slut Virk Start Virk Slut Foreløbig ST TV Foreløbig ST TV Gældende ST TV Gældende ST TV Nedlagt ST TV I DAR 0.9 vil alle ændringer blive håndteret som reelle ændringer og der er ingen mulighed for at lave fejlrettelser tilbage i tiden. DAR 0.9s datastruktur er dog forberedt til at kunne understøtte dette senere. DAR Systembeskrivelse Side 36 af 52 Version 1.0

37 4.3 Konvertering fra BBR adresser til DAR 0.9 Dette afsnit vil give et kort overblik over konverteringen af adresser fra BBR til DAR 0.9. Detaljer for den gennemførte konvertering fremgår af konverteringsnotatet og beskrives ikke her. Adresserne fra BBR Adresse og ADK 0.9 (BBRs udvidede datamodel) er blevet kopieret til DAR 0.9 og danner datagrundlaget for DAR 0.9. BBR ADK 0.9 DAR 0.9 Fra BBR til DAR 0.9 Entiteterne fra BBR (tabellerne geometri, adgangsadresse og enhedsadresse) er blevet konverteret til entiteterne i DAR 0.9 (tabellerne adgangspunkt, husnummer og adresse). De entiteter der hørte sammen i BBR hører også sammen i DAR nu efter konverteringen. BBRs adressesager (tabel Adressesag) er ikke konverteret til DAR 0.9. Overordnet kan man sige, at et adgangsadressepunkt (geometripunkt) konverteres til et adgangspunkt, en adgangsadresse til et husnummer, og en enhedsadresse til en adresse. GEOMETRI ADGANGSADRESSE ENHEDSADRESSE Konverteres til Konverteres til Konverteres til ADGANGSPUNKT HUSNUMMER ADRESSE Fra ADK 0.9 til DAR 0.9 Konverteringen af data fra ADK 0.9 (BBRs udvidede datamodel) til DAR 0.9 er foregået mere eller mindre en-til-en. Konvertering af status fra BBR /ADK 0.9 til DAR 0.9 BBR DAR Godkendt/Gældende Gældende 2 Slettet Nedlagt 3 Foreløbig Foreløbig 4 Afsluttet sagsentitet Konverteres til Henlagt 5 Foreslået Foreløbig Konvertering af historik fra BBR/ADK 0.9 til DAR 0.9 BBRs adresser er konverteret til DAR 0.9 under hensyntagen af den ovenfor beskrevne model for historik med registrerings- og virkningstid. Det samme gælder for konverteringen af BBRs felthistorik. Alle ændringer i BBR er i den forbindelse håndteret som reelle ændringer. DAR Systembeskrivelse Side 37 af 52 Version 1.0

38 BBRs tidsstempler skal konverteres til den ovenfor omtalte model med virkningstid og registreringstid. Registreringer i BBR er i dag altid gældende fra det tidspunkt opdateringen foretages. Dvs. at der hverken registreres med tilbagevirkende kraft eller med virkning gældende fra en fremtidig dato. Det betyder konkret, at virkningstid-start og registreringstid-start altid vil være ens. For hver række i BBRs tabel oprettes der en række i tilsvarende stamdataobjekt tabel i DAR og en række i tilhørende versions-tabel. I forbindelse med konvertering af historik vil der blive tilføjet yderligere rækker i versionstabellen med historisk registreringstid, hvis entiteten er blevet rettet siden dens oprettelse. DAR Systembeskrivelse Side 38 af 52 Version 1.0

39 5 Forretningslogik I dette kapitel beskrives DARs forretningslogik. Forretningslaget sørger for feltvalidering af de indberettede data hvad enten disse indberettes gennem ADK adresseklienten eller gennem de etablerede OIO snitflader, idet begge tilgange benytter de samme webservices i applikationslaget. Om et felt er krævet eller ej, gemmes i database tabellen Felt. Det er denne tabel, forretningslaget slår op i for at validere krævede felter. Ud over den i forretningslaget implementerede validering, foretages der skemavalidering for de data der indberettes gennem de eksterne OIO snitflader. Skemavalideringen sikrer, at de indberettede data overholder de datarestriktioner skemaerne definerer. 5.1 Matrikel-adresse relation Der findes ingen administrative ESR matrikler i DAR 0.9. Adgangspunkter kan således kun knyttes til GST matrikler. Det er adgangspunktets koordinat, som bestemmer matriklen. Matrikel-adresse relationen i DAR er således en afledt relation ud fra adgangspunktets koordinat. Matrikel oplysninger persisteres ikke i DAR. 5.2 Adresseforekomsters liv Et adgangspunkt, et husnummer eller en adresse bibeholder altid sin entydige ID. En adresse kan ikke flyttes til et andet husnummer, men vil altid være tilknyttet det samme husnummer i sin levetid. Et husnummer kan desuden ikke flyttes til et andet adgangspunkt, men vil altid være tilknyttet det samme adgangspunkt i sin levetid. 5.3 Krav om vejkode og husnummer, samt CPR vejstykke Gældende adresser skal have vejkode og husnummer, og de skal ligge på et CPR vejstykke. Foreløbige adresser behøver ikke at have en vejkode hhv. et husnummer og de behøver således ikke ligge på CPR vejstykker. 5.4 Tilknytning af adresser til entiteter i BBR Når adresser tilknyttes til niveauer i BBR kan følgende husnumre/adresser benyttes: Gældende husnumre/adresser Foreløbige husnumre/adresser med vejkode og husnummer (dog ligger de ikke nødvendigvis på godkendte CPR vejstykker). 5.5 Statusværdier Statusværdier for entiteterne adgangspunkt, husnummer og adresse i DAR 0.9 er følgende: Foreløbig Entiteten er oprettet, men har ikke nødvendigvis vejkode, husnummer m.m. Adressen kan kun knyttes til BBR entiteter hvis den har vejkode og husnummer. DAR Systembeskrivelse Side 39 af 52 Version 1.0

40 Gældende Nedlagt Henlagt Adressen behøver ikke at ligge på et godkendt CPR vejstykke. Entiteten er gældende. Entiteten er nedlagt og har tidligere været gældende. Entiteten er henlagt og har tidligere været foreløbig. 5.6 Sammenhæng mellem statusværdier En adresse skal ligge under et husnummer som er mindst lige så betydende. Et husnummer skal ligge under et adgangspunkt som er mindst lige så betydende. Dvs. der kan ikke ligge entiteter med en højere status under entiteter med en lavere status. En entitet med status gældende må ikke rettes tilbage til status foreløbig. En entitet med status henlagt må ikke rettes tilbage til status foreløbig. En entitet med status nedlagt må ikke rettes tilbage til status gældende. 5.7 Adressernes entydighed Husnumre med status foreløbig og gældende skal være entydig på kommunenummer, vejkode og husnummer (hvis vejkode og husnummer er angivet). Gældende husnumre skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Der må gerne eksistere flere foreløbige husnumre uden vejkode eller uden husnummerbetegnelse. Foreløbige husnumre, som har vejkode og husnummer skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Husnumre (gældende og foreløbige med vejkode og husnummer) skal være entydige på kommunenummer, vejkode og husnummerbetegnelse. Dvs. der må ikke findes et godkendt og et foreløbigt husnummer med samme kommunenummer, vejkode og husnummerbetegnelse. Denne regel er mere restriktiv end det er tilfældet i BBR i dag. Gældende og foreløbige adresser skal være entydige på husnummeret, etage og side/dørnummer. Dette gælder også hvis det tilhørende husnummer ikke har en vejkode eller en husnummerbetegnelse. 5.8 Diverse valideringsregler på entitetsniveau Adgangspunkt Felt Status DAR Feltet er krævet og de gældende kodeværdier skal benyttes. DAR Systembeskrivelse Side 40 af 52 Version 1.0

41 Se også afsnit 5.5 og 5.6. Kilde Feltet er krævet for alle adgangspunkter uanset status. De gældende kodeværdier skal benyttes. ADK Adresseklient I ADK adresseklienten sættes kilde automatisk til Oprettet maskinelt på baggrund af matrikelnummer tyngdepunkt (kode 2) hvis brugeren angiver matrikeloplysninger (ny opret funktionalitet). Koden sættes til Oprettet af Teknisk Forvaltning (kode 5) hvis brugeren sætter punktet på kortet eller flytter/retter eksisterende punkt på kortet OIO I OIO snitfladerne kan alle kodeværdier vælges. X,Y koordinater Felterne er krævede for alle adgangspunkter uanset status. Der må ikke oprettes eller opdateres koordinater med værdien (0,0). x, y koordinater skal ligge i kommunen. Reglen vedligeholdes i DAR 0.9 ved hjælp af webservice kald til GST. Adgangspunktet kan oprettes/opdateres selv om GST ikke kan levere et passende kommunenummer eller GST leverer et andet kommunenummer. I givet fald leveres der en besked tilbage som gør brugeren opmærksom på, at punktet ligger udenfor kommunen. ADK Beregnede koordinater i klient (ny opret funktionalitet) I forbindelse med den nye opret funktionalitet i ADK Adresseklient hentes foreløbige koordinater fra GST ud fra matriklen. Punktet kan efterfølgende flyttes på plads i kortet. OIO Når der opdateres data igennem OIO snitfladerne hentes der ikke beregnede koordinater fra GST, men koordinaterne skal angives. Nøjagtighedsklasse Feltet er krævet for alle adgangspunkter uanset status. Der må ikke oprettes adgangspunkter uden at der er angivet koordinater, derfor er kodeværdien U ikke tilladt ved oprettelser og opdateringer. Ved opdatering kan en dårlig nøjagtighedsklasse ikke overskrive en bedre nøjagtighedsklasse. ADK Adresseklient Når et adgangspunkt oprettes igennem ADK Adresseklienten, DAR Systembeskrivelse Side 41 af 52 Version 1.0

42 sættes nøjagtighedsklasse automatisk til enten A eller B, alt efter om brugeren sætter punktet i kortet eller om brugeren angiver matrikeloplysninger i stedet for. Når nøjagtighedsklassen er B og brugeren efterfølgende flytter adgangspunktet på plads i kortet eller opdaterer dens retning, sættes nøjagtighedsklassen automatisk til A. OIO Feltet skal angives. I OIO snitfladerne kan alle kodeværdier (undtagen U) vælges. Revisionsdato Feltet er krævet. Ved opdatering skal revisionsdato være lig med eller nyere end eksisterende revisionsdato. Hvis revisionsdatoen ikke angives eller hvis revisionsdatoen er uændret, men koordinaterne eller retning er ændret, sættes revisionsdatoen automatisk til dagsdato. Dette gælder både for ADK adresseklienten og OIO snitfladen. ADK Adresseklient I ADK Adresseklient sættes revisionsdato automatisk til dagsdato hvis koordinat eller retning ændres. OIO I OIO snitfladen angives revisionsdato ved oprettelser og opdateringer. Hvis datoen ikke angives eller er uændret, sættes den til dagsdato, hvis koordinat eller retning er ændret. Journalnummer ESDH reference Journalnummer må højst bestå af 60 tegn. ESDH reference må højst bestå af 200 tegn. Placering Et heltal: 1, 2, 3, 4, 5, 6, 7, 8 eller 9. Feltet er krævet uanset status. Hvis feltet ikke angives, sættes værdien automatisk til 5 ved oprettelser. ADK Adresseklient I ADK Adresseklient er feltet per default sat til 5, men kan ændres. Når et adgangspunkt oprettes igennem Adresseklientens nye opret funktionalitet sættes feltet automatisk til 5. Sagsbehandleren kan efterfølgende rette værdien på adgangspunktet skærmbilledet. OIO I OIO snitfladerne angives placering ved oprettelser og DAR Systembeskrivelse Side 42 af 52 Version 1.0

43 opdateringer. Hvis feltet ikke angives ved oprettelser, sættes den til 5. Retning Et decimaltal mellem 0.00 og Feltet er krævet for alle adgangspunkter uanset status. ADK Adresseklient I ADK opdateres feltet via kortet. Feltet er sat til per default. Når et adgangspunkt oprettes igennem Adresseklientens nye opret funktionalitet sættes feltet automatisk til Sagsbehandleren kan efterfølgende rette værdien på adgangspunktet skærmbilledet. OIO I OIO snitfladerne angives retning ved oprettelser og opdateringer. Hvis feltet ikke angives, sættes retning til Teknisk standard Feltet er krævet for alle adgangspunkter uanset status. Alle kodeværdier kan benyttes. ADK Adresseklient I ADK adresseklienten sættes teknisk standard automatisk til UF hvis brugeren opretter adgangspunktet ved at angive en matrikel (uden at angive punktet på kortet) Hvis punktet er oprettet med teknisk standard UF og senere flyttes på plads i kortet, kan sagsbehandleren rette koden til. OIO I OIO snitfladerne angives teknisk standard ved oprettelser og opdateringer og alle kodeværdier kan benyttes Husnummer Felt Status DAR Feltet er krævet og de gældende kodeværdier skal benyttes. Se også afsnit 5.5 og 5.6. Husnummerbetegnelse Feltet er krævet for gældende husnumre. Felterne skal opfylde de officielle definitioner for feltet i hvert fald hvis det indberettes. Der gælder følgende ifølge adressebekendtgørelsen: På grund af risikoen for forveksling må DAR Systembeskrivelse Side 43 af 52 Version 1.0

44 bogstaverne I, J, O og Q ikke benyttes for et nyt husnummer, eller når et husnummer ændres. Både OIO snitfladen og ADK 0.9 klienten giver fejl hvis man prøver at oprette eller ændre et husnummer til et husnummer med de uhensigtsmæssige bogstaver. Det vil dog være muligt at opdatere et eksisterende husnummer som har de uhensigtsmæssige bogstaver. Dette resulterer ikke i nogen beskeder hverken i ADK Adresseklienten eller OIO snitfladen. Vejkode Feltet er krævet for gældende husnumre. Feltet vejkode skal opfylde de officielle definitioner i hvert fald hvis det indberettes. Kilde Feltet er krævet for alle husnumre uanset status. ADK Adresseklient Når et husnummer oprettes eller rettes igennem ADK, sættes kilde automatisk til Oprettet af kommunen iht. adressecirkulæret (kode 1). OIO I OIO snitfladerne er feltet krævet ved oprettelser og opdateringer og alle kodeværdier kan vælges. Ikrafttrædelsesdato Ikrafttrædelsesdato sættes automatisk til den dato, hvor adressen ændrer status fra Foreløbig til Gældende Adresse Felt Status Validering Feltet er krævet og de gældende kodeværdier skal benyttes. Se også afsnit 5.5 og 5.6. Kilde Feltet er krævet for alle adresser uanset status. ADK Adresseklient Når en adresse oprettes eller rettes igennem Adresseklienten, sættes kilde automatisk til Oprettet af kommunen iht. adressecirkulæret (kode 1). OIO I OIO snitfladerne er feltet krævet og ved oprettelser og opdateringer kan alle kodeværdier vælges. Etage, sidedør Felterne etage og side/dørnummer skal opfylde de officielle definitioner for felterne i hvert fald hvis de indberettes. DAR Systembeskrivelse Side 44 af 52 Version 1.0

45 Etagebetegnelse for adresser må ikke være 00. Korrekt etagebetegnelse kan være følgende BLANK ST Stuen KL Kælder Side/dørnummer kan være følgende BLANK TV, MF, TH, , bogstaver, kombination af bogstaver (A-Z) og tal, samt tegnene skråstreg og bindestreg Journalnummer ESDH reference Ikrafttrædelsesdato Journalnummer må højst bestå af 60 tegn. ESDH reference må højst bestå af 200 tegn. Ikrafttrædelsesdato sættes automatisk til den dato, hvor adressen ændrer status fra Foreløbig til Gældende. DAR Systembeskrivelse Side 45 af 52 Version 1.0

46 6 Sikkerhed og brugeradgang 6.1 Brugeradministration Brugeradministrationen er fælles for BBR og DAR og brugerne til DAR administreres i BBR 1.7. Denne beslutning er truffet for ikke at skulle udvikle en brugeradministration i DAR 0.9, som alligevel skal skiftes ud, når Grunddata programmets fælles sikkerhedsmodel bliver implementeret. Der henvises til BBRs systemdokumentation for yderligere detaljer. 6.2 Adgang til webservices Til eksterne OIO webservices benytter OWSA model T. Når webservicene kaldes sker følgende: Det medsendte OCES certifikat valideres og der kontrolleres om certifikatet er trukket tilbage (autentifikation). Der foretages autorisationstjek via den interne service, som BBR udstiller til DAR. For at kunne kalde den eksterne webservice (OIO snitflade) skal brugeren have tilknyttet rollen DARAjourfoer. Der vil ikke være grund til at skelne mellem læse- og skriverettigheder i forbindelse med de ny eksterne ajourføringsservices. Hvis en bruger kun har behov for at læse, henvises de til AWS suiten. For at kunne kalde den interne snitflade til DAR, skal brugeren have tilknyttet rollen DARKaldfraBBR. 6.3 Adgang til ADK klienten Der kan logges på ADK Adresseklienten enten via certifikat eller via brugernavn og password. Hvis brugeren logger på med certifikat sker følgende: Det medsendte OCES certifikat valideres og der kontrolleres om certifikatet er trukket tilbage (autentifikation). Der foretages autorisationstjek via den interne service, som BBR udstiller til DAR. Hvis brugeren logger på med brugernavn og password, kalder DAR BBRs interne snitflade for både autentifikation og autorisation af brugeren. Adgangen til ADK Adresseklienten styres af to roller AdresseklientRead og AdresseklientWrite. Brugere kan altså have enten læse- eller skriverettigheder til Adresseklienten. DAR Systembeskrivelse Side 46 af 52 Version 1.0

47 7 Samtidighedsaspekter Når DAR og BBR bliver delt i to registre, og data hentes via interne snitflader, kan de hentede oplysninger være forældede inden behandlingen er gennemført i klienterne. 7.1 Eksempel 1: Adresseanvendelse i DAR Registerføreren i DAR fremsøger en adresse, som ikke er i brug i BBR, fluebenet på skærmbilledet vil vise, at adressen ikke er i brug. Kort efter tilknytter BBR registerføreren selvsamme adresse til en entitet i BBR. I DAR udfører registerføreren nu slet adresse funktionen idet det ser ud til at adressen ikke er i brug i BBR. For at sikre sig at adressen ikke slettes i DAR fordi den nu er i brug i BBR, skal DAR kalde BBR og tjekke adressens brug en ekstra gang før sletningen gennemføres. Adressen skal kun slettes hvis dette nye tjek viser, at adressen ikke er i brug. 7.2 Eksempel 2: BBRs mulighed for at oprette og slette adresser i DAR Når BBR kalder DARs interne services Opret adresse og Slet adresse, skal BBR tage højde for, at disse hændelser kort tid efter indlæses som en INSERT hhv. DELETE hændelse fra AWS en. Ved kaldet Slet adresse skal DAR give lov til at slette adressen på trods af, at den stadig er benyttet i BBR. DAR Systembeskrivelse Side 47 af 52 Version 1.0

48 8 Logning Alle kald som foretages og alle fejl som opstår logges i databasen i tabellen DARLog. Tabellen referer desuden til tabellen Transaktion, så efterfølgende fejlsøgning lettes. DAR Systembeskrivelse Side 48 af 52 Version 1.0