Titel: Database 1. projekt - 3. semester Multimediedesigner uddannelsen - Lyngby

Titel: Database 1. projekt - 3. semester Multimediedesigner uddannelsen - Lyngby

Faktaark Gruppe 8: Titel: URL: Database http://www.graphicweb.dk/3sem.html Janni Cold mail: janni@cold-design.dk www.cold-design.dk Hold: Clmul-b12e 3. semester efterår 2013 Vejledere: Tue Becher Thomas Bügel Hartmann Ivan Rosenvinge Frederiksen Morten Møller Nielsen mail: morten.moeller.nielsen@gmail.com www.weblabs.dk Jens Gaardbo mail: gaardbo@hotmail.dk www.gaardbodesign.dk Mikael Lund Kristensen mail: mlk@graphicweb.dk www.graphicweb.dk

Indholdfortegnelse Indledning... s. 1 Problemformulering... s. 1 Afgrænsning... s. 1 Projektet... s. 2 Gruppekontrakt... s. 2 Planning sheet... s. 3 Sprint 1... s. 4 Burndown chart... s. 5 Analyse og dokumentation... s. 6 ER diagram... s. 6 Attributtabel... s. 7 Use-case model... s. 8 Use-cases... s. 9 Navigationsdiagram... s. 11 CRUD... s. 12 MySQL queries... s. 13 Konklusion... s. 14 Litteraturliste... s. 14

Indledning Hummel planlægger i 2014 at relanchere hacky sacken under navnet Wacky Zack. De ønsker at tilknytte en e-shop til deres site. Hummel har derfor hyret os til at lave en database til deres online shop. Databasen skal indeholde: kundekartotek, ordrer, produkter samt information om butikker. Hummel - Firmaprofil Sportsmærket Hummel blev oprindeligt grundlagt i 1923 i Hamborg, Tyskland. I 1980 bliver firmaet 100% dansk ejet og bliver op gennem dette årti især forbundet med det danske fodboldlandshold, som de sponsorerer. Op gennem 1990 erne oplever Hummel økonomisk tilbagegang. Firmaet opkøbes i 1999 af finansmanden Christian Stadil, som ved hjælp af innovativ marketing, vender den økonomiske udvikling. Han skaber bl.a. en retro bølge ved at genintroducere de 70 er inspirerede Hummel dragter. Disse bliver et kæmpe hit verden over. Dette skyldes bl.a. at kendisser fra hele verden begynder at tage Hummel brandet til sig. Afgrænsning I denne opgave vil vi gøre rede for de metodiske og teoretiske overvejelser, der ligger til grund for vores opbygning af Hummels database til Wacky Zack hjemmesiden. Vi ser bort fra brugergrænseflader og designprincipper, og koncentrerer os udelukket om at analysere og dokumentere Hummels database. Ved hjælp af ER-model, UML, Use Cases, Attribute Table, CRUD matrix, navigations diagram og Flow-chart vil vi dokumentere hvorledes databasen fungerer. En grundig dokumentation gør det nemmere for andre udviklere, at implementere databasen i Hummels nuværende site. Vi indsætter information om kunder i databasen, og efterfølgende viser vi hvorledes en bruger kan interagere med vores database ved hjælp af use-case models og SQL statements. Problemformulering Hvordan kan vi lave en database til Hummel, der er analyseret og dokumenteret. Så der er mulighed for videre udvikling af deres databasesystem? 1

Gruppekontrakt for Databaseprojekt 3. semester (Janni Cold Holm, Jens Jákup Gaardbo, Mikael Kristensen og Morten Møller Nielsen) Hvor tit skal vi mødes? Vi aftaler indbyrdes ved slutningen af hvert møde, hvornår vi samles næste gang. Hvor lange skal møderne være? Mødernes længde er defineret i vores plan for projektet. Hvis deadlines skrider må alle gruppemedlemmer være forberedt på at sætte ekstra tid af til opgaven. Hvordan giver vi besked til hinanden, hvis vi er forhindret i at møde? Er man forhindret i at møde skriver man en SMS eller ringer til en fra gruppen. Alternativt kan man skrive i vores Facebook-gruppe. Hvad forventer vi at få ud af samarbejdet? Alle i gruppen er opsatte på at få etableret et godt samarbejde, hvor arbejdsbyrden er ligeligt fordelt. Derudover håber vi at kunne lære af hinanden. Hvor højt skal ambitionsniveauet være? Vi har alle en ambition om at at overholde deadlines og bestå. Overholdes ovenstående punkter ikke af et eller flere gruppemedlemmer tages det op på et møde i gruppen. Hvis problemerne fortsætter herefter medfører det eksklusion fra gruppen, hvorefter man må arbejde på egen hånd. En eksklusion iværksættes i samråd med de lærere, som er tilknyttet projektet. Janni Cold Morten Møller Nielsen Jens Gaardbo Mikael Lund Kristensen 2

Planning sheet For at opnå bedst muligt resultat, benyttes Scrum som udviklingsmodel. Det er vigtigt at samarbejdet er i højsæde og at der dagligt afholdes statusmøde. Vi har kun 1 sprint, grundet projektperiodens varighed. Alle har indflydelse Sprintet og der kan forekomme ændringer undervejs. Databaseprojekt Hummel Effort "Day 0" calculated using three time estimates (PERT) Story ID Task ID Story / Task Planned (A + 3*B + C) / 5 = M (C - A) / 5 = Sd Description Verify A B C M S d 1.0 Gruppemail 0,5 1 1,2 0,9 0,14 Afsending af mail til ans. lærer vedr. opl. om gruppens medlemmer Ved gennemlæsning 1.1 Kontrakt 0,5 1 1,2 0,9 0,14 Beskrivelse af konsekvenser ved udeblivelse el. Lign. som for negativ betydning for projektet Ved gennemlæsning 1.2 Tidsestimering 2 3,2 4 3,1 0,4 Projektforløbet inkl. samtlige aktiviteter I forløbet Ved gennemlæsning/udregning 1.3 Projektformulering 1 1,5 2 1,5 0,2 En indledende beskrivelse med de forventede slutmål Ved gennemlæsning 1.4 ER-model 3.NF 2 3 4 3,0 0,4 Udarbejde ER-model udfra projektkrav Ved gennemlæsning 1.5 Attribut-tabel 1,5 2 3 2,1 0,3 Uarbejde attributtabel i excel med alle entiteter Ved gennemlæsning 1.6 Use Case model 1,5 2 2,5 2,0 0,2 Model med ønskede handlinger for kunde og admin. Ved gennemlæsning 1.7 Flowchart 2,5 3 4 3,1 0,3 Flowchart med handlinger fra UC modellen Ved gennemlæsning 1.8 Navigationsdiagram 2 3 4 3,0 0,4 Navigationsdiagram over website (til orientering omkring placering af e- shop) Ved gennemlæsning 1.9 CRUD 2 2,5 3 2,5 0,2 Udarbejde CRUD skema = oversigt over SQL handlinger Ved gennemlæsning 1.10 SQL-kodning 4 5,2 6 5,1 0,4 Oprette database, tabeller, indtaste div. oplysninger Ved SELECT tjek 1.11 Rapport 5 6 6,5 5,9 0,3 1.12 Tjek + aflevering 1,5 2 3 2,1 0,3 Opsætte/indsætte udarbejdede emner, tilføje beskrivelser og udarbejde refleksion/afslutning Gennemlæse rapport, korrekturlæsning, rettelser, underskrifter og aflevrering Ved gennemlæsning Ved gennemlæsning 3

Sprint 1. Sprint 1. Database projekt Hummel Days in sprint / Effort left Story ID Story / Task Days 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Task ID Planned 35 33 31 28 26 24 21 19 16 14 12 9 7 5 2 0 Effort left 35 35 33 32 31 27 24 24 22 19 18 17 17 11 8 0 1.0 Gruppemail 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1.1 Kontrakt 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1.2 Tidsestimering 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 0 1.3 Projektformulering 2 2 2 2 1 1 1 1 0 0 0 0 0 0 0 0 1.4 ER-model 3.NF 3 3 3 3 2 1 1 1 0 0 0 0 0 0 0 0 1.5 Attribut-tabel 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 1.6 Use Case model 2 2 2 2 2 1 0 0 0 0 0 0 0 0 0 0 1.7 Flowchart 3 3 3 3 3 3 3 3 3 3 3 2 2 1 1 0 1.8 Navigationsdiagram 3 3 3 3 3 3 3 3 3 1 0 0 0 0 0 0 1.9 CRUD 3 3 3 3 3 3 3 3 3 3 3 3 3 3 1 0 1.10 SQL-kodning 5 5 5 5 5 5 5 5 5 5 5 5 5 2 1 0 1.11 Rapport 6 6 6 6 6 6 4 4 4 3 3 3 3 2 2 0 1.12 Tjek + aflevering 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 4

Burndown chart 40# Effort&le)& 35# 35# 35# 33# 33# 32# 30# 31# 31# 28# 27# 26# 25# 24# 24# 24# 21# 22# 20# 19# 19# 18# 16# 17# 17# 15# 14# 12# 10# 9# 11# 8# 7# 5# 5# 2# 0# 0# 1# 2# 3# 4# 5# 6# 7# 8# 9# Days&in&Sprint& 10# 11# 12# 13# 14# 15# 16# 5

3NF (Workbench) ER-model med UML notation, som visuelt beskriver strukturen i vores database. Ved at inddrage UML i vores projekt, gør vi brug af en international standard der tager hensyn til at kommende systemudviklere kan aflæse og forstå vores projekt. Det vil give kvalitet i projektet, at anvende kendte standarder. Attribute table På følgende side (8) vises samtlige tabeller fra vores database og hvilke tegn og datatyper de gør brug af. 6

Attribute table Entity Attributes Value Notes Datatype CUSTOMER cid 1 X Unique no. N cname a - Å Max. 30 char. AN caddress All char. Max. 35 char. AN (sectorid_fkey) 1 20 Unique no. (industry) N zip_fkey 1000-9999 Number N (SECTOR) sectorid 1 20 Unique no. (industry) N sectorname a - Å AN ZIPCODE zip 1000-9999 Number N city a - Å Max. 30 char. AN STORES sid 1 X Unique no. N sname a - Å Max. 30 char. AN saddress All char. Max. 35 char. AN zip_fkey 1000-9999 Number N STORE_HAS_PRODUCTS pno_fkey 1 X Unique no. N sid_fkey 1 X Unique no. N PRODUCT pno 1 X Unique no. N pname All char. Max. 30 char. AN price Currency Currency place_stock 1 500 Number N p_stock 1 500 Number N min_p_stock 0.5 200 Number N ORDERS_HAS_PRODUCTS ohp_id 1 X Unique no. N oid_fkey 1 X Unique no. N pno_fkey 1 X Unique no. N qnt 1 X Number N ORDERS oid 1 X Unique no. N cid_fkey 1 X Unique no. N odate Date Date status O or C Max. 1 char. A 7

Use-Case model I vores use-case modeller beskriver vi en række handlinger, som en kunde eller admin kan udføre i sin brug af af siden/databasen. KUNDE Søge produkt *1 Oprette/slette produkter *5 ADMIN Vælge produkt *2 Pris redigering *6 Registrering *3 Redigering i kundedatabase *7 Betaling (ekstern feature) Udtrække data til analyse *8 Følge ordre * Trafik analyse *9 8

Use Cases Brugerscenarier ses på efterfølgende flowcharts. Navn: Søge produkt + vælge produkt ID: *1+*2 Beskrivelse: Søge og sammenligne (kvalitet og pris) produkter. Valgte produkt(er) reseveres i lagerdatabase, hvorefter reservationen enten ændres til en ordre eller slettes. (funktionen skal desuden vise samlet sum af valgte produkter). Startbetingelser: Website er åbent og online. Slutbetingelser: (Hvis produkt skal købes) Pop-up vindue med titlen købsproces, som illustrerer oversit, antal og pris over valgte produkter. Aktør(er): Køber(e) Navn: Registrering ID: *3 Beskrivelse: Hvis ny kunde: Oprettelse af medlemskab/personlige opl. Hvis eksisterende kunde: Login indtastes og kundens opl. hentes. Startbetingelser: Købsprocess er igangværende (ID *¹ + *² er udført) Slutbetingelser: Pop-up vindue med indtastede opl. + adgang til næste fane i købsprocessen. Aktør(er): Køber(e) Navn: Følge ordre ID: *4 Beskrivelse: Efter bestilling af produkt, oplyses kunden om et ordreid, som benyttes til tracking af ordren indtil modtagelsen. Startbetingelser: Købsprocess er færdig - produkt er betalt. Slutbetingelser: Pop-vinduer der indikerer hvor ordren befinder sig i det øjeblik køber/bruger ønsker oplysningen.. Aktør(er): Køber(e) Navn: Oprette/slette produkter + pris redigering ID: *5+*6 Beskrivelse: Adgang til oprettelse eller sletning af produkter. Startbetingelser: Særlige adgangsrettigheder. Slutbetingelser: Online webshop er opdateret ift. produkter og priser. Aktør(er): Administrator(e) Navn: Redigering i kundedatabase ID: *7 Beskrivelse: Adgang til redigering i kundedatabasen (bl.a. fejl begået af kunden). Startbetingelser: Særlige adgangsrettigheder (til bl.a. nulstilling af password). Slutbetingelser: Kundedatabasen er opdateret. Aktør(er): Administrator(e) 9

Navn: Udtrække data til analyse ID: *8 Beskrivelse: Adgang til at udtrække analyse materiale til bl.a. salgsoptimering. Startbetingelser: Særlige adgangsrettigheder. Slutbetingelser: Håndterbar datasæt, der bl.a. illustrerer salg, priser, lagertal m.m. Aktør(er): Administrator(e) Navn: Trafik analyse ID: *9 Beskrivelse: Adgang til at udtrække analyse materiale til bl.a. brugernes surf-tid. Startbetingelser: Særlige adgangsrettigheder + forståelse for evt. Google analytics. Slutbetingelser: Håndterbar datasæt, der bl.a. illustrerer købstendenser. Aktør(er): Administrator(e) 10

Navigations diagram Her vises opbygningen af menuen på den hjemmeside, som vores database er tilknyttet. Forside Forside Tilbud Vilkår Kontakt Wacky Zacks T-Shirts Sko Merchandise Læg i Kurv Produktdetaljer Login Opret Ny Kunde Placer Ordre Track Ordre 11

CRUD CRUD diagrammet viser hvilke funktioner der skal være tilgængelige for at udføre handlingerne i kolonnen Entity proces. Create - Read - Update - Delete Entity Process Customer (Sector) Zipcode Stores Products Orders New Customer C CR CR C Delete Customer D RUD Change Customer Address RU CR RU Show Customer R R R R New Zipcode C New Store C RU Show Store Stock R R R New Product C Delete Product D RU Change Product U Show Product R Remove Product from Order U RU New Order RU R R RU C Delete Order U U D Change Order R U RU Show Order R R 12

MySQL Alle vores SQL queries er vedlagt, som SQL fil. Heri har vi skrevet forklarende kommentarer. Her følger et par eksempler på views vi har brugt. 13

Konklusion Efter et gnidningsfrit projektforløb har vi formået at udarbejde en database, som lever op til opgavens krav. Vi har dokumenteret vores arbejde med: ER-model, UML, Use Cases, Attribute Table, CRUD matrix, navigations diagram og Flow-chart. Dette projekt har givet os en forståelse for hvor vigtigt det er med en veldokumenteret analyse og schema, når en database skal implementeres og opretholdes fremadrettet. Litteraturliste Bøger Learn SQL in 10 minutes. Ben Forta. fourth edition. PEARSON education. 2013. ISBN: 9780672336072 Web http://www.w3schools.com/sql/default.asp 14