Din database: En kølig lagerhal eller en topmoderne logistik central?

Din database: En kølig lagerhal

eller en topmoderne logistikcentral?

De fleste, der anvender geodata i det daglige arbejde, anvender også en spatial database; en database, som er indrettet til at håndtere geografiske data hurtigt og effektivt. Men udnytter du mulighederne i din spatiale database fuldt ud?

AF MORTEN STORM, STYRKE 10 APS

En spatial database behøver ikke blot være en “lagerhal” til dine data, men kan fungere som en full blown logistikcentral, som – udover at opbevare dine data – også sørger for at berige og raffinere dine data ud fra forskrifter, som du selv lægger i databasen.

Og hvis du anvender en open source-database som eksempelvis PostgreSQL med PostGIS-extension, har du rige muligheder for at gøre din database til andet og mere end blot en lagerhal.

Hvorfor funktionalitet i databasen?

Vi har brug for funktionaliteten til en bedre og mere effektiv udnyttelse af de meget store datamængder, vi har til rådighed. Herigennem kan vi understøtte vores bestræbelser på at optimere driften og skabe bæredygtig forretning.

Kompetencerne for optimal udnyttelse og forståelse af komplekse data bliver afgørende i løsningen af nutidens svære udfordringer. Mulighederne med funktionalitet i databaserne er i den forbindelse uanede.

De simple greb

Det første simple greb, du kan gøre for at udvide database-anvendelsen, sikrer datakvalitet og letter dit redigeringsarbejde. Det sker bl.a. ved at sætte begrænsninger (constraints) på udvalgte felter i dit geografiske lag / din tabel.

Et eksempel herpå kan være et forsyningsselskab, som ønsker at registrere graveskader. Graveskader skal i henhold til LER-loven indberettes til LER årligt. Derfor er det oplagt at registrere disse i eget GIS i takt med, at skaderne opstår eller opdages. Her er det selvsagt vigtigt at få registreret alle de data om graveskaderne, som LER stiller krav om. Det sikrer du ved at sætte constraints op i din tabel. Constraints gør, at du ikke kan gemme et graveskadeobjekt, hvor skadevolderen er registreret som en virksomhed, medmindre du også inddaterer den pågældende virksomheds CVR-nummer. Det betyder, at data er på plads med det samme, og at du ikke senere skal til at finde skadevolders CVR-nummer for at kunne aflevere dine graveskader til LER.

Et andet simpelt greb går på at lette dit inddateringsarbejde. Det gør du ved at generere og opdatere udvalgte felter automatisk. Der er ingen grund til, at du skal inddatere dine initialer, dato for registrering eller længden af linjeobjekter, når databasen sagtens kan tilføje disse data på egen hånd.

Med en trigger på din tabel kan du definere, hvad der skal ske, når et objekt indsættes, opdateres eller slettes. Triggeren vil sikre, at denne opdatering håndteres ganske automatisk. Det er ikke mindst tidsbesparende og giver en markant forøgelse af datakvaliteten.

Den mere avancerede tilgang

De simple greb arbejder på et enkelt objekt i et enkelt lag eller tabel. Når du tager dette et skridt videre til en mere avanceret tilgang, kan du også indarbejde relationer til andre objekter i samme lag eller andre lag.

Det betyder, at du kan simulere snap i en klient, som ellers ikke understøtter snap. Du har måske behov for at kunne se placeringen af dine kunder geografisk ved at oprette kundeobjekter, som placeres på deres adresse i kortet. Din webGISklient kan godt oprette punktobjekter, men kan i dette eksempel ikke snappe disse til andre objekter i kortet.