1. Hensikten med kurset - Lars Marius Garshol

1. Hensikten med kurset
1.1 Hva er Microsoft Access?
Innføring i databaser
Som det står på manualer og disketter er Access en “relasjonsdatabase for Windows”. Det sier
kanskje ikke de fleste så veldig mye, men det det egentlig betyr er at Access er en spesiell form
for utviklingsverktøy. Access er altså ikke et program som kan brukes til noe nyttig direkte,
slik som tekstbehandlere, regneark og annet. Det man gjør med Access er å lage nyttige
programmer.
1.2 Hva er et dataprogram?
Ifølge Aschehoug og Gyldendals Store Norske Leksikon er det noe som “foreskriver i detalj de
operasjoner som skal foretas av maskinen, og forutsettes utført i alt vesentlig uten menneskelig
inngripen underveis”. Det er forsåvidt korrekt, men kanskje ikke så veldig opplysende.
Poenget er at en datamaskin kan brukes til svært mye forskjellig, forutsatt at man har et
program som forteller maskinen hvordan det skal gjøres. Uten programmer får man ikke gjort
noe som helst på maskinen, fordi den ikke vet hva den skal gjøre. Alle programmer består av
enkle instruksjoner som datamaskinen utfører en for en. Så uansett hva slags programmer du
vil lage må de til syvende og sist oversettes til slike instruksjoner.
1.3 Forskjellige typer dataprogrammer
Her har jeg bare nevnt de viktigste og vanligste typene dataprogrammer. Det finnes utallige
andre typer, men dette er de som er mest brukt i kontorsammenheng.
• Tekstbehandlere
Dette er programmer som lar deg skrive brev, rapporter, bøker, skjemaer og mye annet.
Typiske eksempler: MS Word, AmiPro, WordStar, Emacs, WordPerfect.
• Regneark
Programmer som først og fremst er ment brukt til beregninger, for eksempel matematiske
modeller, regnskap og lignende. De har etterhvert blitt mer avanserte, og man kan lage
enkle databaser i dem. Eksempler: MS Excel, Quattro, Lotus 1-2-3, SuperCalc.
• Tegneprogrammer/bildebehandlere
Her er det mange varianter, men alle går ut på å lage bilder og diagrammer i forskjellige
varianter. Eksempler: CorelDraw, Micrografx Designer, Adobe Illustrator, QuarkXpress og
PhotoShop.
• Databaseverktøy
Dette er, som nevnt ovenfor, programmer du kan bruke til å utvikle andre programmer. De
finnes i mange forskjellige typer, som vi gjennomgår senere. Felles for dem er at de bare kan
1096 - Lars Marius Garshol 2

Innføring i databaser
lage arkivsystemer: dvs programmer som lagrer store datamengder, og kan utføre søk i
disse og trekke statistikk ut av dataene. Eksempler: MS Access, DataEase, dBase III,
FoxPro, Clipper, SyBase, Ingres, Oracle, FileMaker Pro, PowerBuilder, Paradox og mange
flere.
• Spesialutviklede systemer
Dette er programmer som er spesialutviklet for et bestemt, snevert formål. Ofte er de
spesiallaget for en bestemt bedrift. Typiske eksempler er utlånsregister for bibliotek,
AGR/Us soldatdatabase, lagersystemer. Siden programmene er beregnet for mer
spesialiserte formål har de sjelden særlig stor utbredelse.
Så er spørsmålet: hvilke av disse typene programmer kan vi lage med MS Access? Svaret er:
bare den siste typen. Vi kan lage alle mulige former for arkivsystemer, men ikke så veldig mye
annet.
Grunnen til at bedrift (eller en enkeltperson) kan ønske å gjøre dette er enkel. Man vil ha
datamaskinen til å hjelpe en med å utføre en (eller flere) oppgaver, men kan ikke finne et
program som er passende. Løsningen er da enkel, man lager et selv.
Det er dette dere skal lære på dette kurset: Hvordan utvikle enkle arkivsystemer ved hjelp av
MS Access. Tanken er at dere også skal ha så god forståelse av relasjonsdatabaser generelt at
dere lett kan lære dere andre slike systemer på egenhånd
1.4 Hvordan bruke kursheftet
Hensikten fra min side med dette kursheftet er at det skal kunne utfylle undervisningen i timene
slik at dere kan gå tilbake og lese på ting dere ikke fikk med dere i timene. Det er også
hensikten at dere skal ha noe dere kan ta med dere videre og bruke senere. Derfor kan det
lønne seg å notere i heftet.
I avsnitt 14.1 er det en ordliste som kan være grei å ha når du møter uttrykk i teksten som du
ikke kjenner.
Å lese før timene anbefales. Det er ikke nødvendig å forstå alt på forhånd, men det kan være
lurt å ha sett over det.
Når du jobber med oppgaver vil jeg anbefale at du bruker heftet til å slå opp i når det er ting du
er usikker på. Tommelfingerreglene er ment å brukes til å hjelpe deg når du løser oppgaver.
1.5 Konvensjoner
Tastetrykk skrives i dette heftet som f.eks. Alt+F4, som betyr: hold nede Alt mens du trykker
F4.
Beskjeder som "velg Vis | Skjemadesign" betyr velg valget Skjemadesign i Vis-menyen.
1096 - Lars Marius Garshol 3

1.6 Kommentarer
Innføring i databaser
Dette kursheftet er på ingen måte perfekt, ei heller kursopplegget. Jeg tar derfor gjerne imot
både kritikk og forslag om forbedringer og endringer.
1096 - Lars Marius Garshol 4

Innholdsfortegnelse
Innføring i databaser
1. HENSIKTEN MED KURSET..................................................................................................... 2
1.1 HVA ER MICROSOFT ACCESS?........................................................................................................ 2
1.2 HVA ER ET DATAPROGRAM?........................................................................................................... 2
1.3 FORSKJELLIGE TYPER DATAPROGRAMMER ...................................................................................... 2
1.4 HVORDAN BRUKE KURSHEFTET ...................................................................................................... 3
1.5 KONVENSJONER............................................................................................................................ 3
1.6 KOMMENTARER ............................................................................................................................ 4
2. PROGRAMUTVIKLING............................................................................................................ 8
2.1 ET PROGRAMS LIVSSYKLUS ............................................................................................................ 8
2.2 ET PROGRAMS EGENSKAPER..........................................................................................................10
2.3 PROGRAMUTVIKLINGSVERKTØY....................................................................................................10
2.4 GODT DESIGN ..............................................................................................................................11
3. OVERGANGEN FRA IDÉ TIL DATABASE............................................................................12
3.1 HVA ER EN DATABASE? OM STRUKTURERING AV INFORMASJON ......................................................12
3.2 DATAMODELLERING.....................................................................................................................12
3.3 ET ENKELT SPESIFIKASJONSSPRÅK: ER-LIGHT................................................................................13
3.4 FORHOLD.....................................................................................................................................14
3.5 HVORDAN LAGE EN DATAMODELL.................................................................................................14
3.6 TOMMELFINGERREGLER FOR DATAMODELLERING ..........................................................................16
4. RELASJONSDATABASER .......................................................................................................18
4.1 OPPBYGNINGEN AV EN RELASJONSDATABASE.................................................................................18
4.2 FLERE TABELLER - RELASJONER....................................................................................................18
4.3 NORMALISERING..........................................................................................................................19
4.4 TOMMELFINGERREGLER FOR NORMALISERING ...............................................................................20
4.5 SPØRRINGER, SKJEMAER OG RAPPORTER........................................................................................20
4.6 OPPBYGNINGEN AV DATABASER....................................................................................................20
4.7 REFERANSEINTEGRITET ................................................................................................................21
4.8 SQL OG BASIC...........................................................................................................................21
5. ACCESS’ OPPBYGNING OG VIRKEMÅTE ..........................................................................23
5.1 ACCESS SETT I FORHOLD TIL ALTERNATIVENE................................................................................23
5.2 GRENSESNITTET...........................................................................................................................23
5.3 PROGRAMMENES GRENSESNITT.....................................................................................................24
5.4 VEIVISERE ...................................................................................................................................24
5.5 HVORDAN NAVIGERE I ACCESS......................................................................................................25
5.6 STANDARDTABELLEN...................................................................................................................25
6. TABELLER I ACCESS..............................................................................................................27
6.1 HVORDAN OPPRETTE EN TABELL ...................................................................................................27
6.2 FELTDEFINISJON...........................................................................................................................27
6.3 DATATYPER OG FELTEGENSKAPER.................................................................................................28
6.4 ENDRE FELT.................................................................................................................................30
6.5 PRIMÆRNØKKEL...........................................................................................................................30
6.6 FORHOLDENE...............................................................................................................................30
6.7 ET EKSEMPEL...............................................................................................................................31
6.8 SE PÅ OG SKRIVE INN DATA ...........................................................................................................32
1096 - Lars Marius Garshol 5

Innføring i databaser
7. SPØRRINGER I ACCESS .........................................................................................................33
7.1 HVA ER EN SPØRRING?..................................................................................................................33
7.2 SPØRRINGER FRA EN TABELL.........................................................................................................33
7.2.1 Spørringer med alle poster ..................................................................................................33
7.2.2 Spørringer med bare noen av postene..................................................................................35
7.3 SPØRRINGER FRA FLERE TABELLER................................................................................................35
7.4 KOBLINGSEGENSKAPER ................................................................................................................36
7.5 BEREGNEDE FELT: AGGREGATFUNKSJONER OG UTTRYKK...............................................................37
7.5.1 Uttrykk generelt...................................................................................................................37
7.5.2 Uttrykk i de forskjellige typene............................................................................................37
7.5.3 Aggregatfunksjoner .............................................................................................................38
7.5.4 Gruppering..........................................................................................................................39
7.6 DATAMANIPULASJON MED SPØRRINGER.........................................................................................41
8. OPPBYGNING AV GRENSESNITT I WINDOWS..................................................................42
8.1 SKJEMATYPER OG DERES REKKEFØLGE ..........................................................................................42
8.1.1 Hovedmeny..........................................................................................................................42
8.1.2 Velg post-skjemaet...............................................................................................................42
8.1.3 Endre data-skjemaet............................................................................................................43
8.2 HVORDAN LAGE ET GRENSESNITT..................................................................................................43
8.3 TOMMELFINGERREGLER FOR SKJEMAER.........................................................................................43
8.4 SMÅTIPS ......................................................................................................................................44
9. SKJEMAER I ACCESS: BAKGRUNN.....................................................................................45
9.1 HVA ER ET SKJEMA?......................................................................................................................45
9.2 HVA BESTÅR ET SKJEMA AV?.........................................................................................................45
9.3 SKJEMAETS DELER........................................................................................................................46
9.4 SKJEMAVEIVISERNE......................................................................................................................46
9.5 JOBBE MED KONTROLLER..............................................................................................................47
9.5.1 Hvordan velge kontroller.....................................................................................................48
9.5.2 Egenskaper..........................................................................................................................48
10. SKJEMAER I ACCESS: DETALJENE...................................................................................49
10.1 HVORDAN KONTROLLENE FUNGERER...........................................................................................49
10.1.1 Hendelser..........................................................................................................................49
10.1.2 Tekstbokser........................................................................................................................49
10.1.3 Kombinasjons- og listebokser ............................................................................................49
10.1.4 Knapper ............................................................................................................................49
10.2 VIKTIGE EGENSKAPER VED KONTROLLER .....................................................................................50
10.3 HVORDAN LAGE EN KOMBINASJONSBOKS.....................................................................................50
10.4 HVORDAN BYGGE OPP ET SKJEMA................................................................................................51
10.4.1 Endre data-skjema.............................................................................................................51
10.4.2 Velg post-skjema................................................................................................................53
10.4.3 Hovedmeny-skjemaet.........................................................................................................55
10.4.4 Skjema med underskjema...................................................................................................56
11. RAPPORTER I ACCESS .........................................................................................................58
11.1 SKJEMAER/RAPPORTER - FORSKJELLER OG LIKHETER....................................................................58
11.2 HVORDAN LAGE RAPPORTER .......................................................................................................58
11.3 ET ENKELT EKSEMPEL.................................................................................................................59
11.4 HVORDAN BRUKE EN RAPPORT ....................................................................................................59
11.5 RAPPORTVEIVISERNE..................................................................................................................59
11.6 RAPPORTER MED GRUPPERING.....................................................................................................60
11.6.1 Hva er gruppering, og hvorfor bruke det? .........................................................................60
11.6.2 Grupperingsveiviseren.......................................................................................................61
11.6.3 Bruk av inndelingene.........................................................................................................61
1096 - Lars Marius Garshol 6

Innføring i databaser
11.6.4 Sideinndeling.....................................................................................................................63
11.6.5 Gruppering- og sorteringsinnstillingene ............................................................................63
11.7 AGGREGATFUNKSJONER .............................................................................................................63
12. FULLSTENDIGE APPLIKASJONER I ACCESS ..................................................................65
12.1 SELVSTARTENDE DATABASER .....................................................................................................65
12.2 FEILSJEKKING ............................................................................................................................65
12.3 LAGE IKON FOR DATABASEN I PROGRAMBEHANDLING ..................................................................65
12.4 SIKKERHET ................................................................................................................................66
12.5 DATABASER I NETTVERK.............................................................................................................66
12.6 DISTRIBUSJON AV DET FERDIGE PROGRAMMET .............................................................................66
13. VEIEN VIDERE .......................................................................................................................67
13.1 HVORDAN LÆRE MER..................................................................................................................67
13.2 PROGRAMUTVIKLING PÅ EGENHÅND............................................................................................67
14. TILLEGG..................................................................................................................................68
14.1 ORDLISTE ..................................................................................................................................68
14.2 VANLIGE KOMMANDOER.............................................................................................................70
14.3 VANLIGE FEIL ............................................................................................................................71
14.4 LITTERATUR ..............................................................................................................................71
14.5 TAKK TIL ...................................................................................................................................71
1096 - Lars Marius Garshol 7

2. Programutvikling
2.1 Et programs livssyklus
Innføring i databaser
Å utvikle et programsystem er på ingen måte enkelt, og jo større programmet skal være jo
vanskeligere blir det. Det forskes mye på hvordan dette bør gjøres, og det kan være lurt å
bruke litt tid på dette før vi går videre. Egentlig kan det hele oppsummeres i en setning: Tenk
deg om før du gjør noe! Dette kan kanskje høres ut som mas, men hvis du har tenkt å bruke
Access (eller et annet utviklingsverktøy) til noe seriøst bør du følge nøye med.
Som regel når du utvikler et program er det tre aktører involvert. Det er deg selv (utvikler),
den som er oppdragsgiver og bestemmer hvordan programmet skal bli (oppdragsgiver) og de
som skal bruke sluttresultatet (brukerne). Alle disse har hver sine ønsker og behov, og disse er
ikke alltid forenlige med hverandre, og programutvikling kan fort bli en balansegang mellom
disse behovene. Et annet problem er at det kan være vanskelig å forstå hva oppdragsgiver vil
og det behøver ikke nødvendigvis være hva brukerne trenger osv. Derfor kan det fort bli en del
omarbeiding av det man trodde var ferdig, og dette gjør at planlegging blir veldig viktig.
Derfor har jeg tatt med en oversikt over hvordan programutvikling vanligvis forløper, og
hvordan det er vanlig å dele prosessen inn i faser.
• Behov
Her starter det hele. Ofte finner bedriften ut at bestemte arbeidsoppgaver er svært
tidkrevende og rutinepreget, og man ønsker seg et dataprogram som kan løse disse
oppgavene. Men like ofte er visjonene bredere og mer uklare (typisk for mange
bedriftsledere har vært at de ønsker å få hele bedriften inn på data, “information at your
fingertips”), og det er særlig da neste stadium er viktig. Som regel vil det vise at noen av de
planlagte delene er enklere å gjøre på andre måter, og litt sunn skepsis til at absolutt alt må
gjøres på data kan også lønne seg.
• Analyse
Man finner ut at man trenger et program, og bestemmer seg for å lage det. Problemet er:
oppdragsgiver er sjelden helt sikker på akkurat hva det er som trengs. Dette kan det ofte
være svært vanskelig å finne ut av, og resultatet kan fort bli mye fram og tilbake uten at man
får fastlåst en endelig versjon av programmet. Brukerne er sjelden de som lager det, og
dette kan skape problemer fordi det kan være vanskelig å garantere at utvikleren lager det
programmet brukeren vil ha.
• Design
1096 - Lars Marius Garshol 8

Innføring i databaser
Når man har kommet så langt vet man hva som trengs, og begynner å planlegge hvordan
dette skal løses på datamaskinen. Tar man de gale avgjørelsene her kan det koste svært mye
tid og krefter senere.
• Implementasjon
Så er alt klart. Man vet hva man skal ha, og hvordan det skal lages. Da gjenstår bare å lage
det. Denne delen betraktes ofte som 100% (eller 90%) av jobben; men det er feil!
• Feilsjekking
Så fort programmet komplett og har alt det skal tror man ofte at det er ferdig. Det er feil
(igjen). Programmet vil nå inneholde feil. Alle programmer (unntatt de aller minste og
enkleste) har feil. Det gjelder også både Windows og Access.
• Bruk
Etterhvert tas programmet i bruk, selv om det sannsynligvis gjenstår feil. Alle programmer
som er store nok til å være nyttige inneholder feil. (Det er vanlig under utviklingen av store
programsystemer å utgi programmet når antall feilrapporter pr uke har kommet ned i et
passelig tall.)
• Nye behov
Men selv når programmet er tatt i bruk og alle feil fjernet er ikke programmererens oppgave
over. Svært ofte finner man ut at ‘det hadde jo vært fint om programmet også kunne gjøre
sånn og sånn’ eller ‘det var ikke slik det skulle være’ eller oppgavene programmet skal
utføre endres. Da må man til med ny analyse, nytt design og så endre implementasjonen
(systemet), sjekke feil osv nok en gang.
I praksis vil man ikke kjøre gjennom hele denne sekvensen, ihvertfall ikke så grundig som det
er beskrevet her, når man skal lage mindre/middels programmer. Ved større seriøse
programmeringsprosjekter er det utenkelig å ikke kjøre gjennom et nøye planlagt program for
utviklingen. Programutvikling (også kalt software engineering) er altfor vanskelig og dyrt til at
man tør å gjøre noe annet. Det er alt for mange eksempler på utviklingsprosjekter som har
trukket ut i det uendelige uten å komme noen vei. Her hjemmefra kan vi jo nevne
Rikstrygdeverkets TRS’90-system (som et av mange), og også i resten av verden er problemet
velkjent.
Det lønner seg å hele tiden ha i tankene at programmet du lager kan komme til å leve lenge.
Mange av programmene som brukes idag (særlig større administrasjonsprogrammer hos banker
og i offentlig forvaltning) har vært ibruk siden slutten av 60-tallet. Det er ikke uvanlig at
programmer overlever sin utvikler i en bedrift, slik at andre må jobbe videre med det du har
utviklet. Det er da det er viktig at man hadde et godt gjennomtenkt design i begynnelsen.
Dette kan kanskje høres ut som overdrevent mas om å “være grundig og nøyaktig blablabla”,
og så lenge du bare lager programmer for deg selv er det det, men i det øyeblikk andre
mennesker blir involvert som brukere/utviklere blir det svært viktig.
1096 - Lars Marius Garshol 9

2.2 Et programs egenskaper
Innføring i databaser
Når man skal vurdere om et program er godt eller dårlig er det mange egenskaper som spiller
inn. Ofte er det slik at forbedring av en egenskap lett fører til forverring av en annen. Det
perfekte program er dermed temmelig uoppnåelig.
• Hastighet - at programmet er raskt, brukeren slipper å vente
• Enkelt å endre - at programmet lett kan tilpasses nye behov/rutiner
• Ressursbruk - at programmet bruker lite minne, diskplass etc.
• Utviklingstid - at programmet kan lages på kort tid (koster mindre da)
• Dekker behovet til brukeren - mao: det gjør alt det brukeren ønsker
• Brukervennlig - lett å lære, enkelt å bruke, ikke masse unødvendig tasting
En svært viktig egenskap for utvikleren er at programmet er enkelt å endre. Det høres kanskje
ikke så vanskelig ut, men krever svært mye av programmets oppbygning. Det krever at
programmet er konsekvent og elegant laget. Dette å oppnå konsekvens og eleganse er svært
vanskelig, og krever trening og disiplin. Å programmere er om ikke en kunst så er det i det
minste solid håndtverk. ‘Software engineering’, som det kalles, er i dag et stort forskningsfelt
av den enkle grunn at dårlig programmeringsstyring har kostet litt for mange milliarder.
2.3 Programutviklingsverktøy
En typisk del av analysen vil være å velge utviklingsverktøy, og her er Access kun ett av
mange. Og databasesystemer er bare en av mange typer verktøy.
• Assembler
Assembler er (nesten) det samme som maskinkode. Her skriver man instruksjon for
instruksjon den koden maskinen kommer til å utføre. Og siden de fleste maskiner i dag
utfører millioner av instruksjoner pr sekund betyr dette at utviklingen blir ekstremt detaljert.
Programmene blir lange, og generelt er det svært vanskelig å skrive selv enkle programmer.
Det er også svært vanskelig å unngå feil.
Fordelen er at man kan få til absolutt hva som helst maskinen kan gjøre, og at programmene
blir svært raske.
• Programmeringsspråk
Programmeringsspråkene går et skritt videre. Man skriver programmet som tekst i et
formelt språk spesiallaget for dette. Deretter oversetter et spesielt program (kalt
kompilator) teksten til maskinkode. Dette gjør at koden blir kortere, man kan systematisere
programmet mye mer og utviklingen går raskere og enklere. Man får også typisk færre feil
enn om man skriver i assembler.
Ulempene er at programmene blir langsommere enn om man skriver i assembler, og at en
del ting ikke lar seg gjøre. Typisk er dette ting som bruk av fysisk utstyr som mus, tastatur,
scanner, printer osv.
Det finnes svært mange programmeringsspråk og de er inndelt i innbyrdes svært ulike
familier. Blant de mer vanlige er: C/C++, Ada, Pascal, Java, BASIC, LISP, Smalltalk, ML,
Perl og Prolog. Innen hvert enkelt språk igjen finnes en mengde dialekter. Særlig LISP og
BASIC har en hærskare av dialekter.
1096 - Lars Marius Garshol 10

Innføring i databaser
• ‘Visuelle’ programmeringsspråk
Dette er videreutviklinger av vanlige programmeringsspråk, der man kan ‘tegne’ deler av
programmet på skjermen (særlig brukergrensesnittet), og utviklingsverktøyet genererer så
koden for en. Dette forenkler mye av rutinetastingen man ellers måtte gjøre, og sparer både
tid og feil. Ulempen er at man ofte ikke lenger kan gjøre hva som helst, og at programmene
kan bli langsommere.
Eksempler på verktøy av denne typen er Borland Delphi (som bygger på Pascal) og
Microsoft Visual Basic (som bygger på BASIC).
• Fjerde-generasjons-verktøy
Her finnes en mengde forskjellige varianter, og databasesystemer er bare en av dem. Disse
er som regel basert på å utvikle systemer av en bestemt type, slik databasesystemer er ment
til utvikling av arkivprogrammer. Her er man med andre ord enda mer begrenset enn om
man bruker et programmeringsspråk, til gjengjeld blir det færre feil og utviklingen går
raskere. Systemene kan ofte bli vel så raske som om man hadde brukt et vanlig
programmeringspråk.
2.4 Godt design
Å lage et stort program med godt design er ikke enkelt, faktisk nærmest umulig. Å komme i
nærheten av et godt design krever talent, disiplin, mye arbeid, erfaring og iblant også flaks.
Merk at jeg sier stort. For mindre programmer er det langt enklere, og for de systemene vi går
løs på i dette kurset er det ingen stor sak å få det til.
En svært viktig del av et godt databasedesign er valget av tabeller og forhold. Gjør man et
dårlig valg her får man svi for det senere. Et annet viktig poeng er navnene: alle tabeller, felter,
spørringer osv må ha gode navn.
Her er noen små tommelfingerregler:
• Unngå dobbeltlagring! I en god database finnes ikke de samme dataene lagret to forskjellige
steder (enten det er tabeller eller felter.)
• Ikke legg for strenge begrensninger på bruken av systemet. Dersom det er noe du ikke har
tenkt på vil du bare provosere brukerne.
• Ikke gjør systemet for slapt, slik at det tillater ting som ikke burde vært tillatt. (Det er ikke
lett å kombinere dette med regelen ovenfor.)
• Et godt design mangler ingenting og har ingen overflødige deler. Dette er viktig: jo mindre
systemet er, jo bedre. Det blir enklere å endre, forstå og bruke. Pass bare på at det ikke blir
for lite...
• Pass på å ha tenkt gjennom så mye som mulig før du begynner. Når deler av et program
skrives om har det ekstra lett for å oppstå feil.
• Navn er svært viktige! Vær konsekvent og grundig i navngivingen din.
1096 - Lars Marius Garshol 11

3. Overgangen fra idé til database
3.1 Hva er en database? Om strukturering av informasjon
Innføring i databaser
Forskjellen på en database og et vanlig tekstdokument er at informasjonen i en database er
strukturert på en måte som maskinen forstår, mens den ikke forstår tekstdokumentet.
“Anne Tryti eier en Toyota MR2 som har registreringsnummer SP 83400. Hun bor i Dalveien
19, 1800 Askim og privattelefon 69882344. Bil nummer BN 26131 er en Nissan Bluebird eid
av Jarl Andresen, som bor i Nansensgt 69, 4601 Kristiansand og har telefon 38092483.”
Dette er klar tale for et menneske, men for en datamaskin er dette komplett uforståelig. En
database kan behandle informasjonen, organisere den og svare på spørsmål, mens et
tekstbehandlingssystem ikke kan gjøre noen av delene med et dokument. Dataene må med
andre ord organiseres og struktureres før en datamaskin kan ‘forstå’ dem.
Tabeller er løsningen man har brukt for å strukturere dataene i en relasjonsdatabase. Det finnes
andre måter å gjøre det på, men da har man ikke lenger med en relasjonsdatabase å gjøre.
Navn Gateadresse Sted/Postnummer Telefon Registreringsnr Merke
Anne Tryti Dalveien 19 1800 ASKIM 69882344 SP 83400 Toyota MR2
Jarl Andresen Nansensgt 69 4601 KRISTIANSAND 38092483 BN 26131 Nissan Bluebird
Tabell 3.1
Dette er den samme informasjonen, omorganisert til tabellform. Nå er det brått mulig å spørre
datamaskinen om “Hva heter alle som bor i Askim?” eller “Hvem eier bil nummer BN 26131?”
Den kan da i det første tilfellet gå gjennom alle radene i tabellen og for hver gang den finner
Askim i Sted/Postnummer-kolonnen skrive ut det den finner i Navn-kolonnen. Spørsmålet må
selvfølgelig stilles på en måte maskinen forstår, men det kommer vi tilbake til i kapittel 7.
Nå kan du kanskje gjette hva en database er: et system som lagrer informasjon på en
strukturert måte, og som kan la en bruker endre informasjonen og få ut informasjonen
strukturert på en annen måte. Brukeren skal også kunne stille spørsmål til databasen.
3.2 Datamodellering
Når man lager en database er man egentlig ute etter å lage en modell i en datamaskin av en
begrenset del av virkeligheten. I eksempelet ovenfor ville vi lage en modell av eierforholdene
for noen norske biler. Disse eierforholdene er ikke tilfeldig organisert, men styrt av noe vi
kaller ‘forretningsregler’. Disse sier slike ting som at ‘personer eier biler’, ‘en bil kan bare eies
av en person til enhver tid’, ‘en person kan eie flere biler samtidig’ osv.
Den største vanskeligheten med å utvikle databaser skulle nå være åpenbar: å finne ut
av forretningsreglene, og gjøre dem om til et sett med tabeller. Det er et problem til: nemlig å
finne forholdene mellom tabellene. (Hvis dette virker uklart kan du tyvlese litt i kapittel 4.) For
enkle databaser er dette stort sett barnemat når man har litt trening, men for store databaser er
1096 - Lars Marius Garshol 12

Innføring i databaser
det langt i fra selvsagt. Særlig kan det være vanskelig å få ordentlig klarhet i hvordan brukerne
av databasen egentlig vil ha dette.
Det finnes en teknikk for å håndtere disse problemene, nemlig datamodellering. Den er faktisk
svært nyttig i praksis, særlig ved utvikling av store og kompliserte databaser. Datamodellering
gjøres som regel ved å tegne, og til å støtte seg har man forskjellige ‘spesifikasjonsspråk’, som
er regler for hvordan forretningsreglene skal tegnes.
Det finnes en rekke spesifikasjonsspråk, fra de mer avanserte som NIAM til de svært enkle,
som ER. Vi skal ikke dekke noen av disse her, men jeg nevner dem så dere har hørt om dem.
NIAM er faktisk såpass avansert at det finnes databasesystemer som lar deg tegne et NIAMdiagram,
og så lager det tabellene og relasjonene for deg automatisk. Dette lar seg ikke
egentlig gjøre fra et ER-diagram, ettersom ER er mer et skissespråk. I dette kurset skal vi bare
bruke datamodellering til å tenke på papiret og kladde litt før vi lager ting, og trenger derfor
bare en forenklet utgave av ER. Den har jeg kalt ER-light.
3.3 Et enkelt spesifikasjonsspråk: ER-light
Noen av forretningsreglene i bil-eksempelet kan beskrives slik: “En bil har bare en eier. En
person kan eie flere biler. Biler har registreringsnummer og bilmerke. Personer har
gateadresser, postnummer/bosted og telefon.”
Datamodellering går ut på å finne typer av objekter (dette kan være gjenstander eller abstrakte
begreper) som vi er interessert i og disses egenskaper. Objektgruppene/typene kalles entiteter,
og deres egenskaper kalles attributter. I beskrivelsen ovenfor er modelleringen egentlig allerede
gjort. Det ligger mellom linjene at vi har to entiteter: personer og biler. Forholdet mellom dem
er gitt, og entitetenes attributter er klarlagt. (Entiteter og attributter er egentlig svært greie å
forstå, ikke la deg skremme av at ordene høres vanskelige ut.)
I ER-light tegnes dette slik:
Merke
Registreringsnummer
Bil
∞
Bil
1
Person
1096 - Lars Marius Garshol 13
Eier
Telefon

Innføring i databaser
Med andre ord tegnes entiteter med ring rundt, mens attributter må klare seg uten. Mellom Bil
og Person er det et forhold (representert ved en linje.) Ved linjen, inntil Bil står tegnet ∞, som
står for uendelig, og betyr at hver Person kan ha uendelig mange biler. Inntil Person står 1,
som betyr at hver Bil bare kan ha en Person. At Person’en er eier, og ikke tyv bryr vi oss ikke
om. (Dette kalles Person’s rolle.)
Å gjøre om fra datamodellen (dvs: tegningen) til tabeller og begrensningsregler er et tema for
seg, som kalles normalisering. Siden våre databaser blir såpass enkle skal vi ikke gå noe særlig
inn på dette her. (Mer om normalisering står i avsnitt 4.3.)
3.4 Forhold
Forholdene er kjernen i en relasjonsdatabase. De brukes til å organisere dataene og unngå
dobbeltlagring. Mange databasesystemer er mer primitive enn relasjonsdatabasene, fordi de
mangler forholdene. Som regel har de tabeller på samme måte som relasjonsdatabaser, men de
kan altså ikke kobles sammen med forhold. Problemet med dette er at forholdene som gjør
relasjonsdatabasene så kraftige.
Det finnes enda mer avanserte databasetyper, men vi skal ikke gå inn på disse her. Dette blant
annet fordi de aller fleste databasesystemer er relasjonsdatabaser (eller av den enklere typen jeg
nevnte). Mer om dette i avsnitt 5.1.
Forhold kan være av tre typer:
• En-til-en
Her er det slik at det til hver post i den ene tabellen svarer nøyaktig en post i den andre. Da
kan man som regel slå de to tabellene sammen, men ikke alltid, det kan være fornuftige
grunner til å holde dem adskilt.
• Mange-til-en (eller en-til-mange)
Dette er den vanligste typen forhold, og er helt grei å forholde seg til.
• Mange-til-mange
Mange-til-mange-forhold skal ikke forekomme i en database. De trenger seg iblant på, men
må da omgås ved at man lager en entitet mellom de to som har et innbyrdes mange-tilmange-forhold.
Begge de opprinnelige entitetene har et en-til-mange-forhold til den nye.
3.5 Hvordan lage en datamodell
Navn
Adresse
Spørsmålet blir nå: når man skal lage en datamodell, hvordan finner man frem til entitene og
deres attributter, og hvordan finner man forholdene mellom disse? Dette er egentlig et
1096 - Lars Marius Garshol 14

Innføring i databaser
spørsmål om kreativitet og intuisjon, og man kan ikke så lett lage tommelfingerregler for dette,
men et eksempel kan kanskje klargjøre.
Eksempel 3.1
“Du har tenkt å lage en database over alle dine plater og musikkassetter. Du vil registrere tittel,
artist, år, platetype (CD, LP etc.) og alle sanger på hver plate/kassett. For hver sang vil du
registrere tittel, varighet og hvem som gjør hva (dvs: hvem spiller gitar, hvem har produsert,
hvem har skrevet musikken osv.)”
Her har vi tre åpenbare typer objekter som vi vil registrere data om: plater/kassetter, sanger og
artister. Da kan vi begynne med å tegne disse som entiteter. Deretter kan vi sette på
attributtene som ble nevnt ovenfor, unntatt de som er knyttet til andre entiteter.
Da får vi denne modellen:
Tittel
År
Det som da mangler er at vi ikke har sagt noe om forholdene mellom de forskjellige entitetene.
Hvis vi tenker oss om er hver sang bare på en plate, mens en plate i teorien kan ha ubegrenset
mange sanger. Her dukker det opp et lite problem: hva mener vi egentlig med sang? Du kan jo
ha f.eks. både studioversjon og liveopptak av samme sang, og kanskje en coverlåt også? Er
hver av disse forskjellige sanger, eller har vi samme sang flere steder? Dette er et typisk
problem: hva mente den som ville ha databasen egentlig? Ofte vet de det ikke selv, eller, mer
presist, de forstår ikke forskjellen.
Den vanligste og greieste løsningen på problemer som akkurat dette er å si at hver versjon
regnes som separate sanger. (Den motsatte varianten gir deg litt flere muligheter, men er mer
tungvint.) Dermed sier vi at hver versjon av en sang er også innspilt av en (og bare en) artist,
mens hver artist kan ha spilt inn mange sanger.
Tittel
Spilt inn av Har spilt inn
Plate
∞
1
Artist
1096 - Lars Marius Garshol 15
År
Type
Type
Plate Artist
Sang
Tittel Varighet
Sang
Navn
Navn

Innføring i databaser
En plate er utgitt av en artist, men en artist kan utgi mange plater. Eller? Dersom vi tar
samleplater (som Absolute Music) med i betraktningen får vi et mange-til-mange-forhold, som
egentlig er beskrevet av sangene på platen. Her må man gjøre et valg, og de aller fleste vil nok
ende opp med å velge et en-til-mange-forhold mellom Plate og Artist. (Samleplater vil da være
utgitt f.eks. av Diverse artister.)
Det er ikke alltid slik at forretningsreglene alene gir deg de entitetene du trenger. Av og til må
du “jukse” ved å se framover til hvordan databasen vil bli for å få den mest praktiske løsningen.
Hvis du f.eks. vil at en av attributtene til en entitet bare skal kunne ha noen få forskjellige
verdier, f.eks. platetype: CD, LP, kassett, video, lønner det seg å ha en egen tabell for typene
og bruke et forhold til denne. Denne typetabellen vil da være en egen entitet i modellen.
3.6 Tommelfingerregler for datamodellering
1
Inneholder
∞
Utgitt på
• IKKE tenk på skjemaer og tabeller når du modellerer, det kommer senere. Tenk på hva som
hører sammen med hva.
• Begynn med å lage så mange entiteter som mulig. Lag en til hvert begrep som forekommer i
databasebeskrivelsen.
• Fortsett med de mest opplagte attributtene og plasser dem.
• Så kan du begynne å plassere forhold og attributter, og opprette nye entiteter for å få dem
til å passe inn.
• Unngå å velge primærnøkler som kan endre seg.
• Unngå lange primærnøkler.
• Attributter som kan beregnes ut ifra de andre attributtene legges ikke inn i entitetene, men
hører hjemme i spørringene.
• Til slutt må du tenke over om noen entiteter skal fjernes. Kanskje førte du opp noen som
ikke var interessante i vår database likevel.
• En entitet skal være et begrep, noe som det finnes flere ‘instanser’ av i virkeligheten.
Bilnummer er ikke et begrep, men bil er.
• Før du plasserer forhold, tenk gjennom hvorfor du vil ha forholdet der. Det betyr at det skal
registreres data som kobler sammen to instanser av hver entitet. Poenget er at du må vite
hva disse dataene betyr. Eksempel: Har personen lånt bilen, kjøpt den, stjålet den, solgt den
eller hva er det vi registrerer som lager et forhold mellom person og bil?
• Vær nøye med navnene på både entiteter og attributter. Tenk gjennom dem.
• Attributtene til en entitet skal gjelde ett emne, ikke flere.
1096 - Lars Marius Garshol 16

Innføring i databaser
• Dersom flere entiteter har mange felter til felles bør du vurdere å slå dem sammen.
• En entitet som ikke har attributter er kanskje overflødig.
• Attributter som bare kan ha noen få verdier og som du vil gruppere/søke på bør gjøres til
entiteter.
• En attributt som viser til en annen entitet (som identifiserer en instans tilhørende en annen
entitet (eller samme)) skal gjøres om til et forhold.
1096 - Lars Marius Garshol 17

4. Relasjonsdatabaser
4.1 Oppbygningen av en relasjonsdatabase
Innføring i databaser
Hjertet i alle relasjonsdatabaser er tabellene, som er der alle data lagres. En tabell består av en
rekke felter og poster, der postene er dataelementene, mens feltene er det postene består av.
Sagt på en annen måte utgjør feltene definisjonen av tabellen, mens postene er innholdet.
Registreringsnummer Merke Eier
SP 83400 Toyota MR2 Anne Tryti
BN 26131 Nissan Bluebird Jarl Andresen
DE 66477 Opel Kadett Hans Hansen
Tabell 4.1
I dette eksempelet er ‘Registreringsnummer’, ‘Merke’ og ‘Eier’ feltene, mens ‘SP 83400’,
‘Toyota MR2’ og ‘Anne Hansen’ er en post. For å si det på en annen måte er et felt en kolonne
mens en post er en rad i tabellen. (De engelske begrepene er ‘field’ og ‘record’.) Du kan tenke
deg en post som et arkivkort, men husk at det er en forenkling, for i relasjonsdatabaser kan vi
koble flere poster sammen.
Som regel ønsker vi å legge begrensninger på hva som kan stå i et felt. I feltet ‘Eier’ er vi for
eksempel bare interessert i å ha navn, men det kan vi ikke fortelle maskinen på noen enkel
måte. (Den kan ikke forstå at ingen heter ‘Rtwerwq Hasdjksk’.) Det vi kan fortelle den er at
feltet skal inneholde tekst, og ikke mer enn 40 tegn.
Det er også mulig å legge inn andre former for begrensning. For eksempel kan ikke flere biler
ha samme registreringsnummer, dermed sier vi at feltet skal bare ha unike verdier. Vi vil også
typisk bruke registreringsnummer for å vise til/identifisere bestemte biler, og siden feltet er
unikt vil dette alltid fungere. (Alle biler har et registreringsnummer og det finnes ikke to
forskjellige biler med samme nummer.)
Alle tabeller bør ha noe som kalles en primærnøkkel. Primærnøkkelen er ett (eller flere) felt
som må fylles ut for alle poster og som har unike verdier (er det f.eks. to felter må ingen poster
kunne ha like verdier i begge.) Primærnøkkelen brukes til å henvise til bestemte poster og er
en svært viktig egenskap ved en tabell.
I eksempelet overfor er det bare ‘Registreringsnummer’ som har unike verdier. (Felter som har
unike verdier kalles ofte for kandidatnøkler, fordi de er kandidater til å være primærnøkler.)
Siden ‘Registreringsnummer’ er eneste kandidatnøkkel er den også eneste mulige
primærnøkkel.
4.2 Flere tabeller - relasjoner
Så lenge man kun har enkeltstående tabeller er det trivielt å lage databaser, men idet øyeblikk
dataene i flere forskjellige tabeller skal forbindes med hverandre blir ting komplisert. For
eksempel kan vi tenke oss at vi vil lagre data om eierne av bilene, for eksempel telefonnummer
og adresse. Problemet blir da at hvis en person eier flere biler må vi lagre vedkommendes
telefonnummer og adresse en gang for hver bil. Det er ikke særlig elegant og skaper også
1096 - Lars Marius Garshol 18

Innføring i databaser
problemer når personen flytter, fordi vi da må oppdatere de samme dataene flere ganger. (Det
er som regel slik i programutvikling at det som ikke er elegant heller ikke er lurt.)
Dette problemet lar seg løse om vi lager en tabell til for personer:
Navn Gateadresse Postnummer Sted Telefon
Anne Tryti Dalveien 19 1800 ASKIM 69882344
Jarl Andresen Nansensgt 69 4601 KRISTIANSAND 38092483
Hans Hansen Hanseveien 0316
Tabell 4.2
OSLO 22448482
Problemet blir her at ‘Navn’ ikke er egnet som primærnøkkel siden vi godt kan tenke oss at det
finnes flere ‘Hans Hansen’. For å få det hele til å gå opp må vi sette inn et nytt felt som kan
brukes. Dette kan enten være en teller, som fungerer slik at første post blir 1, andre 2 osv, eller
f.eks. personnummer, bare det er unikt for hver post.
Det vi nå mangler er en måte å fortelle Access hvilke personer som eier hvilke biler. Og det er
her relasjonene kommer inn. Vi bruker en relasjon mellom bil-tabellen og person-tabellen til å
koble sammen riktige par av eier og bil. Det gjør vi ved å endre ‘Eier’-feltet i bil-tabellen til
‘Eiers personnummer’. Så forteller vi database-systemet (Access) at ‘Eiers personnummer’
viser til ‘Personnummer’ i person-tabellen. (Formelt sier vi at ‘Eiers personnummer’ er
fremmednøkkel til person-tabellen.) Siden ‘Personnummer’ er primærnøkkel i person-tabellen
vil dette fungere ypperlig.
4.3 Normalisering
Overgangen fra et ER-light-diagram til ferdig tabell- og relasjonsstruktur skulle være grei.
Dette er fremgangsmåten:
1. Lag en tabell for hver entitet.
2. Hver attributt blir ett felt i tabellen. (Av og til deler man opp felter som man ikke gadd
tegne som flere attributter, f.eks. slik jeg under deler opp adresse i gateadresse, postnummer
og sted.)
3. Dersom tabellene ikke har noen naturlig primærnøkkel må en lages. (Denne behøver ikke å
finnes i virkeligheten, men kan være en teller.)
4. Hvert forhold blir en fremmednøkkel (og dermed også et felt) i tabellen. Fremmednøkkelen
må svare til den andre tabellens primærnøkkel. Dersom vi har et en-til-mange forhold lager
vi et felt i tabellen til den entiteten som har ∞-tegnet på sin side.
5. Lag en relasjon for hvert forhold.
Dersom vi følger disse reglene får vi:
1. Tabellene Person og Bil.
2. Person=(Navn, Gateadresse, Postnummer, Sted, Telefon) og Bil=(Registreringsnummer,
Merke). Her er adresse splittet i flere felter.
3. Person=(ID_Person, Navn, Gateadresse, Postnummer, Sted, Telefon) og
Bil=(Registreringsnummer, Merke). ID_Person er en teller som er satt inn.
1096 - Lars Marius Garshol 19

Innføring i databaser
4. Person=(ID_Person, Navn, Gateadresse, Postnummer, Sted, Telefon) og
Bil=(Registreringsnummer, Merke, Eier). Her er Eier en fremmednøkkel til Person-tabellen.
5. Person=(ID_Person, Navn, Gateadresse, Postnummer, Sted, Telefon) og
Bil=(Registreringsnummer, Merke, Eier). Relasjoner: (Person,ID_Person,1)-(Bil,Eier,∞).
Merk her at relasjonen går mellom feltene ID_Person og Eier. En relasjon må alltid være
mellom to felter.
Her har vi det vi i dette kurset vil trenge for å begynne å lage en database. I større systemer
ville man ofte vært interessert i flere regler og begrensninger, men for våre formål holder dette.
4.4 Tommelfingerregler for normalisering
• Primærnøkkelen bør være kort, av hensyn til hastigheten.
• Verdien til primærnøkkelen må være kjent for alle poster.
• Fremmednøkkelen som representerer et forhold skal inn i den tabellen som har ∞-tegnet
nærmest seg.
• Bruk bare tall hvis du vil regne med verdiene i feltet, eller hvis du er helt sikker på at
verdiene i feltet bare er tall.
• Bruk boolean til felter som bare kan ha to verdier. (Det finnes unntak her, men de er få.
Dersom det f.eks. bare kan være to typer av noe er det et unntak.)
• Bruk dato/tid til alt som har med datoer og klokkeslett å gjøre.
• Dersom du har forhold mellom to felter må disse ha samme type. Tellere må kobles med
Tall (Langt heltall).
4.5 Spørringer, skjemaer og rapporter
Etter å ha laget en relasjon mellom bil- og person-tabellene går det svært greit å lage oversikter
der dataene fra disse to tabellene kombineres. Til dette bruker man noe som kalles spørringer
(eng. queries). I en spørring kan man angi hvilke felter man vil ha med, lage nye felter
sammensatt av de gamle, sortere, velge ut bare noen av postene og stort sett gjøre hva man vil.
Spørringene brukes som grunnlag for skjemaene, som er skjermbildene, og rapportene, som er
utskriftene. Skjemaene vises på skjermen som vinduer, mens rapportene ser ut som
dokumenter, og kan forhåndsvises og skrives ut. Skjemaene kan også skrives ut, men det er
ikke hovedhensikten med dem. Dersom du vil vite mer om skjemaer og rapporter kan du tyvtitte
på kapitlene 9 og 11.)
4.6 Oppbygningen av databaser
Dette er en formell ISO-standard som beskriver inndelingen av databasene som utvikles i tre
lag, eller skjemaer. (Ikke å forveksle med skjemaene nevnt ovenfor, som vi skal lage i Access.)
Denne kalles 3-skjema-arkitekturen, men er såpass formell at vi dropper den og tar vår egen
variant istedet. Dersom dette avsnittet er uforståelig så ikke fortvil: dette er ikke ment som
noen viktig del av kurset, bare som en sammenheng å sette det vi lærer senere inn i.
De tre lagene eller skjemaene er
1096 - Lars Marius Garshol 20

Innføring i databaser
• SQL-tolken
Denne delen er allerede laget av Microsoft, nemlig databasemotoren Jet, som er Access’
hjerte. Den er en adskilt del av programmet, som oppbevarer alle data, håndhever alle
begrensninger på dataene og mottar og svarer på alle spørringer. For å si det på en annen
måte er det programdelene som tolker/utfører de to andre delene. Forskjellen på databaseverktøy
og vanlige programmeringsspråk er at i de siste har du ikke denne delen, og må lage
de tilsvarende funksjonene selv.
• Datastruktur
Dette er beskrivelsen av databasen, som lages av deg. Beskrivelsene av alle tabeller,
begrensninger på dataene i tabellene, relasjoner hører hjemme her. Spørringer hører forsåvidt
også hjemme her.
• Brukergrensesnitt
Dette er beskrivelsen av hvordan data skal skrives inn av og presenteres for brukeren. Her
er alle skjemaer og rapporter.
Denne tredelingen av databasene forklarer for en stor del hvorfor ting fungerer som de gjør i
Access og gir en grei sammenheng å sette nye begreper inn i. Det kan med andre ord være
greit å ha den i tankene når du leser videre. Et viktig poeng her er at de to siste delene lages av
utvikler, men at ingen av dem inneholder dataene. Alt som beskrives her er hvordan dataene
skal håndteres.
4.7 Referanseintegritet
Når data endres, slettes og flyttes på kan det fort gå slik at fremmednøkler i en tabell viser til
poster som ikke finnes i den tabellen forholdet går til. Da har man et brudd på
referanseintegriteten, og det kan føre til en god del besvær. Mange databaser har spesielle
rutiner som håndterer dette.
Den varianten Access brukes kalles kaskadesletting (i den norske programteksten:
massesletting). Det vil si at når du sletter en post vil alle poster som har referanser til denne
også bli slettet. Det kan være en farlig strategi i enkelte tilfeller, men fungerer stort sett bra.
Access protesterer av og til når man prøver å lagre en post ved å si at referanseintegriteten
krever en relatert post i tabell T_EttEllerAnnet. Det som da har skjedd er at posten enten har
en referanse til en post som ikke eksisterer, eller at den ikke har noen referanse i det hele tatt
der den skulle hatt det. I så fall må man enten legge inn/rette referansen eller slette posten.
4.8 SQL og BASIC
Selv om Access for en stor del er basert på at utviklingen skal skje via vinduer, veivisere og
klikking gir ikke dette adgang til alle muligheter. Tradisjonelt har relasjonsdatabaser vært
basert på et spesielt programmeringsspråk kalt SQL. SQL står for Structured Query Language,
som er litt misvisende, ettersom SQL brukes både til spørringer, datamanipulasjon og
oppretting/sletting av tabeller.
1096 - Lars Marius Garshol 21

Innføring i databaser
Access bygger også på SQL, men det er mulig å lage fullt brukbare databaser uten å skrive så
mye som en linje med SQL-kode. Likevel kan dette være nødvendig dersom man vil få til mer
kompliserte ting. Dette kurset dekker ikke SQL.
Som nevnt i avsnitt 2.3 er det ting som ikke lar seg gjøre med Access og SQL. Access har
derfor også et vanlig (med det mener jeg imperativt, for de som kan litt om programmering)
programmeringsspråk innebygget, nemlig BASIC. Dette er et gammelt (fra 1965)
programmeringsspråk, som opprinnelig ble laget til bruk i undervisning. Det var svært
primitivt, men har gjennomgått store endringer, blant annet takket være Microsoft, men er og
blir primitivt. BASIC kan brukes til programmering av ting som ikke lar seg uttrykke i SQL,
men kommer fortsatt til kort overfor skikkelige programmeringsspråk.
1096 - Lars Marius Garshol 22

5. Access’ oppbygning og virkemåte
5.1 Access sett i forhold til alternativene
Innføring i databaser
Det finnes mange typer databasesystemer, og den enkleste typen bygger på såkalte "flate filer".
Dette kan betraktes som databaser med bare en tabell, men med litt flere muligheter innen en
enkelt tabell enn det f.eks. Access har. Eksempler på denne typen databasesystemer er
Filemaker Pro og til en viss grad DataEase.
Hakket over disse systemene finner vi de ekte relasjonsdatabasene som Access, Paradox,
dBASE og andre. Disse systemene er laget for PCer, hvilket vil si at de er beregnet på å brukes
på en enkelt maskin, selv om de fleste også kan deles i nettverk. Disse er litt mindre systemer,
som ofte har en rekke svakheter ved utvikling av større systemer. (Dette gjelder også Access.)
Det finnes også større databasesystemer (også de relasjonsdatabaser) som er beregnet på bruk i
større systemer, som f.eks. Oracle, Sybase, Ingres og andre. Disse har gjerne en utvidet SQL
som gjør SQL til et nesten fullverdig programmeringsspråk (kalles ofte for T-SQL) og har
også i større grad støtte for utvikling av større systemer. Enkelte har også modelleringsprogrammer
og mulighet for automatisk normalisering av datamodellene.
Det finnes også mer avanserte typer databaser enn relasjonsdatabasene, nemlig den eldste av
dem alle: nettverksdatabasene og de mer moderne objekt-orienterte databasene. Nettverksdatabasene
brukes lite ettersom de er litt for kompliserte, og relasjonsdatabaser kan håndtere det
meste i alle fall. De objekt-orienterte databasene tilbyr vesentlige forbedringer overfor
relasjonsdatabasene, men har ikke slått gjennom ennå, blant annet fordi utviklerne er så
konservative.
Kongen på haugen i dette hierarkiet er selvfølgelig de rene programmeringsspråkene, som
databasesystemene selv er laget i.
5.2 Grensesnittet
Access er et vindusbasert system, slik at programmene som utvikles i Access blir også
vindusbaserte Windows-programmer. Databasen lagres i en enkelt fil med etternavnet .MDB.
Det er bare mulig å ha en database åpen av gangen, men man kan jobbe med flere forskjellige
deler av databasen samtidig.
Fil-menyens Lagre og Lukk-valg gjelder kun det åpne vinduet, ikke hele databasen.
(Databasevinduet er et unntak, siden det inneholder hele databasen, lukker du det vil du derfor
også lukke databasen.)
1096 - Lars Marius Garshol 23

5.3 Programmenes grensesnitt
Innføring i databaser
Access er et Windows-program og det vil også programmene du lager med Access være. Det
betyr at deres grensesnitt vil følge Windows-standarden med knapper, vinduer osv. I
programmene du lager vil hvert skjema være et dokumentvindu, og oppføre seg som vanlige
Windows-vinduer.
En stor fordel med å bruke Windows som operativsystem er at alle programmer ser mer eller
mindre like ut fordi de har grensesnitt som er bygget opp av de samme elementene. Dersom du
vil lage brukervennlige programmer bør du ha dette i tankene, og prøve å få ditt program til å
ligne mest mulig på andre Windows-programmer. Det vil gjøre at brukerne har lettere for å
lære seg programmet, siden det ligner på andre de allerede kjenner.
5.4 Veivisere
Access har en rekke såkalte “veivisere” (engelsk: wizards), som er små hjelpeprogrammer som
guider deg gjennom oppsettet av en del standardiserte løsninger. Dette kan være spesielle typer
skjemer, knapper, rapporter eller annet. De er ofte tidsbesparende og enkle å bruke, men gir
ikke tilgang til alle muligheter. Imidlertid kan det veiviserne lager senere endres av deg, slik at
du kan lage noe som ligner på det du vil ha, og så endre det etterpå.
Vi skal ikke ta for oss veiviserne spesielt grundig i dette kurset, og skal heller ikke se på alle.
Det kan imidlertid lønne seg å utforske disse litt på egenhånd slik at du husker hva du kan
gjøre enklere hvor. Det bør også legges til at de ikke alltid er like tidsbesparende heller.
1096 - Lars Marius Garshol 24

5.5 Hvordan navigere i Access
Kort
Figur 5.1
Innføring i databaser
Hjertet i Access’ grensesnitt er vinduet i Figur 5.1, herfra har du adgang til alle delene av
databasen din. Vinduet består av en rekke kort (som du ser på venstresiden) og hvert kort har
sin egen liste som vises i vinduet og sin egen knapperad. På bildet vises listen til kortet
‘Tabell’, altså alle tabellene. (Som du ser er det ingen tabeller ennå.)
5.6 Standardtabellen
Dette er et element i Access-grensesnittet som går igjen i en god del forskjellige sammenhenger
og som jeg derfor vil gjøre unna her. Den dukker f.eks. opp når du skal lage tabeller og spørringer,
når du viser tabeller og spørringer og en rekke andre steder, blant annet når du lager og
bruker skjemaer.
Figur 5.1
Knapper
Vindu
1096 - Lars Marius Garshol 25

Innføring i databaser
• Hvordan bevege seg rundt i tabellen
Dette gjøres enkelt og greit ved å bruke piltastene og tab/shift+tab, eventuelt musa.
• Justering av kolonnebredde og radhøyde
Dette gjøres ved å ta tak med musen mellom to kolonner og dra dem til den bredden man vil
ha. Et dobbeltklikk her vil gi en kolonnebredde som akkurat passer til den bredeste verdien i
kolonnen. Radhøyde justeres på samme måte, men dobbeltklikket fungerer ikke.
• Velge kolonne/rad eller hele tabellen
En kolonne eller rad velges i sin helhet ved å trykke i det grå feltet til venstre/over
raden/kolonnen. Et klikk med høyre mustast vil da få opp en hurtigmeny som gir adgang til
å sette inn nye rader/kolonner, slette rader/kolonner og endel annet.
Du kan velge hele tabellen ved å trykke på det grå feltet helt oppe i venstre hjørne.
• Flytte kolonne/rad
En eller flere kolonner/rader flyttes ved at de først merkes ved å dra med musen over dem.
Deretter slipper du mustasten og drar dem på nytt dit du vil ha dem.
• Postvelgerne
Mange av disse standardtabellene (og endel vanlige skjemaer) har navigasjonsknapper nederst
til venstre. Der kan du bla mellom postene med knappene, som er i rekkefølge fra venstre:
første post, en post tilbake, en post frem, siste post. Blar du forbi siste post lager du en ny
post.
• Hvordan lage ny post
En ny post lages ved å gå inn på nederste rad (som alltid er tom) og skrive inn posten her.
1096 - Lars Marius Garshol 26

6. Tabeller i Access
6.1 Hvordan opprette en tabell
Innføring i databaser
Dersom vi skal lage en tabell i Access velger vi kortet ‘Table’ i hovedvinduet og trykker
‘New’-knappen. Vi blir da spurt om vi vil bruke tabell-veiviseren eller lage tabellen selv.
Tabell-veiviseren har en rekke ferdiglagede tabeller klare, men selv om disse kan modifiseres
av brukeren satser vi i dette kurset på å lage tabellene selv. Når vi velger å lage tabellene selv
kommer vinduet i Figur 6.1 opp. Der vises en tabell over feltene i tabellen, med feltnavn,
datatype og en beskrivelse. Feltnavnet er det navnet som brukes på feltet i hele databasen og er
derfor svært viktig.
6.2 Feltdefinisjon
Figur 6.1
Etter at feltet har fått et navn må det få en type. Typen avgjør hva slags data som kan lagres i
feltet og hva vi kan gjøre med dem. Access tilbyr typene ‘Tekst’, ‘Notat’, ‘Tall’, ‘Dato/Tid’,
‘Valuta’, ‘Teller’ og ‘OLE-objekt’. Feltene får en type av to grunner: for det første fordi den
begrenser verdiene som kan legges i feltet, og for det andre fordi det forteller Access hvordan
vi kan behandle verdiene i feltet. Dersom Pris f.eks. lagres som Tall vet Access at ‘Bxcx’ ikke
er en gyldig pris. Den vil også forstå hva du mener med gjennomsnittlig Pris, og vil protestere
hvis du prøver å ta gjennomsnittet av en rekke datoer.
Under 'Beskrivelse' kan du legge inn en beskrivelse av feltet som er synlig både for bruker og
deg selv. Dersom andre enn deg skal være involvert i databasen bør du legge inn beskrivelser
1096 - Lars Marius Garshol 27

Innføring i databaser
her. De kan være gode å ha når du noen måneder senere sitter og klør deg i hodet og lurer på
hva de forskjellige feltene egentlig var ment brukt til.
6.3 Datatyper og feltegenskaper
Alle felt har egenskaper som avgjør hvordan de oppfører seg. Disse varierer fra type til type, så
vi behandler dem under omtalen av typene. Ikke alle egenskapene er like viktige, så vi
gjennomgår bare de aller viktigste her.
En egenskap som er felles for alle felt (og svært viktig) heter 'Indeksert' og har tre muligheter:
Ja (med duplikater), Nei, og Ja (uten duplikater.) Dersom du indekserer et felt bruker du en del
minne og diskplass, men søk og oppslag går langt raskere. Primærnøkler må være indeksert og
blir det automatisk. Dersom du velger 'uten duplikater' vil ikke to forskjellige poster kunne ha
samme verdi i dette feltet.
• Tekst
Her kan du lagre vanlig tekst, maksimalt 255 tegn.
• Feltstørrelse
Dette avgjør den maksimale lengden på feltet. Lengden avgjør hvor stor plass feltet vil ta
på disk og i minnet, men det er likevel som regel ingen vits i å finregne på størrelsen her.
Sørg for at du har nok, men ikke overdriv.
• Standardverdi
Denne verdien settes inn i feltet idet en ny post opprettes, men kan endres av brukeren.
• Valideringsregel
Dette er et boolsk uttrykk (se ordlisten eller avsnitt 7.5.2.3) og når feltverdien ikke
tilfredsstiller dette vil verdien ikke bli godkjent. Som feilmelding vises teksten i
Valideringstekst.
• Valideringstekst (se over)
• Obligatorisk
Dersom du vil at brukeren skal være nødt til å fylle ut dette feltet svarer du ja her.
Primærnøkkelen må være obligatorisk (settes automatisk), men ellers bør du være
forsiktig med denne egenskapen. Den kan fort bli mer til irritasjon enn nytte.
• Notat
Også her kan du lagre tekst, men nå er lengden maksimalt 64000 tegn. Denne typen brukes
mest til å lagre fritekst som kommentarer, beskrivelser og lignende. Man er som regel ikke
interessert i å søke på Notat-felt.
1096 - Lars Marius Garshol 28

Denne typen har akkurat de samme egenskapene som Tekst.
Innføring i databaser
• Tall
Kanskje ikke så overraskende: her kan du lagre tall, og ingenting annet. Hva slags tall det er
snakk om avgjør egenskapene.
• Feltstørrelse
Denne egenskapen avgjør hvor mange byte som skal brukes til å lagre tallet, og hvordan
disse skal tolkes. Byte, heltall og langt heltall er alle heltall (dvs: tall uten komma) og kan
lagre stadig større tall. Langt heltall går til +/- 2 milliarder. Vil du lagre noe større enn
dette må du bruke Flyttall eller Langt flyttall. Begge disse er kommatall, og langt flyttall
har 15 desimaler og går til 10 308 . Plassforskjellen er liten her, så det lønner seg å velge en
variant som man vet gir plass til det man er interessert i.
Navn Bytes Kan lagre
Byte 1 0 til 255.
Heltall 2 -32768 til 32767.
Langt heltall 4 -2147483648 til 2147483647.
Flyttall 4 ±3.402E38 og ned til 1.401E-45.
Langt flyttall 8 ±1.797E308 og ned til 4.94E-324.
Tabell 6.1
• Antall desimaler
Her velger du hvor mange sifre feltet maks skal kunne ha. Hvis du ikke vet hvor mange
det er (som i f.eks. en varepris) bør denne egenskapen settes til Auto.
• Ellers er feltene som for Tekst og Notat.
• Dato/Tid
Denne typen brukes til å lagre dato og/eller klokkeslett. Egenskapen Format brukes til å
avgjøre om det er dato, klokkeslett eller begge deler, og hvordan de skal skrives. Ellers er
egenskapene som for Tekst.
• Valuta
Denne typen brukes til å lagre pengebeløp. Den eneste grunnen til å velge den framfor Tall
(langt heltall) er at Valuta har en rekke ferdigdefinerte formater som kan være greie å ha.
• Teller
Denne typen er spesiell. Den er egentlig den samme som Langt heltall, men har den
egenskapen at første post i tabellen får verdien 1, mens siden telles feltetverdien opp med 1
for hver ny post. Dette sikrer at alle postene har forskjellige verdier. Så hvis en tabell ikke
har noen naturlig primærnøkkel er det vanlig å slenge på et teller-felt og la det være primærnøkkelen.
1096 - Lars Marius Garshol 29

6.4 Endre felt
Innføring i databaser
Å gå tilbake og endre definisjonen av et felt er stort sett greit i Access. Dataene konverteres
automatisk til en eventuell ny type (så langt råd er) og alle andre endringer gjøres problemfritt.
Det er imidlertid ett unntak: feltnavnet. Dersom du endrer dette vil du få feil overalt i
databasen der du har brukt det gamle navnet, og du vil bli nødt til å gå over hele databasen for
å finne alle forekomster av det gamle navnet. Dette er en stor svakhet ved Access, men lite å
gjøre ved.
Det gjelder også å være klar over at endringer som har med primærnøkler og fremmednøkler å
gjøre kan skape problemer dersom data forsvinner eller typene ikke lenger stemmer overens.
Et generelt problem er når man ønsker å konvertere et felt fra en type til en annen. F.eks. når
man går fra tekst til tall. Tekst som “123” går greit, mens ting som “Hansen, Erik” går dårlig
ettersom dette ikke kan skrives som tall. Da må man enten droppe konverteringen, eller finne
seg i at data forsvinner.
6.5 Primærnøkkel
Å definere primærnøkkel i Access er svært enkelt: merk radene til de feltene som skal være
med i nøkkelen. (Du kan ha med flere felter, men jo kortere nøkkel, jo raskere database.) Klikk
med høyre mustast, og velg Sett primærnøkkel i hurtigmenyen som kommer opp. De merkede
feltene blir da sammen ny primærnøkkel.
6.6 Forholdene
Så var det å definere forholdene mellom de forskjellige tabellene man har laget. Det gjøres ved
å velge Redigere|Relasjoner i menyen når du har tabell-kortet oppe. Da kommer først en
dialogboks der du avgjør hvilke tabeller som skal være med i relasjons-oversikten (se Figur
6.2).
Figur 6.2
1096 - Lars Marius Garshol 30

Innføring i databaser
I relasjonsoversikten kan du flytte rundt på tabellene som du vil for å få trukket forholdslinjene
slik at de går minst mulig i kryss. Et forhold mellom to tabeller settes opp ved at du
trekker feltet fra den ene tabellen der 1-tallet skal stå til det tilsvarende feltet i den andre
tabellen. Når du har gjort dette kommer dialogboksen i Figur 6.3 opp. Der setter du et kryss i
feltet Referanseintegritet, og velger om du skal ha en-til-en eller en-til-mange. Dersom du
setter kryss i de to merkefeltene til høyre vil referanseintegriteten automatisk overholdes, ved
at alle poster som viser til ikke-eksisterende poster i andre tabeller vil slettes. Dette valget
anbefales!
6.7 Et eksempel
Figur 6.3
I Access (og andre steder) er det vanlig å angi feltnavn slik: Tabellnavn.Feltnavn, slik at det er
tydelig hvilken tabell feltet tilhører. Det går an å sløyfe tabellnavnet hvis dette er åpenbart
(feltet finnes bare i en tabell).
I bilregister-eksempelet (se avsnitt 3.3) ville jeg laget to tabeller: T_Bil og T_Person. Disse
ville jeg laget slik:
Feltnavn Type Merk
ID_Person Teller Spesialopprettet for å være primærnøkkelen.
Navn Tekst Personens navn.
Gateadresse Tekst Personenes gateadresse.
Postnr Tall Postnummeret til personens bosted. Heltall, 4 siffer.
Sted Tekst Personens bosted.
Telefon Tall Personens telefonnummer. Heltall, 8 siffer.
1096 - Lars Marius Garshol 31

Tabell 6.2: T_Person
Innføring i databaser
Feltnavn Type Merk
Registreringsnr. Tekst Primærnøkkel. Bilens registreringsnummer. Lengde: 9.
Merke Tekst Bilens merke.
Eier Tall Fremmednøkkel til T_Person.ID_Person. Langt heltall.
Tabell 6.3: T_Bil
Forholdet mellom T_Person.ID_Person og T_Bil.Registreringsnummer er en-til-mange,
akkurat som i datamodellen.
6.8 Se på og skrive inn data
Du kan skrive inn og endre data i tabellene ved å åpne tabellene med ‘Åpne’-knappen på
databasevinduet. Du vil da få opp en standardtabell som viser alle postene i tabellen. Der kan
du både skrive inn og endre data.
Det er også mulig å endre data og skrive inn data når du åpner en spørring i dataark-visning.
Det er enkelte typer spørringer som ikke lar deg gjøre dette, men stort sett går det greit.
1096 - Lars Marius Garshol 32

7. Spørringer i Access
7.1 Hva er en spørring?
Innføring i databaser
Spørringer er egentlig to ting, utvalgsspørringer og datamanipulasjonsspørringer. Den første
typen er overlegent den vanligste, og er den vi først og fremst skal beskjeftige oss med. Det er
imidlertid viktig å vite om manipuleringsspørringene også siden det er eneste måten å behandle
data automatisk på i en relasjonsdatabase. (Uten å bruke Access Basic, som vi ikke skal lære
her.)
Utvalgsspørringer trekker ut data fra tabeller og organiserer dem på nye måter. Vi kan f.eks.
liste ut alle personer bosatt i Kristiansand, finne bilen som har registreringsnummer ‘DE 66477’
eller skrive ut hvor mange biler hver enkelt person eier osv. Vi skal begynne forsiktig og bygge
dette opp etterhvert.
Ingen av de spørringene vi lager i dette kapittelet er særlig pene eller spesielt egnet til å skrives
ut eller vises på skjerm. Det er heller ikke meningen. Meningen med spørringer er å få fram de
rette dataene, og så kan disse enten vises på skjerm i et skjema eller skrives ut i en rapport.
Layouten ligger da i skjemaet/rapporten, mens dataene leveres av spørringen.
7.2 Spørringer fra en tabell
7.2.1 Spørringer med alle poster
Den enkleste typen spørring plukker data fra en tabell, men velger bare ut noen av feltene. Du
lager en spørring ved å velge ‘Spørring’-kortet i databasen og så trykke ‘Ny’. Du vil da bli
spurt om du vil bruke en veiviser eller om du vil starte med en blank spørring. Vi satser på å
lage spørrringene selv. Dersom vi vil lage en adresseliste over alle personene i vår eksempeldatabase
gjør vi som beskrevet over. Deretter må vi velge hvilke tabeller og spørringer vi vil gå
ut i fra. Vi velger der tabellen ‘T_Person’, siden det er der informasjonen finnes. Vi får da opp
følgende vindu:
1096 - Lars Marius Garshol 33

Figur 7.1
Innføring i databaser
Her ser vi i øverste halvdel av vinduet tabellene og spørringene vi har valgt ut (og forholdene
mellom dem). Det er ikke nødvendig å ha tabellene og spørringene oppe her for å kunne bruke
dem i spørringen, men det er greit å ha som huskelapper og snarveier til enkelte kommandoer.
Nederste halvdel av vinduet er der vi lager spørringen. Den består av en tabell der hver kolonne
lager en kolonne i den ferdige spørringen, mens radene beskriver hva som skal gjøres med
kolonnene. Vi skal lage en spørring som lister ut alle personene i databasen, og data om dem.
Da skriver vi bare inn feltene vi vil ha med i øverste rad i hver kolonne, eller velger dem. Feltraden
er en rad med kombinasjonsbokser, så du kan trykke pilen i feltet og velge det feltet du
vil ha. Du kan også dobbeltklikke på feltet i huskelisten (øverst i vinduet) eller dra fra huskelisten
til spørringen. Når du er ferdig kan du velge Vis | Dataark i menyen for å se resultatet.
Figur 7.2
Resultatet blir da som i Figur 7.2. Problemet er bare at hvis vi får mange personer vil denne
adresselisten bli vanskelig å finne frem i fordi den ikke er sortert. Det kan vi lett gjøre: Sorterraden
i Figur 7.1 styrer sorteringen av postene. Dersom vi velger ‘Stigende’ i ‘Navn’-kolonnen
vil postene bli sortert på navn i rekkefølgen A-Å. Dermed er vår adresseliste klar. Da er det
bare å lukke vinduet og gi spørringen et navn. (F.eks: ‘Q_Adresseliste’.)
1096 - Lars Marius Garshol 34

Innføring i databaser
7.2.2 Spørringer med bare noen av postene
Av og til er vi interessert i å vise bare noen av postene i databasen. Dette kan også enkelt
gjøres med en spørring. Sett at vi er interessert i en spørring som viser alle personene som bor
på ett bestemt sted. Dette kan gjøres ved at spørringen får en ‘parameter’ som oppgis av
brukeren. Vi kan gå fram på eksakt samme måte som sist, og lage nøyaktig den samme
spørringen. (Vi kan også kopiere den gamle ved hjelp av klipp og lim i databasevinduet.) Det
som da gjenstår er parameteren og å bruke denne. Denne kan legges i en ny kolonne bortenfor
‘Sted’. Der kan du skrive ‘[Angi sted]’ i felt-raden. ‘Angi sted’ er da teksten som vises til
brukeren når han blir bedt om å skrive inn stedet.
Deretter skriver vi et boolsk uttrykk i ‘Vilkår’-raden. I dette tilfellet er det enkelt: ‘=[Sted]’.
Da vises alle poster der [Angi sted] er lik innholdet i feltet Sted. (Du må skrive hakeparenteser
rundt Sted for at Access skal forstå at det er et feltnavn.) Hvis du nå velger Vis|Dataark vil du
bli bedt om å ‘Angi sted’, skriver du da ‘Kristiansand’ vil posten ‘Jarl Andresen’ vises. Der vil
du se at siste kolonne heter ‘Uttr1’ og er lik Sted. Dette er [Angi sted]-kolonnen, og vi er
egentlig ikke interessert i å ha med denne. Den kan tas vekk fra visningen ved at krysset i Visboksen
fjernes.
Boolske uttrykk står forklart i avsnitt 7.5.2.
7.3 Spørringer fra flere tabeller
Som regel ønsker man å kombinere data fra flere tabeller for å få fram informasjon. Dette kan
også enkelt gjøres av en spørring. La oss si at vi vil ha en liste over hva slags biler hver enkelt
person eier. Da lager vi en ny spørring der både T_Bil og T_Person brukes. Siden vi har lagt
inn forholdet mellom disse to tabellene i Redigere|Relasjoner kommer dette opp i spørringsvinduet.
Ferdig laget ser spørringen ut som i Figur 7.3.)
Figur 7.3
1096 - Lars Marius Garshol 35

Innføring i databaser
Dersom du vil forestille deg hvordan dette fungerer kan du tenke deg at datamaskinen først
setter opp alle mulige kombinasjoner av 1 post fra T_Person og 1 fra T_Bil. Deretter plukker
den ut de der T_Person.ID er lik T_Bil.Eier, før den sorterer de som er igjen på
T_Person.Navn og viser det hele.
Figur 7.4
Resultatet vises i Figur 7.4. Som du ser dukker samme person opp flere ganger dersom
han/hun har flere biler. Det er selvsagt ikke særlig pent, men kan lett ordnes i et skjema eller en
rapport. (Spørringen lagres som Q_Biler på eier.)
7.4 Koblingsegenskaper
Når du kobler to tabeller vises bare de radene der de kombinerte feltene i begge tabellene er
like. Dersom en bil for eksempel skulle stå oppført uten eier vil den ikke bli vist. Dette kan du
endre ved å velge koblingen, klikke med høyre mustast og velge koblingsegenskaper.
Der har du tre muligheter:
• standardløsningen: bare ta med rader der begge feltene har samme verdi.
• ta med alle poster fra den ene tabellen, men bare de med en verdi i koblingsfeltet fra den
andre
• den omvendte muligheten.
Dermed kunne vi valgt å ta med alle poster fra T_Bil, men bare de fra T_Person der
koblingsfeltene er like. Da ville vi fått opp også biler uten eiere, som ville hatt Navn-kolonnen
tom.
Stort sett vil referanseintegriteten sørge for at dette skjer automatisk, men iblant får du ikke
opp en eneste rad i en koblingsspørring selv om det er data i tabellene. Da kan
koblingsegenskapene være løsningen.
Hvis du endrer koblingsegenskapene slik at resultatet av spørringen vil avhenge av rekkefølgen
postene leses ut av tabellene i vil du få en feilmelding: «Query contains ambiguous outer join.»
Da er det bare å finne på noe annet.
1096 - Lars Marius Garshol 36

7.5 Beregnede felt: Aggregatfunksjoner og uttrykk
Innføring i databaser
Av og til er vi interessert i å vise frem felt som kan beregnes ut ifra dataene som allerede ligger
i tabellen. Dette gjøres i spørringer og kan aldri gjøres i selve tabellen. Det lønner seg ikke å
lagre slik informasjon i tabellene, fordi du da får dobbeltlagring.
7.5.1 Uttrykk generelt
Generelt kan vi si at et beregnet felt skrives slik: Feltnavn: Uttrykk. Feltnavn er her navnet
feltet vil få i spørringen, mens Uttrykk er et uttrykk som beskriver hvordan det skal beregnes.
Dersom du regner med tall kan uttrykket skrives som et vanlig matematisk uttrykk, men hvis
du jobber med f.eks. tekst blir ting litt annerledes.
7.5.2 Uttrykk i de forskjellige typene
7.5.2.1 Tall
Dersom du har en tabell med ansatte som har feltene ‘Timelønn’, ‘Timer jobbet denne mnd’ og
‘Skatteprosent’ kan du beregne to nye felter: ‘Fradrag’ og ‘Utbetalt lønn’. Disse skrives da
slik: (skatteprosent er mellom 0 og 100)
Fradrag: Timelønn*[Timer jobbet denne mnd]*(Skatteprosent/100)
Utbetalt lønn: Timelønn*[Timer jobbet denne mnd]*((100-Skatteprosent)/100)
I tall-beregninger fungerer parenteser og annet akkurat som vi er vant til fra vanlig
matematikk. Prioritetene er også som vanlig. (Dvs: rekkefølgen de beregnes i, f.eks. beregnes
gange før pluss osv.) Operatorene er (i prioritert rekkefølge):
Prioritet Operator Betydning Operator Betydning
1 ^ Opphøyd i
2 * Gange / Dele
3 + Pluss - Minus
Tabell 7.1
7.5.2.2 Tekst
Dersom du jobber med tekst kan du skrive inn tekst-konstanter i gåseøyne: "Dette er en tekstkonstant".
De kan settes sammen med + slik at "Dette er"+" "+"en test" blir "Dette er en test".
I adresselisten kunne vi for eksempel vært interessert i å ha Sted og Postnr samlet til ett felt,
slik at vi slapp å justere avstanden mellom dem så nøyaktig i rapporter. Dette kunne da gjøres
slik:
Bosted: [Postnr]+" "+[Sted]
Legg merke til at vi setter inn et mellomrom mellom disse. Det er for å unngå resultater som
1800ASKIM.
1096 - Lars Marius Garshol 37

Innføring i databaser
7.5.2.3 Boolske uttrykk
Du lager boolske verdier fra Ja/Nei-felter eller ved å sammenligne to felter av samme verdi.
Det gjøres med en sammenligningsoperator som
Operator Betydning
= er lik
< mindre enn
> større enn
= større enn eller lik
ulik
Tabell 7.2
Uttrykk som A=B, Pris

Figur 7.5
Innføring i databaser
Hvordan dette ser ut i dataark-visning kan du vel tenke deg. Hvis ikke kan du jo prøve det
selv.
De viktigste aggregatfunksjonene er:
Navn Betydning
Summer Summen av feltverdiene
Maks Den største feltverdien
Min Den minste feltverdien
Antall Antall poster som har en verdi i feltet
Gjennomsnitt Gjennomsnittet av feltverdiene
Tabell 7.4
7.5.4 Gruppering
Jeg sa i avsnittet over at aggregatfunksjoner ‘tar data fra ett felt over flere poster og trekker
noe ut av dem’. Det som er viktig her er hvilke poster det er funksjonene opererer over. Dette
avgjøres av grupperingen. Dersom vi ikke grupperer i det hele tatt vil funksjonene operere på
alle postene (snittet av alle poster, antall poster, summen av alle poster etc.) Dersom vi grupperer
på f.eks. Person_ID vil f.eks. sum-funksjonen summere for hver person.
Dersom vi tenker oss en spørring som i eksempeldatabasen gir følgende resultat:
1096 - Lars Marius Garshol 39

Registreringsnummer Merke Eier
SP 83400 Toyota MR2 Anne Tryti
DE 72719 TransAM Anne Tryti
DE 39291 Dodge Van Anne Tryti
AJ 27381 Alfa Romeo GTV Tore Borregaard
AJ 23992 Alfa Romeo Giulia Tore Borregaard
UC 39921 VW Golf GTI Bertha Skottland
BN 26131 Nissan Bluebird Jarl Andresen
DE 66477 Opel Kadett Hans Hansen
Tabell 7.5
Innføring i databaser
Dersom vi ut ifra den samme tabellen (eller flere tabeller, det spiller ingen rolle) lager en spørring
med ett eneste felt: Antall(Registreringsnummer) vil resultatet bli en eneste rad der det står
8. Da har Access gått gjennom tabellene og funnet 8 poster med en verdi i feltet Registreringsnummer.
Dersom vi i spørringen nå legger inn ett felt til, nemlig Eier, vil ting bli annerledes. Da vil
følgende bli resultatet:
Eier Antall(Registreringsnummer)
Anne Tryti 3
Tore Borregaard 2
Bertha Skottland 1
Jarl Andresen 1
Hans Hansen 1
Tabell 7.6
Det som nå har skjedd er at Access teller antall poster som har lik verdi i Eier-feltet. Vi sier at
vi har gruppert på Eier, og da teller vi hvor mange biler hver eier har. Det er ikke mulig å vise
et felt i Access uten å gruppere på det.
Det betyr at dersom vi setter inn feltet registreringsnummer også så vil vi gruppere på Eier og
Registreringsnummer, og dermed teller vi antall poster som har lik verdi i Eier og Registreringsnummer-feltene.
Resultatet blir en linje for hver linje i Tabell 7.5, og hver av dem vil ha
antallet 1.
1096 - Lars Marius Garshol 40

7.6 Datamanipulasjon med spørringer
Innføring i databaser
Så langt har vi bare snakket om utvalgsspørringer, men det finnes også datamanipuleringsspørringer.
Disse kan brukes til å systematisk bearbeide data, og er svært praktiske siden de
kan utløses fra trykk på knapper i skjemaer og andre hendelser. Det fine med dette er at du via
et knappetrykk kan oppdatere 1000 poster på to sekunder.
De viktigste typene er:
Navn Funksjon
Oppdaterings- Endrer dataene i enkelte felter i de utvalgte postene
Føy til- Legger inn nye poster i en tabell
Slette- Sletter de utvalgte postene fra en tabell
Tabell 7.7
Du velger den spørringstypen du vil ha i Spørring-menyen.
Slettespørringer er de enkleste å bruke. De fungerer akkurat som en utvalgsspørring, bortsett
fra at de sletter de postene utvalgsspørringen ville vist frem. (Dataark-visning viser deg postene
som ville blitt slettet om du hadde kjørt spørringen, eller valgt Spørring|Kjør i menyen.)
Oppdateringsspørringer har en ekstra rad i design-vinduet. Der skriver du et uttrykk som
beskriver hva feltet som står øverst skal endres til.
Dersom du velger en Føy til-spørring må du først velge hvilken tabell de nye postene skal føyes
til. Deretter dukker det opp en ekstra rad i design-vinduet som heter 'Føy til'. Der velger du
hvilket felt spørringsfeltet skal settes inn i.
1096 - Lars Marius Garshol 41

8. Oppbygning av grensesnitt i Windows
8.1 Skjematyper og deres rekkefølge
Innføring i databaser
De fleste databaser har store likheter, og det gjør at det finnes en del greie klisjeer for oppbygningen
av grensesnittene. Særlig er det noen typer skjemaer som er vanligere enn andre, og
de gjennomgår jeg her. Du er ikke nødt til å lage dine egne databaser akkurat slik, men det kan
være greie tips å ha med seg.
Utformingen av brukergrensesnitt er noe det forskes mye på i disse dager. Vi skal ikke gå så
veldig dypt i dette, men husk: databasen din bør være enkel å bruke (brukerne bør spares for
unødvendig venting og tasting), enkel å forstå (brukerne bør kunne forstå hva de gjør) og den
bør være behagelig å se på.
8.1.1 Hovedmeny
Brukerne dine bør være beskyttet mot å måtte sitte og navigere rundt i databasen ved hjelp av
databasevinduet. Istedet bør du lage et eget skjema som fungerer som hovedmeny. Derfra skal
alle funksjoner som brukeren skal kunne utføre være tilgjengelige. Det er best å ikke ha data i
hovedmenyen, men istedet bare mulighetene til å velge mellom forskjellige skjemaer. Dersom
databasen er stor kan disse igjen være hovedmenyer for sine deler av databasen.
Hovedmenyen bør ha: overskrift som forklarer hvilken database dette er, en knapp for hvert
skjema brukeren kan gå til og kanskje et bilde til pynt og illustrasjon.
Et litt mer avansert, men ikke nødvendigvis bedre alternativ er å definere sin egen menylinje
istedetfor en hovedmeny. Du kan ha de samme valgene, men du gjør dem tilgjengelige på en
annen måte.
8.1.2 Velg post-skjemaet
Du har sannsynligvis mange poster i databasen din, og mange data om hver enkelt post. Det er
derfor greit å dele endringen av data opp i to skjemaer: et til å velge posten som skal endres,
og et til å gjøre endringene.
Det første skjemaet bør ikke vise mer data om hver enkelt post enn det som trengs til å
identifisere posten for brukeren. Dette kan gjøres enten ved å bruke detalj-delen av skjemaet
(se avsnitt 9.3), eller ved å bruke en listeboks (se avsnitt 9.2). Postene bør være sortert, ellers
blir det vanskelig å finne fram.
Skjemaet bør også ha en overskrift og noen knapper. Følgende knapper bør være med: lukk
skjema, opprett ny post, slett denne posten og endre denne posten. Det siste kan det være flere
knapper for, spesielt hvis vi fra denne posten er interessert i å gå inn i flere andre tabeller.
Dette skjemaet kan fungere som endre data-skjema også hvis tabellen har så få felter at du kan
se alle samtidig.
1096 - Lars Marius Garshol 42

Innføring i databaser
8.1.3 Endre data-skjemaet
Dette skjemaet viser frem de interessante dataene om posten. (Av og til er det så mange data at
det lønner seg å splitte dem på flere skjemaer.) Skjemaet bør ha en overskrift, og for hvert felt
bør det være en etikett (med feltets navn) og en kontroll. Enten en tekstboks, listeboks,
kombinasjonsboks, merkefelt eller annet. Disse skjemaene blir ofte rotete, så det lønner seg å
legge kontrollene mest mulig på linje med hverandre og systematisere det hele så mye som
mulig.
8.2 Hvordan lage et grensesnitt
For noen går dette automatisk (særlig de som har endel trening og erfaring), mens andre sliter
med å finne ut hvordan de skal bygge opp grensesnittene til programmene sine. Dette vil sannsynligvis
komme seg etterhvert som du får mer erfaring, men før du får det lønner det seg å
være metodisk og grundig.
Begynn med å lage en liste over enkelthandlinger bruker sannsynligvis er interessert i å utføre.
Dette bør være ting som (for å holde oss til eksempelet vårt): slette bil, slette person, endre
data om person etc.
Deretter bør du begynne å planlegge skjemaene dine ved å tegne dem på papiret, og sette opp
på et eget ark forbindelsene dem imellom. Mens du gjør dette bør du forsøke å holde tommelfingerreglene
klart for deg og prøve å tenke på hvordan du helt konkret skal få dette til i
Access. Prøv også å bygge systemet opp etter det skjemasystemet jeg foreslo i avsnitt 8.1.
8.3 Tommelfingerregler for skjemaer
Å lage et godt brukergrensesnitt er svært vanskelig, og selv store datafimaer har tabbet seg ut
på dette. Det krever også trening og forståelse for hvordan brukeren jobber, samt kunnskap
om hvordan mennesker oppfatter hva de ser. Den ideelle brukergrensesnittdesigner er selv
bruker og programutvikler, samt psykolog og tankeleser. (Mao: han/hun finnes ikke.)
Her er imidlertid noen tommelfingerregler som kan være greie å ha:
• Sørg for gode navn på alle felter, knapper og skjemaer. Gode navn er korte, men likevel
forståelige for brukeren. Det viktigste er at de er konsekvente! Samme ting må hete det
samme overalt.
• Tabulatorrekkefølgen må være naturlig.
• Bruk så få farger og skriftsnitt (fonter) som mulig. Alt annet blir bare forvirrende for
brukeren.
• Sørg for at kontrollene ligger på linjer.
• Det lønner seg å samle feltene i en gruppe, og ha knappene for seg. Ting som hører sammen
bør stå sammen.
• Ikke ha for mange elementer i ett skjema. Synes du det blir for mye så del det på flere
skjemaer.
• Skjemaene bør ligne på hverandre. Prøv å gjøre tingene på samme måte overalt i samme
database. Du kan f.eks. ha en fast farge på overskriftene dine og en fast farge på Lukkknappen.
1096 - Lars Marius Garshol 43

8.4 Småtips
Innføring i databaser
Dersom du har veldig mange poster kan det være lurt å utvide velg post-skjemaet med et par
kontroller som du kan bruke til å begrense postene som vises. Når du søker på person kan du
f.eks. ha et felt der du kan skrive inn en del av navnet, og en knapp som da viser bare personer
med navn som inneholder denne teksten.
Det kan også være en ide å begrense antall skjemaer brukeren må igjennom for å komme dit
han/hun vil. Alle disse skjemaene må jo lukkes igjen, og det kan bli en plage.
Det kan også være lurt å lage et spesielt skjema med informasjon om programmet. Der bør det
stå hva programmet heter, hvem som har laget det, og kanskje en del annen informasjon, som
når det er laget osv. Det lønner seg også å ha med et versjonsnummer på programmet, slik at
du enkelt kan se om en utgave av det er den siste eller ikke. Dersom programmet skal kopieres
til flere maskiner er dette ganske viktig. Et slikt skjema kan også fungere som reklame for deg
selv som programutvikler.
1096 - Lars Marius Garshol 44

9. Skjemaer i Access: Bakgrunn
9.1 Hva er et skjema?
Innføring i databaser
Et skjema i Access er et dokumentvindu. Det kan inneholde hva som helst som vanlige vinduer
kan inneholde, og fungerer som vinduer i andre programmer. Det vinduer brukes til er å vise,
endre og skrive inn data, samt å velge mellom forskjellige handlinger programmet tilbyr.
Eksempler på det siste kan være å lukke skjemaer, åpne nye skjemaer, utløse
handlingsspørringer eller vise rapporter.
Du kan selvfølgelig lage en database basert kun på tabeller og spørringer, men da er det
tvilsomt om noen andre enn du kan bruke den, og særlig pen blir den ikke. For å gjøre
databasen mer brukervennlig kan du lage et brukergrensesnitt mellom selve databasen og
brukeren. Dette er det du gjør med skjemaene du lager.
9.2 Hva består et skjema av?
Et skjema er som sagt et vindu, og består av de samme kontrollene som vanlige Windowsvinduer.
De kan deles i to grupper: de standardiserte som sitter på vinduskantene, som
rullefelter, postvelger, kontrollmeny-boks osv og de som du selv plasserer i vinduet.
Etikett
Tekstfelt
Kombinasjonsboks
Listeboks
Figur 9.1
Kontrollboks
Postvelgere
Rullefelt
Størrelse-knapper
Navigasjonsknapper
1096 - Lars Marius Garshol 45

Innføring i databaser
De forskjellige kontrollene fungerer på forskjellige måter og har forskjellige funksjoner. Vi kan
dele dem i to typer: handlingskontroller og datakontroller. Handlingskontrollene utløser en
handling, men forandrer ikke data direkte, slik datakontrollene gjør.
Jeg regner med at dere allerede kjenner til hvordan man bruker disse kontrollene, og nøyer med
meg å ha satt navn på dem her.
9.3 Skjemaets deler
Når du designer et skjema i Access kan det bestå det av opptil fem deler. Disse er i rekkefølge:
• topptekst i skjema
• topptekst på side
• detalj
• bunntekst på side
• bunntekst i skjema
Topp- og bunntekstene på side brukes bare ved utskrift på printer, og er derfor ikke interessante
for oss. Topp- og bunnteksten hentes fram ved å velge Vis | Topptekst/bunntekst i
skjemaet.
Dersom du baserer et skjema på en spørring vil topp- og bunnteksten vises en gang hver,
henholdsvis øverst og nederst på skjemaet. Imellom dem gjentas detaljen en gang for hver rad i
spørringen. Dermed brukes topp- og bunntekst til overskrifter, generelle kontroller og
lignende, mens detaljen brukes til å vise data fra radene i spørringen.
9.4 Skjemaveiviserne
Dersom du vil lage et skjema tar du opp Skjema-kortet i databasevinduet og trykker Ny. Du vil
da bli spurt om du vil lage skjemaet selv eller om du vil ha hjelp av en veiviser. Veiviserne kan
være svært greie og spare deg for mye kjedelig tegnearbeid. Når veiviserne har laget et skjema
for deg er det et vanlig skjema som alle andre og kan redigeres og justeres manuelt. Veiviserne
har imidlertid sine helt klare begrensninger, så du vil ofte være nødt til å lage dine egne
skjemaer fra bunnen av.
De forskjellige veiviserne er
• AutoSkjema
Denne veiviseren lager et nytt skjema direkte. Skjemaet er basert på den valgte
tabellen/spørringen og viser alle feltene i kun en post i vinduet samtidig. Du må bruke
postvelgerne til å bla mellom postene. Denne typen skjemaer anbefales ikke alene siden de
gir så liten oversikt. De kan imidlertid brukes som vis/endre data-skjema.
• Enkolonneskjema
Denne varianten ligner svært på AutoSkjema, men lar deg velge mellom flere designvarianter
og feltene i skjemaet.
• Tabellskjema
1096 - Lars Marius Garshol 46

Innføring i databaser
Denne veiviseren lager skjemaet på samme måte som enkolonne-veiviseren, men legger alle
feltene i en rad istedet, slik at du får plass til flere poster i vinduet samtidig. Denne varianten
blir ikke særlig pen, men den blir langt mer oversiktlig enn enkolonne-varianten, og kan
brukes som både velg post-skjema og endre data-skjema, hvis det ikke er for mange felter.
• Diagram
Denne veiviseren lar deg lage skjemaer som viser grafer av dataene i en spørring/tabell. Den
er svært hendig for å lage skjemaer som ellers hadde vært vanskelige å lage, og som tar seg
svært bra ut grafisk. Selve diagrammet er ett enkelt objekt fra MS Graph, som egentlig ikke
er en del av Access i det hele tatt, men som følger med Office-pakken.
• Hovedskjema med delskjema
Denne veiviseren lar deg lage skjemaer som inneholder et nytt skjema inne i seg. De egner
seg godt til å vise en post i en tabell, og en rekke tilknyttede poster i en annen tabell.
9.5 Jobbe med kontroller
I et skjema oppretter du enklest en ny kontroll fra verktøylinjen du får opp ved å velge
Vis|Verktøylinjer i skjema-design-visning. Det gir deg verktøylinjen under.
Peker
Etikett
Alternativgruppe
Alternativknapp
Kombinasjonsboks
Diagram
Linje
Sideskift
Veivisere av/på
Tekstboks
Veksleknapp
Avkrysningsboks
Listeboks
Delskjema
Rektangel
Kommandoknapp
Verktøylås
Figur 9.2
Bortsett fra de to nederste knappene, som er av/på-knapper, og den øverste, som brukes til å
velge kontroller er alle knappene tegneverktøy. Du velger det verktøyet du ønsker, trekker det
opp på skjemaet, og vips så er det opprettet. Dersom veiviser-knappen er nede og kontrollen
har en veiviser, vil en dukke opp for å hjelpe deg med designet.
Siden kan du velge en hvilken som helst kontroll. En rekke svarte rektangler vil da komme opp
rundt kontrollen. Disse kan du dra i for å endre størrelsen på kontrollen, eller du kan flytte
kontrollen ved å dra midt på den. Kontrollen plasserer seg på et rutenett i skjemaet så lenge
Format | Fest til rutenett er valgt. Dette kan du unngå ved å holde inne Ctrl mens du drar.
1096 - Lars Marius Garshol 47

Innføring i databaser
Dersom du har paletten oppe (Vis|Palett), kan du velge kontrollen og så endre farge på den
ved å trykke på paletten. Kontrollens egenskaper kan også redigeres ved å velge kontrollen og
trykke høyre mustast.
9.5.1 Hvordan velge kontroller
Kontroller kan velges på flere måter. Du kan velge dem en for en ved å klikke direkte på dem,
eller du kan holde shift inne mens du klikker på dem. Hvis du holder shift inne idet du trykker
på et element som ikke er valgt velges det i tillegg til allerede valgte elementer, men hvis det
var valgt slutter det med å være det.
Du kan også dra et rektangel over de elementene du vil velge. Alle elementene som er inne i
dette rektangelet vil bli valgt. Og dersom du klikker på linjalene (enten den vertikale eller den
horisontale) vil alle elementer som ligger på akkurat den høyden/bredden velges. Du kan også
klikke og dra på linjalene, slik at alle som ligger i det intervallet du drar over velges.
9.5.2 Egenskaper
Alle deler av en Access-database har egenskaper. For et skjema vil dette si slike ting som navn,
overskrift, hvilken spørring det er basert på osv. Egenskapene til et objekt vil altså avgjøre
hvordan det oppfører seg.
Egenskapene til et objekt kan endres ved at du klikker på objektet med høyre mustast, og
velger Egenskaper i hurtigmenyen som da kommer frem.
1096 - Lars Marius Garshol 48

10. Skjemaer i Access: Detaljene
10.1 Hvordan kontrollene fungerer
Innføring i databaser
De fleste kontrollene er enkle å bruke, men det er en del ting som bør nevnes i forhold til
hvordan de skal lages.
10.1.1 Hendelser
Hver gang du klikker i et vindu eller trykker på en tast skjer en ‘hendelse’. Hver gang en
hendelse inntreffer i et vindu eller en kontroll utløses en ‘hendelseshåndterer’ (event handler),
som avgjør hva som skal skje. Denne er tilgjengelig som en egenskap ved vinduet/kontrollen,
og kan være enten et uttrykk, en makro eller en prosedyre i Access Basic.
10.1.2 Tekstbokser
Tekstbokser er som regel tilordnet et felt i spørringen som skjemaet er basert på. Da vises
feltverdien til gjeldende post i boksen, og dersom bruker endrer denne verdien vil feltverdien
også endres idet gjeldende post skifter eller vinduet lukkes. Mao: tabellen oppdateres når du
velger en ny post eller vinduet lukkes. Tekstboksene oppdateres fra tabellene stadig vekk, slik
at hvis verdien skulle endres et annet sted vil du kunne se det straks.
Du kan også lage en tekstboks som ikke er tilknyttet noe felt, denne vil da fungere som de
andre tekstboksene, men vil ikke oppdatere noe felt. Verdien er likevel tilgjengelig i spørringer,
makroer og prosedyrer som [forms]![Skjemanavn]! [Kontrollnavn]. Dette krever imidlertid at
skjemaet er åpent, ellers vil du få en feilmelding.
10.1.3 Kombinasjons- og listebokser
Kombinasjonsbokser og listebokser viser data i ‘tabellform’, så de kan ikke vise enkle felter
slik en tekstboks kan. Det de viser er spørringer eller tabeller, med utvalgte felter fra utvalgte
poster, og du velger en av postene. Det som lagres i kontrollen er verdien i ett av feltene (det
bundne feltet) i den valgte posten. Hvilket felt dette er velger du når du lager boksen.
Hvis boksen skal oppdatere ett felt i en tabell må det bundne feltet inneholde den verdien som
skal lagres i det feltet som skal oppdateres. For fremmednøkler vil dette være primærnøkkelen.
Kombinasjons- og listebokser oppdateres ikke automatisk, siden dette vil kreve for mye datakraft.
Istedet kan du oppdatere dem med Access Basic-kommandoen «DoCmd Requery
[Boksens navn]». Denne kommandoen kan du sette inn i de hendelsesprosedyrene du måtte ha
behov for den i.
10.1.4 Knapper
Når en knapp trykkes ned utføres hendelseshåndtereren til knappen. Denne vil utføre det som
skal skje når knappen trykkes ned. Hendelseshåndtereren skrives av veiviseren hvis denne er
istand til det, hvis ikke må du skrive den selv. Du kan også endre kode skrevet av veiviseren.
1096 - Lars Marius Garshol 49

Innføring i databaser
Dersom du lærer deg Access Basic kan du gjøre svært mye mer enn det du er istand til å få til
uten. Vi kan imidlertid ikke gå inn på det i dette kurset, ettersom det ville kreve altfor mye tid.
10.2 Viktige egenskaper ved kontroller
De fleste kontroller har en del egenskaper felles. En av dem er ‘Navn’, som er det den høres ut
som. Dette er navnet du bruker til å henvise til kontrollen i et uttrykk eller andre steder.
‘Kontrollkilde’ er det feltet i den underliggende tabellen/spørringen som kontrollen henter sine
data fra og oppdaterer.
‘Tittel’ er teksten som står på kontrollen for å beskrive den overfor brukeren.
‘Tekstjustering’ angir om teksten skal være inntil venstre eller høyre kant, eller eventuelt være
midtstilt.
‘Spesialeffekter’ kan brukes til å gjøre det visuelle mer spennende, ved å få f.eks. en boks
(tekst-, liste- eller kombinasjons-) til å være opphøyd eller senket. Her går det an å prøve seg
frem for å se hva som gir best resultat.
10.3 Hvordan lage en kombinasjonsboks
Kombinasjonsbokser er greie å ha når vi har en fremmednøkkel som er koblet til en annen
tabell og i et skjema trenger å velge en tilhørende post i den tilkoblede tabellen. Den kan også
brukes til å velge når du har en liste med forskjellige verdier et felt kan ha.
Skrittene i kombinasjonsboks-veiviseren er:
1. Først må du velge om du vil at veiviseren skal slå opp verdiene i en spørring/tabell eller om
du skal skrive inn verdiene den kan ta. Dersom du velger det siste er neste skritt å velge
antall kolonner, samt å skrive inn verdiene. Hvis boksen er koblet til en fremmednøkkel skal
vi slå opp verdiene i den tilkoblede tabellen (evt via en spørring.)
2. Neste skritt er å velge hvilken tabell/spørring kombinasjonsboksen skal hente sine verdier.
3. Så må du velge hvilke felter du vil skal vises i kombinasjonsboksen. Hvis boksen er koblet
til en fremmednøkkel må primærnøkkelen være med her. (Sett den opp først av alle.) Ta
også med akkurat mange nok felter til at brukerne kan se hvilke poster de har å velge
mellom.
4. Så skal du sette kolonnebredden til de forskjellige kolonnene. Har du tatt med en
primærnøkkel som ikke er av interesse for brukeren setter du kolonnebredden dens til 0.
5. Deretter spør Access hvilken av kolonnene den verdien vi skal lagre befinner seg i. Er
boksen koblet til en fremmednøkkel er svaret primærnøkkelen.
6. Så må du velge om boksen skal være koblet til et felt i den underliggende tabellen (og i
tilfelle hvilket), eller om den skal være frittstående.
7. Tilslutt gjenstår det bare å sette navnet, og kombinasjonsboksen din er ferdig.
1096 - Lars Marius Garshol 50

10.4 Hvordan bygge opp et skjema
Innføring i databaser
10.4.1 Endre data-skjema
Først lager vi et endre data-skjema for tabellen T_Bil i eksempel-databasen. Det gjøres enklest
ved å opprette en spørring kalt ‘Q_Billiste’, som ganske enkelt viser alle feltene i T_Bil,
unntatt Eier. Der henter du istedet inn Navn fra T_Person. Deretter lager du et enkolonneskjema
basert på alle feltene i denne spørringen. Det skjemaet ser slik ut:
Figur 10.3
Siden dette er ment å være et vanlig endre data-skjema tar vi vekk postvelgerne og
navigasjonsknappene. Det gjøres ved å gå til design-visning med Vis|Skjemadesign og klikke
med høyre mustast i det hvite feltet oppe til høyre. Da får du opp et vindu med såkalte
egenskaper. Der setter du postvelgere, navigasjonsknapper og rullefelter til Nei.
Så kan vi flytte litt rundt på kontrollene, og strekke dem litt for at de skal passe bedre med
feltstørrelsene.
Fargene ligger nå i en egen tabell, slik at istedet for å taste inn fargene for hånd, og håpe på at
vi staver dem riktig hver gang, bruker vi en kombinasjonsboks til å velge dem med. (Det
samme gjelder eier, men der er det så mange poster at vi velger å la det stå. I en skikkelig
database ville vi gjort noe med den.)
Vi lager da en Q_Fargeliste som inneholder FargeNr og Navn og sorterer på Navn. Så kan du
slette tekstboksen Farge og dens etikett, og opprette en kombinasjonsboks der istedet.
Veiviseren vil da la deg plukke ut begge feltene i Q_Fargeliste, og justere kolonnebredden til
hvert av dem. Der setter du kolonnebredden til FargeNr til 0, slik at den ikke synes selv om
den er der. FargeNr er nemlig den kolonnen som har verdiene vi trenger. T_Bil har en Farge,
som er fremmednøkkel til T_Farge, og der lagres jo fargenummeret. Verdien skal altså lagres i
feltet Farge. Etiketten er grei: den skal hete Farge. Så må du bare gå inn og sette listeboksens
egenskap ‘Tekstjustering’ til Venstre, og alt er iorden.
1096 - Lars Marius Garshol 51

Innføring i databaser
Det eneste som mangler da er en knapp til å lukke skjemaet med. Den er ikke absolutt
nødvendig, siden det går an å gjøre det via kontrollboksen, men vi tar det med for å illustrere
hvordan man lager en knapp.
Knappen lages via knappeverktøyet på verktøylinjen. Først må du imidlertid utvide Bunntekst i
skjema, ved å dra i den nedre kanten. Deretter kan du tegne på knappen. Som kommando
velger du Skjemaoperasjoner|Lukk skjema. Resten av veiviseren er mest et spørsmål om
personlig smak, så der kan du gjøre som du vil.
Skjemaet ser nå slik ut:
1096 - Lars Marius Garshol 52

Figur 10.4
Innføring i databaser
10.4.2 Velg post-skjema
Etter å ha laget endre data-skjemaet kan vi lage velg post-skjemaet. Der velger du hvilken post
som skal vises i endre data-skjemaet. Også dette kan lages med utgangspunkt i Q_Billiste, bare
vi endrer den til å sortere på Registreringsnummer. Her kan vi velge om vi vil lage et
tabellskjema med en veiviser, eller om vi vil lage skjemaet selv fra bunnen av og basere
velgingen på en listeboks istedet. Det siste er penest og enklest for bruker, men det første er
raskest.
Siden det første er så enkelt og gir liten læregevinst kan vi velge det andre, og heller bare gi et
kortfattet referat av prosessen. Vi starter med å opprette et tomt skjema som ikke er basert på
noen spørring. (Få opp verktøykassen, paletten og skjema-design-verktøylinjen dersom de ikke
kommer opp av seg selv.)
Så er det bare å velge detalj-delen og sette bakgrunnsfargen til vanlig Windows-grå. Deretter
setter vi inn overskriften “Velg bil” og midtstiller den. Mens den er valgt kan skrifttype, -
størrelse og justering endres med skjema-design-verktøylinjen. Bakgrunnsfargen må også
endres med paletten.
Før vi lager listeboksen midt i vinduet må vi lage en spørring som henter
Så er det bare å trekke opp en listeboks midt i vinduet. Den skal vise verdier fra spørringen
‘Q_Billiste’, nærmere bestemt feltene ‘Registreringsnummer’, ‘Merke’ og ‘Eier’. Så må
kolonnebreddene justeres, og feltet ‘Registreringsnummer’ velges som det interessante feltet i
boksen. Boksen kan f.eks. døpes ‘Valgt bil’. Så oppretter veiviseren boksen for deg, og du kan
nøye deg med å plassere den på nytt, siden veiviseren endrer bredden på den. For å gjøre
skjemaet litt penere kan vi endre egenskapen ‘Spesialeffekt’ til ‘Senket’.
Det eneste som gjenstår da er kommandoknappene. I koden til disse knappene brukes av og til
skjemanavnet, og før du har lagret er det ‘Skjema1’, så du må lagre skjemaet først.
Vi trenger knappene ‘lukk’, ‘ny’, ‘vis’ og ‘slett’. Lukk lages på samme måte som før. ‘Vis’
lages ved å velge kommandoen ‘Åpne skjema’ i veiviseren, og skjemaet ‘F_Bil’, som vi lagde i
1096 - Lars Marius Garshol 53

Innføring i databaser
forrige avsnitt. Vi ønsker å vise bestemte data i skjemaet F_Bil, og velger å koble feltene
‘Valgt bil’ (som jo inneholder registreringsnummer, det valgte vi ovenfor) med
‘Registreringsnummer’. Da vil bilen med samme registreringsnummeret den som ble valgt i
listeboksen bli vist, og siden registreringsnummer er primærnøkkel må dette være samme bilen.
‘Ny’-knappen er litt småvanskelig. Kommandoen er ‘Ny post’, men vil ikke fungere alene.
Hadde vi laget en tabell-rapport ville det gått greit, men som det er vet ikke Access hvilken
tabell den skal lage en ny post i, og den vet ikke hvilket skjema den skal vises i. Alt dette
ordnes ved å klikke ‘Bygg hendelse’ i hurtigmenyen til knappen, og sette inn linjen DoCmd
OpenForm “F_Bil” over linjen med DoCmd GotoRecord ... Dette er en
instruksjon i Access Basic som åpner skjemaet F_Bil. Deretter viser den andre instruksjonen en
ny post i skjemaet. Når F_Bil lukkes vil ikke dataene i listeboksen oppdateres av seg selv. Det
kan ordnes ved å legge inn en linje etter DoCmd Close på lukk-knappen i F_Bil der det står
DoCmd forms![F_Velg bil]![Valgt bil].Requery. Dersom F_Velg bilskjemaet
ikke er åpnet vil dette ikke fungere, og du vil få en feilmelding. Det får heller være...
‘Slett’-knappen er også litt tung. Hadde skjemaet vært et tabell-skjema ville det ikke vært noe
problem, men som det er blir det tungvint. Da kunne veiviseren gjort jobben dersom du valgte
kommandoen ‘Slette post’. Som det er kan vi lage en slettespørring og utløse den fra knappen.
Lag en slettespørring som sletter en post med registreringsnummer lik [forms]![F_Velg
bil]![Valgt bil]. Dette uttrykket betyr innholdet i kontrollen [Valgt bil] i skjemaet [F_Velg bil]
([forms] betyr skjemaer.) Denne spørringen kan du kalle ‘Q_Slett bil’.
Så kan du skru av veiviserene og tegne knappen (og sette på veiviserene igjen.) Du kan endre
teksten på knappen ved å dobbeltklikke på den. Deretter kan du lete opp egenskapen ‘Ved
klikk’ og trykke på ‘...’ på høyrekanten i vinduet, velg så ‘Kodebygger’ og skriv:
DoCmd OpenQuery “Q_Slettbil”
DoCmd Requery “Valgt bil”
Dette skal stå mellom de to linjene som allerede er i vinduet. Den første linjen åpner
slettespørringen som sletter den bilen som er valgt med listeboksen, mens den andre oppdaterer
postene i listeboksen.
Vinduet kan da f.eks. se slik ut:
1096 - Lars Marius Garshol 54

Figur 10.5
Innføring i databaser
10.4.3 Hovedmeny-skjemaet
Så kan vi lage hovedmenyen. Der lager vi en overskrift, en avslutt-knapp og knapper for de
forskjellige delene av programmet. Vi kan f.eks. lage en for kundelisten og en for en enkel
fargeliste. Det eneste som er nytt her er avslutt-knappen, der kommandoen ligger under
‘Applikasjon’ og heter ‘Avslutt program’.
For øvelsens skyld kan vi også legge inn et lite ClipArt-bilde. Du må da velge verktøyet for
OLE-objekter, og så velge Microsoft Clip Art. Så er det bare å velge bildet du vil ha, i vårt
tilfelle velger vi en bil.
Hovedmenyen ser da slik ut når vi er ferdige:
1096 - Lars Marius Garshol 55

Figur 10.6
Innføring i databaser
10.4.4 Skjema med underskjema
Tilslutt kommer rosinen i pølsa: et skjema med underskjema. Vi bør ha et skjema der vi legger
inn eiere, og der kan godt bilene de eier vises i et underskjema. For å få til dette trenger vi et
velg post-skjema for eiere og baserer det på en spørring vi kaller Q_Eierliste. Så må vi lage en
spørring til underskjemaet, den må inneholde de interessante dataene fra T_Bil slik at vi kan
vise dem i underskjemaet, og Eier, slik at vi kan vise bare de bilene personen eier. Vi kan kalle
den Q_Eide biler.
Selve skjemaet lages med Skjema med underskjema-veiviseren, og baseres på Q_Eiereliste,
mens underskjemaet som sagt baseres på Q_Eide biler. På hovedskjemaet skal alle feltene
unntatt ID, som jo ikke er interessant for noen, vises, mens på underskjemaet tar vi med
Registreringsnummer og Merke. (Eier behøver ikke vises, den må bare være i spørringen.)
Mens veiviseren lager skjemaet spør den om navnet på underskjemaet, det er som det skal
være. Den klarer heller ikke å lage en kobling mellom skjemaene selv, men det kan vi ordne for
den. Etter å ha tatt vekk postvelgere, navigasjonsknapper og rullefelter kan du gå inn på
egenskapene til underskjemaet. Der må KobleOverordnetFelt og KobleUnderordnetFelt settes
til henholdsvis ID (som er i hovedskjemaet) og Eier (som er i underskjemaet).
Da er skjemaet klart, og ser slik ut:
1096 - Lars Marius Garshol 56

Figur 10.7
Innføring i databaser
1096 - Lars Marius Garshol 57

11. Rapporter i Access
11.1 Skjemaer/rapporter - forskjeller og likheter
Innføring i databaser
Skjemaer og rapporter er svært like, forskjellen er stort sett at rapporter er helt passive og
beregnet på å skrives ut. Det betyr at innholdet i tekstboksene ikke kan endres og at knapper,
listebokser, kombinasjonsbokser og andre kontroller ikke finnes.
I tillegg kommer det inn en del nye ting, som sideinndeling, topp- og bunntekster og slikt. Det
er også lagt en del bedre til rette for aggregatfunksjoner og gruppering i rapporter enn i
skjemaer.
I en jobbsituasjon der noen har bestilt databasen blir det ofte mange rapporter, og mye pirk
over hvordan de skal se ut. Brukerne har som regel enten meget bestemte, men svært uklare
krav til hvordan rapportene skal se ut, eller svært klare og helt ufravikelige meninger.
11.2 Hvordan lage rapporter
Rapporter lages på samme måte som skjemaer. Elementene redigeres og endres på samme
måte, og inndelingssystemet er det samme. Veiviserene er også stort sett de samme som for
skjemaer. (Se avsnitt 11.5.)
Inndelingene følger det samme systemet som i skjemaene, men er litt mer avanserte. Følgende
inndelinger finnes:
• Topp-/bunntekst i rapport
Dette er en del som kommer aller øverst i rapporten og aller nederst.
• Topp-/bunntekst på side
Denne delen gjentas øverst og nederst på hver side, uavhengig av alt annet.
• Topp-/bunntekst til gruppering på felt
Det som står her gjentas en gang for hver verdi i feltet du har gruppert på. Det er fullt mulig
å ha flere slike og dermed få grupper inne i grupper. Detaljene følger den innerste
grupperingen. Eksempelvis kunne man gruppere soldatene først på kompani, og deretter på
tropp, og la detaljen være enkeltsoldater.
Det er da mulig å gjøre separate beregninger for kompani og soldat, og også mulig å
kombinere disse. Mer om dette i avsnitt 11.6.
• Detalj
Detaljen er eksakt den samme som i skjemaer.
1096 - Lars Marius Garshol 58

11.3 Et enkelt eksempel
Innføring i databaser
Vi lager en enkel rapport, bare for å illustrere hvordan det gjøres. Har du fått til skjemaer
skulle du ikke ha store problemer med dette. Jeg velger å lage en liste over alle bileierene i
databasen. Den baseres på en dertil egnet spørring (Q_Personer), og lages fra bunnen av.
I ‘topptekst side’ setter vi inn et tekstfelt med teksten ‘Bileieroversikt’ som midtstilles og
gjøres stor. Deretter settes kolonneoversikter inn under, og en linje trekkes under disse. (Siden
må utvides til 16 på den horisontale linjalen for å få plass til alt.)
Under detalj settes feltene inn. Det lønner seg å bruke Ctrl til å gjøre detaljen så liten som
mulig, slik at listen ikke tar mer plass enn nødvendig.
Tilslutt kan vi sette inn en liten festlig sak på bunntekst side. Trekk opp feltet, og gå inn på
egenskapen kontroll-kilde med de tre prikkene (...) til høyre. I uttrykks-byggeren kan du velge
‘Vanlige uttrykk’ og ‘Sidetall’. Nå vil sidetallet vises der du trakk opp feltet. (Pass på å at det
står = aller først i feltet.)
Prøv dette selv for å få se resultatet.
11.4 Hvordan bruke en rapport
Når en rapport åpnes kjøres spørringen den er basert på, og vi får noe som ser ut som et Worddokument.
Det kan enten forhåndsvises på samme måte, eller skrives ut på samme måte, men
den kan ikke endres direkte.
Også fra knapper i skjemaer kan en av to kommandoer utløses: forhåndsvis rapport eller skriv
ut rapport. Begge ligger under rapport-operasjoner i knapp-veiviseren.
Utskrift gjøres med Ctrl+P, og derfra fungerer alt som ellers i Windows. Nederst på skjermen
er det navigasjonsknapper som kan brukes til å bla mellom sidene, mens musa kan brukes til å
zoome inn og ut. (Et klikk er inn, deretter er neste ut, og så inn igjen... Det zoomes inn på
stedet der du klikket.)
11.5 Rapportveiviserne
Akkurat som for skjemaer finnes det en rekke rapportveivisere som hjelper deg med å lage
rapporter. De er nyttigere enn skjemaveiviserene, i og med at resultatet ikke blir så stygt som
for skjemaene. De sparer deg som regel også for masse småjustering og fikling, selv om det
alltid er litt igjen.
Veiviserene er:
1096 - Lars Marius Garshol 59

Innføring i databaser
Navn Beskrivelse
Enkolonne Som enkolonne for skjemaer, nesten ubrukelig.
Grupper/totaler Se avsnitt 11.6.2.
Etiketter Brukes til adresseetiketter og andre typer etiketter.
Summering Som grupper/totaler, men med litt ekstra for summeringer.
Tabell Som tabell for skjemaer.
AutoRapport Som AutoSkjema.
11.6 Rapporter med gruppering
Tabell 11.1
11.6.1 Hva er gruppering, og hvorfor bruke det?
Gruppering for rapporter er akkurat det samme som for spørringer, men man kan gjøre litt
andre ting med det. (Gruppering i spørringer står forklart i avsnitt 7.5.4.) Dersom du for
eksempel vil vise alle kurs og for hvert kurs alle påmeldte soldater vil du dersom du ikke
grupperer få noe a la Tabell 11.2.
Kursnavn Soldat
Innføring i databaser Stein Arne Slåtten
Innføring i databaser Ingvald Strømme
Innføring i databaser Tommy Wilson
Strikkekurs Kjetil Ravnås
Strikkekurs Arvid Gundersen
Tabell 11.2
Dette er resultatet fra spørringen. Hvis vi nå lager en rapport der detaljen inneholder Kursnavn
og Soldat, og så har en topp- og bunntekst i rapporten vil rapporten se ut omtrent som
spørringen. Problemet med det er åpenbart: kursnavnet gjentas for hver eneste soldat. Da er en
løsning av følgende type langt mer interessant:
1096 - Lars Marius Garshol 60

Innføring i databaser
Stein Arne Slåtten
Ingvald Strømme
Tommy Wilson
Strikkekurs
Kjetil Ravnås
Arvid Gundersen
Påmeldinger
Innføring i databaser
Dette kan du få til ved å gruppere på kurs og ha en egen topp- og bunntekst for hvert kurs.
11.6.2 Grupperingsveiviseren
Grupperingsveiviseren guider deg gjennom det å lage en rapport med gruppering. Som regel er
dette den greieste måten å gjøre det på. Som eksempel skal vi lage en oversikt over bilene til
hver enkelt bileier, basert på spørringen i Figur 7.4.
Ny rapport opprettes ved å velge rapportkortet i databasevinduet og trykke Ny-knappen.
Deretter velger du spørringen den skal baseres på og Grupper/totaler-veiviseren.
Deretter går veiviseren gjennom følgende skritt:
1. Velg ut feltene som skal være med i rapporten. Dette er kjent kost fra skjemaene.
2. Velg feltene du vil gruppere på i rekkefølge. Dette fungerer på samme måte som skritt 1.
3. Her velger du hvordan du skal gruppere på hvert enkelt felt. Dette kan du bare hoppe over i
99% av tilfellene.
4. Så må du avgjøre hvordan du vil sortere postene. (Merk: dette er innen hver enkelt gruppe.)
5. Her velger du stil og om du vil ha stående eller liggende utskrift.
6. Siste skritt er å velge tittel.
11.6.3 Bruk av inndelingene
1096 - Lars Marius Garshol 61

Figur 11.1
Innføring i databaser
Figur 11.1 viser resultatet av å kjøre veiviseren Grupper/totaler. Når du viser denne rapporten
legges først toppteksten i rapporten (Report header) inn, deretter topptekst side (som siden
gjentas for hver side) og så topptekst Navn hvorpå en detalj for hver post med samme navn
legges på.
Det som står under topptekst side (Page header) er etiketter, så de er de samme på hver side.
Det som står under detalj og topptekst Navn, derimot, er tekstbokser, så de fylles inn med
verdier fra spørringen. Feltene i toppteksten får verdiene til den første posten i den inndelingen,
og dersom feltverdiene (som f.eks. for Navn) er de samme for alle postene er det OK. (Hvis
ikke vil rapporten bli misvisende, men Access vil ikke protestere.)
1096 - Lars Marius Garshol 62

Innføring i databaser
11.6.4 Sideinndeling
Ofte er man interessert i å ha utskriftene slik at hver ny gruppe begynner øverst på et nytt ark.
Dette kan gjøres ved å endre egenskapen TvingSideSkift hos inndelingene. Som regel endrer
du den hos topptekst til gruppen, men alle inndelingene har denne egenskapen.
TvingSideskift kan ha verdiene: Ingen, Før inndeling, Etter inndeling og Før og etter. Hvis du
velger Ingen vil nye grupper komme på samme side som de forrige så lenge det er plass.
Velger du Før inndeling settes sideskiftet inn foran hver ny gruppe. Velger du Etter inndeling
settes sideskiftet inn etter inndelingen. Hvis dette er Topptekst for gruppen vil sideskiftet
komme mellom toppteksten og detaljene. Velger du Før og etter blir sideskiftene satt inn både
før og etter, slik at hver slik inndeling kommer på en side for seg.
11.6.5 Gruppering- og sorteringsinnstillingene
Dersom du vil lage rapporten selv fra bunnen av, eller vil endre gruppering/sortering så kan du
gjøre det ved å klikke med høyre mustast i det hvite feltet øverst til venstre i skjema-designvinduet.
I hurtigmenyen kan du så velge Gruppering og sortering. Da kommer vinduet under
opp (Figur 11.2).
Figur 11.2
Hver rad i tabellen er et felt det skal grupperes på, og rekkefølgen her er svært viktig. Skal du
se kurs for hver soldat, eller deltagere for hvert kurs? Slike spørsmål er det som avgjøres av
rekkefølgen. I kolonnen sorteringsrekkefølge stilles hvordan det skal sorteres på feltet.
I et eget vindu under vises egenskapene til hver enkelt gruppering. ToppTekstforGruppe
avgjør om grupperingen skal ha en egen topptekst eller ikke. (Tilsvarende for BunnTekstfor-
Gruppe.) GrupperEtter skal i 99% av tilfellene være Hver verdi, mens GrupperingsIntervall
nesten alltid er 1. HoldSamlet avgjør om alle postene som tilhører samme gruppe skal vises på
en side eller om de kan spres utover flere.
11.7 Aggregatfunksjoner
Du kan sette inn tekstbokser med uttrykk som bruker aggregatfunksjoner i inndelingene i en
rapport. Disse aggregatfunksjonene vil da gjelde over alle postene som hører til denne
1096 - Lars Marius Garshol 63

Innføring i databaser
inndelingen. F.eks. kan du i Topptekst kursnavn sette inn en boks med teksten
‘=Antall(ID_Soldat)’, og denne vil da telle antall soldater som hører inn under hvert kurs. (De
andre aggregatfunksjonene ville ha reagert på tilsvarende måter.)
Setter du inn en slik aggregatfunksjon i topp- eller bunntekst i en rapport vil den gjelde alle
postene i rapporten. Denne metoden er mye enklere enn å bruke aggregatfunksjonene i
spørringene, og anbefales brukt istedet.
1096 - Lars Marius Garshol 64

12. Fullstendige applikasjoner i Access
12.1 Selvstartende databaser
Innføring i databaser
Det er mye enklere for bruker om han slipper å starte opp hovedmeny-skjemaet selv. Det gir
dessuten et helt annet inntrykk av programmet om bruker aldri ser databasevinduet, men
istedet presenteres for en hovedmeny direkte. Dette gjøres svært enkelt: dersom en database
inneholder en makro som heter AutoExec startes denne automatisk. Det er dermed bare å lage
en makro som åpner hovedmenyen og heter AutoExec.
Denne lager du ved å velge makro-kortet i databasevinduet, og trykke på Ny-knappen. Som
første instruksjon setter du opp ‘UtførMenykommando’, og under argumenter (nederst på
siden) setter du opp Menylinje=Database, Menynavn=Vindu og Kommando=Skjul. Denne
instruksjonen skjuler databasevinduet for brukeren. Det kan hentes frem igjen med kommandoen
Vindu | Ta frem.
Neste instruksjon skal åpne hovedmenyskjemaet automatisk, og til det brukes ÅpneSkjema.
Deretter er det bare å sette argumentet Skjemanavn til det riktige navnet, og makroen er klar.
Dersom du lukker vinduet blir du bedt om et navn, og der skriver du AutoExec.
12.2 Feilsjekking
Skal andre enn deg bruke databasen bør du sjekke den grundig for feil, ellers vil du nesten
garantert få noen sure overraskelser. Brukerne som regel frustrert over å finne feil, hvilket er
enda en grunn til å bruke tid på dette. Under testingen gjelder det å være hard mot seg selv og
prøve bevisst på å kræsje systemet. Skal du finne feil må du prøve å gjøre ting du selv ikke har
tenkt på at noen kunne finne på å gjøre, så etter å ha grovtestet selv bør du sette en av de
fremtidige brukerne til å teste resten.
Access er forferdelig dårlig på feilmeldinger. Som regel får du ikke beskjed om hva som er
galt, og det er direkte elendig av Microsoft. Dette gjør det enda vanskeligere å finne ut hva
som er feil. Feilfjerning er under normale forhold vanskelig, og krever både intuisjon, erfaring
og stahet, og i Access er det enda verre. Likevel er det bare å holde ut, det går lettere
etterhvert som du lærer å kjenne igjen de vanligste feilene du gjør.
12.3 Lage ikon for databasen i Programbehandling
Dette gjøres svært enkelt: gå inn i Programbehandling. Velg Fil | Ny | Programobjekt. Skriv inn
navnet på databasen (eks:’Bilutleieregister’) under Beskrivelse. På Kommandolinje skriver du
path til Access fulgt av \MSACCESS.EXE, mellomrom og databasens filnavn (med path.) Så
trykker du OK og flytter ikonet til riktig gruppe.
1096 - Lars Marius Garshol 65

12.4 Sikkerhet
Innføring i databaser
Access har ganske dårlig sikkerhet i forhold til slettede poster, slik at jevnlig backup er å
anbefale. Alt som da trengs er å ta kopi av .MDB-filen, som inneholder hele databasen. Access
lager også en .LDB-fil, men den trengs ikke.
Dersom du komprimerer databasen med komprimeringsprogrammer som f.eks. PkZip eller
ARJ kan du regne med ganske god komprimering, ettersom databaser ikke bruker særlig
plassbesparende lagringsformater.
12.5 Databaser i nettverk
Det er fullt mulig å lage en Access-database som kan brukes av flere brukere samtidig, og deles
over et nettverk. Selve databasen behøver ikke å lages annerledes av den grunn, men oppsettet
må gjøres litt annerledes. Dette er egentlig et temmelig stort område, så vi skal ikke gå i
dybden på dette her.
Den enkleste (og mest primitive!) måten å dele en database på er å gå inn på Vis|Alternativer i
menyen, og velge Flerbruker/ODBC. Der stiller du Standard postlåsing til ‘Endret post’ og
Standard åpenmodus for databaser til ‘Delt’.
Nå vil brukere kunne dele databasen uten at de overskriver hverandres endringer dersom de
prøver å endre en post samtidig. Istedet vil de få beskjed om at posten er låst, slik at de ikke
kan endre den. Dette kan gjøres mer avansert, blant annet gjennom bruk av Access Basic, men
det går vi ikke inn på her.
12.6 Distribusjon av det ferdige programmet
Det er fullt mulig å lage kommersielle programmer med Access. Det vil si: at du enten lager
programmer på bestilling mot betaling eller at du lager mer generelle programmer og utgir
disse. I begge tilfeller vil du ønske å gi din .MDB-fil til brukerne. Problemet er da at brukerne
må ha Access for å kunne kjøre programmet ditt. Dette kan omgås hvis du anskaffer deg
Access Developer’s Toolkit som koster ca 3500,- Der finnes en fil som heter
MSARN200.EXE som du kan gi bort til hvem som helst, og som bare kan brukes til å kjøre
.MDB-filer, ikke lage dem.
Dersom programmet utgis og brukes av andre enn deg selv vil brukerne garantert forlange
endringer etterhvert. De vil også forlange å få beholde sine gamle data. Du står da overfor et
problem, ettersom skjemaer og rapporter (som er det som mest sannsynlig må endres) ligger i
samme fil som dataene. Dermed: gir du dem en ny tom .MDB-fil må de enten bytte den ut med
den gamle (og miste dataene) eller importere alt de trenger. (Det siste er ikke en jobb for
uerfarne brukere.)
Løsningen på problemet består i å lage en database som bare inneholder tabellene. Så lager du
en database som inneholder alt det andre, og tilknytter tabellene til denne. Du kan da
distribuere grensesnitt-databasen så ofte du vil, uten at dataene slettes, fordi de ligger i en
annen fil.
1096 - Lars Marius Garshol 66

13. Veien videre
13.1 Hvordan lære mer
Innføring i databaser
Som jeg gjentar til kjedsommelighet: programutvikling læres ved å gjøre det. Accessmanualene
inneholder helt greie leksjoner i Access og kan brukes sammen med kursheftet som
veiledning. Den beste måten å lære på er dermed å lage flere databaser, og bruke manualene og
dette heftet som støttemateriale.
Det er bare å prøve seg fram med både modellering og utvikling. Den beste måten å lære dette
på er ved å ta seg vann over hodet og begi seg ut på noe som egentlig er for vanskelig for en.
Derfor: lag databaser! Dersom ingen gir deg oppdrag, så er det bare å lage bokdatabaser og
platesamlingarkiver. Du bør også lese manualene og lære deg Access Basic hvis du vil komme
noen vei.
13.2 Programutvikling på egenhånd
Dersom du har tenkt å utvikle programmer på egenhånd er det noen tips du bør ha med deg.
Det lønner seg å begynne med de enkleste delene, og få de til å fungere først. Deretter kan du
gå videre og bygge på til du har fått med alt du vil ha med. Dersom du synes noe er vanskelig
så vent med det.
Skal du begynne på noe du vet er vanskelig så bruk ekstra god tid på planleggingen. Ofte kan
det lønne seg å tenke gjennom skjemaer også på forhånd. Hold på helt til du føler du har
oversikten.
Iblant vil du garantert føle at du har kjørt deg fast i gjørma og mistet oversikten over det du
gjør fullstendig. Eller du kan oppdage at slik du har lagt opp databasen blir det nesten umulig å
få inn neste del. Da er det som regel enklere å begynne på nytt enn å sitte og flikke på det du
allerede har.
1096 - Lars Marius Garshol 67

14. Tillegg
14.1 Ordliste
Innføring i databaser
• Aggregatfunksjon
En funksjon som brukes i spørringer, slår sammen data innen ett felt fra flere poster til en
verdi. Typiske eksempler: Summere, Gjennomsnitt etc.
• Attributt
Begrep som brukes i datamodellering. Data eller faktum vi ønsker å lagre om en entitet.
• Boolsk uttrykk
Et uttrykk som, når det er ferdig utregnet, gir en boolsk verdi, dvs: sant eller usant. Brukes
som betingelser og krav, f.eks. ved utvalg av poster.
• Enititet
En type gjenstand (gjerne abstrakt begrep) som vi ønsker å registrere data om. Dette kan
typisk være utlån/leie-forhold, personer, biler eller annet. Generelt er det en klasse/mengde
objekter som det finnes flere av, som f.eks. sykler eller bestillinger.
• ER
Entity Relationship, en enkel teknikk for datamodellering. I dette heftet brukes en
forenkling jeg har laget selv.
• Felt
Dette er kolonnene i tabellene. Hver post (dataelement/rad) har en utgave av hvert felt.
• Forretningsregler
Dette er reglene som bestemmer hvordan dataene vi skal lagre i databasen oppfører seg i
den virkelige verden. Dvs: utenfor datamaskinen. Databasen må følge forretningsreglene
etter beste evne.
• Fremmednøkkel
Dette er et felt i en tabell som inneholder fremmednøkkelen til en post i en annen tabell.
Typisk vil feltet ‘Eier’ i tabellen ‘Bil’ være en fremmednøkkel til tabellen ‘Person’, og
verdien i feltet ‘Eier’ vil vise til den personen som eier bilen.
• Hendelse
Hver gang noe skjer i Windows (museklikk, et vindu åpnes eller lukkes, et tastetrykk etc) er
det en hendelse. Til hver hendelse er det knyttet bestemte prosedyrer/makroer som utføres.
Enkelte av disse kan endres av den som lager en database.
• Hurtigmeny
1096 - Lars Marius Garshol 68

Innføring i databaser
Dette er en meny som ikke kommer ned fra menylinjen, men som du får opp ved å trykke
med høyre mustast på ett eller annet objekt i Access. Denne menyen fungerer som en vanlig
meny, men åpnes altså på en litt annen måte.
• Inndeling
I rapporter og skjemaer er dette forskjellige seksjoner i skjemaet/rapporten som vises på
forskjellige steder og gjentas et forskjellig antall ganger. Topptekst i side vises f.eks. øverst
på hver side, mens Detalj vises en gang for hver post i rapporten/skjemaet.
• Instans
En instans av entiteten Bil er en bestemt bil, f.eks. kaptein Lorentzens Opel Kadett.
• Kandidatnøkkel
Et felt som der alle poster skal ha forskjellige (unike) verdier. Kandidat til å være
primærnøkkel, men behøver ikke være det.
• Kontroll
Et element i et vindu, som knapp, tekstboks, listeboks etc.
• NIAM
Nijssen Information Analysis Method, avansert datamodelleringsspråk. Vesentlig bedre og
mer avansert enn ER, kan anbefales.
• Parameter
En verdi som oppgis til en funksjon eller en spørring, og som brukes av disse for å lage
output’en. (Omtrent det samme som x i f(x) i skole-matematikken.)
• Post
En rad i en tabell, et sett med data om en entitet, dvs det vi har data om i tabellen. F.eks. er
en post i tabellen ’Person’ et fullstendig sett med data om en bestemt person.
• Primærnøkkel
Et felt i en tabell som brukes for å identifisere postene i tabellen. For personer ville dette
typisk vært personnummer, for biler registreringsnummer.
• Prosedyre
En makro, et uttrykk eller en samling instruksjoner i Access Basic som beskriver hvordan
noe skal utføres. Med andre ord: en liten bit av et Access-program som er samlet til en
enhet og gitt et navn.
• Query
Engelsk for spørring.
• Rapport
En rapport er en liste med data fra databasen som er beregnet på å skrives ut på papir. Dette
kan typisk være oversiktslister, statistikk/opptelling mm.
1096 - Lars Marius Garshol 69

Innføring i databaser
• Relasjon
En sammenkobling av to tabeller. Relasjoner representeres ved fremmednøkler. Uttrykker et
forhold mellom postene i to forskjellige tabeller.
• Skjema
Et skjema er et skjermbilde, som kan brukes til å endre data, vise informasjon eller som
meny.
• Spesifikasjonsspråk
Et sett med regler for hvordan en datamodell skal tegnes. Eksempler er ER og NIAM.
• Spørring
Spørringer trekker ut og kombinerer data fra forskjellige tabeller for å lage lister. De kan
også brukes til å endre, slette og opprette nye data.
• SQL
Programmeringsspråk som er spesiallaget for bruk i relasjonsdatabaser. Brukes til å lage
spørringer, men også til å definere tabeller og oppdatere data. Finnes i Access, som også har
alternativer til SQL.
• Tabell
Tabellene er der alle data i en database lagres. Tabellene beskriver hva slags data som skal
ligge i en database, men ikke noe mer.
14.2 Vanlige kommandoer
• Endre relasjon
For å endre relasjonene i en database: få opp databasevinduet og velg Redigere | Relasjoner
i menyen. Relasjoner endres ved å klikke på dem med musa. Høyre mustast gir adgang til
egenskaper etc, mens du etter å ha valgt relasjonen kan slette den med Del.
• Endre kobling mellom tekstboks og felt
Dette styres av egenskapen Kontrollkilde i tekstboksen.
• Endre gruppering/sortering i rapport
Klikk med høyre mustast på det hvite feltet øverst til høyre i redigeringsvinduet. Velg
Gruppering/sortering.
• Endre hvilken spørring skjema/rapport er basert på
Dette er en egenskap ved hele skjemaet/rapporten: Postkilde.
• Fjerne postvelgere, navigasjonsknapper og rullefelt i skjema
Dette styres av skjemaets egenskaper: Postvelgere, Navigasjonsknapper og Rullefelt.
1096 - Lars Marius Garshol 70

Innføring i databaser
• Endre farger i et skjema
Dette gjøres enklest dersom du får opp palett-verktøy-linjen. (Vis | Palett i menyen.)
14.3 Vanlige feil
• Jeg endret en tabell/spørring, men kan ikke se noe resultat av det i spørringen/
skjemaet/rapporten der jeg bruker tabellen/spørringen
Du kan ha glemt å lagre endringen, men mer sannsynlig har du glemt å lukke
spørringen/skjemaet/rapporten der du skal bruke resultatet og åpne den igjen, slik at den får
med seg endringen.
• Prøvde å lage en relasjon, men fikk feilmeldingen: “Feil type i relasjon”
De to feltene du prøver å koble sammen har forskjellige typer. To felter med en relasjon
imellom seg må alltid ha samme type.
• Endret typen på et felt i en tabell, men fikk feilmelding om konverteringsfeil
Det finnes data i tabellen som ikke lar seg oversette fra den gamle typen til den nye. Her er
det ikke så mye annet å gjøre en å gå inn i tabellen og se om dette betyr at konverteringen
må droppes, eller om dataene er gale.
• Når jeg åpner spørringen/skjemaet/rapporten får jeg en dialogboks der jeg må skrive inn
en verdi til et av feltene
Du har sannsynligvis feilstavet feltnavnet slik at Access tror det dreier seg om en parameter.
• Når jeg viser skjemaet mitt kommer det opp en dialogboks der jeg må skrive inn tekst, og
denne teksten kommer der jeg lagde en etikett i skjemaet
Du har laget en tekstboks istedetfor en etikett.
14.4 Litteratur
• MS Access-manualene
• Innføring i database, Kjetil Nyhus (kursheftet til dette kurset kontingenten 0196)
• Kompendium for IN 113 - Dataorientert systemutvikling, Ragnar Normann og Jan Erik
Ressem, Institutt for Informatikk, Universitetet i Oslo
• MS Access 2.0 grunnkurs og videregående, DataPower
• Data i fokus, Gerhard Skagestein, Universitetsforlaget
• PCWorld Norge 03/96
14.5 Takk til
• Knut Garshol
Min far leste gjennom dette kursheftet og viste seg å være svært flink til å avdekke svake
punkter i teksten, og gav meg flere verdifulle råd og tips om formulering og innhold.
1096 - Lars Marius Garshol 71

Innføring i databaser
• Kjetil Ravnås
Kjetil leste korrektur på heftet da det var nesten ferdig, og luket ut en rekke småfeil.
• Kjetil Nyhus
Nyhus holdt dette kurset i kontingentene 1095 og 0196. Da han dimitterte lot han meg få
kursheftet han hadde laget. Jeg har stjålet noen av hans ideer og poenger, og er takknemlig
for å ha fått sjansen til det.
• Rolf-Anders Moldeklev
Rolf-Anders kom med en rekke gode forslag etter å ha brukt heftet til selvstudium. Ikke alle
ble fulgt, og noen snek seg inn i undervisningsopplegget istedet.
• Meg selv
Jeg holdt i 0496 kontingenten et kurs i Innføring i EDB der MS Word ble gjennomgått. Å
lage dette kurset gav meg en god forståelse av Word, som var til stor hjelp når jeg skulle
lage dette kursheftet.
1096 - Lars Marius Garshol 72