Grundlæggende oplysninger om databasedesign

En veldesignet database giver adgang til nøjagtige oplysninger, der er up to date. Da et korrekt design er afgørende for at opnå de ønskede resultater med en database, er det en god idé at investere tid i at sætte sig ind i grundprincipperne for et godt design. Det vil i sidste ende sikre, at en database kan opfylde de ønskede behov og nemt tilpasses nødvendige ændringer.

I denne artikel findes retningslinjer for planlægning af en database til pc. Du skal lære at fastlægge, hvilke oplysninger du har brug for, hvordan oplysningerne skal fordeles på tabeller og kolonner, og hvordan tabellerne skal være indbyrdes relateret. Du bør læse denne artikel, før du opretter den første database til pc.

 Vigtigt!   Microsoft Access 2010 giver adgang til en ny designoplevelse, hvor du kan oprette databaseprogrammer til internettet. Mange designmæssige overvejelser er anderledes, når man designer til internettet. Denne artikel beskriver ikke design af databaseprogrammer til internettet. Du kan få flere oplysninger i artiklen Opbygge en database til deling på internettet.

Denne artikel indeholder


Nogle vigtige databaseudtryk

I Access 2010 organiseres oplysninger i tabeller: Lister med rækker og kolonner, der minder om regnskabsbilag eller et regneark. I en simpel database er der måske kun én tabel. Til de fleste databaser skal du bruge mere end én tabel. Du kan f.eks. have en tabel med oplysninger om produkter, en anden tabel med oplysninger om ordrer og en tredje tabel med oplysninger om kunder.

Tre tabeller i dataark

En række kaldes mere korrekt for en post, og en kolonne kaldes for et felt. En post er en logisk og konsekvent måde at sammensætte oplysninger på. Et felt er et enkelt element med oplysninger, der vises i hver post. Hvis du f.eks. har tabellen Produkter, indeholder hver række eller post oplysninger om ét produkt. Hver kolonne eller felt indeholder oplysninger om produktet, f.eks. dets navn eller pris.

Tilbage til toppen Tilbage til toppen

Hvad er et godt databasedesign?

Der er visse principper for databasedesignprocessen. Det første princip er at undgå dubletdata (eller overflødige data), fordi de er spild af plads og øger risikoen for fejl og uregelmæssigheder. Det andet princip er, at dataenes nøjagtighed og fuldkommenhed spiller en afgørende rolle. Hvis databasen indeholder forkerte oplysninger, vil alle rapporter, der baseres på databasen, også indeholde forkerte oplysninger, så de beslutninger, som rapporterne danner grundlag for, også bliver forkerte.

Et godt databasedesign skal derfor opfylde følgende:

  • Fordele oplysningerne på emnebaserede tabeller for at undgå overflødige data.
  • Give Access de oplysninger, der er nødvendige for at kunne sammensætte tabeloplysningerne på den ønskede måde.
  • Sikre nøjagtigheden og integriteten af oplysningerne.
  • Skabe udgangspunktet for den ønskede databehandling og rapportering.

Tilbage til toppen Tilbage til toppen

Designprocessen

Designprocessen består af følgende trin:

  • Fastslå formålet med databasen    

Denne fase skal bane vejen for de resterende trin.

  • Finde og organisere de nødvendige oplysninger     

Du skal indsamle alle de typer oplysninger, du kunne tænke dig at registrere i databasen, f.eks. produktnavn og ordrenummer.

  • Inddele oplysningerne i tabeller    

Du skal inddele oplysningerne i overordnede enheder eller emner som f.eks. produkter eller ordrer. Hvert emne skal derefter blive til en særskilt tabel.

  • Gøre oplysninger til kolonner    

Du skal fastlægge, hvilke oplysninger der skal gemmes i hver enkelt tabel. Hvert element bliver til et felt, der vises som en kolonne i tabellen. Tabellen Medarbejdere kan f.eks. indeholde felterne Efternavn og Ansættelsesdato.

  • Angive primære nøgler    

Du skal vælge hver tabels primære nøgle. Den primære nøgle er en kolonne, der bruges til entydigt at identificere den enkelte række. Det kan f.eks. være Produkt-id eller Ordre-id.

  • Oprette tabelrelationer    

Gennemgå hver enkelt tabel for at fastlægge, hvordan dataene i en tabel er relateret til dataene i andre tabeller. Tilføj felter i tabeller, eller opret nye tabeller for at etablere de nødvendige relationer.

  • Optimere designet    

Du skal undersøge, om designet har fejl. Opret tabeller, og tilføj nogle poster med eksempeldata. Find ud af, om tabellerne giver de ønskede resultater. Foretag justeringer af designet efter behov.

  • Anvende normaliseringsregler    

Du skal anvende normaliseringsregler på dataene for at finde ud af, om tabellerne har den korrekte struktur. Foretag justeringer af tabellerne efter behov.

Tilbage til toppen Tilbage til toppen

Fastslå formålet med databasen

Det er en god idé at nedfælde formålet med databasen på papir: Hvad du forventer at skulle bruge den til, og hvem der skal bruge den. Ved en lille database til brug i en mindre privat virksomhed kan du f.eks. skrive "Kundedatabase med liste over kundeoplysninger til fremstilling af adresselister og rapporter". Hvis databasen er mere kompleks eller skal bruges af mange personer, som det ofte er tilfældet i erhvervslivet, kan formålet nemt fylde et helt tekstafsnit og indeholde oplysninger om, hvem der skal bruge databasen hvornår. Det gælder om at have en velformuleret formålserklæring, der kan anvendes i hele designprocessen. Men en sådan beskrivelse kan du nemmere arbejde målrettet, når du skal tage beslutninger.

Tilbage til toppen Tilbage til toppen

Finde og organisere de nødvendige oplysninger

Når du skal finde frem til og organisere de ønskede data, skal du starte med de eksisterende oplysninger. Du har måske registreret poster med indkøbsordrer i et finansregnskab eller registreret kundeoplysninger i papirformularer, der er opbevaret i et arkiv. Du skal samle disse dokumenter og oprette en liste over alle typer oplysninger (f.eks. hver rubrik, der skal udfyldes i en formular). Hvis du ikke har eksisterende formularer, skal du i stedet forestille dig, at du skal designe en formular til registrering af kundeoplysninger. Hvilke oplysninger skal medtages i formularen? Hvilke rubrikker skal oprettes? Du skal identificere og oprette en liste over alle disse punkter. Lad os f.eks. antage, at du allerede har kundelister på kartotekskort. På hvert kort findes en kundes navn, adresse, by, postnummer og telefonnummer. Hver af disse oplysninger kan blive til en kolonne i en tabel.

Mens du opretter listen, behøver den ikke være perfekt i første omgang. Du skal bare notere dig hvert eneste interessante punkt. Hvis andre skal bruge databasen, kan du forhøre dig hos dem. Du kan altid finjustere listen senere.

Derefter skal du beslutte, hvilke typer af rapporter eller adresselister, du vil fremstille ud fra databasen. Du vil måske have en produktsalgsrapport, der viser salg pr. region, eller en lagerrapport, der viser lagerbeholdninger. Du kan også oprette standardbreve, der skal sendes til kunderne, med oplysninger om udsalg og bonustilbud. Forestil dig rapportens design med udseende og indhold. Hvilke oplysninger skal placeres i rapporten? Skriv alle punkter op. Gør det samme med standardbrevet og eventuelle andre rapporter, du regner med at skulle oprette.

Person, der forestiller sig en lagerrapport

Hvis du nøje overvejer de rapporter og adresselister, du måske vil oprette, kan du nemmere identificere de elementer, du skal bruge i databasen. Du vil måske give kunderne mulighed for at tilmelde (eller framelde) sig regelmæssige nyheder via e-mail, og du vil udskrive en liste over tilmeldingerne. Du kan registrere disse oplysninger ved at tilføje kolonnen “Send e-mail” i kundetabellen. For hver kunde kan du indstille feltet til Ja eller Nej.

Kravet om at skulle sende e-mail til kunderne medfører registrering af endnu et element. Når du ved, at en kunde ønsker at modtage oplysninger via e-mail, skal du også kende den e-mail-adresse, de skal sendes til. Derfor skal du registrere en e-mail-adresse for hver kunde.

Det er en god idé at konstruere en prototype af hver rapport eller outputliste og overveje, hvilke elementer du skal bruge til at fremstille rapporten. Der er et par ting, du skal tage højde for, når du skal oprette et standardbrev. Hvis du vil medtage en indledende hilsen, f.eks. strengen "Hr.", "Fru" eller "Frøken", skal du oprette et hilsenelement. Du kan også indlede et brev med “Kære hr. Smith” i stedet for “Kære hr. Søren Smith”. Det betyder, at du skal registrere efternavnet et andet sted end fornavnet.

Det er meget vigtigt at være opmærksom på, at du skal opdele alle oplysninger i deres mindste brugbare dele. I forbindelse med navne skal du inddele dem i to: fornavn og efternavn. Hvis du f.eks. skal sortere en rapport efter efternavn, er det nyttigt at have registreret efternavnet for sig. Hvis du vil kunne sortere, søge efter, beregne eller rapportere data på basis af en bestemt oplysning, skal du placere den i et særskilt felt.

Du skal tænke over, hvilke spørgsmål databasen skal give svar på. Det kan f.eks. være, hvor mange tilbudsprodukter der blev solgt sidste måned, hvor de mest trofaste kunder bor, eller hvem der er leverandør af det mest solgte produkt. Hvis du kender disse spørgsmål på forhånd, kan du bedre sørge for at få registreret de nødvendige elementer.

Når du har disse oplysninger klar, kan du gå videre til næste trin.

Tilbage til toppen Tilbage til toppen

Inddele oplysningerne i tabeller

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

Håndskrevne oplysninger, der er inddelt i emner

De overordnede emner, der er vist her, er produkterne, leverandørerne, kunderne og ordrerne. Derfor giver det mening at starte med disse fire tabeller: en til fakta om produkter, en til fakta om leverandører, en til fakta om kunder og en til fakta om ordrer. Det fuldender ikke listen, men er et godt udgangspunkt. Du kan blive ved med at finjustere denne liste, indtil du har et velfungerende design.

Når du i første omgang gennemgår den foreløbige liste med punkter, vil du måske være fristet til at placere dem alle i en enkelt tabel i stedet for de fire, der er vist på ovenstående illustration. Du vil dog opdage, at det er en dårlig idé. Prøv at se nærmere på denne tabel:

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 samme leverandør, er leverandørens navn og adresse gentaget mange gange. Det er spild af diskplads. Hvis du kun registrerer leverandøroplysningerne én gang i en separat leverandørtabel, og du derefter sammenkæder denne tabel med tabellen Produkter, er det en meget bedre løsning.

Et andet problem med dette design bliver indlysende, når du skal redigere oplysninger om leverandøren. Du kan f.eks. blive tvunget til at ændre leverandørens adresse, og fordi den står så mange steder, glemmer du måske at få den ændret overalt. Registrering af leverandørens adresse et enkelt sted er løsningen på problemet.

Når du designer en database, skal du altid bestræbe dig på kun at registrere hvert enkelt faktum én gang. Hvis du gentager den samme oplysning flere steder, f.eks. adressen på en bestemt leverandør, skal du placere oplysningerne i en separat tabel.

Lad os også antage, at der kun er ét produkt fra en bestemt leverandør, og du vil slette produktet, men bevare leverandørens navn og adresse. Hvordan kan du så slette produktposten uden at miste leverandøroplysningerne? Det kan ikke lade sig gøre. Da hver post både indeholder fakta om et produkt og leverandøren, kan du ikke slette den ene oplysning uden også at slette den anden. Du skal holde disse fakta adskilt fra hinanden ved at inddele den ene tabel i to: en tabel til produktoplysningerne og en anden tabel til leverandøroplysningerne. Når du sletter en produktpost, bør du kun slette oplysningerne om produktet, ikke oplysningerne om leverandøren.

Når du har valgt det emne, som en tabel skal repræsentere, skal tabellens kolonner kun indeholde fakta vedrørende emnet. Produkttabellen skal f.eks. kun indeholde oplysninger om produkter. Da leverandøradressen er en oplysning om leverandøren, og ikke om produktet, skal den placeres i leverandørtabellen.

Tilbage til toppen Tilbage til toppen

Gøre oplysninger til kolonner

Når du skal definere kolonnerne i en tabel, skal du beslutte, hvilke oplysninger der skal registreres om emnet i tabellen. I tabellen Kolonner vil det f.eks. være logisk at registrere navn, adresse, postnummer-by, e-mail-adresse, hilsen og, om der skal sendes e-mail, i kolonner. Alle poster i tabellen indeholder de samme kolonner, så du kan gemme oplysningerne om navn, adresse, postnummer-by, e-mail-adresse, hilsen og, om der skal sendes e-mail, for hver post. Adressekolonnen indeholder f.eks. kundernes adresser. Hver post indeholder data om én kunde, og adressefeltet indeholder kundens adresse.

Når du har fastlagt de kolonner, du som udgangspunkt vil have i den enkelte tabel, kan du finjustere kolonnerne. Det kan f.eks. give mening at registrere kundenavnet i to separate kolonner, fornavn og efternavn, så du kan sortere, søge i og indeksere disse kolonner for sig. Desuden består adressen af fire separate komponenter: adresse, postnummer, by og land. Det er derfor hensigtsmæssigt at gemme dem i separate kolonner. Hvis du f.eks. vil foretage en søgning, filtrering eller sortering efter landenavne, skal landedataene gemmes i en særskilt kolonne.

Du bør også overveje, om databasen kun skal indeholde oplysninger, der vedrører indenlandske forhold, eller om den også skal dække udenlandske forhold. Hvis du f.eks. har planer om at gemme internationale adresser, er det bedst at have en kolonneoverskrift, der både dækker Danmark, lokalområder, delstater eller regioner i andre lande. Du skal også være opmærksom på, at udenlandske postnumre er anderledes end danske postnumre.

På nedenstående liste findes nogle tip om fastlæggelse af kolonner.

  • Udelad beregnede data    

I de fleste tilfælde skal du ikke gemme resultatet af beregninger i tabeller. Du skal i stedet få Access til at foretage beregningerne, når du ønsker at se resultaterne. Du kan f.eks. have rapporten Bestilte produkter, der viser subtotalen af bestilte enheder pr. produktkategori i databasen. Der findes dog ingen subtotalkolonne med bestilte ordrer i tabellen. I stedet indeholder produkttabellen en kolonne med bestilte enheder, der indeholder de bestilte enheder pr. produkt. Access kan bruge disse data til at beregne subtotalen, hver gang du udskriver rapporten. Selve subtotalen skal ikke gemmes i en tabel.

  • Gem oplysninger i mindst mulige logiske dele    

Du vil måske være fristet til at have et enkelt felt til fulde navne eller til både produktnavne og produktbeskrivelser. Hvis du kombinerer mere end én slags oplysninger i et felt, er det svært at indlæse individuelle oplysninger. Prøv at inddele oplysningerne i logiske enheder ved f.eks. at oprette separate felter til fornavn og efternavn eller produktnavn og produktbeskrivelse.

Liste over dataelementer i designprocessen

Når du har finjusteret datakolonnerne i hver enkelt tabel, er du klar til at vælge hver tabels primære nøgle.

Tilbage til toppen Tilbage til toppen

Angive primære nøgler

Hver tabel skal indeholde en kolonne eller et sæt kolonner, der entydigt identificerer hver række i tabellen. Der er ofte et entydigt identifikationsnummer som f.eks. et id-nummer, et serienummer eller en kode, der fungerer som primær nøgle. I databaseterminologi kaldes disse oplysninger tabellens primære nøgle. I Access bruges primære nøglefelter til hurtigt at forbinde data fra forskellige tabeller.

Hvis du allerede har en entydig identifikator for en tabel som f.eks. et produktnummer, der entydigt identificerer hvert enkelt produkt i kataloget, kan du bruge denne identifikator som tabellens primære nøgle, men kun hvis værdierne i kolonnen altid er forskellige for de enkelte poster. Du kan ikke have dubletværdier i en primær nøgle. Du må f.eks. ikke bruge personnavne som primær nøgle, da navne ikke er unikke. Der kan nemt være to personer med samme navn i samme tabel.

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

Du bør altid vælge en primær nøgle, hvis værdi ikke bliver ændret. I en database, der bruger mere end én tabel, kan tabellens primære nøgle bruges som reference i andre tabeller. Hvis den primære nøgle bliver ændret, skal ændringen også anvendes alle de steder, der refererer til nøglen. Hvis du bruger en primær nøgle, der ikke bliver ændret, mindskes risikoen for, at den primære nøgle mister synkroniseringen med andre tabeller, der refererer til den.

Ofte bruges et vilkårligt entydigt nummer som primær nøgle. Du kan f.eks. tildele hver ordre et entydigt ordrenummer. Det eneste formål med ordrenummeret er at identificere en ordre. Når det først er tildelt, bliver det aldrig ændret.

Hvis du ikke har nogen idé til en kolonne eller sæt af kolonner, der er velegnet som primær nøgle, bør du overveje at bruge en kolonne, der har datatypen Autonummerering. Når du bruger datatypen Autonummerering, tildeles den automatisk en værdi. En sådan identifikator indeholder ingen faktuelle oplysninger, der beskriver den række, som den repræsenterer, og er derfor ideel som primær nøgle, fordi den aldrig bliver ændret. En primær nøgle, der indeholder fakta om en række, f.eks. et telefonnummer eller kundenavn, har større sandsynlighed for at blive ændret, fordi de faktiske oplysninger kan skifte.


Tabellen Produkter med et primært nøglefelt

Billedtekst 1 En kolonne med datatypen Autonummerering et ofte velegnet som primær nøgle, fordi ingen produkt-id'er er ens.

I nogle tilfælde kan du få brug for to eller flere felter, der tilsammen udgør den primære nøgle i en tabel. Tabellen Ordredetaljer, der indeholder vareposter til ordrer, bruger f.eks. to kolonner i dens primære nøgle: Ordre-id og produkt-id. Når en primær nøgle benytter mere end én kolonne, kaldes den også en sammensat nøgle.

Til produktsalgsdatabasen kan du for hver tabel oprette kolonnen Autonummerering som primær nøgle: Produkt-id for tabellen Produkter, Ordre-id for tabellen Ordrer, Kunde-id for tabellen Kunder og Leverandør-id for tabellen Leverandører.

Billede af dataelementer under designproces

Tilbage til toppen Tilbage til toppen

Oprette tabelrelationer

Nu, hvor du har inddelt oplysningerne i tabeller, skal du samle oplysningerne igen på meningsfulde måder. Følgende formular indeholder f.eks. oplysninger fra forskellige tabeller.


Formularen Ordrer

Billedtekst 1 Oplysningerne i denne formular stammer fra tabellen Kunder...
Billedtekst 2 ...tabellen Medarbejdere...
Billedtekst 3 ...tabellen Ordrer...
Billedtekst 4 ...tabellen Produkter...
Billedtekst 5 ...og tabellen Ordredetaljer.

Access er et administrationssystem for relationsdatabaser. I en relationsdatabase skal du inddele oplysningerne i separate, emnebaserede tabeller. Du skal derefter bruge tabelrelationerne til at samle oplysningerne efter behov.

Tilbage til toppen Tilbage til toppen

Oprette en en-til-mange-relation

Se nærmere på dette eksempel: tabellerne Leverandører og Produkter i produktordredatabasen. En leverandør kan levere et hvilket som helst antal produkter. For enhver leverandør i tabellen Leverandører kan der være mange produkter 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 kolonnen Leverandør-id fra tabellen Leverandører i tabellen Produkter. Access kan derefter bruge leverandør-id-nummeret i tabellen Produkter til at finde den korrekte leverandør af hvert produkt.

Kolonnen Leverandør-id i tabellen Produkter kaldes en fremmed nøgle, som 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.

Liste over dataelementer i designprocessen

Du skal skabe grundlaget for sammenføjning af relaterede tabeller ved at oprette par af primære nøgler og fremmede nøgler. Hvis du er usikker på, hvilke tabeller der skal dele en fælles kolonne, kan du identificere en en-til-mange-relation for at sikre, at de to tabeller får en fælles kolonne.

Tilbage til toppen Tilbage til toppen

Oprette en mange-til-mange-relation

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 pr. produkt og mange produkter pr. ordre. Når du skal identificere en 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. Det er et problem, for hvad ville der ske, hvis du forsøgte at oprette relationen mellem de to tabeller ved at tilføje feltet Produkt-id i tabellen Ordrer. Hvis der skal være mere end ét produkt pr. ordre, skal der være mere end én post pr. ordre i tabellen Ordrer. Du vil komme til at gentage ordreoplysningerne for hver række, der relaterer til en enkelt ordre, så du får et ineffektivt design, der kan give unøjagtige data. Du får samme problem, hvis du placerer feltet Ordre-id i tabellen Produkter. Du ville få mere end én post i tabellen Produkter for hvert produkt. Hvordan løses problemet?

Du skal oprette en tredje tabel, der også kaldes en samlingstabel, der opdeler mange-til-mange-relationen i to en-til-mange-relationer. Du skal indsætte den primære nøgle fra hver af de to tabeller i den tredje tabel. Det medfører, at hver forekomst af relationen registreres i den tredje tabel.

En mange-til-mange-relation

Hver post i tabellen Ordredetaljer repræsenterer et linjeelement på en ordre. Tabellen Ordredetaljer har en primær nøgle, der består af to felter: de fremmede nøgler fra tabellen Ordrer og tabellen Produkter. Det er ikke nok at bruge feltet Ordre-id som primær nøgle i denne tabel, fordi en ordre kan have mange vareposter. Ordre-id'et er gentaget for hver varepost på en ordre, så feltet indeholder ingen entydige værdier. Det er heller ikke nok at bruge feltet Produkt-id, fordi et produkt kan forekomme på mange forskellige ordrer. Men tilsammen 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. De er i stedet indirekte relateret via tabellen Ordredetaljer. Mange-til-mange-relationen mellem ordrerne og produkterne 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 én varepost, men hver varepost er kun forbundet med én ordre.
  • Tabellen Produkter og tabellen Ordredetaljer har en en-til-mange-relation. Hvert produkt kan have mere end en varepost, men hver varepost refererer kun til ét produkt.

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

Når du har indarbejdet tabellen Ordredetaljer, kan listen over tabeller og felter f.eks. se sådan ud:

Liste over dataelementer i designprocessen

Tilbage til toppen Tilbage til toppen

Oprette en en-til-en-relation

En anden type relation er en-til-en-relationen. Lad os antage, at du skal registrere nogle supplerende produktoplysninger, der kun skal bruges i sjældne tilfælde eller kun gælder for nogle få produkter. Da du ikke skal bruge oplysningerne ofte, og fordi lagring af oplysningerne i tabellen Produkter ville medføre tom plads for alle produkter, der ikke skal have disse oplysninger, skal du placere dem i en separat tabel. Ligesom tabellen Produkter kan du også bruge produkt-id'et som primær nøgle. Relationen mellem denne supplerende tabel og produkttabellen er en en-til-en-relation. For hver post i produkttabellen findes kun én post i den supplerende tabel. Når du har en sådan relation, skal de to tabeller dele et fælles felt.

Når du opdager behovet for en en-til-en-relation i databasen, skal du overveje, om du kan placere oplysningerne fra de to tabeller i én tabel. Hvis du af en eller anden grund ikke ønsker at gøre det, måske fordi det ville give en masse tom plads, kan du på nedenstående liste se, hvordan du kan medtage relationen i designet:

  • Hvis de to tabeller har samme emne, kan du sikkert oprette relationen ved at bruge 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 den ene eller anden af tabellerne og indsætte dens primære nøgle som en fremmed nøgle i den anden tabel.

Hvis du fastlægger relationerne mellem tabeller, kan du bedre sikre dig, at du har de rette tabeller og kolonner. Når der findes en en-til-en- eller en-til-mange-relation, skal tabellerne have en eller flere fælles kolonner. Når der findes en mange-til-mange-relation, skal du bruge en tredje tabel til at repræsentere relationen.

Tilbage til toppen Tilbage til toppen

Optimere designet

Når du har de tabeller, felter og relationer, du skal bruge, bør du oprette og udfylde tabellerne med eksempeldata og arbejde med oplysningerne ved at oprette forespørgsler, tilføje nye poster osv. Det gør det nemmere at opdage eventuelle problemer: Du skal måske tilføje en kolonne, du har glemt at indsætte i designfasen, eller du har måske en tabel, der skal inddeles i to tabeller for at undgå dubletter.

Find ud af, om databasen kan give de ønskede svar. Opret råskitser af formularer og rapporter, og se, om de viser de forventede data. Undersøg, om der er unødige dubletter af data, og rediger designet for at eliminere dem.

Når du afprøver databasen, vil du sikkert opdage, at der er plads til forbedringer. Du skal f.eks. kontrollere følgende:

  • Har du glemt nogle kolonner? Hvis det er tilfældet, findes oplysningerne så i eksisterende tabeller? Hvis det er oplysninger om noget andet, skal du måske oprette en ny tabel. Opret en kolonne for hvert dataelement, du skal registrere. Hvis elementet ikke kan beregnes ud fra andre kolonner, skal du sikkert bruge en ny kolonne til det.
  • Er der overflødige kolonner, fordi de kan beregnes ud fra eksisterende felter? Hvis et dataelement kan beregnes ud fra eksisterende kolonner, f.eks. beregning af rabatpris ud fra udsalgspris, er det normalt den bedste løsning, så du ikke skal oprette nye kolonner.
  • Indtaster du gentagne gange dubletdata i en tabel? Hvis det er tilfældet, skal du sikkert inddele 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? I så fald bør du ændre tabellens design, så den har færre felter og flere poster.
  • Er hver oplysning inddelt i de mindste brugbare dele? Hvis du skal rapportere, sortere, søge efter eller beregne et dataelement, skal du placere det i en kolonne for sig.
  • Indeholder hver kolonne et faktum om tabellens emne? Hvis en kolonne ikke indeholder oplysninger vedrørende tabellens emne, hører den hjemme i en anden tabel.
  • Er alle relationer mellem tabeller repræsenteret via fælles felter eller 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.

Finjustere tabellen Produkter

Lad os antage, at hvert produkt i produktsalgsdatabasen tilhører en generel kategori som f.eks. drikkevarer, grøntsager eller fisk. Produkttabellen kan indeholde et felt, der viser kategorien for hvert produkt.

Lad os desuden antage, at du kontrollerer og finjusterer databasens design og beslutter dig for at gemme en beskrivelse af kategorien sammen med dens navn. Hvis du tilføjer feltet Kategoribeskrivelse i tabellen Produkter, skal du gentage hver kategoribeskrivelse for hvert produkt i kategorien – det er en dårlig løsning.

Det er bedre at gøre kategorier til et nyt emne i databasen med egen tabel og egen primær nøgle. Du kan derefter føje den primære nøgle fra tabellen Kategorier til tabellen Produkter som en fremmed nøgle.

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

Når du gennemgår tabelstrukturer, skal du være opmærksom på, om grupper gentages. Du kan f.eks. have en tabel med følgende kolonner:

  • Produkt-id
  • Navn
  • Produkt-id1
  • Navn1
  • Produkt-id2
  • Navn2
  • Produkt-id3
  • Navn3

Her er hvert produkt en gentaget gruppe af kolonner, der kun er forskellige fra hinanden pga. nummeret i slutningen af kolonnenavnet. Når kolonner er nummereret på denne måde, bør du revidere designet.

Et sådant design har flere fejl. For det første tvinger det dig til at angive en øvre grænse for antallet af produkter. Når grænsen er overskredet, skal du tilføje en ny kolonnegruppe i tabelstrukturen, hvilket er en større administrativ opgave.

Et andet problem er, at de leverandører, der har færre produkter end det maksimale antal, medfører spild af plads, fordi de overskydende kolonner vil være tomme. Den største fejl ved et sådant design er, at det bliver svært at udføre en række opgaver som f.eks. sortering og indeksering af tabellen efter produktets id eller navn.

Når grupper gentages, skal du nøje gennemgå designet med henblik på at inddele tabellen i to. I ovenstående eksempel er det bedre at bruge to tabeller: en til leverandørerne og en til produkterne med en sammenkædning via leverandør-id.

Tilbage til toppen Tilbage til toppen

Anvende normaliseringsregler

Du kan anvende datanormaliseringsregler som det næste trin i designet. Du skal anvende disse regler for at finde ud af, om tabellerne har den korrekte struktur. Anvendelsen af regler på databasedesignet kaldes normalisering af databasen, eller bare normalisering.

Normalisering er især nyttigt, hvis du har indsat alle oplysningerne i et foreløbigt design. Du skal sikre dig, at du har fordelt oplysningerne på de nødvendige tabeller. Normalisering kan ikke sørge for, at du har alle de rigtige dataelementer fra starten af.

Du skal anvende reglerne i rækkefølge, og for hvert trin skal du sørge for, at designet får såkaldte "normalformer". Det er almindeligt med fem normalformer: første til femte normalform. I denne artikel beskrives de tre første, fordi de er alt, hvad du skal bruge i de fleste databasedesign.

Første normalform

Første normalform angiver, at hvert skæringspunkt mellem en række og kolonne i tabellen har en enkelt værdi, aldrig en liste over værdier. Du kan f.eks. ikke have et felt med navnet Pris, hvor du kan placere mere end én pris. Hvert skæringspunkt mellem en række og kolonne er en celle, og hver celle kan kun indeholde én værdi.

Anden normalform

Anden normalform kræver, at hver kolonne, der ikke er en nøgle, er helt afhængig af den fulde primære nøgle, ikke kun dele af nøglen. Denne regel anvendes, når du har en primær nøgle, der består af mere end én kolonne. Du kan f.eks. have en tabel med 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 er en overtrædelse af den anden normalform, fordi 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 skal tilhøre en anden tabel (Produkter).

Tredje normalform

Tredje normalform kræver ikke alene, at alle kolonner, der ikke er en nøgle, er afhængig af hele den primære nøgle, men også at kolonner, der ikke er nøgler, er uafhængige af hinanden.

Sagt på en anden måde skal hver kolonne, der ikke er en nøgle, være afhængig af den primære nøgle, men kun den primære nøgle. Du kan f.eks. have en tabel med følgende kolonner:

  • Produkt-id (primær nøgle)
  • Navn
  • Vejledende pris
  • Rabat

Lad os antage, at rabatten afhænger af den vejledende pris. Denne tabel overtræder den tredje normalform, fordi en ikke-nøglekolonne, Rabat, afhænger af en anden ikke-nøglekolonne, Vejledende pris. Kolonneuafhængighed betyder, at du skulle kunne ændre enhver ikke-nøglekolonne uden at påvirke en anden kolonne. Hvis du ændrer en værdi i feltet Vejledende pris, ændres rabatten tilsvarende, hvilket er et regelbrud. I så fald skal rabatten flyttes til en anden tabel, der ikke er nøgleafhængig af Vejledende pris.

Tilbage til toppen Tilbage til toppen

 
 
Gælder for:
Access 2010