1. Hensikten med kurset

Transkript

1 1. Hensikten med kurset 1.1 Hva er Microsoft Access? 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 Lars Marius Garshol 2

2 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 Lars Marius Garshol 3

3 1.6 Kommentarer 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 Lars Marius Garshol 4

4 Innholdsfortegnelse 1. HENSIKTEN MED KURSET HVA ER MICROSOFT ACCESS? HVA ER ET DATAPROGRAM? FORSKJELLIGE TYPER DATAPROGRAMMER HVORDAN BRUKE KURSHEFTET KONVENSJONER KOMMENTARER PROGRAMUTVIKLING ET PROGRAMS LIVSSYKLUS ET PROGRAMS EGENSKAPER PROGRAMUTVIKLINGSVERKTØY GODT DESIGN OVERGANGEN FRA IDÉ TIL DATABASE HVA ER EN DATABASE? OM STRUKTURERING AV INFORMASJON DATAMODELLERING ET ENKELT SPESIFIKASJONSSPRÅK: ER-LIGHT FORHOLD HVORDAN LAGE EN DATAMODELL TOMMELFINGERREGLER FOR DATAMODELLERING RELASJONSDATABASER OPPBYGNINGEN AV EN RELASJONSDATABASE FLERE TABELLER - RELASJONER NORMALISERING TOMMELFINGERREGLER FOR NORMALISERING SPØRRINGER, SKJEMAER OG RAPPORTER OPPBYGNINGEN AV DATABASER REFERANSEINTEGRITET SQL OG BASIC ACCESS OPPBYGNING OG VIRKEMÅTE ACCESS SETT I FORHOLD TIL ALTERNATIVENE GRENSESNITTET PROGRAMMENES GRENSESNITT VEIVISERE HVORDAN NAVIGERE I ACCESS STANDARDTABELLEN TABELLER I ACCESS HVORDAN OPPRETTE EN TABELL FELTDEFINISJON DATATYPER OG FELTEGENSKAPER ENDRE FELT PRIMÆRNØKKEL FORHOLDENE ET EKSEMPEL SE PÅ OG SKRIVE INN DATA Lars Marius Garshol 5

5 7. SPØRRINGER I ACCESS HVA ER EN SPØRRING? SPØRRINGER FRA EN TABELL Spørringer med alle poster Spørringer med bare noen av postene SPØRRINGER FRA FLERE TABELLER KOBLINGSEGENSKAPER BEREGNEDE FELT: AGGREGATFUNKSJONER OG UTTRYKK Uttrykk generelt Uttrykk i de forskjellige typene Aggregatfunksjoner Gruppering DATAMANIPULASJON MED SPØRRINGER OPPBYGNING AV GRENSESNITT I WINDOWS SKJEMATYPER OG DERES REKKEFØLGE Hovedmeny Velg post-skjemaet Endre data-skjemaet HVORDAN LAGE ET GRENSESNITT TOMMELFINGERREGLER FOR SKJEMAER SMÅTIPS SKJEMAER I ACCESS: BAKGRUNN HVA ER ET SKJEMA? HVA BESTÅR ET SKJEMA AV? SKJEMAETS DELER SKJEMAVEIVISERNE JOBBE MED KONTROLLER Hvordan velge kontroller Egenskaper SKJEMAER I ACCESS: DETALJENE HVORDAN KONTROLLENE FUNGERER Hendelser Tekstbokser Kombinasjons- og listebokser Knapper VIKTIGE EGENSKAPER VED KONTROLLER HVORDAN LAGE EN KOMBINASJONSBOKS HVORDAN BYGGE OPP ET SKJEMA Endre data-skjema Velg post-skjema Hovedmeny-skjemaet Skjema med underskjema RAPPORTER I ACCESS SKJEMAER/RAPPORTER - FORSKJELLER OG LIKHETER HVORDAN LAGE RAPPORTER ET ENKELT EKSEMPEL HVORDAN BRUKE EN RAPPORT RAPPORTVEIVISERNE RAPPORTER MED GRUPPERING Hva er gruppering, og hvorfor bruke det? Grupperingsveiviseren Bruk av inndelingene Lars Marius Garshol 6

6 Sideinndeling Gruppering- og sorteringsinnstillingene AGGREGATFUNKSJONER FULLSTENDIGE APPLIKASJONER I ACCESS SELVSTARTENDE DATABASER FEILSJEKKING LAGE IKON FOR DATABASEN I PROGRAMBEHANDLING SIKKERHET DATABASER I NETTVERK DISTRIBUSJON AV DET FERDIGE PROGRAMMET VEIEN VIDERE HVORDAN LÆRE MER PROGRAMUTVIKLING PÅ EGENHÅND TILLEGG ORDLISTE VANLIGE KOMMANDOER VANLIGE FEIL LITTERATUR TAKK TIL Lars Marius Garshol 7

7 2. Programutvikling 2.1 Et programs livssyklus Å 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 Lars Marius Garshol 8

8 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 Lars Marius Garshol 9

9 2.2 Et programs egenskaper 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 Lars Marius Garshol 10

10 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 Lars Marius Garshol 11

11 3. Overgangen fra idé til database 3.1 Hva er en database? Om strukturering av informasjon 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 Hun bor i Dalveien 19, 1800 Askim og privattelefon Bil nummer BN er en Nissan Bluebird eid av Jarl Andresen, som bor i Nansensgt 69, 4601 Kristiansand og har telefon 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 ASKIM SP Toyota MR2 Jarl Andresen Nansensgt KRISTIANSAND BN 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 Lars Marius Garshol 12

12 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 Eier Person Telefon Lars Marius Garshol 13

13 Navn Adresse 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 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 Lars Marius Garshol 14

14 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: Navn Tittel Plate Artist År Type Sang Tittel Varighet 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. Navn Tittel Plate Spilt inn av Har spilt inn 1 Artist Lars Marius Garshol 15 År Type Sang

15 1 Inneholder Utgitt på 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 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 Lars Marius Garshol 16

16 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 Lars Marius Garshol 17

17 4. Relasjonsdatabaser 4.1 Oppbygningen av en relasjonsdatabase 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 Toyota MR2 Anne Tryti BN Nissan Bluebird Jarl Andresen DE 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å Lars Marius Garshol 18

18 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 ASKIM Jarl Andresen Nansensgt KRISTIANSAND Hans Hansen Hanseveien 0316 OSLO Tabell 4.2 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 Lars Marius Garshol 19

19 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 Lars Marius Garshol 20

20 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 Lars Marius Garshol 21

21 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 Lars Marius Garshol 22

22 5. Access oppbygning og virkemåte 5.1 Access sett i forhold til alternativene 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.) Lars Marius Garshol 23

23 5.3 Programmenes grensesnitt 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 Lars Marius Garshol 24

24 5.5 Hvordan navigere i Access Kort Knapper Vindu Figur 5.1 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 Lars Marius Garshol 25

25 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 Lars Marius Garshol 26

26 6. Tabeller i Access 6.1 Hvordan opprette en tabell 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. Figur Feltdefinisjon 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 Lars Marius Garshol 27

27 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 ) 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 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 Lars Marius Garshol 28