Grundlæggende oplysninger om databasedesign

I denne artikel

• Nogle vigtige databaseudtryk

• Hvad er et godt databasedesign?

• Designprocessen

• Fastslå formålet med databasen

• Find og organiser de nødvendige oplysninger

• Inddel oplysninger i tabeller

• Omdan oplysningselementer til kolonner

• Angiv primære nøgler

• Opret tabelrelationerne

• Finjuster designet

• Anvend normaliseringsreglerne

Nogle vigtige databaseudtryk

Access organiserer dine oplysninger i tabeller: lister over rækker og kolonner, der minder om en revisors blok eller et regneark. I en simpel database har du muligvis kun én tabel. For de fleste databaser skal du bruge mere end én. Du kan f.eks. have en tabel, der gemmer oplysninger om produkter, en anden tabel, der lagrer oplysninger om ordrer, og en anden tabel med oplysninger om kunder.

Hver række kaldes mere korrekt en post, og hver kolonne, et felt. En post er en meningsfuld og ensartet måde at kombinere oplysninger om noget på. Et felt er et enkelt oplysningselement – en elementtype, der vises i hver post. I tabellen Produkter indeholder hver række eller post f.eks. oplysninger om ét produkt. Hver kolonne eller hvert felt indeholder nogle typer oplysninger om det pågældende produkt, f.eks. dets navn eller pris.

Toppen af siden

Hvad er et godt databasedesign?

Der er visse principper, som udgør en vejledning for processen med at designe en database. Det første princip er, at dublerede oplysninger (også kaldet overflødige data) er noget makværk, fordi det er spild af plads og øger risikoen for fejl og uoverensstemmelser. Det andet princip er, at oplysningernes korrekthed og fuldstændighed er vigtig. Hvis databasen indeholder forkerte oplysninger, vil alle rapporter, der trækker oplysninger fra databasen, også indeholde forkerte oplysninger. Som resultat deraf vil de beslutninger, du træffer, som er baseret på disse rapporter, derfor bygge på et forkert grundlag.

Et godt databasedesign er derfor et, som:

• Opdeler dine oplysninger i emnebaserede tabeller for at reducere mængden af redundante data.

• Giver Acces de oplysninger, der er nødvendige for at sammenføje oplysningerne i tabellerne efter behov.

• Er med til at understøtte og sikre dine oplysningers nøjagtighed og integritet.

• Er tilpasset dine data- og rapporteringsbehov.

Toppen af siden

Designprocessen

Designprocessen består af følgende trin:

• Fastslå formålet med databasen    

  Dette er med til at forberede dig til de resterende trin.

• Find og organiser de nødvendige oplysninger     

  Indhent alle de typer oplysninger, du vil registrere i databasen, f.eks. produktnavn og ordrenummer.

• Inddel oplysningerne i tabeller    

  Inddel dine oplysningselementer i overordnede enheder eller emner såsom Produkter eller Ordrer. Hvert emne bliver så til en tabel.

• Omdan oplysningselementer til kolonner    

  Beslut, hvilke oplysninger du vil gemme i hver tabel. Hvert element bliver til et felt og vises som en kolonne i tabellen. Tabellen Medarbejdere kan f.eks. indeholde felter som Efternavn og Ansættelsesdato.

• Angiv primære nøgler    

  Vælg en primær nøgle for hver tabel. Den primære nøgle er en kolonne, der bruges til entydigt at identificere hver række. Et eksempel kan være Produkt-id eller Ordre-id.

• Konfigurer tabelrelationerne    

  Kig på hver tabel, og beslut, hvordan dataene i den ene tabel er relateret til data i andre tabeller. Føj felter til tabeller, eller opret nye tabeller for at tydeliggøre relationer, som det er nødvendigt.

• Tilpas dit design    

  Analysér dit design for fejl. Opret tabellerne, og tilføj nogle få poster med eksempeldata. Se, om du kan hente de ønskede resultater fra tabellerne. Foretag justeringer i designet efter behov.

• Anvend normaliseringsreglerne    

  Anvend datanormaliseringsreglerne for at se, om tabellerne er struktureret korrekt. Foretag justeringer i tabellerne efter behov.

Toppen af siden

Fastslå formålet med databasen

Det er en god ide at skrive formålet med databasen ned på papir – dens formål, hvordan du forventer at bruge den, og hvem der vil bruge den. For en lille database til en hjemmebaseret virksomhed kan du f.eks. skrive noget simpelt som f.eks. "Kundedatabasen holder en liste over kundeoplysninger med henblik på at producere forsendelser og rapporter.". Hvis databasen er mere kompleks eller bruges af mange personer, som det ofte sker i en virksomhed, kan formålet nemt være et afsnit eller mere og bør omfatte, hvornår og hvordan hver person skal bruge databasen. Ideen er at have en veludviklet mission erklæring, der kan henvises til gennem hele designprocessen. En sådan erklæring hjælper dig med at fokusere på dine mål, når du træffer beslutninger.

Toppen af siden

Find og organiser de nødvendige oplysninger

Hvis du vil finde og organisere de nødvendige oplysninger, skal du starte med dine eksisterende oplysninger. Du kan f.eks. registrere indkøbsordrer i en hovedbog eller opbevare kundeoplysninger på papirformularer i et arkivskab. Indsaml disse dokumenter, og angiv hver type oplysninger, der vises (f.eks. hvert felt, du udfylder i en formular). Hvis du ikke har nogen eksisterende formularer, kan du i stedet forestille dig, at du skal designe en formular for at registrere kundeoplysningerne. Hvilke oplysninger vil du angive i formularen? Hvilke udfyldningsfelter ville du oprette? Identificer og opliste hvert af disse elementer. Antag f.eks., at du i øjeblikket beholder kundelisten på indekskort. Undersøgelse af disse kort kan vise, at hvert kort indeholder et kundenavn, adresse, by, stat, postnummer og telefonnummer. Hvert af disse elementer repræsenterer en potentiel kolonne i en tabel.

Når du forbereder denne liste, skal du ikke bekymre dig om at gøre det hele perfekt i første forsøg. Prøv i stedet at angive alle de elementer, du kommer i tanke om. Hvis andre skal bruge databasen, kan du også spørge dem om deres ideer. Du kan finjustere listen senere.

Dernæst skal du overveje de typer rapporter eller forsendelser, du måske vil oprette fra databasen. Det kan f.eks. være, at du vil have en produktsalgsrapport til at vise salg efter område eller en oversigtsrapport over lager, der viser produktlagerniveauer. Du kan også oprette standardbreve, der skal sendes til kunder, der annoncerer en salgsbegivenhed eller tilbyder en præmie. Design rapporten i dit sind, og forestil dig, hvordan den vil se ud. Hvilke oplysninger vil du anbringe i rapporten? Vis hvert element. Gør det samme for standardbrevet og for alle andre rapporter, du forventer at skulle oprette.

At overveje de rapporter og forsendelser du måske kommer til at oprette, hjælper dig med at identificere de elementer, du skal bruge i databasen. Antag eksempelvis, at du giver kunderne mulighed for at tilmelde sig (eller framelde sig) periodiske mailopdateringer, og du vil udskrive en liste over dem, der har tilmeldt sig. For at registrere disse oplysninger tilføjer du en kolonne med navnet "Send mail" i tabellen. For hver kunde kan du angive feltet til Ja eller Nej.

Kravet om at sende mails til kunder medfører, at der skal registreres endnu et element. Når du ved, at en kunde ønsker at modtage mails, skal du også kende den mailadresse, du skal sende dem til. Derfor skal du registrere en mailadresse for hver kunde.

Det giver god mening at konstruere en prototype af hver rapport eller output notering og overveje, hvilke elementer du skal bruge til at producere rapporten. Når du f.eks. undersøger et standardbrev, kan der komme et par ting i tankerne. Hvis du vil medtage en korrekt hilsen – f.eks. strengen "Hr.", "Fru" eller "Ms", der starter en hilsen, skal du oprette et starthilsenelement. Du kan også typisk starte et bogstav med "Kære Hr. Smith" i stedet for "Kære. Mr. Sylvester Smith". Dette foreslår, at du typisk vil gemme efternavnet adskilt fra fornavnet.

Et vigtigt punkt at huske er, at du skal opdele hver oplysning i dens mindste nyttige dele. Hvis der er tale om et navn, skal du opdele navnet i to dele – fornavn og efternavn for at gøre efternavnet umiddelbart tilgængeligt. Hvis du f.eks. vil sortere en rapport efter efternavn, hjælper det at få kundens efternavn gemt separat. Hvis du vil sortere, søge, beregne eller rapportere baseret på et oplysningselement, skal du placere elementet i sit eget felt.

Tænk over de spørgsmål, du måske vil have databasen til at besvare. Hvor mange salg af dit udvalgte produkt lukkede du f.eks. sidste måned? Hvor bor dine bedste kunder ? Hvem er leverandøren af dit bedst sælgende produkt? Hvis du forventer disse spørgsmål, hjælper det dig med at komme ind på yderligere elementer, der skal registreres.

Efter at have indsamlet disse oplysninger er du klar til det næste trin.

Toppen af siden

Inddel oplysningerne i tabeller

Hvis du vil inddele oplysningerne i tabeller, skal du vælge de overordnede enheder eller emner. Når du f.eks. har fundet og organiseret oplysninger om en produktsalgsdatabase, kan den foreløbige liste se sådan ud:

De overordnede enheder, der er vist her, er produkterne, leverandørerne, kunderne og ordrerne. Det giver derfor mening at starte med disse fire tabeller: en til fakta om produkter, én til fakta om leverandører, én til fakta om kunder og en til fakta om ordrer. Selvom det ikke fuldfører listen, er det et godt sted at starte. Du kan fortsætte med at finjustere listen, indtil du har et design, der fungerer godt.

Når du første gang gennemser den foreløbige liste over elementer, kan det være fristende at samle dem alle i én enkelt tabel i stedet for de fire, der er vist i den foregående illustration. Du finder ud af her, hvorfor det er en dårlig ide. Overvej et øjeblik den tabel, der er vist her:

I dette tilfælde indeholder hver række oplysninger om både produktet og dets leverandør. Da du kan have mange produkter fra den samme leverandør, skal oplysninger om leverandørens navn og adresse gentages mange gange. Det er spild af diskplads. Det er en meget bedre løsning kun at registrere leverandøroplysningerne én gang i en separat tabel med Leverandører, og derefter sammenkæde den pågældende tabel med tabellen Produkter.

Et andet problem med dette design bliver tydeligt, når du vil redigere oplysninger om leverandøren. Antag f.eks., at du vil ændre en leverandørs adresse. Da den vises mange forskellige steder, ændrer du måske adressen ved et uheld ét sted, men glemmer at ændre den de andre steder. Du løser dette problem ved kun at registrere leverandørens adresse ét sted.

Når du designer din database, skal du altid forsøge at optage hvert enkelt faktum én gang. Hvis du oplever, at du gentager de samme oplysninger på mere end ét sted, f.eks. adressen for en bestemt leverandør, skal du placere disse oplysninger i en separat tabel.

Et sidste scenarie kan være, at Coho Winery kun leverer ét produkt, som du gerne vil slette, men du vil gerne bevare oplysningerne om leverandørens navn og adresse. Hvordan vil du med slette produktposten uden at miste leverandøroplysningerne? Det kan du ikke. Da hver post indeholder oplysninger om et produkt samt oplysninger om en leverandør, kan du ikke slette det ene uden også at slette det andet. Du kan derfor inddele den ene tabel i to dele for at holde disse oplysninger adskilt: den første til produktoplysninger og den anden til leverandøroplysninger. Når du sletter en produktpost, sletter du så kun oplysningerne om produktet, og ikke oplysningerne om leverandøren.

Når du har valgt det emne, der er repræsenteret af en tabel, bør kolonnerne i den pågældende tabel kun gemme oplysninger om emnet. Eksempelvis skal produkttabellen kun indeholde oplysninger om produkter. Da leverandøradressen er en oplysning om leverandøren og ikke en oplysning om produktet, hører det til i leverandørtabellen.

Toppen af siden

Omdan oplysningselementer til kolonner

For at bestemme kolonnerne i en tabel skal du beslutte, hvilke oplysninger der skal registreres om emnet i tabellen. Til tabellen Kunder kunne Navn, Adresse, Postnummer By, Send mail, Starthilsen og Mailadresse være et godt udgangspunkt for listen over kolonner. Hver post i tabellen indeholder det samme sæt af kolonner, så du kan gemme oplysninger om Navn, Adresse, Postnummer By, Send mail, Starthilsen og Mailadresseoplysninger for hver post. Eksempelvis indeholder adressekolonnen kundernes adresser. Hver post indeholder data om én kunde, og adressefeltet indeholder adressen på den pågældende kunde.

Når du har fastlagt det første sæt kolonner for hver tabel, kan du indskrænke kolonnerne yderligere. Det giver f.eks. mening at gemme kundenavnet som to separate kolonner: fornavn og efternavn, så du kun kan sortere, søge og indeksere på disse kolonner. På samme måde består adressen faktisk af fem separate komponenter, adresse, by, stat, postnummer og land/område, og det giver også mening at gemme dem i separate kolonner. Hvis du f.eks. vil udføre en søgning, filtrering eller sortering efter tilstand, skal du have oplysninger om tilstanden gemt i en separat kolonne.

Du bør også overveje, om databasen indeholder oplysninger, der kun er nationale eller internationale. Hvis du f.eks. planlægger at gemme internationale adresser, er det bedre at have en kolonne af typen Område i stedet for Stat, fordi en sådan kolonne kan rumme både indenlandske stater og områder i andre lande/områder. På samme måde giver postnummer mere mening end postnummer, hvis du vil gemme internationale adresser.

Følgende liste viser nogle tip til at beslutte dig for dine kolonner.

• Medtag ikke beregnede data    

  I de fleste tilfælde bør du ikke gemme resultatet af beregninger i tabeller. I stedet kan du få Access til at udføre beregningerne, når du vil se resultatet. Antag f.eks., at der er en Rapport over produkter på ordre, der viser subtotalen for enheder i ordre for hver produktkategori i databasen. Der er dog ingen subtotalkolonne for Enheder i rækkefølge i nogen tabel. I stedet indeholder tabellen Produkter kolonnen Enheder efter ordre, der gemmer enhederne på ordre for hvert produkt. Ved hjælp af disse data beregner Access subtotalen, hver gang du udskriver rapporten. Selve subtotalen må ikke gemmes i en tabel.

• Gem oplysninger i deres mindste logiske dele    

  Du kan være fristet til at have et enkelt felt til fulde navne eller til produktnavne sammen med produktbeskrivelser. Hvis du kombinerer mere end én type oplysninger i et felt, er det svært at hente individuelle oplysninger senere. Prøv at opdele oplysninger i logiske dele; Opret f.eks. separate felter til for- og efternavn eller til produktnavn, kategori og beskrivelse.

Når du har justeret datakolonnerne i hver tabel, er du klar til at vælge en primær nøgle for hver tabel.

Toppen af siden

Angiv primære nøgler

Hver tabel indeholder en kolonne eller et sæt af kolonner, som entydigt identificerer hver række, der er gemt i tabellen. Dette er ofte et entydigt id, såsom et medarbejder-id eller et serienummer. I databaseterminologi kaldes oplysningerne for tabellens primære nøgle. Access bruger primær nøglefelter til hurtigt at tilknytte data fra flere tabeller og samle data for dig.

Hvis du allerede har et entydigt id for en tabel, f.eks. et produktnummer, der entydigt identificerer hvert produkt i kataloget, kan du bruge dette id som tabellens primære nøgle – men kun hvis værdierne i denne kolonne altid vil være forskellige for hver post. Du kan ikke have dublerede værdier i en primær nøgle. Brug f.eks. ikke personers navne som en primær nøgle, da navne ikke er entydige. Du kan nemt have to personer med samme navn i den samme tabel.

En primær nøgle skal altid have en værdi. Hvis en kolonnes værdi kan blive ikke-tildelt eller ukendt (en manglende værdi) på et tidspunkt, kan den ikke bruges som en komponent i en primær nøgle.

Du bør altid vælge en primær nøgle, hvis værdi ikke ændres. En tabels primære nøgle kan bruges som reference i andre tabeller i en database, der anvender mere end én tabel. Hvis den primære nøgle ændres, skal ændringen også anvendes overalt, hvor der refereres til nøglen. Når du bruger en primær nøgle, der ikke ændres, reduceres risikoen for, at den primære nøgle ikke bliver synkroniseret med andre tabeller, der refererer til den.

Ofte bruges et vilkårligt entydigt tal som den primære nøgle. Du kan f.eks. tildele hver ordre et entydigt ordrenummer. Ordrenummerets eneste formål er at identificere en ordre. Når den er tildelt, ændres den aldrig.

Hvis du ikke tænker på en kolonne eller et sæt af kolonner, der kan være en god primær nøgle, kan du overveje at bruge en kolonne med datatypen Automatisk nummerering. Når du bruger datatypen Automatisk nummerering, tildeler Access automatisk en værdi for dig. En sådan identifikator er faktaløs; Den indeholder ingen faktuelle oplysninger, der beskriver den række, den repræsenterer. Faktaløse id'er er ideelle til brug som primær nøgle, fordi de ikke ændres. En primær nøgle, der indeholder oplysninger om en række – f.eks. et telefonnummer eller et kundenavn – ændres sandsynligvis, fordi selve de faktuelle oplysninger kan ændres.

1. En kolonne, der er angivet til datatypen Automatisk nummerering udgør ofte en god primær nøgle. Der er ikke to produkt-id'er, der er ens.

I nogle tilfælde kan det være en ide at bruge to eller flere felter, som tilsammen udgør den primære nøgle for en tabel. Eksempelvis bruger en tabel med ordreoplysninger, der gemmer linjeelementer til ordrer, måske to kolonner til den primære nøgle: Ordre-id og produkt-id. Når en primær nøgle anvender mere end én kolonne, kaldes den også en sammensat nøgle.

Du kan oprette kolonnen Automatisk nummerering for hver af tabellerne som primær nøgle for produktsalgsdatabasen: Produkt-id for tabellen Produkter, Ordre-id for tabellen Ordrer, Kunde-id for tabellen Kunder og Leverandør-id for tabellen Leverandører.

Toppen af siden

Opret tabelrelationerne

Nu, hvor du har opdelt dine oplysninger i tabeller, skal du bruge en metode til at samle oplysningerne igen på en meningsfuld måde. Følgende formular indeholder oplysninger fra flere tabeller.

1. Oplysningerne i denne formular stammer fra tabellen Kunder...

2. ... tabellen Medarbejdere ...

3. ... tabellen Ordrer ...

4. ... tabellen Produkter ...

5. ... og tabellen Ordredetaljer.

Access er et relationsdatabasesystem. I en relationsdatabase inddeler du oplysningerne i separate, emnebaserede tabeller. Du kan derefter bruge tabelrelationer til at samle oplysninger efter behov.

Toppen af siden

Finjuster designet

Når du har de tabeller, felter og relationer, du skal bruge, skal du oprette og udfylde tabellerne med eksempeldata og prøve at arbejde med oplysningerne: oprette forespørgsler, tilføje nye poster osv. Dette er med til at fremhæve potentielle problemer – det kan f.eks. være nødvendigt at tilføje en kolonne, som du har glemt at indsætte i designfasen, eller du har muligvis en tabel, som du skal opdele i to tabeller for at fjerne duplikering.

Se, om du kan bruge databasen til at få de svar, du ønsker. Opret grove udkast til formularer og rapporter, og se, om de viser de data, du forventer. Hold øje med unødvendig duplikering af data, og rediger dit design for at fjerne dubletterne, når du finder dem.

Når du afprøver din første database, vil du sikkert opdage, at der er plads til forbedring. Her er nogle ting, du skal kontrollere:

• Har du glemt nogen kolonner? Hvis det er tilfældet, hører oplysningerne så til i de eksisterende tabeller? Hvis det er oplysninger om noget andet, skal du muligvis oprette en anden tabel. Opret en kolonne for hvert oplysningselement, du skal registrere. Hvis oplysningerne ikke kan beregnes ud fra andre kolonner, er det sandsynligt, at du skal bruge en ny kolonne til dem.

• Er der nogen kolonner, der er unødvendige, fordi de kan beregnes ud fra eksisterende felter? Hvis et oplysningselement kan beregnes ud fra andre eksisterende kolonner – f.eks. en nedsat pris beregnet ud fra salgsprisen – er det normalt bedre at gøre netop det og undgå at oprette en ny kolonne.

• Indtaster du gentagne gange de samme oplysninger i en af tabellerne? Hvis det er tilfældet, skal du sandsynligvis dele tabellen i to tabeller, der har en en-til-mange-relation.

• Har du tabeller med mange felter, et begrænset antal poster og mange tomme felter i individuelle poster? Hvis det er tilfældet, skal du overveje at ændre tabellens design, så den har færre felter og flere poster.

• Er hvert oplysningselement blevet opdelt i dets mindste brugbare dele? Hvis du vil rapportere, sortere, søge eller beregne på et oplysningselement, skal du placere det pågældende element i sin egen kolonne.

• Indeholder hver kolonne en oplysning om tabellens emne? Hvis en kolonne ikke indeholder oplysninger om tabellens emne, hører det til i en anden tabel.

• Er alle relationer mellem tabeller repræsenteret enten af almindelige felter eller af en tredje tabel? En-til-en- og en-til-mange-relationer kræver fælles kolonner. Mange-til-mange-relationer kræver en tredje tabel.

Anvend normaliseringsreglerne

Du kan anvende datanormaliseringsreglerne (sommetider blot kaldet normaliseringsregler) som det næste trin i dit design. Du bruger disse regler til at se, om tabellerne er struktureret korrekt. Processen med at anvende regler på databasedesignet kaldes normalisering af databasen, eller bare normalisering.

Normalisering er især nyttigt, når du har angivet alle oplysningerne og har opnået midlertidigt design. Formålet er at hjælpe dig med at sikre, at du har opdelt dine oplysningselementer i de rette tabeller. Normalisering kan dog ikke sikre, at du har alle de korrekte dataelementer til at starte med.

Du skal anvende reglerne i rækkefølge på hvert enkelt trin for at sikre, at dit design ender med at have en af de såkaldte "normalformer". Fem normalformer er generelt anerkendt – fra den første normalform til den femte normalform. Denne artikel beskæftiger sig med de første tre, fordi de dækker alt, hvad der kræves for størstedelen af databasedesigns.