Smagsprøve. Databasedesign med Access 2000

Transkript

1

2 Smagsprøve Databasedesign med Access 2000 Helle Frederiksen ISBN: Link: Indholdsfortegnelse, forord og første kapitel Copyright IDG Forlag IDG Forlag Carl Jacobsens Vej Valby Telefon: Fax:

3 Indholdsfortegnelse Indledning... 4 Del I: Overblik...5 Databasebegreber... 5 Systemudviklingsbegreber... 5 Introduktion til Access Præsentation af case Centrale databasebegreber... 6 Administrative edb-systemer... 6 Standardsystem... 6 Database... 6 Relationsdatabase Systemudvikling hvad er det? Krav til systemet Brugerindflydelse Analyse af systemet Grundlæggende om Access Hovedelementerne Guider Databaseguiden Brugernes grænseflade Udviklerens grænseflade Tabeller Relationer Forespørgsler SQL-forespørgsler Formularer Rapporter Menusystemet Hæftets case et bibliotekssystem Del II: Analyse...36 Funktionsanalyse Dataanalyse Funktions- og dataanalyse Objektorienteret analyse Hvad skal man vælge? Struktureret Analyse Dataflowdiagrammet Kontekstdiagram Dataordbog Oversigtsdiagram Niveau Procesbeskrivelser Analyseresultat Dataanalyse Entitets-/relations-modellering E/R-diagram Kardinalitet E/R-diagram for Tegneseriesystemet Fra entitet til tabel Fra relation til tabel Normalisering Del III. Konstruktion...64 Hvad skal du bruge? Konstruktion af tabeller Låner By SerieAlbum og Serie Konstruktion af relationer Vælg tabeller ud Byg datamodellen op Definer relationer Udstedelse af lånerkort Proces 1, Udstedelse af lånerkort Skærmbilledet Indtast Låner Rapport til udskrivning af lånerkort Registrering af nye titler Proces 3, Registrering af ny titel Strategi Indtast EnkeltUdgivelse Skærmbillede til periodiske udgivelser Overordnet skærmbillede Udlånsadministration Registrering af udlån Registrering af afleveringer Udskrivning af rykkere Opsummering Menusystem Stikordsregister

4 Indledning Access er en repræsentant for de moderne relationsdatabasesystemer. Med et værktøj som dette kan du lynhurtigt fremstille velvoksne administrative edb-systemer med flotte brugergrænseflader menuer, skærmbilleder og muligheder for udskrivning af rapporter og alt sammen kan du lave ved hjælp af lettilgængelige værktøjer, som skåner dig for nærkontakt med programmering og rå data. Der findes megen anden litteratur, som beskriver Access s fortræffeligheder, og som netop sætter dig i stand til at producere fancy systemer på ingen tid. Det svage punkt i den meget hurtige tilgang til systemudvikling du tilbydes med programmer som Access og i meget af den litteratur, der følger i kølvandet er imidlertid at for hurtig udvikling kan komme til at betyde mangelfuld planlægning. Analysemetoder Et edb-system, som ikke er gennemtænkt, vil næppe leve op til forventningerne. Systemudvikling er ikke en af de discipliner, der lægger op til ad hoc-løsninger ved skærmen, efterhånden som man kommer i tanke om behovene. Dårlige edb-systemer er netop karakteriseret ved mange hovsaløsninger. Systemets kvalitet bliver højere, hvis behovene analyseres nøje før systemet konstrueres. Der findes metoder til denne analyse, og hæftets første målsætning er at præsentere dig for disse metoder. Ligeledes skal den database, edb-systemet hviler på, designes hensigtsmæssigt. Springer du let og elegant over selve databasedesignet, risikerer du at få en upålidelig database, som fylder for meget og som er vanskelig at vedligeholde. Hæftets anden målsætning er at præsentere dig for metoder, du kan anvende for at opnå en veldesignet relationsdatabase. Access Først som det tredje og sidste formål kommer selve arbejdet med Access. Hæftet beskriver hvordan du kommer fra din analyse til et velkonstrueret system. Hæftet er bygget over en case. Det er denne case, der analyseres, designes og opbygges, så du ender op med et færdigt kørende system. Opbygning Hæftet er delt op i tre dele: Første del giver dig overblik over den sammenhæng databasedesign optræder i. Du introduceres til de vigtigste begreber omkring databaser og systemudvikling, du får en introduktion til Access 2000, og endelig præsenteres du for hæftets case. Hæftets anden del præsenterer de metoder man anvender inden for systemudvikling og databasedesign. Metodevalg inden for disse områder diskuteres, og udvalgte metoder Struktureret Analyse kombineret med Entitets/Relationsmodellering gennemgås. Hæftets case udsættes for metoderne og en samlet analyse af systemet gennemføres trin for trin. Hæftets tredje del er viet til konstruktion af case-systemet ved hjælp af Access Udgangspunktet er analysen af casen fra hæftets anden del og resultatet er et kørende system med brugergrænseflade. Hæftet indeholder undervejs mange opgaver, som fungerer som et vigtigt supplement til gennemgangene. En del af analyse og konstruktion af systemet ligger desuden i opgaverne der er ikke plads i hæftet til at gennemgå alle aspekter. 4

5 Del I: Overblik Hæftets første del skal give dig et overblik over hele det problemområde, du nu skal til at beskæftige dig med. Databasebegreber Du skal i gang med at arbejde med databaser, og derfor lægger jeg ud med et kapitel, kapitel 1, Centrale databasebegreber, som handler om, hvad databaser er, og hvori du får en gennemgang af nogle af alle de mange udtryk, der følger med, når man snakker om databaser og den sammenhæng databaser optræder i. Vi ser på, hvad en relationsdatabase er, og hvad den består af, og vi ser på de principielle problemer, der er forbundet med at designe disse databaser. Systemudviklingsbegreber Databasedesign står aldrig alene når man har brug for en database, er det altid i sammenhæng med udviklingen af et edb-system, der kan arbejde med databasen. Kapitel 2, Systemudvikling hvad er det?, giver en hurtig gennemgang af, hvad systemudviklingsprocessen består af (altså ud over at handle om at konstruere selve databasen). Vi kommer ind på, hvordan et systemudviklingsprojekt opdeles i faser, og hvilke problemer man uvægerligt vil løbe ind i, når man som systemudvikler skal skabe et system, som skal fungere i en bestemt sammenhæng med en bestemt brugergruppe. Introduktion til Access 2000 I hæftet her skal du også lære praktisk databasedesign og -konstruktion ved hjælp af et bestemt værktøj, nemlig Access I kapitel 3, Grundlæggende om Access, får du en gennemgang af værktøjet. Med udgangspunkt i et konkret system ser vi på alle de mange ingredienser i systemet, som du får brug for at arbejde aktivt med i hæftets sidste del, når case-systemet skal konstrueres. Introduktionen til Access vil også give dig en mere konkret fornemmelse af de databasebegreber, der blev introduceret i kapitel 1. Kapitel 3 indeholder også en introduktion til det søgesprog, SQL, der anvendes i Access. SQL anvendes også i mange andre databasesystemer. Præsentation af case Endelig indeholder denne del af hæftet en introduktion til hæftets case. Det sker i kapitel 4, Hæftets case et bibliotekssystem. Hæftets case er et system til et tegneseriebibliotek, hvor udlån skal administreres. 5

6 1. Centrale databasebegreber Hæftet her handler om, hvordan man udvikler edb-systemer ved hjælp af et relationsdatabasesystem. Men det er ikke et hvilket som helst edb-system, som opbygges ved hjælp af databasesystemer for eksempel vil man bruge helt andre værktøjer til udvikling af systemer som for eksempel regnearksprogrammer eller computerspil. Administrative edb-systemer De systemer, der her er tale om, kaldes også for administrative edb-systemer. Det er nemlig edbsystemer, der bruges til at administrere og holde styr på et eller andet. Det kan være alt mellem himmel og jord. Det kan være et edb-system på en skole, som skal bruges til at holde styr på de karakterer, elever i forskellige klasser får af forskellige lærere, så der kan udskrives terminskarakterer. Det kunne også være et system, som kan bruges når man vil søge i en samling musikcd er efter en bestemt plade, kunstner, gruppe etc. Eller det kunne være et reservationssystem for billetter biografbilletter, flybilletter eller koncertbilletter. Det kan også være et system, som holder styr på et firmas indkomne ordrer, og sørger for udskrift af faktura til kunden, når en ordre er ekspederet. Fælles for systemerne er, at de skal holde styr på mange ting hvad enten disse ting nu er skoleelever, flyafgange eller varebestillinger. Standardsystem Administrative edb-systemer anvendes mange steder i erhvervslivet. For eksempel er systemer som det sidst omtalte ordresystemet et system, som skal bruges i næsten alle virksomheder. Systemer, som anvendes mange steder, vil ofte blive udviklet som standardsystemer. Et standardsystem er et administrativt edb-system, som kan bruges af mange forskellige virksomheder. Det er et system, som nogen har udviklet og nu udbyder til salg. Disse nogen har fået øje på, at der fandtes et generelt behov og dermed et marked for et system, som kan købes fikst og færdigt og som opfylder dette behov. Står man altså og skal bruge et edb-system af en type, som er meget udbredt, kan man derfor være heldig og slippe for besværet og i stedet købe et standardsystem. Eksisterer der et standardsystem, som opfylder ens behov, vil det næsten altid være en stor fordel at vælge dette. Det er tidskrævende og dermed kostbart at udvikle edb-systemer, og med standardsystemer er man mange om at betale regningen også selv om sælgeren tager en ordentlig luns af kagen. Det betyder, at standardsystemer (som regel da) vil være af en højere kvalitet end det man selv kan lave der er simpelthen flere ressourcer til at gennemarbejde systemet, og for eksempel sørge for at det er helt fejlfrit. Er man klog, skal man derfor holde sig til standardsystemer, når man kan slippe af sted med det, og begrænse sig til systemudvikling, når det drejer sig om systemer, som netop ikke fås som hyldevarer. Database Et edb-system, som skal administrere og holde styr på en masse ting, må nødvendigvis gemme, hente og opdatere en masse informationer eller data. I ordresystemet er disse data oplysninger om kunder, ordrer, varer og priser for eksempel, der skal holdes styr på. I flybilletsystemet er det blandt andet billetreservationer og flyafgange der skal gemmes data om. Edb-systemet benytter sig af en database til at holde styr på alle oplysningerne. En database er et sted på computeren, hvor ensartede data omkring et eller andet emne eller problemfelt gemmes på en måde, så man kan søge i dem, og så de kan ændres, slettes og udvides efter behov. 6

7 1. Centrale databasebegreber Relationsdatabase Databaser kan være opbygget på mange forskellige måder; men i øjeblikket er de fleste databaser af typen relationsdatabaser. En relationsdatabase er en database, hvor data er organiseret i tabeller over systemets ting eller enheder, og hvor der imellem disse tabeller er relationer. I den særlige terminologi, der anvendes, når man taler om databaser, bruges begrebet entiteter om systemets enheder. Eksempler på entiteter er elever, lærere og fag i et skoleadministrationssystem og varer og leverandører i et lagerstyringssystem. Tabel En tabel kender du mange andre steder fra for eksempel fra et regneark. Den er organiseret i nogle rækker og søjler. Når vi taler databaser, kaldes en række i tabellen for en post, og en kolonne kaldes et felt. En database, som indgår i et lønsystem, kan for eksempel have en medarbejdertabel, som ser sådan ud: Cpr Fornavn Efternavn Hanne Frandsen Børge Andersen Henrik Hansen Figur 1.1. En simpel tabel over medarbejdere. Hver medarbejder har en post (række) i tabellen. For hver medarbejder har tabellen en række ensartede oplysninger en post repræsenterer en medarbejder. Et felt er en bestemt oplysning, som gemmes om alle medarbejdere, for eksempel feltet Efternavn, som bruges til at gemme medarbejdernes efternavne! Medarbejdere er en entitet altså en vigtig enhed i en database, som bruges af for eksempel et lønsystem. Men hvad mener man med at der er relationer mellem tabellerne? For at se behovet for relationer skal du præsenteres for et par klassiske databaseproblemer: Forestil dig, at medarbejderne i lønsystemet ovenfor har en timeløn og en arbejdstid, der afhænger af hvilken afdeling de arbejder i. Lønnen vil de fleste steder være individuel; men forestil dig, at det er sådan. En nærliggende måde at registrere disse oplysninger på er da, at du udvider medarbejdertabellen med nogle felter, som indeholder disse oplysninger. Resultatet kunne for eksempel være som i figur 1.2. Redundans Men tabellen i figur 1.2 er meget problematisk. Forestil dig at tabellen rummer et stort antal medarbejdere fordelt på en række afdelinger den vil da indeholde mange gentagelser. Medarbejdere i samme afdeling har jo samme timeløn og samme arbejdstid. Gentagelser i en database kaldes redundans. Redundans er et stort problem af flere forskellige grunde: For det første koster det plads på harddisken. Nu er harddiske efterhånden kommet ned på et overkommeligt prisleje men med store databaser betyder det noget. Cpr Fornavn Efternavn Afdeling Timeløn Arbejdstid Hanne Frandsen Børge Andersen Henrik Hansen ,5 Figur 1.2. Tabellen er udvidet med tre felter, så informationer om timeløn og arbejdstid også er kommet med. 7

8 Del I: Overblik Et andet problem er, at det bliver mere tidskrævende at søge i basen simpelthen fordi det tager længere tid at søge i en stor base end i en lille. Der er også andet, der er besværligt: Når en ny medarbejder skal tilføjes til basen, skal man samtidig indtaste værdier for timeløn og arbejdstid for den pågældendes afdeling, selv om disse informationer allerede forekommer til hudløshed i databasen. Inkonsistens Men især er det meget omstændeligt at ændre noget i en database med udpræget redundans. Ændres timelønnen for eksempel for afdeling C ja, så skal denne værdi ændres hos samtlige medarbejdere i afdeling C. Og er man ikke omhyggelig med opdateringer af databasen, risikerer man at værdien ikke bliver ændret alle steder. Herved opstår der et alvorligt problem, for det bliver umuligt at afgøre, hvilken værdi for timelønnen der er rigtig. Begrebet for denne upålidelighed i en database er inkonsistens. Poster med forskellig længde Et tredje problem i at ville gemme alle sine data i en enkelt tabel er, at posterne ofte vil få forskellig længde. Forestil dig for eksempel en musikdatabase, hvor der skal holdes styr på musikgrupper og gruppemedlemmer. Her vil antallet af gruppemedlemmer ikke være givet på forhånd man kan forestille sig alt mellem 1 og 10 (og måske ville 20 eller 30 være en mere passende grænse?). Posterne kan komme til at se ud som i figur 1. 3 (nederst på siden). Som det fremgår af denne figur, har tabellens poster forskellige længder, og kun når antallet af gruppemedlemmer en sjælden gang er oppe på 10, udnyttes pladsen i tabellen fuldt ud. Og før eller siden støder man på en gruppe, som har mere end 10 gruppemedlemmer, og hvad så? Hertil kommer, at musikere har det med at indgå i nye grupper og her vil musikerens navn blive gentaget i basen, og der opstår dermed en vis redundans. I eksemplet her indgår musikerne Sven Svin og Søren Sund hver i to forskellige grupper. Problemet kan løses ved at give hver gruppe flere poster, nemlig én for hvert gruppemedlem. Løsningsforslaget ser du her: Gruppenavn Fornavn Efternavn The Group Sven Svin The Group Søren Sund The Group Line Lang The Group Lone List Banden Kaj Kvist Banden Søren Sund Banden Louise Last Kinky Brothers Sven Svin Kinky Brothers Sune Sand Figur 1.4. Mulig løsning på problemet med poster af forskellig længde. Posterne har nu ens længde. Prisen er dog mere redundans i tabellen. Gruppenavnet (og i en virkelig database kunne man forestille sig, at der blev gemt flere oplysninger om gruppen i databasen end blot navnet) gentages nu. Gruppenavn Nr. 1 Nr. 2 Nr. 3 Nr. 4 Nr. 5 Nr. 6 Nr. 7 Nr. 8 Nr. 9 Nr. 10 The Group Sven Svin Søren Sund Line Lang Lone List Banden Kaj Kvist Søren Sund Louise Last Kinky Brothers Sven Svin Sune Sand Figur 1.3. Tabellen over musikgrupper og gruppemedlemmer har poster, hvis længde afhænger af antallet af gruppemedlemmer. 8

9 1. Centrale databasebegreber Redundansen fra før gentagelse af en musikers navn, når vedkommende indgår i flere grupper, er heller ikke forsvundet. Endelig kunne man forestille sig en løsning, som går ud på at lave en tabel med et felt, Gruppemedlemmer, for hver gruppe, hvor samtlige gruppemedlemmers navne indgår. Der kan for eksempel som her være komma imellem navnene for at adskille dem: Gruppe Gruppemedlemmer The Group Sven Svin, Søren Sund, Line Lang, Lone List Banden Kaj Kvist, Søren Sund, Louise Last Kinky Brothers Sven Svin, Sune Sand Figur 1.5: Nyt forsøg på at gøre posterne lige lange. Men også her har vi knap løst ét problem, før et par nye dukker op. Problemet med at have gruppemedlemmerne smækket sammen i et enkelt tekstfelt er, at det bliver betydelig vanskeligere at søge på gruppemedlemsnavne i basen. Når man arbejder med store mængder data, vil man desuden ofte have behov for at kunne sortere dem navne vil man for eksempel tit få brug for at kunne ordne alfabetisk. Men hvordan skal man kunne ordne denne tabel alfabetisk efter gruppemedlemmer, når et gruppemed- lem ikke har sit eget felt? Hertil kommer, at der igen vil være en (godt nok begrænset, men alligevel!) redundans i de tilfælde, hvor et gruppemedlem spiller i flere forskellige grupper. Relationer Det er for at komme disse problemer til livs, at relationsdatabaser er opbygget som de er. Princippet i relationsdatabaser er, at de enkelte data i basen så vidt muligt kun optræder en gang, og det opnår man ved at oprette særskilte tabeller til alle systemets entiteter. I lønsystem-eksemplet fra figur 1.2 (se side 7), skal du således oprette to tabeller: en for entiteten medarbejdere og en for entiteten afdelinger. I Afdelingstabellen skal der blot være en enkelt post pr. afdeling og på den måde undgår du at skulle gentage afdelingsoplysningerne. Hvis tabellen fra figur 1.2 bare splittes op i to tabeller, vil der imidlertid gå information tabt: nemlig informationen om, hvilken afdeling en medarbejder arbejder i (og implicit: hvilken arbejdstid og timeløn vedkommende derfor har). Det er netop her, at begrebet relation kommer ind i billedet. Relationen består i en henvisning eller reference mellem tabellerne. I eksemplet her er relationen konstrueret ved feltet Afdeling i Medarbejdertabellen, som refererer til feltet Afdeling i Afdelingstabellen: Cpr Fornavn Efternavn Afdeling Hanne Frandsen Børge Andersen Henrik Hansen Peter Poulsen Sofie Hansen 3 Medarbejdertabel Afdeling Timeløn Arbejdstid ,5 Afdelingstabel Figur 1.6. Tabellen fra figur 1.2 opdeles i to: en Medarbejdertabel og en Afdelingstabel. Feltet Afdeling i Medarbejdertabellen refererer til feltet Afdeling i Afdelingstabellen. En relation mellem to tabeller er simpelthen en henvisning (du kan også kalde det en link) som knytter to tabeller sammen. Ved hjælp af henvisningen i Medarbejdertabellen kan man slå op i Afdelingstabellen og finde ud af, hvilken arbejdstid og timeløn en given medarbejder har. Her er ingen redundans. 9

10 Del I: Overblik I eksemplet med musikgrupperne og gruppemedlemmerne (se figur 1.3 side 8) er opdelingen noget vanskeligere: Entiteterne i eksemplet er klare nok, der skal naturligvis være en Gruppetabel og en Musikertabel. Men relationen mellem de to tabeller er ikke lige så nem at indføre som i forrige eksempel. Indføres et felt i Musikertabellen, som kan referere til den gruppe, musikeren er medlem af, ja, så opstår der et problem, når den pågældende musiker er medlem af flere grupper. Og ideen med blot at indføje flere felter til at referere til musikerens forskellige grupper ja, det vil være at bede om at få problemet med poster af forskellig længde igen. Løsningen er at opsplitte tabellen i tre: en Gruppetabel, en Musikertabel og desuden en relationstabel, som kunne hedde Gruppemedlemskab. Gruppemedlemskabstabellen kommer til at binde de to andre tabeller sammen ved at referere til de numre, der nu er indført for grupper og musikere. Se resultatet i figur 1.7. Nøglefelter Feltet Afdeling i Afdelingstabellen er et entydigt nummer, som hver afdeling har. At det er entydigt betyder, at hvert nummer kun forekommer en gang. Et sådant felt kaldes et nøglefelt. Feltet Afdeling i Medarbejdertabellen, som indeholder referencen til nøglefeltet i Afdelingstabellen, kaldes en lånenøgle (I Access kaldes det for en fremmednøgle). Medarbejdertabellen indeholder også et nøglefelt det er feltet Cpr. Alle medarbejdere har forskellige cpr-numre. I eksemplet med grupper og gruppemedlemmer er feltet Gruppenummer i Gruppetabellen og Musikernummer i Musikertabellen nøglefelter. Derimod er felterne Gruppenummer og Musikernummer i Gruppemedlemskabstabellen begge lånenøgler. For Gruppe- og Musikertabellens vedkommende er nøglefelterne her indføjet, fordi der kan forekomme grupper med samme navne og mere sandsynligt musikere med samme navne. Gruppe- Gruppe_ nummer navn 1 The Group 2 Banden 3 Kinky Brothers Gruppe- Musikernummer nummer Musiker- Fornavn Efternavn nummer 1 Svend Svin 2 Søren Sund 3 Line Lang 4 Lone List 5 Kaj Kvist 6 Loise Last 7 Sune Sand Gruppetabel Gruppemedlemskab Musikertabel Figur 1.7. De tre tabeller for musikgrupper og medlemmer af grupper. Læg mærke til, at posterne i Gruppetabellen og i Musikertabellen nu nummereres fortløbende. Når der refereres fra en tabel til en anden, er det nødvendigt at referere entydigt. Havde der i løneksemplet været flere afdelinger med samme numre, ville det ikke være muligt at slå op i tabellen efter arbejdstid og timeløn for en medarbejder for var det den ene eller den anden afdeling 2 s værdier, der skulle bruges? 10

11 1. Centrale databasebegreber Når mennesker kan finde ud af, ved hjælp af en sådan reference, at slå op i en tabel og finde relaterede felter til en post, så kan en computer også den er oven i købet særlig velegnet til netop sådanne mekaniske arbejdsopgaver. Relationsdatabasesystemet indeholder netop mange faciliteter til at opbygge og søge i sådanne systemer af relaterede tabeller. Databasedesign Omkostningen ved at splitte databasen op i mange små tabeller er, at det bliver mere besværligt at arbejde med den. Hver gang du skal have fat i en samling oplysninger, skal de sammenstykkes fra mange relaterede tabeller, og det betyder at du som databaseudvikler skal have styr på, hvordan du får databasesystemet til at slå op i de rigtige tabeller. Det er derfor vigtigt at være meget omhyggelig med opdelingen af databasen i tabeller, så man undgår redundans- og inkonsistens-problemer, og så man alligevel kan sammenstykke de informationer man har brug for fra basen. Arbejdet med at opsplitte databasen i relaterede tabeller kaldes databasedesign. Del II, kapitel 6 (side 51) handler om databasedesign og de metoder man kan anvende. Opgaver Opgave 1. Deltag i Database-quizzen og svar på følgende spørgsmål: Hvad er en database? Hvad er redundans i en database? Hvad er inkonsistens i en database? Hvad er en relationsdatabase? Hvad er en databasetabel? Hvad er en post (når vi taler om databaser)? Hvad er et felt i en databasetabel? Hvad er en relation mellem databasetabeller? Hvad er et nøglefelt? Hvad er en lånenøgle? Hvad er en entitet? Opgave 2. Hvorfor vil man undgå redundans i databaser, og hvad kan man gøre for at undgå det? Opgave 3. Hvorfor er det ikke så smart, at posterne i en database har forskellig længde? Opgave 4. Forestil dig en database til registrering af videofilm og forestil dig, at databasen skal bruges i en videobutik, hvor kunderne skal kunne søge efter bestemte film. Hvilke entiteter mener du systemet skal operere med? Opgave 5. Forestil dig en database til registrering af, hvilke klasser en flok skoleelever går i. Hvilke tabeller vil du foreslå? Opgave 6. Forestil dig et firma, hvor arbejdet er organiseret i projekter. I hvert projekt deltager et vilkårligt antal medarbejdere; den enkelte medarbejder kan deltage i flere projekter. Og forestil dig så en database, som skal bruges til at registrere, hvilke medarbejdere der deltager i hvilke projekter. Hvilke tabeller vil du foreslå? 11