OnLibri.dk. Access Torben Lage Frandsen. Download gratis bøger på ventus.dk / BookBoon.com

Transkript

1

2 Access 2007 Torben Lage Frandsen

3 2008 Torben Lage Frandsen & OnLibri Alle rettigheder forbeholdes. Ingen del af denne bog må gengives, lagres i et søgesystem eller transmitteres i nogen form eller med nogen midler grafisk, elektronisk, mekanisk, fotografisk, indspillet på plade eller bånd, overført til databanker eller på anden måde, uden forlagets skriftlige tilladelse. Enhver kopiering fra denne bog må kun ske efter reglerne i lov om ophavsret af 14. juni 1995 med senere ændringer. Det er tilladt at citere med kildeangivelse i anmeldelser. ISBN udgave

4 Indholdsfortegnelse Indholdsfortegnelse Indledning Hvad kommer du til at lære? En lille læsevejledning Nyheder i Access 2007 Bånd og faner Databasevinduet er væk Hvor finder jeg de gamle knapper? Genvejstaster 1. Databaseteori 1.1 Databasens grundelementer Tabeller Relationstyper Nøgler Forespørgsler 1.2 Specielle elementer i Access Formularer Rapporter Makroer Moduler 1.3 Planlægning af en database Idégenerering Entiteter og relationer Konstruér mange til mange -relationerne Øvrige nøgler 1.4 Resterende planlægning 2. Skærmbilledet og dets elementer 2.1 Office-knappen 2.2 Hurtig adgang 2.3 Båndet og fanerne 2.4 Statuslinjen 2.5 Visningsknapper 2.6 Navigationsruden 2.7 Arbejdsområdet 2.8 Navigationsknapper 3. Tabeller 3.1 Felter og datatyper Tekst-datatyper Tal-datatyper Om datoer og klokkeslæt 3.2 Indeksering Indstilling af indeks i tabeller 3.3 Øvrige feltegenskaber 3.4 Flere tabeller og relationerne imellem dem Relation mellem t_film og t_medie Flere tabeller Tabeller til mange til mange -relationerne Relationer 3.5 Indtastning af stamdata

5 Indholdsfortegnelse 4. Forespørgsler 4.1 En udvælgelsesforespørgsel 4.2 Kriterier i forespørgsler Flere typer kriterier med tekststrenge Kriterier med tal 4.3 Formler i forespørgsler 4.4 Indbyggede funktioner En almindelig funktion En domæneaggregatfunktion Konverteringsfunktioner 4.5 Grupper og totaler 4.6 Krydstabulering 4.7 Forespørgsel i filmkartoteket. 5. Formularer 5.1 Oprettelse ved hjælp af en guide 5.2 Formularvisning 5.3 Designvisning 5.4 Egenskaber 5.5 Indsætte kontrolelementer 5.6 Hoved- og underformularer 6. Makroer 6.1 Hysterisk sikkerhedsindstilling 6.2 En knap til makroen 7. Rapporter 7.1 En knap til udskrift 8. De sidste detaljer 8.1 Søgeformularer Søg skuespiller Søg genre Søg sprog 8.2 Lav en hovedmenu 8.3 Startindstillinger Afsluttende bemærkninger

6 Indledning Indledning Access er det program i Microsoft Office pakken, der er mest udfordrende at gå i gang med. I Word og PowerPoint kan man umiddelbart bare gå i gang med at lave et eller andet, men sådan er det altså ikke med Access. Access kræver noget teoretisk viden og planlægning, inden man går i gang. Derfor er der mange, som slet ikke anvender programmet, fordi de synes, det er for svært. Dén påstand vil jeg gerne mane i jorden med det samme. Access er udfordrende at arbejde med, men hvis du lærer det på den rigtige måde, er det ikke svært. Men det kræver, at du bruger lidt tid på at sætte dig ind i det. Access indeholder hjælp og guider til langt de fleste opgaver, præcis som de andre programmer gør. Derfor er der ingen grund til at være nervøs for, at du ikke kan lære det. Den største udfordring ligger i at forstå, hvordan en database grundlæggende fungerer. Derfor fylder det temmelig meget i denne bog. Til gengæld vil du herefter kunne lave dine egne, temmelig avancerede programmer på relativ kort tid. Du vil blive i stand til at indsamle og strukturere store mængder data og præsentere dem i nogle pæne skærmbilleder og rapporter, præcis som du har behov for. Og det er vel at mærke uden, at du behøver at lære at programmere. Hvad kommer du til at lære? I modsætning til de andre bøger i denne serie om Microsoft Office 2007 starter vi ikke med at se på programmets skærmbillede og grundlæggende elementer. Vi starter med noget grundlæggende databaseteori, som du skal have på plads først. Databaseteori er noget, som du ikke alene kan bruge til Access, men også til andre større databasesystemer, hvis du får appetit på det. Teorien får du i forbindelse med planlægningen af den database, som udgør den gennemgående øvelse i denne bog. Efter den første planlægning ser vi nærmere på programmet, og hvordan det er opbygget. Herefter kan vi gå i gang med det praktiske arbejde med at bygge databasen op. Databasen, vi skal opbygge, er et filmkartotek. Filmkartoteket vil kunne indeholde en oversigt over din filmsamling på dvd, VHS og andre typer medier, og du vil kunne søge på filmtitler, genrer og skuespillere. Du vil også kunne se, hvilke skuespillere der har spillet sammen i hvilke film, og du vil kunne holde styr på de film, du har lånt ud til venner og bekendte. En lille læsevejledning I løbet af bogen arbejder vi på en database, som vi løbende lægger forskellige ting ind i. For at du ikke skal løbe ind i problemer undervejs, er det meget vigtigt, at du laver alle øvelserne. En Access-database består af mange forskellige ting, som skal arbejde sammen, og hvis du springer noget over, kan du komme til at mangle det senere hen. Derfor skal du lave samtlige øvelser i bogen. Til gengæld vil jeg love dig, at den tid, du har investeret, er givet godt ud. Når jeg beder dig om at klikke på noget, mener jeg et klik med venstre museknap. Et dobbeltklik er to hurtige klik med venstre museknap. Hvis jeg vil have dig til at klikke med højre museknap, kalder jeg det et højreklik. Knapper og menuer, som du kan/skal klikke på, skrives altid med understreget skrift. Det betyder, at når du ser noget understreget tekst i bogen, skulle du gerne kunne finde noget tilsvarende på skærmen, som du kan klikke på. 6

7 Nyheder i Access 2007 Nyheder i Access 2007 Bånd og faner Som de andre programmer i Office-pakken, har Access også fået et nyt og smartere udseende. Det første, der springer i øjnene, er, at de traditionelle menulinjer og værktøjslinjer er erstattet af det nye Bånd. Båndet indeholder faneblade, og hvert faneblad indeholder knapper til de funktioner, som du før fandt i menuerne og værktøjslinjerne. Båndet er langt mere visuelt og opgaveorienteret og tilpasser sig hele tiden den aktivitet, du er i gang med. Når man i mange år har været vant til at arbejde med menuer og værktøjslinjer, kræver båndet noget tilvænning. Efter nogen tids brug vænner man sig til det, og man kan faktisk godt gå hen og blive rigtig glad for det. Mange funktioner krævede tidligere, at man skulle klikke sig langt ned i menuer og dialogbokse. På båndet er mange indstillinger og funktioner trukket frem, så de er mere direkte tilgængelige. Databasevinduet er væk Databasevinduet er erstattet af oversigtspanelet i venstre side af skærmen. Hvor finder jeg de gamle knapper? Dem, som har brugt Access i nogen tid, og som lige er skiftet til version 2007, vil nok få lidt problemer i starten med at finde de funktioner, de plejer at bruge. Det skyldes primært, at mange funktioner er ændret i forbindelse med implementering af båndet. Derfor vil jeg her liste de vigtigste funktioner op, så du hurtigt kan vænne dig til den nye brugerflade. Oprettelse af tabeller, forespørgsler, formularer og rapporter sker fra fanen Opret på båndet. For at starte Guiden Formular, skal du klikke på knappen Flere formularer, hvorefter menupunktet Guiden Formular vil komme frem. Relationslayoutet finder du i fanen Databaseværktøjer. Funktionen til at komprimere og reparere databasen finder du ved at klikke på Office-knappen i øverste venstre hjørne og vælge Administrér. Startindstillinger finder du ligeledes ved at klikke på Office-knappen. Her skal du bare klikke på knappen Accessindstillinger og herefter vælge kategorien Aktuel database. Udskriv finder du også i Office-knappen. 7

8 Access 2007 Genvejstaster Genvejstaster er kombinationer af tastetryk på tastaturet, som giver adgang til langt de fleste af de funktioner, som du ellers ville vælge med musen. Hvis du er glad for at bruge genvejstaster i stedet for musen, skal du vide, at de fungerer en smule anderledes i hele Office 2007 i forhold til tidligere versioner. Access er nok ikke det program, hvor man er mest tilbøjelig til at bruge genvejstaster. Jeg vil dog gerne slå et slag for dem alligevel. I stedet for at bruge musen hele tiden kan man i mange tilfælde aktivere mange forskellige funktioner langt hurtigere. Jeg vil varmt anbefale dig, at du øver dig i genvejene til de funktioner, du benytter mest. Du får især udbytte af det, hvis du i forvejen benytter dig af 10-finger systemet. For det første kan du arbejde langt hurtigere, og for det andet reducerer du risikoen for at få en muse-arm, fordi du kan sidde i en god afslappet arbejdsstilling med begge hænder hvilende på tastaturet. Ved et enkelt tryk på ALT-tasten på dit tastatur vises nogle små firkanter med tal eller bogstaver over Officeknappen, værktøjslinjen Hurtig adgang og over de enkelte faner i båndet. De tal og bogstaver, der vises, svarer selvfølgelig til den tast, du skal trykke på for at vælge funktionen. Her behøver du ikke længere at trykke på ALTtasten imens. Hvis du f.eks. trykker på N, vises fanen Indsæt, og funktionerne i denne fane vil automatisk være markeret med genveje. Igen skal du blot taste det, der står i de små firkanter, uden at trykke på ALT-tasten imens. Nogle genveje indeholder flere tegn, som skal tastes på tastaturet. Det gælder f.eks. funktionen Figurer under fanen Indsæt. Den bruger genvejen SU. Så taster du bare S og U lige efter hinanden. Figur 1: Visning af genveje. At det er lavet sådan giver mening, når man som jeg bruger 10-finger systemet. Når man først har indarbejdet de nye genveje, kan man arbejde endnu mere afslappet med genvejstaster, da man ikke skal vride hænderne for at nå CTRL-tasten eller ALT-tasten plus en tast mere. Heldigvis ser de gamle genveje også ud til at virke stadigvæk, så hvis du har meget indgroede vaner omkring nogle funktioner såsom klip, kopier og sæt ind, så kan du også stadig bruge de genveje, du altid har brugt. Jeg er ikke selv stødt ind i problemer endnu. 8

9 1. Databaseteori 1. Databaseteori Det korrekte navn for databaseteori er Entitets- og relationsteori eller E-/R-teori. Det lyder svært, men er i virkeligheden ret enkelt. Det handler om, hvordan man strukturerer forskellige former for data, så de kan lægges ind i en database på den mest optimale og sikre måde. Uden at vide det er du i vores moderne samfund i direkte kontakt med adskillige databaser hver dag. Ethvert edb-system, som du indsætter eller udtrækker data fra, har en relationsdatabase til at gemme og udtrække oplysninger. Når du betaler for en liter mælk henne i supermarkedet, sker der en masse transaktioner i forskellige databaser. Det registreres i butikkens database, at der er købt 1 stk. af et varenummer på et givent tidspunkt. Databasen har oplysninger liggende, om at varenummeret tilhører Mælk, og at mælken på det pågældende tidspunkt koster kr. 7,95, og at du har betalt. Supermarkedets lageroversigt vil også blive nedskrevet med 1 liter mælk. Oplysningerne ligger nu i databasen og anvendes senere til at lave et udtræk over omsætningen i de forskellige varegrupper, og faktisk også til at danne supermarkedets årsregnskab. Her slutter det ikke, for hvis du betaler med dankort, registreres det i samme database, at du har betalt med dankort. Via internet eller en telefonforbindelse sendes der oplysninger om din betaling til PBS s database, som tilbagesender oplysninger til supermarkedet om, at dit dankort ikke er spærret. PBS s database sender også oplysninger til din banks database om, at din konto skal nedskrives med kr. 7,95, som skal overføres til supermarkedets konto. Et andet eksempel på brug af databaser er internettet. Alle de websites, som indeholder dynamisk indhold, bruger én eller flere databaser. Alle de store nyhedsmedier, chatsider, sociale netværk og søgemaskiner har en database til at modtage, opbevare og levere oplysningerne til dig, når du går ind på siden. Vores moderne samfund kunne slet ikke fungere uden databaser. Access vil selvfølgelig ikke kunne håndtere den mængde transaktioner og sikkerhedskrav, som PBS har behov for. Dertil kræves langt kraftigere databasesystemer. Men ellers fungerer Access på nøjagtig samme måde, bare i mindre målestok. Du kan sagtens bruge Acces til at håndtere regnskabet i en lille virksomhed eller indholdet i din egen blog på nettet. Jeg har selv anvendt Access til så forskellige ting som: Registrering af kvalitetsmålinger i en fabrik og levering af løbende kvalitetsstatistikker. Lagerstyring i en mellemstor tekstilvirksomhed. Produktionsplanlægning og styring af jobrotation i en produktionsafdeling med mere end 100 medarbejdere, inklusive udskrivning af jobkort og produktionsplaner. Her var jeg også ved at nå grænsen for Access formåen, men det giver et meget godt billede af, hvad man kan opnå, når man er ved at beherske programmet. 9

10 1. Databaseteori Access taler samme sprog som de store databasesystemer. Det er et sprog kaldet SQL, hvilket står for Structured Query Language. Vi berører ikke SQL i denne bog, og du behøver heller ikke lære det for at bruge Access. Du kan dog skrive SQL i Access, hvilket blot vil give dig flere muligheder. Hvis du er interesseret i at blive decideret databaseudvikler, er Access derfor et glimrende sted at starte. 1.1 Databasens grundelementer En database kan defineres som noget, som man kan gemme strukturerede oplysninger i. Det ligger næsten i navnet. Hvilke oplysninger, der lægges ind, afhænger af, hvad databasen skal bruges til, men oplysningerne gemmes altid i tabeller. En database består som regel af et antal tabeller, og de kan relateres til hinanden i form af relationer. Man indsætter, sletter og viser data fra tabellerne ved hjælp af forespørgsler, og i Access kan man vise oplysningerne til brugeren ved hjælp af skærmbilleder kaldet formularer eller rapporter, som kan udskrives eller konverteres til tekstbehandlingsdokumenter Tabeller Access-databaser er såkaldte relationsdatabaser. Som nævnt består relationsdatabaser af forskellige tabeller med data i. Tabellerne relaterer sig til hinanden på én eller anden måde. Figur 2: Simpelt adressekartotek. F.eks. kan et meget simpelt adressekartotek bestå af to tabeller. Den ene tabel indeholder alle medlemmernes navne, adresser og postnumre, mens den anden tabel indeholder en postnummerliste med tilhørende bynavn. Figur 3: Adressekartotek i en relationsdatabase. I modsætning til en simpel liste over medlemmerne, hvor der står navn, adresse, postnummer og bynavn i den samme tabel, vil en relationsdatabase med to tabeller sikre at: 10

11 1. Databaseteori Der ikke kan indtastes postnumre, som ikke findes, da der kun kan indtastes postnumre, som står i postnummertabellen. Der skal ikke bruges harddiskplads til at gemme det samme bynavn mere end én gang, da databasen allerede ved, hvad bynavnet er, når postnummeret er indtastet. Der skal ikke bruges tid på at indtaste bynavnet, når postnummeret allerede er indtastet. Det, du normalt vil kalde tabellens lodrette kolonner, kaldes i forbindelse med databaser for felter. For at undgå ordforvirring kalder jeg også kolonnerne for felter i denne bog, for det kaldes de også i Access. En vandret række i en tabel kaldes en post. Nogle bruger også betegnelsen record om en post, men da det kaldes en post i Access, vil jeg også bruge dette ord i denne bog. En værdi i en tabel kaldes faktisk en værdi. Andre bruger undertiden betegnelsen dataelement, men jeg kalder det en værdi i denne bog. En post indeholder lige så mange værdier, som der er felter, og et felt indeholder lige så mange værdier, som der er poster. Et felt uden noget indhold har en nulværdi. Alle felter har således en værdi, uanset hvad der er indtastet. Et felt er defineret ved, at det har et navn, en position i forhold til de andre felter, samt en datatype. Datatyper er der mange af, men det kommer vi tilbage til. Stærkt forenklet kan vi sige, at en datatype enten kan være tal eller tekst. Man kan ikke gemme tekst i et tal-felt, men du kan godt skrive tal i et tekst-felt. I det sidste tilfælde vil tallet dog være lagret som tekst, og du vil ikke kunne foretage beregninger på det Relationstyper I vores eksempel med adressekartoteket har vi en relation mellem de to tabeller. En relation mellem to tabeller er altid knyttet til felter i hver tabel med samme datatype. I eksemplet er det feltet Postnummer i de respektive tabeller, som indgår i relationen. Der findes tre typer relationer: En til en -relationer, hvor én, og kun én post i den ene tabel refererer til én, og kun én post i den anden tabel. En til mange -relationer, hvor én, og kun én post refererer til én eller flere poster i den anden tabel. Det er dén type relation, du kommer til at bruge mest. I vores eksempel går der en en til mange -relation mellem postnummertabellen og adressetabellen. Postnummeret må kun forekomme én gang i postnummertabellen, men gerne flere gange i adresselisten. Mange til mange -relationer, hvor flere poster i én tabel kan referere til flere poster i en anden tabel. I Access er det et lidt specielt tilfælde, som faktisk kræver en ekstra tabel. Det ser vi også på senere. Relationer er således det, som knytter en relationsdatabase sammen. Relationer sikrer til en vis grad, at du ikke registrerer ugyldige oplysninger. En til mange -relationer har en retning. I vores eksempel med adressekartoteket går relationen fra postnummerlisten til adresselisten. Det ligger også i navnet en til mange. En post i postnummertabellen kan referere til mange poster i adresselisten. 11

12 1. Databaseteori Nøgler Tabeller knyttes sammen med relationer. Relationerne peger på et eller flere felter i de tabeller, som indgår i relationen. Disse felter kaldes for nøgler. I eksemplet med adressekartoteket udgør feltet Postnummer postnummertabellens primære nøgle. Feltet Postnummer i adresselisten kaldes fremmednøglen. I en til en -relationer og en til mange -relationer skal den første tabel altid have en primær nøgle. Et felt, som er primær nøgle, må kun have unikke værdier. Det giver sig selv, at et postnummer ikke må forekomme mere end én gang i en postnummertabel. Ellers ville det ikke være muligt at definere præcis, hvilken by postnummeret hører til. Fremmednøglen i en en til mange -relation må selvsagt gerne indeholde den samme værdi i flere poster, men det må den ikke i en -relation Forespørgsler I en Access-database bruger man primært forespørgsler til at vise data fra databasen. I princippet fortæller man Access, hvilke felter man vil have vist fra hvilke tabeller, og om værdierne skal opfylde nogle bestemte kriterier for at komme med i resultatet. Resultatet af en sådan forespørgsel er noget, som ligner en tabel. F.eks. kan man lave en forespørgsel, som trækker data ud af de to tabeller i Figur 3 og fremviser dem som en tabel magen til den i Figur 2. Man kan også bruge forespørgsler til at indsætte, ændre eller slette data i tabellerne. I Access er det let at lave forespørgsler, fordi det foregår visuelt i et skærmbillede. Men i baggrunden foregår der faktisk det, at Access skriver en slags programmering i databasesproget SQL. I større databasesystemer foregår alt faktisk i dette programmeringssprog, inklusive oprettelse af tabeller og relationer. Tabeller, relationer, nøgler og forespørgsler udgør grundstenene i enhver relationsdatabase, og det er vigtigt, at du forstår disse begreber. Hvis det virker forvirrende, så er du så absolut ikke den første! Faktisk kender jeg ikke nogen, som har forstået det til fulde første gang, inklusive mig selv. Læg eventuelt denne bog fra dig nogle timer, og vend tilbage og læs dette afsnit én gang til. 12

13 1. Databaseteori 1.2 Specielle elementer i Access Grundelementerne, som blev beskrevet i sidste afsnit er grundelementer i enhver relationsdatabase. Dertil kommer nogle elementer, som Access tilbyder, som gør, at du kan gøre databasen til et helt lille program Formularer En formular er et skærmbillede i Access, som du selv opbygger. En formular kan indeholde indtastningsfelter, knapper, tekst og grafik. Det er ikke påkrævet, at du opretter formularer til din database, men hvis du skal bruge den som en slags program, og hvis andre også skal bruge den, er det en god idé at lave nogle gode formularer. Formularerne er databasens brugergrænseflade. Det er her, man gør det nemt at indtaste, redigere og udtrække data fra databasen Rapporter Rapporter bruges til at lave pæne udskrifter af udtræk fra databasen. Man opbygger rapporter på en måde, som minder meget om opbygningen af formularer Makroer En makro er en liste over kommandoer, som man vil have udført automatisk, når nogle bestemte betingelser er opfyldt. Du kan f.eks. lave en knap i en formular. Når der trykkes på knappen afspilles en makro, som kører en forespørgsel, der viser et udtræk fra databasen. Du kan bruge makroer til mange forskellige ting, lige fra åbning og lukning af vinduer til start af andre programmer. Du kan sågar sende en mail ved hjælp af en makro. Makroer indeholder også en række begrænsninger, men dem kan du komme ud over ved i stedet at anvende moduler Moduler Med Access følger et helt programmeringssprog kaldet Visual Basic. Med dette programmeringssprog kan du tilføje en masse funktionalitet til Access, som ikke var i programmet i forvejen. Et modul kan kaldes et stykke papir, hvor du kan skrive små programmer i dette sprog. Ud over at du kan oprette selvstændige moduler, indeholder alle formularer og rapporter også deres egne moduler. Det gør det muligt at indsætte små programmer, som startes, når du f.eks. klikker på en knap. Visual Basic er et kæmpe område i sig selv, og vi berører det ikke i denne bog. Når du føler dig hjemme i Access, kan jeg varmt anbefale dig at begynde at eksperimentere med det, for det giver dig næsten ubegrænsede muligheder. Access i sig selv indeholder ligesom alle andre programmer nogle begrænsninger, men med Visual Basic kan du i langt de fleste tilfælde programmere dig ud af disse begrænsninger. 13

14 1. Databaseteori 1.3 Planlægning af en database Vi skal lave et filmkartotek i Access, hvor vi kan organisere vores filmsamling. Den bedste måde at starte planlægningen på er at generere nogle idéer til, hvilke oplysninger vi gerne vil have i databasen Idégenerering Dette arbejde har jeg allerede gjort i vores tilfælde. I Figur 4 kan du se en illustration af, hvad jeg er nået frem til. Jeg er startet med at lave en kasse i midten, der hedder Film. Det er, fordi det er film, det handler om, og derfor virkede det logisk. Rundt om kassen har jeg tegnet nogle lyseblå bobler, som kort beskriver, hvad jeg kunne tænke mig at registrere om mine film. I forbindelse med de lyseblå bobler har jeg yderligere tegnet nogle grå bobler, som er en slags eksempler på, hvad jeg mener. Filmtitel har jeg ikke skrevet ind, da den giver sig selv. Figur 4: Idéer til, hvad et filmkartotek bør indeholde. Hvis du synes, at jeg mangler noget, så fortvivl ikke. Når vi har opbygget filmkartoteket sammen, har du så meget styr på Access, at du selv vil kunne tilføje dine egne oplysninger. Vi har nu et godt udgangspunkt for at begynde på den proces, som kaldes normalisering. Normalisering er en proces, hvor vi efterhånden får den mudrede suppe af oplysninger i Figur 4 til at blive så strukturerede, at de kan lægges ind i en database. 14

15 1. Databaseteori Normaliseringsprocessen kan godt tage lang tid, især hvis man er utrænet i det. Processen er en såkaldt iterativ proces, hvor man prøver sig lidt frem og gradvist kommer nærmere den endelige databasestruktur. Målet er, at vi finder ud af, hvilke tabeller vi har behov for i databasen. Vi finder ud af, hvad der skal være i tabellerne, og hvilke relationer der skal være mellem dem Entiteter og relationer Det første, vi skal gøre, er at tage et grundigt blik på Figur 4 og finde ud af, hvad der er entiteter. Tænk på en entitet som noget forholdsvis håndgribeligt, som vi ønsker at registrere nogle oplysninger om. Entiteter har en tendens til enten at ende med at blive til én eller flere tabeller i den færdige database eller til at ende som værdier i en anden entitet. En meget løs tommelfingerregel til at identificere entiteter er, at man skal se efter navneord, når man forsøger at beskrive databasen. Det kunne være en film, en bil eller en bankkonto for den sags skyld. Jeg er allerede forholdsvis sikker på, at entiteten Film ender med at blive en tabel i den færdige database. Det betyder, at Film kommer til at indeholde en liste over alle vores film, med en række felter til at identificere de forskellige oplysninger om filmen såsom sprog, billedformat osv. Når man skal udpege entiteterne, skal man også tænke på relationerne imellem dem. Her tænker jeg helt konkret på, om de har en en til mange -relation eller en af de andre relationstyper i forhold til de andre entiteter. En anden meget løs tommelfingerregel er, at man skal se efter udsagnsord i en beskrivelse af databasen. Hvis vi starter fra midten og påstår, at en film er en entitet, så lad os se lidt på de bobler, der er udenom. En film kan have flere medvirkende skuespillere, så måske er både Film og Skuespillere entiteter. Omvendt kan en skuespiller også være med i flere film, så måske er der oven i købet en mange til mange -relation mellem Film og Skuespillere. Ser vi på boblen Medie kan den måske også være en entitet. En film kan ikke både være på VHS og dvd på én gang. Vi kunne selvfølgelig have flere eksemplarer på forskellige medier, men i denne database forudsætter vi, at vi kun har ét eksemplar af hver film. Omvendt kan vi have mange dvd-film og VHS-film, så der er nok en en til mange -relation mellem Medie og Film. En dvd-film kan indeholde flere forskellige lyd og billedformater, men vi beslutter, at vi kun registrerer den bedst mulige værdi for disse to entiteter, som i øvrigt har den samme type relation til entiteten Film, som Medie har. En film kan godt tilhøre flere genrer, hvis vi vælger, at en actionkomedie skal registreres som Action og Komedie. Det kan der være god mening i, så vi har en mange til mange -relation mellem Film og Genre. Ser vi på boblen Spilletid, kan en film godt nok kun have én spilletid. Men Spilletid er en lidt uhåndgribelig værdi, som det nok er bedst bare at have som en værdi i entiteten Film. 15

16 1. Databaseteori Ser vi på boblen Årstal, kan det diskuteres, om det skal være en entitet eller ej. Vi beslutter os for, at årstallet blot skal registreres som en værdi i entiteten Film. Jeg er efterhånden ret sikker på, at entiteten Film ender med at blive en tabel i den færdige database. Sprog kan være en entitet i sig selv. En dvd-film kan indeholde flere sprog, og det kan være relevant at registrere de sprog, vi kunne forestille os at anvende. F.eks. kunne en Harry Potter-film blive registreret med sprogene engelsk og dansk. Jeg vil helst se den på engelsk, men børnene vil helst se den på dansk. Vi får derfor en mange til mange -relation mellem Film og Sprog. Udlånt kan enten være Ja eller Nej, men vi vil gerne kunne registrere, hvem en film i givet fald er udlånt til, og hvornår vedkommende har udlånt den. Derfor kan det være en idé at have en entitet, vi kalder Udlånt. En film kan kun være udlånt til én person ad gangen, men en person kan godt låne flere film på én gang. Derfor skal der være en en til mange -relation mellem Udlånt og Film. Hvis du har forstået alt indtil nu, er du muligvis uenig i, at Udlånt skal være en entitet. Så er du rigtig skarp! Bare rolig, vi retter fejlen senere. Nu kan vi efterhånden tegne et lidt mere struktureret billede af vores data. Det kaldes et entitets- og relationsdiagram eller et E-/R diagram og kan tegnes på flere forskellige måder. Figur 5: Foreløbigt entitets- og relationsdiagram. Jeg har valgt at tegne entiteterne som kasser og illustreret relationerne mellem dem som streger. En streg med et m i hver ende er en mange til mange -relation, og en streg med et 1 i den ene ende og et m i den anden er en en til mange -relation. I nogle af entiteterne har jeg skrevet stikord om, hvad jeg mener, der skal registreres i dem. Hvis entiteten ender med at blive en tabel, vil disse stikord muligvis blive til felter i tabellen. Men der er et stykke vej endnu, før vi har et endeligt billede af, hvilke tabeller der skal være. 16

17 1. Databaseteori Konstruér mange til mange -relationerne Mange til mange -relationer kræver i praksis en ekstra tabel for at fungere. Denne ekstra tabel er knyttet til hver af de to andre tabeller via en til mange -relationer. Det giver derfor også mulighed for, at selve relationen kan bære oplysninger i sig selv. Det lyder måske langhåret, men det er det ikke. Figur 6: En "mange-til-mange"-relation. Vi har en mange til mange -relation mellem entiteterne Film og Skuespillere. Vi besluttede jo tidligere, at en film kan have mere end én skuespiller, og at en skuespiller kan være med i mere end én film. Ser vi på entiteterne som tabeller, skal tabellen Film indeholde én og kun én post for hver film, der er registreret. Tabellen Skuespillere skal indeholde én og kun én post for hver skuespiller, vi har registreret i systemet. Vi gider nemlig ikke skrive Arnold Schwarzenegger, hver gang vi skal registrere en film, han er med i. Det er meget lettere bare at skrive, at det er skuespiller nr. 8! Derfor har jeg i Figur 6 skrevet et stikord kaldet Film ID i entiteten Film, og Skuespiller ID i entiteten Skuespillere. Disse ID er har jeg tænkt mig skal være primære nøgler i disse to entiteter. Det har jeg markeret ved at understrege dem. Derved får hver film et entydigt nummer, og det gør hver skuespiller også. Figur 7: En mange til mange -relation. Vi kan derefter definere en mange til mange - relation som en slags entitet i sig selv. Relationen kalder vi Medvirkende, og den skal have en fremmednøgle bestående af de primære nøgler fra de to entiteter, som den knytter sammen. Disse to nøgler udgør derved relationens primære nøgle. 17

18 1. Databaseteori Nu har jeg tidligere forklaret, at en primær nøgle er et entydigt felt, men man har altså også mulighed for at bruge flere felter, hvilket kaldes en sammensat nøgle. Det samme Film ID kan bruges mange gange, men kun sammen med forskellige Skuespiller ID. Felterne kan i sig selv godt indeholde dublerede værdier, men kombinationen af de to felter skal altid være unik. Da en mange til mange -relation bliver til en tabel i den endelige database, kan den i sig selv indeholde informationer. Det er nærliggende at registrere i mange til mange -relationen, om den medvirkende skuespiller er hovedrolleindehaver. Figur 8: E-/R diagram med mange til mange -relationer. Efter at have behandlet de øvrige mange til mange -relationer, ser diagrammet således ud: Tag dig god tid til at se diagrammet igennem, og prøv om du kan forstå sammenhængene Øvrige nøgler For at knytte Film -entiteten sammen med de øvrige entiteter med en til mange -relationer, skal hver af entiteterne have en primær nøgle, som bliver fremmednøgle i entiteten Film. Det er ret enkelt. Hver entitet får en primær nøgle, som ofte vil være et ID-nummer. Det er en god idé også at have oplysninger i klar tekst i entiteterne. Herefter nærmer vi os noget, som efterhånden er tæt på at være det færdige databasedesign! Men vi har et lille problem. Problemet ligger i entiteten Udlånt, hvor vi ikke har gjort os de store overvejelser om, hvordan vi vil håndtere vores udlån. Måske er Udlånt slet ikke en entitet, hvilket ved nærmere eftertanke måske giver mening. Et udlån er jo i virkeligheden noget, som foregår mellem en person og en film. Personen kan låne flere film, og en film kan udlånes til flere personer, så længe det ikke er på samme tid. Måske vil det være smart at fjerne entiteten Udlån og oprette en Person -entitet i stedet for. Person-entiteten skal indeholde et person-id og et navn. Film -entiteten kan så indeholde oplysninger om, hvorvidt en film er udlånt til hvilket person-id og på hvilken dato. 18

19 1. Databaseteori Når en film ikke er udlånt, skal der ikke stå noget person-id i filmens post. Hvis vi laver en en til mange - relation fra Person til Film, kræver det, at der altid står et person-id i Film, som findes i Person - entiteten. Vi kan derfor ikke få lov at have ingenting til at stå i en post i entiteten Film. Det kaldes referentiel integritet og sikrer os mod at have ugyldige data i databasen. Figur 9: Tæt på, men ikke helt. I dette tilfælde er det ikke hensigtsmæssigt at have referentiel integritet. Derfor laver vi et join i stedet for en relation. Et join er en løsere form for relation, som tillader, at vi indtaster data i Film, som der ikke kan refereres til i Personer. Det retter vi til i diagrammet, og vi har nu et diagram, som vi kan betragte som færdigt (Figur 10). Vi kan nu tillade os at kalde entiteterne for tabeller, hvilket vi herefter gør. Fra nu af taler vi kun om tabeller og relationer. Figur 10: Vores færdige E-/R diagram. 19

20 1. Databaseteori Hvis du nu synes, at planlægningen af databasestrukturen har været meget forvirrende, så skal du ikke fortvivle og give op! Meget få mennesker i denne verden har forstået det hele første gang. I praksis vil det vise sig, at når vi begynder at arbejde med databasen i Access, vil du efterhånden forstå, hvordan det hænger sammen. Når vi er godt i gang med at lave filmkartoteket, kan du så vende tilbage til dette afsnit og læse det stille og roligt én gang til. Så er jeg sikker på, at alting giver meget mere mening. 1.4 Resterende planlægning Nu har du efterhånden lært nok databaseteori til, at du kan gå i gang med at lære Access at kende. Det, vi har planlagt indtil videre, giver ikke et komplet billede af det filmkartotek, vi skal ende med at have. Vi har udelukkende planlagt, hvilke tabeller vi skal have, og hvordan de skal relatere sig til hinanden. Det er til gengæld også nok til, at vi kan begynde at lave den grundlæggende database. Senere skal vi finde ud af, hvordan vi lægger data ind i tabellerne, og hvordan vi trækker dem ud igen på forskellige måder. Vi skal også lave nogle pæne skærmbilleder, så det til sidst ender med at ligne et helt lille program, du selv har lavet. Alt det burde man i praksis også tænke lidt over på forhånd og eventuelt tegne nogle skitser. Det springer vi dog let og elegant hen over i denne bog. Jeg har planlagt det hele på forhånd, så du kan koncentrere dig om at få noget hands-on -erfaring i stedet for. Derefter vil du uden videre selv kunne foretage dén del af planlægningen. 20