dar 0.9 systembeskrivelse · 2015. 4. 16. · dar 0.9 systembeskrivelse side 5 af 52 version 1.0 1...

DAR 0.9 Systembeskrivelse

Version 1.0

DAR 0.9 Systembeskrivelse Side 2 af 52 Version 1.0

Versionsoversigt

Version Dato Beskrivelse

Initialer

0.0 01.02.2015 Version 0.0 oprettet som kopi af

arkitekturbeskrivelsen

JWT

1.0 27.02.2015 Version 1.0 sendt til KOMBIT JWT


Indholdsfortegnelse

1 Indledning .......................................................................................................... 5

2 Systemarkitektur ................................................................................................ 7

2.1 Præsentationslag ............................................................................................... 8

2.1.1 ADK Klient .................................................................................................. 8 2.1.2 OIO snitflade .............................................................................................. 9

2.2 Applikationslag .................................................................................................. 9

2.2.1 Service Interface Lag ................................................................................... 9 2.2.2 Batch Lag ................................................................................................... 9 2.2.3 Forretnings Lag ........................................................................................... 9 2.2.4 Data Access Lag .......................................................................................... 9

2.3 Datalag ............................................................................................................ 9

3 Dataudveksling med andre systemer ................................................................ 10

3.1 Snitflader, som DAR udstiller .............................................................................. 11

3.1.1 Snitflade til BBR (DAR udstiller, BBR kalder) .................................................. 11 3.1.2 Eksterne ajourføringsservices til 3. part ........................................................ 11 3.1.3 Snitflade til AWS suiten ............................................................................... 12

3.2 Udtræk som DAR leverer ................................................................................... 15

3.2.1 Levering af totaludtræk til AWS .................................................................... 15

Specifikation af CSV format ................................................................................... 17

3.3 Data, som modtages og indlæses i DAR ............................................................... 17

3.3.1 Indlæsning af data fra CPR .......................................................................... 17

3.4 Snitflader, som DAR kalder ................................................................................ 18

3.4.1 Snitflade til GST ......................................................................................... 18 3.4.2 Snitflade til certificeringscenter .................................................................... 18 3.4.3 Snitflade til BBR (BBR udstiller, DAR kalder) .................................................. 18

4 Datamodel ........................................................................................................ 19

4.1 Den logiske datamodel ...................................................................................... 19

4.1.1 Adgangspunkt ............................................................................................ 22 4.1.2 Husnummer .............................................................................................. 24 4.1.3 Adresse..................................................................................................... 25 4.1.4 Sagsreference ............................................................................................ 27

4.2 Den fysiske datamodel ...................................................................................... 28

4.2.1 Nøgler ...................................................................................................... 28 4.2.2 Entiteter med historik (Adgangspunkt, husnummer, adresse, sagsreference) ..... 28 4.2.3 Transaktioner og timestamps ....................................................................... 29 4.2.4 Tegning af databasemodellen ....................................................................... 31 4.2.5 Andre systemtabeller i den fysiske datamodel ................................................ 34 4.2.6 Tabeller til CPR data ................................................................................... 35 4.2.7 Bitemporale egenskaber .............................................................................. 35

4.3 Konvertering fra BBR adresser til DAR 0.9 ............................................................ 37

5 Forretningslogik ............................................................................................... 39

5.1 Matrikel-adresse relation ................................................................................... 39

5.2 Adresseforekomsters liv .................................................................................... 39

5.3 Krav om vejkode og husnummer, samt CPR vejstykke ........................................... 39

5.4 Tilknytning af adresser til entiteter i BBR ............................................................. 39

5.5 Statusværdier .................................................................................................. 39


5.6 Sammenhæng mellem statusværdier .................................................................. 40

5.7 Adressernes entydighed .................................................................................... 40

5.8 Diverse valideringsregler på entitetsniveau .......................................................... 40

5.8.1 Adgangspunkt ............................................................................................ 40 5.8.2 Husnummer .............................................................................................. 43 5.8.3 Adresse..................................................................................................... 44

6 Sikkerhed og brugeradgang.............................................................................. 46

6.1 Brugeradministration ......................................................................................... 46

6.2 Adgang til webservices ...................................................................................... 46

6.3 Adgang til ADK klienten ..................................................................................... 46

7 Samtidighedsaspekter ...................................................................................... 47

7.1 Eksempel 1: Adresseanvendelse i DAR ................................................................ 47

7.2 Eksempel 2: BBRs mulighed for at oprette og slette adresser i DAR ........................ 47

8 Logning ............................................................................................................ 48

9 Produktions- og demomiljø .............................................................................. 49

9.1 Produktionsmiljø ............................................................................................... 50

9.2 Demomiljø ....................................................................................................... 51

10 Dokumentation ................................................................................................. 52

10.1 Brugervejledninger ....................................................................................... 52

10.1.1 Brugervejledning til ADK klienten ............................................................... 52

10.2 Snitfladebeskrivelser ..................................................................................... 52

10.2.1 Snitfladebeskrivelse til AddressV1 ............................................................... 52

10.3 Installationsvejledning ................................................................................... 52


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ø


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.


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.

Website ADK 0.9

Autentifikation

Service Agenter

SQLServer DAR

Service Gateway

Service Agenter

Enitity framework

ASP.NET MVC OIO XML

DAR Service Interface Lag

Service Adapter

Service Contract

Forretnings Lag

ForretningsLogik

ForretningsEntiteter

Data Access Lag

ServiceAgenter

Data AccessLogik

DAR

Batch

WindowsServices/Scheduled

tasks

Kald til andre systemer- BBR-GST

Figur 1 Systemarkitektur DAR 0.9


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.

2.1.1 ADK Klient

ADK 0.9.2 er én måde at tilgå DAR 0.9 på. ADK 0.9.2 giver mulighed for at oprette og

vedligeholde adgangspunkter, husnumre og adresser.

En mere detaljeret beskrivelse af ADK findes i brugervejledning for ADK Adresseklient (afsnit

10.1.1 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 view-

specifikke scripts bliver koblet til på de underliggende views der bruger dem med en @section

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)


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.

2.2.1 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.

2.2.2 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.

2.2.3 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.

2.2.4 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.


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.

DAR

AWS

CPR

GST

BBR

Certificeringsce

nter

Koordinater til adresser

Hent certifikater

Vejstykker mm.

Ajourførings-

services(OIO)Ekstern OIO snitflade

BBR DAR interne services(OIO)

Adresse data i

ny datamodel

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.


— 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

BBR kan oprette og slette adresser i DAR.

OIO snitflade til 3. part 3. part kan benytte OIO snitfladen til at opdatere adressedata.

Snitflade til AWS AWS kan kalde en snitflade for at hente adresseopdateringer.

3.1.1 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.

3.1.2 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


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 10.2.1

Snitfladebeskrivelse til AddressV1).

3.1.3 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 3.2.1 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=2015-01-01+10:10:50&til=2015-

01-01+10: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);

http://dar-kommune.dk/services/getaccesspointbyupdatedate?from=2015-01-01+10:10:50&to=2015-01-01+10:09:50

http://dar-kommune.dk/services/getaccesspointbyupdatedate?from=2015-01-01+10:10:50&to=2015-01-01+10:09:50


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 10.000 entiteter i en forespørgsel. Hvis resultatet indeholder mere end

10.000 entiteter returneres de første 10.000 entiteter i en ordnet rækkefølge efter ’opdateret’ timestamp.

— DAR garanterer at der maksimalt findes 10.000 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=2010-07-05T12:16:15.69+02:00&til=2011-07-05T12:16:15.69+02: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.


— 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':'0A3F50B3-8159-32B8-E044-0003BA298018', 'husnummerid':'0A3F5088-EC8B-32B8-E044-0003BA298018', 'statuskode':'1', 'etagebetegnelse':'ST', 'doerbetegnelse':'', 'esdhreference':'', 'journalnummer':'E044-0003BA298018', 'kildekode':'1', 'ikrafttraedelsesdato': '2010-07-05T12:16:15.6900000+02:00', 'registreringstart': '2010-07-05T12:16:15.6900000+02:00', 'registreringslut':'', 'virkningstart': '2010-07-05T12:16:15.6900000+02: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-E044-0003BA298018', 'adgangspunktid':'0A3F5088-EC87-32B8-E044-0003BA298018', 'registreringstart': '2010-07-05T12:16:15.6900000+02:00', 'registreringslut':'', 'virkningstart': '2010-07-05T12:16:15.6900000+02:00', 'virkningslut':'', 'vejkode':'11', 'husnummer':'003', 'statuskode':'1', 'kildekode':'1', 'ikrafttraedelsesdato': '2010-07-05T12:16:15.6900000+02: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-1D50-4443-A9AE-50FBCEAD300B', 'id':'0A3F5088-EC87-32B8-E044-0003BA298018', 'statuskode':'1', 'kildekode':'5', 'nord':'6141337.41', 'oest':'583086.98',


'tekniskstandard':'TK', 'noejagtighedsklasse':'A', 'retning':'234', 'placering':'5', 'kommunenummer':'461', 'esdhreference':'', 'journalnummer':'', 'revisionsdato': '2010-07-05T12:16:15.6900000+02:00', 'registreringstart': '2010-07-05T12:16:15.6900000+02:00', 'registreringslut':'', 'virkningstart': '2010-07-05T12:16:15.6900000+02: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': '2010-07-05T12:16:15.6900000+02:00', 'aendringstimestamp': '2010-07-05T12:16:15.6900000+02:00', 'ophoerttimestamp': '2010-07-05T12:16:15.6900000+02: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. 2010-07-05T12:16:15.6900000+02: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 Data

AWS - totaludtræk DAR leverer en gang i døgnet et totaludtræk til AWS’en.

3.2.1 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 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_20150223.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


'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)]'


— Adgangspunkt


'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 Data

CPR veje, vejstykker,

vejnavne m.m.

DAR indlæser data, som modtages fra CPR (en gang dagligt).

3.3.1 Indlæsning af data fra CPR

Der indlæses dagligt opdateringer fra CPR omkring veje, vejstykker, postdistrikter, bynavne og

lokalitet i DAR 0.9.


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 Data

GST – geodata til

Bygninger, Teknisk anlæg

og Adresser

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

Certificeringscenter Denne snitflade bruges i forbindelse med autentifikation af

brugere ved logon med certifikat (medarbejder-, funktions- og

virksomhedscertifikater).

BBR DAR kalder BBR for at

- Tjekke om en adresse hhv. et husnummer er i brug i BBR

- Autentificere brugeren

3.4.1 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

3.4.2 Snitflade til certificeringscenter

DAR autentificerer brugere ved logon med certifikat (medarbejder-, funktions- og

virksomhedscertifikater).

3.4.3 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.


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 0.9.

4.1 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 4.1.1 til 4.1.4 for en oversigt over alle felter for de vigtigste entiteter i den logiske

datamodel.


Figur 3 Informationsmodel for DAR 0.9


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ær-skilt adgang til et areal, en bygning eller en del af en bygning efter reglerne i adresse-bekendtgørelsen. I en bygning kan flere adresser (med forskellig etage og dør-betegnelse) 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.


4.1.1 Adgangspunkt

Felt Beskrivelse

Id UUID

Feltet sættes automatisk af systemet.

Status Status

Kodeværdier:

1- Gældende

2- Nedlagt

3- Foreløbig

4- Henlagt

Kommunenummer Kommunenummer

ESDH-ref ESDH – Reference til kommunens eget ESDH system (max 200 tegn)

Journal nr. Journalnummer (max 60 tegn)

Ejendomsnummer 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.


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:


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:

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

Adgangspunktretning Retningsvinkel

Retningsvinkel for tekst i gon, jf. TK-standard: 0.00-400.00

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 Se afsnit 4.2.7 Bitemporale egenskaber

Registreringstid Se afsnit 4.2.7 Bitemporale egenskaber


4.1.2 Husnummer

Felt Beskrivelse

Id UUID


AdgangspunktId Id for adgangspunktet som husnummeret referer til

Status 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

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 Postnummer

Feltet opdateres automatisk ud fra vejkode og husnummeret.

Postdistrikt/navn Postdistrikt


Suppl. bynavn Supplerende bynavn



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.

11 - Oplysning fra anden kilde


True – hvis husnummeret ligger i en sagsreference.


IBrugIBBR Boolean

True – hvis husnummeret (adgangsadressen) benyttes i BBR.




4.1.3 Adresse

Felt Beskrivelse

Id UUID


HusnummerId Husnummeret som adressen referer til.

Status Status

Kodeværdier:

1- Gældende

2- Nedlagt

3- Foreløbig

4- Henlagt

Etagebetegnelse

Korrekte etagebetegnelse kan være følgende

BLANK


ST – Stuen

01-99

KL – Kælder

Dørbetegnelse

Side/dørnummer kan indeholde:

BLANK

TV, MF, TH,

0001-9999,

bogstaver,kombinationer af bogstaver (A-Z) og tal, samt tegnene

skråstreg og bindestreg.

ESDH reference ESDH – Reference til kommunens eget ESDH system (max 200 tegn)

Journal Journalnummer (max 60 tegn)

Kilde Kilde til adressen

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.

11 - Oplysning fra anden kilde

Ikrafttrædelsesdato Ikrafttrædelsesdato

”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.


True – hvis adressen ligger i en sagsreference.


IBrugIBBR Boolean

True – hvis adressen (enhedsadressen) benyttes i BBR.





4.1.4 Sagsreference

Felt Beskrivelse

Status Status angiver om sagen stadig er aktiv eller om den er nedlagt.

Sagsnummer Sagsnummer

Sagsnummer skal være entydigt.

Oprettelsesdato Oprettelsesdato

Feltet opdateres automatisk af systemet.

Titel Titel på sagen

Max-X Feltet opdateres automatisk af systemet ud fra det område det markeres

på kort.

Max-Y Feltet opdateres automatisk af systemet ud fra det område det markeres

på kort.

Min-X Feltet opdateres automatisk af systemet ud fra det område det markeres

på kort.

Max-X Feltet opdateres automatisk af systemet ud fra det område det markeres

på kort.

Kommentar fra ejer Kommentar fra ejer

Kommentar fra

sagsbeh.

Kommentar fra sagsbehandler

Dokumenter Det er muligt at uploade dokumenter til en sag. Dokumenter skal være af

typen .docx eller .pdf.


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)

4.2.1 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_.

4.2.2 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 4.2.7 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),


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.


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.


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.

4.2.4 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.

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



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


Doerbetegnelse

Etagebetegnelse

VirkningStart

VirkningSlut



DBRegistreringSlutTimestamp

FK_RegistreringSlutTransaktio...

Husnummer

Husnummer_id

BK_Husnummer_id

FK_RegistreringStartTransaktion_id


HusnummerAktuelt

Husnummer_id

FK_HusnummerVersion_id

FK_Adgangspunkt_id

Vejkode

Husnummer

StatusKode

KildeKode

Vejnavn

Postnummer

Postdistrikt

Bynavn


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


VirkningStart

VirkningSlut




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


Figur5: Den fysiske datamodel: Sagsreferencer

Adgangspunkt

Adgangspunkt_id

BK_Adgangspunkt_id

FK_RegistreringStartTrans...

DBRegistreringStartTimest...

AdgangspunktSagsreference

AdgangspunktSagsreference_id

BK_AdgangspunktSagsreference_id



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



Adresse

Adresse_id

BK_Adresse_id


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


FK_RegistreringStartTransaktio...


Husnummer

Husnummer_id

BK_Husnummer_id


HusnummerSagsreference

HusnummerSagsreference_id

BK_HusnummerSagsreference_id



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




FK_RegistreringSlutTransaktion_id

Sagsreference

Sagsreference_id

BK_Sagsreference_id


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.. .

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

DAR Systembeskrivelse Side 35 af 52 Version 1.0

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”).

4.2.6 Tabeller til CPR data

Følgende tabeller vedligeholdes ved indlæsning af data fra CPR.

— Vej

— Vejstykke

— Postdistrikt

— By

4.2.7 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.


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 1.1.2001 1.1.2001

Adressen ændres til gældende – reel ændring


Foreløbig ST TV 1.1.2001 1.1.2009 1.1.2001

Foreløbig ST TV 1.1.2009 1.1.2001 1.1.2009

Gældende ST TV 1.1.2009 1.1.2009

Adressen nedlægges


Foreløbig ST TV 1.1.2001 1.1.2009 1.1.2001

Foreløbig ST TV 1.1.2009 1.1.2001 1.1.2009

Gældende ST TV 1.1.2009 1.1.2014 1.1.2009

Gældende ST TV 1.1.2014 1.1.2009 1.1.2014

Nedlagt ST TV 1.1.2014 1.1.2014

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.


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

DAR 0.9

ADK 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 ADGANGSPUNKT

ADGANGSADRESSE HUSNUMMER

ENHEDSADRESSE 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 0.9

1 – Godkendt/Gældende Gældende

2 – Slettet Nedlagt

3 – Foreløbig Foreløbig

4 – Afsluttet sagsentitet 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.

Konverteres til

Konverteres til

Konverteres til

Konverteres til


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.


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.


Adressen behøver ikke at ligge på et godkendt CPR vejstykke.

Gældende Entiteten er gældende.

Nedlagt Entiteten er nedlagt og har tidligere været gældende.

Henlagt 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 husnummer-

betegnelse.

Der må gerne eksistere flere foreløbige husnumre uden vejkode eller uden husnummer-

betegnelse.

Foreløbige husnumre, som har vejkode og husnummer skal være entydige på kommune-

nummer, 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

5.8.1 Adgangspunkt

Felt DAR

Status 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 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,


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 Journalnummer må højst bestå af 60 tegn.

ESDH reference 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


opdateringer. Hvis feltet ikke angives ved oprettelser, sættes den

til 5.

Retning Et decimaltal mellem 0.00 og 400.00.

Feltet er krævet for alle adgangspunkter uanset status.

ADK Adresseklient

I ADK opdateres feltet via kortet. Feltet er sat til 200.00 per

default.

Når et adgangspunkt oprettes igennem Adresseklientens nye opret

funktionalitet sættes feltet automatisk til 200.00.

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 200.00.

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.

5.8.2 Husnummer

Felt DAR



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å


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”.

5.8.3 Adresse

Felt Validering



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.


Etagebetegnelse for adresser må ikke være ’00’.

Korrekt etagebetegnelse kan være følgende

BLANK

ST – Stuen

01-99

KL – Kælder

Side/dørnummer kan være følgende

BLANK

TV, MF, TH,

0001-9999,

bogstaver, kombination af bogstaver (A-Z) og tal, samt

tegnene skråstreg og bindestreg

Journalnummer Journalnummer må højst bestå af 60 tegn.

ESDH reference ESDH reference må højst bestå af 200 tegn.

Ikrafttrædelsesdato ”Ikrafttrædelsesdato” sættes automatisk til den dato, hvor

adressen ændrer status fra ”Foreløbig” til ”Gældende”.


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.


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.


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.


9 Produktions- og demomiljø

Dette afsnit beskriver løsningens teknologiarkitektur. I denne beskrivelse er der fokus på de

enkelte komponenters fordeling på fysiske servere. Følgende diagram viser den overordnede

netværks topologi i DAR:

Citizen

Internet

Firewall

Load balancing

MS SQL Server

PresentationLayer

ApplicationLayer

Figur 5 Generel netværks topologi i DAR

BBR og DAR løsningerne er designet i en flerlagsarkitektur, hvor løsningernes komponenter er

separeret i logiske arkitekturlag. Lagene udgøres af et præsentationslogiklag, et

forretningslogiklag, samt et datalogiklag. Lagdelingen af applikationerne tjener det formål at

sikre en høj sikkerhed af den samlede løsning.

Klienter tilgår løsningen over internet via browser og databærende trafik er altid krypteret på

transportlaget (https).

Præsentationslogik og forretningslogik er adskilt på web/applikationsframens servere og kører i

egne applikationsinstanser under separate sikkerhedskonti.

Services på præsentations- og forretningslagene er udstillet via en Applikation Content

Delivery service (BIGIP load balancer). ADC’en sikrer fordeling af load i farmen både fra

klienter til præsentationsservices, såvel som fra præsentationslaget til forretningsservices.


ADC’en fungerer som en fuld TCP proxy, som terminerer SSL trafikken. Herved bidrager

ADC’en både til at reducere den mulige angrebsflade på serverne i web/applikations-farmen,

samtidig med at den sikrer en optimal udnyttelse af ressourcerne i serverfarmen og aflaster

serverfarmen ved at håndtere SSL trafikken.

Data er placeret i eget lag i egen sikkerhedszone.

Der er etableret et demo- og et produktionsmiljø.

9.1 Produktionsmiljø

SQL Server 2012Report

JR5000PD

Internet

Windows Server 2012R2Webserver/

App

FRONT


App

BACK

Windows Server 2012R2Application Server

Ftp/Batch


App

SQL Server 2012BBR/DAR

JR5000PD


App

Server Type:Størrelse : A3EQU_ID : vCPU : 4 stkvMEM : 7168 MBMBC-disk : 60GBD-disk : 40GB

Server Type:Størrelse : A2EQU_ID : vCPU : 2 stkvMEM : 3584 MBC-disk : 60GBD-disk : 40GB

Server Type:Størrelse : Cloud LargeEQU_ID : vCPU : 4 stkvMEM : 32 GBC; OS : 60 GBd: BIN : 25 GBe: TMP : 50 GBf: LOG : 100 GBg:DAT : 200 GB

Server Type:Størrelse : Cloud LargeEQU_ID : vCPU : 4 stkvMEM : 32 GBC; OS : 60 GBd: BIN : 25 GBe: TMP : 50 GBf: LOG : 200 GBg:DAT : 500 GB

Figur 6 DARs produktionsmiljø


9.2 Demomiljø

SQL Server 2012

BBR/DARDB 1

Internet

FRONT

Windows Server 2012Web/App-server

BACK

Server Type:Størrelse : A3EQU_ID : vCPU : 4 stkvMEM : 7168 MBMBC-disk : 60GBD-disk : 40GB

Figur 7 DARs demomiljø

I demomiljøet findes én webserver, én applikationsserver samt en SQL server. Demomiljøet

kan f.eks. benyttes af KOMBIT/MBBL til test af ny funktionalitet i ADK Adresseklienten samt af

3. parts applikationer til test af OIO snitfladerne.


10 Dokumentation

Ud over denne systemdokumentation, som har løsningens systemejer KOMBIT og MBBL som

målgruppe, findes der yderligere dokumentation for løsningen.

10.1 Brugervejledninger

10.1.1 Brugervejledning til ADK klienten

Der er udarbejdet en brugervejledning til Adresseklienten ADK. Målgruppen er de kommunale

brugere.

10.2 Snitfladebeskrivelser

10.2.1 Snitfladebeskrivelse til AddressV1

Der er udarbejdet en snitfladebeskrivelse for løsningens OIO snitflade. Målgruppen er 3. part

anvendere.

10.3 Installationsvejledning

Der skal udarbejdes dokumentation for, hvordan løsningen og dens komponenter skal

installeres i driftsmiljø. Installationsvejledningen deles op i tre dele for hhv. web- og

applikationsservere samt SQL serveren.

dar 0.9 systembeskrivelse · 2015. 4. 16. · dar 0.9 systembeskrivelse side 5 af 52 version 1.0 1...

Documents