Grundläggande databasdesign

Artikelinnehåll

• Databastermer som är bra att känna till

• Vad är god databasdesign?

• Designprocessen

• Bestäm syftet med databasen

• Hitta och strukturera den information som behövs

• Dela upp informationen i tabeller

• Omvandla informationsobjekt till kolumner

• Ange primärnycklar

• Skapa tabellrelationer

• Förfina designen

• Tillämpa normaliseringsregler

Databastermer som är bra att känna till

Access ordnar din information i tabeller: listor med rader och kolumner som påminner om en revisors block eller ett kalkylblad. I en enkel databas kanske du bara har en tabell. För de flesta databaser behöver du fler än en. Du kan till exempel ha en tabell som lagrar information om produkter, en annan tabell som lagrar information om order och en annan tabell med information om kunder.

Varje rad kan mer korrekt kallas för en post, och varje kolumn för ett fält. En post är ett meningsfullt och konsekvent sätt att kombinera information om något. Ett fält är en enstaka bit information – en objekttyp som visas i varje post. I tabellen Produkter skulle t.ex. varje rad eller post innehålla information om en produkt. Varje kolumn eller fält skulle innehålla en viss typ av information om den produkten, exempelvis dess namn eller pris.

Överst på sidan

Vad är god databasdesign?

Det finns vissa principer som bör vägleda arbetet med databasdesign. Den första principen är att duplicerad information (kallas även redundanta data) är något dåligt, eftersom det tar upp utrymme och ökar risken för fel och inkonsekvenser. Den andra principen är att det är viktigt att informationen är korrekt och komplett. Om databasen innehåller felaktig information, så kommer även rapporter som hämtar information från databasen att innehålla felaktig information. I sådant fall kommer eventuella beslut som du fattar utifrån dessa rapporter att bygga på felaktig information.

Det innebär att en god databasdesign gör följande:

• Delar upp informationen i ämnesbaserade tabeller för att minska redundanta data.

• Förser Access med den information som behövs för att sammanfoga informationen i tabellerna vid behov.

• Bidrar till att stödja och säkerställa korrektheten och fullständigheten hos informationen.

• Klarar att uppfylla dina databehandlings- och rapporteringsbehov.

Överst på sidan

Designprocessen

Designprocessen består av följande steg:

• Bestäm syftet med databasen    

  Det här steget är en förberedelse för resten av stegen.

• Hitta och strukturera den information som behövs     

  Samla in alla de typer av information som du kan vilja lagra i databasen, t.ex. produktnamn och ordernummer.

• Dela upp informationen i tabeller    

  Dela upp dina informationsobjekt i olika grupper eller ämnen, t.ex. produkter eller beställningar. Varje ämne blir en egen tabell.

• Omvandla informationsobjekt till kolumner    

  Bestäm vilken information du ska lagra i varje tabell. Varje objekt blir ett fält och visas som en kolumn i tabellen. Tabellen Personal kan t.ex. innehålla fält som Efternamn och Anställningsdatum.

• Ange primärnycklar    

  Välj primärnyckel för varje tabell. Primärnyckeln är en kolumn som används för att identifiera varje enskild rad. Ett exempel kan vara produkt-ID eller beställnings-ID.

• Skapa tabellrelationer    

  Titta på varje tabell och avgör hur data i en tabell förhåller sig till data i andra tabeller. Lägg till fält i tabeller eller skapa nya tabeller för att klargöra relationer efter behov.

• Förfina designen    

  Analysera designen och sök efter fel. Skapa tabeller och lägg till några poster med exempeldata. Se om du får önskat resultat från tabellerna. Justera designen vid behov.

• Tillämpa normaliseringsregler    

  Tillämpa datanormaliseringsregler för att ta reda på om tabellerna är strukturerade på rätt sätt. Justera tabellerna vid behov.

Överst på sidan

Bestämma syftet med databasen

Det är en bra idé att skriva ned syftet med databasen på papper, inklusive hur du tänker använda den och vem som ska använda den. För en liten databas för en verksamhet du driver hemifrån kan du t.ex. skriva något enkelt, som ”Kunddatabasen innehåller en lista med kundinformation för att skapa utskick och ta fram rapporter”. Om databasen är mer komplex eller används av många personer, vilket ofta är fallet i företagsmiljöer, så kan syftet bli ett helt stycke lång, eller flera stycken, och redogöra för när och hur varje person ska använda databasen. Tanken är att ha en väl utvecklad uppdragsbeskrivning som du kan hänvisa till under hela designprocessen. En sådan beskrivning gör det lättare för dig att fokusera på dina mål när du ska fatta beslut.

Överst på sidan

Hitta och strukturera den information som behövs

När du ska hitta och strukturera informationen du behöver börjar du med din befintliga information. Du kanske registrerar inköpsorder i en huvudbok eller har din kundinformation på pappersformulär i ett arkivskåp. Samla in de relevanta dokumenten och skapa en lista över de olika typerna av information som visas (t.ex. de olika rutorna du fyller i i ett formulär). Om du inte har något befintligt formulär kan du istället tänka dig att din uppgift är att skapa ett formulär för registrering av kundinformation. Vilken information skulle du ta med i formuläret? Vilka ifyllningsfält skulle du skapa? Identifiera alla dessa uppgifter och ta med dem i listan. Anta att du för närvarande har din kundlista på arkivkort. Efter en undersökning av korten kanske du upptäcker att varje kort innehåller en kunds namn, adress, ort, region, postnummer och telefonnummer. Var och en av dessa uppgifter representerar en möjlig kolumn i en tabell.

När du förbereder den här listan behöver du inte anstränga dig för att få till allting perfekt från början. Skriv i stället ned alla tänkbara uppgifter som du kommer på. Om någon annan ska använda databasen kan du be dem att dela med sig av sina tankar också. Du kan alltid finjustera listan senare.

Nästa steg är att fundera på vilka typer av rapporter och utskick du kan tänkas vilja skapa utifrån databasen. Du kanske t.ex. vill ha en produktförsäljningsrapport som visar försäljningen per region, eller en sammanfattningsrapport för inventering där lagernivåerna för olika produkter visas. Du kanske även vill generera standardbrev som du ska skicka till kunder för att meddela om en kampanj eller ett erbjudande. Utforma rapporten i huvudet och föreställ dig hur den skulle se ut. Vilken information skulle du ta med i rapporten? Ta med alla uppgifter i listan. Gör samma sak för standardbrevet och eventuella andra rapporter som du planerar att skapa.

Att tänka över de rapporter och utskick du kanske vill skapa kan hjälpa dig att identifiera de uppgifter som du behöver ha med i databasen. Anta t.ex. att du ger kunder möjlighet att välja om de vill få regelbundna uppdateringar via e-post, och att du vill skriva ut en lista över kunder som angett att de vill ha dessa meddelanden. Om du vill nedteckna den informationen måste du lägga till kolumnen ”Skicka e-post” i kundtabellen. För varje kund kan du sedan ställa in fältet som Ja eller Nej.

Om du behöver skicka e-postmeddelanden till kunder är det ganska lätt att komma på en annan uppgift som behöver nedtecknas. När du vet att en kund vill ta emot e-postmeddelanden, så måste du också veta vilken e-postadress du ska skicka dem till. Du måste därför registrera en e-postadress för varje kund.

Det är vettigt att skapa en prototyp av varje rapport eller utdatalistning och fundera över vilka objekt du behöver för att producera rapporten. När du till exempel undersöker ett formulärbrev kan några saker komma att tänka på. Om du vill ta med en korrekt hälsningsfras, till exempel strängen "Herr", "Fru" eller "Ms" som inleder en hälsningsfras, måste du skapa en hälsningsfras. Dessutom kan du vanligtvis börja ett brev med "Dear Mr. Smith", snarare än "Dear. Mr Sylvester Smith" Det här tyder på att du vanligtvis vill lagra efternamnet separat från förnamnet.

En viktig sak att komma ihåg är att du ska dela upp varje typ av information i sina minsta användbara beståndsdelar. När det gäller namn bör du lagra dem i två delar – förnamn och efternamn – så att du kan använda endast efternamnet. Om du t.ex. vill sortera en rapport efter efternamn, så hjälper det t.ex. om du har kundens efternamn lagrat för sig. Rent allmänt gäller att om du vill sortera, söka, beräkna eller rapportera utifrån en viss informationskomponent, så ska den informationen finnas i ett eget fält.

Koncentrera dig på de frågor som du kan tänkas vilja att databasen ska besvara. Till exempel, hur många försäljningar av en viss produkt genomfördes förra månaden? Var bor dina bästa kunder ? Vem är leverantören för din bästsäljande produkt? Om du kan förutse de här frågorna så blir det lättare att lista ut vilka ytterligare uppgifter du behöver ta med.

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

Överst på sidan

Dela upp informationen i tabeller

När du ska dela upp informationen i tabeller väljer du större enheter eller ämnen. När du hittar och strukturerar information för en produktförsäljningsdatabas, så kanske den preliminära listan ser ut så här:

De större enheterna som visas här är produkterna, leverantörerna, kunderna och beställningarna. Därför är det vettigt att utgå från de här fyra tabellerna: en för fakta om produkter, en för fakta om leverantörer, en för fakta om kunder och en för fakta om beställningar. Även om det kanske inte är en helt färdig lista, så är det en bra utgångspunkt. Du kan fortsätta att förfina den här listan tills du fått till en design som fungerar bra.

När du först granskar den preliminära listan över objekt, så kanske du frestas att placera dem alla i en enda tabell, i stället för de fyra som visas i bilden ovan. Du kommer nu att få veta varför det är en dålig idé. Ta en titt på tabellen som visas nedan:

I det här fallet innehåller varje rad information om både produkten och dess leverantör. Eftersom du kan ha många produkter från samma leverantör, så måste leverantörens namn och adress upprepas många gånger. Det slösar lagringsutrymme. Det är en mycket bättre lösning att spara leverantörsinformationen en gång i en separat leverantörstabell och sedan länka den tabellen till tabellen Produkter.

Ett andra problem med denna design blir tydligt när du vill ändra information om leverantören. Anta att du t.ex. behöver ändra en leverantörs adress. Eftersom den förekommer på många platser kan du råka ändra den på en plats men glömma att ändra den på de andra. Genom att bara ha leverantörens adress på en plats undviker du det problemet.

När du utformar din databas bör du alltid försöka undvika att nedteckna en viss uppgift flera gånger. Om du märker att samma information upprepas på flera ställen, t.ex. en viss leverantörs adress, så bör du placera den informationen i en separat tabell.

Anta slutligen att Coho Winery bara levererar en produkt och att du vill ta bort produkten men behålla leverantörens namn och adressinformation. Hur tar du bort produktposten utan att även förlora leverantörsinformationen? Det går inte. Eftersom varje post innehåller information om en produkt samt information om en leverantör, går det inte att ta bort den ena utan att ta bort den andra. För att hålla dessa data separerade delar du upp tabellen i två tabeller: en för produktinformation och en annan för leverantörsinformation. När du tar bort en produktpost ska endast information om produkten tas bort – inte information om leverantören.

När du har valt det ämne som en tabell ska representera, så ska kolumner i den tabellen endast innehålla information om det ämnet. En produkttabell ska t.ex. bara innehålla information om produkter. Eftersom leverantörens adress är information om leverantören och inte information om produkten, så hör den hemma i tabellen med leverantör.

Överst på sidan

Omvandla informationsobjekt till kolumner

För att bestämma kolumnerna i en tabell bestämmer du vilken information du behöver spåra om ämnet som registrerats i tabellen. För tabellen Kunder innehåller exempelvis namn, adress, ort-delstat, skicka e-post, hälsningsfras och e-postadress en bra startlista med kolumner. Varje post i tabellen innehåller samma uppsättning kolumner så att du kan lagra information om namn, adress, ortsstatus, skicka e-post, hälsning och e-postadress för varje post. Adresskolumnen innehåller till exempel kundernas adresser. Varje post innehåller data om en kund och adressfältet innehåller adressen till kunden.

När du har fastställt den första uppsättningen kolumner för varje tabell kan du förfina kolumnerna ytterligare. Det är till exempel vettigt att lagra kundnamnet som två separata kolumner: förnamn och efternamn, så att du kan sortera, söka och indexera bara för de kolumnerna. På samma sätt består adressen faktiskt av fem separata komponenter, adress, ort, region, postnummer och land/region, och det är också vettigt att lagra dem i separata kolumner. Om du till exempel vill utföra en sökning, filtrera eller sortera efter tillstånd behöver du den tillståndsinformation som lagras i en separat kolumn.

Du bör även fundera på om databasen enbart kommer innehålla information om inrikeskunder, eller om den även kommer innehålla internationella kunder. Om du planerar att lagra internationella adresser är det bättre om du har kolumnen Region jämfört med kolumnen Län, eftersom en kolumn med regioner kan innehålla både svenska län och andra länders olika regioner. På liknande sätt är kolumnen Postnummer bättre än kolumnen Zip Code om du ska lagra adresser från fler länder än USA.

I följande lista finns några tips för att bestämma vilka kolumner du behöver.

• Ta inte med beräknade data    

  I de flesta fall bör du inte lagra resultat från beräkningar i tabeller. Du kan i stället låta Access utföra beräkningarna när du vill visa resultatet. Antag t.ex. att det finns en rapport med namnet Beställda produkter, där delsummorna för beställda enheter i varje produktkategori från databasen visas. Det finns dock ingen kolumn med en delsumma av beställda produkter i någon av tabellerna. I stället innehåller produkttabellen en kolumn med Beställda enheter där antalet beställda enheter lagras för varje produkt. Access beräknar delsumman utifrån dessa data varje gång du skriver ut rapporten. Själva delsumman ska inte lagras i en tabell.

• Lagra informationen i dess minsta logiska delar    

  Du kan frestas att ha ett enda fält för fullständiga namn eller för produktnamn tillsammans med produktbeskrivningar. Om du kombinerar mer än en typ av information i ett fält är det svårt att hämta enskilda fakta senare. Försök att dela upp information i logiska delar. Du kan till exempel skapa separata fält för för- och efternamn, eller för produktnamn, kategori och beskrivning.

När du justerat datakolumnerna i tabellerna väljer du en primärnyckel för varje tabell.

Överst på sidan

Ange primärnycklar

Varje tabell bör ha en kolumn eller uppsättning kolumner som unikt identifierar varje rad som lagrats i tabellen. Detta är ofta ett unikt ID-nummer, t.ex. ett anställningsnummer eller ett serienummer. I databasterminologi heter det att den här informationen är tabellens primärnyckel. Access använder primärnyckelfält för att snabbt koppla samman data från olika tabeller och sammanställa dessa data åt dig.

Om du redan har en unik identifierare för en viss tabell, t.ex. ett produktnummer som unikt identifierar varje produkt i katalogen, så kan du använda den identifieraren som tabellens primärnyckel, men bara om värdena i den här kolumnen alltid kommer vara olika för varje post. Du får inte förekomma dubblettvärden i en primärnyckel. Använd t.ex. inte personers namn som primärnyckel, eftersom namn inte är unika. Det kan lätt hända att du har två personer med samma namn i en viss tabell.

En primärnyckel måste alltid ha ett värde. Om värdet för en kolumn kan tänkas tas bort eller bli okänt (värdet saknas) vid något tillfälle, så kan inte den kolumnen användas som komponent i en primärnyckel.

Du bör alltid välja en primärnyckel vars värde inte kommer ändras. I databaser med flera tabeller kan en tabells primärnyckel användas som en referens i andra tabeller. Om primärnyckeln ändras måste ändringen också tillämpas överallt där det förekommer referenser till nyckeln. Om du använder en primärnyckel som inte kommer ändras, så minskar du risken att primärnyckeln kommer ur synk med andra tabeller som refererar till den.

Ofta används ett godtyckligt unikt nummer som primärnyckel. Du kan t.ex. tilldela varje beställning ett unikt ordernummer. Det enda syftet ordernumret har är just att identifiera en order. När det väl har tilldelats ändras det aldrig.

Om du inte har kommer att tänka på någon kolumn eller uppsättning kolumner som kan fungera bra som primärnyckel, så kan du överväga att använda en kolumn med datatypen Räknare. När du använder datatypen Räknare tilldelas varje post ett värde automatiskt. En sådan identifierare innehåller ingen egentlig information, ingenting som beskriver raden den representerar. Informationslösa identifierare är perfekta att använda som primärnycklar eftersom de inte ändras. Det är mer troligt att en primärnyckel som innehåller information om en rad – t.ex. ett telefonnummer eller en kunds namn – kommer att ändras, eftersom den faktiska uppgifter själv kan komma att ändras.

1. En kolumn med datatypen Räknare fungerar ofta bra som primärnyckel. Inga två produkt-ID:n är identiska.

I vissa fall kanske du vill använda två eller flera fält som gemensamt utgör en tabells primärnyckel. Exempelvis skulle en tabell med orderinformation, som innehåller radspecifikationer för order, kunna använda två kolumner i sin primärnyckel: Order-ID och Produkt-ID. När en primärnyckel består av flera kolumner kallas den för en sammansatt nyckel.

I en databas för produktförsäljning kan du skapa kolumner med datatypen Räknare i varje tabell och använda dem som primärnycklar: Produkt-ID för tabellen Produkter, Order-ID för tabellen Order, Kund-ID för tabellen Kunder och Leverantörs-ID för tabellen Leverantörer.

Överst på sidan

Skapa tabellrelationer

Nu när du har delat upp din information i tabeller behöver du kunna sammanställa informationen på ett meningsfullt sätt. Följande formulär innehåller t.ex. information från flera tabeller.

1. Informationen i det här formuläret kommer från tabellen Kunder ...

2. … tabellen Anställda …

3. … tabellen Order …

4. … tabellen Produkter …

5. … och tabellen Orderdetaljer.

Access är ett relationsbaserat databashanteringssystem. I en relationsdatabas delar du upp informationen i separata, ämnesbaserade tabeller. Sedan använder du tabellrelationer för att sammanställa informationen vid behov.

Överst på sidan

Förfina designen

När du har de tabeller, fält och relationer som du behöver bör du skapa tabellerna och fylla dem med exempeldata och sedan prova att arbeta med informationen genom att skapa frågor, lägga till nya poster m.m. Genom att göra det kan du identifiera potentiella problem. Exempelvis kan du behöva lägga till en kolumn som du glömde att infoga under designfasen, eller spå har du kanske en tabell som du borde dela upp i två tabeller för att undvika dubblettinformation.

Kontrollera att du kan använda databasen för att få de svar du vill ha. Skapa utkast av formulär och rapporter, och kontrollera om de visar de data du förväntar dig. Leta efter onödig dubblering av data, och ändra designen för att eliminera den om du hittar den.

När du provar din första version av databasen kommer du antagligen upptäcka att det finns utrymme för förbättring. Här är några saker att kontrollera:

• Har du glömt några kolumner? I så fall, hör den informationen hemma i de befintliga tabellerna? Om det rör sig om information om något annat, så kanske du måste skapa en ytterligare tabell. Skapa kolumner för alla informationsobjekt som du behöver spåra. Om informationen inte kan beräknas utifrån andra kolumner, så är det sannolikt att du behöver en ytterligare kolumn för den.

• Finns det några överflödig kolumner som kan beräknas utifrån befintliga fält? Om ett informationsobjekt kan beräknas utifrån andra befintliga kolumner – t.ex. ett rabatterat pris som beräknas utifrån det ordinarie priset – så är det oftast bättre att göra just det och undvika att skapa ny kolumn.

• Anger du dubblerad information upprepade gånger i någon av dina tabeller? I så fall behöver du antagligen dela upp tabellen i två tabeller med en 1:N-relation till varandra.

• Har du tabeller med många fält, ett begränsat antal poster och många tomma fält i enskilda poster? I så fall bör du fundera på att ändra tabellens design så att den har färre fält och fler poster.

• Har alla informationsobjekt brutits ned i sina minsta användbara delar? Om du behöver rapportera, sortera, söka och beräkna utifrån ett informationsobjekt, så lägger du objektet i en egen kolumn.

• Innehåller varje kolumn ett faktum om tabellens ämne? Om en kolumn inte innehåller information om tabellens ämne, så hör den hemma i en annan tabell.

• Representeras alla relationer mellan tabeller, antingen av gemensamma fält eller av en tredje tabell? 1:1- och 1:N-relationer kräver gemensamma kolumner. Många-till-många-relationer kräver en tredje tabell.

Tillämpa normaliseringsregler

Nästa steg i designarbetet kan vara att tillämpa databasnormaliseringsregler (kallas ibland endast för normaliseringsregler). De här reglerna används för att ta reda på om tabellerna är strukturerade på rätt sätt. Processen att tillämpa regler på databasdesignen kallas för att normalisera databasen, eller bara normalisering.

Normalisering är mest användbart när du redan har representerat alla informationsobjekt och har skapat en preliminär design. Tanken är att du ska kunna se till att du har delat upp dina informationsobjekt mellan lämpliga tabeller. Det som inte går att göra med normalisering är att se till att du har de rätta dataobjekten från början.

Reglerna tillämpas i en följd, och i varje steg säkerställs att designen producerar någon av de som kallas för de ”normalformerna”. Fem normalformer är allmänt accepterade – från den första normalformen till den femte normalformen. I den här artikeln redogör vi för de tre första av dem, eftersom det är allt som krävs för flesta databasdesignerna.