Webbshop - Databasen
Förord
I den här artikelserien kommer jag att fördjupa mig lite mer och förklara koden som ligger bakom och även hur jag har planerat databasen. Jag börjar med att beskriva lite grann om vad relationer är, sedan går jag in på modellering och normalisering. Sen visar jag hur själva databasen ser ut.Innehåll
»»
»
»
»
»
»
Relaterade artiklar
» En enkel webbshop
Relationer
En relation kan beskrivas som att två tabeller har ett gemensamt nyckelvärde.Kategorier som beskrivs senare är relaterad till Produkter. Det faktum att produkten har ett värde i kategoriID sätter upp en relation mellan just denna artikel och posten för kategorin.
De tre typerna av relationer
Relationer kan delas upp på tre typer, 1:1, 1:N och N:N.
1:1
Den enklaste (och den minst använda) relationen är 1:1. Den innebär att för varje post i en av tabellerna i relationen så finns det en enda motsvarande post i den andra tabellen som ingår i relationen.
1:N
Relationen 1:N fungerar så att en post i en tabell har många relaterade poster i en annan tabell.
Denna relation är den som använda mest i relationsdatabaser.
I vår databas finns det en 1:N relation mellan tabellen Kategorier och tabellen produkter.
Varje kategori kan vara relaterad till flera produkter.
N:N
I en N:N relation kan många poster i en tabell ha många poster i en annan tabell. Den strikta definitionen av en relationsdatabas medger inte relationer av typen N:N. Istället skapas en mellantabell som innehåller primärnycklarna från två tabeller som sekundärnyckel.
Detta skapar två 1:N relationer för mellanlagringstabellen, en för varje tabell i relationen N:N.
Normalisering av data
Processen vid modifiering av databasens struktur så att den helt motsvarar relationsmodellen kallas för normalisering. Målet för normaliseringen är att ta bort överflödig data från databasen. Under denna process görs den slutgiltiga databasen mer flexibel och kommer därmed bättre att kunna klara ändringar i dess struktur. Nu är bästa tillfället att se till att nya tabeller klarar att följa dessa rekommendationer.Normalisering består av följande process:
- Se till att fälten i varje tabell är unikt identifierade av tabellens primärnyckel
- Se till att varje fält innehåller endast en typ av information. Lagra t ex. inte postnummer och ort i samma fält
- Ta bort överflödiga data från tabellerna. Varje post i databasen ska innehålla unika data. Varje unik del av del av informationen ska lagras på en enda plats (med undantag för nyckelfält som har dubblerande värden i hela databasen)
- Ta bort upprepade gruppfält om det finns en möjlighet att flera fält kommer att läggas till i gruppen. Om t ex en tabell med information om kontaktpersoner innehåller ett hemtelefonnummer, ett nummer till arbetet, ett faxnummer och mobilnummer, kan det vara klokt att skapa en tabell som innehåller numret och en beskrivning av dess typ, tillsammans med en sekundärnyckel till kontaktpersonen med varje telefonnummer. För att lägga in nya typer av telefonnummer i framtiden är det bara att lägga till den nya telefonnummer typen till listan med nummer. Detta är därmed en databastrukturfråga eftersom du inte behöver ändra databasen för att åstadkomma detta.
Vad ska man börja med?
Det är en fråga som många ställer, vilken ände ska man börja i?Jag brukar börja med att modellera databasen på papper, där skriver jag upp vilka tabeller som jag tror kan behövas och vad de ska innehålla. En del kanske anser att det här är "overkill", dvs. för mycket jobb, men jag tycker att det är ett bra sätt att få överblick på databasen och hur den ska se ut. Jag gör även på samma sätt med sidorna, när jag sedan ska koda så kan jag enkelt se hur de olika sidorna ska länkas till varandra och även flödet i shopen.
Skissen kan se ut så här när jag är klar med den.
T ex.
Produkter = Tabellnamn
Produktnr = Tal, beskrivning = Text (255), pris, Tal (Valuta), kategoriId= tal.
Sedan gör jag samma sak med kategorier.
Kategorier = Tabellnamn
KategoriId = Räknare, KategoriNamn = Text (50)
En tabell som innehåller ordrarna måste vi också ha, och den ser ut så här:
Korg = Tabellnamn
KorgId = räknare, AnvId= Tal, ProdId = Tal, Antal = Tal, Spara = Ja/Nej, BestDatum = Datum/Tid (Datum ())
En tabell har vi kvar att göra, vi måste ju spara våra kunder också. Den tabellen ser ut så här:
KundId = Räknare, SessionID = Tal, Namn, Adress, PostNr, Ort, Epost, tel = Text på alla.
Skapa databasen
När jag har gått igenom mina skisser och är nöjd då sätter jag mig och kodar databasen.Eftersom 80 % av jobbet redan är klart så behöver jag bara skriva in de Tabellnamn, namn och datatyper som jag har valt. Jag kan till nästan 99 % vara säker på att databasen kommer att fungera. Nu har jag inte gått igenom hur man kodar databasen och det beror på att de olika databaser som finns ser olika ut när man kodar dem.
Varför ser databasen ut så här för?
Ni kanske undrar varför jag inte sparar kategorinamnet i tabellen med produkter och då kommer vi in på något som kallas redundans, relationer och även normalisering som beskrevs ovanför.Redundans, vad är det?
När man kodar databaser så pratar man om att man vill försöka undvika redundans.
Redundans brukar beskrivas som att man lagrar samma data flera gånger.
Men säger ni då, KategoriID lagras ju flera gånger?
Det stämmer och det beror på att tal tar upp mindre plats i databasen än vad text gör.
Ibland så kan man inte undvika redundans, men det är något man får ta ställning till när och om den problematiken dyker upp.
0 Kommentarer