Databaser II – Online bokdatabase

Slides:



Advertisements
Liknende presentasjoner
Mer om SQL-spørringer og funksjoner
Advertisements

Slik bruker du vår nettbutikk!
Repetisjon innkapsling static tabell av primitiv datatype LC191D Videregående programmering Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring.
Tabeller av objekter Klassen ArrayList
Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring
Antalis-HQ BRUKERVEILEDNING FOR BESTILLINGER. Antalis, Europas ledende distributør av papir, emballasjeløsninger og dekor & display produkter, presenterer.
Et hjelpemiddel for å lage litteraturlister/kildelister.
SuperOffice - Visma Global ERP link - Tilbud/Ordre SuperOffice - Visma Global integrasjonen består av 3 produkter. ERP link SuperOffice - Visma Global.
Hvordan etablere nettbutikk med GoOnline Commerce
GoOnline publisering Hvordan komme i gang med GoOnline. Denne presentasjonen tar deg steg for steg gjennom oppsett av nettsted med bruk av GoOnline Proffesional.
BraWeb Bestilling.
LC238D Datamodellering og databaser Else Lervik, september 2012 Forelesning 6, Uke 39 Objektorientering i ER-modeller.
SkrivBIB - et verktøy for forskere, studenter og bibliotekarer.
© Atmel Norway 2005 Webinteface for presentasjon av lisensbruk Hovedprosjekt 003E.
Slik kommer du til «Personverninnstillinger»: Logg inn på Facebook.
Mange til mange sammenhengen
Programmering i ActionScript - hva er det, og hvordan undervise?
Høgskolen i Oslo Webprogrammering SQL og databaser del 3.
B IBLIOTEKSKURS 2 INFORMASJONSSØK KILDEKRITIKK. ATEKST Du finner ATEKST i Fronter eller på bibliotekets forside. Kun datamaskiner på skolen har tilgang.
Java database persistence framework.  SELECT by FROM postnr AS p WHERE ( SELECT DISTINCT postnr FROM addr AS a WHERE user.adrId = a.Id ) = p.postnr;
Uke 10 - Sortering, og hvordan lage en klasse for et klassebibliotek 21 okt. 2003, Arne Maus Inst. for informatikk, UiO.
- du trenger ingen annen!
Avansert SQL og problemløsning
Programmering i Java versjon januar 2005 Kun til bruk i tilknytning til læreboka ”Programmering i Java” skrevet av Else.
Databaser Verktøybok om Access med innslag av Frontpage: Snarveien til Access.
Felles lånekort – praktiske opplysninger Av Øystein Reiersen, prosjektleder.
Foresattepålogging Du velger Foresatte Foreldremøte Adresse:
Databaseteori.
Normalformer – avleggs?
Norske Runer Språk i perioden
Databasehåndtering med MySQL
Arbeidskrav og rammebetingelser IKT-krav Betraktninger.
Forside Korteste sti BFS Modifikasjon Dijkstra Eksempel Korrekthet Analyse Øving Spørsmål Dijkstras algoritme Åsmund Eldhuset asmunde *at* stud.ntnu.no.
Dijkstras algoritme Åsmund Eldhuset asmunde *at* stud.ntnu.no
1 Øvingsforelesning 7 Kai Olav Ellefsen. 2 I dag… Databaser: Databasedesign og SQL JSP: Koble databasen til nettsiden Kai Olav Ellefsen, NTNU, 2010.
Anette Kure Bibliotekar  Det dere gjør her ved Høgskolen er en forberedelse til og en øvelse i forskningsarbeid.  All forskning og alt akademisk.
LC238D Datamodellering og databaser Else Lervik, september 2012 Forelesning 6, Uke 39 Objektorientering i ER-modeller.
In 135 Datamodellering og databaser Introduksjon, Enkeltentiteten, Informasjon Ola Bø.
LC238D Datamodellering og databaser Else Lervik, september 2011 Forelesning 6, Uke 38 Objektorientering i ER-modeller.
Hvordan skrive en god utredning?
Sqlite Et lite eksempel på en SQL- database. SQL kan startes på ulike måter Kommandolinjeversjon or Windows –Programmet må innstalleres Hentes fra
1 Kap 02 Relasjonsdatabaser. Data-organisering - Manuelt Ansatte Pasienter Utstyr Økonomi Avdelinger RøntgenOnkologisk.
SkrivBIB - et verktøy for forskere, studenter og bibliotekarer.
Testing av system Gruppe 6 Henrik Bækhus Morten A. Iversen Mathias Bondeson Gunnar K. Kulleseid Svein Ivar Kristiansen Ronny Hulthin.
Object Oriented Measurement
1 Organisering av kode (Kapittel 5). 2 Mål ● Forstå inkludering er og hvilken gevinst det gir ● Lære å utvikle egne funksjoner ● Forstå variablenes virkemåte.
Structured Query Language Kræsj-kurs
ER-modellen, notasjon ENTITETS- Attributter TYPE Relasjon
Eksempel på SQL ”SQL-setninger” har en struktur som likner på ”naturlig språk”, med ”verb, subjekter og adjektiver”. SQL-setningene begynner alltid med.
DATABASE: Oppgave 2 et medlemsregister for en idrettsklubb med flere idrettsgrener (fotball, håndball, osv). klubben ønsker å lagre informasjon om medlemmenes.
storoppgave OPPGAVE3: bibliotekdatabase
Dynamiske nettsider PHP Del 1 – variable. PHP  PHP (Personal Home Page)  Fritt tilgjengelig programmeringsspråk  åpen kildekode  Plattformuavhengig.
ELEFANTKLUBBEN (De eldste barna)
Fødselsdato (dmå) er født har lønn Ansatt (ansnr) Beløp (NKr)+ Telefon
Hvordan kan foreldre bruke de vangligste funksjonene i Itslearning.com
VOD. VOD- Vegobjektdialog Åpne eksisterende vegobjekt Nytt vegobjekt.
Struktur Nå Internett Uavhengig systemer bygd opp over tid.
Linq To SQL Fagdag 20. November DataContext  DataContexten er mappingen mot databasen –Generer objekter for alle entiteter (tabeller), med properties.
REFERANSETEKNIKK Forelesning for: Spesialpedagogikk tirsdag tirsdag Anette Kure.
Skjemaendringer i systemer bestående av XML-data i relasjonsdatabaser Høgskolen i Gjøvik Master i Medieteknikk, Marianne Brattrud.
Hvordan føre kilder?.
4. Prioritizing Your Usability Problems Prioriteringer.
Se ellers læreboka, kap , side
1 Java Database Connectivity (JDBC) Norvald H. Ryeng
Online løpssøknad via ”Klubben Online” For O-sesongen 2006 skal alle orienteringsgrupper søke om sine arrangementer via elektronisk søknadsskjema i ”Klubben.
INF1000 (Uke 14) Eksamen V06 Grunnkurs i programmering Institutt for Informatikk Universitet i Oslo Are Magnus Bruaset og Arild Waaler.
2003 Ontopia AS1 Tanker om standarder for e-læring Emnekart og published subjects Lars Marius Garshol, utviklingsleder Ontopia,
HUMIT1731 Hypermedier Introduksjon til XSL Transformation (XSLT)
Inf1000 (Uke 5) Arrayer, filer og tekst
© USIT/SAPP/GT, Bård Jakobsen UNIVERSITETET I OSLO USIT :34 Side 1 FEIDE – BAS – Cerebrum v/Bård H.M. Jakobsen GT/SAPP/USIT, UiO.
Utskrift av presentasjonen:

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

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.

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.

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

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

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

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

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

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

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

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)

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

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.

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.

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 www.posten.no 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

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.

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.

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 www.posten.no 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.

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

Arv mellom tabeller SELECT * FROM Forfatter; f_navn | e_navn | f_dato | forfatter_id | d_dato ------------------------------------------------------------------------------- Lars Saaby | Christensen | 1953-09-21 | FO0001 | NULL | f_sted | pseudo | biolink ------------------------------------------ Moss,Norge | NULL | {http://www.aftenposten.no/alex/litterat/forfatte/christen.htm, http://www.cappelen.no/main/forfatter.asp?f=7011} Bilde -------- NULL Her ser vi at f_navn, e_navn og f_dato er arvet fra tabellen Person:

OID som datatype bildeOID lager seg selv: SELECT * FROM bilde; Bnavn | bildeoid ------------------------------------------------ baudelaire | 47192 Elstad | 47194 hcAndersen | 47196 niniRollAnker | 47198 hermanBroch | 47200 asbjornsen | 47202 paalBrekke | 47204 ingeborgBachman | 47206 bjorneboe | 47209 margaretAtwood | 47211 moe | 47213 bildeOID lager seg selv:

Spørring som viser array SELECT biolink FROM Forfatter WHERE e_navn = ’Christensen’; biolink ---------------------------------------------------------------------------{http://www.aftenposten.no/alex/litterat/forfatte/christen.htm, http://www.cappelen.no/main/forfatter.asp?f=7011} (1 row) Her ser vi at forfatteren Lars Saaby Christensen har to biolinker i en array:

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

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.

personnr_trigger create trigger personnr_trigger before insert on Kunde for each row EXECUTE PROCEDURE personnr_trigger_function(); (# 'Rolvsøyveien 357', '588B4567', 'lMartin@hotmail.com', '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:

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)

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”

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.  

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

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

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

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