Grunnleggende om databaseutforming

I denne artikkelen

• Noen databasetermer å vite

• Hva er god databaseutforming?

• Utformingsprosessen

• Fastslå formålet med databasen

• Finne og organisere den nødvendige informasjonen

• Dele informasjonen inn i tabeller

• Gjøre informasjonselementer om til kolonner

• Angi primærnøkler

• Opprette tabellrelasjonene

• Finjustere utformingen

• Bruke normaliseringsreglene

Noen databasetermer å vite

Access organiserer informasjonen i tabeller: lister med rader og kolonner som minner om en regnskapsførers tastatur eller et regneark. I en enkel database har du kanskje bare é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.

Hver rad kalles en post på riktig måte, og hver kolonne, et felt. En post er en meningsfull og konsekvent måte å kombinere informasjon om noe på. Et felt er ett 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?

Enkelte prinsipper veileder utformingsprosessen for databasen. Det første prinsippet er at duplisert informasjon (også kalt overflødige data) er ugyldig, fordi den kaster bort plass og øker sannsynligheten for feil og inkonsekvenser. Det andre prinsippet er at riktighet og fullstendighet av informasjon er viktig. Hvis databasen inneholder feil informasjon, vil alle rapporter som henter informasjon fra databasen, også inneholde feil informasjon. Som et resultat vil eventuelle beslutninger du tar som er basert på disse rapportene, deretter bli feilinformert.

En god databaseutforming er derfor en som:

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

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

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

• Imøtekommer behovene for databehandling og rapportering.

Til toppen av siden

Utformingsprosessen

Utformingsprosessen består av følgende trinn:

• Bestem formålet med databasen    

  Dette bidrar til å forberede deg på 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.

• Begrens 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 i utformingen etter behov.

• Bruke normaliseringsreglene    

  Bruk datanormaliseringsreglene for å se om tabellene er strukturert riktig. 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. For en liten database for en hjemmebasert bedrift kan du for eksempel skrive noe enkelt, for eksempel «Kundedatabasen oppbevarer en liste over kundeinformasjon med det formål å produsere masseutsendelse og rapporter». Hvis databasen er mer kompleks eller brukes av mange personer, som ofte forekommer i en bedriftsinnstilling, kan formålet enkelt være et avsnitt eller mer, og bør inkludere når og hvordan hver person skal bruke databasen. Ideen er å ha en godt utviklet misjonserklæring som kan refereres til gjennom hele designprosessen. Å ha en slik uttalelse hjelper deg med å fokusere på målene dine når du tar avgjørelser.

Til toppen av siden

Finne og organisere den nødvendige informasjonen

Hvis du vil finne og organisere informasjonen som kreves, starter du med den eksisterende informasjonen. Du kan for eksempel registrere innkjøpsordrer i en hovedbok eller beholde 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 noen eksisterende skjemaer, kan du tenke deg i stedet at du må utforme et skjema for å registrere kundeinformasjonen. Hvilken informasjon vil du legge inn i skjemaet? Hvilke utfyllingsbokser ville du opprettet? Identifiser og list opp hvert av disse elementene. Anta for eksempel at du for øyeblikket har kundelisten på indekskort. Undersøkelse av disse kortene kan vise 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 klargjør denne listen, trenger du ikke å bekymre deg for å få den perfekt i begynnelsen. List i stedet opp hvert element som kommer til hjernen. Hvis noen andre skal bruke databasen, kan du også be om ideene deres. Du kan finjustere listen senere.

Vurder deretter hvilke typer rapporter eller masseutsendelse du kanskje vil produsere fra databasen. Du vil for eksempel kanskje at en produktsalgsrapport skal vise salg etter område eller en lagersammendragsrapport som viser produktlagernivåer. Det kan også hende du vil generere skjemabrev som skal sendes til kunder som annonserer et salgsarrangement eller tilbyr en premie. Utform rapporten i tankene dine, og tenk deg hvordan den vil se ut. Hvilken informasjon vil du plassere i rapporten? List opp hvert element. Gjør det samme for skjemabrevet og for alle andre rapporter du forventer å opprette.

Hvis du tenker på rapportene og masseutsenderingene du kanskje vil opprette, er det enklere å identifisere elementer du trenger i databasen. Anta for eksempel at du gir kundene muligheten til å melde seg på (eller av) periodiske e-postoppdateringer, 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 å registrere. Når du vet at en kunde ønsker å motta e-postmeldinger, må du også vite e-postadressen de skal sendes til. Derfor må du registrere en e-postadresse for hver kunde.

Det er fornuftig å konstruere en prototype av hver rapport eller utdataliste og vurdere hvilke elementer du trenger for å produsere rapporten. Når du for eksempel undersøker et skjemabrev, kan et par ting komme til hjernen. Hvis du vil inkludere en riktig hilsen, for eksempel «Mr.», «Fru» eller «Fru» som starter en hilsen, må du opprette et hilsenselement. Du kan også vanligvis starte et brev med "Kjære Mr. Smith", i stedet for "Kjære. Mr. Sylvester Smith". Dette tyder på at du vanligvis vil lagre etternavnet atskilt fra fornavnet.

Et viktig poeng å huske er at du bør dele opp hver del av informasjonen i de minste nyttige delene. Hvis du vil gjøre etternavnet lett tilgjengelig når det gjelder et navn, deler du navnet opp i to deler – Fornavn og Etternavn. Hvis du for eksempel vil sortere en rapport etter etternavn, hjelper det å lagre kundens etternavn separat. Hvis du vil sortere, søke, beregne eller rapportere basert på et informasjonselement, bør du generelt plassere elementet i et eget felt.

Tenk på spørsmålene du kanskje vil at databasen skal svare på. Hvor mange salg av det utvalgte produktet avsluttet du forrige måned? Hvor bor de beste kundene dine? Hvem er leverandøren for ditt bestselgende produkt? Hvis du forventer disse spørsmålene, kan du få null på flere elementer du kan registrere.

Når du har samlet inn 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:

Hovedenhetene som vises her, er produktene, leverandørene, kundene og ordrene. Det er derfor fornuftig å starte 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 å begrense listen til du har en utforming som fungerer bra.

Når du først ser gjennom den foreløpige listen over elementer, kan du bli fristet til å plassere alle i én enkelt tabell, i stedet for de fire som vises i den foregående illustrasjonen. Du vil lære her hvorfor det er en dårlig idé. Vurder et øyeblikk, tabellen som vises her:

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

Et annet problem med denne utformingen oppstår når du trenger å endre informasjon om leverandøren. Anta for eksempel at du må endre adressen til 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. Registrering av leverandørens adresse på bare ett sted løser problemet.

Når du utformer databasen, kan 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 levert av Coho Winery, og at du vil slette produktet, men beholde leverandørens navn og adresseinformasjon. Hvordan vil du slette produktposten uten også å miste leverandørinformasjonen? Det går ikke. Fordi hver post inneholder fakta om et produkt, i tillegg til fakta om en leverandør, kan du ikke slette den ene uten å slette den andre. Hvis du vil holde disse faktaene atskilt, må du dele den ene tabellen i to: én tabell for produktinformasjon og en annen tabell for leverandørinformasjon. Hvis du sletter en produktpost, slettes bare fakta om produktet, ikke fakta om leverandøren.

Når du har valgt emnet som representeres av en tabell, bør kolonnene i 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, hører den til i leverandørtabellen.

Til toppen av siden

Gjøre informasjonselementer om til kolonner

Hvis du vil fastslå kolonnene i en tabell, bestemmer du hvilken informasjon du trenger å spore om emnet som er registrert i tabellen. For kunder-tabellen, for eksempel Navn, Adresse, Poststed-Poststed, Send e-post, Hilsen og E-postadresse utgjør en god startliste med kolonner. Hver post i tabellen inneholder samme sett med kolonner, slik at du kan lagre navn, adresse, poststed-postnummer, send e-post, hilsen og e-postadresseinformasjon for hver post. Adressekolonnen inneholder for eksempel kundenes adresser. Hver post inneholder data om én kunde, og adressefeltet inneholder adressen til 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 delstat, trenger du tilstandsinformasjonen som er lagret i en egen kolonne.

Du bør også vurdere om databasen vil inneholde informasjon som bare er av innenlandsk opprinnelse, eller internasjonalt. Hvis du for eksempel planlegger å lagre internasjonale adresser, er det bedre å ha en områdekolonne i stedet for Delstat, fordi en slik kolonne kan gi plass til både nasjonale delstater og områder i andre land/områder. På samme måte gir postnummer mer mening enn postnummer hvis du skal lagre internasjonale adresser.

Listen nedenfor viser noen tips for å 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 rapport om produkter på bestilling som viser delsummen for enheter i rekkefølge for hver produktkategori i databasen. Det finnes imidlertid ingen delsumkolonne for enheter i ordre i noen tabell. I stedet inneholder Produkter-tabellen en enhetsrekkefølge-kolonne som lagrer enhetene i ordre for hvert produkt. Ved hjelp av disse dataene beregner Access delsummen hver gang du skriver ut rapporten. Selve delsummen bør ikke lagres i en tabell.

• Lagre informasjon i de minste logiske delene    

  Du kan bli fristet til å ha ett enkelt felt for fullt 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 felt for fornavn og etternavn, eller for produktnavn, kategori og beskrivelse.

Når du har raffinert 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 bør inneholde en kolonne eller et sett med kolonner som unikt identifiserer hver rad som er lagret i tabellen. Dette er ofte et unikt identifikasjonsnummer, for eksempel et ansatt-ID-nummer eller et serienummer. I databaseterminologi kalles denne informasjonen primærnøkkelen for tabellen. Access bruker primærnøkkelfelt til raskt å knytte data fra flere tabeller og samle dataene for deg.

Hvis du allerede har en unik identifikator for en tabell, for eksempel et produktnummer som unikt identifiserer hvert produkt i katalogen, kan du bruke denne identifikatoren som primærnøkkelen for tabellen, men bare hvis verdiene i denne kolonnen alltid vil være forskjellige for hver post. Du kan ikke ha dupliserte verdier i en primærnøkkel. Du må for eksempel ikke bruke navn på personer som primærnøkkel, fordi navnene 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 en kolonneverdi 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 hvis verdi 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 hvor nøkkelen refereres til. Hvis du bruker en primærnøkkel som ikke endres, reduseres sjansen for at primærnøkkelen blir synkronisert med andre tabeller som refererer til den.

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

Hvis du ikke har i tankene en kolonne eller et sett med kolonner som kan lage en god primærnøkkel, bør du vurdere å bruke en kolonne som har datatypen Autonummer. Når du bruker datatypen Autonummer, tilordner Access automatisk en verdi for deg. En slik identifikator er faktaløs; den inneholder ingen faktainformasjon som beskriver raden den representerer. Faktaløse 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 – et telefonnummer eller et kundenavn – endres, fordi den faktiske informasjonen i seg selv kan endres.

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

I noen tilfeller vil du kanskje bruke to eller flere felt som sammen angir primærnøkkelen for en tabell. En Ordredetaljer-tabell som lagrer linjeelementer for ordrer, bruker for eksempel 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 Autonummerering-kolonne for hver av tabellene som skal fungere som primærnøkkel: Produkt-ID for Produkter-tabellen, OrdreID for ordretabellen, KundeID for Kunder-tabellen og LeverandørID for leverandører-tabellen.

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. Følgende skjema inneholder for eksempel informasjon fra flere tabeller.

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

2. ... Ansatte-tabellen...

3. ... Ordrer-tabellen...

4. ... Produkter-tabellen...

5. ... og Ordredetaljer-tabellen.

Access er et relasjonsdatabasebehandlingssystem. I en relasjonsdatabase deler du informasjonen inn i separate, emnebaserte tabeller. Deretter bruker du tabellrelasjoner til å samle informasjonen etter behov.

Til toppen av siden

Finjustere 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. Når du gjør dette, kan det hende du må legge til en kolonne som du har glemt å sette inn i utformingsfasen, eller du kan ha en tabell som du bør dele opp i to tabeller for å fjerne duplisering.

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

Når du prøver ut den opprinnelige databasen, vil du sannsynligvis oppdage rom for forbedring. Her er noen ting du bør se etter:

• Har du glemt noen kolonner? I så fall hører informasjonen til i de eksisterende tabellene? Hvis det er informasjon om noe annet, må du kanskje opprette en ny tabell. Opprett en kolonne for hvert informasjonselement du må spore. Hvis informasjonen ikke kan beregnes fra andre kolonner, er det sannsynlig at du trenger 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 – 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 én av tabellene? I så fall 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? I så fall bør du tenke på å utforme tabellen på nytt, slik at den har færre felt og flere poster.

• Har hvert informasjonselement blitt delt inn i de minste nyttige delene? Hvis du trenger å rapportere, sortere, søke eller beregne på et informasjonselement, legger du elementet i en egen kolonne.

• Inneholder hver kolonne et faktum om tabellens emne? Hvis en kolonne ikke inneholder informasjon om emnet for tabellen, hører den til i en annen tabell.

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

Bruke normaliseringsreglene

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

Normalisering er mest nyttig når du har representert alle informasjonselementene og har kommet frem til en foreløpig utforming. Tanken er å hjelpe deg med å sikre at du har delt informasjonselementene inn i de riktige tabellene. Det normaliseringen ikke kan gjøre, er å sikre at du har alle de riktige dataelementene til å begynne med.

Du bruker reglene i rekkefølge ved hvert trinn for å sikre at utformingen kommer til et av de «normale skjemaene». Fem normale skjemaer er allment godtatt – den første normale formen gjennom den femte normale formen. Denne artikkelen utvides på de tre første, fordi de er alt som kreves for de fleste databaseutforminger.