Projekt Database, Gruppe 4A. Projekt 1, 3. Semester D A T A B A S E. Klasse MulA13 Gruppenummer: A4

Transkript

1 Projekt Database, Gruppe 4A 0 Projekt 1, 3. Semester D A T A B A S E Klasse MulA13 Gruppenummer: A4

2 Projekt Database, Gruppe 4A 1 Fakta-ark Klasse MulA13, Gruppenummer: A4 Gruppemedlemmer: Amalie Ardahl Skøtt cph-as227@cphbusiness.dk Sofie Roug Jensen cph-sj193@cphbusiness.dk Gitte Skogstad _semester.html cph-gs52@cphbusiness.dk

3 Indholdsfortegnelse: Projekt Database, Gruppe 4A 2 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 side 14 Navigationsdiagram side 14 SQL side 15 Konklusion side 17

4 Indledning: Projekt Database, Gruppe 4A 3 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.

5 Projekt Database, Gruppe 4A 4 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 samles 2 Dokumentation, præsentation og rapport 12) rapport i Word? 13) Præsentation d i klassen 1 Punkt10erfjernet,dadetteikkeeretkraviopgaven 2 Punkt12erfjernet,dadetteikkeeretkraviopgaven

6 Ganttkort: Projekt Database, Gruppe 4A 5 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

7 ER diagram Projekt Database, Gruppe 4A 6 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

8 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.

9 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

10 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. Logon Filtrer Kunde Produkt+ kurv Admin CRUD kunde CRUD produkt

11 Navn: Filtrering af varer Id: UC-3 Projekt Database, Gruppe 4A 10 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.

12 Aktører Projekt Database, Gruppe 4A 1) Kunden (filtrerer varer ud fra kriterier) 2) Administratorer opdaterer produkter og filtre, som bruges I filtreringen. 11 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.

13 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).

14 Starttilstande Projekt Database, Gruppe 4A 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. 13 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)

15 CRUD diagram Projekt Database, Gruppe 4A 14 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

16 Projekt Database, Gruppe 4A 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. 15 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.

17 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 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.

18 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.