Projekt Database, Gruppe 4A
!
0!
Projekt 1, 3. Semester
DATABASE
Klasse MulA13
!
Gruppenummer: A4
Projekt Database, Gruppe 4A
!
1!
Fakta-ark
Klasse MulA13, Gruppenummer: A4
Gruppemedlemmer:
!
Amalie Ardahl Skøtt
http://amalieardahl.dk/3rd-semester-1st-project.html
[email protected]
!
!
!!
Sofie Roug Jensen
http://mul37.itkn.dk/portfolio/database.html
[email protected]
Gitte Skogstad
http://mul12.itkn.dk/eksamensprojekt/portfoliohtml/showroom_3
_semester.html
[email protected]
!
!
Projekt Database, Gruppe 4A
!
Indholdsfortegnelse:
Fakta ark
side
1
Indholdsfortegnelse
side
2
Indledning
side
3
Product-Breakdown-Structure
side
4
Ganttkort
side
5
ER-diagram
side
6
Attribut skema
side
8
UC
side
8
Filtrering af varer, Id: UC-3
side 10
Kundelogin, Id: UC-2
side 11
Produkt og kurv, Id: UC-1
side 12
CRUD diagram
Navigationsdiagram
SQL
side 14
side 14
side 15
Konklusion
side 17
!
2!
Projekt Database, Gruppe 4A
!
3!
Indledning:
Dette projekt skal udfordre vores viden inden for modellering og SQL kodning. Disse
to elementer vil i sidste ende munde ud i et produkt der fungerer som backend del til
en webshop. Vi har valgt at bruge virksomheden Designersmarket der sælger dametøj,
som udgangspunkt for vores projekt. Databasen kommer derfor til at indeholde
entiteter der kendetegner den måde man finder tøj på bl.a. ud fra størrelser og
kategorier. Rapportens indhold er bygget op efter vores PBS da det er det mest
naturlige når man læser den.
!
Projekt Database, Gruppe 4A
!
PBS: Product-Breakdown-Structure
Product Breakdown Structure gik vi i gang med det samme, PBS bruges til at få hul
på opgaven og få styr på hvilke opgaver der ligger i projektet/produktet.
Gennem PBS finder man frem til en mængde arbejdsopgaver der skal føres videre til
Ganttkortet for en strukturering af opgaven og dens tisforløb.
Modellering + analyse
1) PBS, opgaver der skal udføres i projektet.
2) Ganttkort, tidsestimering af opgaver
Logical
3) ER-diagram 3. Normalform (NF)
4) Tabel med attributter
5) UC-Model
6) Beskrivelse af 3 UC i detaljer
7) CRUD, tabel over handlingsfunktioner
8) Navigation, Htmlside
Fysisk SQL
9) Velfungerende database med SQL-statement som kan fremvises.
10) Html, java-script, PHP, 1
11) Sitet samles2
Dokumentation, præsentation og rapport
12) rapport i Word?
13) Præsentation d. 19.9. i klassen
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
1!Punkt!10!er!fjernet,!da!dette!ikke!er!et!krav!i!opgaven!
2!Punkt!12!er!fjernet,!da!dette!ikke!er!et!krav!i!opgaven!
!
4!
Projekt Database, Gruppe 4A
!
5!
Ganttkort:
Ganttkort: Vi har valgt at benytte Ganttkort til vores strukturering af opgaven.
Vi har inddelt opgaverne med hjælp af PBS. Derefter har vi placeret arbejdsopgaverne
i skemaet og har lavet et estimat over tidforbruget på de enkelte opgaver.
Ganttkortet kan undervejs justeres som vi også har måtte gøre i dette projekt.
I starten af et projekt og i et projekt der indeholder kendte og ukendte faktorer kan det
ikke undgås at der sker ændringer i tidsplanen. Nedenfor vil du se det første Ganttkort
nr. 1, Ganttkortet her viser at vi bl.a. har medregnet tid til at samle My-SQL og PHP,
Java-script i en htmlfil dette er taget væk igen da det ikke var et krav til opgaven..
Ganttkort nr. 1
Ganttkort nr. 2 nedenfor viser bl.a. denne ændring
!
Projekt Database, Gruppe 4A
!
6!
ER diagram
Tanker omkring modellering af database
Inden man laver selve databasen, er det er vigtigt at bruge noget tid på at modellere strukturen
for den. Gør man ikke det, kan man risikere at lave en masse fejl i databasen og det tager lang
tid at ændre på. Man får også et godt overblik over hvilket indhold der er nødvendigt, og hvad
der er unødvendigt. Til at modellere databasen bruger man et ER diagram som indeholder
informationer om hvilke entiteter den skal indeholder samt deres relationer til hinanden.
Derudover finder vi også ud af hvilke attributter entiteterne skal indeholde.
Arbejdet med ER diagram
Først og fremmest har vi været inde og kigge på den hjemmeside der i forvejen er tilknyttet
den virksomhed vi har valgt (Designers Market). De har en simpel hjemmeside med en
webshop hvor man kan se produkter, tilføje til kurven samt købe. Vi har herefter besluttet
hvilke entiteter vi mener er vigtige i vores database. Vi lægger ud med de to entiteter vi har
fået tildelt i opgaven (Customers og Products). Vi har fjernet og tilføjet nogle attributter til
disse to tabeller for at den passer til vores virksomheds kriterier. Dernæst har vi tilføjet
Orders, Orderdetails, Colors og Sizes. Vi begynder herefter at lave relationerne mellem
entiteterne for at finde ud af at vi har lavet nogle fejl i diagrammet. Når vi laver en mange til
mange relation mellem Products og Orders laver den automatisk en entitet der hedder
Orders_has_Products. Denne ligner tilnærmelsesvis Orderdetails hvilket får os til at slette den
og arbejde videre med Orders_has_Products. Vi vælger bare at ændre navnet på den så den
hedder Orderdetails. Efter en grundig gennemgang af alle entiteterne må vi konkludere at den
bliver for kompleks hvis vi ikke sletter colors. Vi beholder Sizes og laver en til en relation
mellem den og Orderdetails.
Dette er første udgave af vores ER diagram
!
Projekt Database, Gruppe 4A
!
7!
1. NF
Første Normal Form bliver opfyldt når grupper af data ikke bliver gentaget. Har man en tabel
der indeholder samme slags data under to forskellige navne er 1. NF ikke opfyldt. I vores
første udgave af ER diagrammet er 1. NF ikke opfyldt da vi har en gentagelse i entiteten
‘Orderdetails’. Den indeholder både OrderID samt OrderNumber. 2 attributter der i
virkeligheden indeholder samme data. Vi har derfor fjernet OrderNumber og bibeholder
OrderID. I andre tilfælde kunne man komme ud for at man var nødt til at lave en ny entitet for
at holde styr på samme slags data.
2. NF
ER diagrammet er på 2. NF når 1. NF er opfyldt. Derudover skal alle attributter i tabellen
være fuldt afhængig af primærnøglen. Der må derfor ikke være attributter såsom price i
‘Orderdetails’ fordi den kun er afhængig af den ene primary key, som i dette tilfælde er
ProductdID. Quantity derimod er fuldt afhængig af alle tre primærnøgler og kan derfor blive i
‘OrderDetails’.
3. NF
Diagrammet er på 3. NF når 1. og 2. NF er opfyldt. Ingen attributter må være afhængig af en
anden. I vores ER diagram har vi i entiteten Customer både zip og city. For at opfylde 3. NF
har vi oprettet en ny tabel til disse to attributter og kaldt entiteten ‘Zipcodes’. Zip er nu
Primary Key og City er attribut og fuldt afhængig af Zip. Vi har gjort det samme med Status.
Vi havde i starten en masse forskellige muligheder for status på et produkt. fx. shipped, paid
og ordered. Disse attributter er afhængige af hinanden og vi har derfor lavet en tabel og kaldt
entiteten for Status. Alle attributter er afhængige af Primary Key som er StatusID.
Dette er vores færdige udgave af ER diagrammet.
!
Projekt Database, Gruppe 4A
!
8!
Attribut skema
UC
Vi har valgt at bruge use cases da vi mener, at det ville være den bedste måde at formidle
vores tanker og idéer med denne model og dertil hørende beskrivelser. Vores model
indeholder flere actions som kunden eller administratoren bliver inddraget.
I modellen er det illustreret hvilke actions vores database kan muliggøre og hvilke aktører der
er aktive i de forskellige actions. Det skal bl.a. være muligt for brugeren at oprette en bruger
og derefter kunne logge ind på siden i forbindelse med evt. køb.
Derudover skal det være muligt for brugeren at finde produkter ud fra specifikke kriterier ved
at bruge filtrerings funktionen. Afslutningsvist skal brugeren kunne lægge varer i kurven og
derefter kunne redigere i antal og slette varer når de er inde i selve kurven.
Administratoren er den anden aktør og har som sådan ikke noget at gøre med de ovenstående
scenarier som kunden kommer ud for, da det er SQL statements der skal styre disse, på nær
oprettelse af brugeroprettelsen. I denne action skal administratoren have mulighed for at slette
en bruger og evt. bruge informationer som brugeren kommer med til fx shipment af et
!
Projekt Database, Gruppe 4A
!
9!
produkt. Administratoren skal også kunne redigere, slette og oprette nye produkter i shoppen
så den altid er fuldt opdateret.
Vi har lavet tre detaljerede beskrivelser fra vores use case model som går i dybden med vores
intention for hver action. Den første beskriver brugerens oplevelse med loginfunktionen.
Denne funktion vil være tilgængelig på alle underside samt forside men ikke være nødvendig
at gennemføre for at se på varer eller tilføje til kurv. Først ved betaling vil der være et krav
om login. Dette betyder at brugeren ikke føler sig bundet og let kan shoppe i fred og ro inden
personen kommer til checkout.
Den anden beskrivelse drejer sig om filtrering på websitet som skal gøre det muligt at finde
tøj på kryds og tværs vha. at stille kriterier op i form af checkboxe. Disse kan fx udgøre
størrelser og kategorier. Denne action vil altså gøre det muligt for brugeren at blive ledt hen
til det ønskede produkts side.
I den sidste beskrivelse går vi i dybden med det at lægge et produkt i kurven. Dette skal være
muligt fra produktsiden. Derudover skal brugeren som sagt kunne redigere i antal og evt.
slette et produkt. I slutningen af denne use case vil brugeren have mulighed for at komme til
login eller direkte til betaling hvis brugeren allerede er logget ind på sin bruger.
Log!on!
Filtrer!
Kunde!
Produkt!+!
kurv!
CRUD!
kunde!
CRUD!
produkt!
!
Admin!
Projekt Database, Gruppe 4A
!
10!
Navn: Filtrering af varer
Id: UC-3
Beskrivelse
Det skal være muligt at filtrere varer ud fra kriterier, som f.eks. størrelse og kategori.
Mål
Det skal være nemmere at finde produkter ud fra filtrering, som kun viser bestemte
produkter.
Starttilstande
Man skal være på forsiden eller på produktsiden, for at filtreringen kommer frem.
Man kan også være på et specifikt produkt.
Intet krav om at være logget ind.
Hyppighed
Hyppigheden er meget høj, op til 20 gange per unik besøgende (antagelse). Antallet af
filtreringer kommer også an på, hvor mange produkter og filtre, der er.
Forventet forløb
Use case begynder når kunden trykker I select boxe, for at vælge filtre, produkterne
skal filtreres i.
Produkterne bliver vist, og hvis kunden ønsker det, kan kunden klikke den I kurven.
Use case ender når produkterne er blevet filtreret og vist efter kundens ønske.
Sluttilstande
Use case slutning nr. 1: En side med filtrerede produkter bliver vist.
Use case slutning nr. 2: Kunden har lag noget I kurven, og det kan starte en anden use
case.
!
Projekt Database, Gruppe 4A
!
11!
Aktører
1) Kunden (filtrerer varer ud fra kriterier)
2) Administratorer opdaterer produkter og filtre, som bruges I filtreringen.
Efterfølgende Use Cases
Klikke I kurv (køb), hvor indholdet kommer over I kurven.
Navn: Kundelogin
Id: UC-2
Beskrivelse
Det skal være muligt at logge ind som eksisterende bruger, hvorefter
kontaktoplysninger bliver hentet.
Mål
Login lykkes. Når man er logget ind, gemmes ens kontaktoplysninger, så det gør det
nemmere for brugeren, og brugeren kommer igen.
Starttilstande
1. Man kan godt logge ind når man åbner siden, men man kan også vente til
check out (kurven).
2. Man skal være oprettet som bruger for at kunne fuldføre et login
Hyppighed
Hyppigheden er ca. 1 gang per køb.
Forventet forløb
1. Use case begynder når kunden åbner siden og logger ind med det samme.
2. Use case ender når kunden er logget ind.
!
Projekt Database, Gruppe 4A
!
12!
Alternativt forløb
1) I “The Happy Path”/Basic Course punkt 2) kan ende med, at kunden ikke kan
logge ind. Dette kan skyldes forskellige faktorer:
a. Kunden er ikke oprettet
b. Kunden har opgivet et forkert brugernavn
c. Kunden har opgivet et forkert password
d. Kunden har opgivet en forkert kombination af password og brugernavn
e. Loginformularen er case sensitive og kunden har ikke taget højde for store
og små bogstaver i sit login.
Sluttilstande
1. Use case slutning nr. 1: Login lykkes.
2. Use case slutning nr. 2: Login mislykkes, henvisning til loginhjælp.
Aktører
1. Kunden (som logger ind)
Navn: Produkt og kurv
Id: UC-1
Beskrivelse
Det skal være muligt at klikke køb på en vare, hvorefter varen ligger I kurven.
Mål
Varen skal flyttes fra produkter til kurven (orderDetails).
!
Projekt Database, Gruppe 4A
!
Starttilstande
Intet krav om at være logget ind for at lægge varer I kurven.
Intet krav om at være oprettet som bruger
Produktet skal være synligt på hjemmesiden inden den kan lægges I kurven
Produktet skal have en købknap.
Man skal være inde på en produktside.
Hyppighed
Hyppigheden er meget høj, anslået omkring 6-10 gange pr køb x antal køb.
Forventet forløb
Use case begynder når kunden trykker på knappen for at lægge produktet I kurven.
Produktet ligger I kurven.
Kunden går ind på kurven, ser de ilagte varer.
Use case ender når kunden går til betaling.
Sluttilstande
Use case slutning nr. 1: browseren lukkes. Ingenting sker.
Use case slutning nr. 2: varen slettes fra kurven.
Use case slutning nr. 3: Varen købes og betales over siden.
Aktører
1. kunden (klikker produktet I kurven, kan opdatere antal og størrelse)
Efterfølgende Use Cases
Login af eksisterende burger (I forbindelse med betaling)
!
13!
Projekt Database, Gruppe 4A
!
14!
CRUD diagram
CRUD står for Create, Read, Update og Delete. Det er altså de handlinger der kan
foretages i hver entitet når en usecase action udføres. Vores diagram har altså tre use
cases som ses i den lodrette kolonne samt alle vores entiteter i den vandrette kolonne.
Ud fra disse informationer må vi så spørge os selv hvad der sker i vores entiteter når
en action udføres. I diagrammet kan i fx se at hvis en bruger lægger en varer i kurven
vil entiteterne; Orderdetails, Sizes, Products og Product_has Sizes bliver påvirket af
den pågældende action. Orderdetails vil eksempelvis få oprettet/læst/opdateret/slettet
en kolonne. Derfor har den fået CRUD. CRUD diagrammet hjælper os til at forstå
hvilke entiteter der bliver påvirket i forskellige sammenhænge og er en sikkerhed for
at vi ikke har lavet fejl i hele databasens struktur.
Navigationsdiagram
Vi har valgt at lave navigationen på webshoppen meget flad i strukturen. Dette
skyldes at vi vil gøre det så let som muligt for brugeren at komme i gang med at
shoppe. Der skal ikke være for mange klik før brugeren kommer frem til de ønskede
undersider. Dette har vi valgt at eksemplificere ved at lave et diagram der viser hvilke
trin man kommer igennem afhængigt af hvad man vil på siden. Brugeren starter på
index siden, hvor det skal det være muligt at logge ind hvis dette ønskes. Fra index
!
Projekt Database, Gruppe 4A
!
15!
siden kan man klikke på en kategori fx. kjoler hvorefter man kommer ind på
produktsiden med kjoler. På alle undersider inklusiv indexsiden skal filtrerings
funktionen være synlig i siden. Dette udmønter sig i et filtrerings resultat på en ny
side der viser produkterne ud fra kriterierne. Fra index siden skal det altså også være
muligt at komme direkte til et filtrerings resultat. Fra alle sider skal det også være
muligt at komme til kurven. Vores navigation vil forhåbentlig resultere i et højt salg
da det er meget let for brugeren at navigere rundt i arkitekturen på webshoppen.
SQL
På baggrund af det materiale vi har samlet under modelleringsfasen, i form af ER diagram,
Attributskema, Use Cases og CRUD diagram, kan vi efterfølgende gå i gang med SQL delen.
Først og fremmest opretter vi tabellerne i den rækkefølge som ER diagrammet bestemmer.
Man starter med at oprette de tabeller som ikke bliver refereret til. I dette tilfælde opretter vi
derfor Status, Zipcodes og Categories. Vi kan ikke oprette de andre tabeller først da de vil
indeholde referencer til andre tabeller som endnu ikke er oprettet og derfor ikke være gyldige
når man kører scriptet på serveren.
Ovenfor vil du se et eksempel på oprettelse af tabel i SQL scriptet.
Øverst i statement gør man opmærksom på hvad man vil foretage, i dette tilfælde skriver man
CREATE TABLE for at indikere at der skal oprettes en ny tabel. Dernæst kommer alle
attributterne med deres values og eventuelle Primary Keys og Foreign Keys. Kigger man
eksempelvis på customerId vil man kunne se at den indeholder heltal fordi vi har skrevet INT.
Derudover sætter den selv id ind i kolonnen i opadgående rækkefølge fordi vi har sat
AUTO_INCREMENT på, som udfører dette for os. Sidst men ikke mindst har vi skrevet
NOT NULL for at den ved at den skal være eksisterende.
!
Projekt Database, Gruppe 4A
!
16!
I billedet ovenfor vil vi demonstrere et INSERT statement som vi bruger når vi skal sætte data
ind i en tabel. Når alle tabellerne er oprettet i den rigtige rækkefølge, kan vi begynde at sætte
data ind og oprette kolonner under de forskellige tabeller. I tabellen Zipcodes har vi fx sat
postnumre og byer ind fra størstedelen af Sjælland blot for at demonstrere dens funktion.
INSERT INTO betyder at vi vil indsætte data i en tabel. Derefter skriver vi hvilken tabel det
skal sættes ind i, i dette tilfælde Zipcodes. Til sidst sætter vi værdierne ind efter VALUES.
Som administratorer sætter vi ikke selv data i Orders, Orderdetails og Product_has_sizes da
de først vil blive genereret når en bruger interagere i frontend delen. Men vi har lavet
eksempler på hvordan SQL scriptet ser ud når brugeren udfører disse handlinger som vores
Use Cases beskriver.
Ovenfor ses eksempel på Login funktionen. Ud fra denne vil vi demonstrere at kunden får lov
til at logge ind hvis kombinationen af email og telefonnummeret som brugeren oplyser i login
felterne findes i den samme række under Customers tabellen. Hvis kombinationen bliver
godkendt får vi vist det unikke CustomerId samt firstname vil blive hentet frem fra tabellen.
Hvis kombinationen ikke findes vil der komme fejlmeddelelse der vil lede brugeren videre til
oprettelse af ny bruger.
I eksemplet ovenfor vil vi vise hvad der sker når brugeren klikker et produkt i kurven. Når
dette sker henter SQL scriptet informationerne; OrderId, ProductId, Quantity samt SizeId.
!
Projekt Database, Gruppe 4A
!
17!
Dette bliver indsat som ny række i tabellen. Ordren skal allerede eksistere før man kan udføre
denne handling. Derfor bliver der lavet en ny ordre når brugeren logger ind. Dette
eksemplificeres i det øverste statement IF NOT EXISTS.
Konklusion
I dette projekt har vi lært hvor vigtigt det er at have styr på modelleringen af databasen inden
den bliver kodet i SQL i Workbench. Har man lavet store fejl kan det tage lang tid at lave
ændringer når databasen først er oprettet. Vi har haft problemer undervejs med mange af
delelementerne, bl.a. Use Case som vi havde svært ved at sætte sammen men har efterhånden
fået en bred forståelse for projektets indhold. Vi føler dog stadig at der mangler en
helhedsforståelse mellem frontend og backend delen, der i sidste ende vil skabe et færdigt
produkt man kan bruge til noget. Dette er vi dog sikre på at vi nok skal nå at få lært på dette
semester.
!