FKG Fælleskommunale Geodatasamarbejde FKG datamodellen Version 2.3.1 Implementeringsguidelines Sidste revisionsdato: 24. oktober 2013 1
Dokumenthistorik Version Dato Initialer Ændring 1.0 5.7.2013 TBS/NIRAS Initialversion 1.1 8.7.2013 TBS/NIRAS Tilpasset FOT s review (revisionsspor) 1.2 8.7.2013 TBS/NIRAS Tilpasset FOT s review (use-kommando) 1.3 26.8.2013 TBS/NIRAS Tilpasset høringssvar 1.4 24.10.2013 TBS/NIRAS Tilpasset anden rundes høringssvar 2
Indholdsfortegnelse 1 BASELINE... 4 1.1 INDHOLD... 4 1.2 DEN LOGISK DATAMODEL... 4 1.3 IMPLEMENTERING PÅ SQL SERVER... 4 1.4 INTEGRATION TIL DESKTOP GIS... 4 2 GUIDELINES... 5 2.1 OVERSIGT... 5 2.2 NAVNGIVNING AF TABELLER... 5 2.3 TEMATABELLERNES NØGLER... 5 2.4 OBLIGATORISKE OG VALGFRIE ATTRIBUTTER... 5 2.5 VÆRDIOMRÅDER... 5 2.6 KODETABELLER... 6 2.7 GEOMETRI... 6 2.8 INDEX... 6 2.9 INTERFACEVIEWS... 6 2.10 HISTORISKE INTERFACEVIEWS... 8 2.11 DATATYPER... 8 3
1 Baseline 1.1 Indhold Nærværende dokument er en implementeringsguideline, som databaseudviklere, der implementerer en fysisk FKG database, bør overholde. Dokumentets formål er at sikre, at de fysiske implementeringer af FKG datamodellen, følger et minimum af fælles retningslinjer. På den måde sikres det, at vilkårlige applikationer kan anvendes mod vilkårlige leverandøres databaseimplementeringer, så længe adgangen til databasen går via interfaceviews. versionen er tilgængelig via scripts og disse er dokumenteret i dokumentet FKG datamodellen version 2.3.1 - MS SQL Server. 1.4 Integration til desktop GIS For at sikre en velintegreret integration af markedsledende desktop GIS værktøjer, er der foretaget en række tilpasninger/udvidelser af den fysiske database. Disse er dokumenteret i dokumenterne FKG datamodellen version 2.3.1 - GeoMedia integration og FKG datamodellen version 2.3.1 - MapInfo Integration De to variationer benævnes FKG GeoMedia databasen og FKG MapInfo databasen Den fysiske database benævnes FKG basis databasen. 1.2 Den logisk datamodel De angivne guidelines tager udgangspunkt i den logiske FKG datamodel, som er dokumenteret i dokumentet FKG datamodellen version 2.3.1. Den logiske datamodel benævnes FKG datamodellen. Der henvises til dokumentet om FKG datamodellen for alle nærmere forklaringer af modellens indhold, herunder definitioner af modellens tabeller og attributter. 1.3 Implementering på SQL Server Den fysiske datamodel er implementeret på en MS SQL Server platform. Implementeringen overholder de nævnte guidelines. MS SQL Server 4
2 Guidelines 2.1 Oversigt FKG datamodellen Version 2.3.1 Implementeringsguidelines 2.2 Navngivning af tabeller Alle kodetabeller/opslagstabeller navngives identisk med FKG datamodellens tabelnavne (fx d_basis_ja_nej). FKG basis databasen skal implementere FKG datamodellens temaspecifikke og generelle datamodel, dvs. tematabeller og kodetabeller. Implementeringen skal understøtte hierarkiet med temagrupper, temaer og objekter i temaer. Hierarkiet beskrives i tabellerne d_temagruppe, d_tema og tematabellerne. d_temagruppe PK temagruppe_kode temagruppe Figur 1 Temagrupper og temaer d_tema PK tema_kode tema_navn FK temagruppe_kode geo udvekslingsnavn D_temagruppe og d_tema skal fx indehold disse rækker: t_5000_vandl_t PK versions_id objekt_id FK temakode FK cvr_kode bruger_id FK oprindkode FK statuskode link FK tidl_amt_kode FK ejerstatus_kode FK dvfi_bedoemmelse_kode FK trussel_vand_kode systid_fra systid_til oprettet Alle tematabeller skal navngives på baggrund af udvekslingsnavnet i d_tema, men post_fix es med _t (da udvekslingsnavnet er identisk med det interfaceview, som skal bygges over temaet). Fx bliver tematabellen til tema 5000 navngivet således: t_5000_vandl_t, mens det interfaceview, der skal bygges over tabellen skal hedde t_5000_vandl. 2.3 Tematabellernes nøgler Tematabellernes primære nøgler skal navngives versions_id. Datatypen er UUID (identisk med GUID). 2.4 Obligatoriske og valgfrie attributter FKG datamodellen angiver om værdierne i de enkelte attributter er obligatoriske (O), valgfrie (F) eller systemudfyldte (S). Attributter med obligatorisk indhold skal implementeres med NOT-NULL constraints Systemudfyldte attributter, der udfyldes med en kodetabel, er ikke oprettet i tematabellerne (se afsnit 2.6). Systemudfyldte attributter er selvfølgelig synlige i interfaceviews, hvor kodetabeller og tematabeller sammenstilles. 2.5 Værdiområder FKG datamodellen udstikker forskellige former for værdiområder. Figur 2 Eksempler på temagruppe og tema Værdiområder, der i FKG datamodellen fastlægger et interval af antal teksttegn (fx 1-128), skal implementeres som tekststreng (x), hvor x 5
svarer til intervallets maksimum (se afsnit 2.11 for en præcisering af hvilken datatype, der skal vælges til en tekststreg-implementering). Værdiområder, der fastlægger indholdsmæssige restriktioner (fx gyldige talværdier: 000000,0-200000,0 ), skal implementeres som constraints på de enkelte attributter (fx ([station_fra]>=(0) AND [station_fra]<=(200000)) ) FKG datamodellen Version 2.3.1 Implementeringsguidelines 2.8 Index På alle tematabeller skal der oprettes følgende indekser: Unik indeks på versions_id. Unik indeks på objekt_id og systid_fra. 2.6 Kodetabeller Der skal oprettes en kodetabel for hver kodeliste i FKG datamodellen. Til en attribut med en tilhørende kodeliste (fx t_5000_vandl_t.temakode), skal der oprettes en relation til en kodetabel (fx d_tema.kode). Dette sikrer, at der kun kan angives værdier, der er i overensstemmelse med indholdet i kodetabellen. Almindelig indeks på objekt_id. Almindelig indeks på systid_til. Almindelig indeks på systid_fra. Almindelig indeks på systid_fra og systid_til. Spatial indeks på geometri. Det er muligt at indsætte nye værdier i kodetabellerne, men det anbefales, at man kun indsætter/retter i de kodetabeller, hvor dette er specifikt angivet i FKG datamodellen. Fx specificerer FKG datamodellen ikke indholdet i kodetabellen d_basis_omraade. Denne tabel skal befolkes i de enkelte fysiske implementeringer. 2.7 Geometri Kolonner til geometri skal understøtter Open Geospatial Consortium (OGC) specifikation for geometry-objekter. Der lægges vægt på, at det i de enkelte tematabeller kun er muligt at indsætte geometrityper (punkt, linje, flade) som matcher det pågældende tema. Fx er et vandløb en linje. Dette sikres fx via anvendelse af en trigger/procedure på de enkelte tabeller, som kontrollerer, at den geometritype, der indsættes/opdateres, matcher det aktuelle tema. Overtrædelse af reglen skal returnere en fejl. I de enkelte databaser kan man efterfølgende oprette flere indekser, der er tilpasset de opslag, der foretages i forskellige konkrete brugssituationer. Der skal oprettes spatiale indekser på geometri-kolonnerne. Såfremt databasen understøtter det, skal de geometriske indekser oprettes på baggrund af en bounding box, der omfatter hele Danmark inkl. Bornholm. Bounding box er angivet med koordinater i UTM zone 32. Såfremt der viser sig performancemæssige udfordringer med dette setup, kan man overveje at tilpasse bounding box til det geografiske område, der er omfattet af databasen. 2.9 Interfaceviews En bruger skal ikke foretage opslag direkte på tabellerne. En bruger skal heller ikke foretage opdateringer direkte i tabellerne. Opslag og opdateringer foretages igennem interfaceviews. 6
Der skal oprettes de interfaceviews som fremgår af d_tema.udvekslingsnavn. Som centrum i hvert interfaceview findes en tematabel, og til denne joines alle de relevante kodetabeller, som fremgår af FKG datamodellen. Der skal indbygges et sæt regler i FKG basis databasen til sikring af dataintegritet. Når en række indsættes: Hvis attributten bruger_id er null, skal brugernavnet på den aktuelle databasebruger indsættes automatisk for at sikre sporbarhed. Hvis attributten objekt_id er null, skal der automatisk genereres og indsættes en ny objekt_id. Hvis den angivne objekt_id har en værdi, der allerede eksisterer i viewet, skal databasen returnere en fejl til. Databasen skal automatisk opdatere attributten systid_fra med den aktuelle dato og tid. Databasen skal automatisk opdatere attributten systid_til til null. Databasen skal automatisk opdatere attributten oprettet med aktuel dato og tid. Når en række opdateres: Databasen skal gøre to ting: Den oprindelige række gøres historisk ved at udfylde systid_til med aktuel dato og tid. En ny række skal indsættes, og attributterne i denne skal svare til den de opdaterede attributter. Databasen skal opdatere attributten systid_fra i den nye række med den aktuelle dato og tid. Hvis attributten cvr_kode er null, skal der automatisk indsættes en standardværdi. Standardværdier bør være konfigurerbare (ikke hardkodede. En oplagt metode er at oprette en tabel indstillinger, som har to kolonner: noegle og vaerdi. En række i tabellen kan indeholde noegle= std_cvr_kode og vaerdi= 123456. Ved en insert transaktion med cvr_kode null skal databasen så automatisk indsætte 123456 som cvr_kode. Databasen skal undersøge, om geometritypen matcher af den type, der er gældende for temaet (punkt, linje eller flade). Disse fremgår af d_tema.geo. Hvis dette ikke er tilfældet, skal databasen returnere en fejl. Databasen skal opdatere attributten Systid_til i den nye række til null. Databasen skal sikre, at kodetekster, der hentes fra kodetabeller, ikke opdateres. Kun kodeværdier må opdateres. Eksempel i view t_5000_vandl: Vil man ændre kodeteksten i feltet vandl_type, så skal man ændre kodeværdien i feltet vandl_type_kode. Sammenhængen mellem kodeværdier og kodetekster er beskrevet i FKG datamodellen. Attributten bruger_id skal håndteres som ved insert. Databasen skal sikre, at attributten objekt_id ikke opdateres. Databasen skal sikre, at der kun kan indsættes en temakode, der svarer til viewets temanummer. Hvis en transaktion indeholder en ulovlig temakode, skal databasen returnere en fejl. Attributten geometritypen skal håndteres som ved insert. Databasen skal sikre, at attributten temakode ikke opdateres. Databasen skal automatisk generere et versions_id. Databasen skal automatisk generere et Versions_id. 7
Databasen skal sikre, at attributten oprettet ikke opdateres. Når en række slettes Databasen skal automatisk opdatere rækkens systid_til med den aktuelle dato og tid. Dvs. at række ikke slettes, men markeres som historisk. FKG datamodellen Version 2.3.1 Implementeringsguidelines 2.11 Datatyper FKG datamodellens angivelse af datatyper skal implementeres med følgende datatyper i MS SQL Server, Oracle og PostgreSQL Datamodel SQL Server Oracle PostgreSQL 2.10 Historiske interfaceviews Hvert af FKG basis databasen interfaceviews skal have oprettet en historisk pendant. Et interfaceview til historiske data skal tildeles fornavnet hist_. Fx: for tema 5000 er navnet på interfaceview t_5000_vandl, mens det historiske view hedder hist_t_5000_vandl. Tekststreng Nvarchar Nvarchar2 Varchar Heltal Int Smallint Number(10) Number(5) Int Smallint Double Numeric Number Double precision Dato Datetime Timestamp Timestamp Geometri Geometry Sdo_geometry Geometry UUID uniqueidentifier Raw(32) Uuid 8