En riktig utformet database gir deg tilgang til oppdatert, nøyaktig informasjon. Siden en riktig utforming er avgjørende for å nå målene dine når du arbeider med en database, er det fornuftig å investere tiden som kreves for å lære prinsippene for god design. Når det kommer til stykket, er det mye mer sannsynlig at du ender opp med en database som dekker dine behov og enkelt kan ta hensyn til endringer.
Denne artikkelen inneholder retningslinjer for planlegging av en skrivebordsdatabase. Du lærer hvordan du fastslår hvilken informasjon du trenger, hvordan du deler 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 din første skrivebordsdatabase.
I denne artikkelen
- Noen databasetermer du bør vite
- Hva er god databaseutforming?
- Utformingsprosessen
- Fastslå formålet med databasen
- Finne og organisere den nødvendige informasjonen
- Del informasjonen inn i tabeller
- Gjør informasjonselementer om til kolonner
- Angi primærnøkler
- Oppretting av tabellrelasjoner
- Forbedre utformingen
- Bruke normaliseringsreglene
Noen databasetermer du bør vite
Access organiserer informasjonen i tabeller – lister med rader og kolonner som ligner på regnskapsskjemaer 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 inneholder informasjon om ordrer, og en annen tabell med informasjon om kunder.
Hver rad kalles mer korrekt en post, og hver kolonne kalles 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 alle oppføringer. 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.
Hva er god databaseutforming?
Visse prinsipper veileder databaseutformingsprosessen. Det første prinsippet er at duplisert informasjon (også kalt overflødige data) er dårlig, fordi det tar unødig plass og øker sannsynligheten for feil og inkonsekvenser. Det andre prinsippet er at det er viktig at informasjonen er korrekt og fullstendig. Hvis databasen inneholder feil informasjon, vil eventuelle rapporter som henter informasjon fra databasen, også inneholde feil informasjon. Som et resultat vil eventuelle beslutninger du tar som er basert på disse rapportene, bli feilinformert.
En god databaseutforming er derfor en som gjør følgende:
- Deler informasjonen inn i emnebaserte tabeller for å redusere overflødige data.
- Gir Access informasjonen som kreves for å slå sammen informasjonen i tabellene etter behov.
- Bidrar til å støtte og sikre nøyaktigheten og integriteten til informasjonen din.
- Tilrettelegger for dine behov for databehandling og rapportering.
Utformingsprosessen
Utformingsprosessen består av følgende trinn:
-
Bestem formålet med databasen
Dette hjelper deg med å forberede deg på de gjenværende trinnene. -
Finn og organiser den nødvendige informasjonen
Samle inn alle typer informasjon du kan registrere i databasen, for eksempel produktnavn og ordrenummer. -
Del informasjonen inn i tabeller
Del informasjonselementene i hovedenheter eller emner, for eksempel produkter eller ordrer. Hvert emne blir da en tabell. -
Gjøre informasjonselementer om til kolonner
Bestem hva slags 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 avgjør hvordan dataene i én tabell er relatert til dataene i andre tabeller. Legg til felt i tabeller eller opprett nye tabeller etter behov for å tydeliggjøre relasjonene. -
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 i utformingen etter behov. -
Bruke normaliseringsreglene
Bruk datanormaliseringsreglene for å se om tabellene er riktig strukturert. Foreta justeringer i tabellene etter behov.
Fastslå formålet med databasen
Det er lurt å skrive ned formålet med databasen på papir – formålet, 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 slikt som «Kundedatabasen inneholder en liste over kundeinformasjon med det formål å produsere masseutsendelser og rapporter.» Hvis databasen er mer kompleks eller brukes av mange personer, noe som ofte skjer i en bedriftssammenheng, kan formålet lett være et avsnitt eller flere, og bør inkludere når og hvordan hver enkelt person skal bruke databasen. Tanken er å ha en velutviklet 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 beslutninger.
Finne og organisere den nødvendige informasjonen
Hvis du vil finne og organisere den nødvendige informasjonen, starter du med den eksisterende informasjonen. Du kan for eksempel registrere kjøpsordrer i en protokoll eller oppbevare kundeinformasjon på papirskjemaer i et arkivskap. Samle inn disse dokumentene og list opp hver type informasjon som vises (for eksempel hver boks du fyller ut i et skjema). Hvis du ikke har noen eksisterende skjemaer, kan du i stedet tenke deg at du må utforme et skjema for å registrere kundeinformasjonen. Hvilken informasjon ville du ha lagt til i skjemaet? Hvilke utfyllingsbokser ville du opprettet? Identifiser og liste opp hvert av disse elementene. Anta for eksempel at du for øyeblikket oppbevarer kundelisten på kartotekkort. Når du undersøker disse kortene, kan det vise at hvert kort inneholder kundens navn, adresse, poststed, postnummer og telefonnummer. Hvert av disse elementene representerer en potensiell kolonne i en tabell.
Når du klargjør denne listen, ikke bekymre deg for å gjøre den perfekt i begynnelsen. List i stedet opp hvert element du tenker på. Hvis noen andre skal bruke databasen, kan du også be om deres ideer. Du kan finjustere listen senere.
Deretter bør du vurdere hvilke typer rapporter eller masseutsendelser du kanskje vil opprette fra databasen. Du vil for eksempel kanskje ha en produktsalgsrapport som viser salg etter område, eller en sammendragsrapport for beholdningen som viser lagerbeholdningen av produktet. Du kan også generere standardbrev som skal sendes til kunder som kunngjør en salgshendelse eller tilbyr en premie. Utform rapporten slik at du kan forestille deg hvordan den vil se ut. Hvilken informasjon ville du plassere i rapporten? Før opp hver enkelt liste. Gjør det samme for standardbrevet og for alle andre rapporter du regner med å opprette.
Når du tenker gjennom hvilke rapporter og masseutsendelser du skal opprette, blir det enklere å identifisere elementer du trenger i databasen. La oss for eksempel si at du gir kunder mulighet til å melde seg på (eller av) periodiske oppdateringer per e-post, og at du vil skrive ut en liste over de som har meldt seg på. Du registrerer denne informasjonen ved å legge til kolonnen Send e-post i kundetabellen. Du kan angi feltet til Ja eller Nei for hver kunde.
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 de skal sendes til. Derfor må du registrere en e-postadresse for hver kunde.
Det er fornuftig å lage en prototype av hver rapport- eller utdataliste og vurdere hvilke elementer du trenger for å produsere rapporten. Når du for eksempel undersøker en standardbrev, kan det være et par ting du tenker på. Hvis du vil inkludere en ordentlig hilsen, for eksempel «Mr.», «Mrs.» eller «Ms.»-strengen som starter en hilsen, må du opprette et hilsningselement. Du kan også vanligvis starte et brev med «Kjære herr Smith», i stedet for «Kjære. Mr. Sylvester Smith". Dette antyder at du vanligvis ønsker å lagre etternavnet atskilt fra fornavnet.
Et viktig poeng å huske er at du bør dele hver bit informasjon opp i de minste delene som gir mening. Når det gjelder et navn, må du dele navnet i to deler – fornavn og etternavn for å gjøre etternavnet lett tilgjengelig. 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 over spørsmålene du kanskje vil at databasen skal gi svar på. Hvor mange salg av det utvalgte produktet avsluttet du for eksempel forrige måned? Hvor bor de beste kundene dine? Hvem er leverandøren for ditt bestselgende produkt? Å forutse disse spørsmålene hjelper deg med å finne flere elementer som skal registreres.
Når du har samlet inn denne informasjonen, er du klar for neste trinn.
Del informasjonen inn i tabeller
Hvis du vil dele informasjonen inn i tabeller, velger du hovedenhetene eller emnene. Etter at du for eksempel har funnet og organisert informasjon for en produktsalgsdatabase, kan den foreløpige listen se slik ut:
De viktigste enhetene som vises her, er produktene, leverandørene, kundene og ordrene. Derfor er det fornuftig å starte med disse fire tabellene: en for fakta om produkter, én for fakta om leverandører, en for fakta om kunder og en for fakta om ordrer. Selv om dette ikke fullfører listen, er det et godt utgangspunkt. Du kan fortsette å begrense denne listen til du har en utforming som fungerer bra.
Når du ser gjennom den foreløpige listen over elementer, kan det friste å plassere alle elementene i én enkelt tabell, i stedet for de fire som er vist i illustrasjonen ovenfor. Du vil lære her hvorfor det er en dårlig idé. Tenk litt over tabellen som er vist her:
I dette tilfellet inneholder hver rad informasjon både om 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 er en mye bedre løsning å registrere leverandørinformasjon bare én gang i en separat leverandørtabell og deretter koble denne tabellen til Produkter-tabellen.
Et annet problem med denne utformingen oppstår når du må endre informasjon om leverandører. 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øser du problemet.
Når du utformer databasen, bør du alltid prøve å registrere hvert faktum bare én gang. Hvis du oppdager at du gjentar den samme informasjonen på mer enn ett sted, for eksempel på 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 du vil slette produktet, men beholde leverandørnavnet og adresseinformasjonen. Hvordan kan du slette produktoppføringen uten at du også mister 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 én post uten å slette den andre. Hvis du vil holde disse faktaene separate, må du dele én tabell i to: én tabell for produktinformasjon og en annen tabell for leverandørinformasjon. Når du sletter en produktoppføring, skal bare fakta om produktet, ikke fakta om leverandøren, slettes.
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, hører den hjemme i leverandørtabellen.
Gjør informasjonselementer om til kolonner
Når du skal bestemme kolonnene i en tabell, må du bestemme hvilken informasjon du må spore om emnet som er registrert i tabellen. For kundetabellen utgjør for eksempel Navn, Adresse, Poststed, Send e-post, Hilsen og E-postadresse en god startliste med kolonner. Hver post i tabellen inneholder samme sett med kolonner, slik at du kan lagre informasjon om navn, adresse, poststed, poststed, hilsen og e-postadresse for hver post. Adressekolonnen inneholder for eksempel kundenes adresser. Hver post inneholder data om én kunde, og adressefeltet inneholder adressen til denne kunden.
Når du har bestemt det første settet med kolonner for hver tabell, kan du presisere 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. Adressen består også 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 søke, filtrere eller sortere etter delstat, trenger du informasjonen om delstat lagret i en egen kolonne.
Du bør også vurdere om databasen kan inneholde informasjon som bare er av innenlands opprinnelse, eller om den også er internasjonal. Hvis du for eksempel har tenkt å lagre internasjonale adresser, er det bedre å ha en Område-kolonne i stedet for Delstat, fordi en slik kolonne kan romme både nasjonale delstater og områdene i andre land/områder. På samme måte er postnummer mer fornuftig enn postnummer hvis du skal lagre internasjonale adresser.
Listen nedenfor viser noen tips for å bestemme kolonnene dine.
-
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 Produkter i ordre-rapport som viser delsummen av enheter i ordre for hver produktkategori i databasen. Det finnes imidlertid ingen kolonne for delsum for enheter i ordre i noen tabeller. Produkt-tabellen inneholder i stedet en kolonne for enheter i ordre som inneholder enhetene som er bestilt for hvert produkt. Access beregner delsummen hver gang du skriver ut rapporten ved hjelp av disse dataene. Selve delsummen skal ikke lagres i en tabell. -
Lagre informasjon i de minste logiske delene
Det kan hende du ønsker å bruke 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 å innhente enkeltfakta 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.
Når du har finpusset datakolonnene i hver tabell, er du klar til å velge primærnøkkelen for hver tabell.
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 en ansatt-ID eller et serienummer. I databaseterminologi kalles denne informasjonen primærnøkkelen for tabellen. Primærnøkler brukes til å koble sammen data fra flere tabeller i Access og til å samle dataene sammen 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økkel 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 bør for eksempel ikke bruke andres navn som primærnøkkel, fordi navn ikke er unike. Du kan lett ha to personer med samme navn i samme tabell.
En primærnøkkel må alltid ha en verdi. Hvis en kolonneverdi kan bli utilordnet eller ukjent (en manglende verdi), kan den ikke brukes som en komponent i en primærnøkkel.
Du bør alltid velge en primærnøkkel som ikke endrer verdien. I en database som bruker mer enn én tabell, kan primærnøkkelen for en tabell brukes som referanse i andre tabeller. Hvis primærnøkkelen endres, må endringen også brukes overalt der nøkkelen refereres til. Hvis du bruker en primærnøkkel som ikke vil endres, reduseres sjansen for at primærnøkkelen ikke lenger synkroniseres med andre tabeller som refererer til den.
Et vilkårlig unikt nummer brukes ofte som primærnøkkel. Du kan for eksempel tilordne hver ordre et unikt ordrenummer. Ordrenummerets eneste formål er å identifisere en ordre. Når den først er tilordnet, endres den aldri.
Hvis du ikke tenker på en kolonne eller et sett med kolonner som kan være en god primærnøkkel, bør du vurdere å bruke en kolonne som har datatypen Autonummer. Når du bruker datatypen Autonummer, tilordnes det automatisk en verdi i Access. En slik identifikator er faktaløs; Det inneholder ingen faktiske opplysninger som beskriver raden den representerer. Identifikatorer uten fakta er ideelle 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 faktainformasjonen kan endres.
1. En kolonne satt til datatypen Autonummer er 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 utgjør primærnøkkelen for en tabell. En Ordredetaljer-tabell som lagrer linjeelementene 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.
Du kan opprette en Autonummerering-kolonne for hver av tabellene for å fungere som primærnøkkel i produktsalgsdatabasen: ProduktID for Produkter-tabellen, OrdreID for Ordrer-tabellen, KundeID for Kunder-tabellen og LeverandørID for Leverandører-tabellen.
Oppretting av tabellrelasjoner
Nå som du har delt informasjonen inn i tabeller, trenger du en metode for å samle informasjonen på en meningsfull måte. Skjemaet nedenfor inneholder for eksempel informasjon fra flere tabeller.
1. Informasjonen i dette skjemaet kommer fra tabellen Kunder...
2. ... tabellen Ansatte ...
3. ... ordretabellen ...
4. ... Produkter-tabellen...
5. ... og Ordredetaljer-tabellen.
Access er et system for administrasjon av relasjonsdatabaser. I en relasjonsdatabase deler du informasjonen inn i separate, emnebaserte tabeller. Deretter bruker du tabellrelasjoner til å samle informasjonen etter behov.
Opprette en én-til-mange-relasjon
Se på dette eksemplet: Tabellene Leverandører og Produkter i produktordredatabasen. En leverandør kan levere et hvilket som helst antall produkter. Følgelig kan det være mange produkter representert i Produkter-tabellen for alle leverandører som er representert i tabellen. Relasjonen mellom Leverandører-tabellen og Produkter-tabellen er derfor en én-til-mange-relasjon.
Hvis du vil representere en én-til-mange-relasjon i databaseutformingen, tar du primærnøkkelen på den ene siden i 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 tabellen Leverandører i tabellen Produkter. Access kan deretter bruke leverandør-ID-nummeret i Produkter-tabellen til å finne den riktige leverandøren for hvert produkt.
Leverandør-ID-kolonnen i produkttabellen kalles sekundærnøkkel. En sekundærnøkkel er primærnøkkelen i en annen tabell. Kolonnen Leverandør-ID i tabellen Produkter er en sekundærnøkkel fordi den også er primærnøkkelen i tabellen Leverandører.
Du danner grunnlaget for sammenføyning av relaterte tabeller ved å opprette par av primærnøkler og sekundærnøkler. Hvis du ikke er sikker på hvilke tabeller som skal dele en felles kolonne, kan du identifisere en én-til-mange-relasjon sørge for at de to tabellene som er involvert, faktisk krever en delt kolonne.
Opprette en mange-til-mange-relasjon
Vurder relasjonen mellom varetabellen og ordretabellen.
É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 varetabellen kan det være mange poster i ordretabellen. Denne typen relasjon kalles en mange-til-mange-relasjon fordi det kan være mange ordrer for et hvilket som helst produkt. Og for enhver bestilling kan det være mange produkter. Merk at for å oppdage mange-til-mange-relasjoner mellom tabellene, er det viktig at du tenker over begge sider i relasjonen.
Emnene i de to tabellene – ordrer og produkter – har en mange-til-mange-relasjon. Dette er et problem. For å forstå problemet kan du forestille deg hva som ville skje hvis du prøvde å opprette relasjonen mellom de to tabellene ved å legge til Produkt-ID-feltet i Ordrer-tabellen. Hvis du vil ha mer enn ett produkt per ordre, trenger du mer enn én post i ordretabellen per ordre. Du ville gjentatt ordreinformasjon for hver rad som er knyttet til en enkelt ordre, noe som resulterte i en ineffektiv utforming som kan føre til unøyaktige data. Du støter på det samme problemet hvis du plasserer feltet Ordre-ID i produkttabellen – du vil ha mer enn én post i produkttabellen for hvert produkt. Hvordan løser du dette problemet?
Løsningen er å opprette en tredje tabell, ofte kalt foreningstabell, som deler opp 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.
Hver post i tabellen Ordredetaljer representerer én linjeartikkel i en ordre. Primærnøkkelen til Ordredetaljer-tabellen består av to felt – sekundærnøklene fra Ordrer- og Produkt-tabellen. Bruk av feltet Ordre-ID alene fungerer ikke som primærnøkkel for denne tabellen, fordi én ordre kan ha mange linjeelementer. Ordre-ID-en gjentas for hvert linjeelement i en ordre, slik at feltet ikke inneholder unike verdier. Bruk av Produkt-ID-feltet alene fungerer heller ikke, fordi ett produkt kan vises i mange forskjellige ordrer. Sammen gir de to feltene alltid en unik verdi for hver post.
I produktsalgsdatabasen er ikke ordretabellen og produkttabellen direkte relatert til hverandre. I stedet er de indirekte relatert gjennom 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 ett linjeelement, men hvert linjeelement er bare koblet til én ordre.
- Varetabellen og Ordredetaljer-tabellen har en én-til-mange-relasjon. Hvert produkt kan ha mange linjeelementer tilknyttet, men hvert linjeelement refererer bare til ett produkt.
Fra Ordredetaljer-tabellen kan du bestemme alle produktene i en bestemt ordre. Du kan også finne ut alle ordrene for et bestemt produkt.
Når Ordredetaljer-tabellen er innlemmet, kan listen over tabeller og felt se omtrent slik ut:
Opprette en én-til-én-relasjon
En annen type relasjon er én-til-én-relasjon. Anta for eksempel at du må registrere spesiell supplerende produktinformasjon som du sjelden trenger, eller som bare gjelder noen få produkter. Fordi du ikke trenger informasjonen ofte, og fordi lagring av informasjonen i Produkter-tabellen resulterer i tom plass for hvert produkt den ikke gjelder for, plasserer du den i en egen tabell. På samme måte som med Produkter-tabellen bruker du Produkt-ID som primærnøkkel. Relasjonen mellom denne ekstratabellen og produkttabellen er en én-til-én-relasjon. For hver post i produkttabellen finnes det én enkelt samsvarende post i tilleggstabellen. 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 ikke vil gjøre dette av en eller annen grunn, kanskje fordi det ville føre til mye ledig plass, 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 ulike 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.
Når du fastslår relasjonen mellom tabeller, kan du sikre at du har riktige tabeller og kolonner. Når det finnes en én-til-én- eller én-til-mange-relasjon, må de berørte tabellene dele en eller flere felles kolonner. Når det finnes en mange-til-mange-relasjon, er det nødvendig med en tredje tabell som representerer relasjonen.
Forbedre 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 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 vil ha. Opprett grove utkast 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, kan du endre utformingen for å fjerne den.
Når du prøver den første databasen, oppdager du sannsynligvis rom for forbedringer. Her er noen ting du bør sjekke for:
- Har du glemt noen kolonner? Hører informasjonen i så fall hjemme 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 vil 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 som beregnes ut fra utsalgsprisen, er det vanligvis bedre å gjøre nettopp dette, og unngå å opprette en ny kolonne.
- Legger du gjentatte ganger inn duplikatinformasjon i en av tabellene? I så fall må du sannsynligvis dele tabellen 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 kan du vurdere å utforme tabellen på nytt, slik at den har færre felt og flere poster.
- Er hvert informasjonselement delt inn i de minste delene som gir mening? Hvis du trenger å rapportere, sortere, søke i eller beregne med et informasjonselement, kan du plassere elementet i en egen kolonne.
- Inneholder hver kolonne fakta om tabellens emne? Hvis en kolonne ikke inneholder informasjon om tabellens emne, hører den til i en annen tabell.
- Er alle relasjoner mellom tabeller representert, enten etter fellesfelt eller av en tredje tabell? Én-til-én- og én-til-mange-relasjoner krever felles kolonner. Mange-til-mange-relasjoner krever en tredje tabell.
Finjustere produkttabellen
La oss anta at hvert produkt i produktsalgsdatabasen dekkes av en generell kategori, for eksempel drikkevarer, smakstilsetninger eller sjømat. Produkttabellen kan inneholde et felt som viser kategorien for hvert produkt.
La oss si at du, etter å ha undersøkt og finjustert utformingen av databasen, bestemmer deg for å lagre en beskrivelse av kategorien sammen med navnet. Hvis du legger til et felt for kategoribeskrivelse i produkttabellen, må du gjenta hver kategoribeskrivelse for hvert produkt som faller inn under kategorien. Dette er ingen god løsning.
En bedre løsning er å gjøre kategorier til et nytt emne databasen kan spore, med sin egen tabell og sin egen primærnøkkel. Deretter kan du legge til primærnøkkelen fra Kategorier-tabellen i Produkter-tabellen som en sekundærnøkkel.
Kategori- og Produkter-tabellene har en én-til-mange-relasjon: En kategori kan omfatte mer enn ett produkt, men et produkt kan bare tilhøre én kategori.
Når du ser gjennom tabellstrukturene, bør du være oppmerksom på gjentakende grupper. Se 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 gjentakende gruppe med kolonner som skiller seg 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.
Et slikt design har flere feil. For det første tvinger det deg til å sette en øvre grense for antall produkter. Så snart du overskrider denne grensen, må du legge til en ny gruppe med kolonner i tabellstrukturen, som er en viktig administrativ oppgave.
Et annet problem er at de leverandørene som har færre enn maksimalt antall produkter vil kaste bort litt plass, siden de ekstra kolonnene vil være tomme. Den alvorligste feilen med en slik utforming er at den gjør mange oppgaver vanskelige å utføre, for eksempel sortering eller indeksering av tabellen etter produkt-ID eller -navn.
Når du ser gjentakende grupper, kan du se nøye gjennom utformingen med tanke på å 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.
Bruke normaliseringsreglene
Du kan bruke datanormaliseringsreglene (noen ganger bare kalt normaliseringsregler) som neste trinn i utformingen. Du kan bruke disse reglene til å se om tabellene er riktig strukturert. Prosessen med å bruke reglene i databaseutformingen kalles normalisering av databasen, eller bare normalisering.
Normalisering er mest nyttig når du har representert alle informasjonselementene og har kommet til en foreløpig utforming. Hensikten er å hjelpe deg med å sikre at du har delt informasjonselementene inn i de riktige tabellene. Det normalisering ikke kan gjøre, er å sikre at du har alle de riktige dataelementene til å begynne med.
Du bruker reglene i rekkefølge på hvert trinn for å sikre at designet ditt kommer frem til en av det som er kjent som de "normale formene". Fem normalformer er allment akseptert - den første normalformen til den femte normalformen. Denne artikkelen viderefører de tre første, fordi de er alt som kreves for de fleste databaseutforminger.
Første normalskjema
Første normalskjema sier at det finnes en enkelt verdi og aldri en liste over verdier i hvert skjæringspunkt mellom rader og kolonner i tabellen. 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 inneholde bare én verdi.
Andre normalskjema
Andre normalskjema krever at hver kolonne uten nøkkel er fullstendig avhengig av hele primærnøkkelen, ikke bare en del av nøkkelen. Denne regelen gjelder når du har en primærnøkkel som består av flere kolonner. La oss for eksempel si 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 med den andre normale formen fordi produktnavnet er avhengig av produkt-ID, men ikke av ordre-ID, så det er ikke avhengig av hele primærnøkkelen. Du må fjerne Product Name fra tabellen. Den hører hjemme i en annen tabell (Produkter).
Tredje normalform
Tredje normalform krever at ikke bare alle kolonner uten nøkkel er avhengige av hele primærnøkkelen, men at kolonner uten nøkkel er uavhengige av hverandre.
En annen måte å si dette på er at hver kolonne uten nøkkel må være avhengig av primærnøkkelen og bare primærnøkkelen. Anta for eksempel at du har en tabell som inneholder følgende kolonner:
- Produkt-ID (primærnøkkel)
- Navn
- SRP
- Diskonto
Anta at rabatt avhenger av veiledende utsalgspris (SRP). Denne tabellen bryter med tredje normalskjema fordi en kolonne uten nøkkel, Diskontert, avhenger av en annen ikke-nøkkelkolonne, SRP. Kolonneuavhengighet betyr at du skal kunne endre en hvilken som helst kolonne uten nøkkel, uten at det påvirker noen andre kolonner. Hvis du endrer en verdi i SRP-feltet, endres rabatten tilsvarende, og dermed bryter du regelen. I dette tilfellet bør rabatten flyttes til en annen tabell som er inntastet på SRP.