I LOIS vil de datasæt, som findes på Datafordeleren, kunne findes i forskellige implementeringer. Ikke alle data vil findes i alle typer implementeringer, da dette vil give redundante data.
Nativ implementering
I LOIS udstiller vi data fra de forskellige datamodeller, direkte i deres grundform. Man kan altså bruge de native data, direkte som de findes i kilden - se mere om dette her.
Ud over ovenstående datamodel, udstiller data også i LIFA's egen implementering:
LIFA's implementering - aktuelle data
I den daglige brug af data, har man oftest kun brug for de aktulle data. Det vil f.eks. sige, at man kun ønsker at arbejde med de aktuelle bygninger som findes, de aktuelle jordstykker som er gældende osv.
Data i LOIS 3.0 udstilles derfor i views som udelukkende viser de aktulle data, for at gøre det nemt for slutbrugeren. På denne måde behøver brugeren ikke at skulle filtrere på dataudtræk, hver gang data skal sættes i spil.
LIFA's implementering - historiske data
De fleste registre udstiller også historik i data, således at udgåede objekter (f.eks. nedrevede bygninger o.l.) stadig fremgår af registret, men med en kode som angiver, at dette objekt ikke længere er gældende.
Disse data findes som standard også i LOIS, men vil kunne tilgås i views som er betegnet skema.HisNavnView - se mere her.
LIFA's implementering - dobbelthistoriske data
Hvis en kunde har behovet (og pladsen i databasen) kan data også udstilles med den dobbelthistorik som registeret tilbyder.
Da implementering af dobbelthistorik betyder flerdobling af alle objekter i et register, er der tale om meget store datamængder, hvis en kunde ønsker dette i deres egne lokale database.
Fremsøgning af data i en database med dobbelthitorik kræver også ret avanceret SQL, så derfor levereres dette kun, hvis kunden er helt klar over konsekvenserne af dette valg.
LIFA's implementering
For at bringe data nemmere i spil for slutbrugeren, har vi i LOIS valgt at udstille data i en udvidet model i forhold til grunddatamodellerne.
Det betyder, at i LIFA's implementering findes der ikke kun nøgler til andre registre, men vi har valgt at implementere disse data direkte i vores views. Helt konkret betyder det f.eks., at tekster på kodeværdier, vejnavne samt matrikelnumre kan findes direkte i de de afledte data som vi danner.
Man skal således ikke joine flere tabeller/views hver gang man skal koble en adresse, jordstykke, kodeværdi tekst eller andet på, da vi har valgt at udstille data i en denormaliseret form i vores views.
Dette kan eksemplificeres med data for bygninger fra BBR:
Data om BBR Bygning, vil derfor potentielst kunne findes i tre forskellige views:
DAF_BBR.Bygning - Alle data (normaliseret)
BBR.BygningView - Kun aktuelle data (ikke normaliseret)
BBR.HisBygningView - Alle data (ikke normaliseret)
Ulemper ved LIFA's implementering:
Når data ikke er normaliseret, og dermed ikke overholder grunddatamodellen, vil det være sværere at udskifte eventuelle fagystemer, som baserer sig på denne implementering af datamodellen.
Fagsystemerne vil dog blot kunne benytte basistabellerne, hvor data stadig ligger i deres grundform.
Fordele ved LIFA's implementering:
Ved at koble relevante data på den korrekte måde direkte i de views som skal anvendes af brugeren, slipper brugerne for at skulle lave de samme joins igen og igen.
På denne måde er det gjort nemmere for slutbrugeren at bringe data i spil.
Da relevante data samtidig bliver geokodet i LIFA's implementering giver dette en ekstra fordel vd at benytte disse views.
Den store fordel ved at benytte LOIS-databasen som datagrundlag er, at man kan få fordelene fra begge implementeringer, da de samme grunddata udstilles på begge måder.