FESD Navn- og Adressemodel

Transkript

1 FESD Navn- og Adressemodel Standard IT- og Telestyrelsen København den 10. december 2008 FESD-standardisering Navn- og adressemodel. Datamodel Version 1.1

2 Kolofon: FESD-standardisering. Navn- og adressemodel. Datamodel. Version 1.1 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Kontoret for standardiserings- og arkitekturpolitik, FESD-standardiseringsgruppen i samarbejde med de tre FESD leverandører Software Innovation A/S, Traen Informationssystemer A/S og CSC Danmark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita Lützhøft, Mail-adresse [email protected] Telefon (direkte) Traen Informationssystemer A/S Vesterbrogade 95 A 1620 København K Telefon: Web-adresse: CSC Danmark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade Nærum Telefon: Web-adresse: Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen Kontoret for standardiserings- og arkitekturpolitik Holsteinsgade 63 DK-2100 København Ø Telefon: Fax [email protected] 2 / 49

3 Indholdsfortegnelse 1 FORORD Teknisk forord DEL A BAGGRUND Indledning Afgrænsning DEL B FORRETNINGEN VEDRØRENDE ADRESSEDATA OG ESDH Indledning Oprettelse og vedligeholdelse af person/organisation- og adresseoplysninger i et ESDH-system Oprettelse af registre Vedligehold af registre Brug og behandling af person/organisation- og adresseoplysninger i forbindelse med brug af ESDH Oprettelse af sag principiel hovedfunktionalitet: Modtagelse af dokumenter principiel hovedfunktionalitet: Afsendelse af dokumenter principiel hovedfunktionalitet DEL C DATA OG ADRESSEOMRÅDET M.V Model for dataflow - adressedata FESD adressedatamodel Introduktion og afgrænsning CPR-systemet BBR-systemet CVR-systemet Konklusioner vedr. CPR, BBR og CVR Kobling til FOA-systemet OIOXML adresseguide Kobling til adressedata i andre systemer: EPJ-systemer DEL D. FESD-ADRESSEMODEL Beskrivelse af klasser Adresse Adressepunkt Bygning Bygningsenhed coadresse Ejendom Ejerlav ElektroniskPostadresse GeneriskGenstand GeneriskGenstandType Genstand Indlandsadresse JournalPostPart Kommune Kontakt / 49

4 kontaktadresserolle KontaktGenstandRolle KontaktGruppe KontaktRelation Land MatrikelOplysning Organisation OrganisationstypeType Person PostDistrikt Sag sagsgenstand Sagspart SammensatAdresse Telefon TelefonRolle UdlandsAdresse Vej ANVENDTE TYPER I FESD-MODELLERNE / 49

5 1 Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sags- og dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både mellem ESDH-systemer og til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESDstandardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-komiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telestyrelsens OIO-Katalog (digitaliser.dk), som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. Denne udgave af standarden er både såkaldt konsolideret og revideret i forhold til version På grund af den måde FESD-standardiseringsarbejdet er tilrettelagt på forskellige afleveringer på forskellige tidspunkter siden 2004 udkommer FESD-datamodellen som deldatamodeller. Det har betydet, at enkelte detaljer i det forventede slutresultat altså den samlede FESD-datamodel kan være overset. Det har endvidere været 5 / 49

6 nødvendigt at konsekvenstilføje noget, der tidligere er sprunget over fx på grund af manglende standardisering på det tidspunkt, den aktuelle standard blev udarbejdet. Endvidere har NDR (Name and Design Rules) reglerne givet anledning til en del ændringer i sprogbrug (semantik) vedrørende attributter af hensyn til efterfølgende generering af XML Den samlede FESD-datamodel (i form af deldatamodellerne) til og med 2008 er derfor gennemgået og genvurderet i forbindelse med denne standard. Denne genvurdering konsolidering - har ikke medført forretningsmæssige radikale ændringer i deldatamodellen, men har dog givet anledning til en del justeringer, typisk af præsentationsmæssig (semantik) karakter, især pga. NDR-reglerne. Den samlede FESD datamodel udgøres af FESD standarderne Sager og dokumenter, Brugeradministration, Udvalgsbehandling, Arkivstruktur, Emnesystematik, Navn- og adressemodel. Dette er endvidere en revideret udgave, idet brugere havde den opfattelse, at den oprindelige model var for kompliceret at bruge i praksis. Revisionen har dog bibeholdt langt de fleste attributter/elementer kendt fra version af hensyn til bagudkompatibilitet. I denne reviderede udgave er der først og fremmest sket en omfordeling af de kendte attributter/elementer (men der er dog indført nye attributter/elementer) på nye eller reviderede klasser, idet modelleringsprincipperne har undergået en forandring. 1.1 Teknisk forord Grundlaget for FESD-datamodellen er blevet udarbejdet på en periode på mere end fire år, hvor der er udarbejdet standarder for de forskellige delområder. Arbejdsmetoder, terminologi og anvendelse af datatyper har ændret sig i denne periode FESD-standardiseringsgruppen har f.eks. indført en konsekvent brug af UML-notation i de senere standarder. Konsolideringen af datamodellen har derfor forudsat, at der blev defineret en fælles modelleringsmetode og et sæt af primitive datatyper, der var kompatibelt med alle deldatamodellerne. De primitive datatyper, som modellen er opbygget af, fremgår af kapitel 6. 6 / 49

7 2 Del A Baggrund 2.1 Indledning Som en del af FESD-datamodellen skal der standardiseres dataelementer, der omhandler adresse-området. Adressemodellen, der således er en delmængde af FESD-standardiseringens komplette datamodel, har til formål at beskrive de kontakt- og lokationsinformationer, der er nødvendige for, at et FESD-system kan varetage: Håndtering af stedrelaterede sagstyper: eksempelvis miljø-, ejendoms- og matrikelsager. Håndtering af sagstyper hvor en person, en organisation eller en virksomhed er sagens hovedemne. Håndtering af kontaktinformationer for sagsparter. Desuden skal adressemodellen give grundlaget for maskinel kommunikation med eksterne registre, der indeholder de ovenfor nævnte data, eksempelvis CPR (Centrale personregister), CVR (Centrale virksomhedsregister) og BBR (Bygnings- og Boligregister), hvilket er specificeret som en forudsætning for FESDstandardiseringsarbejdet. 2.2 Afgrænsning Det skal indledningsvist nævnes, at FESD-datamodellen for adresse-området ikke baserer sig på eller tager udgangspunkt i den norske NOARK, som det øvrige FESD-datamodel arbejde. Grunden til dette er, at det er anset for vigtigt, at ESDH-systemer er kompatible med de store registre på netop dette område af hensyn til genbrug af data, som alligevel opsamles i Danmark. Det er dog anset for hensigtsmæssigt, at de forskellige FESD-standardiseringsaktiviteter, når relevant, skal give indblik i NOARK s behandling af emnet. Dvs. når der fx skal udarbejdes datamodel for adresseområdet, skal der indledningsvist kortfattet redegøres for, hvorledes NOARK behandler området. Det skal således her anføres, at NOARK4 har et antal tabeller, der styrer adresser samt person og organisationsdata. Det er primært tabellerne eller klasserne som vist i det efterfølgende diagram, hvor enkelte klasser kan være udeladt. De væsentligste klasser for adresseområdet er dog de på diagrammet nævnte. 7 / 49

8 cd N oarks adressem od el Adresser::POSTN R + PO_KOMMUNE: + PO_KOMNR: + PO_N ED LD AT O: + PO_OPRDATO: + PO_POSTNR: + PO_POSTSTED: Journalpost::AVSMOT + AM_ADMID: + AM _ADRESSE: + AM _AVSKAV: + AM _AVSKDATO: + AM _AVSKM : Adresser::AD R TYPE + AT_BETEGN: + AT_KODE: Adresser::AD R ESSEK P + AK_ADRGRUPPE: + AK_ADRID: + AK_BASEID: + AK_EPOST: + AK_FAKS: + AK_KORTNAVN: + AK_MOBIL: + AK_NAVN: + AK_OPDGRUPPE: + AK_ORGNR: + AK_OVEROR D: + AK_PERSOK: + AK_POSTADR: + AK_POSTNR: + AK_POSTSTED: + AK_REGEPOST: + AK_TGGRUPPE: + AK_TILDATO: + AK_TLF : + AK_TYPE: Organisasjon:: ADRADMENH + AA_ADMID: + AA_ADRID: Tilgangstyring:: ADRPERSON + PA_ADRID: + PA_PEID: + AM _BEHANSV: + AM _BESVAR: + AM _EPOSTADR: + AM _FORSEND: + AM_FRIST: + AM _FSSTATUS: + AM _GRUPPE: + AM _GRUPPEM OT: + AM_ID: + AM _IHTYPE: + AM _JENHET: + AM _JPID: + AM_KOPIMOT: + AM _KORTNAVN : + AM _N AVN: + AM_POSTNR: + AM_POSTSTED: + AM _R EF: + AM _SBHID: + AM _U 1: + AM _U TLAND: + AK_UTLAND: Sakshåndtering:: SAKSPART + SP_ADRESSE: + SP_EPOSTADR: + SP_FAKS: + SP_KONTAKT: + SP_KORTNAVN: + SP_MERKNAD: + SP_NAVN: + SP_POSTNR: + SP_POSTSTED: + SP_ROLLE: + SP_SAID: Adresser:: MEDLADRGR + MG_GRID: + M G_M ED LID : Adresser:: KPFORMAT + KF_ADRID: + KF_FORMAT: Adresser::D IG ISER T + SE_ADRID: + SE_EPOST: + SE_FRADATO: + SE_ID: + SE_NAVN: + SE_SERT: + SE_SIGNTEKST: Ad resser:: KPAUTORIS + KA_ADRID: + KA_AUTAV: + KA_AUTDATO: + KA_FRADATO: + KA_TGKODE: + KA_TILDATO: + SP_TLF: + SP_U1: + SP_UTLAND: + SE_TILDATO: + SE_TTPEPOST: + SE_VERAV: + SE_VERDATO: Figur 1 NOARK 4 på adresseområdet. UML-diagram over de mest centrale klasser/tabeller Det bemærkes som nævnt ovenfor, at NOARK ikke er skønnet særlig relevant for FESDstandardiseringsarbejdet på adresse-området på grund af særlige danske forhold; dvs. de store registre CPR, CVR, BBR etc. som kan give mulighed for genbrug af data. 8 / 49

9 3 Del B Forretningen vedrørende adressedata og ESDH 3.1 Indledning Inden der kan konstrueres den nødvendige del-datamodel og de nødvendige grænsesnit, er det nødvendigt at beskrive det forretningsområde, hvori model og grænsesnit indgår, eller med andre ord hvad de omhandlede data bruges til i ESDH-systemer. Efter gennemgang af fx NOARK4 ses, at i forhold til ESDH har person/organisation- og adresseoplysninger ikke nogen væsentligt selvstændig unik forretning. Person/organisation- og adresseoplysninger indgår som meget nødvendige hjælpeoplysninger i forbindelse med forretningen sagsbehandling men er i den forbindelse samlet set mindre vigtige i forhold til andre typer af dataelementer, der vedrører sager og dokumenter. Den forretning, der beskrives i det følgende, omhandler derfor først og fremmest helt praktiske forhold knyttet til funktionalitet ved håndtering af adresse-data. Beskrivelsen kan opdeles i to overordnet forskellige dele: 1. Oprettelse og vedligeholdelse af person/organisation- og adresseoplysninger i et ESDH-system 2. Brug og behandling af person/organisation- og adresseoplysninger i forbindelse med brug af ESDH 3.2 Oprettelse og vedligeholdelse af person/organisation- og adresseoplysninger i et ESDH-system Oprettelse af registre Der er i princippet to muligheder for at oprette registre: Automatisk eller ved inddatering. I det følgende forudsættes automatisk inddatering, hvilket dog ikke må afskære et system muligheden for manuel inddatering. En automatisk oprettelse kan i princippet foregå ved en batch-overførsel af de nødvendige oplysninger eller ved en online overførsel af de nødvendige oplysninger. FESD-standardiseringen tager ikke stilling til, hvordan et ESDH-system således ajourføres med person/organisation- og adresseoplysninger, men forudsætter blot at disse eksisterer i ESDH-systemet. Det må forventes, at data i videst muligt omfang hentes fra centrale registre og lagres lokalt i ESDH-systemets adressedatabase som redundante data, bl.a. for at sikre at benyttede adresseoplysninger lagres i ESDH-systemet til brug for senere visning af sagers og sagsparters tilknyttede adressedata. Det må formodes, at en fremtid med en fuldt udbygget service orienteret arkitektur (SOA) kan overflødiggøre lokale redundante registre, men det må samtidig konstateres, at den nødvendige infrastruktur endnu ikke er opbygget - og at det ikke vides, hvornår SOA vedrørende fx adresse-data er en realitet. Planlægningen vedrørende adresse-data må således tage højde for, at fremtiden bliver SOA orienteret, men må samtidig indstille sig på, at fortidens metoder stadig vil fungere i en overgangsperiode af ukendt længde Vedligehold af registre Vedligehold kan foregå forskelligt, både automatisk og manuelt. Det følgende centrerer om automatisk understøttet vedligehold, men det skal nævnes, at manuelt vedligehold stadig bør være muligt. Registre skal opdateres, når der foreligger ændringer og den mest hensigtsmæssige måde at opdatere på, er ved alene at opdatere nyt, dvs. ændringer og tilføjelser. I det følgende centreres således om brug af webservice til sådanne opdateringsformål. På de relevante områder findes CPR (Centrale personregister), CVR (Centrale virksomhedsregister), BBR (Bygnings- og Boligregister) / OIS (den Offentlige Informations Server) og senere FOA (Fælles Offentlig Adressebase p.t. under opbygning i ITST) som store autoritative registre, der er relevante for person/organisation- og adresseoplysninger knyttet til ESDH. Af disse tilbyder CVR allerede web-service til overførsel af data, og de øvrige må forventes også at kunne tilbyde web-service på et tidspunkt. Men uanset muligheden for web-service er disse registre at opfatte som 9 / 49

10 autoritative dataleverandører, hvorfor person/organisation- og adresseoplysninger i ESDH-systemer bør indrettes således, at ESDH-systemets lokale registre på disse områder altid kan udnytte de store autoritative registre. Endvidere skal nævnes, at KMD vedligeholder en kopi af CPR-registret, kaldet P-data, der anvendes på tværs af de kommunale løsninger. P-data står til rådighed for alle kommuner, og dataadgang kan opnås gennem web-services. Den fremtidige funktionalitet/forretning for ESDH-systemer er således, at vedligehold på de relevante områder sker via udnyttelse af disse registre. ESDH-systemet skal således have mulighed for at importere data fra disse registre og helst uden forudgående mapninger og/eller konverteringer. 3.3 Brug og behandling af person/organisation- og adresseoplysninger i forbindelse med brug af ESDH Oprettelse af sag principiel hovedfunktionalitet: Ved oprettelse af sag skal tilknyttes en sagsbehandler typisk fra egen organisation, dvs. fx fra register over ansatte. ESDH-systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til sag Fremsøgning, visning samt efterfølgende tilknytning til sag Modtagelse af dokumenter principiel hovedfunktionalitet: Ved modtagelse af dokumenter registreres typisk person/organisation, som har afsendt dokumenterne, hvilket kan gøres ved enten indtastning af oplysningerne eller ved fremsøgning af de nødvendige oplysninger i ESDH-systemets lokale persons/organisation- og adresseoplysningsregistre. ESDH-systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til dokumenter Fremsøgning, visning samt efterfølgende tilknytning til dokument Afsendelse af dokumenter principiel hovedfunktionalitet Ved afsendelse af dokumenter registreres typisk, at der er afsendt dokument samt modtager af dokumentet ESDH-systemets funktionalitet i denne forbindelse skal således indeholde mulighed for vedrørende person/organisation- adresseoplysninger: Inddatering, lagring og tilknytning til dokumenter Fremsøgning, visning samt efterfølgende tilknytning til dokument De tre nævnte overordnede funktioner oprettelse af sag, modtagelse af dokument, afsendelse af dokument kræver alle samme typer af funktionalitet i forbindelse med person/organisation- og adresseoplysninger. Den væsentligste forskel er, at det er data fra forskellige registre, der skal benyttes. Der er således i ESDH-systemet behov for data fra følgende typer af registre: Register over ansatte i egen organisation Register over personer der kan blive sagsparter (i princippet alle) Register over organisationer der kan blive sagsparter (i princippet alle både offentlige og private) De væsentligste krav, der således stilles, er, at Den daglige brug af og funktion af adresseoplysninger i sagsbehandlingen skal være mulig ESDH-systemers datamodel på person/organisation- og adresseoplysninger skal indrettes således, at de beskrevne dataoverførsler og opdateringer bliver mulig. 10 / 49

11 Det betyder, at det foreliggende arbejde skal skitsere de samlede dataelementer på person/organisations og adresseområdet også under hensyn til hvilke data der kan overføres fra CVR (Centrale virksomhedsregister), CPR (Centrale personregister), BBR (Bygnings- og Boligregister) / OIS (den Offentlige Informations Server) samt FOA (Fælles offentlig adressebase). 11 / 49

12 4 Del C Data og adresseområdet m.v. 4.1 Model for dataflow - adressedata Dataflow et skal understøtte de ønskede funktioner i et ESDH-system i relation til udarbejdelse af integrationer til de store stamregistre (CPR, CVR etc.) I princippet skal følgende logik kunne håndteres af et ESDH-system: CPR Inddatering CVR BBR FOA Stamregistre i eller online overførsel til ESDH-system. Baseret på import Dynamisk Partskartotek i ESDH-system. Tilvækst med tilvækst af Journalposter. Hver part/adresse er knyttet til mindst én Journalpost Statisk Figur 2 Det er således data fra det ovenfor nævnte dynamiske stamregistre, der knyttes til ESDH-specifikke data. Det deraf afledede Partskartotek er statisk, hvilket betyder, at fx en person med to adresser på forskellige tidspunkter kan optræde to gange i Partskartotek. Dette er nødvendigt, da journalisering af fx et brev, hvortil der knyttes en afsender, skal benytte personens aktuelle adresse for tidspunktet for brevets oprettelse. En yderligere binding til dette dataflow er et ønske om, at web-service knyttet til de store registre skal være mulig. Bemærk dog, at skitsen alene afspejler, hvad der skal være et muligt logisk dataflow og er ikke udtryk for eller forslag til faktiske implementeringer. 4.2 FESD adressedatamodel Introduktion og afgrænsning FESD-standarden på adresseområdet skal således åbne mulighed for, at adresseregistre m.v. i ESDHsystemer kan opdatere data via web-services (integrationer) knyttet til de store registre, dvs. CPR, CVR, BBR og også FOA. I det følgende gives en introduktion til FESD-adressedatamodellen og afgrænsning af relationerne til et antal "hoved-adressekilder". Formålet er at udveksle adressedata mellem adressesystemer og ESDH-systemer, som overholder FESD-standarden. Disse adressedata vil primært være baseret på adresser fra CPR-, BBR- og CVR-systemerne. Desuden omtales koblinger til adressedata i FOA-systemet samt til adresse-datamodeller i 12 / 49

13 EPJ-systemer, og OIOXML Adresseguide beskrives som den samlende standard for visse af de relevante data i denne sammenhæng CPR-systemet CPR-personadressedata hentes typisk ind i et ESDH-system som "read-only" og lagres som en del af sagen. Teknisk set vil det ligeledes kunne lade sig gøre, at et fagsystem i forbindelse med et standardiseret ESDHsystem kan anvende CPR-systemets interfaces til ajourføring af en persons CPR-adresse. Typisk ajourføres CPR-systemets data om borgere af medarbejdere i folkeregistrene, der anvender Javaklienter. Et system, der ligeledes ajourfører CPR-systemets venteregister, er KMD s P-data-system. Via dette system har borgeren mulighed for at indberette oplysning om flytning til CPR s venteregister. Borgerens oplysninger overføres først fra venteregistret til selve CPR-registeret, når en kommunal myndighed har valideret borgerens indberetning. Såfremt der identificeres andre behov for opdatering af CPR-adressedata, fx i forbindelse med FESD, så skal CPR-kontoret inddrages for at vurdere, om det er tilladeligt BBR-systemet I forbindelse med kommunikation mellem BBR og et ESDH-system forudsættes, at BBR-data for bygninger og ejendomme hentes ind i ESDH-systemet fra OIS, og at ESDH-systemet ikke kommunikerer direkte med KMD's forskellige centraler, herunder Århus' og Københavns kommunes EDB-centraler. Det forudsættes, at procedurer og krav til sikkerhed omkring anvendelse og opdatering af BBR-data er tilsvarende de, der gælder for andre store systemer med personhenførbare data, som fx ToldSkat - blot gældende på kommuneniveau. Anvendelse og opdatering af BBR-data finder således sted under et bruger- og autorisationssystem, som ligger i KMD-regi. Og opdatering af en kommunes BBR-oplysninger kan kun finde sted af autoriserede BBR-sagsbehandlere i den pågældende kommune. Anvendelsen (forespørgselsadgang) er kun mulig landsdækkende enten gennem BBR i SVUR eller i OIS, der drives af KMD CVR-systemet Virksomhedsdata i CVR-systemet ajourføres af de ansvarlige dataleverandører ToldSkat, E&S (Erhvervs- og Selskabsstyrelsen), DSt (Danmarks Statistik) og ABT (Arbejdstilsynet). Det er i regler fastlagt, hvem der har kompetence over hvilke data og for hvilke virksomhedsformer. E&S har fx selskaber som ansvarsområde. Og ToldSkat har enkeltmandsvirksomheder stadigvæk selv om den praktiske vedligeholdelse foretages via et system hos E&S. DSt har ansvar for vedligehold af de offentlige myndigheder. Vedligeholdsansvaret gælder for navn, adresse, virksomhedsform og livsforløb. For brancher ligger ansvaret formelt hos DSt, men 'alle' kan ajourføre. Til de enkelte virksomheder hører en eller flere produktionsenheder, der har 'samme slags data' med samme format fx ensartet opbygning af adresser som virksomheden, men hvor ansvaret formelt ligger hos DSt dog 'hjælper' ABT til med at ajourføre. For virksomhederne gælder i praksis, at de ansvarlige dataleverandørers egne systemer 'fanger' og kontrollerer data, fx adresser, og sender dem videre til CVR, hvis de er i orden. CVR-systemet indeholder ikke ret meget kontrol af data, idet det er lagt an på, at de ansvarlige leverandører også er de rette ansvarlige for datakvaliteten. Dette forventes også at være gældende for produktionsenhederne. CVR-systemet tilbyder desuden en browsergrænseflade, der er tænkt anvendt af myndigheder, som ikke selv har et eget 'datafangst- og registreringssystem', fx til brug for ABT Konklusioner vedr. CPR, BBR og CVR Det anbefales, at adressedata i første omgang alene modtages ind i FESD-systemerne fra "hovedadressekilderne", CPR-, BBR(OIS)- og CVR-systemerne dvs. en-vejskommunikation. Opdatering af adressedata bør ske direkte i de centrale registre. Senere - når færdigudbygget - forventes anvendelse af adressedata fra FOA-systemet også at komme på tale. 13 / 49

14 4.2.5 Kobling til FOA-systemet Det fælles offentlige adressesystem, FOA, har til formål at vedligeholde adresseoplysninger blandt andet for myndigheder og personer, som er tilknyttet den offentlige forvaltning i statslig regi. FOA-systemet indeholder en offentlig portal samt en redigeringsportal, som benyttes til at vedligholde entitetstyper, fx myndigheder og personer, samt postnumre, stillingsbetegnelser, partier, ordener osv. Både for personer og til myndigheder kan oprettes felter til bl.a. navn, adresselinier, postnummer, by, land, telefonnumre, faxnumre, mailadresser, hjemmesider samt CVR/CPR numre. Udover felterne til navn, adresse og øvrige kontaktoplysninger kan både for myndigheder og personer angives en værdi indenfor en række klassificeringer, det kunne fx være parti, lønramme m.v. Det er også muligt at vedligeholde myndighedseller ordenshierarkierne. Desuden findes en administrationsportal, som blandt andet benyttes til brugeradministration. Brugergrænsefladen til redigeringsportalen er webbaseret. Det overordnede formål for redigeringsportal er at tilbyde funktionalitet til at kunne søge og administrere diverse entiteter i systemet. FOA omfatter blandt andet følgende entiteter: Myndigheder, personer, funktioner (beskriver en persons tilknytning til en myndighed), titler (beskriver de titler en person kan have), partier (beskriver sammenhængen mellem partibetegnelser og partinavne), ordner (beskriver sammenhængen mellem ordenskoder og ordensnavne og kan tilknyttes personer). FOA-systemet består primært af en myndighedsdatabase og en persondatabase. Myndighedsdatabasen indeholder p.t aktive enheder. Persondatabasen indeholder ca personer. Alle personer i databasen er relateret til en eller flere enheder/myndigheder og/eller en eller flere ordener. Kobling til FOA er ikke medtaget i tidligere versioner af denne standard og heller ikke i denne version OIOXML adresseguide For at skabe sammenhæng til anden dataudveksling i det offentlige skal FESD-standarden på adresseområdet også rette ind efter den adresse-standardisering, der sker i XML-projektet, dvs. den eksisterende OIOXML adresseguide, som er en del af det standardiseringsarbejde, der fandt sted under den fælles offentlige XMLkomité i regi af Nøgledatagruppen. Nøgledatagruppens primære opgave er at tilvejebringe XML-beskrivelser af data i de tre nøglebaser: CVR - Det Centrale Virksomhedsregister, CPR - Det Centrale Personregister, BBR - Bygnings- og Boligregistret samt Told & Skats databaser. Formålet er at identificere og standardisere informationsobjekter, som er fælles for mange af de offentlige IT-systemer. En adresse er et sådant fælles informationsobjekt. I OIOXML adresseguide anbefales endvidere de adressetyper som Nøgledatagruppen finder bedst egnet som udvekslingsformat i forskellige situationer. OIOXML adresseguide standarden omfatter således data fra flere af de samme hovedkilder, som er relevante for ESDH-systemer, hvorfor FESD-standardiseringen anvender denne, hvad angår udvalg af data og beskrivelser af disse til udveksling i forbindelse med grænsesnit Kobling til adressedata i andre systemer: EPJ-systemer På sigt kan det være relevant og muligt at etablere en integration mellem ESDH-systemer og EPJ (Elektronisk Patient Journal)-systemer, da disse to typer systemer begge er baseret på CPR-informationer om personer i dette tilfælde patienter. De fleste EPJ-systemer og PAS (Patient Administrative)-systemer benytter (i princippet) samme adressedatamodel, som benyttes i CPR-systemet. EPJ/PAS-systemer fx GS (Grønt System) indeholder egne adressedatabaser for at sikre, at disse for samfundet kritiske systemer om nødvendigt kan køre uafhængigt af andre adressedata-kilder. Nye eller ændrede adressedata for personer (patienter) og ændrede vejregister-data overføres fra CPRregistret via batch-opdatering til de (centrale) EPJ/PAS-systemer, som abonnerer på CPR-systemets personadresse- og vejregisterdata. Det er desuden muligt at oprette egne person-adressedata i EPJ-systemet, men disse personadressedata vil blive overskrevet af eventuelle CPR-adressedata, som modtages fra CPR-registret 14 / 49

15 for samme CPR-nummer. Det tilstræbes, at adressedata i EPJ-systemer så vidt muligt er synkroniseret med personadresse- og vejregisterdata fra CPR-systemet. Der sker ingen eller kun begrænset transformation/mapning af adressedata, som modtages fra CPR-systemet. Tilsvarende sker der ingen eller kun begrænset berigelse af person (patient) adressedata i EPJ-systemerne. Et eksempel er dog den entydige personidentifikation, som oftest vil være det officielle CPR-nummer, som fås fra CPR-registret, men personidentifikationen kan i nødstilfælde udgøres af et midlertidigt erstatnings-cprnummer, som fx kan tildeles en patient, der ankommer bevidstløs til et sygehus. FESD-datamodellen på adresseområdet kobler ikke til EPJ-systemer, men da både EPJ- og FESDdatamodellen vedrørende personer og adresser relaterer sig til CPR-data, burde der kunne opnås kompatibilitet vedrørende disse data. 15 / 49

16 5 Del D. FESD-adressemodel Modellen er beskrevet ved anvendelse af UML. Den model, der beskrives i det efterfølgende, skal som tidligere nævnt kunne anvendes i forbindelse med: 1. Håndtering af sagstyper hvor en person, en organisation eller en virksomhed er sagens hovedemne. 2. Håndtering af stedrelaterede sagstyper; eksempelvis miljø-, ejendoms- og matrikelsager. 3. Håndtering af kontaktinformationer for sagsparter. For at dække punkt 1 skal modellen kunne indeholde data om: Individuelle personer. Råd, nævn og udvalg inklusiv tværorganisatoriske. Organisationer og virksomheder. Organisatoriske enhedstyper som afdeling, styrelse, kontor og lignende. 16 / 49

17 5.1 Beskrivelse af klasser class FESD Adressemodel «enumeratio... Koordina tsystem «enumeration» kontaktadressetype system 34 system 45 «enum» KP2000 Postadr utmed50 Besøgsadr coadresse utmeuref89 JournalP ostpart Adressepunkt Leveringsadr + conavn: char(255) Fakturaadr + koordinatsystem: KoordinatSystem «enumeratio... + koordinatx: flow TelefonType + koordinaty: flow Telefon 0..1 «enum» Udlands Adresse Privat + telefonnummer: char(20) 1 Erhverv + adresselinie1: char(34) La nd Mobil + adresselinie2: char(34) Indlandsadresse Telefax 0..* + adresselinie3: char(34) + landkode: char(2) + adresselinie4: char(34) 0..*1 + landnavn: char(40) 1 0..* + bynavn: char(34) + adresselinie5: char(34) + doerbetegnelse: char(4) [0..1] + adresselinie6: char(34) + etage: char(2) [0..1] TelefonRolle kontaktadresserolle + husnr: char(4) + kommunenr: int(4) + telefonbemærkningtekst: char(255) + kontaktadressetype: kontaktadressetype + lokalitetsnavn: char(34) [0..1] ElektroniskPostadresse + telefontype: TelefonType + postboks: ch ar(4) [0..1] Vej 0..* + postnr: int(4) + epostadresse: uri:mailto + vejkode: char(4) + epostadressebeskrivelse: char(255) + vejadresseringsnavn: char(20) Adresse + primaerindikator: Boolean + vejkode: int(4) 1 0..* + landkode: char(2) + vejnavn: char(40) 0..* 1 0..* 1 +foraeldregruppe Sammensa tadresse 0..1 KontaktGruppe Kommune Ejerlav + Adresse: char(255) + gruppenavn: char(50) KontaktGenstandRolle + kommunenr: integer(4) + kommunenavn: char(20) + kommuneejerlavsnavn: char(16) + slutdato: date [0..1] + postnr: integer(4) 0..* 1 + kommunenr: int(4) 1 0..* + kommuneejerlavsnr: int(3) + startdato: date + vejkode: integer(4) + kommunenr: int(4) +delgruppe landsejerlavsnavn: char(40) 0..* Kontakt + landsejerlavsnr: int(4) +sourcecontact Gens tand «enumeration» KontaktRelation + kontakttype: KontaktType 0..* 1 KontaktRelationKodeType + kortnavntekst: char(8) + genstandstype: char(34) + beskrivelsetekst: char(255) + opdateretaf: string + opdateretaf: char(34) + kontaktrelationkode: KontaktRelationKodeType + opdateretdato: datetime + opdateretdato: datetime MatrikelOplysning «enum» +targetcontact Medarbejder + slutdato: date [0..1] + reklamebeskyttelse: boolean + delnr: integ er(3) [0..1] Afdeling + startdato: date [0..1] + kommunenr: int(4) Enhed + landsejerlavnr: int(4) JuridiskEnhed + matrikelbogstav: char(3) Produkti onsenhed + matrikelnr: int(4) + parcelnr: string Sagspart sagsgenstand + beskrivelsetekst: char(255) + sagspartrolle: char(40) + Beskrivelse: char(255) «enumeration» + sagspartundtagetoffentlighed: boolean + Navn: char(255) Kontak ttype + Rolle: char(50) «enum» Organi sation Person Person + adresseringsnavn: char(34) [0..1] + akademisktitel: char(50) + beskyttelseslutda to: date [0..1] + cprnr: int(10) [0..1] + cprnrstatus: int(2) [0..1] + doedindikator: boolean + efternavn: char(40) + foedselsdato: date [0..1] + foedselsdatousikker: boolean [0..1] + fornavn: char(50) + koen: char(1) + mellemnavn: char(50) [0..1] + professioneltitel: char(50) + reklamebeskyttelse: boolean Organi sation + bibranchekode: int(6) [0..*] + branchekode: int(6) [0..1] + cvrnr: int(8) [0..1] + EanNr: int(10) + enhedophoerdato: date [0..1] + enhedstartdato: date [0..1] + organisationsnavn: char(50) + orgenhednavn: char(50) + orgophoer: date [0..1] + orgstart: date [0..1] + pnr: int(10) [0..1] + virksomhedsform: int(3) [0..1] + webadresseurl: URI * OrganisationstypeType Sag Bygning + BBRidentifikator: char(15) + bygningsnr: int(4) + ejendomsnr: int(6) [0..1] + kommunenr: int(4) [0..1] 0..* Ej endom + ejendomsnr: int(6) + kommunenr: int(4) Generisk Genstand Name: FESD Adressemodel Author: Claus Rantzau Version: Created: :00:00 Updated: :52:33 GeneriskGe nstandtype + typenavn: char(110) Figur 3 17 / 49

18 5.1.1 Adresse Klassen Adresse har ikke selvstændig mening, men fungerer i sammenhæng med associerede adresse-klasser DAN ENG Type Kardinalitet Beskrivelse landkode countryidentificationcode char(2) [1] ISO-betegnelse for land. Refererer til klassen Land. Herfra kan landnavn hentes. Alle instanser har default = DK, da denne klasse primært benyttes til danske adresser. Relationer SammensatAdresse. Adresse. Adresse. JournalPostPart. UdlandsAdresse. Adresse. coadresse. Adresse. Kontakt. Adresse. Genstand. Adresse. Indlandsadresse. Adresse. 18 / 49

19 5.1.2 Adressepunkt Adressepunktet er et geografisk punkt. Kommunen skal placere adressepunktet indenfor den bygning eller det matrikelnummer som adressen hører til. Adressekoordinaterne er de geografiske koordinater (X,Y) som viser adressepunktets præcise beliggenhed. Type Kardinalitet Beskrivelse DAN ENG koordinatsystem coordinatesystemcode Koordinat- System [1] Koordinatsystemet vælges fra Klassen Koordinat- System koordinatx XCoordinate flow [1] X-koordinaten for punktet. Beskrives med det i koordinatsystem angivne system. koordinaty YCoordinate flow [1] Y-koordinaten for punktet. Beskrives med det i koordinatsystem angivne system Relationer 1 Indlandsadresse Adressepunkt. Enumeration - KoordinatSystem DAN system34 system45 KP2000 utmed50 utmeuref89 ENG system34 system45 KP2000 utmed50 utmeuref89 19 / 49

20 5.1.3 Bygning Klassen Bygning DAN ENG Type Kardinalitet Beskrivelse BBRidentifikator BBRIdentfier char(15) [1] Unik identifikator dannet af BBR. Unik for hver bygning i Danmark. bygningsnr buildingidentifier integer(4) [1] Bygningsnummeret er en entydig nummerering af ejendommens bygninger. ejendomsnr municipalrealpropertyidentifier integer(6) [0..1] Ejendomsnummeret identificerer den enkelte ejendom indenfor kommunen. kommunenr municipalitycode integer(4) [0..1] Reference til Kommune. Kommunekode Relationer Bygning. Genstand. 0..* Bygning. Ejendom. 0..* Bygningsenhed. Bygning. 20 / 49

21 5.1.4 Bygningsenhed Klassen BygningsEnhed kan være bolig- eller erhvervsenhed. DAN ENG Type Kardinalitet Beskrivelse bygningsnr buildingidentifier integer(4) [1] Bygningsnummeret er en entydig nummerering af ejendommens bygninger. ejendomsnr municipalityrealpropertyidentifier integer(6) [0..1] Ejendomsnummeret identificerer den enkelte ejendom indenfor kommunen. lejlighedsnr appartmentnumber integer(4) [0..1] Unik identifikator for BygningsEnhed indenfor bygningen. Relationer 0..* Bygningsenhed. Bygning coadresse Klassen coadresse kan knyttes til Adresse klassen DAN ENG Type Kardinalitet Beskrivelse conavn careofname char(255) [1] Navnet på den person der er ejer eller lejer af den bolig, kontakten bor i. Anvendes i tilfælde hvor pgl. kontakt ikke har eget navneskilt på dør/postkasse/etc. 21 / 49

22 Relationer coadresse. Adresse Ejendom Klassen Ejendom Type Kardinalitet Beskrivelse DAN ENG ejendomsnr municipalityrealpropertyidentifier integer(6) [1] Ejendomsnummeret identificerer den enkelte ejendom indenfor kommunen. Når ejendomsnummeret suppleres med kommunenummeret identificerer det entydigt den enkelte ejendom på landsplan. kommunenr municipalitycode integer(4) [1] Reference til Kommune. Kommunekode Relationer 0..* Bygning. Ejendom. Ejendom. Genstand. 22 / 49

23 5.1.7 Ejerlav Klassen ejerlav DAN ENG Type Kardinalitet Beskrivelse kommuneejerlavsnavn cadastraldistrictmunicipalname char(16) [1] Kommuner definer ofte egne ejerlav kommuneejerlavsnr cadastraldistrictmunicipalidentifier integer(3) [1] Kommuner definer ofte egne ejerlav. kommunenr municipalitycode integer(4) [1] Reference til Kommune. Kommunekode landsejerlavsnavn cadastraldistrictname char(40) [1] Kode og betegnelse for det landsejerlav, hvor ejendommens matrikelnumre er beliggende. Et landsejerlav er et geografisk afgrænset område, der er en del af et sogn i et herred. Det er oprindelig et jordfællesskab. landsejerlavsnr cadastraldistrictidentifier integer(4) [1] Kode og betegnelse for det landsejerlav, hvor ejendommens matrikelnumre er beliggende. Et landsejerlav er et geografisk afgrænset område, der er en del af et sogn i et herred. Det er oprindelig et jordfællesskab. Relationer 0..* MatrikelOplysning. 1 Ejerlav. 0..* Ejerlav. 1 Kommune. 23 / 49

24 5.1.8 ElektroniskPostadresse Klassen ElektroniskPostadresse DAN ENG Type Kardinalitet Beskrivelse epostadresse addressidentifier uri:mailto [1] adresse i standard uri-form; <navn>@<domæne> epostadressebeskrivelse descriptiontext char(255) [1] Beskrivelse af adressen. Fri tekst primaerindikator primaerindikator Boolean [1] 1 = Primær Relationer 1 Kontakt. 0..* ElektroniskPostadresse GeneriskGenstand Klassen GeneriskGenstand er uden attributter og beregnet til at angive forskellige slags af genstand for sagsbehandlingen. Generisk genstand kan fx være en bil, hvis den er genstand for sagen. Relationer GeneriskGenstand. Genstand. GeneriskGenstand. GeneriskGenstandType. 24 / 49

25 GeneriskGenstandType Klassen GeneriskGenstandType er uden attributter og knyttes alene til klassen GeneriskGenstand Relationer GeneriskGenstand. GeneriskGenstandType Genstand Klassen Genstand samler information om sagens genstand, som kan være en bygning, en ejendom, eller en anden form for genstand for sagen. DAN ENG Type Kardinalitet Beskrivelse genstandstype itemtype char(34) [1] Typen af genstand opdateretaf updatedby char(34) [1] Den der har opdateret opdateretdato updateddate datetime [1] Opdateringsdato Relationer Bygning. Genstand. GeneriskGenstand. Genstand. Ejendom. Genstand. 25 / 49

26 Genstand. Sag. Genstand. Adresse. Genstand. Kontakt Indlandsadresse Klassen Indlandsadresse til danske adresser DAN ENG Type Kardinalitet Beskrivelse bynavn districtsubdivisionidentfier char(34) [1] Det fastsatte bynavn præciserer beliggenheden inden for en kommune eller postdistrikt. Et evt. bynavn er en nødvendig del af den fuldstændige og korrekte adresse. Et bynavn skal fastsættes, når der findes ens eller enslydende vejnavne i postdistriktet eller kommunen. bynavn kan bestå af indtil 34 tegn. doerbetegnelse suiteidentifier char(4) [0..1] Identifikation som beskriver beliggenheden af en bestemt indgangsdør på en etage (trappeafsats) i den pågældende opgang. Betegnelserne tv, mf og th bruges, når der er indtil tre døre på trappeafsatsen. Hvis der er flere døre anvendes tallene 1, 2, 3, 4 osv. Andre betegnelser på indtil 4 tegn kan dog også fastsættes. På etager med fire enheder kan betegnelserne TV, MFTV, MFTH og TH anvendes. 26 / 49

27 etage flooridentifier char(2) [0..1] Etagen, hvor enheden er beliggende. Etagen kan antage følgende værdier: Den etage hvis gulvplan ligger i eller umiddelbart over gadeniveau benævnes ST De følgende etager herover benævnes nedefra og opefter 1, 2, 3, til 99 Kældre (etagerne under gadeniveau) benævnes KL K2 K3 til K9 i retning ovenfra og nedefter Etagen angives ikke, hvis der kun er en enhed i bygningen. husnr streetbuildingidentifier char(4) [1] Nummerbetegnelse inkl. et evt. stort bogstav, som identificerer en bestemt adgang til en bygning, en grund eller et teknisk anlæg og lign. med udgangspunkt i dén navngivne vej, som giver adgang hertil. Ved Husnummer forstås i Danmark altid husnummer inkl. evt. bogstav. Indgår et bogstav i adressen, er dette en nødvendig del af den fuldstændige og korrekte adresse. Et husnummer består af et tal i intervallet Husnummeret kan have tilknyttet et bogstav fra A til Z. kommunenr municipalitycode integer(4) [1] Reference til Kommune. Kommunekode lokalitetsnavn maildeliverysublocationidentifier char(34) [0..1] Ikke entydigt navn for lokalitet. lokalitetsnavn (gårdnavn, bygningsnavn e.l.) kan knyttes til en enkelt eller flere adresser 27 / 49

28 i en bygning eller et bygningskompleks lokalitetsnavn består af indtil 34 tegn som indgår i den officielle adressebetegnelse, f.eks. fra CPR Reglerne herom findes i 17, stk. 3, i Cirkulære om ajourføring af CPRs vej- og boligregister (Cirkulære nr. 130 af 25. november 2002). postboks postofficeboxidentifier char(4) [0..1] Nummer eller anden identifikation af postboks jvf. Post Danmark. postnr postcodeidentifier integer(4) [1] Et postnummer består af fire cifre. Refererer til klassen PostDistrikt. Herfra kan postdistrikt hentes (tekstbetegnelse for distriktet) vejkode streetcode char(4) [1] Vejkoden består af fire cifre i intervallet Intervallet kaldes 'højvejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i Danmark. Refererer til klassen Vej. Herfra kan udledes såvel vejnavn som vejadresseringsnavn Relationer 0..* Indlandsadresse. 1 PostDistrikt. Indlandsadresse. Adresse. 28 / 49

29 0..* Indlandsadresse. 1 Kommune. 0..* Indlandsadresse. 1 Land. 0..* Indlandsadresse. 1 Vej. 1 Indlandsadresse Adressepunkt JournalPostPart Kobling fra Adresse til klassen JournalPostPart indeholder parten til journalposten. JournalPostPart er beskrevet i sager og dokumenter Relationer Adresse. JournalPostPart Kommune Klassen Kommune DAN ENG Type Kardinalitet Beskrivelse kommunenavn municipalityname char(20) [1] Kommunens officielle navn kommunenr municipalitycode integer(4) [1] Reference til Kommune. Kommunekode 29 / 49

30 Relationer 0..* SammensatAdresse. 1 Kommune. 0..* Indlandsadresse. 1 Kommune. 0..* Ejerlav. 1 Kommune Kontakt Klassen Kontakt relaterer sag til navn- og adressemodellen. DAN ENG Type kontakttype contacttype KontaktType Kardinalitet Beskrivelse [1] Typen af kontakt kortnavntekst shortnametext char(8) [1] Kortnavn for kontakten der kan anvendes som pseudonøgle (f.eks. initialer på person) opdateretaf UpdatedBy string [1] Navn på den, der har opdateret opdateretdato updateddate datetime [1] Dato for opdatering reklamebeskyttelse marketingprotectionindicator boolean [1] Angiver om der er reklame-beskyttelse for instansen. ten reflekterer den tilsvarende oplysning i CPR- og CVR-registrene 30 / 49

31 Relationer KontaktGruppe. Kontakt. 0..* DigitalSignatur. 1 Kontakt. Organisation. Kontakt. Person. Kontakt. Kontakt. Sag. Kontakt. Kontakt. 1 Kontakt. 0..* ElektroniskPostadresse. 1 Kontakt. 0..* Telefon. Kontakt. Adresse. Genstand. Kontakt. 31 / 49

32 Enumeration - KontaktType DAN Organisation Person ENG Organization Person kontaktadresserolle Klassen KontaktAdresseRolle angive typen af adresse DAN ENG Type Kardinalitet Beskrivelse kontaktadressetype contactaddresstype kontakt- AdresseType [1] Typen på kontaktadresse jf. udfaldsrum Enumeration - kontaktadressetype DAN Postadr Besøgsadr Leveringsadr Fakturaadr ENG Postaladdr Visitaddr Deliveryaddr Invoiceaddr KontaktGenstandRolle Klassen KontaktGenstandRolle indeholder ingen attributter. Angiver genstandens rolle som kontakt. 32 / 49

33 KontaktGruppe Klassen KontaktGruppe dækker alle former for udvalg, råd og nævn, såvel indenfor en organisation som tværorganisatorisk. DAN ENG Type Kardinalitet Beskrivelse gruppenavn groupname char(50) [1] Gruppens navn slutdato grouptodate date [0..1] Gruppens slutdato startdato groupfromdate date [1] Gruppen oprettelsesdato Relationer KontaktGruppe. Kontakt KontaktGruppe.foraeldreGruppe 0..* KontaktGruppe. delgruppe KontaktRelation Klassen KontaktRelation angiver rollen for kontakt DAN ENG Type Kardinalitet Beskrivelse beskrivelsetekst roledescription char(255) [1] Kort, men dækkende beskrivelse af rollen. kontaktrelationkode rolename KontaktRe- lationkode- Type [1] kontaktrealionkode angiver funktionen. Kan eventuelt være stillingsbetegnelse startdato startdate dato [0..1] Dato for start af rollen slutdato enddate dato [0..1] Dato for slut på rollen 33 / 49

34 Enumeration - KontaktRelationKodeType DAN ENG Medarbejder Afdeling Enhed JuridiskEnhed Produktionsenhed Employee Department Unit LegalUnit ProductionUnit Land Klassen Land Type Kardinalitet Beskrivelse DAN ENG landkode countryidentificationcode char(2) [1] ISO-betegnelse for land. Refererer til klassen Land. Herfra kan landnavn hentes. Alle instanser har default = DK, da denne klasse primært benyttes til danske adresser. landnavn countryname char(40) [1] Landets navn Relationer 0..* UdlandsAdresse. 1 Land. 34 / 49

35 0..* Indlandsadresse. 1 Land MatrikelOplysning Klassen MatrikelOplysning til beskrivelse af matrikler DAN ENG Type Kardinalitet Beskrivelse delnr sublandparcelidentifier Integer(3) [0..1] Oplysning fra ESR. Benyttes af kommunen som midlertidig betegnelse kommunenr municipallitycode integer(4) [1] Reference til Kommune. Kommunekode landsejerlavnr cadastraldistrictidentifier integer(4) [1] Kode og betegnelse for det landsejerlav, hvor ejendommens matrikelnumre er beliggende. Et landsejerlav er et geografisk afgrænset område, der er en del af et sogn i et herred. Det er oprindelig et jordfællesskab. matrikelbogstav landparcelletter char(3) [1] Fra 1 til 3 bogstaver anvendes. Kun små bogstaver er tilladte. Alle bogstaver bortset fra 'j', 'w' og 'å' er tilladte. matrikelnr landparcelidentifier integer(4) [1] Matrikelnummeret er et nummer, der identificerer matriklen (jordstykket). En ejendom kan bestå af flere matrikelnumre. matrikelnr kan antage værdier fra 1 til parcelnr parcelidentifier string [1] Anvendes af kommunen som midlertidig betegnelse for parcellen Relationer 35 / 49

36 0..* MatrikelOplysning. 1 Ejerlav Organisation Klassen Organisation beskriver organisationer og virksomheder DAN ENG Type Kardinalitet Beskrivelse bibranchekode secondbusinessactivity integer(6) [0..*] Eventuelt andre brancher end den i branchekode angivne. Anvender samme værdimængde som branchekode. branchekode companycategory integer(6) [0..1] Organisationens primære branche. Branchebetegnelserne er harmoniseret i EU, og gengivet i "Dansk Branchekode 1993, 2. udg." (DB93). Enhederne tildeles en branche ud fra de 810 brancher i DB93, efter en konkret analyse eller efter bedste skøn. cvrnr CVRNumberIdentifier integer(8) [0..1] Det tildelte CVR-nummer. EanNr EANNumber integer(10) [1] Det tildelte EAN-nummer enhedophoerdato unitstop date [0..1] Ophørsdatoen for en enhed angiver første dag enheden er inaktiv efter en aktiv periode. enhedstartdato unitstart date [0..1] Startdatoen for en enhed. Startdatoen er den første dag enheden er aktiv. Efter evt. genstart angiver startdatoen første dag enheden igen er aktiv. organisationsnavn legalunitname char(50) [1] Navnet på organisationen eller virksomheden orgenhednavn organizationunitname char(50) [1] Navn på den organisatoriske enhed. orgophoer organizationenddate date [0..1] Dato for ophør for organisation 36 / 49

37 orgstart organizationstartdate date [0..1] Dato for starten på organisationen/virksomhedsform. Startdatoen afhænger af den juridiske enheds virksomhedsform. For enheder, der er registreret hos Erhvervs- og Selskabsstyrelsen, er startdato som udgangspunkt stiftelsestidspunktet. For ToldSkats enheder vil startdatoen være datoen for pligternes ikrafttræden. pnr pnr integer(10) [0..1] P-nummeret er det entydige identifikationsnummer for en p-enhed i CVR. I modsætning til CVRnummeret er offentlige myndigheder ikke forpligtet til at anvende p-nummeret i kommunikationen med og om p-enheder. virksomhedsform ownershiptypecode integer(3) [0..1] Virksomhedsform fx A/S webadresseurl webaddress URI [1] Organisationens officielle webadresse Relationer 0..* Organisation OrganisationstypeType. Organisation. Kontakt OrganisationstypeType Klassen OrganisationsType angiver typen af organisation Type Kardinalitet Beskrivelse DAN ENG typenavn typename char(110) [1] Typificering af virksomheden efter eget valg 37 / 49

38 Relationer 0..* Organisation OrganisationstypeType Person Klassen Person DAN ENG Type Kardinalitet Beskrivelse adresseringsnavn personname char(34) [0..1] Jvn.f. 5 i Indenrigsministeriets bekendtgørelse nr. 842 af 13. oktober akademisktitel academictitle char(50) [1] Akademisk titel beskyttelseslutdato nameaddressprotectionenddate date [0..1] Angiver datoen for adressebeskyttelsens ophør. Normalt et år efter beskyttelsens oprettelse. cprnr personcivilregistrationidentifier integer(10) [0..1] Entydig identifikation på en person. CPR-nummer cprnrstatus personcivilregistrationidentifierstatuscode integer(2) [0..1] Angiver om et personnummer er aktiv, inaktiv eller en række andre oplysninger. doedindikator deathindicator boolean [1] Angivelse om personen er død. Antager værdien 1 såfremt personen er død. efternavn personsurname char(40) [1] Efternavn på person. Feltets indhold kan bestå af flere navne adskilt af en blank position eller af en bindestreg. Feltet kan være blank for børn, hvis disse endnu ikke er navngivet. foedselsdato birthdate date [0..1] Dato angivet som DDMMYYYY foedselsdatousikker birthdateuncertaintyindicator boolean [0..1] Sættes til true når angivelsen af fødselsdatoen er behæftet med usikkerhed. Sættes altid til true når foedselsdato ingen værdi har. 38 / 49

39 fornavn persongivenname char(50) [1] Fornavn på person koen persongendercode char(1) [1] 'koen' kan sættes til værdierne 'K' (for kvinde) eller 'M' (for mand), mellemnavn personmiddlename char(50) [0..1] Mellemnavn(e) på person professioneltitel title char(50) [1] Personens erhvervsmæssige titel, knyttet til personens stilling/funktion reklamebeskyttelse personinformationprotectionindicator boolean [1] Markering der viser om personen har navne- /adressebeskyttelse Relationer Person. Kontakt PostDistrikt Klassen Postdistrikt Type Kardinalitet Beskrivelse DAN ENG postdistrikt districtname char(20) [1] Tekstbetegnelse for postdistriktet. postnr postcodeidentifier integer(4) [1] Id defineret af Post Danmark. Postnummer Relationer 39 / 49

40 0..* Indlandsadresse. 1 PostDistrikt Sag Kobling fra Kontakt og Genstand til Klassen Sag, som er beskrevet i Sager og dokumenter Relationer Kontakt. Sag. Genstand. Sag sagsgenstand Klassen sagsgenstand angiver genstandens rolle i forhold til sagen Type Kardinalitet Beskrivelse DAN ENG beskrivelse descriptiontext char(255) [1] Beskrivelse af genstand navn name char(255) [1] Navn på genstand rolle role char(50) [1] Genstandens rolle i forhold til sagen, i den specifikke relation mellem de to klasser 40 / 49

41 Sagspart Klassen Sagspart, som angiver oplysninger vedrørende part i en sag. Oplysninger vedrørende sagspart skal opdateres dynamisk. DAN ENG Type Kardinalitet Beskrivelse beskrivelsetekst casefilepartydescription char(255) [1] Beskrivelse af sagspart i klartekst sagspartrolle casefilepartyrole char(40) [1] Beskrivelse af sagspartens rolle sagspartundtagetoffentlighed casefilepartynotpublic boolean [1] Markering af om sagsparten er undtaget offentlighedens kendskab. 1= Ja SammensatAdresse Klassen SammensatAdresse angiver aggregerede adresseoplysninger og er medtaget af praktiske årsager DAN ENG Type Kardinalitet Beskrivelse adresse address char(255) [1] Hele adressen i samme felt kommunenr municipalitycode integer(4) [1] Reference til Kommune. Kommunekode postnr postcodeidentifier integer(4) [1] Id defineret af Post Danmark. Postnummer vejkode streetcode integer(4) [1] Vejkoden består af fire cifre i intervallet Intervallet kaldes 'højvejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i Danmark. Refererer til klassen Vej. Herfra kan udledes såvel vejnavn som vejadresseringsnavn 41 / 49

42 Relationer SammensatAdresse. Adresse. 0..* SammensatAdresse. 1 Vej. 0..* SammensatAdresse. 1 Kommune Telefon Klassen Telefon DAN ENG Type Kardinalitet Beskrivelse telefonnummer telephonnumberidentifier char(20) [1] Telefonnummer Relationer 1 Kontakt. 0..* Telefon. 42 / 49

43 TelefonRolle Klassen Telefonrolle angiver typen af telefon DAN ENG Type Kardinalitet Beskrivelse telefonbemærkningtekst telephonedescriptiontext char(255) [1] Beskrivelse telefontype telephonetype TelefonType [1] Typen af telefon jf. udfaldsrum Enumerationsliste - TelefonType DAN Privat Erhverv Mobil Telefax ENG Private Business Mobile Fax UdlandsAdresse Klassen UdlandsAdresse Type Kardinalitet Beskrivelse DAN ENG adresselinie1 postaladdressfirstlinetext char(34) [1] Første linie i adressebeskrivelse til udenlandsk adresse adresselinie2 postaladdresssecondlinetext char(34) [1] Anden linie i adressebeskrivelse til udenlandsk adresse adresselinie3 postaladdressthirdlinetext char(34) [1] Tredje linie i adressebeskrivelse til udenlandsk 43 / 49

44 adresse adresselinie4 postaladdressfourthlinetext char(34) [1] Fjerde linie i adressebeskrivelse til udenlandsk adresse adresselinie5 postaladdressfifthlinetext char(34) [1] Femte linie i adressebeskrivelse til udenlandsk adresse adresselinie6 postaladdresssixthlinetext char(34) [1] Sjette linie i adressebeskrivelse til udenlandsk adresse Relationer UdlandsAdresse. Adresse. 0..* UdlandsAdresse. 1 Land Vej Klassen Vej. Vejnavn, vejadresseringsnavn og vejkode registreres i CPRs vejregister. Alle vejnavne og vejkoder som registreres i CPRs vejregister er knyttet til den pågældende kommune. Type Kardinalitet Beskrivelse DAN ENG vejadresseringsnavn streetaddressname char(20) [1] Eventuel forkortet udgave af vejnavn på indtil 20 tegn. Hvis vejnavn ikke overstiger 20 tegn skal de to navne være ens. For veje med vejkoder i intervallet må vejadresseringsnavn kun indeholde en af følgende angivelser: 44 / 49

45 1) Kommunenavnet samt evt. et nummer. 2) Teksten KOMMUNEKONTORET samt evt. et nummer. 3) Teksten FOLKEREGISTRET samt evt. et nummer. 4) Teksten UDEN FAST BOPÆL samt evt. et nummer. 5) Teksten UKENDT ADRESSE samt evt. et nummer. vejkode streetcode integer(4) [1] Vejkoden består af fire cifre i intervallet Intervallet kaldes 'højvejkode' og er afsat til særlig anvendelse. Vejkode angiver koden for den gade/vej, hvor ejendommen/bygningen/enheden er beliggende. Vejkode danner sammen med kommunekode en entydig kode for en vej i Danmark. vejnavn streetname char(40) [1] Det fuldstændige og korrekte vejnavn. 45 / 49 Et vejnavn angiver en bestemt fysisk vej, plads, torv, sti o.l. efter reglerne i adressecirkulærets 7. Et vejnavn kan sammensættes af indtil 40 tegn. For veje med vejkoder i intervallet må vejnavn kun indeholde en af følgende angivelser: 1) Kommunenavnet samt evt. et nummer. 2) Teksten KOMMUNEKONTORET samt evt. et nummer. 3) Teksten FOLKEREGISTRET samt evt. et

46 nummer. 4) Teksten UDEN FAST BOPÆL samt evt. et nummer. 5) Teksten UKENDT ADRESSE samt evt. et nummer. Relationer 0..* SammensatAdresse. 1 Vej. 0..* Indlandsadresse. 1 Vej. 46 / 49

47 6 Anvendte typer i FESD-modellerne FESD-modellerne er udarbejdet i UML med det formål at beskrive den logiske informationsarkitektur i en FESD-løsning. UML-modellen er opbygget af et antal klasser, der igen er opbygget af relationer til andre klasser og primitive typer, så man kan opfatte UML-modellen som opbygget af byggesten, hvoraf den mindste er de primitive datatyper. I UML-modellen beskriver de primitive datatyper det logiske domæne, som datatypen kan antage, men ikke hvordan den fysiske repræsentation af data skal være. I skemaerne ses for hver primitiv datatype, der anvendes i FESD-UML-modellen, den tilsvarende datatype for hhv. SQL og XSD. integer Benyttes til angivelse af heltal. Der kan benyttes en angivelse af max længde hvis intet er angivet, vil domænet være i intervallet mellem og Anvendte længder i den nuværende model: 2, 3, 4, 6, 8, 10. Benyttes alene til naturlige tal (positive heltal). Benyttes også til at danne identifikator med udfaldsrum UML Type Beskrivelse SQL datatype XSD datatype Integer (int) NonNegativeInteger Heltal i rummet mellem og , begge tal inclusive. Den maksimale længde angives i modellen. Naturlige tal Heltal i rummet mellem 0 og , begge tal inclusive NUMBER(Maksimal længde) NUMBER(Maksimal længde) xsd:int xsd:int boolean Er en grundtype i UML. UML Type Beskrivelse SQL datatype XSD datatype Boolean Udfaldsrummet er binært true / false (eller rigtigt / forkert). BOOLEAN xsd:boolean Identifikationstyper UML Type Beskrivelse SQL datatype XSD datatype URI Enhver mulig lovlig URI. Der kan evt. anvendes en maxlængde. STRING xsd:anyuri 47 / 49

48 HttpURI Lovlig http(s)-adresse STRING xsd:anyuri MailToURI Smtp-adresse på en mailmodtager. STRING Evt. restrictions der afgrænser til http. xsd:anyuri UUID Identifikator på objekt UUID xsd:anyuri UserIdentifier SystemIdentifier BinaryObject Det er en identifikation af bruger Det er en identifikation af systemer Et binary large object - også kaldet blob - er en samling af binære data, der opbevares som en separat entitet i et database management system. Blobs er typisk billeder, lyd og andre medieobjekter, selvom binær eksekverbar kode til tider også opbevares som en blob. Database support for blob er ikke universal. Binary Large Object (BLOB) Evt. restrictions der afgrænser til mailadresser. Evt. restrictions der afgrænser til UUID. char Benyttes til karakterstrenge af varierende længde, men med en defineret maksimal længde. Anvendte længder: 1, 2, 3, 4, 15, 16, 20, 34, 40, 50, 60, 70, 110, 120, 255. Benyttes også nogle steder til at angive en boolsk værdi. UML Type Beskrivelse SQL datatype XSD datatype Char ShortText Text Code Name ReferenceText Den minimale og maksimale længde er angivet i modellen. Anvendes til felter der indeholder en kort beskrivende tekst Anvendes til en beskrivende tekst med en fast længde. Anvendes til at beskrive en kode, der er nøgle/fremmednøgle i en opslagstabel. Anvendes til felter der indeholder navne, der kan opfattes som brugervendte nøgler. Anvendes til at felter der indeholder tekster, der af brugerne opfattes som fremmednøgler. VARCHAR(maksimal længde) VARCHAR(70) VARCHAR(255) VARCHAR(2) VARCHAR(70) VARCHAR(40) xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde xsd:string Med restriction på den maximale længde 48 / 49

49 date, datetime og time. Typen Date bruges til at angive dato. Typen DateTime bruges til Dato og tidspunkt, også i betydningen tidsstempel. Typen Time bruges til klokkeslæt. UML Type Beskrivelse SQL datatype XSD datatype Year Årstal VARCHAR (4) xsd:gyear Date Dato DATE xsd:date DateTime Dato og tidspunkt DATETIME xsd:datetime Time Tidspunkt uden datoangivelse TIME xsd:time string Er en grundlæggende type i UML. UML Type Beskrivelse SQL datatype XSD datatype String Tekststreng af vilkårlig længde STRING xsd:string float Defineres som sådan: UML Type Beskrivelse SQL datatype XSD datatype Float Decimaltal hvor længde og præcision begrænses til en samlet størrelse på 16-bit. DECIMAL(X,Y) xsd:float 49 / 49