We couldn’t sign you in
Select the account you want to use.
Grunnleggende om databaseutforming

En riktig utformet database gir deg tilgang til oppdatert, nøyaktig informasjon. Fordi en riktig utforming er avgjørende for å oppnå målene dine i arbeid med en database, er det fornuftig å investere tiden det tar å lære prinsippene om god utforming. Det er mye mer sannsynlig at du ender opp med en database som oppfyller behovene dine, og som enkelt kan tilpasse endringer.

Denne artikkelen inneholder retningslinjer for planlegging av en skrivebordsdatabase. Du lærer hvordan du avgjør hvilken informasjon du trenger, hvordan du deler denne informasjonen inn i riktige tabeller og kolonner og hvordan disse tabellene er relatert til hverandre. Du bør lese denne artikkelen før du oppretter den første skrivebordsdatabasen.

Viktig!:  Access gir utformingsopplevelser som lar deg opprette databaseprogrammer for nettet. Mange utformingshensyn er forskjellige når du utformer for nettet. Denne artikkelen tar ikke for seg utforming av webdatabaseprogram. Hvis du vil ha mer informasjon, kan du se artikkelen Bygge en database som skal deles på nettet.

I denne artikkelen


Noen databasevilkår du må vite

Access organiserer informasjonen i tabeller:lister med rader og kolonner som ligner på regnskapsførerens tastatur eller regneark. I en enkel database kan det hende at du bare har én tabell. For de fleste databaser trenger du mer enn én. Du kan for eksempel ha en tabell som lagrer informasjon om produkter, en annen tabell som lagrer informasjon om ordrer, og en annen tabell med informasjon om kunder.

Bilde som viser tre tabeller i dataark

Hver rad kalles en post mer riktig,og hver kolonne, et felt. En oppføring er en meningsfull og konsekvent måte å kombinere informasjon om noe på. Et felt er et enkelt informasjonselement – en elementtype som vises i hver post. I for eksempel Produkter-tabellen vil hver rad eller post inneholde informasjon om ett produkt. Hver kolonne, eller hvert felt, inneholder en type informasjon om produktet, for eksempel navn eller pris.

Til toppen av siden

Hva er god databaseutforming?

Visse prinsipper leder prosessen for databaseutforming. Det første prinsippet er at duplisert informasjon (også kalt overflødige data) er dårlig, fordi det tar opp plass og øker sannsynligheten for feil og inkonsekvenser. Det andre prinsippet er at riktigheten og fullstendigheten av informasjonen er viktig. Hvis databasen inneholder feil informasjon, vil eventuelle rapporter som henter informasjon fra databasen, også inneholde uriktige opplysninger. Dermed blir eventuelle beslutninger du tar basert på disse rapportene, feilinformert.

En god databaseutforming er derfor følgende:

  • Deler informasjonen inn i emnebaserte tabeller for å redusere overflødige data.

  • Gir Access informasjonen som kreves for å koble informasjonen i tabellene sammen etter behov.

  • Bidrar til å støtte og sikre nøyaktigheten og integriteten til informasjonen.

  • Dekker behovene dine for databehandling og rapportering.

Til toppen av siden

Utformingsprosessen

Utformingsprosessen består av følgende trinn:

  • Bestem formålet med databasen    

    Dette bidrar til å klargjøre resten av trinnene.

  • Finn og organiser den nødvendige informasjonen     

    Samle inn alle typer informasjon du kanskje vil registrere i databasen, for eksempel produktnavn og ordrenummer.

  • Dele informasjonen inn i tabeller    

    Del informasjonselementene inn i hovedenheter eller emner, for eksempel Produkter eller Ordrer. Hvert emne blir deretter en tabell.

  • Gjøre informasjonselementer om til kolonner    

    Bestem hvilken informasjon du vil lagre i hver tabell. Hvert element blir et felt og vises som en kolonne i tabellen. En Ansatte-tabell kan for eksempel inneholde felt som etternavn og ansettelsesdato.

  • Angi primærnøkler    

    Velg primærnøkkelen for hver tabell. Primærnøkkelen er en kolonne som brukes til å identifisere hver rad unikt. Et eksempel kan være Produkt-ID eller ordre-ID.

  • Konfigurere tabellrelasjonene    

    Se på hver tabell, og bestem hvordan dataene i én tabell er relatert til dataene i andre tabeller. Legg til felt i tabeller, eller opprett nye tabeller for å tydeliggjøre relasjonene etter behov.

  • Finjustere utformingen    

    Analyser utformingen for feil. Opprett tabellene og legg til noen poster med eksempeldata. Se om du kan få resultatene du ønsker fra tabellene. Foreta justeringer av utformingen etter behov.

  • Bruke normaliseringsreglene    

    Bruk reglene for data normalisering for å se om tabellene er riktig strukturert. Foreta justeringer i tabellene etter behov.

Til toppen av siden

Fastslå formålet med databasen

Det er lurt å skrive ned formålet med databasen på papir – formålet med den, hvordan du forventer å bruke den, og hvem som skal bruke den. Når det gjelder en liten database for en hjemmebasert bedrift, kan du for eksempel skrive noe enkelt, for eksempel «Kundedatabasen inneholder en liste over kundeinformasjon med det formål å produsere masseutsendelser og rapporter». Hvis databasen er mer kompleks eller brukes av mange personer, kan formålet enkelt være et avsnitt eller mer, og bør inkludere når og hvordan hver enkelt person skal bruke databasen. Idéen er å ha en godt utviklet målsetning som kan refereres til gjennom hele utformingsprosessen. En slik erklæring hjelper deg med å fokusere på målene når du tar beslutninger.

Til toppen av siden

Finne og organisere den nødvendige informasjonen

Hvis du vil finne og organisere informasjonen som kreves, begynner du med den eksisterende informasjonen. Du kan for eksempel registrere kjøpsordrer i en bok eller ha kundeinformasjon på papirskjemaer i et arkivskap. Samle inn disse dokumentene, og vis hver type informasjon som vises (for eksempel hver boks du fyller ut i et skjema). Hvis du ikke har eksisterende skjemaer, kan du i stedet tenke deg at du må utforme et skjema for å registrere kundeinformasjon. Hvilken informasjon ville du lagt til i skjemaet? Hvilke utfyllingsbokser ville du opprettet? Identifiser og før opp hvert av disse elementene. Anta for eksempel at du for øyeblikket beholder kundelisten på indekskort. Når du undersøker disse kortene, kan det hende at hvert kort inneholder et kundenavn, adresse, poststed, delstat, postnummer og telefonnummer. Hvert av disse elementene representerer en potensiell kolonne i en tabell.

Når du forbereder denne listen, trenger du ikke å bekymre deg for å få den perfekt til å komme i gang. Vis i stedet hvert element i tankene. Hvis noen andre skal bruke databasen, kan du også be dem dele sine ideer. Du kan finjustere listen senere.

Deretter bør du vurdere hvilke typer rapporter eller masseutsendelser du kanskje vil produsere fra databasen. Du vil for eksempel at en produktsalgsrapport skal vise salg etter område, eller en sammendragsrapport for beholdningen som viser varelagernivåer. Du kan også generere standardbrev som skal sendes til kunder som annonserer et salgsarrangement eller tilbyr en premium. Utform rapporten i tankene dine, og tenk hvordan den vil se ut. Hvilken informasjon ville du ha plasser i rapporten? Før opp hvert element. Gjør det samme for standardbrevet og for alle andre rapporter du forventer å opprette.

En person som ser for seg en varelagerrapport

Hvis du tenker på rapporter og masseutsendelser som du kanskje vil opprette, kan du lettere identifisere elementer du trenger i databasen. Anta for eksempel at du gir kundene muligheten til å melde seg på (eller av) periodiske oppdateringer via e-post, og at du vil skrive ut en liste over de som har meldt seg på. Hvis du vil registrere denne informasjonen, legger du til en «Send e-post»-kolonne i kundetabellen. For hver kunde kan du angi feltet til Ja eller Nei.

Kravet om å sende e-postmeldinger til kunder foreslår et annet element som skal registreres. Når du vet at en kunde ønsker å motta e-postmeldinger, må du også vite e-postadressen som kunden skal sende til. Derfor må du registrere en e-postadresse for hver kunde.

Det er fornuftig å lage en prototype av hver rapport eller utdataoppføring, og tenke over hvilke elementer du trenger for å produsere rapporten. Når du for eksempel undersøker en standardbrev, er det et par ting du må huske på. Hvis du vil inkludere en riktig hilsen, for eksempel "Hr.", "Mrs." eller "Ms." streng som starter en hilsen, må du opprette et hilsningselement. Det kan også hende at du vanligvis starter en bokstav med «Kjære Hr. Smith» i stedet for «Kjære. Mr. Sylvester Smith". Dette foreslår at du vanligvis vil lagre etternavnet atskilt fra fornavnet.

Et viktig punkt du må huske på, er at du bør dele hver bit av informasjon opp i de minste delene som gir mening. Hvis du vil gjøre etternavnet lett tilgjengelig, deler du navnet opp i to deler: Fornavn og Etternavn. Hvis du for eksempel vil sortere en rapport etter etternavn, hjelper det å ha kundens etternavn lagret separat. Hvis du vil sortere, søke, beregne eller rapportere basert på et element med informasjon, bør du generelt plassere elementet i et eget felt.

Tenk på spørsmålene du kanskje vil at databasen skal besvare. Hvor mange salg av det aktuelle produktet avsluttet du forrige måned? Hvor bor dine beste kunder? Hvem er leverandøren for ditt bestselgende produkt? Hvis du forventer disse spørsmålene, hjelper det deg med å holde oversikt over flere elementer du kan spille inn.

Når du har innhentet denne informasjonen, er du klar for neste trinn.

Til toppen av siden

Dele informasjonen inn i tabeller

Hvis du vil dele informasjonen inn i tabeller, velger du hovedenhetene eller emnene. Når du for eksempel har funnet og organisert informasjon for en produktsalgsdatabase, kan den foreløpige listen se slik ut:

Håndskrevne informasjonselementer gruppert i emner

De viktigste enhetene som vises her, er produktene, leverandørene, kundene og ordrene. Derfor er det fornuftig å begynne med disse fire tabellene: én for fakta om produkter, én for fakta om leverandører, én for fakta om kunder, og én for fakta om ordrer. Selv om dette ikke fullfører listen, er det et godt utgangspunkt. Du kan fortsette å finjustere denne listen til du har en utforming som fungerer bra.

Når du ser gjennom den foreløpige listen over elementer, kan det hende du blir fristet til å plassere alle elementene i én enkelt tabell i stedet for de fire som vises i forrige illustrasjon. Her får du vite hvorfor det er en dårlig idé. Vurder et øyeblikk, tabellen som vises her:

Bilde som viser en tabell som inneholder både varer og leverandører

I dette tilfellet inneholder hver rad informasjon om både produktet og tilhørende leverandør. Fordi du kan ha mange produkter fra samme leverandør, må leverandørens navn og adresse gjentas mange ganger. Dette opptar unødig diskplass. Det å registrere leverandørinformasjon bare én gang i en separat leverandørtabell og deretter koble denne tabellen til Produkter-tabellen, er en mye bedre løsning.

Et annet problem med denne utformingen oppstår når du må endre informasjon om leverandøren. Anta for eksempel at du må endre adresse for en leverandør. Fordi adressen vises mange steder, kan det hende du ved et uhell endrer den på ett sted, men glemmer å endre den på de andre. Hvis du registrerer leverandørens adresse bare ett sted, løses problemet.

Når du utformer databasen, bør du alltid prøve å registrere hvert faktum bare én gang. Hvis du gjentar den samme informasjonen på mer enn ett sted, for eksempel adressen til en bestemt leverandør, plasserer du denne informasjonen i en egen tabell.

La oss til slutt anta at det bare er ett produkt som leveres av Coho Winery, og at du vil slette produktet, men beholde leverandørnavn og adresseinformasjon. Hvordan kan du slette produktposten uten også å miste leverandørinformasjon? Det går ikke. Fordi hver post inneholder fakta om et produkt, i tillegg til fakta om en leverandør, kan du ikke slette én post uten å slette den andre. Hvis du vil holde disse faktaene atskilt, må du dele én tabell i to: én tabell for produktinformasjon og en annen tabell for leverandørinformasjon. Hvis du sletter en produktpost, bør du bare slette fakta om produktet, ikke fakta om leverandøren.

Når du har valgt emnet som representeres av en tabell, bør kolonnene i denne tabellen bare lagre fakta om emnet. Produkttabellen bør for eksempel bare lagre fakta om produkter. Fordi leverandøradressen er et faktum om leverandøren, og ikke et faktum om produktet, tilhører den i leverandørtabellen.

Til toppen av siden

Gjøre informasjonselementer om til kolonner

Hvis du vil finne kolonnene i en tabell, må du bestemme hvilken informasjon du vil spore om emnet som er registrert i tabellen. For eksempel vil kundetabellen, Navn, Adresse, Poststed, Send e-post, Hilsning og E-postadresse utgjør en god startliste over kolonner. Hver post i tabellen inneholder samme sett med kolonner, slik at du kan lagre informasjon om navn, adresse, poststed, poststed, send e-post, hilsen og e-postadresse for hver post. Adressekolonnen inneholder for eksempel kundenes adresser. Hver oppføring inneholder data om én kunde, og adressefeltet inneholder adressen for denne kunden.

Når du har bestemt det første settet med kolonner for hver tabell, kan du finjustere kolonnene ytterligere. Det er for eksempel fornuftig å lagre kundenavnet som to separate kolonner: fornavn og etternavn, slik at du kan sortere, søke og indeksere på bare disse kolonnene. På samme måte består adressen faktisk av fem separate komponenter, adresse, poststed, delstat, postnummer og land/område, og det er også fornuftig å lagre dem i separate kolonner. Hvis du for eksempel vil utføre en søke-, filter- eller sorteringsoperasjon etter status, trenger du at informasjon om tilstanden er lagret i en egen kolonne.

Du bør også vurdere om databasen skal inneholde informasjon som bare er av innenlands eller utenlands. Hvis du for eksempel har tenkt å lagre internasjonale adresser, er det bedre å ha en områdekolonne i stedet for Delstat, fordi en slik kolonne kan inneholde både innenlands delstater og områder i andre land/regioner. På samme måte gir postnummer mer fornuftig enn postnummer hvis du skal lagre internasjonale adresser.

Listen nedenfor viser noen tips for hvordan du kan fastslå kolonnene.

  • Ikke inkluder beregnede data    

    I de fleste tilfeller bør du ikke lagre resultatet av beregninger i tabeller. I stedet kan du få Access til å utføre beregningene når du vil se resultatet. Anta for eksempel at det finnes en ordrerapport for produkter som viser delsummen av enheter i rekkefølge for hver produktkategori i databasen. Det er imidlertid ingen delsumkolonne for enheter i rekkefølge i noen tabell. Produkter-tabellen inneholder i stedet en kolonne for ordreenheter som lagrer enhetene i bestillingen for hvert produkt. Med disse dataene beregnes delsummen hver gang du skriver ut rapporten. Selve delsummen skal ikke lagres i en tabell.

  • Lagre informasjon i de minste logiske delene    

    Du kan bli fristet til å ha ett enkelt felt for fullstendige navn, eller for produktnavn sammen med produktbeskrivelser. Hvis du kombinerer mer enn én type informasjon i et felt, er det vanskelig å hente individuelle fakta senere. Prøv å dele opp informasjon i logiske deler. Du kan for eksempel opprette separate felter for fornavn og etternavn, eller for produktnavn, kategori og beskrivelse.

Bilde som viser informasjonselementer under utformingsprosessen

Når du har finjustert datakolonnene i hver tabell, er du klar til å velge primærnøkkelen for hver tabell.

Til toppen av siden

Angi primærnøkler

Hver tabell må inneholde en kolonne eller et sett med kolonner som identifiserer hver rad som er lagret i tabellen på en unik måte. Dette er ofte et unikt identifikasjonsnummer, for eksempel en ansatt-ID eller et serienummer. I databaseterminologien kalles denne informasjonen primærnøkkelen for tabellen. I Access brukes primærnøkkelfelt til raskt å knytte sammen data fra flere tabeller og til å samle dataene sammen for deg.

Hvis du allerede har en unik identifikator for en tabell, for eksempel et produktnummer som identifiserer hvert produkt i katalogen unikt, kan du bruke denne identifikatoren som tabellens primærnøkkel, men bare hvis verdiene i denne kolonnen alltid er forskjellige for hver post. Du kan ikke ha dupliserte verdier i en primærnøkkel. Du bør for eksempel ikke bruke navn på personer som primærnøkkel, fordi navn ikke er unike. Du kan enkelt ha to personer med samme navn i samme tabell.

En primærnøkkel må alltid ha en verdi. Hvis verdien i en kolonne kan bli ikke-tilordnet eller ukjent (en manglende verdi) på et tidspunkt, kan den ikke brukes som en komponent i en primærnøkkel.

Du bør alltid velge en primærnøkkel som har en verdi som ikke endres. I en database som bruker mer enn én tabell, kan primærnøkkelen for en tabell brukes som en referanse i andre tabeller. Hvis primærnøkkelen endres, må endringen også brukes overalt der det refereres til nøkkelen. Hvis du bruker en primærnøkkel som ikke endres, reduseres sjansen for at primærnøkkelen kan bli ikke synkronisert med andre tabeller som refererer til den.

Et vilkårlig unikt tall brukes ofte som primærnøkkel. Du kan for eksempel tilordne hver ordre et unikt ordrenummer. Det eneste formålet med bestillingsnummeret er å identifisere en bestilling. Når den er tilordnet, endres den aldri.

Hvis du ikke har i tankene en kolonne eller et sett med kolonner som kan utgjøre en god primærnøkkel, kan du vurdere å bruke en kolonne som har datatypen Autonummer. Når du bruker datatypen Autonummer, tilordnes det automatisk en verdi for deg i Access. En slik identifikator er faktafri. den inneholder ingen faktiske opplysninger som beskriver raden den representerer. Fakta-identifikatorer er ideelle for bruk som primærnøkkel fordi de ikke endres. Det er mer sannsynlig at en primærnøkkel som inneholder fakta om en rad, for eksempel et telefonnummer eller et kundenavn, endres, fordi selve faktiske informasjonen kan endres.

Bilde som viser varetabell med primærnøkkelfelt.

1. En kolonne som er angitt til datatypen Autonummer, er ofte en god primærnøkkel. Ingen produkt-IDer er like.

I noen tilfeller vil du kanskje bruke to eller flere felt som, sammen, oppgir primærnøkkelen for en tabell. En Ordredetaljer-tabell som lagrer linjeelementer for ordrer, vil for eksempel bruke to kolonner i primærnøkkelen: Ordre-ID og Produkt-ID. Når en primærnøkkel bruker mer enn én kolonne, kalles den også en sammensatt nøkkel.

For produktsalgsdatabasen kan du opprette en Autonummer-kolonne for hver av tabellene som skal fungere som primærnøkkel: ProduktID for Produkter-tabellen, OrdreID for Ordrer-tabellen, KundeID for Kunder-tabellen og Leverandør-ID for Leverandører-tabellen.

Bilde som viser informasjonselementer under utformingsprosessen


Til toppen av siden

Opprette tabellrelasjonene

Nå som du har delt informasjonen inn i tabeller, trenger du en måte å samle informasjonen på nytt på meningsfulle måter. Skjemaet nedenfor inneholder for eksempel informasjon fra flere tabeller.

Ordreskjemaet

1. Informasjonen i dette skjemaet kommer fra Kunder-tabellen ...

2. ... Ansatte-tabellen ...

3. ... Ordretabellen ...

4. ... Produkter-tabellen ...

5. ... og Ordredetaljer-tabellen.

Access er et system for databasebehandling for relasjonsdatabaser. I en relasjonsdatabase deler du informasjonen inn i separate emnebaserte tabeller. Deretter bruker du tabellrelasjoner til å samle informasjonen etter behov.

Til toppen av siden

Opprette en én-til-mange-relasjon

Vurder dette eksemplet: Tabellene Leverandører og Produkter i databasen for produktordrer. En leverandør kan levere et hvilket som helst antall produkter. Den gjør at for alle leverandører som er representert i Leverandører-tabellen, kan det være mange produkter representert i Produkter-tabellen. Relasjonen mellom tabellen Leverandører og varetabellen er derfor en én-til-mange-relasjon.

Én-til-mange begrepsmessig

Hvis du vil representere en én-til-mange-relasjon i databaseutformingen, tar du primærnøkkelen på «én»-siden av relasjonen og legger den til som en ekstra kolonne eller kolonner i tabellen på «mange»-siden i relasjonen. I dette tilfellet legger du for eksempel til kolonnen Leverandør-ID fra leverandører-tabellen i Produkter-tabellen. Access kan deretter bruke leverandør-ID-nummeret i produkter-tabellen til å finne riktig leverandør for hvert produkt.

Kolonnen Leverandør-ID i Produkter-tabellen kalles en sekundærnøkkel. En sekundærnøkkel er primærnøkkelen for en annen tabell. Kolonnen Leverandør-ID i produkter-tabellen er en sekundærnøkkel fordi den også er primærnøkkelen i Leverandører-tabellen.

Bilde som viser informasjonselementer under utformingsprosessen

Du danner grunnlaget for sammenføyning av relaterte tabeller ved å etablere paringer av primærnøkler og sekundærnøkler. Hvis du ikke er sikker på hvilke tabeller som skal dele en felles kolonne, sikrer identifisering av en én-til-mange-relasjon at de to tabellene involvert faktisk krever en delt kolonne.

Til toppen av siden

Opprette en mange-til-mange-relasjon

Vurder relasjonen mellom Produkter-tabellen og Ordre-tabellen.

Én enkelt ordre kan inkludere mer enn én vare. På den andre siden kan én enkelt vare vises i mange ordrer. For hver post i ordretabellen kan det derfor være mange poster i varetabellen. Og for hver post i Produkter-tabellen kan det være mange poster i Ordre-tabellen. Denne relasjonstypen kalles en mange-til-mange-relasjon fordi det for ethvert produkt kan være mange ordrer. og det kan være mange produkter for en hvilken som helst ordre. Vær oppmerksom på at når du skal gjenkjenne mange-til-mange-relasjoner mellom tabellene, er det viktig at du tar hensyn til begge sidene av relasjonen.

Emnene for de to tabellene – ordrer og produkter – har en mange-til-mange-relasjon. Dette gir et problem. For å forstå problemet kan du tenke deg hva som ville skje hvis du prøvde å opprette relasjonen mellom de to tabellene ved å legge til Produkt-ID-feltet i Ordre-tabellen. Hvis du vil ha mer enn ett produkt per ordre, trenger du mer enn én post i Ordre-tabellen per ordre. Du vil gjenta ordreinformasjonen for hver rad som er knyttet til én enkelt rekkefølge, noe som resulterer i en ineffektiv utforming som kan føre til unøyaktige data. Det samme problemet oppstår hvis du plasserer feltet Ordre-ID i Produkter-tabellen – du har mer enn én post i Produkter-tabellen for hvert produkt. Hvordan løser du dette problemet?

Svaret er å opprette en tredje tabell, ofte kalt en foreningstabell, som bryter sammen mange-til-mange-relasjonen i to én-til-mange-relasjoner. Du setter inn primærnøkkelen fra hver av de to tabellene i den tredje tabellen. Den tredje tabellen registrerer dermed hver forekomst av relasjonen.

Mange-til-mange-relasjoner

Hver post i Ordredetaljer-tabellen representerer ett linjeelement i en ordre. Primærnøkkelen for Ordredetaljer-tabellen består av to felt – sekundærnøklene fra Ordrer- og Produkter-tabellene. Bruk av ordre-ID-feltet fungerer ikke som primærnøkkelen for denne tabellen, fordi én ordre kan ha mange linjeelementer. Ordre-ID-en gjentas for hvert linjeelement i en ordre, så feltet inneholder ikke unike verdier. Bruk av produkt-ID-feltet fungerer heller ikke heller, fordi ett produkt kan vises i mange forskjellige ordrer. Men sammen gir de to feltene alltid en unik verdi for hver post.

I produktsalgsdatabasen er ikke Ordre-tabellen og Produkter-tabellen direkte relatert til hverandre. I stedet relateres de indirekte via Ordredetaljer-tabellen. Mange-til-mange-relasjonen mellom ordrer og produkter representeres i databasen ved hjelp av to én-til-mange-relasjoner:

  • Ordretabellen og Ordredetaljer-tabellen har en én-til-mange-relasjon. Hver ordre kan ha mer enn én linjeelement, men hvert linjeelement er koblet til bare én ordre.

  • Produkter-tabellen og Ordredetaljer-tabellen har en én-til-mange-relasjon. Hvert produkt kan ha mange linjeelementer tilknyttet, men hvert linjeelement refererer til bare ett produkt.

Fra Ordredetaljer-tabellen kan du bestemme alle produktene i en bestemt ordre. Du kan også fastslå alle ordrene for et bestemt produkt.

Etter at du har innlemmet Ordredetaljer-tabellen, kan listen over tabeller og felt se omtrent slik ut:

Bilde som viser informasjonselementer under utformingsprosessen


Til toppen av siden

Opprette en én-til-én-relasjon

En annen relasjonstype er én-til-én-relasjonen. Anta for eksempel at du trenger å registrere spesiell tilleggsinformasjon om produkter som du trenger sjelden eller som bare gjelder for noen få produkter. Fordi du ikke trenger informasjonen ofte, og fordi lagring av informasjonen i Produkter-tabellen fører til tom plass for hvert produkt den ikke gjelder for, plasserer du den i en egen tabell. I likhet med Produkter-tabellen bruker du ProduktID som primærnøkkel. Relasjonen mellom denne ekstra tabellen og Produkt-tabellen er en én-til-én-relasjon. Det finnes én samsvarende post i tilleggstabellen for hver post i Produkt-tabellen. Når du identifiserer en slik relasjon, må begge tabellene dele et fellesfelt.

Når du oppdager behovet for en én-til-én-relasjon i databasen, bør du vurdere om du kan sette informasjonen fra de to tabellene sammen i én tabell. Hvis du av en eller annen grunn ikke vil gjøre dette, for eksempel fordi det vil føre til mye tomme mellomrom, viser listen nedenfor hvordan du vil representere relasjonen i utformingen:

  • Hvis de to tabellene har samme emne, kan du sannsynligvis konfigurere relasjonen ved å bruke den samme primærnøkkelen i begge tabellene.

  • Hvis de to tabellene har forskjellige emner med forskjellige primærnøkler, velger du én av tabellene (én av dem) og setter inn primærnøkkelen i den andre tabellen som en sekundærnøkkel.

Ved å fastslå relasjonene mellom tabeller sikrer du at du har riktige tabeller og kolonner. Når det finnes en én-til-én- eller én-til-mange-relasjon, må de involverte tabellene dele en felles kolonne eller kolonner. Når det finnes en mange-til-mange-relasjon, er det nødvendig med en tredje tabell for å representere relasjonen.

Til toppen av siden

Begrense utformingen

Når du har tabellene, feltene og relasjonene du trenger, bør du opprette og fylle ut tabellene med eksempeldata, og prøve å arbeide med informasjonen: opprette spørringer, legge til nye poster og så videre. Dette bidrar til å fremheve potensielle problemer – du må for eksempel kanskje legge til en kolonne som du glemte å sette inn under utformingsfasen, eller du kan ha en tabell som du bør dele inn i to tabeller for å fjerne duplisering.

Se om du kan bruke databasen til å få svarene du ønsker. Opprett utkast av skjemaer og rapporter, og se om de viser dataene du forventer. Se etter unødvendig kopiering av data og, når du finner noen, kan du endre utformingen for å eliminere den.

Når du prøver ut den første databasen, vil du sannsynligvis oppdage rom for forbedring. Her er noen ting du kan sjekke:

  • Har du glemt noen kolonner? Hvis det er det, tilhører informasjonen i de eksisterende tabellene? Hvis det er informasjon om noe annet, må du kanskje opprette en annen tabell. Opprett en kolonne for hvert informasjonselement du må spore. Hvis informasjonen ikke kan beregnes fra andre kolonner, trenger du sannsynligvis en ny kolonne for den.

  • Er noen kolonner unødvendige fordi de kan beregnes fra eksisterende felt? Hvis et informasjonselement kan beregnes fra andre eksisterende kolonner – for eksempel en rabattert pris beregnet fra utsalgsprisen – er det vanligvis bedre å gjøre nettopp dette, og unngå å opprette en ny kolonne.

  • Skriver du inn duplisert informasjon gjentatte ganger i en av tabellene? Hvis dette er gjort, må du sannsynligvis dele tabellen inn i to tabeller som har en én-til-mange-relasjon.

  • Har du tabeller med mange felt, et begrenset antall poster og mange tomme felt i individuelle poster? Hvis det er det, bør du tenke over hvordan du omformer tabellen slik at den har færre felt og flere poster.

  • Har hvert informasjonselement blitt delt inn i de minste nyttige delene? Hvis du har behov for å rapportere, sortere, søke etter eller beregne et element med informasjon, kan du plassere elementet i en egen kolonne.

  • Inneholder hver kolonne et faktum om emnet for tabellen? Hvis en kolonne ikke inneholder informasjon om emnet for tabellen, tilhører den en annen tabell.

  • Representeres alle relasjoner mellom tabeller, enten av fellesfelt eller en tredje tabell? Én-til-én- og én-til-mange-relasjoner krever felles kolonner. Mange-til-mange-relasjoner krever en tredje tabell.

Begrense Produkter-tabellen

Anta at hvert produkt i produktsalgsdatabasen faller under en generell kategori, for eksempel drikkevarer, condiments eller kjøtt. Produkter-tabellen kan inneholde et felt som viser kategorien for hvert produkt.

La oss si at etter å ha undersøkt og definert utformingen av databasen, bestemmer du deg for å lagre en beskrivelse av kategorien sammen med navnet på den. Hvis du legger til et felt for kategoribeskrivelse i Produkter-tabellen, må du gjenta hver kategoribeskrivelse for hvert produkt som faller under kategorien – dette er ikke en god løsning.

En bedre løsning er å gjøre Kategorier til et nytt emne som databasen kan spore, med en egen tabell og sin egen primærnøkkel. Du kan deretter legge til primærnøkkelen fra Kategorier-tabellen i Produkter-tabellen som en sekundærnøkkel.

Tabellene Kategorier og Produkter har en én-til-mange-relasjon: en kategori kan inneholde mer enn ett produkt, men et produkt kan tilhøre bare én kategori.

Når du ser gjennom tabellstrukturene, kan du være på utkikk etter gjentatte grupper. Vurder for eksempel en tabell som inneholder følgende kolonner:

  • Produkt-ID

  • Navn

  • Produkt-ID1

  • Navn1

  • Produkt-ID2

  • Navn2

  • Produkt-ID3

  • Navn3

Her er hvert produkt en gjentagende gruppe med kolonner som er forskjellig fra de andre bare ved å legge til et tall på slutten av kolonnenavnet. Når du ser kolonner nummerert på denne måten, bør du gå tilbake til utformingen.

En slik utforming har flere anseelser. Først tvinger det deg til å plassere en øvre grense på antall produkter. Så snart du overskrider grensen, må du legge til en ny gruppe med kolonner i tabellstrukturen, som er en viktig administrativ oppgave.

Et annet problem er at leverandører som har mindre enn det maksimale antallet produkter, sløser med litt plass, siden de ekstra kolonnene vil være tomme. Den mest alvorlige mangelen på en slik utforming er at det gjør mange oppgaver vanskelige å utføre, for eksempel å sortere eller indeksere tabellen etter produkt-ID eller navn.

Når du ser gjentatte grupper, ser du nøye gjennom utformingen med et øye med å dele tabellen i to. I eksemplet ovenfor er det bedre å bruke to tabeller, én for leverandører og én for produkter, koblet med leverandør-ID.

Til toppen av siden

Bruke normaliseringsreglene

Du kan bruke reglene for data normalisering (noen ganger bare kalt normaliseringsregler) som neste trinn i utformingen. Du bruker disse reglene for å se om tabellene er riktig strukturert. Prosessen med å bruke reglene i databaseutformingen kalles å normalisere databasen, eller bare normalisering.

Normalisering er svært nyttig når du har representert alle informasjonselementene og har kommet til et foreløpig design. Idéen er å sikre at du har delt informasjonselementene inn i de riktige tabellene. Hva normalisering ikke kan gjøre, er å sikre at du har alle de riktige dataelementene til å begynne med.

Du bruker reglene etter hverandre, på hvert trinn for å sikre at utformingen kommer til ett av det som kalles «vanlige skjemaer». Fem normale skjemaer er bredt godkjent – det første normale skjemaet gjennom det femte normale skjemaet. Denne artikkelen utvides på de tre første, fordi de er alle som kreves for de fleste databaseutforminger.

Første normale skjema

Første normale skjema viser at det i hver rad og kolonne skjæringspunkt i tabellen der, finnes en enkelt verdi, og aldri en liste over verdier. Du kan for eksempel ikke ha et felt kalt Pris der du plasserer mer enn én pris. Hvis du tenker på hvert skjæringspunkt mellom rader og kolonner som en celle, kan hver celle bare inneholde én verdi.

Andre normalskjema

Andre normalskjema krever at hver ikke-nøkkelkolonne er helt avhengig av hele primærnøkkelen, ikke bare på en del av nøkkelen. Denne regelen gjelder når du har en primærnøkkel som består av mer enn én kolonne. Anta for eksempel at du har en tabell som inneholder følgende kolonner, der ordre-ID og produkt-ID utgjør primærnøkkelen:

  • Ordre-ID (primærnøkkel)

  • Produkt-ID (primærnøkkel)

  • Produktnavn

Denne utformingen bryter andre normalform fordi produktnavnet er avhengig av produkt-ID, men ikke på ordre-ID, så den er ikke avhengig av hele primærnøkkelen. Du må fjerne produktnavnet fra tabellen. Den tilhører en annen tabell (produkter).

Tredje normalskjema

Tredje normalskjema krever at ikke bare hver ikke-nøkkelkolonne er avhengig av hele primærnøkkelen, men at ikke-nøkkelkolonner er uavhengige av hverandre.

En annen måte å si dette på, er at hver ikke-nøkkelkolonne må være avhengig av primærnøkkelen og ingenting annet enn primærnøkkelen. Anta for eksempel at du har en tabell som inneholder følgende kolonner:

  • ProduktID (primærnøkkel)

  • Navn

  • SRP

  • Diskonto

La oss si at Rabatt avhenger av den foreslåtte utsalgsprisen (SRP). Denne tabellen bryter tredje normalform fordi en ikke-nøkkelkolonne, Discount, avhenger av en annen ikke-nøkkelkolonne, SRP. Uavhengighet av kolonner betyr at du skal kunne endre ikke-nøkkelkolonner uten å påvirke andre kolonner. Hvis du endrer en verdi i SRP-feltet, endres rabatten tilsvarende, og bryter dermed denne regelen. I dette tilfellet skal Rabatt flyttes til en annen tabell som er tastet inn på SRP.

Til toppen av siden

Trenger du mer hjelp?

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Microsoft Office Insider-deltakere

Var denne informasjonen nyttig?

Hvor fornøyd er du med språkkvaliteten?
Hva påvirket opplevelsen din?

Takk for tilbakemeldingen!

×