Grunnleggende om databaseutforming

Grunnleggende om databaseutforming

Viktig: Denne artikkelen er maskinoversatt, se ansvarsfraskrivelsen. Du finner den engelske versjonen av artikkelen her som referanse.

En riktig utformet database gir deg tilgang til oppdatert og nøyaktig informasjon. Fordi en riktig utforming er viktig å oppnå dine mål i å arbeide med en database, bruke tid kreves for å lære prinsipper for god utforming gir mening. I slutten, er mye mer sannsynlig skal ende opp med en database som oppfyller dine behov og å lett endre.

Denne artikkelen inneholder retningslinjer for planlegging av en skrivebordsdatabase. Du vil lære hvordan du avgjør hvilken informasjon du trenger, hvordan du deler denne informasjonen inn i passende tabeller og kolonner, og hvordan disse tabellene er relatert til hverandre. Du bør lese denne artikkelen før du kan opprette din første skrivebordsdatabase.

Viktig: Access inneholder utforming opplevelser som lar deg opprette databaseprogrammer for nettet. Mange utformingshensyn er forskjellige når du utformer for nettet. Denne artikkelen diskutere ikke Web databaseutforming-programmet. For mer informasjon, kan du se artikkelen bygge en database som skal deles på weben.

I denne artikkelen

Noen databasetermer kjent

Hva er god databaseutforming?

Utformingsprosessen

Bestemme formålet med databasen

Søke etter og organisere den nødvendige informasjonen

Å dele informasjon i tabeller

Gjøre informasjonselementer til kolonner

Angi primærnøkler

Opprette tabellrelasjoner

Finpusse utformingen

Bruke normaliseringsregler


Noen databasetermer kjent

Access organiserer informasjonen i tabeller: lister med rader og kolonner som ligner på regnskapsskjemaer eller et regneark. I en enkel database må du kanskje bare én tabell. For de fleste databaser trenger du mer enn én. Du kan for eksempel har en tabell som inneholder informasjon om produkter, en annen tabell som inneholder informasjon om ordrer og en annen tabell med informasjon om kunder.

Bilde som viser tre tabeller i dataark

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

Til toppen av siden

Hva er god databaseutforming?

Bestemte prinsipper utformingsprosessen databasen. Det første prinsippet er at duplisert informasjon (også kalt overflødige data) er ugyldig, fordi det sløsing med mellomrom, og øker sannsynligheten for feil og inkonsekvenser. Det andre prinsippet er at det er viktig å korrekte og fullstendige av informasjon. Hvis databasen inneholder uriktig informasjon, vil alle rapporter som henter informasjon fra databasen også inneholder uriktig informasjon. Resultatet blir deretter alle beslutninger som er basert på disse rapportene være misinformed.

En god databaseutforming er derfor ett som:

  • Dividerer informasjonen i Emne-baserte tabeller til å redusere overflødige data.

  • Gir tilgang med informasjon for å slå informasjonen i tabellene sammen etter behov.

  • Støtter og sikrer nøyaktigheten og integritet informasjon.

  • Passer for din databehandling og rapportering.

Til toppen av siden

Utformingsprosessen

Utformingsprosessen består av følgende trinn:

  • Bestem formålet med databasen   

    Dette hjelper med å gjøre deg klar for resten av trinnene.

  • Finn og organiser den nødvendige informasjonen   

    Samle inn alle typer informasjon du vil registrere i databasen, for eksempel produktnummer navn og rekkefølge.

  • Dele informasjonen i tabeller   

    Dele opp din informasjonselementer i hovedenheter eller emner, for eksempel produkter eller ordrer. Hvert emne blir deretter en tabell.

  • Gjøre informasjonselementer til kolonner   

    Bestemme hva slags informasjon du vil lagre i hver tabell. Hvert element blir et felt, og vises som en kolonne i tabellen. En ansattabell kan for eksempel inneholde felt, for eksempel etternavnet 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 vare-ID eller ordre-ID.

  • Konfigurere tabellrelasjoner   

    Se på hver tabell, og Finn ut hvordan data i én tabell er relatert til dataene i andre tabeller. Legge til felt i tabeller eller opprette nye tabeller for å klargjøre relasjoner, etter behov.

  • Finpusse utformingen   

    Kontroller utformingen for feil. Opprette tabeller og legge til noen poster med eksempeldata. Se hvis du kan få resultatet du ønsker fra tabellene. Foreta endringer i utformingen etter behov.

  • Bruke normaliseringsregler   

    Bruk datanormaliseringsreglene for å se om tabellene er strukturert på riktig måte. Foreta endringer i tabellene etter behov.

Til toppen av siden

Bestemme formålet med databasen

Det er en god idé å skrive ned formålet med databasen på papir – formålet, hvordan du forventer å bruke den, og hvem skal bruke den. For en liten database for en privat basert bedrift, for eksempel kan du skrive enkle ting som "kundedatabasen har en liste over kundeinformasjon for å prøve å produsere masseutsendelser og rapporter." Hvis databasen er mer kompleks eller brukes av mange personer, så ofte forekommer i en bedriftens innstilling formålet, kan være et avsnitt eller flere og skal inneholde når og hvordan hver person skal bruke databasen. Tanken er å ha et godt utformet målsetting som kan refereres til i hele utformingsprosessen. Har for eksempel en setning hjelper deg å fokusere på målene dine når du skal bestemme.

Til toppen av siden

Søke etter og organisere den nødvendige informasjonen

Start med eksisterende informasjon for å finne og organiser den nødvendige informasjonen. Du kan for eksempel registrere bestillinger i en hovedbok eller ha kundeinformasjon på papirskjemaer i et arkivskap. Samle disse dokumentene og liste opp hver informasjonstype, vises (for eksempel hver boks du fyller ut i et skjema). Hvis du ikke har eksisterende skjemaer, heller tenke deg at du trenger å utforme et skjema til å registrere kundeinformasjon. Hva slags informasjon du setter i skjemaet? Hvilke fill-in-boksene vil du opprette? Identifiser og Vis hvert av disse elementene. Anta for eksempel du lagrer kundelisten i et kartotekkort. Undersøker disse kortene, kan vise at hvert kort inneholder kundenavn, adresse, by, tilstand, postnummer og telefonnummer. Hver av disse elementene representerer en mulig kolonne i en tabell.

Når du lager denne listen, ikke bekymre deg om den blir perfekt fra starten. Før opp hvert element som kommer til deg. Hvis noen andre skal bruke databasen, be om deres ideer, også. Du kan finjustere listen senere.

Vurder deretter hvilke typer rapporter eller masseutsendelser du vil opprette fra databasen. Du kan for eksempel vil en salg produkt-rapport som viser salg etter region, eller en sammendragsrapport for lagerbeholdning som viser produktet for lager. Du kan også hende du vil generere standardbrev skal sendes til kunder som gir beskjed om et salg arrangement eller har en førsteklasses. Utforme rapporten i tankene dine og forestille seg hvordan den vil se ut. Hva slags informasjon vil du plassere i rapporten? Hvert listeelement. Gjør det samme for standardbrevet og andre rapporter du regner med å opprette.

En person som ser for seg en varelagerrapport

Du tenker rapporter og masseutsendelser du vil opprette hjelper deg å identifisere elementer du trenger i databasen. Tenk deg at du gir kunder muligheten til å melde deg på til (eller ut av) periodiske e-oppdateringer, og du vil skrive ut en liste over personene som har valgt. Hvis du vil registrere denne informasjonen, kan du legge til en kolonne med «Send e-post» til Kunde-tabellen. For hver kunde, kan du sette feltet til Ja eller Nei.

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

Det er lurt å lage en prototyp for hver rapport eller utdata oppføringen og tenke over hvilke elementer du trenger for å lage rapporten. Når du undersøker et standardbrev, kan du for eksempel et par ting komme på. Hvis du vil inkludere en ordentlig hilsen – for eksempel "Hr", "FRU" eller "FR." strengen som starter en hilsen, må du opprette en innledende hilsningselement. Du kan også vanligvis starte et brev med "Kjære hr Nordmann" i stedet for "Kjære. Hr fornavnet". Dette foreslår du vanligvis vil lagre etternavnet atskilt fra fornavnet.

Et viktig poeng å huske er at du skal dele informasjonen i minste mulige deler. Når det gjelder et navn for å gjøre et etternavn lett tilgjengelig du vil bryte navnet i to deler – Fornavn og etternavn. Hvis du vil sortere en rapport etter etternavn, for eksempel kan det være nyttig for å ha kundens etternavn lagret separat. Hvis du vil sortere, søke, beregne eller rapporten basert på et element med informasjon, bør du Generelt plassere elementet i et eget felt.

Tenk på spørsmålene du vil at databasen til å svare. For eksempel hvor mange salg av produktet solgte du forrige måned? Der de beste kundene live? Hvem er leverandør for bestselgende produktet? Tenke over disse spørsmålene hjelper deg med å null i flere elementer å registrere.

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

Til toppen av siden

Å dele informasjon i tabeller

Hvis du vil dele informasjonen i tabeller, velger du viktige enheter eller emner. Etter søke etter og organisere informasjon for en salg produkt-database, kan listen foreløpig for eksempel se slik ut:

Håndskrevne informasjonselementer gruppert i emner

Viktige enheter vist her er produktene, leverandører, kunder og ordrer. Derfor det er 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øre listen, er det et godt utgangspunkt. Du kan fortsette å begrense denne listen til du har en utforming som fungerer bra.

Når du bør du lese gjennom foreløpig listen over elementer, kan det være fristende å plassere alle i én tabell, i stedet for de fire vist i illustrasjonen. Du lærer her hvorfor det vil si en dårlig idé. Se litt tabellen vist 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 leverandøren. Fordi du kan ha mange produkter fra samme leverandør, har leverandør navn og adresse informasjonen skal gjentas mange ganger. Dette er sløsing med diskplass. Innspilling leverandørinformasjonen bare én gang i en separat leverandørtabell, og deretter koble denne tabellen i produkter-tabellen, er en mye bedre løsning.

Et annet problem med denne utformingen leveres når du skal endre informasjon om leverandøren. Tenk deg at du må endre adressen for en leverandør. Fordi det vises i mange steder, kan du ved et uhell endre adressen på ett sted, men glemme å endre det i den andre. Registrere leverandørens adresse på ett sted løse problemet.

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

Til slutt anta at det er bare ett produkt som leveres av Coho Winery, og du vil slette produktet, men beholde leverandør navn og adresse informasjonen. Hvordan sletter produktet posten uten å miste leverandørinformasjonen? Du kan ikke. Fordi hver post inneholder fakta om et produkt, i tillegg til fakta om en leverandør, kan du slette en uten å slette den andre. Hvis du vil beholde disse fakta separat, må du dele én tabell i to: én tabell for produktinformasjon, og en annen leverandørinformasjon i tabellen. Hvis du sletter en produktpost skal slettes bare fakta om produktet, ikke fakta om leverandøren.

Når du har valgt emne som representeres av en tabell, skal kolonner i tabellen bare lagre fakta om emnet. For eksempel skal product-tabellen bare lagre fakta om produkter. Fordi leverandøradressen er et faktum om leverandøren, og ikke et faktum om produktet, hører den i leverandørtabellen.

Til toppen av siden

Gjøre informasjonselementer til kolonner

Hvis du vil finne ut kolonner i en tabell, kan du bestemme hva slags informasjon du trenger å spore om emnet som er registrert i tabellen. Hvis du for eksempel på Kunder-tabellen, navn, adresse, by-land-postnummer, sende e-post, innledende hilsen og e-postadressen utgjør en god start liste over kolonner. Hver post i tabellen inneholder samme sett med kolonner, slik at du kan lagre navn, adresse, by-land-postnummer, sende e-post, innledende hilsen og e-adresseinformasjon for hver post. Adressekolonnen inneholder for eksempel kundenes adresser. Hver post inneholder data om én kunde, og i Adresse-feltet inneholder adressen for den aktuelle kunden.

Når du har bestemt startsettet med kolonner for hver tabell, kan du finpusse kolonnene. Hvis du for eksempel det er fornuftig å lagre kundenavn som to separate kolonner: fornavn og etternavn, slik at du kan sortere, søk og indeks på bare disse kolonnene. På samme måte adressen består av fem separate komponenter, adresse, by, tilstand, postnummer og land/område, og det er også fornuftig å lagre dem i separate kolonner. Hvis du vil utføre et søk, filtrere eller sortere operasjonen etter område, for eksempel må lagre denne informasjonen i en egen kolonne.

Du bør også vurdere om databasen skal inneholde informasjon som er innenlands origin bare eller internasjonale, også. For eksempel hvis du skal lagre internasjonale adresser, er det bedre å ha en Region-kolonne i stedet for status, fordi slik kolonne kan brukes både innenlands delstater og regioner i andre land/regioner. På samme måte fornuftig postnummer mer enn postnummer hvis du skal lagre internasjonale adresser.

Følgende liste viser noen tips for å fastsette kolonnene.

  • Ikke ta med beregnede data   

    I de fleste tilfeller, bør du ikke lagre resultatet av beregninger i tabeller. I stedet, kan du ha tilgang til å utføre beregningene når du vil se resultatet. Tenk deg at det er en produkter i ordre-rapport som viser delsummen for enheter på nytt for hver produktkategori i databasen. Det er imidlertid ingen bestilte delsum kolonne i en tabell. I stedet inneholder produkter-tabellen en kolonne for bestilte som lagrer enhetene på for hvert produkt. Bruker disse dataene, beregner Access delsummen hver gang du skriver ut rapporten. Selve delsummen skal ikke lagres i en tabell.

  • Lagre informasjon i minste logiske deler   

    Du kan være fristende å ha ett enkelt felt for fullstendige navn, eller for varenavn sammen med varebeskrivelser. Hvis du kombinerer mer enn én type informasjon i et felt, er det vanskelig å hente individuelle fakta senere. Prøv å dele informasjon i logiske deler. for eksempel opprette atskilte felt for fornavn og etternavn, eller for varenavn, kategori og beskrivelse.

Bilde som viser informasjonselementer under utformingsprosessen

Når du har finpusset datakolonnene i hver tabell, er du klar til å velge hver tabells primærnøkkel.

Til toppen av siden

Angi primærnøkler

Hver tabell skal inneholde en kolonne eller et sett med kolonner som identifiserer hver rad i tabellen. Dette er ofte et unikt identifikasjonsnummer, for eksempel en ansatt-ID-nummer eller et serienummer. I terminologien kalles denne informasjonen primærnøkkelen i tabellen. Access bruker primærnøkkelfeltene til raskt å knytte data fra flere tabeller og som samler dataene for deg.

Hvis du allerede har en unik identifikator for en tabell, for eksempel et produktnummer som identifiserer hver vare i katalogen, kan du bruke denne identifikatoren som tabellens primærnøkkel, men bare hvis verdiene i denne kolonnen blir alltid forskjellig for hver post. Du kan ikke ha dupliserte verdier i en primærnøkkel. Hvis du for eksempel ikke Bruk navn på personer som primærnøkkel, fordi navnene 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 verdien for en kolonne, kan bli ikke-tilordnede eller ukjent (en manglende verdi) på et bestemt tidspunkt, kan det ikke brukes som en komponent i en primærnøkkel.

Du bør alltid velge en primærnøkkel som inneholder verdien ikke endres. I en database som bruker mer enn én tabell, kan en tabells primærnøkkel brukes som en referanse i andre tabeller. Hvis primærnøkkelen endres, må endringen også brukes overalt nøkkelen det refereres til. Ved hjelp av en primærnøkkel som ikke endres reduserer sjansen for at primærnøkkelen blir ikke synkronisert med andre tabeller som refererer til den.

En vilkårlig entydig tall brukes ofte, som primærnøkkel. Du kan for eksempel tilordne hver ordre et unikt rekkefølge tall. Nummeret for bare hensikten er å identifisere en ordre. Når tilordnet, endres aldri.

Hvis du ikke har huske på en kolonne eller et sett med kolonner som kan få en god primærnøkkel, kan du vurdere å bruke en kolonne som inneholder datatypen Autonummer. Når du bruker datatypen Autonummer, tilordnes det automatisk en verdi for deg. En slik identifikator har ingen fakta; den inneholder ingen faktiske opplysninger som beskriver raden den representerer. Identifikatorer er ideelt for bruk som primærnøkkel fordi de ikke endres. En primærnøkkel som inneholder fakta om en rad, et telefonnummer eller kundenavn, for eksempel – det er mer sannsynlig skal endres fordi selve faktaopplysningene kan endres.

Bilde som viser varetabell med primærnøkkelfelt.

1. en datakolonne angitt til datatypen Autonummer ofte er en god primærnøkkel. Ingen vare-IDer er like.

I noen tilfeller kan du vil bruke to eller flere felt som sammen utgjør primærnøkkelen for en tabell. For eksempel en Ordredetaljer-tabellen som lagrer linjeelementer for bestillingene bruker to kolonner i primærnøkkelen: ordre-ID og produkt-IDen. Når en primærnøkkel bruker mer enn én kolonne, kalles også en sammensatt nøkkel.

For databasen, kan du opprette et Autonummer-kolonnen for hver tabell skal fungere som primærnøkkel: ProduktID for produkter-tabellen, OrdreID for ordrene bord, KundeID for Kunder-tabellen, og leverandør-ID for tabellen Leverandører.

Bilde som viser informasjonselementer under utformingsprosessen


Til toppen av siden

Opprette tabellrelasjoner

Nå som du har delt informasjonen i tabeller, trenger du en måte å samle sammen informasjonen på meningsfulle måter. Følgende skjema inneholder for eksempel informasjon fra flere tabeller.

Ordreskjemaet

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

2... .dialogboksen ansattabell...

3... .dialogboksen Ordrer-tabellen...

4... .dialogboksen Varetabell...

5... og Ordredetaljer-tabellen.

Access er en relasjonsdatabase behandlingssystemet. I en relasjonsdatabase angir du informasjonen i atskilte, emne-baserte tabeller. Deretter kan du bruke tabellrelasjoner til å samle inn informasjonen etter behov.

Til toppen av siden

Opprette en én-til-mange-relasjon

På dette eksemplet: tabellene Leverandører og varer i produktet orders databasen. En leverandør kan levere vilkårlig antall produkter. Den kommer etter at en av leverandørene representert i Leverandører-tabellen, det kan være for mange produkter som er representert i produkter-tabellen. Forholdet mellom tabellen Leverandører og produkter-tabellen er derfor en én-til-mange-relasjon.

Én-til-mange begrepsmessig

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

Leverandør-ID-kolonnen i produkter-tabellen kalles en sekundærnøkkel. En sekundærnøkkel er en annen tabells primærnøkkel. Leverandør-ID-kolonnen i produkter-tabellen er en sekundærnøkkel fordi det er også primærnøkkelen i Leverandører-tabellen.

Bilde som viser informasjonselementer under utformingsprosessen

Du gir grunnlaget for å bli med relaterte tabeller ved å opprette par med primærnøkler og sekundærnøkler. Hvis du ikke er sikker på hvilke tabeller som skal dele en felles kolonne, sikre identifisere en én-til-mange-relasjon at de to tabellene som er involvert, virkelig, krever en delt kolonne.

Til toppen av siden

Opprette en mange-til-mange-relasjon

Vurder forholdet mellom produkter-tabellen og Ordrer-tabellen.

En enkelt ordre kan inneholde mer enn ett produkt. Et enkeltprodukt kan derimot, vises i mange ordrer. Derfor for hver post i Ordrer-tabellen, kan det være mange poster i produkter-tabellen. Og for hver post i produkter-tabellen, kan det være mange poster i Ordrer-tabellen. Denne relasjonstypen kalles en mange-til-mange-relasjon fordi det kan være mange ordrer; for et produkt og det kan være mange varer for en hvilken som helst rekkefølge. Legg merke til at for å oppdage mange-til-mange-relasjoner mellom tabellene, er det viktig at du vurderer begge sider av relasjonen.

Emnene av de to tabellene – Ordrer og varer – har en mange-til-mange-relasjon. Dette viser et problem. For å forstå problemet, Tenk deg hva som vil 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 oppføring i tabellen Ordrer per ordre. Du må gjenta ordreinformasjonen for hver rad som er knyttet til en enkelt ordre, noe som resulterer i en tidkrevende utforming som kan føre til unøyaktige data. Det oppstår det samme problemet hvis du legger til feltet ordre-ID i produkter-tabellen, vil du har mer enn én oppføring i produkter-tabellen for hvert produkt. Hvordan løser du dette problemet?

Svaret er å opprette en tredje tabell, ofte foreningstabell, som deler opp mange-til-mange-relasjon til to én-til-mange-relasjoner. Du kan sette inn primærnøkkelen fra hver av de to tabellene i den tredje tabellen. Resultatet registrerer den tredje tabellen hver forekomst av relasjonen.

Mange-til-mange-relasjoner

Hver post i tabellen Ordredetaljer representerer ett linjeelement i en rekkefølge. Tabellen Ordredetaljer primærnøkkelen består av to felt – sekundærnøklene fra ordrene og produkter-tabeller. Bare å bruke ordre-ID-feltet fungerer ikke som primærnøkkel for denne tabellen fordi én ordre kan ha mange linjeelementer. Ordre-ID gjentas for hvert linjeelement på en ordre, slik at feltet ikke inneholder unike verdier. Ved hjelp av produkt-ID-feltet alene fungerer ikke, fordi ett produkt kan vises på mange forskjellige ordrer. Men sammen, to feltene gi alltid en unik verdi for hver post.

I databasen, tabellen Ordrer og produkter-tabellen er ikke knyttet til hverandre direkte. I stedet er de indirekte relatert til tabellen Ordredetaljer. Mange-til-mange-relasjon mellom ordrer og varer representeres i databasen ved hjelp av to én-til-mange-relasjoner:

  • Tabellen Ordrer og Ordredetaljer-tabellen har en én-til-mange-relasjon. Hver ordre kan ha flere enn ett 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.

Du kan finne alle produktene på en bestemt rekkefølge fra Ordredetaljer-tabellen. Du kan også finne alle ordrer for et bestemt produkt.

Når du implementerer 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 type relasjon er én-relasjon. Anta for eksempel at du må registrere noen spesielle supplerende produktinformasjon som du sjelden trenger eller som gjelder bare for noen produkter. Og fordi du ikke trenger informasjonen ofte og lagre informasjonen i produkter-tabellen resulterer i tomt område for hver vare der det ikke gjelder, kan du plassere det i en egen tabell. Eksempel produkter-tabellen, kan du bruke ProductID som primærnøkkel. Relasjonen mellom denne supplerende og produkt-tabellen er en én-relasjon. Det finnes en samsvarende post i tabellen supplerende for hver post i Product-tabellen. Når du finner en slik relasjon, må begge tabellene dele et felles felt.

Når du oppdager at du trenger for en én-relasjon i databasen, bør du vurdere om du kan plassere informasjonen fra de to tabellene i én tabell. Hvis du ikke vil gjøre dette en eller annen grunn, kanskje viser fordi det vil føre i mange tomt område i listen nedenfor hvordan du kan 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, velg én eller flere tabeller (en) og setter inn primærnøkkelen i den andre tabellen som en sekundærnøkkel.

Fastslå relasjonene mellom tabellene hjelper deg med å sikre at du har riktig tabeller og kolonner. Når det finnes en én- eller én-til-mange-relasjon, må tabellene som er involvert dele felles kolonnen eller kolonnene. Når det finnes en mange-til-mange-relasjon, er en tredje tabell nødvendig for å representere relasjonen.

Til toppen av siden

Finpusse utformingen

Når du har tabeller, felt og relasjoner som 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 vil utheve potensielle problemer, for eksempel kan hende du må legge til en kolonne som du har glemt å sette inn i utformingsfasen, eller du har en tabell som skal deles inn i to tabeller for å fjerne like data.

Se hvis du kan bruke databasen for å få svar på det du vil bruke. Lag utkast til skjemaer og rapporter, og se om de viser dataene du forventer. Se etter unødvendige duplikater av data, og når du finner en, kan du endre utformingen for å fjerne den.

Når du prøver ut den første databasen, vil du sannsynligvis oppdage forbedres. Her er noen ting å se etter:

  • Har du glemt kolonner? Hvis dette er tilfelle, hører informasjonen i de eksisterende tabellene? Hvis du vil ha informasjon om noe annet, må du opprette en annen tabell. Opprette en kolonne for hvert informasjonselement som du trenger å spore. Hvis informasjonen ikke kan beregnes fra andre kolonner, er det sannsynlig at du trenger en ny kolonne til den.

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

  • Er du gjentatte ganger inn duplisert informasjon i én av tabellene? Hvis dette er tilfelle, 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 enkeltoppføringer? I så fall tror utforme tabellen slik at det er færre felt og flere poster.

  • Har hvert informasjonselement er inndelt minste mulige deler? Hvis du trenger å rapportere, sortere, søke eller beregne på et element med informasjon, kan du plassere elementet i en egen kolonne.

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

  • Er alle relasjoner mellom tabeller som er representert av felles felt eller en tredje tabell? Relasjoner og én-til-mange-relasjoner krever felles kolonner. Mange-til-mange-relasjoner krever en tredje tabell.

Finpusse produkter-tabellen

La oss si at hvert produkt i databasen faller under Generelt, for eksempel drikkevarer, diverse eller Sjømat. Produkter-tabellen kan inkludere et felt som viser kategorien for hvert produkt.

La oss si at etter å undersøke og finpusset utformingen av databasen, du bestemmer deg for å lagre en beskrivelse av kategorien sammen med navnet. Hvis du legger til en kategori beskrivelsesfeltet produkter-tabellen, må du Gjenta hver Kategoribeskrivelse for hvert produkt som hører til i kategorien – dette er ikke en god løsning.

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

Kategorier og varer tabeller 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 går gjennom din tabellstrukturen, kan du være oppmerksom gjentatte grupper. Anta for eksempel en tabell som inneholder følgende kolonner:

  • Produkt-ID

  • Navn

  • Vare-ID1

  • Navn1

  • Produkt-ID2

  • Navn2

  • Produkt-ID3

  • Name3

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

En slik utforming har flere feil. For det første tvinger den du vil plassere en øvre grense for antall produkter. Så snart du overskrider denne grensen, må du legge til en ny gruppe med kolonner tabellstrukturen, som er en stor administrativ oppgave.

Et annet problem er at de leverandørene som har færre enn det maksimale antallet produkter ekstra plass, siden de andre kolonnene vil være tomme. Den mest alvorlige feilen med en slik utforming er at det er mange aktiviteter vanskelig å utføre, for eksempel sortere eller indeksere tabellen etter produkt-IDen eller navn.

Når du ser gjentatte grupper, kontrollerer du utformingen nøye med tanke på å dele inn tabellen i to. I eksemplet ovenfor er det bedre å bruke to tabeller, én for leverandører og én for varer, koblet sammen av leverandør-ID.

Til toppen av siden

Bruke normaliseringsregler

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

Normalisering er svært nyttig når du har representert alle informasjonselementene og har kommet til en foreløpig utforming. Tanken er å hjelpe deg med å sikre at du har delt dine informasjonselementer i passende tabeller. Normalisering ikke kan gjøre er sørge for at du har alle de riktige dataelementene til å begynne med.

Du bruker reglene etter hverandre, på hvert trinn for at utformingen kommer på én av det som er kjent som "normal skjemaene". Fem vanlige skjemaer godtas i stor utstrekning – det første vanlige skjemaet til det femte vanlige skjemaet. Denne artikkelen utvider de første tre, fordi de er alle som er nødvendig for fleste databaseutforminger.

Første normale form

Første vanlige skjemaet angir at hver rad og kolonne skjæringspunktet i tabellen finnes det en enkelt verdi og aldri en liste med verdier. Du kan for eksempel ikke et felt kalt pris i du legger inn mer enn én pris. Hvis du tror på hvert krysningspunkt mellom rader og kolonner som en celle, kan hver celle bare inneholde én verdi.

Andre vanlige skjemaet

Andre vanlige skjemaet krever at hver-nøkkelkolonne er helt avhengig av hele primærnøkkelen, ikke på bare en del av nøkkelen. Denne regelen når du har en primærnøkkel som består av flere kolonner. Hvis du for eksempel anta at du har en tabell som inneholder følgende kolonner, der ordre-ID og produkt-IDen danner primærnøkkelen:

  • Ordre-ID (primærnøkkel)

  • Produkt-ID (primærnøkkel)

  • Varenavn

Denne utformingen bryter med andre vanlige skjemaet, fordi Varenavn er avhengig av produkt-ID, men ikke på ordre-ID, slik at det ikke er avhengig av hele primærnøkkelen. Du må fjerne Varenavn fra tabellen. Den hører til i en annen tabell (produkter).

Tredje normale form

Tredje vanlige skjemaet krever at ikke bare hver ikke-nøkkelkolonne er avhengig av hele primærnøkkelen, men at uten nøkler kolonner være uavhengig av hverandre.

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

  • ProductID (primærnøkkel)

  • Navn

  • SRP

  • Rabatt

Anta at rabatt avhenger av de foreslåtte utsalgsprisen (SRP). Denne tabellen bryter med det tredje vanlige skjemaet fordi en ikke-nøkkelkolonne, rabatt, avhenger av et annet ikke-nøkkelkolonne, SRP. Kolonneuavhengighet betyr at du skal kunne endre en ikke-nøkkelkolonne uten å påvirke andre kolonne. Hvis du endrer en verdi i feltet SRP, ville rabatt endre tilsvarende, dermed bryte denne regelen. I dette tilfellet må rabatt flyttes til en annen tabell som har SRP.

Til toppen av siden

Merknad: Ansvarsfraskrivelse for maskinoversettelse: Denne artikkelen er oversatt av et datasystem i stedet for en oversetter. Microsoft tilbyr disse maskinoversettelsene slik at brukere som ikke snakker engelsk, får tilgang til innhold om Microsoft-produkter, -tjenester og –teknologier. Ettersom artikkelen er maskinoversatt, kan den inneholde feil i vokabular, syntaks eller grammatikk.

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

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×