Databaser II – Online bokdatabase

Presentasjon om: "Databaser II – Online bokdatabase"— Utskrift av presentasjonen:

1 Databaser II – Online bokdatabase
Av gruppe 17: Gerd Franchesa Danclar Gunhild Kristiansen Marianne E Ates

2 Formål og brukerbehov On-line bokhandel for norske forbrukere
Bøker i forskjellige sjangre og språk Bred kundegruppe Kunde skal ha tilgang på informasjon uten å registrere seg Tilgjengelige bilder og linker Formål og brukerbehov Formålet med databasen er en on-line bokhandel for norske forbrukere. Bokhandelen har bøker i flere forskjellige sjangrene og språk. Bokhandelen ønsker å strekke seg til en bred kundegruppe derfor finnes det også bøker av veldig høy prisklasse. Pga. dette har vi lagt pris verdien til DEC(6,2). Vi tenker oss at man som uregistrert kunde skal ha tilgang til all informasjon om bøker, priser og tilbud. Når man ønsker å kjøpe bøker, skriver man inn personopplysningene som navn, adresse, fødselsdato, personnummer og e-post adresse. Der det finnes bilde av forfatter og bok, skal kunden kunne se dette.

3 Applikasjoner Webside Registrering ved kjøp av bøker Enkel applikasjon
Selve applikasjonen er en webside der kunden registrerer seg før han/hun kjøper bøker. Gjøre applikasjonen så enkel som mulig for brukeren. Det skal ikke være nødvendig å laste ned ekstra programvare eller bruke tid på uvesentlige ting som ikke har direkte med bokkjøp å gjøre.

4 Dokumentasjon Dokumentasjon er Viktig!! Hvorfor?
For at andre skal forstå databasen! Unngå misforståelser! Derfor har vi lagt mye arbeid i selve dokumentasjonen Hvorfor? Forstå databasen. Skal man ta over databasen bør personen kunne vite at for_id er forfatterId slik at man slipper å gjette. Også det at man har laget databasen med tanke på at postnr har CHAR (4) Vi ble ikke trukkes ut for at vi hadde verdens beste databaseløsning. MEN, på grunn av rapporten

5 Forutsetninger og begrensninger
Antar at alle kunder er norske Vi har brukt INT på tlf og postnummer. Skulle det vært en ”internasjonal” database hadde vi brukt Varchar siden man da kan ha bokstaver eller andre tegn i postnummeret. Antar at alle tlf_nr har 8 siffer Anta at alle postnummer har 4 siffer. Antar at alle kunder har 11 siffer i personnr Dødsdato (d_dato) kun i tabellen forfatter Forutsetninger og begrensninger Vi har som sagt måtte sette en del begrensninger og forutsetninger som vi på beste måte ønsker å spesifisere her. Vi har ikke gått i detaljer om begrensninger satt til den delen av virksomheten som gjelder for salg, lager, regnskap, ansatte og leverandører. Vi har forutsatt at alle kunder har personnummer med elleve siffer. Grunnen til dette er at: online bokhandelen er på norsk og derfor antar vi at alle er norske statsborgere. Dødsdato (d_dato) er bare satt på forfatter siden døde kunder ikke kan handle. Vi har forutsatt at alle kunder er norske statsborgere, så vi har også satt telefonnummer til 8 siffer

6 Forutsetninger og begrensninger
Hoppet elegant over ”kundekartotek”/ ”Kundehistorie” – det ble for mye jobb Begrensninger på antall boksjangre Ikke implementert ”boktilbud” Vi har funnet ut at det blir for mye jobb å implementere ”Kundekartotek” som er naturlig i en bokdatabase. I denne skulle kunden fått oppgitt et kundenummer og passord. Disse opplysningene skulle igjen kunne brukes av vår salgsavdeling for å spesifisere hvilke bøker en kunde eventuelt skulle kjøpe. Vi har satt begrensninger på antall boksjangere. Vi har ikke implementert i databasen de tilbudene som bokhandelen måtte ha

7 Databasens struktur Forfatter ------------------- Forfatter_id{PN}
D_dato F_sted Pseudo Biolink bilde Kunde Kunde_id{PN} Personnr Adresse Tlf Mail Post_nr Person F_navn E_navn F_dato Bok Bok_id{PN} ISBN Tittel Bilde Sjanger Forlag Utgave Sprak Pris bilde Databasens struktur For å kunne få den hele oversikten har vi først valgt å legge ved ER-modellen ( se Figur 3.1). Deretter har vi valgt å listet opp struktur, tabeller og attributter for å få en mer komplett og detaljert oversikt. Forfatterbok Bok_id{PN} Forfatter_id{PN} Postnummer Post_nr{PN} Post_sted

8 Datatyper Date Int Char Dec Varchar Text[] Oid f_dato, d_dato
post_nr, tlf Identifikatorer pris Navn, o.l Array Blob Datatyper: Vi har brukt flere forskjellige datatyper. Disse ønsker vi å forklare nærmere hvor og hvorfor vi har brukt hver av dem. DATE \Denne datatypen har vi brukt på f_dato (fødselsdato i tabellen Person) og d_dato (dødsdato i tabellen Forfatter) INT Grunnen til at vi har valgt INT er at vi i disse to kun trenger heltall. Vi har brukt INTEGER på post_nr (tabellen Postnummer), post_nr og tlf ( tabellen Kunde) CHAR Når vi har brukt CHAR, har vi valgt verdien (6). Grunnen til dette er at vi ønsket å bruke to bokstaver og 4 siffer. DEC Vi har brukt dec(6.2) på pris. Grunnen til at vi ønsket å bruke desimal er at bok priser inneholder 2 desimaler( f.eks kr).  VARCHAR Vi har valgt å bruke varchar mange steder siden dette gir en fleksibilitet i valg av antall karakterer. Verdiene vi har brukt i de respektive har variert fra (11) som vi har brukt i personnummer, til varchar(50). TEXT [] Vi har brukt text[] for å lage endimensjonale array. I tabellen Forfatter i attributtet pseudo (pseudonym). Vi har brukt text[] på biolink i den samme tabellen. Vi har også brukt text[] i tabellen Bok. OID Vi har brukt OID til å peke til en mappe vi har opprettet og hvor vi har bilder.

9 lo_import() og sånn… lo_import() funksjonen lagrer ”baudelaire.jpg”:
INSERT INTO bilde VALUES ( ’baudelaire’, lo_import(’/home/studenter/it00/marianea/bilder/baudelaire.jpg’)); lo_unlink() fjerner large objekt SELECT lo_unlink(bilde.bildeOID) FROM bilde; Un_link prøvde vi kun når vi hadde ett bilde i databasen, men antar at den fjerner alle bildene

10 NULL / NOT NULL ISBN – ikke alle bøker har isbn-nummer
bildeoid(bok) – ikke alle bøker har bilde av forsiden bildeoid(forfatter) – det er ikke bilder av alle forfattere pseudo – ikke alle forfattere skriver under pseudonym f_navn og e_navn – ikke alle forfattere bruker fornavn eller etternavn. Noen forfattere er ukjente Det er noen attributter som nødvendigvis må inneholde en verdi og disse har vi derfor valgt å sette NOT NULL verdi på. Dette fant vi særlig viktig i tabellen Kunde hvor alle personopplysninger som personnummer, adresse, tlf, mail og post_nr, er nødvendige for å kunne gjennomføre en handel. På de av attributtene som skal ha mulighet til å være tomme har vi valgt å ikke skrive NULL siden dette er en default verdi. Forklaringer på NULL-verdier ·        ISBN – På denne har vi valgt å bruke NULL, siden det ikke er alle bøker som har ISBN nummer (særlig gjelder dette gamle bøker) ·        bildeOID (Bok) – Ikke alle bøker har bilde av forsiden (særlig gjelder dette gamle bøker) ·        bildeOID (Forfatter) - Det er ikke bilde av alle forfatterne, siden noen av forfatterne er ukjent ·        pseudo – Ikke alle forfattere skriver under pseudonym ·        f_navn og e_navn - Vi har satt f_navn og e_navn med tillatt NULL-verdi siden ikke alle forfattere har etternavn (f.eks Prinsesse Martha), og heller ikke alle forfattere bruker fornavnet sitt. Det er heller ikke alltid at forfatteren er kjent

11 NULL / NOT NULL f_dato – forfatters fødselsdato er ikke alltid kjent
d_dato – ikke alle forfattere er døde biolink – ikke alle forfattere har websider f_sted – ikke alle forfatteres fødested er kjent forlag – noen eldre bøker har ikke forlag utgave – på noen bøker er det ikke angitt utgave ·        f_dato – Ikke alle forfattere har kjent fødselsdato ·        d_dato (Dødsdato )– Ikke alle forfatter er døde. Vi har valgt å sette d_dato kun på forfatter, siden det ikke er mulig for en død kunde å handle bøker. ·        biolink – Ikke alle forfattere har websiden med biografien sin ·        f_sted – Vi har satt f_sted kun på forfatter, og det er tillatt med NULL-verdi. Noen forfattere ønsker ikke å oppgi personlig info, og for andre er f_sted ukjent ·        Forlag – På gamle bøker oppgir man ikke forlag (Vi tenker da særlig på at vi har bøker av veldig høy prisklasse) ·        Utgave – På noen bøker kommer det ikke frem hvilken utgave det er snakk om (Igjen gjelder dette gamle bøker)

12 Tabeller og attributter
Alle tabeller som er brukt 1 Alle tabeller som er brukt Vi har totalt 6 tabeller i databasen. Dette er Person, Forfatter, Kunde, Bok, Forfatterbok, Poststed og bilde. Disse tabellene blir omtalt nærmere her: Vi har ikke tenkt til å gå i detalj når det gjelder tabellene, men ønsker å vise det slik vi har satt det opp i rapporten

13 Person - tabellen Attributter Forklaring f_navn e_navn f_dato Fornavn
Etternavn f_dato fødselsdato Person Dette er ”hovedtabellen” som forfatter og bok arver fra.

14 Forfatter - tabellen Attributter Forklaring for_id d_dato f_sted
forfatter_id, spesifisert med CHAR(6), to bokstaver og fire tall. d_dato Eventuell dødsdato. Er ikke i Person-tabellen fordi den ikke gjelder for kunde. f_sted Fødested pseudo Eventuelle pseudonymer som forfatteren bruker. bilde Bilde av forfatteren biolink Linker til websider om forfatteren Forfatter Her ligger all respektiv informasjon om forfatterne Her har vi vært på nettet og søkt etter data. Alle url’er til biografiene er autentiske. Forfatterens f_sted, f_dato og eventuelle d_dato er korrekte på de vi kunne finne opplysninger om dette. Imagene om forfatterne har vi funnet på nettet.

15 Kunde - tabellen Attributter Forklaring kunde_id personnr adresse tlf
Spesifisert med CHAR(6), 2 bokstaver og 4 tall personnr Kundens personnummer adresse Kundens adresse tlf Kundens telefonnummer (8 siffer) mail Kundens mailadresse postnummer Kundens postnummer Kunde Her ligger all respektiv informasjon om Kundene Kundene er fiktive. Her har vi igjen vært inne på websiden til for å hente informasjon om hvilke gater som finnes i de kommunene vi har lagt inn i databasen. Dette har vi igjen knyttet opp mot den fiktive kunden

16 Bok - tabellen Attributter Forklaring bok_id ISBN tittel sjanger
Spesifisert med CHAR(6), 2 bokstaver og 4 tall ISBN Bokens ISBN-nummer tittel Bokens tittel sjanger Array, fordi noen bøker kan sorteres under forskjellige sjangre forlag Bokens forlag utgave Hvilken utgave av boken dette er sprak Hvilket språk denne boken er skrevet på Bok Bøkene med ISBN nummer, tittel og forfatter er autentiske. På noen av stedene har vi satt inn et ”fiktivt forlag” på de stedene hvor vi ikke kunne finne opplysninger om dette. Imagene av forsiden til bøkene har vi igjen funnet på nettet.

17 Forfatterbok - tabellen
Attributter Forklaring bok_id Refererer til bok_id i tabellen Bok for_id Refererer til forfatter_id i tabellen Forfatter Forfatterbok Her har vi lagt inn bok_id og forfatter_id Siden en forfatter kan skrive flere bøker og enn bok kan være skrevet av flere forfattere har vi delt dette opp i forfatterbok, som representerer den ene boken.

18 Poststedet som postnummer refererer til
Poststed - tabellen Attributter Forklaring post_nr Postnummer post_sted Poststedet som postnummer refererer til  Postnummer Data om postnummer og poststed er hentet fra og er autentiske. Som en tommelfingerregel sier vi at denne ”bør” alltid stå for seg selv. Grunnen til dette: I de fleste db’er er det adresser involvert, der også mange av disse har samme postnummer. I stedet for å lage masse redundante data blir så disse lagt inn i en egen tabell.

19 Spørringer Vi har med noen få eksempler på spørringer her.
Vi syntes det er uinteressant å legge frem mange spørringer i denne presentasjonen, men viser ett par enkle

20 Arv mellom tabeller SELECT * FROM Forfatter; f_navn | e_navn | f_dato | forfatter_id | d_dato Lars Saaby | Christensen | | FO | NULL | f_sted | pseudo | biolink Moss,Norge | NULL | { Bilde NULL Her ser vi at f_navn, e_navn og f_dato er arvet fra tabellen Person:

21 OID som datatype bildeOID lager seg selv: SELECT * FROM bilde;
Bnavn | bildeoid baudelaire | Elstad | hcAndersen | niniRollAnker | hermanBroch | asbjornsen | paalBrekke | ingeborgBachman | bjorneboe | margaretAtwood | moe | 47213 bildeOID lager seg selv:

22 Spørring som viser array
SELECT biolink FROM Forfatter WHERE e_navn = ’Christensen’; biolink { (1 row) Her ser vi at forfatteren Lars Saaby Christensen har to biolinker i en array:

23 Funksjoner, triggere, CASE clause
Funksjonalitet Funksjoner, triggere, CASE clause

24 Triggere Beskrankninger og rules har vi lagt i triggere. Det er mange steder vi ønsker en beskankning, men har valgt å legge disse på postnummer og personnummer. Postnummer skal kun inneholde 4 siffer Personnummer skal inneholde 11 siffer Vi har valgt å lage BEFORE triggere. Hvorfor BEFORE? Vi ønsker å forbedre databasen vår ved å legge inn flere triggere.

25 personnr_trigger create trigger personnr_trigger before insert on Kunde for each row EXECUTE PROCEDURE personnr_trigger_function(); (# 'Rolvsøyveien 357', '588B4567', '1600'); ERROR: Personnummer skal kun inneholde siffer! Funksjonen blir kalt opp av triggeren ”personnr_trigger”. Her prøvde vi med bokstav i pers.nr, og dette hendte:

26 CASE clause SELECT tittel, forlag, CASE WHEN forlag = 'Gyldendal’ THEN 'utsolgt' WHEN forlag = 'Cappelen' OR forlag = 'Orion' THEN 'På lager' ELSE 'Kommer snart' END FROM Bok ORDER BY tittel; tittel | forlag | case Herman | Cappelen | På lager Livsslaven | Gyldendal | utsolgt Margret | Aschehoug | Kommer snart MariaMaria | Aschehoug | Kommer snart Pesten | Orion | På lager En oversikt over hvilke bøker som er på lager og hvor de er i systemet Aschehoug = ligger under alle andre(Else)

27 Kvalitetsvurdering I Minimalt med redundante data, og om/når de finnes, er det kun fordi det kan forsvares i forhold til effektivitet, tempo o.L. Datamodellen bør være klar, konsis, lett å tyde. Alle momenter (attributter, entiteter) som man vil kunne ha bruk for i forskjellige scenarier bør være tatt med i modellen. Alle krav om funksjonalitet / innhold som er beskrevet i oppgavens del 1 må være oppfylt. Spøringene, løsningen på oppgavens del 2, må også være relevante og i tråd med hva oppgaven spør etter. 1.      Redundante data= Dobbellagring av data. Data man bruker ofte kan være fint å ha dobbeltlagret slik at man da slipper å gå ned i databasen å spørre flere ganger etter samme bok. Vil unngå å lage databasen unødvendig stor og tung, samt vanskeliggjøre og komplisere funksjonaliteten. 2.      Datamodellen bør være klar, konsis, lett å tyde. Det skal ikke være noe problem for en utenforstående å sette seg inn i databasens funksjonalitet. Dette vil også føre til at det blir mindre komplisert å lage spørringer til databasen. 3.      Alle momenter (attributter, entiteter) som man vil kunne ha bruk for i forskjellige scenarier bør være tatt med i modellen. Her er det viktig å kunne klare å legge inn nok varierte scenarier, slik at man får tilstrekkelig testing av databasen. 4.      Alle krav om funksjonalitet / innhold som er beskrevet i oppgavens del 1 må være oppfylt - Arv mellom tabeller, OID som datatype, Temporale datatyper(kan begrenset til bruk av DATE type), Arrayer som lagrede verdier - Binary Large Object(BLOBS) som datatype: bilder, tekster, lyd og video, Funksjoner i form av server side triggers, Regler (Rules).” 5.      Spørringene, løsningen på oppgavens del 2, må også være relevante og i tråd med hva oppgaven spør etter. ”Hver gruppe skal utforme et sett med SQL-spørringer som viser brukt av databasen. Disse spørringene skal være slik utformet at de omfatter alt det som er spesifisert i Del 1. Man skal også vise et par spørringer ved bruk av CASE clause”

28 Kvalitetsvurdering II
Forutsetninger og begrensninger som er blitt satt bør være dokumentert. Databasen må fungere! Det bør være tatt med en oversikt over brukte datatyper. Det bør være tatt med forklaringer på null-verdier, der dette ikke er innlysende. Beskrankninger, rules og triggere må fungere tilfredsstillende. 1.      Forutsetninger og begrensninger som er blitt satt bør være dokumentert. Ellers kan man finne feil og mangler der det i utgangspunktet ikke er noen. 2.      Databasen må fungere! Spørringer, relasjoner, linker o.l skal fungere uten problemer. 3.      Oversikt over brukte datatyper Helst med forklaringer, særlig gjelder dette egendefinerte. 4.      Forklaringer på NULL-verdier, der dette ikke er innlysende. Eks, hvorfor forfatter.f_navn tillater NULL-verdi (svar: Man vet ikke fornavnet til alle forfattere) 5.      Beskrankninger, Rules og Triggere må fungere tilfredsstillende.

29 Svakheter/endringer Vi ser i ettertid at databasen vår har diverse svakheter, og at rapporten har noen feil. Disse skal vi naturligvis rette opp. Selve databasen ser vi i ettertid er litt for liten til å være funksjonell, men det er noe vi ikke kommer til å gjøre noe med. Vi har skrevet i rapporten at det er et star skjema uten Time tabellen. Dette er feil. Vi har blandet litt…..

30 Konklusjon En lærerik og slitsom prosess, til tider frustrerende
Utfordring å måtte finne kode som kunne brukes i postgreSQL uten å få hjelp fra lærebok / forelesninger Forenklet databaseløsning, ønsker å legge mer inn i et ferdig produkt Vi kan etter å ha jobbet med denne databasen si at det har vært lærerikt og slitsomt prosess. Vi kan også konkludere med at det i visse perioder har vært frustrerende. Siden dette var et fag hvor vi ikke har fått introduksjon i, var det en ekstra stor utfordring å måtte finne alt kode på ”egen hånd”. En annen grunn til dette var at Pensumboken heller ikke dekket det vi trengte for å kunne opprette en database med postgres Det var visse funksjoner vi ønsket å implementere i databasen men som vi ikke klarte, mye pga tiden vi hadde til rådighet. Men bare for å ha nevnt disse-………….: v     Kundekartotek v     Lagerstyring – hvor finnes boken, hvilket lager og på hvilken plass? Er den utsolgt, må vi bestille den, hvor lang tid tar det osv. Automatiske utregninger - m.h.t. inntekt og utgifter, som ev. kunne settes rett inn i et tilkoblet regnskapsprogram

31 Kilder Vi har brukt mange kilder og alle disse er godt dokumentert i rapporten. Grunnen til at vi har lagt stor vekt på dokumentasjon av de kildene vi har brukt er flere: Rettigheter Bedre kvalitetssikring på de kildene man har brukt. Lesere av rapporten kan dobbelsjekke kildene

32 Noen spørsmål?? Ikke det…….?
Takk for oss!