===DOKUMENTASJON AV TABELLENE.=== Terje Reite februar 2005. GENERELL OVERSIKT. Tabellene kan kategoriseres på 3 forskjellige måter: 1) den ene er kilden til innholdet i tabellene: runtime - metadata 2)den andre er model - observasjon 3)den tredje er hva eksterne brukere trenger: trenger - ikke trenger. 1) Kategorisert etter kilden til innholdet i tabellene får vi en run_time gruppe og en metadatagruppe. På mange måter kan vi oppfatte runtimegruppen som en datagruppe. Tabellene i runtimegruppen er: data, text_data, rejectdecode og model_data; blant disse er også to views: data_view og text_data_view. Tabellene key_val, workque og workstatistik er tabeller til hjelp under runtime. Tabellene i metadatagruppen er resten av tabellene i databasen. 2)En annen måte å dele tabellene inn etter grupper er etter modell - observasjon. da blir tabellen model og model_data i en gruppe og resten av tabellene i en annen gruppe. Tabellen model er da en metadata tabell og tabellen model_data er en runtime tabell. 3)En tredje måte å dele inn tabellene på er etter hva kundene SYNOP-enkoderen, Klimadatabasen, KRO og eventuelle andre trenger - kunder trenger ikke vite noe om modelldata, tabellene model_data og model blir da uaktuelle - kunder trenger ikke vite noe om ikke dekodede data, tabellen rejectdecode forsvinner - kunder trenger ikke vite noe om metadata og tabeller som har med checker og algoritmer, flesteparten av metadatatabellen forsvinner bortsett fra types param station data. KILDE: NORCOM, ComObs, AUtoObs, div. etterregistrering. HVEM bruker tabellen: Alle moduler. BESKRIVELSE av tabellen: Inndata meldinger blir parset til observasjoner og plassert her. BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer, se tabellen station. obstime: Observasjonstermin. Tidspunkt for observasjonens gyldighet. original: Observert parameterverdi paramid: parameternummer, se tabellen param. tbtime: Tidspunkt for når raden ble generert i Kvalobsdb. typeid: Se tabellen types. sensor: Sensornummer der samme parameter observeres ved flere sensorer. I klimadatabasen er sensor en del av parameteren, det er den ikke i kvalobs. level: Sensors høyde målt i forhold til bakkenive der samme parameter kan observeres i ulik høyde eller dybde. Defaultverdi er lik tallet 0. Hva defaultverdien egentlig er ligger utenfor kvalobs. Systemet virker slik at defaultverdien er symbolsk og satt lik 0, alle de andre høydene er fysiske. Siden 0 er potensielt aktuelt å måle, så må den situasjonen også håndteres. Løsningene som skal velges skal velges i følgende rekkefølge der 1) skal velges først osv. Den første løsningen beskrevet her sier at dette rett og slett ikke er noe problem. 1) Det mest vanlige i de situasjoner der 0 er aktuelt å måle er faktisk at 0 er default. Dermed er default 0 ikke noe problem siden det sammenfaller med den fysiske verdien. Grunnen at vi i praksis har denne situasjonen er at det fysiske mediumet vi måler i er en del av parameterdefinisjonen i tillegg til den fysiske størrelsen. 2) En måler ikke i 0 meter, en kan måle i 0.0001 meter over bakken eller -0.0001 meter under bakken, legg merke til at dette er to forskjellige parametere siden de er målt i to forskjellige medium. 3) En kan dersom ikke noe annet nytter eller det har en fysikalsk begrunnelse definere en ny parameter ( temperaturen på 0 meter er vel ikke akkurat temperaturen i lufta, men den er heller ikke i bakken, den er en overflatetemperatur på bakken) Målenheten for level er meter ganget med en skaleringsfaktor. Eksponenten til denne skaleringsfaktor heter level_scale og finnes i tabellen param. Verdien i meter tolkes slik: level*10 opphøyd i level_scale. corrected: Observert verdi evt. endret i kontrollene. controlinfo: Kodet informasjon om resultatet av kontrollene, koden er 64 bit. useinfo: Kodet kvalitetsinformasjon om observasjonen, koden er 64 bit. cfailed: tester som har gitt utslag; syntaksen for denne kolonnen er qcx:language i en kommaseparert liste der en får verdiene i fra tabellen checks. text_data. KILDE: INTERN. HVEM bruker tabellen: Alle moduler. BESKRIVELSE av tabellen: Inndata blir parset og plassert her. Poenget med denne tabellen er at det er noen data som ikke er tall. Denne tabellen er en variant av tabellen data og skal ved hjelp av et view sees på som en tabell sammen med tabellen data. Dette viewet er en måte å se på at dataene data og text_data i en felles tabell(view) der dataene fra disse tabellene knyttes sammen med å være fra samme melding. En melding har stationid og obstime som en nøkkel. stationid: stasjonsnummer, se tabellen station. obstime: Observasjonstid. Tidspunkt for observasjonens gyldighet. original: Observert parameterverdi, tekststring som beskriver en signatur eller kode. paramid: parameternummer, se tabellen param. tbtime: Tidspunkt for når posten ble generert i Kvalobsdb. typeid: se tabellen types. VIEW data_view KILDE: tabellene data og text_data BESKRIVELSE av viewet: Outer join der en får med alle kolonner fra datatabellen og de kolonnene i text_data tabellen som har felles stationid og paramid med data_tabellen. VIEW text_data_view KILDE: tabellene data og text_data BESKRIVELSE av viewet: Outer join der en får med kolonner fra text_data tabellen som ikke har felles stationid og paramid med data_tabellen. rejectdecode. KILDE: INTERN HVEM bruker tabellen: Modul for innlesning og diverse. BESKRIVELSE av tabellen: Meldinger som kommer inn og som ikke kan dekodes. message: Melding som har kommet inn og som ikke kunne dekodes tbtime: Tidspunkt for når message ble lagret i Kvalobsdb. decoder: Beskriver hvilken dekoder som er brukt comment: kommentar. F.eks. tekst som beskriver hvorfor meldingen ble forkastet. model_data. KILDE: Pseudodata, fra modeller. HVEM bruker tabellen: Prognostisk romkontroll (QC1-4) og HQC. BESKRIVELSE av tabellen: Inndata fra modell-beregningene tilsvarende observerte verdier, et eksempel her er HIRLAM. BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer, se tabellen station. obstime: Observasjonstid. Tidspunkt for observasjonens gyldighet. paramid: parameternummer, se tabellen param. level: Nivå der samme parameter observeres i ulik høyde eller dybde. original: Beregnet parameterverdi. modelid: En id som indikerer hvilken modell det er, jfr. tabellen model. model KILDE: METADATA, manuelt inntastet. HVEM bruker tabellen: tabellen model_data BESKRIVELSE av tabellen: Dette er en tabell for hvilken modell modelid i tabellen model_data svarer til. modelid: Betegnelse på modell gitt som integer. name: navnet på modellen, f. eks. hirlam10 og EC240. comment: kommentar. types. KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: Data. BESKRIVELSE av tabellen: Dette er en tabell for attributten typeid i tabellene data og text_data. BESKRIVELSE av attributtene i tabellen: typeid: Et tall som identifiserer typiske trekk ved dataene fra en værstasjon som skyldes forskjellig avlesning, formatet som er brukt ved overføring/forsendelse av dataene og registrering av den avleste informasjonen fra samme sensor. Dette betyr at samme observasjon er blitt avlest forskjellig, men med samme sensor/måleinstrument og er sendt inn eller registrert forskjellig. Et eksempel på dette er at samme observasjon kan foreligge i flere ulike formater der presisjonen er forskjellig eller avlesningen er gjort ved litt forskjellig tidspunkt. Et annet eksempel er at samme måleinstrument avleses manuelt eller ved hjelp av automatstasjon. Positive tall regefererer til observasjoner som ikke er endret før kvalobs. Dette er stort sett rene observasjoner, men de kan være avledet, dersom de er avledet skjer avledningen før kvalobs. Negetative tall refererer til avledede observasjoner som er generert etter at observasjonen ble lagt til i kvalobs. format: Navnet på meldingsformatet. Som eksempel har vi: autoobs dagbok metar miljødata pluviometerdata ship SMS meldingsformat synop ukekort earlyobs: INTEGER - tidsgrense i minutter for at en melding er å betrakte som kommet for tidlig lateobs: INTEGER - tidsgrense i minutter for at meldingen er å betrakte som kommet for sent read: Dette har med hvordan observasjonen er avlest og vi har da 3 typer: M = Manuell, A = Automatisk, I = (Kvalobs)Intern. obspgm: observasjonsprogrammet, er det time eller minutt. comment: kommentar. generated_types KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: Data. BESKRIVELSE av tabellen: Dette er en tabell som viser hvilke stationid, paramid kombinasjoner av en typeid som er genererte BESKRIVELSE av attributtene i tabellen: stationid: se tabellen station typeid: se tabellen types param. KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: Alle moduler BESKRIVELSE av tabellen: Kode og beskrivelse for observerte værparametere BESKRIVELSE av attributtene i tabellen: paramid: parameternummer. Se eget dokument. name: Parameterkode, det er et en-entydig forhold mellom kolonnene paramid og name. description: Parameterbeskrivelse unit: Måleenhet for parameteren level_scale: Dette er en 10'er eksponent skala til level for denne parameteren, denne styrer hvordan level i tabellen data skal tolkes. Da vil vi for meter ha verdien 0, for cm vil vi ha -2 for km vil vi ha 3 osv. comment: Tilleggstekst om spesielle forhold ved parameteren. station. KILDE: METADATA, fra ST_INFO_SYS & kvalobs-interne HVEM bruker tabellen: Alle modulene BESKRIVELSE av tabellen: Denne tabellen inneholder informasjon om stasjonene. BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer.Stasjoner som har static lik true kommer fra ST_INFO_SYS, de som har static lik false er kvalobs-interne stasjonsnummer og er autogenerert i kvalobs. Tallet 0 er forbeholdt å brukes som verdi i tabellene checks og station_param som et flagg i betydningen alle stasjoner. Ingen stasjoner kan ha stationid 0. 1) Norske stasjoner. Norske stasjoner som har nationalnr får dette som stationid. Dette er da et tall på 5 siffere i intervallet [60,99999]. Denne er ikke beskrevet i stationstr. 2) Utenlandske stasjoner med wmonr. Her tar en wmonr og legger til 2 nuller bakerst. 3) Stasjoner som ikke faller inn under 1) eller 2) har stationid sekvensielt valgt fra tallverdier større enn +10 000 000. lat: breddegrader måles i det samme system som diana, nemlig i desimalgrader. lon: lengdegrader måles i det samme system som diana, nemlig i desimalgrader. height: dette er høyden over havet målt i meter. maxspeed: maximum farten til fartøyet, måles i m/s name: Stasjonsnavn. For alle stasjoner som hverken har nationalnr eller wmonr bruker vi samme struktur som beskrevet i stationstr. wmonr: Stasjonsnummer inkl. områdenummer benyttet i synopmeldinger, fem siffer. De to første sifferne er områdenummer, de 3 siste er stasjonsnummer. Vi har kun lagret stasjoner som er gyldige i dag. nationalnr: Stasjonsnummer benyttet i Klimadatabasen, fem siffer. Verdiene [60,99999] er norske stasjoner. Verdiene [1,59] brukes i klimadatabasen til deres egen nummerering av utenlandske stasjoner, disse verdiene bruker vi ikke i kvalobsdatabasen. ICAOid: Stasjonsbetegnelse benyttet i METAR-meldingene, fire karakterer. call_sign: Stasjonsbetegnelse benyttet for båter i SHIP-meldinger, syv karakterer. stationstr: For alle andre muligheter enn de overfor nevnte. Kodingen er her områdenummeret (d.e. de to første sifferne) i wmonr ; og til slutt det originale nummer. Dersom ikke dette er entydig så kan en bruke firmanr eller organisasjonsnr i tillegg først etter wmonr med en semikolon i mellom. Eks. XX = de to første sifferne i wmonr YY = firmakode eller organisasjonsnr NN = originalkode kodingen blir dermed: XX;NN eller XX;YY;NN environmentid: En id som refererer til observasjonsmiljøet på stasjonen. environment environmentid environmentdescription FLY 1 Flyplass LANDBRUK 2 Landbruksfelt LOKALKLIMA 3 Lokalklima(oppstilling) MAR_M 4 Oljerigg(bevegelig) MAR_P 5 Oljeplattform MAR_S 6 Skip MAR_V 7 Værskip METNO 8 Områderepresentativ (land) - værstasjon NEDB 9 Nedbøroppstilling NEDB_OPPS 10 Nedbøroppstilling for oppsamling T 11 Turistforeningshytte, etc VEG 12 Vegmiljø static : boolsk variabel, default false; er bare true for de stasjoner som er manuelt godkjent. Aktuelt i første omgang for skip som bare legges inn automatisk i denne tabellen - de får dermed static lik false. Har static verdien false så kan disse radene i tabellen risikere å bli slettet ved automatiske rutiner. fromtime: Tiden fra dataene for denne stasjonen gjelder; det betyr at det ikke nødvendigvis er tiden fra stasjonen ble opprettet. environment. KILDE: METADATA, basert på analyse av type_begrepet i klimadatabasen. HVEM bruker tabellen: station BESKRIVELSE av tabellen: Denne tabellen inneholder en beskrivelse av forskjellige typer miljø for en stasjon. BESKRIVELSE av attributtene i tabellen: environmentid: et id nummer til tabellen environment som sier noe om observasjonsmiljøet på stasjonen name: navnet på miljøet, en alfanumerisk navnekode use: hva dataene kan brukes til description: Beskrivelse av miljøet på stasjonen checks. KILDE: METADATA, våre egne. Det er 2 hovedmåter tabellen checks mottar metadata på: 1) Automatisk Metadataene i checkene er automatisk generert for disse filene og styres i fra station_param og et template for checken som gjør at en får autogenerert hvilke parametere den gjelder for. 2) Manuelt Manuell punching av checks metadata i små filer som deretter leses inn i databasen ved hjelp av et script. HVEM bruker tabellen: QABase BESKRIVELSE av tabellen: Holder rede på filnavn, type sjekk og qcx verdi for sjekker. stationid: stasjonsnummer, den stasjonen som en tester. Her skal 0 bety at testen gjelder for alle stasjoner i tabellen station; se "OVERSIKT OVER stationid=0" nederst. qcx : Hva slags kontroll. Datatypen er her en streng. Beskrivelsen er gitt i eget dokument. Eks. for tester for QC1-2 så benytter vi QC1-2 som prefiks i dette feltet. Vi kan slik fullstendig identifisere kontrollen i forhold til det som er i dokumentet, slik som qc1-2-311a. medium_qcx: Kontrolltype, f.eks. 'QC1-1', 'QC1-2'. Avgjør hvilket av kontrollflaggene som sjekken oppdaterer. Jfr. tabellen qcx_info. language: er kode for språk slik som perlscript, C-kode. checkname: er navn på script lagret i tabellen algorithms. checksignature: realiseringen av signature i tabellen algorithms. Her er det vesentlig at det som bare er en variabel for parameterne i algorithms faktisk har et navn fra kolonnen name i tabellen param og at metadataene faktisk finnes med det navnet de har i tabellen station_param. Disse signaturene i checksignature er ofte autogenererte ved hjelp av en mal som parameterne fylles inn i, men ikke alltid. active: Defaultteksten '* * * * *' betyr at sjekken alltid skal kjøre når dataene kommer inn. Første asterisk angir minutt, andre time, tredje dag, fjerde måned, femte firesifret år. Komma kan angi flere forekomster. eks. 5,10 * * * * betyr at sjekken skal kjøres 5 og 10 minutter over hver time. fromtime: Tiden fra dataene for denne tabellen gjelder station_param. KILDE: METADATA, eksterne og våre egne. Denne tabellen har mange externe kilder, men kjernen i mottakssystemet forholder seg bare til filer. Det er 2 hovedmåter tabellen station_param mottar metadata på: 1) Automatisk, stort sett eksterne. Det mottas station_param metadata fra tegnseparerte filer der hver kolonne skal transformeres/leses inn som en rad i databasen. Filer på formatet stationid paramid tid + metadata eller bare paramid tid + metadata. For nærmere beskrivelse av dette og for "tid" jfr. dokumentet Dokumentasjon.dbQC.pl. Disse filene legges inn under station_param_auto. Det som kjennetegner disse filene er at de er verktøy/datamaskingenerert og representerer ikke punching fra mennesker. Disse filene er store, og har relativt enkel struktur. Det er ofte stasjonsavhengigheter i metadataene for disse filene, noe som gir store metadatamengder/store filer for station_param metadata. Metadataene i checkene er automatisk generert for disse filene og styres fra station_param og et template for checken som gjør at en får autogenerert hvilke parametere den gjelder for. 2) Manuell, våre egne. Manuell punching av station_param metadata i små filer som deretter leses inn i databasen ved hjelp av et script. De tilsvarende sjekkene i checks må også der som regel punches inn fordi de ofte er så kompliserte eller de gjelder for så få parametere at en templateløsning har liten hensikt. Under maskingenererte filer har vi flere leverandører og foreløpig to: 1) Metadataene er beregnet ut fra hva som finnes i klimadatabasen. 2) Metadata er beregnet fra modellkjøringer og levert fra FoU-div. HVEM bruker tabellen: Kontrollmodulene BESKRIVELSE av tabellen: Metadata til sjekkene i tabellen checks. BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer, se tabellen station. Her skal 0 bety at metadataene gjelder for alle stasjoner; se "OVERSIKT OVER stationid=0" nederst. paramid: parameternummer, se tabellen param. level: se tabellen data. sensor: se tabellen data fromday: Fra og med hvilken dag i året metadataene gjelder today: Til og med hvilken dag i året metadataene gjelder hour: time på døgnet metadataene gjelder, -1 er default og det betyr at metadatene gjelder for alle timer i døgnet. qcx : Hva slags kontroll. Se tabellen checks. metadata: Informasjon som skal brukes til kontroll av observasjoner, vil være avhengig av både stasjon og parameter. Dette er formatet på metadataene til kvalobsdatabasen. Vi lagrer dataene i en tabell struktur der første linje uttrykker kolonnenavn og linjene under er rader til denne "tabellen". navn1; ...; navnm verdi11; ...; verdi1m .. .. verdin1; ...; verdinm En har her en databasestruktur og det er fort å endre metadataene dersom en har mange nedover som har samme struktur. Eksempel der tallverdiene er helt vilkårlige, bare laget for å illustrere strukturen på et filformat: høyde;max;min;frozen;dip 2;5;2;3;4 10;6;1;3;4 50;7;-10;5;7 no;step;me 2;5;2 10;6;1 50;7;1 desc_metadata: Beskrivelse av hva metadataene er for noe. fromtime: Tiden fra dataene for denne raden gjelder. algorithms KILDE: METADATA, våre egne. HVEM bruker tabellen: QABase BESKRIVELSE av tabellen: lagrer skript, dette er en skripttabell. Det er nødvendig å ha denne tabellen i tillegg til checks fordi vi blant annet har situasjoner der samme algoritme er benyttet for flere sjekker. BESKRIVELSE av attributtene i tabellen: language: er kode for skriptspråk. language = 1 tilsvarer perlskript. checkname: er navn på skriptet. signature: signaturen til parametere, metadata og variabelnavn som en trenger til scriptet. Antall parametere for tester med flere parametere finnes her. Antall stasjoner for tester med flere stasjoner finnes her. Numeriske modell-verdier er pseudodata som behandles tilsvarende som for data. script: koden for skriptet. reference_station KILDE: METADATA, våre egne HVEM bruker tabellen: Den brukes av det scriptet som skal preprosessere kolonnene til checks. BESKRIVELSE av tabellen: BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer, dette er stasjonen det skal tas referanser i forhold til paramsetid: Dette er en gruppe parametere som er definert i tabellen paramset. reference: kommaseparert liste av stationid for referansestasjonene. timecontrol KILDE: METADATA, våre egne. HVEM bruker tabellen: Den som kontrollerer arbeidet. BESKRIVELSE av tabellen: Denne tabellen er foreløpig bare for QC2 tester. Denne tabellen er for tidskontroll for når testene skal kjøres. Det som skjer er at en gang i timen så sjekker datamaskinen om noen tester skal kjøres. Dersom en får tilbake noe fra spørring til fromday, today og time så kjører en den med høyest prioritet. En får en bedre ytelse dersom testene lastes inn en gang i døgnet fra databasen til programmet. BESKRIVELSE av attributtene i tabellen: fromday: Fra og med hvilken dag i året testen gjelder today: Til og med hvilken dag i året testen gjelder time: Hele time for når testen skal kjøres priority: Prioritering av rekkefølge for når testene skal kjøres; laveste tall har høyest prioritet. Vi begynner å telle fra og med 1 og oppover. qcx: Hva slags kontrolltype, se tabellen checks. obs_pgm KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: QABases modul for manglende observasjoner BESKRIVELSE av tabellen: Denne tabellen er observasjonsprogrammet for stasjoner som observerer ved hele timer (minutt=00). Observasjonsprogrammet styrer når en parameter observert på en stasjon skal kontrolleres. Ikke alle parametere blir observert for alle terminer. En stasjon (observatør) trenger heller ikke å observere for alle terminer. obs_pgm tabellen angir når en parameter blir observert og brukes for å finne ut om en observasjon mangler. En observasjon mangler når en kombinasjon av stationid, paramid, level og sensor ikke finnes. Da setter en inn en verdi fra obs_pgm for typeid. Dersom en kombinasjon av stationid, paramid, level og sensor ikke finnes så velger en ut verdien for typeid i obs_pgm som verdien for denne manglende observasjonens typeid. BESKRIVELSE av attributtene i tabellen: stationid: stasjonsnummer, se tabellen station. paramid: parameternummer, se tabellen param. level: Nivå der samme parameter observeres i ulik høyde eller dybde, se tabellen data. nr_sensor: antall sensorer for en gitt kombinasjon av paramid, stationid og level (for en gitt fromtime). Siden sensor bare er et tall med verdi fra 0 til 9 så angir nr_sensor forventede verdier for sensor i tabellen data. Hvis f.eks. nr_sensor har verdien 3, så har stasjonen 3 sensorer numerert 0, 1, og 2. Hva disse tallene betyr er ikke definert i kvalobs. typeid: prioritert typeid som settes inn når noe mangler, se tabellen types. collector: Observasjonen kan komme til ulike tider, men er ikke påkrevet. Operasjonelt så betyr dette at hvis collector er sann så trenger en ikke sjekke innsamlingstidspunkt, det er alltid OK. kl00 - kl23: Observasjonstidspunkt. mon - son: Observasjonsdag. fromtime: Tiden fra dataene i denne raden gjelder operator KILDE: METADATA, våre egne - username skal stemme med ldap-brulernavnet HVEM bruker tabellen: hqc BESKRIVELSE av tabellen: Holder rede på sammenhengen mellom username og userid, inneholder hvilke hqc operatører som har lov til å justere data og sette flagg. username: Brukernavnet til hqc-operatøren slik det er gitt i LDAP serveren. userid: en id til brukernavnet, integer. qcx_info KILDE: METADATA, våre egne. HVEM bruker tabellen: QABase HVEM opdaterer tabellen: Den samme som oppdaterer flaggene, og er ansvarlig for flaggsetting i QABase. BESKRIVELSE av tabellen: Holder rede på sammenhengen mellom kontroller på overordnet nivå medium_qcx: 'QC1-1', 'QC1-2' osv. main_qcx: 'QC1', 'QC2d', 'QC2m', 'HQC' controlpart: Hvilken del av controlinfo i tabellen data som blir oppdatert (0-15). comment: beskrivelse av sjekken. key_val KILDE: INTERN HVEM bruker tabellen: runtimesystemet BESKRIVELSE av tabellen: Hjelpetabell som brukes av runtimesystemet, ingen mennesker skal putte noe inn her. Jfr. systemdokumentasjonen. BESKRIVELSE av attributtene i tabellen: package: namespace for å beskrive område/modul og er en del av nøkkelen, package brukes for å lagre namespace. Et eksempel her er at alle nøkler for 'manageren' kan ha package 'kvManagerd'. key's som er gyldig for alle modulene kan ha package 'kvalobs'. key: nøkkel sammen med package, en må oppfatte key som en subnøkkel for en gitt package value: verdi for en vilkårlig key. stationid_klima KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: Hele Meteorologisk institutt, deriblant kvalobs. BESKRIVELSE av tabellen: Denne tabellen brukes til å finne sammenhengen mellom koden for en stasjon i klimadatabasen og i kvalobs. stationid: stasjonsnummer, se tabellen station. klima: klimadatabasens gamle system for utenlandske stasjoner klop: klimadatabasens nye system for utenlandske stasjoner param_feltfil KILDE: METADATA, fra ST_INFO_SYS. HVEM bruker tabellen: Hele Meteorologisk institutt, deriblant kvalobs. BESKRIVELSE av tabellen: Denne tabellen brukes til å finne sammenhengen mellom koden for en parameter i en feltfil og i kvalobs. paramid: parameternummer, se tabellen param. level: Nivå der samme fysiske parameter observeres i ulik høyde eller dybde målt i meter. For værkoder derimot er dette en tidsparameter som har en ubestemt verdi innenfor et bestemt tidsintervall. feltfil_paramid: dette er en kode som er paramid for parameteren feltfil_vertical_coordinate: dette sier noe om hvilken type vertikal koordinat vi har. feltfil_level1: dette er høyde nivået for parameteren. feltfil_level2: dette er høyde nivå parameteren i de tilfellene parameteren beskriver et område mellom to høydeflater. paramset Informasjonen om innholdet skal ligge i script.create_doc; det skal lages en egen fil som vil fungere som bibliotek, denne filen ligger i /kvalobs/src/lib/kvalobs/ paramset er ikke lenger noen tabell, derimot er det et bibliotek Biblioteket brukes for å gruppere parametere. paramid: parameternummer, se tabellen param. paramsetid: en id for en gruppe av parametere, rader med felles paramsetid tilhører samme gruppe. Kategoriseringer om sammenhengen paramid og paramsetid sortert etter paramsetid: INGEN INFORMASJON ER FORELØPIG SATT INN OVERSIKT OVER stationid=0. Mange tabeller som har stationid kan ha denne lik 0. Disse tabellene er: checks station_param I tabellen obs_pgm kan ikke stationid være 0. Så hva betyr det at stationid=0 i checks og station_param? Jo, det betyr at en henviser til en annen tabell for å vise hvilke stasjoner som sjekken gjelder for. Tabellen checks henviser til station_param og tabellen station_param henviser til tabellen obs_pgm. Dette gir følgende rekkefølge i programmet under runtime: 1) En slår opp i tabellen checks for å finne ut hvilke tester som skal kjøres, og hvilke metadata de trenger og hvilke stasjoner de skal kjøres for. stationid=0 betyr her at hvilke stasjoner sjekken skal kjøres for styres fra station_param. Dersom stationid er forskjellig fra 0 i checks så er det checks som styrer hvilke stasjoner som sjekken skal kjøres for. Hva skjer dersom en både har stationid = 0 og stationid <> 0 for samme qcx i tabellen checks? 2) Etter å ha slått opp i checks så slår en opp i tabellen station_param. Dersom stationid er forskjellig fra 0 i station_param så er det station_param som styrer hvilke sjekker som skal kjøres. Dersom stationid=0 i station_param så må en slå opp i tabellen obs_pgm for å se hvilke stasjoner sjekken skal kjøre for. Men en står overfor samme problemstilling i station_param som den en hadde for checks: Hva skjer dersom en både har stationid = 0 og stationid <> 0 for samme qcx i tabellen station_param? Det valget som er gjort er følgende: En spesifikk stationid har forrang for stationid=0; Først kjøres alle sjekker med spesifikk stationid, deretter blir de stasjonene som ikke har noen spesifikk stationid styrt av stationid=0. For station_param betyr det at disse henvises til og styres av obs_pgm. Spesifikk stationid betyr en stationid forskjellig fra null.