Grundläggande databasdesign

En databas som designats på rätt sätt tillhandahåller den senaste och mest korrekta informationen. Eftersom designen är så viktig för att du ska kunna uppnå målen med databasen, bör du ta dig tid att lära dig de designregler som finns. Då ökar chanserna för att du får en databas som uppfyller dina behov och som lätt kan anpassas.

I den här artikeln finns riktlinjer för hur du planerar en databas. Du får lära dig att bestämma vilken information som behövs, hur du delar upp informationen i lämpliga tabeller och kolumner och hur dessa tabeller relaterar till varandra. Du bör läsa det här avsnittet innan du skapar din första databas.

Artikelinnehåll


Databastermer som du bör känna till

I Microsoft Office Access 2007 struktureras informationen i tabeller: listor med rader och kolumner som påminner om ett Microsoft Office Excel 2007-kalkylblad. I en enkel databas kanske det bara finns en tabell, men för de flesta databaser krävs det flera. Du kan t.ex. ha en tabell som innehåller information om produkter, en som innehåller information om order och en tredje som innehåller information om kunder.

Bild med tre tabeller i datablad

Varje rad kallas också för en post, och varje kolumn kallas för ett fält. I en post kombineras information om något på ett konsekvent och meningsfullt sätt. Ett fält är ett enskilt element med information – en elementtyp som visas i varje post. I t.ex. tabellen Produkter kan varje post eller rad innehålla information om en produkt. Varje kolumn eller fält innehåller viss typ av information om produkten, t.ex. dess namn eller pris.

Överst på sidan Överst på sidan

Vad kännetecknar en bra databasdesign?

Vissa regler styr designprocessen. Den första regeln är att dubblettinformation (kallas även för redundanta data) är något negativt, eftersom den tar upp onödigt utrymme och ökar risken för fel och inkonsekvenser. Den andra regeln är att informationen måste vara korrekt och fullständig. Om databasen innehåller felaktig information kommer alla rapporter som sammanställs från informationen i databasen också att innehålla felaktig information. Därför grundas alla beslut som du fattar utifrån rapporten på missvisande information.

En bra databasdesign kännetecknas av detta:

  • Informationen delas upp i subjektbaserade tabeller som minskar redundant data.
  • Den tillhandahåller den information som krävs för att informationen i tabellerna ska kunna kopplas ihop.
  • Den ser till att informationen är korrekt och har integritet.
  • Den uppfyller de behov av databearbetning och -rapportering som du har.

Överst på sidan Överst på sidan

Designprocessen

Designprocessen består av följande steg:

  • Bestäm syftet med databasen    

Det här underlättar förberedelserna inför kommande steg.

  • Hitta och strukturera informationen    

Samla in all typ av information som du kan tänkas vilja registrera i databasen, t.ex. produktnamn och ordernummer.

  • Dela upp informationen i tabeller    

Dela upp informationselementen i huvudenheter eller ämnen, t.ex. Produkter eller Order. Varje ämne blir sedan en tabell.

  • Omvandla informationselement till kolumner    

Bestäm vilken information som ska lagras i vilken tabell. Varje element blir ett fält och visas som en kolumn i tabellen. T.ex. tabellen Anställda kan innehålla fält som Efternamn och Anställningsdatum.

  • Ange primärnycklar    

Välj varje tabells primärnyckel. Primärnyckeln är en kolumn som används för att unikt identifiera varje rad. Exempel på detta kan vara Produktnummer eller Ordernummer.

  • Ange tabellrelationer    

Ta en titt på tabellerna och bestäm hur data i en tabell är relaterade till data i de andra tabellerna. Lägg till fält i tabellerna eller skapa nya tabeller som förtydligar relationerna, om det behövs.

  • Förfina designen    

Analysera designen och sök efter fel. Skapa tabellerna och lägg till några poster med exempeldata. Kontrollera att du får det resultat du vill från tabellerna. Gör eventuella justeringar av designen.

  • Tillämpa normaliseringsregler    

Tillämpa reglerna för datanormalisering för att kontrollera att tabellerna är strukturerade på rätt sätt. Gör eventuella justeringar av tabellerna.

Överst på sidan Överst på sidan

Bestäm syftet med databasen

Du bör skriva ned syftet med databasen på papper – vad den ska användas till, hur du tror du kommer att använda den och vem som kommer att använda den. När det gäller en mindre databas för kan det kanske vara "en kunddatabas som innehåller en lista med kundinformation som ska användas för att skapa utskick och rapporter". Om databasen är mer komplicerad eller ska användas av många, t.ex. i ett större företag, kan syftet omfatta ett helt textstycke eller mer och bör även innehålla när och hur varje person ska använda databasen. Tanken är att ha en väl utvecklad målsättning som kan tillämpas genom hela designprocessen. Då blir den enklare att fokusera på målen när du ska fatta beslut.

Överst på sidan Överst på sidan

Hitta och strukturera informationen

När du vill ta reda på och strukturera den information som behövs börjar du med den befintliga informationen. Du kanske t.ex. förvarar inköpsorder i en pärm eller lagrar kundinformation på pappersformulär i ett arkivskåp. Samla ihop dessa dokument och lista de olika informationstyperna (t.ex. varje ruta som du fyller i på formuläret). Om du inte har några befintliga formulär föreställer du dig att du måste designa ett formulär för att registrera kundinformation. Vilken information skulle du då samla in med formuläret? Vilka rutor skulle du skapa? Identifiera och skriv upp alla dessa element. Anta att du har information om kunderna i ett kartotek. Korten kanske innehåller kundens namn, adress, ort, postnummer och telefonnummer. Vart och ett av dessa element representerar en potentiell kolumn i en tabell.

Medan du förbereder listan behöver du inte bekymra dig om att den ska bli perfekt på en gång. I stället ska du skriva upp alla element som du kommer att tänka på. Om även andra ska använda databasen ber du dem om synpunkter. Du kan finjustera listan senare.

Sedan ska du överväga vilka typer av rapporter eller adresslistor som du kan komma att skapa utifrån databasen. Du kanske vill skapa en försäljningsrapport som beskriver försäljning per region, eller en lagersammanfattning som visar inventeringsnivåer. Du kanske också vill skapa standardbrev som ska skickas till kunderna om erbjudanden eller evenemang. Designa rapporten först i huvudet och föreställ dig hur den kan se ut. Vilken information skulle du då ha med i rapporten? Skriv upp alla element. Gör samma sak för standardbrevet och andra rapporter som du tror att du kommer att skapa.

En person som föreställer sig en lagerrapport

Om du tänker igenom de rapporter eller adresslistor som du kan komma att skapa, blir det enklare att identifiera vilka element som behövs i databasen. Anta att du ger dina kunder möjlighet att prenumerera på e-postuppdateringar och vill skriva ut en lista över dem. Du registrerar den informationen genom att lägga till kolumnen “Skicka e-post” i kundtabellen. Du kan ange det här fältet till Ja eller Nej för respektive kund.

Om ett e-postmeddelande ska skickas till kunderna måste ytterligare ett element registreras. När du vet vilka kunder som vill få e-postmeddelanden måste du också känna till vilken e-post adress meddelandena ska skickas till. Därför måste du registrera e-postadressen till respektive kund.

Du bör skapa en prototyp av varje rapport eller lista och fundera över vilka element som behövs för att skapa rapporten. När du t.ex. undersöker ett standardbrev kanske du kommer att tänka på en eller annan sak. Om du vill ha med en lämplig hälsning – t.ex. strängen "Herr", "Fru" eller "Frk" som inleder hälsningsfrasen, måste du skapa ett hälsningselement. Eller så inleder du ett brev med “Till herr Svensson” i stället för “Till herr Sven Svensson”. I så fall bör du lagra för- och efternamn för sig.

En nyckeluppgift är att bryta ned informationen i så små delar som möjligt. När det gäller namn bör efternamnet kunna användas för sig, så därför ska du dela upp namnet i två delar – förnamn och efternamn. Om du vill sortera en rapport utifrån efternamn underlättar det om kundens efternamn lagras separat. Om du vill kunna sortera, söka, beräkna eller rapportera utifrån ett informationselement, bör du i allmänhet placera det elementet i ett separat fält.

Fundera över vilka frågor som databasen ska kunna besvara. T.ex. hur många av en viss produkt lyckades du sälja förra månaden? Var bor dina bästa kunder? Vem levererar din bästsäljande produkt? Om du förutser dessa frågor behöver du kanske inte lägga till fler element i posten senare.

När du har samlat in den här informationen är du klar för nästa steg.

Överst på sidan Överst på sidan

Dela upp informationen i tabeller

När du delar upp informationen i tabeller ska du först välja huvudenheter, eller ämnen. När du t.ex. har letat reda på och strukturerat information för en produktförsäljningsdatabas kan den preliminära listan se ut så här:

Handskrivna informationselement som är grupperade i ämnen

De huvudenheter som visas här är produkter, leverantörer, kunder och order. Därför är det logiskt att börja med dessa fyra tabeller: en för uppgifter om produkter, en för leverantörer, en för kunder och en för order. Även om detta inte blir en komplett lista är det en bra utgångspunkt. Du kan fortsätta att finjustera listan tills du har en design som fungerar.

När du först går igenom den preliminära listan med element kanske du frestas att placera alla i en enda tabell, i stället för de fyra som visas i bilden ovan. Du får snart lära dig varför det inte är någon bra idé. Ta en titt på tabellen som visas här:

Bild som visar en tabell som innehåller både produkter och leverantörer

I det här fallet innehåller varje rad information om både produkten och dess leverantör. Eftersom du har många produkter från samma leverantör, måste leverantörens namn- och adressinformation upprepas många gånger. Detta tar upp onödigt mycket diskutrymme. Att registrera leverantörsinformationen en gång i en separat leverantörstabell och sedan länka den tabellen till produkttabellen är en betydligt bättre lösning.

Ett annat problem med den här designen uppstår när du måste ändra informationen om leverantören. Anta att du måste ändra leverantörens adress. Eftersom den dyker upp på en mängd platser, kanske du av misstag ändrar adressen på ett ställe men missar att göra det på andras ställen. Om du bara registrerar leverantörens adress på ett ställe undviker du det här problemet.

När du designar databasen ska du alltid försöka att registrera en uppgift bara en gång. Om du märker att du upprepar samma information på flera platser, t.ex. adressen till en viss leverantör, ska du placera den informationen i en separat tabell.

Anta till slut att det bara finns en produkt som levereras av Coho Winery och att du vill ta bort produkten men behålla leverantörens namn- och adressinformation. Hur tar du bort produktposten utan att förlora informationen om leverantören? Det går inte. Eftersom varje post innehåller uppgifter om en produkt, inklusive uppgifter om en leverantör, går det inte att ta bort en uppgift utan att ta bort den andra. För att kunna hålla dessa uppgifter åtskilda måste du dela upp tabellen på två olika: en tabell för produktinformation och en annan för leverantörsinformation. Om du tar bort en produktpost tas bara uppgifterna om själva produkten bort, inte om leverantören.

När du har valt ämnet som representeras av en tabell, ska kolumnerna i den tabellen lagra uppgifter om bara det ämnet. Produkttabellen ska bara lagra uppgifter om produkter. Eftersom leverantörsadressen är en uppgift om leverantören, och inte om produkten, tillhör den leverantörstabellen.

Överst på sidan Överst på sidan

Omvandla informationselement till kolumner

När bestämmer vilka kolumner som ska finnas i tabellen måste du först ta reda på vilken information du behöver om ämnet som registreras i tabellen. För tabellen Kunder är kolumnerna Namn, Adress, Postadress, Skicka e-post, Hälsningsfras och E-postadress en bra början. Varje post i tabellen innehåller samma uppsättning kolumner så att du kan lagra information som namn, adress, postadress, skicka e-post, hälsningsfras och e-postadress för varje post. Adresskolumnen innehåller t.ex. kundernas adresser. Varje post innehåller data om en kund och adressfältet innehåller adressen för den kunden.

När du har bestämt vilka kolumner du vill börja med för respektive tabell kan du börja finjustera kolumnerna. Det kan t.ex. vara logiskt att lagra kundnamn som två skilda kolumner, förnamn och efternamn, så att du kan sortera, söka och indexera efter dessa kolumner. Adressen består också för det mesta av flera olika komponenter, gatuadress, ort, postnummer och land/område, så du bör lagra dem i skilda kolumner. Om du vill söka, filtrera eller sortera utifrån t.ex. ort, måste orten lagras i en särskild kolumn.

Du bör också fundera över om databasen ska innehålla enbart inhemsk information eller även internationell. Om du t.ex. tänker lagra internationella adresser bör det finnas en regionkolumn eftersom en sådan kolumn kan innehålla regioner som finns i andra länder/regioner.

I listan nedan finns några tips på hur du bestämmer vilka kolumner som bör finnas med.

  • Ta inte med beräknade data    

I det flesta fall bör du inte lagra resultatet av beräkningar i tabeller. I stället kan du låta Access utföra beräkningar när du vill visa resultatet. Anta att du har en rapport med namnet Beställda produkter som innehåller delsumman för de enheter som är beställda av varje produktkategori i databasen. Det finns emellertid ingen delsummekolumn för Beställda enheter i någon tabell. I stället innehåller tabellen Produkter kolumnen Beställda enheter som lagrar de beställda enheterna för varje produkt. Utifrån dessa data beräknas delsumman varje gång som du skriver ut rapporten. Själva delsumman lagras inte i någon tabell.

  • Lagra informationen i så små logiska delar som möjligt    

Du kanske frestas att ha ett enda fält för hela namnet, eller för produktnamnet tillsammans med produktbeskrivningen. Om du kombinerar flera olika typer av information i ett fält blir det svårt att senare hämta enskilda uppgifter. Försök att dela upp informationen i logiska delar. Skapa t.ex. skilda fält för för- och efternamn, eller för produktnamn, kategori och beskrivning.

Lista med informationselement under designprocessen

När du har finjusterat datakolumnerna i respektive tabell är du klar att välja primärnyckel för tabellerna.

Överst på sidan Överst på sidan

Ange primärnycklar

Varje tabell ska innehålla en kolumn eller en grupp med kolumner som unikt identifierar varje rad som lagras i tabellen. Dessa innehåller ofta ett unikt identifieringsnummer, t.ex. ett anställningsnummer eller ett serienummer. Med databasterminologi kallas den här informationen för tabellens primärnyckel. Primärnyckelfälten används för att associera data från flera tabeller och sammanföra dem åt dig.

Om du redan har en unik identifierare för en tabell, t.ex. ett produktnummer som unikt identifierar varje produkt i en katalog, kan du använda den som tabellens primärnyckel – men bara om värdena i den kolumnen alltid kommer att vara olika för varje post. Det får inte finnas dubbletter av primärnyckeln. Du ska t.ex. inte använda personnamn som primärnyckel, eftersom namnen inte är unika. Det kan lätt hända att två personer med samma namn finns i samma tabell.

En primärnyckel måste alltid innehålla ett värde. Om en kolumns värde kan bli otilldelat eller okänt (ett saknat värde) vid något tillfälle, kan det inte användas som komponent i en primärnyckel.

Du ska alltid välja en primärnyckel vars värde inte kommer att ändras. I en databas som använder fler än en tabell, kan tabellens primärnyckel användas som referens i andra tabeller. Om primärnyckeln ändras måste ändringen också göras på alla andra ställen där nyckeln refereras. Genom att använda en primärnyckel som inte ändras minskar risken för att primärnyckeln blir osynkroniserad med andra tabeller som refererar till den.

Ofta används ett godtyckligt unikt nummer som primärnyckel. Du kanske t.ex. tilldelar varje order ett unikt ordernummer. Ordernumrets enda syfte är att identifiera ordern. När det är tilldelat, ändras det aldrig.

Om du inte har någon egen uppfattning om vilken kolumn som skulle kunna fungera som primärnyckel, bör du använda en kolumn med datatypen Räknare. När du använder datatypen Räknare tilldelas ett värde automatiskt. En sådan identifierare är uppgiftslös, d.v.s. den innehåller inte någon faktisk information som beskriver raden den representerar. Uppgiftslösa identifierare passar utmärkt som primärnycklar eftersom deras värden inte ändras. En primärnyckel som innehåller uppgifter om en rad – t.ex. ett telefonnummer eller kundnamn – kommer troligtvis att ändras eftersom själva informationen kan ändras.


Bild som visar tabellen Produkter med ett primärnyckelfält.

Bildtext 1 En kolumn som anges till datatypen Räknare blir ofta en bra primärnyckel. Två produkter kan inte ha samma produktnummer.

I vissa fall kanske du vill använda två eller flera fält som tillsammans tillhandahåller primärnyckeln för en tabell. Anta att tabellen Orderinformation innehåller radartiklar för order som använder två kolumner som primärnyckel: Ordernr och Produktnr. När en primärnyckel utnyttjar fler än en kolumn kallas den också för sammansatt nyckel.

För produktförsäljningsdatabasen kan du skapa en kolumn med typen Räknare som fungerar som primärnyckel för var och en av tabellerna: Produktnummer för tabellen Produkter, Ordernummer för tabellen Order, Kundnummer för tabellen Kunder och Leverantörsnummer för tabellen Leverantörer.

Bild som visar informationselementen under designprocessen

Överst på sidan Överst på sidan

Skapa tabellrelationer

Nu när du har delat upp informationen i tabeller måste du sammanföra informationen igen på ett meningsfullt sätt. Följande formulär innehåller information från flera tabeller.


Formuläret Order

Bildtext 1 Informationen i det här formuläret kommer från tabellen Kunder...
Bildtext 2 ...tabellen Anställda ...
Bildtext 3 ...tabellen Order...
Bildtext 4 ...tabellen Produkter...
Bildtext 5 ...och tabellen Orderdetaljer.

Access är ett relationsdatabassystem. I en relationsdatabas delar du upp informationen i separata, subjektbaserade tabeller. Sedan använder du tabellrelationerna för att sammanföra informationen.

Överst på sidan Överst på sidan

Skapa 1:N-relationer

Ta en titt på det här exemplet: tabellerna Leverantörer och Produkter i produktorderdatabasen. En leverantör kan leverera ett antal produkter. Därför kan det för varje leverantör i tabellen finnas flera produkter i tabellen Produkter. Relationen mellan tabellen Leverantörer och tabellen Produkter är därför en 1:N-relation.

Begreppet 1:N

När du representerar en 1:N-relation i databasdesignen ska du ha primärnyckeln på 1-sidan av relationen och lägga till den som en ytterligare kolumn eller kolumner i tabellen på N-sidan av relationen. I det här fallet lägger du till kolumnen Leverantörsnummer från tabellen Leverantörer i tabellen Produkter. Access kan sedan använda leverantörsnumret i tabellen Produkter för att hitta rätt leverantör för respektive produkt.

Leverantörsnumret i tabellen Produkter kallas för extern nyckel. En extern nyckel är detsamma som en annan tabells primärnyckel. Leverantörsnumret i tabellen Produkter är en extern nyckel eftersom det också är primärnyckeln i tabellen Leverantörer.

Lista med informationselement under designprocessen

Du sammanför relaterade tabeller genom att para ihop primärnycklar och externa nycklar. Om du är osäker på vilka tabeller som ska ha en gemensam kolumn, kan du genom att identifiera en 1:N-relation säkerställa att två tabeller verkligen behöver en delad kolumn.

Överst på sidan Överst på sidan

Skapa N:N-relationer

Ta en titt på relationen mellan tabellen Produkter och tabellen Order.

En enda order kan omfatta flera produkter. Å andra sidan kan en enskild produkt finnas på flera order. Därför kan det för varje post i tabellen Order finnas många poster i tabellen Produkter. Och för varje post i tabellen Produkter kan det finnas många poster i tabellen Order. Den här typen av relation kallas för N:N-relation eftersom det för varje produkt kan finnas många order och för varje order kan det finnas många produkter. För att du ska hitta N:N-relationerna mellan tabeller är det viktigt att du granskar båda sidorna i relationen.

Ämnena i de två tabellerna – order och produkter – har en N:N-relation. Detta utgör ett problem. För att förstå problemet måste du föreställa dig vad som kan hända om du försöker att skapa en relation mellan de två tabellerna genom att lägga till fältet Produktnummer i tabellen Order. Om det ska kunna finnas mer än en produkt per order, behövs det fler än en post i tabellen Order per order. Då skulle du få upprepa orderinformationen för varje rad som relaterar till en enskild order – vilket innebär en ineffektiv design som kan leda till felaktiga data. Du ställs inför samma problem om du placerar fältet Ordernummer i tabellen Produkter – du skulle behöva ha fler än en post i tabellen Produkter för varje produkt. Hur ska du lösa det problemet?

Svaret är att skapa en tredje tabell, som ofta kallas för kopplingstabell, som bryter ned N:N-relationen i två 1:N-relationer. Du infogar primärnyckeln från var och en av de två tabellerna i den tredje tabellen. I den tredje tabellen registreras därför alla förekomster av relationen.

N:N-relation

Varje post i tabellen Orderdetaljer representerar ett radelement på en order. Tabellens primärnyckel består av två fält – de externa nycklarna från tabellerna Order och Produkter. Fältet Ordernummer fungerar inte ensamt som primärnyckel för tabellen eftersom en order kan innehålla många radelement. Ordernumret upprepas i varje radelement på en order, så fältet innehåller inte unika värden. Fältet Produktnummer fungerar inte heller ensamt, eftersom en produkt kan förekomma på flera order. Men tillsammans skapar de två fälten ett unikt värde för varje post.

I produktförsäljningsdatabasen är tabellerna Order och Produkter inte relaterade till varandra direkt. I stället är de indirekt relaterade via tabellen Orderdetaljer. N:N-relationen mellan order och produkter representeras i databasen med två 1:N-relationer:

  • Tabellen Order och tabellen Orderdetaljer har en 1:N-relation. Varje order kan ha flera radelement, men varje radelement är bara kopplat till en order.
  • Tabellen Produkter och tabellen Orderdetaljer har en 1:N-relation. Varje produkt kan ha flera associerade radelement men varje radelement refererar bara till en produkt.

Från tabellen Orderdetaljer kan du fastställa alla produkter på en viss order. Du kan också fastställa alla order för en viss produkt.

I och med tabellen Orderdetaljer kan listan med tabeller och fält se ut så här:

Lista med informationselement under designprocessen

Överst på sidan Överst på sidan

Skapa 1:1-relationer

En annan typ av relation är 1:1-relationen. Anta att du vill registrera en del extra produktinformation som du sällan behöver eller som bara gäller några få produkter. Eftersom du inte behöver informationen så ofta, och eftersom en massa utrymme tas upp i onödan om du lagrar informationen i tabellen Produkter, ska du placera den i en separat tabell. Du använder Produktnummer som primärnyckel, liksom du gör i tabellen Produkter. Relationen mellan denna extra tabell och tabellen Produkter är en 1:1-relation. För varje post i tabellen Produkter finns det bara en enskild matchande post i den extra tabellen. När du identifierar en sådan relation måste båda tabellerna ha ett gemensamt fält.

När du tycker att du behöver en 1:1-relation i databasen bör du fundera på om du kan placera informationen från de två tabellerna i en tabell. Om du av någon anledning inte vill ha det så, kanske för att en massa tomt utrymme tas upp, visar listan nedan hur du bör representera relationen i designen:

  • Om de två tabellerna har samma ämne, kan du förmodligen konfigurera relationen genom att använda samma primärnyckel i båda tabellerna.
  • Om de två tabellerna har olika ämnen med olika primärnycklar, väljer du en av tabellerna (vilken som) och infogar dess primärnyckel i den andra tabellen som extern nyckel.

Genom att fastställa relationerna mellan tabellerna blir det enklare att säkerställa att du har rätt tabeller och kolumner. När det finns en 1:1-relation eller 1:N-relation måste de inblandade tabellerna ha en gemensam kolumn eller gemensamma kolumner. När det finns en N:N-relation måste en tredje tabell representera relationen.

Överst på sidan Överst på sidan

Förfina designen

När du har de tabeller, fält och relationer som du behöver ska du skapa och fylla tabellerna med exempeldata och försöka att arbeta med informationen: skapa frågor, lägga till nya poster o.s.v. På så sätt kan du hitta potentiella problem – du kanske t.ex. behöver lägga till en kolumn som du har glömt att infoga under designfasen, eller så kanske du har en tabell som du bör dela upp i två tabeller och ta bort dubbletterna.

Kontrollera om du kan använda databasen för att få fram de svar som du vill ha. Skapa enkla utkast av formulären och rapporterna och kontrollera om önskade data visas. Leta efter onödiga dubbletter av data och, om du hittar några, ändra designen så att de försvinner.

När du testar databasen upptäcker du förmodligen hur den kan förbättras. Detta ska du hålla utkik efter:

  • Har du glömt några kolumner? Om så är fallet, tillhör informationen de befintliga tabellerna? Om det är information om något annat kanske du behöver skapa en till tabell. Skapa en kolumn för varje informationselement du behöver. Om informationen inte kan beräknas från andra kolumner, behöver du förmodligen en ny kolumn för den.
  • Är några kolumner onödiga eftersom de kan beräknas från befintliga fält? Om ett informationselement kan beräknas från andra befintliga kolumner – t.ex. ett rabatterat pris som räknas fram från listpriset – är det för det mesta bättre att göra just det och inte skapa någon ny kolumn.
  • Registrerar du samma information om och om igen i någon av tabellerna? I så fall behöver du förmodligen dela upp tabellen i två tabeller som har en 1:N-relation.
  • Har du tabeller med många fält, ett begränsat antal poster och många tomma fält i enskilda poster? Då ska du fundera på att ändra tabellens design så att den får färre fält och fler poster.
  • Har varje informationselement brutits ned i minsta användbara del? Om du behöver rapportera, sortera eller beräkna information bör du placera elementet i en separat kolumn.
  • Innehåller varje kolumn en uppgift om tabellens ämne? Om en kolumn inte innehåller information om tabellens ämne tillhör den en annan tabell.
  • Representeras alla relationer mellan tabellerna, antingen med gemensamma fält eller av en tredje tabell? 1:1- och 1:N-relationer kräver gemensamma kolumner. För N:N-relationer krävs en tredje tabell.

Finjustera tabellen Produkter

Anta att varje produkt i produktförsäljningsdatabasen tillhör en övergripande kategori, t.ex. drycker, tillsatser eller skaldjur. Tabellen Produkter kan innehålla ett fält som visar kategorin för varje produkt.

Anta att du efter att ha undersökt och finjusterat databasens design bestämmer dig för att lagra en beskrivning av kategorin tillsammans med dess namn. Om du lägger till fältet Kategoribeskrivning i tabellen Produkter måste du upprepa varje kategoribeskrivning för varje produkt inom den kategorin –det är ingen bra lösning.

En bättre lösning är att göra Kategorier till ett nytt ämne i databasen, med en egen tabell och en egen primärnyckel. Du kan sedan lägga till primärnyckeln från tabellen Kategorier i tabellen Produkter som en extern nyckel.

Tabellerna Kategorier och Produkter har en 1:N-relation: en kategori kan innehålla fler än en produkt, men en produkt kan bara tillhöra en kategori.

När du går igenom tabellstrukturen ska du hålla utkik efter grupper som upprepas. I en tabell kan det t.ex. finnas följande kolumner:

  • Produktnummer
  • Namn
  • Produktnummer1
  • Namn1
  • Produktnummer2
  • Namn2
  • Produktnummer3
  • Namn3

Här är varje produkt en upprepad grupp med kolumner som bara skiljer sig från de andra genom att en siffra har lagts till i kolumnnamnet. När du ser kolumner som numreras på det här sättet bör du kanske ändra designen.

En sådan design har flera brister. Till att börja med tvingar den dig att ha en övre gräns för antalet produkter. Så snart du överskrider den gränsen måste du lägga till en ny grupp med kolumner i tabellstrukturen, vilket är administrativt besvärligt.

Ett annat problem är att de leverantörer som har färre än maxantalet produkter tar upp onödigt utrymme, eftersom de extra kolumnerna blir tomma. Den allvarligaste bristen med en sådan här design är att många uppgifter blir svåra ett utföra, t.ex. att sortera eller indexera tabellen efter produktnummer eller namn.

När du hittar upprepande grupper ska du noggrant gå igenom designen och fundera på om tabellen kan delas upp i två. I exemplet ovan är det bättre att använda två tabeller, en för leverantörer och en för produkter, sammanlänkade med leverantörsnumret.

Överst på sidan Överst på sidan

Tillämpa normaliseringsregler

Som nästa steg i designen kan du tillämpa datanormaliseringsregler (kallas ibland bara för normaliseringsregler). Du använder dessa regler för att kontrollera att tabellerna är strukturerade på rätt sätt. Att tillämpa reglerna på databasdesignen kallas för att normalisera databasen eller bara för normalisering.

Normalisering är mest användbart efter att du har placerat in alla informationselement och har kommit fram till en preliminär design. Meningen är att säkerställa att du har delat in informationselementen i lämpliga tabeller. Normaliseringen ser till att du har alla korrekta data till att börja med.

Du tillämpar reglerna i tur och ordning, och säkerställer vid varje steg att designen uppnår vad som kallas för "normalformer". Fem normalformer brukar användas – den första normalformen t.o.m. den femte normalformen. I den här artikeln beskrivs de första tre, eftersom det är allt som behövs för de flesta databaser.

Första normalformen

Den första normalformen anger att det vid den första rad- och kolumnskärningen finns ett enskilt värde och aldrig en lista med värden. Det går t.ex. inte att ha ett fält med namnet Pris där du placerar flera pris. Om du ser varje skärningspunkt mellan rader och kolumner som en cell, kan varje cell bara innehålla ett värde.

Andra normalformen

Den andra normalformen kräver att varje kolumn som inte innehåller någon nyckel ska vara helt beroende av hela primärnyckeln, inte bara en del av den. Den här regeln gäller när det finns en primärnyckel som består av flera kolumner. Anta att du har en tabell som innehåller följande kolumner, där Ordernummer och Produktnummer utgör primärnyckeln:

  • Ordernummer (primärnyckel)
  • Produktnummer (primärnyckel)
  • Produktnamn

Den här designen bryter mot den andra normalformen eftersom Produktnamn är beroende av Produktnummer men inte av Ordernummer, så den är inte beroende av hela primärnyckeln. Du måste ta bort Produktnamn från tabellen. Den tillhör en annan tabell (Produkter).

Tredje normalformen

Den tredje normalformen kräver att inte bara de kolumner som inte innehåller nyckel ska vara beroende av hela primärnyckeln, utan att alla kolumner utan nyckel ska vara oberoende av varandra.

Det kan också uttryckas som att alla kolumner utan nyckel måste vara beroende av primärnyckeln och inget annat än primärnyckeln. Anta att du har en tabell med följande kolumner:

  • Produktnummer (primärnyckel)
  • Namn
  • Listpris
  • Rabatt

Anta att Rabatt är beroende av Listpris. Den här tabellen bryter mot den tredje normalformen eftersom en kolumn utan nyckel, Rabatt, är beroende av en annan kolumn utan nyckel, Listpris. Kolumnoberoende innebär att du ska kunna ändra en kolumn utan nyckel utan att påverka någon annan kolumn. Om du ändrar ett värde i fältet Listpris, ändras även Rabatt vilket bryter mot den här regeln. I det här fallet ska Rabatt flyttas till en annan tabell som har en gemensam nyckel med Listpris.

Överst på sidan Överst på sidan

Mer information

Mer information om tabelldesign finns i artikeln Skapa tabeller i en databas.

Mer information om databasdesign finns i följande böcker:

  • Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, andra upplagan. Addison-Wesley Professional. 2003.
  • Fleming, Candace C. von Halle, Barbara. Handbook of Relational Database Design. Addison-Wesley Professional. 1989.
  • Riordan, Rebecca M. Designing Effective Database Systems. Addison-Wesley Professional. 2005.

Överst på sidan Överst på sidan

 
 
Gäller:
Access 2007