3. semester, 2. projekt: Database MulA - Gruppe 1 7. september 2015-20. september 2015 Vejledere - IRF / TUJE
FAKTAARK PROJEKTTITEL Database URL http://moodings.com Mette Line Tarp Jørgensen Email cph-mj420@cphbusiness.dk Portfolio metteline.nu SKOLE Copenhagen Business Academy HOLD CLmul-a14e ÅRGANG 2014 Rie Larsen Email cph-rl71@cphbusiness.dk Portfolio rie-larsen.com VEJLEDERE Tue Becher Ivan Rosenvinge Frederiksen HOVEDOMRÅDER Interaktionsudvikling Simone Fie Truelsen Email cph-st88@cphbusiness.dk Portfolio simonetruelsen.dk Helena Maria Abel Email cph-ha105@cphbusiness.dk Portfolio hma-design.dk 2
INDHOLDSFORTEGNELSE INDLEDNING... 3 GANTT-KORT... 4 PBS... 5 ER-DIAGRAM... 6 ATTRIBUTTABEL... 9 DATABASE & SQL... 11 USE CASE... 14 CRUD... 17 LITTERATURLISTE... 18 INDLEDNING I dette projekt skulle vi lære at analysere, veldokumentere og udvikle en velfungerende database, som skulle kunne underbygge en forretning i fremtiden. Vi skulle vælge en kendt webshop, og hertil skulle vi selv udvikle en database og dokumentere dette i form af en use case/user story og et ER-diagram på 3. normalform. Vi valgte at tage udgangspunkt i Moodings.com, som er en dansk online webshop der sælger skandinavisk interiør design. 3
GANTT-KORT Projekt 2: Database Start Slut Dage 7.. Man 8. Tirs 9. Ons 10. Tors 11. Fre 12. Lør 13. Søn 14. Man 15. Tirs 16. Ons 17. Tors 18. Fre 19. Lør 20. Søn Indledende - Brainstorm - valg af webshop - Projektplanlægning Database og rapport - Analyse: UC, CRUD, ERmodel - Dokumentation: Attributtabel - Udvikle (SQL) - Opsætning og layout - Finpudsning 07.09 08.09 2 07.09 07.09 1 08.09 08.09 1 09.09 19.09 11 09.09 10.09 16.09 13.09 8 4 11.09 18.09 8 14.09 19.09 6 19.09 19.09 1 Aflevering 20.09 20.09 1 4
PBS Projekt 2: Database Datamodellering Rapport ER-Model - 3.NF. Planlægning CRUD Matrix Layout Use Case Finpudsning Attribute tabel Aflevering SQL 5
ER-DIAGRAM Vores ER-diagram illustrerer hvordan vores database er bygget op med de forskellige entiteter og attributterne, og dette diagram er lavet på 3. normalform. 6
ER-DIAGRAM Customer: I denne tabel, har vi (customer_id) som vores primary key og så har vi en foreign key (zipcode_zip_ code), der har fået sin egen tabel. Derudover har vi nogle forskellige attributter der fortæller noget om kunden, såsom fornavn, efternavn og adresse. Relationen: Mellem de to førnævnte tabeller har vi en en til mange relation, der beskriver, at en kunde kan have et enkelt postnummer, hvor et postnummer kan have flere kunder. Zipcode: I denne tabel, har vi (zip-code) som vores primary key. Denne bliver brugt i tabellen Customer. Derudover har vi attributten city. Relationen: Mellem de to førnævnte tabeller har vi en en til mange relation, der beskriver, at en kunde kan have et enkelt postnummer, hvor et postnummer kan have flere kunder. Orders: I denne tabel, har vi (order_no) som vores primary key, og så har vi to foreign keys (customers_customers_id) og (order_status), som kommer fra tabellerne Customers og Order_status. Dette skyldes, at man på ordren samlet kan se kundenummer og ordrestatus på den afgivne ordre. Relationen: Vi har en en til mange relation mellem Orders og Customers der beskriver at en kunde kan have mange ordrer, mens en ordre kun kan have en kunde. Imellem relationen Orders og Orderstatus har vi en tabel der hedder order_status_has_orders hvori (order_status_order_status_id) og (order_order_no) er vores primary keys. Derudover indeholder tabellen attributten (order_date), der automatisk angiver ordre datoen. Orderdetails: I denne tabel, har vi to primary keys (orders_order_no) og (products_product_no), som trækker sig fra tabellerne Orders og Products. Derudover har vi attributten (quantity) som beskriver hvor mange der er af samme vare. Relationen: En ordre (order_no) kan godt have flere ordredetaljer hvor en ordrelinie kun kan knytte sig til en ordre. Et produkt kan have flere ordrelinier, mens en ordrelinie kan kun have et produkt. Orderstatus: I denne tabel, har vi (order_status_id) der er vores primary key. Så har vi attributten (status), der beskriver om ordren enten er modtaget, afsendt eller om den stadig er i indkøbskurven hos kunden på websitet. Relationen: Mellem tabellen Orderstatus og Orders er tabellen order_status_has_orders blevet oprettet. 7
ER-DIAGRAM Products: I denne tabel, har vi (product_no) som vores primary key og så har vi en foreign key (category_categori_id), der knytter sig til tabellen category. Derudover har vi nogle forskellige attributter der fortæller noget om produktet, såsom pris og navn mm. Relationen: Mellem Products og Category er en en til mange relation, da kategorierne godt kan have flere forskellige produkter. Category: I denne tabel, har vi (category_id) som vores primary key. Så har vi attributten (category_name). Relationen: Mellem Products og Category er en en til mange relation, da kategorierne godt kan have flere forskellige produkter. 8
ATTRIBUTTABEL Entiteter customers products orders Attributter Værdi Datatype customer_id 1 - X INT customer_first_name a - Å VARCHAR(40) customer_last_name a - Å VARCHAR(40) customer_adresse All character VARCHAR(65) customer_phone 1-9 INT(10) customer_email All character VARCHAR(55) zip_code 1000-9999 INT(4) city a - Å VARCHAR(30) product_no 1 - X INT product_name All character VARCHAR(100) product_description All character TEXT product_price 1-9 DECIMAL(10,2) product_stock 1-1000 INT min_stock 1-10 INT category_id 1 - X INT category_name a - Å VARCHAR(30) order_no order_status order_date quantity 1 - X a - Å YYYY-MM-DD 1 - X INT VARCHAR(30) INT INT Noter Primary, NOT NULL Unique Primary, NOT NULL Unique Unique Primary, NOT NULL 9
ATTRIBUTTABEL Vi har lavet en attribut tabel over vores entiteter for at skabe et overblik. Denne tabel er grundstenen for videre udvikling af vores ER-diagram der er på 3. normalform. Vi har tilføjet alle entiteter på 1. normalform samt indhold. Entiteter: Customers, Products, Orders. Disse godkender tilsammen de krav, som vi kræver at systemet, for at arbejde med en webshop. Vores tabel er opdelt således, at vi i første kolonne har; Entiteter så har vi Attributter, Værdi, Datatype og til sidst Noter. Denne tabel er lavet på 1.NF og er derfor senere lavet om til 3.NF i vores ER-diagram. Ved at lave den om til 3.NF, udvikler vi fx tabellen zipcode som er forbundet med tabellen Customers via primary og foreign keys. 10
DATABASE & SQL Vi har udviklet vores ER-diagram i programmet MySQL- Workbench, og herefter har vi trykket Forward Engineer for at kunne se SQL koden. Hvis man skulle starte fra den anden vej, skulle man starte med at oprette en database, og for at sikre at der ikke i forvejen findes en database med samme navn (mydb) bruges if ixists i forbindelse med dette. Koden lyder således: DROP DATABASE IF EXISTS mydb; CREATE DATABASE mydb; Herefter oprettes der en række tabeller til databasen, hvilket eksempelvis gøres på følgende måde: CREATE TABLE IF NOT EXISTS `mydb`.`customers` ( `customer_id` INT NULL AUTO_INCREMENT, `customer_firstname` VARCHAR(40) NULL, `customer_lastname` VARCHAR(40) NULL, `customer_address` VARCHAR(65) NULL, `customer_phone` INT(10) NULL, `customer_email` VARCHAR(55) NULL, `zipcode_zip_code` INT(4) NOT NULL, PRIMARY KEY (`customer_id`, `zipcode_zip_code`), INDEX `fk_customers_zipcode1_idx` (`zipcode_zip_code` ASC), CONSTRAINT `fk_customers_zipcode1` FOREIGN KEY (`zipcode_zip_code`) REFERENCES `mydb`.`zipcode` (`zip_code`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; 11
DATABASE & SQL Først opretter (create) vi en tabel, og for at sørge for at den ikke allerede i forvejen findes, skriver vi IF NOT EX- ISTS således der ikke findes to ens tabeller i samme database. Koden viser hvilke forskellige kolonner tabellen indeholder (fx customer_id og customer_firstname ), og dertil kan det også ses hvilken datatype (INT, VARCHAR) de hver især har. Kolonnen customer_id er primary key i denne tabel, hvorimod zipcode_zip_code er en foreign key. Når de forskellige tabeller er oprettet i databasen, kan der indsættes data i disse. For at illustrere hvordan dette gøres, kan vi tage tabellen customers til at starte med: INSERT INTO customers (customer_id, customer_firstname, customer_lastname, customer_address, customer_phone, customer_email, zipcode_zip_code) VALUES (NULL, Rie, Larsen, Abildgaardsvej 12 1th, 53576754, r-larsen@hotmail.com, 2830 ); INSERT INTO customers (customer_id, customer_firstname, customer_lastname, customer_address, customer_phone, customer_email, zipcode_zip_code) VALUES (NULL, Helena, Abel, Gammel Køge Landevej 23, 1234578, helena@abel.dk, 2650 ); INSERT INTO customers (customer_id, customer_firstname, customer_lastname, customer_address, customer_phone, customer_email, zipcode_zip_code) VALUES (NULL, Simone, Truelsen, Magnoliavej 12, 54545454, simone@fie.dk, 2600 ); INSERT INTO customers (customer_id, customer_firstname, customer_lastname, customer_address, customer_phone, customer_email, zipcode_zip_code) VALUES (NULL, Mette, Jørgensen, Herlevvej 92, 49284828, mette@line.dk, 2700 ); 12
DATABASE & SQL Et andet eksempel på at vise hvordan dataen indsættes i databaserne, er hvis admin fx skal oprette produkter på produktlisten på websites. Først oprettes tabellen med samme fremgangsmåde som tabellen customers : CREATE TABLE IF NOT EXISTS `mydb`.`products` ( `product_no` INT NULL, `product_name` VARCHAR(100) NULL, `product_description` TEXT NULL, `product_price` DECIMAL(10,2) NULL, `product_stock` INT NULL, `min_stock` INT NULL, `category_category_id` INT NOT NULL, PRIMARY KEY (`product_no`), INDEX `fk_products_category1_idx` (`category_category_id` ASC), CONSTRAINT `fk_products_category1` FOREIGN KEY (`category_category_id`) REFERENCES `mydb`.`category` (`category_id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB; Og herefter tilføjes de nye produkter i databasen på følgende måde: INSERT INTO products (product_no, product_name, product_description, product_price, product_stock, min_ stock, category_category_id) VALUES (1020, Mogens Lassen Kubus Lysestage, Flot lysestage med plads til 4 lys, 999,99, 123, 50, Lysestager ); INSERT INTO products (product_no, product_name, product_description, product_price, product_stock, min_ stock, category_category_id) VALUES (1023, Frederik Bagger glas, Fine krystalglas i Crispy serien fra danske Frederik Bagger., 249,00, 350, 50, Service ); 13
USE CASE Opret produkt Opdatér produkt Adminstrator Slet produkt Opret kategori Se lagerstatus Se ordre Vi har udviklet en Use Case Model for at give et samlet overblik over hvad de aktører (bruger og admin) kan foretage sig og hvad deres funktioner er på websitet. Annullér ordre Opret kunde Bruger Søge efter produkter Sortér efter kategori Læg i indkøbskurven Rediger indkøbskurven Opret ordre 14
USE CASE Herefter har vi givet en detaljeret beskrivelse på tre af de mest vigtige use cases. USE CASE STORY 1: NAME: Opret ordre PRECONDITIONS: Kunden skal have produkter i kurven, indtastet sine oplysninger og trykket på køb før kunden bliver oprettet. BASIC COURSE: Kunde vælger produkter og lægger dem i kurven Kunde indtaster sine oplysninger og kontooplysninger og trykke køb Kundens oplysninger ryger ind i databasen, så de kan bruges til at afsende ordren CONDITION: Kunde indtaster sine oplysninger i formular Oplysningerne ryger ind i de forskellige tabeller i databasen, så de er struktureret på en ordentlig måde så ordren kan afsendes til den rigtige kunde (create, read). USE CASE STORY 2: NAME: Redigér indkøbskurven PRECONDITIONS: Kunden skal have valgt nogle produkter til indkøbskurven, så de enten kan slettes, tilføjes flere eller ændre antal varer. BASIC COURSE: Kunde vælger produkter og lægger dem i kurven Kunde ønsker ikke et af produkterne alligevel og sletter det fra indkøbskurven. CONDITION: Kunde vælger produkter og lægger dem i kurven Kunde ønsker ikke et af produkterne alligevel og sletter det fra indkøbskurven (read, update, delete). POST-CONDITION: Enten bliver produkterne læst, opdateret eller slettet i indkøbskurven. POST-CONDITION: Alle oplysningerne kan ses på kunden i databasen. 15
USE CASE USE CASE STORY 3: NAME: Opret produkt PRECONDITIONS: Admin skal oprette et produkt i en kategori på websitet. BASIC COURSE: Admin tilføjer nyt produkt i databasen i en ny eller allerede eksisterende kategori. CONDITION: Admin tilføjer nyt produkt i databasen og udfylder følgende attributter i tabellen products : product_no, product_name, product_description_ product_price, product_stock, min_ stock og vælger en kategori i tabellen category med attributterne: category_id og category_name (create) POST-CONDITION: Produkterne bliver tilføjet til databasen og vises på websitet (create). 16
CRUD Bruger Admin ENTITET AKTIVITET - Opret kunde - Søg efter produkter - Sortér efter kategori - Læg i indkøbskurven - Redigér indkøbskurven - Opret ordre - Opret produkt - Opdatér produkt - Slet produkt - Opret kategori - Se lagerstatus - Annullér ordre - Se ordre customers zipcode orders order_status order_status_ orderdetails products category has_orders C C/R R R R C R R R, U, D R, U, D R, U C C C R R C C R, U R, U D D C R D D D D D R R R R R R R R Vores CRUD-matrix beskriver hvilke funktioner (Create, Read, Update, Delete), som brugeren kan foretage sig på websitet og hvad admin (moodings.com) kan foretage sig i databasen. 17
LITTERATURLISTE Bøger: Sams Teach Yourself SQL in 10 min Ben Forta, 2013 (Person Education, inc) Websites: www.w3school.com www.stackoverflow.com www.agiledata.org/essays/datamodeling101.html www.moodings.com 18