SOSI-modell i MSAccess (Uferdig notat)

Transkript

1 Erling Onstein 19.febr 1998 SOSI-modell i MSAccess (Uferdig notat) 1. Innledning Access-implementasjonen bygger på logisk modell beskrevet i notat SOSI-forvaltning logisk modell skrevet av David Skogan. Kjernen i modellen er de 5 hoved -tabellene (objektkataloger, objekttypedefinisjoner, elementdefinisjoner, gruppetyper og begreper) markert med rød ring i figur under. Innholdet i disse tabellene, og hvordan de er koblet sammen (ved fremmed-nøkler eller via konstruksjonstabeller) går (til en viss grad) også fram av figuren under.

2 2. De ulike tabellene Litt mer omtale av de ulike tabellene som finnes Objektkataloger Felt datamodell peker på en figur i tabell Figurer. Dette medfører at hver objektkatalog kun kan ha en figur som beskriver modellen. Dersom det finnes flere modeller(-figuere), må disse settes sammen i en figur Objekttypedefinisjoner Som en ser av tabelldefinisjonen, inneholder denne et felt objektkatalog, som angir hvilken objektkatalog de ulike objekttypene tilhører. Objekttypene har også tilordnet et felt dimensjon. Dette feltet (kan bl.a.) brukes til å angi hvilket lovlig set med gruppetyper som kan brukes, se også felt dimensjon i tabell gruppetype.

3 Hver objekttype har sin definisjon. I dagens SOSI brukes i stor grad samme definisjon på objekttyper med samme temakode, slik at 3 objekttyper (representasjonspunktet, begrensningslinja og flata) bruker samme definisjonen. Dersom slik felles-definisjon finnes, vil den i Access-basen bli lagret 3 ganger Elementdefinisjoner Inneholder både basis-element og gruppe-element. Felt gruppe gir grunnlag for å skille disse to. Elementnavn er primærnøkkel. Dette tvinger fram entydige elementnavn Kodeverdier Lovlige kodeverdier er definert for en del elementer. Dette finnes i tabell Kodeverdier

4 For å være lovlig egenskapsnavn i denne tabellen, må det finnes tilsvarende elementnavn i tabell elementdefinisjoner. (referanse-integritet) 2.5. Begrepdefinisjoner Et begrep er koblet til en objekt-katalog via feltet objektkatalog, dvs hvert definert begrep tilhører maksimalt en objektkatalog. Dersom feltet er tomt, tilhører den ingen objektkatalog (hva tilhører det da?) 2.6. Gruppetyper

5 2.7. Figurer Figurer er lagret i egen tabell. I denne versjonen er figurene lagret dobbelt, tilgjengelig både for WEBrapportering (via felt Figur_WEB_adresse) og som OLE-objekt via felt Figur_OLE. Dette bør vel egentlig være unødvendig. 3. Sammensetningen av objektene. De ulike sammensetningene er løst både ved hjelp av fremmednøkler og ved egne konstruksjons-tabeller Objekttypene tilhører en objektkatalog. Dette er tatt vare på av feltet objektkatalog i objekttype-tabellen Objekttypene har egenskaper Egen tabell objektegenskaper håndterer dette.

6 3.3. Objekt_egenskaps_verdi-skranker Objekttypene har skranker på hvilke egenskapsverdier som må finnes. Egen tabell Objekt_egenskaps_verdi. De egenskapene som har skranke-verdier, må være lovlige egenskaper for denne objekttypen, dvs de må eksistere i tabell objektegenskaper. De definerte skranke-verdiene må være lovlig kode for de respektive elementene, dvs de må finnes i tabell kodeverdier.

7 3.4. Objekttypene representeres med gruppe-typer Objekttypene har definert ei liste med lovlige gruppetyper som de kan representeres med Gruppe-element består av sub-element Håndteres i tabell Gruppeelement_sammensetning.

8 3.6. Gruppetypene har sine egenskaper. Håndtert i tabell gruppeegenskaper 3.7. Kobling begrep figurer Denne tabellen gjør det mulig at et begrep (en term) kan ha tilknyttet flere figurer.

9 4. Ting som må avklares/diskuteres 4.1. Tekst-lagring For å håndtere større mengder tekst er det brukt datatype notat. I notat er det sterke begrensninger på hvilke formaterings-muligheter som finnes for deler av notatet. Formatteringsinstruksjonene går på hele innholdet i notat-feltet. Dette medfører at uthevinger, innrykk, tabeller og lignende ikke kan brukes. Dersom disse begrensningene ikke er akseptable, må en bytte ut notat-datatypen med noen annet, for eksempel OLEobjekt. Notat-datatyper finnes i flere andre datatyper (ORACLE, INFORMIX..). Dersom notat benyttes bør en dermed være friere enn om en benytter MS-spesifikke OLE-datatyper Kardinalitet-angivelser Dette er dårlig beskrevet i SOSI. Det er ofte snakk om både minimums-kardinalitet og maksimuskardinalitet. Minimus-kardinaliteten er til en viss grad dekket med standard/opsjonsfeltet, men maksimumskardinaliteter ikke er beskrevet. I KVAKK parameterfiler finnes til en viss grad dette. Eksempel: En eiendomsteig kan ha flere forekomster av GID, mens en markslagsfigur kun kan ha en ATILforekomst. Det som er tolket inn i KVAKK parameterfilene burde også finnes i Access-basen Mangel-verdier Det er gjennomført at egenskaper som har default-verdi (den mest vanlig verdien) ikke blir oppgitt. Men kun unntaksvis (hva er unntaket?) er det klart definert hva som er default-verdi. For en del egenskaper er verdien 0 defaultverdi (gjelder EKODE, ARKODE. Hvor finnes denne bestemmelsen?). Se også punkt 4.3 under Standard/opsjons-feltet i tabell Kodeliste og detaljeringsgrad Dette begrepet er benyttet på to forskjellige ting: 1. På frivillige og obligatoriske egenskaper.. Noen egenskaper til objekttypene må en registrere (de er standard), andre kan en hvis en har lyst (de er opsjoner). Dette stemmer med bruken av standard/opsjoner i del 4 Registrereringsinstruksen. 2. På betinga egenskaper. Noen egenskaper er aktuelle for alle objekttyper, men med regler om at dersom egenskapen har den mest vanlige veriden (default-verdien) skal ikke dette angis. Når MEDUIM ikke gis, kan dette da enten bety at MEDUIM ikke er vurdert, eller at MEDUIM har defaultverdien som (på tross av at den ikke er formelt definert) er på bakken Verdi-feltet i tabell Kodeliste og detaljeringsgrad For noen egenskaper (f.eks HREF) er det av og til listet flere mulige verdier. Dette skal i de fleste tilfeller oppfattes som gjensidig ekskluderende verdier (kan ikke være både HREF TOP og HREF FOT). Unntaksvis skal det oppfattes som om flere av forekomstene kan finnes i samme gruppe/objekt. Ei gruppe kan for eksempel ha flere temakoder (multiple koder).