DATAMODEL FOR VANDFORSYNING

Transkript

1 DANVA DANVAND DATAMODEL FOR VANDFORSYNING Beskrivelse Version 1.1 September 2009

2

3 INDHOLDSFORTEGNELSE 1. INDLEDNING Afgrænsning Læsevejledning LEDNINGSNETVÆRK Begreber Knuder og komponenter Knude og komponenter - relationsbeskrivelse Ledninger Regler i ledningsnettet Rørkatalog og komponentkataloger Ventiler Punkter på ledninger Bygværker HISTORISKE DATA Nedlæggelse af ledning Udskiftning af ledning mellem to knuder Deling af en ledning Udskiftning af en del af en ledning Sammenlægning af ledninger Udskiftning af en knude OPRINDELSE ZONER VÆRDIANSÆTTELSE KODETABELLER REFERENCESYSTEMER GEOGRAFISKE INFORMATIONSSYSTEMER UDVEKSLINGSFORMAT XML Netværksstruktur Navngivning af namespaces Definerede XML-schemas Rækkefølge for indsættelse af data fra XML-filer REGLER FOR DESIGN AF DATAMODELLEN Normalisering...31 i

4 11.2 Navngivning Navngivning af tabeller Navngivning af felter Navngivning af sequences...32 APPENDIKS...33 A1. DATABASEBEGREBER...34 Normalisering...34 Generalisering...35 Referenceintegritet...36 View 37 Trigger 38 BILAG...39 ii

5 1. INDLEDNING DANVAND er blevet udviklet med henblik på, at blive en national standard for registrering af ledningsanlæg. DANVAND er en databasemodel og udvekslingsformat, som beskriver en struktur for ledningsnettets fysiske data. DANVA, Dansk Vand- og Spildevandsforening, har det fulde ejerskab af modellen. DANVAND version 1.1 fra september 2009 er en videreudvikling af den første udgave, som blev frigivet i oktober Udviklingen foregår, i regi af DANVA, i henholdsvis en styregruppe og en teknikergruppe. Styregruppen har det overordnede ansvar for drift, vedligehold og udvikling af modellen. Teknikergruppen står for udviklingen, opbygning, ændringer og udbygning af modellen. Styregruppen bag DANVAND version 1.1 bestod af: Erling Nissen, Odense Vandselskab as (formand) Otto Leopold, TRE-FOR Vand A/S Eric Lauridsen, Esbjerg Kommune Anne Margrethe Hansen og Finn Asmussen, Københavns Energi A/S Kurt Brinkmann Kristensen, Århus Kommune, Vand og Spildevand Jackie Sandgård, Intergraph Danmark A/S Jens Holt, Informi Gis Jens Virring Sørensen, Orbicon A/S Allan Nielsen, Cowi Steen Madsen og Martin Brandi, NIRAS (Repræsentant-Udvikler) Lars Nørgaard, FVD/Ikast Vandværk (Repræsentant-FVD) Thomas Sørensen, DANVA Teknikergruppen bag DANVAND version 1.1 bestod af: Otto Leopold, TRE-FOR Vand A/S (formand) Steen Schjønning, KE Henrik Willemoes, Odense Vandselskab as Peter Svinkløv, Esbjerg Kommune Bent Guldager, Århus Vand og Spildevand Bruno Højrizi, Ålborg Kommune Vandforsyningen Simon V. Andersen, Intergraph Danmark A/S Jesper Damgaard-Iversen, Informi Gis Anders Hahn Kristensen, NIRAS 1

6 Peter Norvin, Orbicon A/S Jan Nielsen, Rambøll Danmark A/S Jacob Jørgensen, Alectia A/S Ricki Korsholm, Cowi A/S Ulrik Balslev, breakoutimage A/S Thomas Sørensen, DANVA NIRAS ved Kristian Verwold, har stået for den fysiske opbygning af DANVAND Version Afgrænsning Vandforsyningsområdet har historisk set anvendt flere forskellige systemer til registrering af sine ledningsdata. DANVAND er udviklet for at have en fælles, ensartet datamodel, som forenkler udveksling af data samt øger udbudet og valgfriheden af applikationer, der bygger på ledningsregistreringen. Der vil i fremtiden være forskelligartede behov for anvendelse af forskellige systemer til f.eks. beregninger, afregning, styring og økonomi. Det er derfor nødvendigt med en afgrænsning af modellen, så denne kan danne grundlag for arbejdet indenfor forsyningen. Datamodellen afgrænses således: Dette første tiltag til en national vanddatamodel afgrænses til de data, der beskriver det fysiske netværk (knuder, komponenter og ledninger). Endvidere skal datamodellen omfatte de datatyper, der er en tradition for at bruge hos ledningsejerne. Datamodellen skal, endvidere indeholde de datatyper, der er relevante for ledningsejerne at udveksle med eksterne parter. I version 1.1 er endvidere medtaget datafelter til brug for værdiansættelse, koblingsnøgle til SRO-data samt nem opstilling af beregningsmodeller. Ensartethed og udveksling af data er således ét af de vigtige formål med denne datamodel. Senere, når der er opnået yderligere erfaring med den fælles nationale vanddatamodel, kan modellen eventuelt udvides med andre områder fx. Beregningsresultater Analyseresultater Drift og vedligehold Dokumenthåndteringsdata Økonomisystemer Forbrugsafregningssystemer Personaleregistre Adressedata Matrikeldata Disse data kan dels vedrøre hele ledninger, eller de kan være stedfæstede på dele af ledninger, og således være hændelsesbaserede. 2

7 Ledningsejere, der allerede på et tidligt tidspunkt har større behov end det, den fælles nationale vanddatamodel tilbyder, kan udvide den til at omfatte deres særlige behov. Dog vil disse udvidelser ikke kunne udveksles med andre via standard udvekslingsformatet. Under udviklingen af datamodellen er der således taget hensyn til, at data, der vedrører komponenter og ledninger, kan vedligeholdes, også når der er tilknyttet data, der vedligeholdes af andre systemer, der ikke er egentlige ledningsregistreringssystemer. Der er derfor i DANVAND angivet en metode til at håndtere historiske data. Der behøver således ikke forekomme tab af eksterne data, når ledningsdata ændres eller slettes. DANVA leverer database scripts til Oracle og MS SQL Server og database filen til MS Access som eksempler. Ledningsejerne skal kunne udbygge datamodellen således, at den kan anvendes i et GIS-værktøj. Standard-datamodellen skal således ikke tilpasses særlige behov, der stilles i forskellige GIS-værktøjer. 1.2 Læsevejledning For at få en god forståelse for datamodellens opbygning anbefales det at læse appendiks A1 om databasebegreber. Her forklares de mest basale begreber omkring datamodeller, valideringer, m.v., og det kan måske afklare spørgsmål omkring datamodellens grundlæggende design. Rapporten er inddelt i afsnit, der beskriver datamodellen ud fra de problemområder, som vi mener, har særlig interesse. Der vil være felter i datamodellen, der ikke er beskrevet i afsnittene. Et mere fyldestgørende overblik over datamodellen fås i bilag 2 og 3, der indeholder databasediagrammer og beskrivelse af samtlige tabeller og felter. Endvidere er der i bilag 1 beskrevet den notation, der er anvendt til at beskrive datamodellen. 3

8 2. LEDNINGSNETVÆRK 2.1 Begreber Ledningsnetværket beskrives ved sammenhængen mellem knuder og ledninger. Til disse kan der knyttes komponenter. Disse er således centrale begreber i datamodellen, hvorfor de præciseres i det følgende Knuder og komponenter Knuderne beskriver sammen med ledningerne netværket. Endvidere kan der til knuderne knyttes én eller flere komponenter, med vandforsyningstekniske egenskaber. Der kan således ikke angives egentlige typer af knuder, men knuderne beskrives ved de komponenter, der er tilknyttet. Figur 2-1 Tabeller med knuder og komponenter. Her er kun vist tre komponenter. Indsættelse af en knude på en ledning vil typisk medføre opdeling af ledningen i to nye ledninger. Der vil dog være tilfælde, hvor det ikke vil være hensigtsmæssigt at opdele ledningen. Dette afhænger af hvilken komponent, der er knyttet til knuden. 4

9 2.1.2 Knude og komponenter - relationsbeskrivelse. Nedenstående figur viser relationer mellem knuder og komponenter og skal betragtes som vejledning. Hvilke komponenter kan placeres på sammen knude læses i skemaet f.eks. således Ventil skal selvfølgelig indeholde en knude og en ventil samt kan indeholde en enkelt samling, Målerenhed, tapsted og bygværkskomponent Ledninger En ledning forbinder to knuder. Til en ledning kan der knyttes dels vandforsyningstekniske egenskaber og dels administrative egenskaber. Som det er tilfældet i DANDAS, identificeres en ledning ved de to knuder Knude1ID og Knude2ID. Da det må forventes, at der oprettes flere ledninger mellem de to knuder f.eks. historiske ledninger, skal der også anvendes felt til et løbenummer (se Figur 2-2). 2.2 Regler i ledningsnettet Det er hensigtsmæssigt, at definere regler for sammenhæng mellem komponenter og ledninger. Det er ikke altid hensigtsmæssigt at designe datamodellen således, at det er fysisk umuligt at bryde regler, der vedrører det vandforsyningstekniske. Det skal være muligt at validere data ved hjælp af forespørgsler i databasen. Databaseregler bør dog ikke brydes. Visse regler kan ikke brydes, hvis referenceintegritet er implementeret i databasen. 5

10 Indsættelse af en knude på en ledning vil ikke nødvendigvis medføre, at ledningen skal deles. Hvis der ikke er forskel på ledningsmateriale/-dimension på hver side af komponenten, og hvis der ikke sker væsentlige indgreb i netværket, er der ofte ingen mening i at dele ledningen op i mindre dele. Der er komponenttyper, der har en så væsentlig virkning på netværkets egenskaber, at ledningen skal deles ved indsættelse af en knude, der indeholder disse komponenttyper. Regler, der vedrører det vandforsyningstekniske, er defineret for hver type komponent. Reglerne omhandler om ledningen skal være opdelt, der hvor komponenten er indsat, og antallet af ledninger, der må tilsluttes komponenten. Komponenttyperne er defineret i kodetabeller, hvor også de ovenstående regler er defineret. I de tilfælde hvor ledningen ikke deles, skal knuden placeres på ledningen, og den knyttes til ledningen ved hjælp af feltet LedningID i tabellen Knude_Van. Figur 2-2 Tabeller for knuder, komponenter og ledninger. Der vises kun tabeller for visse komponenter. 2.3 Rørkatalog og komponentkataloger Formålet med kataloger til rør og komponenter er bl.a., at forhindre ulovlige kombinationer af f.eks. dimensioner og materialer, og i øvrigt give brugerne et overblik over gyldige rør og komponenttyper. Rørs egenskaber registreres således udelukkende i et rørkatalog, der er defineret i tabellen Roerkatalog_Van. I kataloget angives rørtyper ved kombination af dimension, trykklasse, materiale, fabrikant og fabrikantbetegnelse. Denne kombination er unik i tabellen, og kan anvendes som søgenøgle i kataloget. Er posterne i kataloget angivet med et varenummer, kan varenummer anvendes til søgning. Varenummer er unikt og skal anvendes ved udveksling af data. 6

11 Figur 2-3 Tabeller til rørkatalog. Hver komponenttype har ligeledes tilknyttet et katalog. Dette gælder dog ikke de mere uspecificerede komponenter som f.eks. boringer og reservoir. For at sikre at katalogerne opfylder deres formål, er det meget vigtigt at felterne, der udgør kandidatnøglen i katalogerne, er unikt indekserede. Dette kræver, at felterne er obligatoriske. Dette sikrer, at hvert rør og hver komponenttype kun kan registreres én gang. Det skal alligevel være muligt, at oprette poster i katalogerne, der ikke har fået defineret værdier i de pågældende felter. F.eks. skal et rør med ukendt dimension have værdien 0 i feltet NominelDim. Tilsvarende er tekst-felter oprettet med fast længde, hvor tomme pladser udfyldes med blanktegn. Dette sikrer, at tekstfelter altid kan indgå i et unikt indeks. 2.4 Ventiler Kombikryds og kombitee er eksempler på komponenter, der kan indeholde flere ventiler. Det er ønskeligt, at hver ventil knyttes til en ledning. Til dette kan der anvendes to metoder. 1. Ét kryds eller tee samt alle ventiler knyttes til én og samme knude. På hver ventil angives den ledning, der er sluttet til ventilen 2. Kryds eller tee samt alle ventiler registreres i hver sin knude. Se Figur

12 Knude med ventil Knude med tee Ledning Figur 2-4 Registrering af kombitee med fire knuder (metode 2). Metode 1 er den mest enkle metode i forbindelse med registrering af komponenter og ledninger. Derimod kan det, med standardværktøjer i et GIS-system, være vanskeligere at foretage analyser (traceing). Metode 2 kræver mere arbejde i registreringen, men det er mere sandsynligt, at analyser kan foretages med standardværktøjer i et GIS-system. 2.5 Punkter på ledninger Ledninger kan registreres med et antal punkter, således at ledningens horisontale og vertikale forløb kan beskrives. Punkternes koordinater kan hvis det ønskes registreres i en punkttabel. Hvis et GIS-system anvendes, kan man alternativt blot registrere punkterne i de grafiske objekter. Punkterne skal dog udveksles i den form, der svarer til punkttabellen. 2.6 Bygværker Knuder, der i marken betegnes som et bygværk, skal ikke nødvendigvis registreres på en særlig måde i databasen. Hvis bygværket skal beskrives med flere knuder, eller hvis bygværket har en vis udstrækning, kan bygværket registreres med en polygon og én eller flere knuder kan knyttes til denne. Knuderne i bygværket skal kunne forbindes, for at kunne beskrive netværket. Til dette er der defineret feltet Fiktivledning, der anvendes hvis knuderne ikke er forbundet med en egentlig ledning. Knude Ledning Fiktivledning [J] Figur 2-5 Skitsering af bygværk. 8

13 Figur 2-6 Tabeller til bygværker. 9

14 3. HISTORISKE DATA Ændringer i ledningsnettet kan bedst dokumenteres ved at bevare historiske data. Historiske data håndteres på knuder, komponenter, ledninger og bygværker. Formålet med at bevare de historiske data er f.eks.: At bevare muligheden for eksterne systemer, at relatere til knuder og ledninger, der er fjernet eller erstattet af andre knuder og ledninger. At bevare grundlaget for statistisk behandling af bl.a. lækager. Der er forskellige former for historik: 1. Historisk status f.eks. i brug, planlagt, anlagt, ikke i brug, sløjfet m.v. 2. Historik på de enkelte objekter bl.a. af hensyn til referenceintegritet i databasen. 3. Historik på attributniveau, der svarer til versionering af de enkelte databaseposter. De to første former for historik håndteres i DANVAND. Den tredje form for historik er mere avanceret, da man stadig skal tage hensyn til referenceintegriteten. Visse databasesystemer har indbygget værktøjer, der håndterer denne form for historik. Ved håndtering af historik bevarer man de oprindelige databaseposter, efter en knude eller ledning er fjernet eller udskiftet. Dette er nødvendigt, da referenceintegritet i databasen skal overholdes og tilknyttede data skal bevares (se appendiks, Databegreber). De oprindelige databaseposter bliver markeret som værende historiske, og deres data skal ikke vedligeholdes fremover. Der er således ikke tale om redundante data. I tabellerne Knude_Van, Ledning_Van, Bygvaerk_Van, Pejleboring_Van og i komponenttabellerne findes felterne DatoEtableret, der angiver hvornår objektet er etableret/anlagt.feltet kan anvendes til analyse af aldersfordelingen. DatoHistorisk, der angiver hvornår objektet er blevet historisk. Hvis feltet er tomt (null), er objektet ikke historisk. StatusKode, der angiver om ledning er i brug, ikke i brug, sløjfet m.v. DatoStatus, der angiver hvornår den status, der er registreret i StatusKode, er trådt i kraft. Ovenstående felter kan anvendes til historiske analyser. 10

15 I tabellerne findes endvidere felterne DatoOprettet og DatoOpdateret, der angiver tidspunktet for datapostens oprettelse og sidste opdatering. Datoer i disse felter vil sjældent være sammenfaldende med ovenstående felter. F.eks. vil man ofte angive en historisk dato, der ligger måneder tilbage i forhold til den aktuelle oprettelsesdato eller opdateringsdato for dataposten. Felterne bør derfor ikke umiddelbart anvendes i forbindelse med analyser af historiske data. Endvidere findes der i tabellen Ledning_Van følgende felter, der angiver forbindelsen mellem de historiske ledninger og de nye ledninger: ErstatID, der angiver den oprindelige ledning, der er erstattet af den aktuelle ledning. SamletID, der angiver den nye ledning, der er en samling af bl.a. den aktuelle ledning. De to felter skal give mulighed for sporbarhed, når ledninger bliver erstattet af nye ledninger. I det følgende beskrives hvordan historiske data kan håndteres. 3.1 Nedlæggelse af ledning A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: 10 B Tidspunkt 1 A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: Sløjfet DatoStatus: Tid2 DatoHistorisk: 10 B Tidspunkt 2 Tidspunkt 2 Figur 3-1 Nedlæggelse af en ledning. Den mest simple situation er når en ledning mellem to knuder nedlægges. Her skal StatusKode angives til f.eks. sløjfet, og feltet DatoStatus skal udfyldes med datoen for nedlæggelsen. 11

16 3.2 Udskiftning af ledning mellem to knuder A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: 10 ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: Sløjfet DatoStatus: Tid2 DatoHistorisk: 10 B Tidspunkt 1 Tidspunkt 2 A ErstatID: 10 SamletID: DatoEtableret: Tid2 StatusKode: I brug DatoStatus: Tid2 DatoHistorisk: 101 B Tidspunkt 2 Figur 3-2 Udskiftning af en ledning. Den oprindelige ledning angives som sløjfet, og der oprettes en ny ledning mellem de to knuder. Den nye ledning nr. 101 får i feltet ErstatID en reference til den oprindelige ledning nr Deling af en ledning A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: 10 B Tidspunkt 1 ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: Tid2 10 Tidspunkt 2 A ErstatID: 10 ErstatID: 10 SamletID: SamletID: DatoEtableret: Tid1 DatoEtableret: Tid1 StatusKode: I brug StatusKode: I brug DatoStatus: Tid1 C DatoStatus: Tid1 DatoHistorisk: DatoHistorisk: B Tidspunkt 2 Figur 3-3 Deling af en ledning. 12

17 Deling af en ledning forekommer, hvis der indsættes en knude/komponent et sted på ledningen (Figur 3-3). Den oprindelige ledning nr. 10 bevares og gøres historisk, og der oprettes to nye ledninger nr. 101 og 102. De nye ledninger får i feltet ErstatID en reference til den oprindelige ledning nr. 10. Endvidere får de en etableringsdato, der svarer til den oprindelige ledning. 3.4 Udskiftning af en del af en ledning A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: 10 ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: Tid2 10 B Tidspunkt 1 Tidspunkt 2 A ErstatID: 10 ErstatID: 10 ErstatID: 10 SamletID: SamletID: SamletID: DatoEtableret: Tid1 DatoEtableret: Tid1 DatoEtableret: Tid1 StatusKode: I brug StatusKode: Sløjfet StatusKode: I brug DatoStatus: Tid1 C DatoStatus: Tid2 DatoStatus: Tid1 D DatoHistorisk: DatoHistorisk: DatoHistorisk: ErstatID: 102 SamletID: DatoEtableret: Tid2 StatusKode: I brug DatoStatus: Tid2 DatoHistorisk: 104 B Tidspunkt 2 Figur 3-4 Udskiftning af en del af en ledning. Udskiftning af en del af en ledning forekommer f.eks. i forbindelse med en reparation. På ledningen indsættes to nye knuder C og D. Den oprindelige ledning nr. 10 gøres historisk. Der oprettes fire nye ledninger, og det udskiftede stykke er ledning nr. 102, og det er angivet som f.eks. sløjfet. Det nye stykke er ledning nr Ledningerne 101,102 og 103 får overført egenskaberne fra den oprindelige ledning nr herunder etableringsdatoen. Ledningerne nr. 101, 102, 103 får i feltet ErstatID en reference til den oprindelige ledning 10 og ledning 104 får 102 som ErstatID. Ovenstående handling kan sjældent udføres med standardværktøjerne i et GIS-system, ved blot at indsætte de to nye knuder. Det nye ledningsstykke skal indsættes ved en samlet operation. Det anvendte værktøj skal sørge for, at det kun er ledning nr. 102, der gemmes som værende sløjfet og ikke ledning nr. 101 eller 103. Endvidere skal værktøjet sørge for, at 3 af de nye ledninger peger på den oprindelige ledning nr. 10 og den sidste på ledning nr

18 3.5 Sammenlægning af ledninger A ErstatID: ErstatID: SamletID: SamletID: DatoEtableret: Tid1 DatoEtableret: Tid1 StatusKode: I brug StatusKode: I brug DatoStatus: Tid1 B DatoStatus: Tid1 DatoHistorisk: DatoHistorisk: ErstatID: ErstatID: SamletID: 101 SamletID: 101 DatoEtableret: Tid1 DatoEtableret: Tid1 StatusKode: I brug StatusKode: I brug DatoStatus: Tid1 DatoStatus: Tid1 DatoHistorisk: Tid2 DatoHistorisk: Tid C Tidspunkt 1 Tidspunkt 2 A ErstatID: SamletID: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoHistorisk: 101 C Tidspunkt 2 Figur 3-5 Sammenlægning af to ledninger. Sammenlægning af ledninger vil typisk forekomme, hvis der fjernes en knude, der er fejlregistreret. Knuden B fjernes og de oprindelige ledninger nr. 10 og 11 gøres historiske. Begge de oprindelige ledninger får i feltet SamletID en reference til den nye ledning nr Den nye ledning får en etableringsdato, der kan svare til etableringsdatoen fra én af de oprindelige ledninger. 3.6 Udskiftning af en knude D B A C Figur 3-6 Udskiftning af knude Da knuder identificerer ledninger, vil ledningerne naturligvis blive påvirket, når en knude gøres historisk og erstattes med en ny. Når knude A udskiftes med en ny knude, skal de ikke-historiske ledninger nr. 11 og 12 opdateres, således at felterne Knude1ID og Knude2ID indeholder nøglen til den nye knude. Den historiske ledning ad skal dog ikke opdateres. Denne kan fortsat pege på den nu historiske knude. 14

19 4. OPRINDELSE Figur 4-1 Oprindelsesoplysninger på knuder og ledninger. Oprindelsesoplysninger kan registreres på knuder og ledninger. For koordinater og koter kan der angives koder for følgende: Skønnet Projekt Digitaliseret fra kort Fotogrammetri Landmåling Andet Til oprindelsesoplysninger angives typen af opmålingsinstrumentet og nøjagtigheden ved hjælp af nøjagtighedsklassen som er inddelt i <= 0,05 m 0,05 0,10 m 0,10 0,25 m 0,25 0,50 m 0, m > 1,00 m I tabellen Oprindelse kan der registreres Måledato Dato for levering af data Journalnummer Skitsenummer Åbengrav (J/N) Opmålingsinstrument type Nøjagtigheden 15

20 Firma der har foretaget opmålingen Måledato Opmåler initialer Et dokument Oprindelseskode for koordinater og koter Middelfejl på koordinater og koter Bemærkning 16

21 5. ZONER Zonemodellen er ændret i DANVAND Version 1.1 og understøtter nu hierarkisk opbygning. Via zone kategori i tabellen ZoneKategori_Van defineres, om zonen tillader hierarkisk opbygning og maksimale antal niveauer. Zoner defineres i Zoner_Van tabellen. Tillader zonen et hierarki, henviser den underordnede zone til deres overordnede zone i Zoner_Van tabellen og bestemmer niveau af zonen. I ZoneType_Van defineres typenavne til zonerne og deres hierarkiske struktur pr. kategori og niveau. I tabellen LedningZone_Van tilføjes de ledninger, som tilhører en eller flere zoner. Tabelstrukturen forhindrer, at en ledning kan tilføjes den samme zone kategori i forskellige niveauer igen. Figur 5-1 Tabeller til zonemodellen PK Ledning_Van ID FK1,U1 Knude1ID FK2,U1 Knude2ID U1 Loebenr Kaldenavn FK4,I1 KategoriKode FK8 TrykTypeKode ForbrugPaaLedn FK10,I2 RoerkatalogID KalibreretDim KalibreretRuhed KalibEnkelttab FK6 LaegningsmetKode FK3 EjerforholdKode FiktivLedning Netberegning FK5,I5 StatusKode DatoStatus KanSlettes FK7,I3 SamletID FK9,I4 ErstatID DatoEtableret Sagsnummer Anskaffelsespris DatoHistorisk FK11 OprindXYID FK12 OprindKoteID DatoOprettet DatoOpdateret Initialer Bemaerkning PK ZoneType_Van PK ID FK1 U1 U1 LedningZone_Van ID FK2,U1 LedningID FK1 ZoneID FK1,U1 ZonekategoriID ZoneKategoriID Niveau Navn Sortering Aktiv Zoner_Van PK ID PK,FK2 ZoneKategoriID U1 FK3 FK3 FK1 Navn ParZoneID ParZoneKategoriID Niveau TrykKote StatusKode DatoStatus DatoOprettet DatoOpdateret Initialer Bemærkning ZoneKategori_Van PK ID U1 Navn AntalNiveauer Sortering Aktiv 17

22 6. VÆRDIANSÆTTELSE Baggrunden for håndtering af værdiansættelse i DANVAND er Indenrigsministeriets betænkning nr af 3. marts 1999 om Det fremtidige budget- og regnskabssystem for kommuner og amtskommuner. Med DANVAND er der rige muligheder for at etablere et datagrundlag, der kan anvendes ved værdiansættelsen. Man vil ofte anvende forskellige strategier for værdiansættelsen, der er afhængig af de data, der er registreret på de enkelte objekter. Værdiansættelsen kan således enten foretages på baggrund af objekternes egenskaber eller ud fra den faktiske anlægspris. Data, der direkte vedrører værdiansættelsen, knyttes til ledninger og knuder. Da det er muligt at gemme historiske data og data vedr. saneringer for ledninger og knuder, er det også muligt at håndtere renoveringer m.v., der forlænger levetiden. I DANVAND registreres kun de faktiske anlægsudgifter. En anlægsudgift vil typisk vedrøre en samling af bygværker, ledninger m.v. i forbindelse med et projekt. På længere sigt vil det være vanskeligt at håndtere udgifter for et helt projekt, da der løbende vil ske ændringer og saneringer af anlæg. Den registrerede anlægsudgift for et projekt vil således ikke længere være gældende. Anlægsudgifterne skal derfor fordeles til de enkelte komponenter. Genanskaffelsesværdier, afskrivningssaldi m.v. registreres ikke i DANVAND, da de typisk vil blive beregnet i forbindelse med forespørgsler i databasen. Endvidere er de afhængige af indekstal, årstal og andre parametre, der ændrer sig med tiden. På ledninger og knuder registreres Etableringsdato Sagsnummer Anskaffelsespris 18

23 PK ID Knude_Van PK KnudeVaerdi_Van ID U1 Knudenavn XKoord YKoord Kote FK1 OprindXYID FK2 OprindKoteID FK3 StatusKode DatoStatus FK4 EjerforholdKode KanSlettes FK6 FK5 LedningID BygvaerkID DatoEtableret Sagsnummer Anskaffelsespris DatoHistorisk DatoOprettet DatoOpdateret Initialer Bemaerkning FK1,U1 KnudeID U1 Gruppenavn SidsteAnvendDato Pris DatoEtableret Sagsnummer Initialer DatoOprettet DatoOpdateret Figur 6-1 Tabeller til værdiansættelse af knuder - herunder bygværker. Knuder kan enten være almindelige komponenter, hvor anskaffelsespris registreres direkte på tabellen, eller det kan være bygværker med flere funktioner, hvor der er behov for specificere værdier for flere grupper af installationer f.eks. SRO-anlæg. Derfor kan data vedr. værdiansættelsen registreres i tabellen KnudeVaerdi_Van (se Figur 6-1). Her registreres Gruppenavn Etableringsdato Sagsnummer Pris på anlægstidspunktet Sidste anvendelsesdato (til bestemmelse af restlevetiden) 19

24 7. KODETABELLER Visse felter i DANVAND skal have tildelt værdier i form af koder. Koderne er defineret i kodetabeller. Fordelen ved at oprette en kodetabel for hver sæt koder er, at det er den mest enkle måde at validere de inddaterede koder i databasen. Der er oprettet en relation fra de felter, der er knyttet til en kodetabel. Dette sikrer, at der ikke kan indtastes værdier, uden at de er defineret i en kodetabel. Kodetabellerne har som minimum følgende felter: Kode. Beskrivelse af kode. Indholdet i kodetabellerne er en del af DANVAND standarden. Der kan oprettes nye koder, men disse bør ikke eksporteres via udvekslingsformatet.!!! OBS!!! Koder i kodetabeller må ikke ændre betydning! Udgåede koder må således ikke genbruges. Der kan opstå alvorlige problemer, hvis applikationer og brugernes scripts analyserer på koder, der har ændret betydning. 20

25 8. REFERENCESYSTEMER De anvendte referencesystemer er vigtige at kende i forbindelse med udveksling af data mellem forskellige interessenter. Disse registreres i tabellen ReferenceSys_Van. Tabellen indeholder felter til Koordinatsystem Højdesystem Enhed på retninger og vinkler Der kan angives følgende koordinatsystemer: S34j System 34 Jylland S34s System 34 Sjælland S45b System 45 Bornholm KP2000j Kortprojektion 2000 Jylland KP2000s Kortprojektion 2000 Sjælland KP2000b Kortprojektion 2000 Bornholm UTM32/ED50 UTM, zone 32, European 1950 UTM33/ED50 UTM, zone 33, European 1950 UTM32/EUREF89 UTM, zone 32, EUREF89 UTM33/EUREF89 UTM, zone 33, EUREF89 Kort- & Matrikelstyrelsen (KMS) anbefaler, at brugere, der omlægger data, anvender UTM/EUREF89 som den primære kortprojektion - og Kp2000 som den sekundære. Det skal forstås sådan, at kun UTM/EUREF89 anvendes til lagrings-, bearbejdnings- og udvekslingsformål Kp2000 anvendes temporært internt i de organisationer, hvor der er behov for at skifte fra skærm til markarbejde. UTM/EUREF89 er i EU-regi anbefalet som standardkortprojektion til brug ved lagring og udveksling af data. Anbefalinger vedr. anvendelse af kortprojektioner henvises til KMS s web site på 21

26 Der kan angives følgende højdesystemer: DNNGM91 Dansk Normal Nul i Jylland DNNGI44 Dansk Normal Nul på Fyn, Sjælland og Lolland-Falster MSL Højdesystem for øer uden forbindelse til DNN KN Københavns Nul DVR90 Dansk Vertikal Reference DVR90 er en del af det nye System Med introduktionen af referencesystemet System 2000, der skal erstatte System 34/45, Dansk Normal Nul (DNN) m.v., er det særlig vigtigt, at være opmærksom på hvilket referencesystem der anvendes. Af hensyn til standardsoftware er det mest hensigtsmæssigt, at koordinater og koter ikke gemmes i flere forskellige systemer. DANVAND understøtter ikke en blanding af referencesystemer, hvorfor alle data skal angives i ét og samme system. Der er således kun én record i tabellen Reference- Sys_Van. 22

27 9. GEOGRAFISKE INFORMATIONSSYSTEMER Standard GIS-systemerne vil ikke umiddelbart kunne anvende de alfanumeriske felter med koordinater i DANVAND. Disse er tænkt anvendt, dels af brugere af alfanumeriske systemer og dels i forbindelse med udveksling af data mellem de forskellige systemer. Inden for et par år kan det overvejes at udbygge udvekslingsformatet til DAN- VAND, således at det opfylder OpenGIS-standarden. For GIS-systemerne skal der oprettes felter, der indeholder grafik eller nøgler til grafik. Følgende tabeller vil være relevante at udbygge: Objekt Knude_Van Ledning_Van Bygvaerk_Van Type Punkt Polyline Flade Felttypen til grafikken vil være helt afhængig af hvilket GIS-system, der anvendes, hvorfor tilpasningen typisk vil blive foretaget af softwareleverandøren. 23

28 10. UDVEKSLINGSFORMAT XML XML er anvendt som en fælles offentlig standard for udveksling af data. Endvidere er XML en international standard, og den kan læses og forstås uanset hvilken teknologi, man bruger. XML har den fordel at den understøttes af markedet. Udvalget om Digital Forvaltning anbefalede i deres rapport "Digital forvaltning" fra maj 2001 XML som fælles offentlig standard for datakommunikation. XML anvendes således i både den offentlige og private sektor til udveksling af data. Der er således defineret XMLschemas for data og datatyper fra f.eks. BBR, ESR m.v. Også for afløbssystemer (DANDAS) anvendes XML-formatet til udveksling af data. XML er et HTML-lignende sprog, der kan anvendes til web sites på internettet. XML er udvidet med et regelsæt, der omtales som et schema. Et XML Schema er et værktøj til at beskrive en datastruktur eller dataformat. Data, der er gemt som XML-data, kan således valideres i forhold til et XML Schema. Der findes standardsoftware, der kan udføre denne validering. XML er således et godt værktøj til udveksling af data. Følgende er en overordnet beskrivelse af strukturen i XML schemas, og er ikke en beskrivelse af XML sproget. Strukturen i schemas til DANVAND er illustreret i bilag 4. Til hvert schema er der knyttet et UML klassediagram, der beskriver strukturen i schemaet. Eksemplerne nedenfor skal udelukkende illustrere de overordnede principper i opbygningen af XML-data. Navne på elementer og datatyper svarer således ikke nødvendigvis til dem, der anvendes i de egentlige XML-schemas. Figur 10-1 Forenklet eksempel på strukturen i et XML-schema. 24

29 Datastrukturen i XML er primært hierarkisk. De enkelte elementer i et XML-dokument er dermed indlejrede (nestede) i forhold til hinanden. F.eks. kan en ledning have indlejret én eller flere punkter. Dette sikrer, at punkter ikke kan udveksles uden den ledning, de tilhører. Tilsvarende kan komponenter ikke udveksles uden angivelse af den knude, de tilhører. Ethvert XML-schema skal have defineret et rodelement, der er øverst i hierarkiet. Roden er ofte et element, der fungerer som en gruppe. I et XML Schema for ledninger, er rodelementet en gruppe med et antal ledninger. Dette er illustreret med UMLdiagrammet i Figur Et eksempel på XML-schema og XML-data er illustreret i henholdsvis Figur 10-2 og Figur 10-3.OBS alle figurer skal henvise /2009/9/1 <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace=" xmlns:van=" xmlns=" elementformdefault="qualified"> <include schemalocation="van_stringtype.xsd" /> <element name="ledninggroup"> <complextype> <sequence> <element name="referencesys" type="van:referencesystype" /> <element name="ledning" type="van:ledningtype" maxoccurs="unbounded" /> </sequence> </complextype> </element> <!-- Type-definitioner --> <complextype name="ledningtype"> <all> <element name="punktitems"> <complextype> <sequence> <element name="punkt" type="van:punkttype" minoccurs="0" maxoccurs="unbounded" /> </sequence> </complextype> </element> <element name="knudepaaledningitems"> <complextype> <sequence> <element name="knudenavn" type="van:knudenavntype" minoccurs="0" maxoccurs="unbounded" /> </sequence> </complextype> </element> </all> <attribute name="knude1" type="van:knudenavntype" use="required" /> <attribute name="knude2" type="van:knudenavntype" use="required" /> <attribute name="loebenr" type="short" use="required" /> </complextype> <complextype name="punkttype"> <all> <element name="xkoordinat" type="decimal" minoccurs="0" /> <element name="ykoordinat" type="decimal" minoccurs="0" /> <element name="kote" type="decimal" minoccurs="0" /> <element name="datooprettet" type="datetime" minoccurs="0" /> <element name="datoopdateret" type="datetime" minoccurs="0" /> <element name="initialer" type="van:string10type" minoccurs="0" /> </all> <attribute name="sortering" type="short" use="required" /> </complextype> </schema> Figur 10-2 Forenklet XML schema for ledninger. 25

30 <?xml version="1.0"?> <LedningGroup xmlns=" xmlns:xsi=" xsi:schemalocation=" file:///c:/van_ledning.xsd"> <Referencesys> <KoordinatsysKode>10</KoordinatsysKode> <KotesysKode>5</KotesysKode> <!--Element Initialer is optional--> <Initialer>string</Initialer> <!--Element DatoOprettet is optional--> <DatoOprettet> T12:00:00-05:00</DatoOprettet> <!--Element DatoOpdateret is optional--> <DatoOpdateret> T12:00:00-05:00</DatoOpdateret> </Referencesys> <!--Element Ledning, maxoccurs=unbounded--> <Ledning Knude1="Knude1" Knude2="Knude2" Loebenr="1234"> <PunktItems> <!--Element Punkt is optional, maxoccurs=unbounded--> <Punkt Sortering="1"> <!--Element XKoordinat is optional--> <XKoordinat>1.23</XKoordinat> <!--Element YKoordinat is optional--> <YKoordinat>1.23</YKoordinat> <!--Element Kote is optional--> <Kote>1.23</Kote> <!--Element DatoOprettet is optional--> <DatoOprettet> T12:00:00-05:00</DatoOprettet> <!--Element DatoOpdateret is optional--> <DatoOpdateret> T12:00:00-05:00</DatoOpdateret> <!--Element Initialer is optional--> <Initialer>string</Initialer> </Punkt> <Punkt Sortering="2"> <!--Element XKoordinat is optional--> <XKoordinat>1.23</XKoordinat> <!--Element YKoordinat is optional--> <YKoordinat>1.23</YKoordinat> <!--Element Kote is optional--> <Kote>1.23</Kote> <!--Element DatoOprettet is optional--> <DatoOprettet> T12:00:00-05:00</DatoOprettet> <!--Element DatoOpdateret is optional--> <DatoOpdateret> T12:00:00-05:00</DatoOpdateret> <!--Element Initialer is optional--> <Initialer>string</Initialer> </Punkt> </PunktItems> </Ledning> </LedningGroup> Figur 10-3 Forenklet eksempel på XML-data til ledning, hvor ledning har tilknyttet punkter Netværksstruktur Ved mange-til-én-relationer anvendes en netværksstruktur med en key/keyref konstruktion. Princippet er illustreret i Figur 10-4, hvor en mange-til-én relation mellem Ledning og Oprindelse er illustreret. I klassen Oprindelse er attributten Journalnr nøglen. I klassen Ledning findes tilsvarende XYOprind. Et eksempel på XML-schema og XMLdata er illustreret i henholdsvis Figur 10-5 og Figur

31 Figur 10-4 Eksempel på mange-til-én relation. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace=" xmlns:van=" xmlns=" elementformdefault="qualified"> <element name="ledninggroup"> <complextype> <sequence> <element name="ledning" type="van:ledningtype" maxoccurs="unbounded" /> <element name="oprindelsegroup" type="van:oprindelsegrouptype" /> </sequence> </complextype> <!-- key and keyref definitioner --> <!-- Oprindelse skal have et unikt Journalnr --> <key name="oprindelsekey"> <selector xpath="van:oprindelsegroup/van:oprindelse" /> <field /> </key> <!-- hvis Ledning/OprindXY element er angivet, skal dets værdi referere til et --> <keyref name="ledningxytiloprindelse" refer="van:oprindelsekey"> <selector xpath="van:ledning" /> <field xpath="van:oprindxy" /> </keyref> <!-- hvis Ledning/OprindKote element er angivet, skal dets værdi referere til et --> <keyref name="ledningkotetiloprindelse" refer="van:oprindelsekey"> <selector xpath="van:ledning" /> <field xpath="van:oprindkote" /> </keyref> </element> <!-- Type-definitioner --> <complextype name="ledningtype"> <all> <element name="oprindxy" type="van:journalnrtype" minoccurs="0" /> </all> <attribute name="knude1" type="van:knudenavntype" use="required" /> <attribute name="knude2" type="van:knudenavntype" use="required" /> <attribute name="loebenr" type="short" use="required" /> </complextype> <complextype name="oprindelsegrouptype"> <sequence> <element name="oprindelse" type="van:oprindelsetype" minoccurs="0" maxoccurs="unbounded" /> </sequence> </complextype> </schema> Figur 10-5 Forenklet eksempel på schema med mange-til-én relation. 27

32 <?xml version="1.0"?> <LedningGroup xmlns=" xmlns:xsi=" xsi:schemalocation=" file:///c:/van_ledning.xsd"> <!--Element Ledning, maxoccurs=unbounded--> <Ledning Knude1="string" Knude2="string" Loebenr="-32768"> <!--Element OprindXY is optional--> <OprindXY>Journal1</OprindXY> <!--Element Varenummer is optional--> </Ledning> <OprindelseGroup> <!--Element Oprindelse is optional, maxoccurs=unbounded--> <Oprindelse Journalnr="Journal1"> <!--Element Skitsenr is optional--> <Skitsenr>12345</Skitsenr> <!--Element OprindKoordKode is optional--> <OprindKoordKode>50</OprindKoordKode> <!--Element MiddelfejlKoord is optional--> <MiddelfejlKoord>-32768</MiddelfejlKoord> <!--Element MiddelfejlKoter is optional--> <MiddelfejlKoter>-32768</MiddelfejlKoter> <!--Element Maaledato is optional--> <Maaledato> T12:00:00-05:00</Maaledato> </Oprindelse> </OprindelseGroup> </LedningGroup> Figur 10-6 Forenklet eksempel på XML-data med mange-til-én-relation. Begge ledninger peger på samme journalnr. for oprindelsesoplysninger Navngivning af namespaces Namespace skal have en global unik identifikation. Derfor bliver et namespace normalt navngivet med en URL, der er som en adresse på internettet, og den vil altid være unik. Det er ikke en betingelse, at adressen eksisterer på internettet. Versionerne af XML-schemas skal kunne håndteres i namespace. Navnet på namespace navngives efter følgende struktur: Et namespace kan f.eks. navngives således: 1.0) eller (version 1.1) 10.3 Definerede XML-schemas Der defineres XML-schemas til udveksling af Knuder (VAN_Knude.xsd) Ledninger (VAN_Ledning.xsd) Komponenter (VAN_Komponent.xsd) Zoner (VAN_Zoner.xsd) 28

33 Der er datatyper, der anvendes på tværs af flere schemas. Disse er defineret i schemas, der inkluderes i de ovenstående schemas. Det er såkaldte type-schemas, og der kan ikke dannes objekter alene på grundlag af disse. Type schemas er VAN_CodeType.xsd VAN_FirmaType.xsd VAN_KeyType.xsd (første gang) VAN_LedningKeyType.xsd VAN_MaterialeType.xsd VAN_NativeType.xsd VAN_NoteType.xsd VAN_OprindelseType.xsd VAN_ReferencesysType.xsd VAN_RoerkatalogType.xsd VAN_StringType.xsd VAN_KeyType.xsd (dette er anden gang??) VAN_LedningZone.xsd (mangler der Type??) VAN_ZoneKategoriType.xsd VAN_ZoneTypeType.xsd VAN_CodeType.xsd er datatyper, der er dannet på grundlag af kodetabellerne. Disse datatyper sikrer, at XML-data kun er valide, når der anvendes koder, der er defineret i DANVAND. Det er muligt at udveksle andre koder, der ikke omfattet af DANVAND, men dette må normalt frarådes, da der er risiko for uorden i kodestrukturen i databasen. VAN_KeyType.xsd indeholder centrale datatyper, der kan anvendes som nøgler. VAN_StringType.xsd er blot datatyper, der begrænser længden af tekststrenge Rækkefølge for indsættelse af data fra XML-filer Rækkefølgen for indsættelse af data i en database fra en XML-fil kan beskrives således: 1. Indsæt data, der er struktureret i en netværksstruktur. 2. Indsæt data, der er struktureret i en hierarkisk struktur. Hierarkiet bestemmer rækkefølgen for indsættelsen. For hvert objekt f.eks. ledning startes med data, der ligger øverst i hierarkiet. Data, der indgår i den hierarkiske datastruktur, kan have en reference til data i en netværks datastruktur. Dette er illustreret i Figur Fra Ledning til oprindelse er der en mange-til-en-relation. Der er således flere ledninger, der kan pege på den samme oprindelse. For at sikre, at referenceintegriteten overholdes, skal oprindelses-data indlæses før ledningsdata. I eksemplet indsættes data i følgende rækkefølge: 1. Oprindelse 2. Ledning 29

34 3. Punkter Figur 10-7 Data, der er struktureret efter en hierarkisk og netværks datastruktur. Også XML-filerne skal indlæses i en bestemt rækkefølge. XML-filer, der indeholder data for knuder og ledninger, skal indlæses således: 1. Indlæs XML-filer, der er bygget over schema-filen VAN_Knude.xsd. 2. Indlæs XML-filer, der er bygget over schema-filen VAN_Ledning.xsd. 3. Indlæs XML-filer, der er bygget over schema-filen VAN_Komponent.xsd. 4. Indlæs XML-filer, der er bygget over schema-filen VAN_Zone.xsd. 30

35 11. REGLER FOR DESIGN AF DATAMODELLEN 11.1 Normalisering Normaliseringer i databasen foretages således, at de som regel opfylder tredje normalform. Der kan i mange tilfælde, for at spare plads i databasen, foretages yderligere normaliseringer. Det vurderes, at dette vil stille større krav til de applikationer, der skal udvikles til at håndtere DANVAND, og det vil ofte nedsætte databasens ydeevne, hvilket begrænser fordelene ved yderligere normaliseringer. Som teknologien er i dag, er datamængden i et vandforsyningssystem et mindre problem, end det var for nogle år siden. Set i forhold til databaseteknologien, er der faktisk tale om relativt små datamængder. For brugerne er der derimod tale om relativt store datamængder, da der skal bruges store ressourcer til at indsamle og vedligeholde data. Derfor er der lagt vægt på, at der skabes hensigtsmæssige sammenhænge mellem data, således at redundans minimeres, og data kan valideres og udnyttes bedst muligt Navngivning Under designet af datamodellen er der defineret nogle vejledende regler for navngivning af tabeller og felter. Formålet er at tilstræbe, at den fysiske database bliver lettere at gennemskue og administrere for databaseadministratorer, programmører og de avancerede brugere Navngivning af tabeller Tabelnavne må højst være på 18 karakterer. Der findes Database Management Systemer (DBMS), der ikke kan håndtere tabelnavne, der er længere end 18 karakterer. Endvidere vil databaseadministratorer ikke finde det hensigtsmæssigt, at håndtere de lange tabelnavne ved udarbejdelse af forespørgsler. Tabeller i DANVAND er navngivet således, at navnet ender på _VAN. Hermed kan de adskilles fra andre tabeller, der ikke vedrører vandforsyning. Tabelnavnene skal endvidere være så sigende som muligt. Slutbrugere bør dog som regel ikke forholde sig til tabelnavne Navngivning af felter Som det er tilfældet ved tabelnavne, må feltnavne højst være på 18 karakterer. Endvidere er der anvendt følgende regler for interne nøgler: Et felt, der er primærnøgle og genereres ved autonummerering, skal have navnet ID. 31

36 Et felt, der er fremmednøgle fra et autonummereret felt, skal have et navn, der består af en kombination af parent-tabellen og ID. F.eks. skal et felt, der er fremmednøgle til tabellen Knude, have navnet KnudeID, da tabellen Knude har en primærnøgle med navnet ID. Den sidstnævnte regel må dog fraviges og navnet tilpasses, hvis feltnavnets længde overstiger 18 karakterer. Felter, hvortil der er tilknyttet en kodetabel, skal navngives således, at det ender på Kode Navngivning af sequences En sequence er en facilitet i Oracle, der holder styr på værdien i et autonummereret felt, der oftest er en primærnøgle. En sequence navngives med en kombination af tabelnavn og _SEQ. F.eks. vil en sequence til tabellen Knude få navnet KNUDE_VAN_SEQ. 32

37 APPENDIKS 33

38 A1. DATABASEBEGREBER Ved design af datamodellen er det tilstræbt at datamodellen afspejler virkeligheden, at datamodellen sikrer validering af data, at den skal være let at udbygge, at der ikke er overflødige data (redundans), at databasen i højere grad end applikationer kontrollerer de regler, der gælder for, hvordan data behandles i en database. En velstruktureret datamodel vil gøre det betydeligt lettere, at udbygge datamodellen til at håndtere andre typer data. Dermed er det også mere enkelt for f.eks. en kommune eller softwareleverandør at udbygge datamodellen, og således opfylde mere individuelle behov, uden at data skal konverteres. Datamodellen skal opfattes som en datastandard, der omfatter de rent vandforsyningstekniske data, der er interessante at udveksle med andre organisationer. Udveksling af data skal kunne foretages, uanset hvilke applikationer afsender og modtager bruger. Databasesystemerne kunne være enten Microsoft Access, Microsoft SQL Server, Oracle eller andre. Afhængig af hvilken applikation man bruger f.eks. GIS, vil der altid være behov for mindre udvidelser, der tilgodeser applikationens behov. Der er lagt meget stor vægt på validering af data. Som eksempel skal det sikres, at man ikke mister eksterne data, hvis en bruger, sletter eller ændrer navn på f.eks. en knude. Dette gøres ved at databasen kan nægte at slette knuden, før man har taget stilling til de eksterne data. En anden mulighed ved sletning af en knude er, at lade databasen foretage en automatisk oprydning i de eksterne data, hvilket dog normalt må frarådes. Navneændringer bør kunne foretages, uden at man mister forbindelsen til eksterne data. Ændrede navne på knuder skal dermed være synlige, uanset hvilken tilgang man har til databasen. For at opfylde ovenstående målsætninger, er der i datamodellen lagt stor vægt på normalisering, generalisering og referenceintegritet. Disse begreber uddybes i de følgende afsnit. Normalisering Normalisering skal her kun berøres kort. 34

39 Normalisering af data benyttes til at fjerne uheldige egenskaber i en database. Dette vil ofte være redundans, hvor samme oplysninger lagres flere steder i databasen. Hvis normalisering er gennemført til det yderste, vil tabellerne være i 4. eller 5. normalform. Dette er ikke altid hensigtsmæssigt, da der kan opstå så mange tabeller, at databasens ydeevne reduceres. Det er tilstræbt, at tabellerne er i 3. normalform, hvilket ofte anses for at være et passende kompromis. Den 3. normalform kan defineres på følgende måde: Primærnøglen, hele primærnøglen og kun primærnøglen bestemmer data i en tabel. Generalisering Det forekommer ofte, at man har et antal tabeller, der indeholder samme type information. I disse tilfælde kan man bruge generalisering. Generalisering er illustreret i nedenstående eksempel. I Figur A1.1 er der vist to tabeller, hvor der ikke er foretaget generalisering. Begge tabeller indeholder attributten Saldo. Figur A Tabeller uden generalisering. I Figur A1.2 er der foretaget en generalisering, således at saldo kun gemmes i parenttabellen Konto. Attributter, der kun er relevante i forbindelse med udlån eller indlån gemmes i henholdsvis Udlån eller Indlån, der er child-tabeller. Alle tabellerne har samme nøgle, hvorfor relationstypen er en-til-en mellem Konto og Udlån og mellem Konto og Indlån. Attributten IndlånUdlån i tabellen Konto angiver kontotypen og dermed i hvilken childtabel, der skal foretages opslag. 35

40 Figur A1.2 Tabeller med generalisering. I eksemplet er generaliseringssymbolet angivet med to vandrette streger. Dette betyder, at generaliseringen er komplet, således at der skal være en række i én af childtabellerne. I visse tilfælde vil der kun være én streg i symbolet, hvilket angiver, at der ikke nødvendigvis findes en række i child-tabellerne. Der må ikke registreres data i flere end én af child-tabellerne. Referenceintegritet Referenceintegritetsreglen siger populært, at alle steder, hvor der peges på noget andet, skal dette andet findes. Dette er illustreret i Figur A1.3. I tabellen Konto er attributten Navn en fremmednøgle, der peger på primærnøglen i tabellen Person. Referenceintegritetsreglen medfører, at en række i tabellen Person ikke må slettes, så længe der er refereret til den i tabellen Konto. Den medfører også, at der ikke kan oprettes en konto, før personen er registreret i tabellen Person. Figur A1.3 Referenceintegritet I en database kan man vælge at gennemtvinge referenceintegritet, således at det er fysisk umuligt, at slette fra tabellen Person, så længe der peges på personen fra Konto. Man kan også vælge, at lade databasen automatisk slette fra tabellen Konto, når en person slettes. I forbindelse med generalisering skal man være opmærksom på, hvordan man laver fremmednøgler i child-tabeller. I Figur A1.4 har tabellen Indlån en fremmednøgle til tabellen Person. Hvis en person slettes, slettes dennes kontonummer fra tabellen Indlån, men det slettes ikke fra tabellen Konto! Denne har jo ikke nogen fremmednøgle til Indlån. Man kan altså risikere, at have et kontonummer, der hverken er indlån eller udlån. 36