I fællesoffentlig regi, er der vedtaget en Gunddatamodel, som fremover kommer til at omfatte de væsentligste registre, hvor man gennem denne, forsøger at skabe én sammenhængende datamodel, på tværs af registre.
I dette afsnit vil vi gennemgå, hvordan vi har valgt implementeringen i LOIS-databasen version 3.0.
Native grunddata
For at understøtte den fællesoffentlige grunddatamodel og brug af grunddata i andre applikationer, der ønsker at basere sig på data fra LOIS-databasen, vil en lang række grunddata på sigt være at finde i deres native form i LOIS databasen.
I skemaet "DAF_xxx" (for Datafordeler), vil du kunne finde tabeller med grunddata i samme datamodel, som de udstilles på Datafordeleren.
Data herfra vil du findes i deres normaliserede form, som de distribueres med fra Datafordeleren.
Et eksempel på, hvordan denne native datamodel ser ud for en del af BBR-bygning, kan ses her:
Ulemper ved DAF-implementering:
Den fællesoffentligte datamodel er fuldstændig normaliseret, hvilket vil sige, at der der i hver tabel kun er de helt basale attributter, samt nøgler til andre data.
Det vil eksempelvis sige, at I BBR Bygning findes der kun nøgler til adressen og jordstykke, men ikke de reelle data. Det betyder, at hver gang man skal fremsøge data på baggrund af en adresse, matrikel, geometri eller andet, skal man lave joins mellem en række tabeller for at kunne fremsøge data.
Dette er i modsætning til den nuværende implementering i LOIS 2.0 - eks. NyBBR_BygningView - hvor man direkte via view'et kan fremsøge bygningsdata via adressen eller matriklen.
Fordele ved DAF-implementering:
Fordelen ved at benytte DAF-implementeringen af datamodellen er, hvis data skal benyttes i fagsystemer eller lign. som skal have data i grunddatamodellen.
På denne måde vil det være nemmere at skifte "dataleverandør" til fagsystemerne.
Ovenstående årsagen er gunden til, at LIFA har valgt at lave vores egen implementering af datamodellerne, som gør data mere operationelle for slutbrugeren.