Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Fact sheet

Indholdsfortegnelse Fact Sheet Gantt kort Valgt af virksomhed Brainstorm Attribut tabel ER-diagram Skitse MySQLWorkbench Er-diagram Dokumentation CRUD matrix Use Case Use Case 1: Use Case Use Case 2: Use Case Use Case 3: Use Case Use Case 4: ER-diagram til SQL koder ER-diagram til SQL koder Interaktioner Interaktioner Interaktioner Konklustion Litteraturliste 2 4 5 5 6 7 7 7 8 8 9 10 10 11 11 12 12 13 13 14 15 16 17 18 19 20

Gantt kort Vi startede med at lave et Gantt Kort, for at få overblikket over hvor meget vi skulle lave, samt for at få overblikket over vores tid, og hvordan vi bedst kunne bruge den. Der har været små justeringer undervejs. Derudover har vi fulgt Gantt kortet meget præcist. 4

Valg af virksomhed Brainstorm Første punkt i vores Gantt Kort var at lave en brainstorm over hvilket firma samt produkter, som vi ville arbejde med. Vores tanker gik blandt andet på, om det skulle være et eksisterende eller ikke eksisterende firma. Derudover hvor mange produkter vi ville have med. Vores valg blev Nespresso. Vi har valgt at tage to produktlinjer ind; Kaffemaskiner og kaffekapsler. Om virksomheden Nespresso systemet blev præsenteret i 1976 af en medarbejder fra Nestlé, Eric Favre. I 1996 grundlagde Nespresso processen for espresso på kapsler. Nespresso dyrker og tester kaffe på de bedste jordstykker som kaldes Gourmetkaffe. Kaffen udvælges af kvaliteten, metoden for dyrkning, høsten og behandlingen. Kaffebønnerne bliver altid håndplukket. 5

Attribut tabel Hvis vi kigger på vores bruger, som selvfølgelig er vores kunde, kan man se, at attributten 'Bruger_id' er UNIQUE. Dette betyder at et bruger_id kun kan optræde en gang. Gennem bruger id, som er en primær nøgle, vil man kunne se resterende oplysninger. 'Postnr_id' vil i vores 3. normalisering få en ekstern boks, således at man i databasen ikke skal skrive postnr. mange gange, men kan have dem registreret i en ekstern tabel. Under Produkt har vi igen et id. Dette id er dog ikke UNIQUE, da flere kunder godt kan vælge samme produkt i samme farve, og dermed få samme produkt_id. Under Ordre, har vi vigtige informationer, som leveringsdato m.m.. Her har vi også en attribut der hedder status, således at det kan ses, om ordren er i indkøbskurv eller betalt. Vi benytter datatyperne INT, VARCHAR og DATE. DATE benyttes til datoer, INT til hele tal som fx. Produkt_id og Ordre_id. Derudover benyttes VARCHAR til fx. tekst og tegn. 6

ER-diagram Skitse Her ses vores ER-diagram som skitse og fra MySQLWorkbench. Næste side dokumentere diagrammet. I vores zip-fil vises de første skitser. MySQLWorkbench 7

ER-diagram Dokumentation Efter vi havde lavet en attribut tabel samt tegnet vores ER-diagram i hånden, lavede vi vores ER-diagram i MySQLWorkbench. Vores attribut tabel er en smule anderledes end det endelige ER-diagram, da vi efterfølgende har overholdt normaliseringsreglerne. Eksempel på 2. normalform: Ved at indsætte Ordre_id og Produkt_id i Ordrelinje som Primary Key, og navn, antal og pris som attributter, ville vi få en sammensat nøgle, som ville identificere det, som allerede blev identificeret i Produkt. Grundet dette sletter man attributterne, navn og pris i Ordrelinje. Normalformerne ift. vores ER-diagram: 1. normalform: Vi har ingen repeterende felter samt ingen mange-til-mange relationer. Vi har fx delt vores Ordre og Produkt op i et tredje felt Ordrelinje, for at undgå en mange-til-mange relation. Vi har valgt at indsætte attributten, antal, i Ordrelinje uden nogen Primary Key, og derfor gør vi ikke brug af 2. normalform. 2. normalform: Vi gør ikke brug af 2. normalform i vores ER-diagram. Dog vil vi alligevel gerne illustrere, hvordan vi kunne have haft gjort brug af 2. normalform i vores eksisterende ER-diagram. 3. normalform: Vi har lavet en ekstra tabel Postnr., for at undgå at skulle skrive samme postnr. hos forskellige brugere. Vi kunne også overveje at lave ekstra tabeller for fx betalingsmetode og farve, da dette også vil være noget, der skal gentages flere gange på ordrene. 8

CRUD matrix I vores CRUD matrix har vi vores entiteter, som er bruger, produkt og ordre. Vi har nogle use cases, og ser på hvilken rolle vores entiteter har. Oprette kunde: Her er det brugeren som bliver oprettet (C). En ordre vil her ikke blive opdateret (U). Hvis en kunde ændrede personlige oplysninger efter f.eks. at være gået til kassen, vil ordren blive opdateret, men hvis en kunde ikke har tilføjet vare, vil oprettelse af bruger ikke påvirke ordren. Når en kunde tilføjer en vare til indkøbskurven, vil produktet læses(r) og der vil blive oprettet en ordre, som samtidig opdateres. Det samme vil ske, hvis en kunde ændrer antal vare, her vil produktet både blive læst, men også opdateret. Det vil blive opdateret af selve kunden, som dermed vil opdatere ordren. Use case Entity Oprette kunde Tilføj vare til kurv Ændre antal af varer Slet varer fra kurv Bruger C Produkt Ordre U R CU RU U D U 9

Use Case Use Case 1: Navn: Betaling med kort Aktører: Ny kunde Beskrivelse af handling: En kunde, som ikke er registret i databasen, vil købe en vare og ændrer antal vare. kunden skal angive informationer, for at kunne gennemføre ordren. Forudsætninger: Kunde kender alle informationer, som skal gives. Ønsket vare er på lager. Ønsket betalingsmetode er mulig. Konkret handling: 1. Kunde besøger hjemmeside 2. Kunde undersøger varer 3. Kunde tilføjer en vare til indkøbskurven 4. Kunde ændrer antal stk. 5. Kunde går til betaling 6. Kunde indtaster bruger info 7. Kunde vil betale med specielt kort 8. Kunde betaler med bankoverførsel Alternativ handling: 3. Hvis kunden ikke kan tilføje en vare, kan det skyldes at varen er udsolgt, eller at der er mindre antal på lager end ønsket. Hjemmesiden vil vise en popup-boks, sendt fra databasen om manglende vare. 4. Her kunne samme situation ske, her kunne kunden opleve, at kunne bestille 1 stk., men at der kun er den ene vare på lager. 5. Når kunden går til betaling, kunne der komme en meddelelse om at kunde mangler at vælge fx farve, antal osv., som skal angives for at en ordre kan ske. 6. Kunden kan skrive et postnr., som ikke er registreret i databasen. Her vil databasen undersøge postnr. tabellen, og se at postnr. ikke kan genkendes. 7. Hvis kundens kort ikke er et kort, som er tilføjet i tabel og anført i databasen, kan brugeren få vist betalingsmetoder, som databasen tillader. 8. Kunde kan under en bankoverførsel indtaste fx. bogstaver, som ikke godkendes, da datatypen er sat til INT(kun hele tal) og vil derfor fejlmelde. Efter denne use case, vil vi befinde os på ordren, som indeholder oplysninger om kunden (bruger-id) og informationer om produktet (produkt-id) 10

Use Case Use Case 2: Navn: Se produkter. Aktører: Ny kunde. Forudsætninger: Der skal være internet forbindelse. Kunden skal befinde sig på vores hjemmeside. Handling: 1. Kunden vælger de produkter som de gerne vil vide mere om 2. Kunden klikker på produktnavn 3. Nu kan kunden læse mere om produktet Alternativ handling: Da kunden ikke selv skal indtaste informationer eller gå til en betaling, vil der ikke være alternative handlinger, de fejl der kunne komme, vil være hvis f.eks. et produkt er udsolgt, og en kunde derfor ikke vil kunne se produkt information. Kunden har nu læst om vores produkter, hvis de gerne vil handle, skal de registrere sig som kunde, for at kunne gennemføre en ordre. 11

Use Case Use Case 3: Navn: Handel for registreret kunde. Aktører: Registreret kunde Forudsætninger: Kunden skal befinde sig på vores hjemmeside. Kunde er registeret som bruger. Handling: 1. Kunden åbner hjemmesiden. 2. Kunden vælger de produkter som de gerne vil købe/vide lidt mere om 3. Kunden kan tilføje produkter til indkøbskurv. 4. Klikker på Gå til betaling 5. Kunde betaler og modtager bekræftelse på ordre. Alternativ handling: 3. Hvis kunden f.eks. vil købe 3 stk. varer, men der kun er 2 stk. på lager, vil kunden allerede her få besked om dette. 4. Da forudsætningen er, at kunden er registret som bruger, vil der ikke kommer yderligere trin her. Hvis kunden ikke var oprettet, ville kunden her blive bedt om, at oprette sig som bruger. 5. Da kunden er oprettet i databasen, vil der ikke være nogle problemer ved betaling. Dog skal kunden først ved betaling angive betalingsmetode, da dette først er en attribut under ordre tabellen. Kunden vil derfor kunne opleve at skrive forkert kortnummer f.eks., da betalings_id ikke er registreret i databasen. Kunden har nu valgt produkter og befinder sig på ordren, hvor databasen vil opdatere status fra indkøbskurv til ordre, når kundens betaling godkendes. 12

Use Case Use Case 4: Navn: Registreringen Forudsætninger: Kunden skal befinde sig på vores hjemmeside og har valgt produkter. Kunde er nu klar til at gå til kassen. Alternativ handling: 1. Hvis kunden ingen produkter havde valgt, vil kunden ikke kunne gå til betaling, men vil se en tom indkøbskurv. Handling: 1. Kunde klikker på "gå til betaling". 2. Databasen har ikke kunden registreret. 3. Kunden indtaster bruger informationer. 4. Kunden er nu oprettet i databasen og kan nu gennemføre handlen. 2. Kunden er i dette tilfælde ikke registreret. Hvis kunden var registreret i databasen, ville kunden blive sendt direkte til betaling. 3. Kunden kunne her skrive forkerte informationer. Hvis kunden f.eks. kom til at skrive "261o" under 'Postnr.', vil databasen ikke godkende det, da datatypen er sat til INT og kunden derfor kun vil kunne indtaste hele tal. Kunden vil nu have indtastet de nødvendige informationer, for at kunne gennemføre en handel. 13

ER-diagram til SQL kode Efter at have lavet vores Er-Diagram, blev der oprettet en Sql kode. Her bliver der direkte kodet vores database, med de oplysninger vi har angivet i ER-Diagrammet. F.eks. de primary-keys vi har valgt. I øverste linje kan vi se den skriver, at hvis tabellen 'Bruger' i 'Projekt_database' ikke eksistere, skal den oprette den, med nedenstående data. 14

ER-diagram til SQL kode Efterfølgende opretter vi nogle brugere i databasen, ved at tilføje 'Values' til vores attributter. Her skal rækkefølgen selvfølgelig følge vores rækkefølge på vores attributter. Det samme gøres med vores produkter. Her indsætter vi nogle produkter, for efterfølgende at kunne oprette en handel, opdatere den m.m.. 15

Interaktioner 1) Det første vi koder er, at oprette en ordre. Her skriver vi 'Insert into Ordre'. Her skriver vi, at der skal indsættes noget til tabellen 'Ordre'. Efterfølgende kommer vores attributter, som vi har defineret i vores Er-Diagram. Nedenunder skriver vi, at der skal indsættes nogle 'Values' ud fra vores attributter. 2) Det næste vi koder er selve ordrelinjen. Som vist ovenfor, koder vi to ordrelinjer, som vises på samme ordre. Her indtastes igen værdier, som skal passe til vores attributter. Dette svare til, at en kunde køber f.eks. en kaffemaskiner, går til kassen og derefter tilføjer kaffekapsler. 16

Interaktioner Ovenstående kode viser, at det er indsat to produkt_id til vores ordre. Vi har nu en ordre, med produkt_id 5 og produkt_id 13. Nu ønsker vi at slette et produkt. Vi sletter produkt id = 13, ved at skrive, at dette produkt id skal slettes, hvor ordre id'et er 1. 17

Interaktioner Vi har tidligere lavet en ordre, hvor der er tilføjet 1. stk., af produkt_id= 1. I koden nedenfor opdaterer vi ordrelinjen fra 1 stk. til 2 stk., således at vi nu har en ordrelinje, med 2 stk. af samme produkt. 18

Konklusion Databasen: I denne opgave har vi lavet en database for Nespresso. Vi har valgt udvalgte produkter hos Nespresso (kaffemaskiner og kaffekapsler), som er en del af vores database. I databasen vises det, at når en bruger er oprettet, hvordan bestilling af varer og en ordre oprettes. Derudover har vi lavet eksempler på, hvordan oplysninger i databasen kan opdateres ( status ). Dokumentation og analyse: Først har vi analyseret vores database ved at lave en attribut tabel, som beskriver indholdet for database tabellerne. Dernæst har vi ud fra attribut tabellen lavet et ER-diagram i MySQLWorkbench, som præcist viser, hvordan vores database tabeller skal være. Til sidst har vi lavet en Use Case, som step-by-step fortæller hvad der kræves opdateres fra brugerens side samt hvilke step der kan give fejl, hvis brugeren giver forkerte oplysninger. 19

Litteraturliste http://www.w3schools.com/sql/ 'Sams teach yourself sql in 10 minutes', Ben Forta, Pearson P T R, 2012. (ovenstående er benyttet til generel læring om sql kodning) 20