Grundlæggende oplysninger om databasedesign

Grundlæggende oplysninger om databasedesign

En korrekt designet database giver dig adgang til nøjagtige oplysninger, der er opdateret. Da et korrekt design er afgørende for, at du når dine mål i arbejdet med en database, er det værd at investere den tid, der kræves for lære principperne for godt design. I sidste ende er der meget større sandsynlighed for, at du ender med en database, der opfylder dine behov, og som nemt kan tilpasses ændringer.

I denne artikel får du retningslinjer for planlægning af en skrivebordsdatabase. Du lærer at beslutte, hvilke oplysninger du har brug for, hvordan du inddeler disse oplysninger i de rette tabeller og kolonner, og hvordan disse tabeller er relateret til hinanden. Du bør læse denne artikel, før du opretter din første skrivebordsdatabase.

Vigtigt: Access giver designoplevelser, der gør det muligt at oprette databaseprogrammer til internettet. Mange designovervejelser er anderledes, når du designer til internettet. I denne artikel diskuteres der ikke design af webdatabaseprogrammer. Du kan få mere at vide i artiklen Opbyg en database, der skal deles på internettet.

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 af rækker og kolonner, der minder om en bogholders blok eller et regneark. I en simpel database har du muligvis kun én tabel. I de fleste databaser skal du bruge mere end én. Det kan f.eks. være, at du har en tabel, der lagrer oplysninger om produkter, en anden tabel, der lagrer oplysninger om ordrer, og en tredje tabel med oplysninger om kunder.

Tre tabeller i dataark

Hver række kaldes mere korrekt en post, og hver kolonne kaldes et felt. En post er en meningsfuld og ensartet måde til at kombinere oplysninger om noget. Et felt er et enkelt oplysningselement – en elementtype, der vises i hver post. I tabellen Produkter vil f.eks. hver række eller post indeholde oplysninger om et produkt. Hver kolonne eller hvert felt indeholder en eller anden form for oplysninger om produktet, 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 det vises som en kolonne i tabellen. Medarbejdertabellen 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 notere formålet med databasen på papir – dens formål, hvordan du forventer at bruge den, og hvem der skal bruge den. Hvis du laver en lille database til en virksomhed i hjemmet, kan du f.eks. skrive noget simpelt såsom "Kundedatabasen indeholder en liste over kundeoplysninger med det formål at producere mails og rapporter". Hvis databasen er mere kompleks eller bruges af mange personer, som det ofte er tilfældet i en virksomhed, kan formålet nemt fylde et helt afsnit eller mere, og det bør omfatte, hvornår og hvordan de enkelte personer skal bruge databasen. Ideen er at få et veludviklet idegrundlag, som der kan refereres til gennem hele designprocessen. Ved at have sådan et grundlag kan du fokusere på dine mål, når du træffer beslutninger.

Toppen af siden

Find og organiser de nødvendige oplysninger

Start med dine eksisterende oplysninger, når du skal finde og organisere de nødvendige oplysninger. Eksempelvis registrerer du måske indkøbsordrer i en hovedbog, eller du har kundeoplysninger i formularer på papir i et arkivskab. Indsaml disse dokumenter, og opfør alle typer oplysninger, der vises (f.eks. hvert felt, du udfylder i en formular). Hvis du ikke har nogen eksisterende formularer, skal du i stedet forestille dig, at du skal designe en formular til at registrere kundeoplysninger. Hvilke oplysninger ville du skrive i formularen? Hvilke felter til udfyldning ville du oprette? Identificer og angiv hvert af disse elementer. Lad os antage, at du aktuelt har kundelisten på kartotekskort. Hvert af disse kort indeholder eventuelt en kundes navn, adresse, by, 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.

Derefter skal du overveje den type af rapporter eller mails, du vil oprette ud fra databasen. Det kan f.eks. være, at du vil have en produktsalgsrapport til at vise salg efter område, eller en oversigtsrapport for lagerbeholdning, der viser lagerbeholdninger for produkter. Du kan også oprette standardbreve til at sende til kunder, der giver besked om salgsbegivenheder eller tilbyder en bonus. Design rapporten i hovedet, og forestil dig, hvordan den kommer til at se ud. Hvilke oplysninger vil du skrive i rapporten? Angiv hvert element. Gør det samme for standardbrevet og alle andre rapporter, du regner med at skulle oprette.

Person, der forestiller sig en lagerrapport

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 er en god idé at opbygge en prototype for hver rapport eller outputoversigt og overveje, hvilke elementer du skal bruge for at danne rapporten. Når du f.eks. undersøger et standardbrev, kommer du måske i tanke om nogle ting. Hvis du vil medtage en formel titulering – f.eks. strengen "Hr.", "Fr." eller "Frk.", der indleder en hilsen, skal du oprette et starthilsenelement. Du kan også typisk starte et brev med "Kære hr. Jensen" i stedet for "Kære hr. Sylvester Jensen". Dette antyder, at man normalt bør gemme efternavnet adskilt fra fornavnet.

En vigtig ting at huske på er, at du bør inddele hver enkelt oplysning i dens mindste brugbare dele. Tilfældet af et navn ville du for at gøre efternavnet let tilgængeligt skulle inddele navnet i to dele – fornavn og efternavn. Hvis du f.eks. vil sortere en rapport efter efternavn, hjælper det at have kundens efternavn gemt separat. Hvis du vil sortere, søge, beregne eller rapportere baseret på et oplysningselement, bør du generelt placere det pågældende element i sit eget felt.

Tænk over de spørgsmål, du kunne tænkes at ville have databasen til at give. Det kunne f.eks. være, hvor mange salg af et udvalgt produkt lukkede du i sidste måned? Hvor bor jeres bedste kunder? Hvem er leverandøren af jeres bedst sælgende produkt? Ved at forudse disse spørgsmål kan du rette ind mod andre 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

For at inddele oplysningerne i tabeller skal du vælge de overordnede enheder eller emner. Efter at have fundet og organiseret oplysninger til en produktsalgsdatabase, kunne den foreløbige liste f.eks. se sådan ud:

Håndskrevne oplysninger, der er inddelt i emner

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:

Tabel, der indeholder både produkter og leverandører

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 kun at registrere hvert enkelt oplysning én gang. Hvis du opdager, at du gentager de samme oplysninger på mere end ét sted, f.eks. adressen på en bestemt leverandør, kan 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 besluttet dig for det første sæt kolonner til hver tabel, kan du finjustere kolonnerne yderligere. Det vil f.eks. give mening at gemme kundens navn som to separate kolonner: Fornavn og Efternavn, så du kan sortere, søge og indeksere udelukkende på disse kolonner. På samme måde består adressen faktisk af fire separate komponenter: adresse, postnummer, by 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, filtrerings- eller sorteringshandling efter postnummer, skal oplysningerne om postnummer gemmes i en separat kolonne.

Du skal også overveje, om databasen skal indeholde oplysninger, der kun er nationale eller kun udenlandske. Hvis du f.eks. planlægger at gemme udenlandske adresser, kan det være nødvendigt at have en kolonne for Stat i stedet for område, fordi en sådan kolonne kan tage højde for både nationale områder og delstater i andre lande/områder. På samme måde, giver Zip Code måske bedre mening, hvis du skal gemme amerikanske 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å Acces til at udføre beregningerne, når du vil have vist resultatet. Lad os f.eks. antage, at der er en rapport for produkter i ordre, der viser subtotalen for bestilte enheder for hver produktkategori i databasen. Men der er ikke nogen kolonne med subtotal for enheder i ordre i nogen tabel. I stedet indeholder tabellen Produkter kolonnen Enheder i ordre, der gemmer de bestilte enheder for hvert produkt. Ud fra disse data beregner Access subtotalen, hver gang du udskriver rapporten. Selve subtotalen bør ikke gemmes i en tabel.

  • Gem oplysninger i deres mindste logiske dele    

    Det kan være fristende at have ét enkelt felt til fulde navne eller til produktnavne sammen med produktbeskrivelser. Hvis du kombinere mere end én type af oplysninger i et felt, bliver det svært at hente de individuelle oplysninger senere. Prøv at inddele oplysningerne i logiske dele ved f.eks. at oprette separate felter til fornavn og efternavn eller til produktnavn, kategori og beskrivelse.

Billede, der viser oplysninger elementer under designprocessen

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 dit katalog, kan du bruge det pågældende 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. Du bør eksempelvis ikke bruge folks navne som primær nøgle, fordi navne ikke er entydige. Du kan nemt have to personer med det 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 der et vilkårligt entydigt nummer 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 det er blevet tildelt, ændres det aldrig.

Hvis du ikke har en kolonne eller et sæt af kolonner i tankerne, som kan udgø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. Sådan et id er faktaløst. Det indeholder ingen faktiske oplysninger, som beskriver den række, det repræsenterer. Faktaløse id'er er ideelle til brug som primære nøgler, fordi de ikke ændres. En primær nøgle, der indeholder oplysninger om en række – f.eks. et telefonnummer eller en kundes navn – vil med større sandsynlighed ændre sig, fordi de faktiske oplysninger kan blive ændret.

Tabellen Produkter med et primært nøglefelt

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.

Billede, der viser oplysninger elementer under designprocessen


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.

Formularen Ordrer

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

Opret en en-til-mange-relation

Overvej dette eksempel: Tabellerne Leverandører og Produkter i produktordredatabasen. En leverandør kan levere et vilkårligt antal produkter. Det følger, at for en hvilken som helst leverandør, der er repræsenteret i tabellen Leverandører, kan der være mange produkter repræsenteret i tabellen Produkter. Relationen mellem tabellen Leverandører og tabellen Produkter er derfor en en-til-mange-relation.

En-til-mange-relation

Når du skal repræsentere en en-til-mange-relation i databasedesignet, skal du tage den primære nøgle på en-siden af relationen og tilføje den som en eller flere ekstra kolonner i tabellen på mange-siden af relationen. I dette tilfælde skal du f.eks. tilføje en ny kolonne – kolonnen Leverandør-id fra tabellen Leverandører – i tabellen Produkter. Access kan derefter bruge leverandør-id'et i tabellen Produkter til at finde den korrekte leverandør til hvert produkt.

Kolonnen Leverandør-id i tabellen Produkter kaldes en fremmed nøgle. En fremmed nøgle er en anden tabels primære nøgle. Kolonnen Leverandør-id i tabellen Produkter er en fremmed nøgle, fordi den også er den primære nøgle i tabellen Leverandører.

Billede, der viser oplysninger elementer under designprocessen

Du levere grundlaget for at sammenføje relaterede tabeller ved at danne par mellem primære nøgler og fremmede nøgler. Hvis du ikke er sikker på, hvilke tabeller der skal dele en fælles kolonne, kan du ved at identificere en en-til-mange-relation sikre dig, at de to pågældende tabeller rent faktisk kræver en delt kolonne.

Toppen af siden

Opret en mange-til-mange-relation

Lad os se på relationen mellem tabellen Produkter og tabellen Ordrer.

En enkelt ordre kan omfatte mere end ét produkt, og et enkelt produkt kan forekomme i mange ordrer. Derfor kan der for hver post i tabellen Ordrer være mange poster i tabellen Produkter, og for hver post i tabellen Produkter kan der være mange poster i tabellen Ordrer. Denne type relation kaldes en mange til mange-relation, fordi der kan være mange ordrer på ethvert produkt, og i hver ordre kan der være mange produkter. Når du skal identificere en eksisterende mange til mange-relation, skal du derfor se på begge sider af relationen.

Emnerne i de to tabeller – ordrer og produkter – har en mange til mange-relation. Dette udgør et problem. For at forstå problemet skal du forestille dig, hvad der ville ske, hvis du forsøgte at oprette relationen mellem de to tabeller ved at tilføje feltet Produkt-id i tabellen Ordrer. Hvis du vil have mere end ét produkt pr. ordre, har du brug for mere end én post pr. ordre i tabellen Ordrer. Du ville ende med at gentage ordreoplysninger for hver række, der relaterer til en enkelt ordre – hvilket medfører et ineffektivt design, der kan føre til unøjagtige data. Du støder på det samme problem, hvis du placerer feltet Ordre-id i tabellen Produkter – så har du mere end én post i tabellen Produkter for hvert produkt. Hvordan kan problemet løses?

Løsningen er at oprette en tredje tabel, ofte kaldet en samlingstabel, der opdeler mange-til-mange-relationen i to en-til-mange-relationer. Du kan indsætte den primære nøgle fra hver af de to tabeller i den tredje tabel. Den tredje tabel registrerer dermed hver forekomst eller instans af relationen.

En mange-til-mange-relation

Hver post i tabellen Ordredetaljer repræsenterer ét linjeelement på en ordre. Den primære nøgle for tabellen Ordredetaljer består af to felter – de fremmede nøgler fra tabellerne Ordrer og tabellen Produkter. Det fungerer ikke at bruge feltet Ordre-id alene som den primære nøgle for denne tabel, fordi én ordre kan have mange linjeelementer. Ordre-id'et gentages for hvert linjeelement på en ordre, så feltet indeholder ikke entydige værdier. Det fungerer heller ikke kun at bruge feltet Produkt-id, fordi ét produkt kan være til stede i mange forskellige ordrer. Men sammen giver de to felter altid en entydig værdi for hver post.

I produktsalgsdatabasen er tabellen Ordrer og tabellen Produkter ikke direkte relateret til hinanden. I stedet er de indirekte relateret via tabellen Ordredetaljer. Mange-til-mange-relationen mellem ordrer og produkter er repræsenteret i databasen ved hjælp af to en-til-mange-relationer:

  • Tabellen Ordrer og tabellen Ordredetaljer har en en-til-mange-relation. Hver ordre kan have mere end ét linjeelement, men hvert linjeelement er kun forbundet til én ordre.

  • Tabellen Produkter og tabellen Ordredetaljer har en en-til-mange-relation. Hvert produkt kan have mange linjeelementer, der er knyttet til det, men hvert linjeelement refererer kun til ét produkt.

I tabellen Ordredetaljer kan du se alle produkterne på en bestemt ordre. Du kan også se alle ordrer på et bestemt produkt.

Efter at have inkorporeret tabellen Ordredetaljer kan listen over tabeller og felter se omtrent sådan ud:

Billede, der viser oplysninger elementer under designprocessen


Toppen af siden

Oprette en en til en-relation

En anden type relation er en en-til-en-relation. Antag f.eks., at du skal registrere nogle særlige supplerende produktoplysninger, som du sjældent skal bruge, eller som kun gælder for nogle få produkter. Da du ikke har brug for oplysningerne ofte, og fordi lagring af oplysningerne i tabellen Produkter resulterer i tomme pladser for hvert af de produkter, de ikke er gældende for, skal du placere dem i en separat tabel. Ligesom med tabellen Produkter bruger du Produkt-id som den primære nøgle. Forholdet mellem denne supplerende tabel og tabellen Produkter er en-til-en-relation. For hver post i tabellen Produkter findes der en enkelt matchende post i den supplerende tabel. Når du identificerer sådan en relation, skal begge tabeller have et felt til fælles.

Når du registrerer behovet for en-til-en-relation i din database, skal du overveje, om du kan sammensætte oplysningerne fra de to tabeller i én tabel. Hvis du af en eller anden grund ikke vil gøre det, måske fordi det resulterer i en masse tomme pladser, kan du i den følgende liste se, hvordan du kan repræsentere relationen i dit design:

  • Hvis de to tabeller ikke har det samme emne, kan du sandsynligvis konfigurere relationen ved at bruge den samme primære nøgle i begge tabeller.

  • Hvis de to tabeller har forskellige emner med forskellige primære nøgler, skal du vælge en af tabellerne (lige meget hvilken) og indsætte dens primære nøgle i den anden tabel som en fremmed nøgle.

Ved at fastslå relationer mellem tabeller kan du sikre dig, at du har de rette tabeller og kolonner. Når der findes en en-til-en- eller en en-til-mange-relation, skal de tabeller, det drejer sig om, have en eller flere fælles kolonner. Når der findes en mange-til-mange-relation, er der brug for en tredje tabel til at repræsentere relationen.

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 og så videre. Det gør det nemmere at opdage potentielle problemer – f.eks. kan det være nødvendigt at tilføje en kolonne, som du har glemt at indsætte i designfasen, eller du kan have en tabel, som skal opdeles i to tabeller for at fjerne dublering.

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 nogen af kolonnerne unødvendige, fordi de kan beregnes ud fra eksisterende felter? Hvis et oplysningselement kan beregnes ud fra eksisterende kolonner – f.eks. en rabatpris beregnet ud fra den almindelige salgspris – er det som regel bedre at gøre netop det og undlade 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.

Finjustering af tabellen Produkter

Antag, at hvert produkt i produktsalgsdatabasen falder inden for en overordnet kategori, f.eks. drikkevarer, krydderier eller fisk og skaldyr. Tabellen Produkter kan indeholde et felt, der viser kategorien for hvert produkt.

Antag, at du efter at have undersøgt og finjusteret databasens design beslutter dig for at gemme en beskrivelse af kategorien sammen med dens navn. Hvis du tilføjer feltet Beskrivelse af kategori i tabellen Produkter, skal du gentage hver kategoribeskrivelse for hvert produkt, der falder inden for kategorien – dette er ikke en god løsning.

En bedre løsning er at gøre Kategorier til et nyt emne, som databasen skal registrere, og give det sin egen tabel og sin egen primære nøgle. Du kan derefter tilføje den primære nøgle fra tabellen Kategorier i tabellen Produkter som en fremmed nøgle.

Tabellerne Kategorier og Produkter har en en-til-mange-relation: En kategori kan indeholde mere end ét produkt, men et produkt kan kun tilhøre én kategori.

Når du gennemgår dine tabelstrukturer, skal du være opmærksom på, om der er gentagende grupper. Hvis vi f.eks. tager en tabel, der indeholder følgende kolonner:

  • Produkt-id

  • Navn

  • Produkt-id1

  • Navn1

  • Produkt-id2

  • Navn2

  • Produkt-id3

  • Navn3

Her er hvert produkt en gentagende gruppe af kolonner, der kun adskiller sig fra de andre ved at tilføje et tal i slutningen af kolonnenavnet. Når du ser kolonner, der er nummereret på denne måde, skal du genoverveje dit design.

Sådan et design har flere svagheder. For det første tvinger det dig til at sætte en øvre grænse for antallet af produkter. Så snart du overskrider denne grænse, skal du tilføje en ny gruppe af kolonner i tabelstrukturen, hvilket er en større administrativ opgave.

Et andet problem er, at de leverandører, der har færre end det maksimale antal produkter, kommer til at spilde noget plads, da de ekstra kolonner vil være tomme. Den største svaghed i sådan et design er, at det gør mange opgaver svære at udføre, f.eks. sortering eller indeksering af tabellen efter produkt-id eller navn.

Når du opdager gentagende grupper, skal du gennemgå designet omhyggeligt med henblik på at opdele tabellen i to. I eksemplet ovenfor er det bedre at bruge to tabeller – én til leverandører og én til produkter – sammenkædet med leverandør-id.

Toppen af siden

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.

Første normalformular

Første normalform angiver, at der ved hver skæring mellem rækker og kolonner i en tabel findes en enkelt værdi og aldrig en liste af værdier. Du kan f.eks. ikke have et felt med navnet Pris, hvor du skriver mere end én pris. Hvis du betragter hvert skæringspunktet mellem rækker og kolonner som en celle, kan hver celle kun indeholde én værdi.

Anden normalform

Anden normalform kræver, at hver kolonne, der ikke er en nøgle, er fuldt ud afhængig af hele den primære nøgle og ikke kun en del af nøglen. Denne regel gælder, når du har en primær nøgle, der består af mere end én kolonne. Lad os f.eks. antage, at du har en tabel, der indeholder følgende kolonner, hvor Ordre-id og Produkt-id udgør den primære nøgle:

  • Ordre-id (primær nøgle)

  • Produkt-id (primær nøgle)

  • Produktnavn

Dette design overtræder anden normalform, fordi kolonnen Produktnavn er afhængig af Produkt-id, men ikke af Ordre-id, så den er ikke afhængig af hele den primære nøgle. Du skal fjerne Produktnavn fra tabellen. Den hører til i en anden tabel (Produkter).

Tredje normalform

Tredje normalform kræver ikke bare, at enhver kolonne, der ikke er en nøgle, skal være afhængig af den primære nøgle, men også at kolonner, som ikke er nøgler, skal være uafhængige af hinanden.

En anden måde at sige det på er, at hver kolonne, der ikke er en nøgle, skal være afhængig af den primære nøgle og intet andet end den primære nøgle. Hvis vi f.eks. antager, at du har en tabel, der indeholder følgende kolonner:

  • Produkt-id (primær nøgle)

  • Navn

  • Vejledende udsalgspris

  • Rabat

Antag, at Rabat afhænger af den vejledende udsalgspris. Denne tabel overholder ikke tredje normalform, fordi kolonnen Rabat, som ikke er en nøgle, er afhængig af en anden kolonne, som ikke er en nøgle, nemlig Vejledende udsalgspris. Kolonneuafhængighed betyder, at du skal kunne ændre eventuelle kolonner, som ikke er nøgler, uden at det påvirker andre kolonner. Hvis du ændrer en værdi i feltet Vejledende udsalgspris, ændres Rabat tilsvarende og overtræder dermed denne regel. I dette tilfælde bør Rabat flyttes til en anden tabel, som bruger Vejledende udsalgspris som nøgle.

Toppen af siden

Udvid dine færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Bliv Office Insider

Var disse oplysninger nyttige?

Tak for din feedback!

Tak for din feedback! Det lyder, som om det vil kunne hjælpe, hvis du bliver sat i forbindelse med en af vores Office-supportteknikere.

×