Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2007

Like dokumenter
Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008

ITGK - H2010, Matlab. Dagens tema : Teori - Databaser

Introduksjon til fagfeltet

Miniverden og ER- modell

INF Obligatorisk innlevering 7

Hvordan databasesystemene kan hjelpe RAM-produsentene

Hvordan designe en ER-modell med MS-VISIO

2. Beskrivelse av mulige prosjektoppgaver

Databaser: Relasjonsmodellen, del I

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

UNIVERSITETET I OSLO

Løsningsskisse til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Primus Brukerveiledning for masseimport av bilder. Primus 5.6.5

Å bruke Java API-et til å sortere tabeller/arraylister der elementene er (referanser til) objekter

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Gruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>

OM DATABASER DATABASESYSTEMER

INF Obligatorisk innlevering 7

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

VEDLEGG 1 KRAVSPESIFIKASJON

1. Innføring i bruk av MySQL Query Browser

Eksamensoppgåve i TDT4145 Datamodellering og databasesystemer

Gruppe Forprosjekt. Gruppe 15

Enhet for digital dokumentasjon ved HF, Universitetet i Oslo

Bruk av oppgaver og grupper i

>>21 Datamodellering i MySQL Workbench

Innføring i bruk av skolens/barnehagens hjemmesider (for ansatte)

Navigering av en mobil mikrorobot

1. SQL datadefinisjon og manipulering

Løsningsforslag til Case. (Analysen)

Modeller for design av Web-Applikasjoner

Brukerveiledning. For administrering av nettressursen BRUKERVEILEDNING ADMINISTRATOR

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)

Kunnskapsorganisasjon og gjenfinning 1. Relasjonsmodellen og -databaser

Applikasjonsutvikling med databaser

Eksamen i IBE211 Databaser Våren 2017

Obligatorisk oppgave nr. 3 i INF1300 høsten 2009

INF100 INNLEVERING 3 HØSTEN 2004

1. Designe ER-modeller med MS Visio

PROSESSDOKUMENTASJON

D: Ingen trykte eller håndskrevne hjelpemiddel tillatt. Bestemt, enkel kalkulator tillatt.

Databaser. Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen

Implementering av database og tjeneste

1 Kodegenerering fra Tau Suiten

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven Prosessdokumentasjon - Alternativ 1

Rekker (eng: series, summations)

Implementering av database og tjeneste

Plan for dagen. Vprg 4. Dagens tema - filbehandling! Strømmer. Klassen FilLeser.java. Tekstfiler

1. Relasjonsmodellen Kommentarer til læreboka

Kravdokument Innholdsfortegnelse 1 Innledning 2 Bakgrunn og oversikt 3 Detaljerte krav 4 Systemsekvensdiagram

Kravspesifikasjon. Forord

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

INF1050 Systemutvikling

Følgende «tommelfinger-regler» bør (må) følges:

Brukerveiledning Innlegging av prosjekter til NILs årbok

HØGSKOLEN I SØR-TRØNDELAG

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.

Innledende Analyse Del 1.2

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oppgaver Oppgave a: Sett opp mulige relasjoner

IKT for elever Kurs mandag 12. sept Reglement Trådløst nettverk på skolen Ressurser på nett Program og filtyper Lagring

Løsning til Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Innlevering 2b i INF2810, vår 2017

Byggeweb Prosjekt Brukerveiledning Arbeidsområdet

Datamodellering 101 En tenkt høgskoledatabase

DV - CODEC. Introduksjon

ErgoGroup AS eway Nydalsveien 28 Postboks 4364 Nydalen 0402 Oslo Tlf.: Faks:

Rekker (eng: series, summations)

Forprosjekt gruppe 13

Beskjed fra Skagestein

TDT4102 Prosedyre og Objektorientert programmering Vår 2015

Askeladden Release-logg 30. august 2012

Min digitale infrastruktur

P L A N I A 8 S Y S T E M K R A V PLANIA 8 SYSTEM KRAV. Plania 8 Systemkrav.docx av 8

INF1050 Klasseromsoppgave Uke 6

Prosessgrensesnitt. Generell informasjon. Versjon: 2.2

Installasjonsveiledning

Oppgaven består av to deler, del A og del B. Alle skal besvare både del A og del B, men det finnes noen valgmuligheter innenfor hver del.

2 of :19 1 of :19 [Kurssidene] [ ABI - fagsider bibin ]

Prosjektoppgave. i «IMT Objekt-orientert programmering» våren 2016

UNIVERSITETET I OSLO

Veiledning - Avansert kart

Brukerdokumentasjon for LabOra portal - forfattere

Web Service Registry

SQL Structured Query Language. Definere tabeller Skranker Fylle tabeller med data

INF130: Datahåndtering og analyse

Vi skal først lage innhold i fanene, inkludert metadata, deretter vil vi starte å lage leksjonene.

UKE 11 UML modellering og use case. Gruppetime INF1055

Use Case Modeller. Administrator og standardbruker

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

Informasjonsorganisering. Information Architecture Peter Morville & Jorge Arango Kapittel 4, 5 & 6

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

Brukerveiledning Pensumliste

Bruksanvisning. for. Væren og gjesdal.kommune.no

LabOra Gudstjeneste.

Opprette firma. Innhold

Algoritmer og Datastrukturer

Transkript:

Prosjektoppgave: Bildedatabase TDT4145 Datamodellering og Databasesystemer Våren 2007 NB! Kun for de som ikke tar fellesprosjektet.

Innledning I løpet av de siste årene har det blitt stadig mer vanlig å lagre bilder digitalt. Større utbredelse av PC-er, brukbare fargeskrivere, billige scannere og stadig billigere digitalkamera har bidratt til at digital lagring av bilder ikke lenger bare er for profesjonelle fotografer. Digital lagring gjør det også mulig å knytte beskrivelsesdata opp mot bildene på en enkel måte. Dette kan for eksempel gjøres i en relasjonsdatabase. Dessverre kan det være vanskelig for både hobbyfotografer og profesjonelle fotografer å lære seg nok om databaser til å realisere en slik løsning selv. Forretningsideen til Digitalt Album & Sønn er å tilby en komplett databaseløsning som passer fotografer uansett ambisjonsnivå. For en billig penge skal man få tilgang til en ferdig designet database, samt applikasjoner for innlegging og uthenting av både bilder og beskrivelsesdata. I denne oppgaven skal dere designe og implementere bildedatabasen til Digitalt Album & Sønn. Dere skal også lage en enkel Java-applikasjon som tilfredsstiller behovene til mindre krevende hobbyfotografer. Innholdet i databasen kan deles inn i to hoveddeler: Bildedata Digitale utgaver av bilder. Det skal være mulig å lagre mer enn en utgave (versjon) av hvert bilde. Slik kan f.eks. mobile terminaler (som PDA-er og mobiltelefoner) få levert en liten utgave, mens stasjonære PC-er kan få en større. Metadata Beskrivelser tilknyttet et bilde. Hvem har tatt bildet og med hvilket kamera? Når og hvor ble bildet tatt? Hvem er til stede på bildet? Nøyaktig hva som skal lagres er beskrevet i kravspesifikasjonen på neste side. Prosjektoppgaven består av tre deler. Først skal dere designe en konseptuell datamodell som tilfredsstiller alle oppgitte krav til datamodellen. Deretter skal denne modellen realiseres som en relasjonsdatabase i Oracle. Til slutt skal det lages en enkel Java-applikasjon som ved hjelp av JDBC gjør det mulig å legge inn og hente ut data fra databasen.

Kravspesifikasjon 1. Systemet skal lagre bilder i en database. For hvert bilde skal det lagres en tittel, en beskrivelse og datoen da bildet ble tatt (eksponeringsdato). Det skal også lagres om bildet kan publiseres offentlig eller om det skal regnes som privat. 2. Hvert bilde har ett eller flere utgaver. En utgave er en versjon av et bilde f.eks. et JPEG-komprimert bilde på 800x600 piksler. Hver utgave skal ha en innleggingsdato og muligheter for registrering av en beskrivelse. (Se sist i oppgaveteksten for informasjon om hvordan man lagrer bilder i databasen) 3. For hver utgave skal det registreres hvordan det er digitalisert. Gyldige alternativer skal være kun: Digitalkamera, filmscanner, flatbedscanner, trommelscanner og vet ikke. 4. Hvert bilde kan være en del av en (og bare en) film. Hver film har en produsent (f.eks. Fuji), type (f.eks. Reala) og følsomhet (f.eks. ISO 100). Det skal også kunne lagres hvilket nummer i filmen et gitt bilde er. 5. Det skal være mulig å registrere med hvilket kamera et bilde er tatt. Hvert kamera er eid av en fotograf. For et kamera skal det lagres merke, modell og om det er digitalt eller ikke. 6. Det skal være mulig å registrere hvilken fotograf som har tatt et bilde. For fotografer skal det lagres fornavn og etternavn. E-post adresse, beskrivelse og hjemmeside-url skal det også være mulig å lagre. 7. Bildene skal kunne tilhøre en eller flere kategorier. Eksempler på kategorier: Feriebilder, Høytid og fest og Skogsturer. Hver kategori skal ha en tittel og en beskrivelse. Navn på kategorier skal ikke hardkodes i databasen hver bruker skal legge inn sine egne. 8. Hver kategori skal kunne ha en overkategori og en eller flere underkategorier. For eksempel kan kategorien Feriebilder ha underkategoriene Maldivene 2000 og Hardangervidda høsten 2001. 9. Hvert bilde skal kunne være med i en eller flere bildeserier. En bildeserie har et navn og mulighet for en beskrivelse. Eksempel: Mine beste bilder 2000. Rekkefølgen til bildene i en serie skal også lagres. 10. Hvert bilde skal kunne ha ett eller flere motiv. Et motiv er enten en person, et sted, en hendelse eller et objekt. 11. For personer skal fornavn, etternavn og beskrivelse lagres, mens navn og beskrivelse skal lagres for sted, hendelse og objekt. 12. Steder er enten land, fylker, kommuner eller områder. Et område ligger i en kommune, en kommune ligger i et fylke og et fylke ligger i et land. Hvis et bilde er tatt i et annet land enn Norge, skal kun land og område registreres (område ligger da direkte i et land). En oversikt over alle fylker og kommuner i Norge er lagt ut på http://www.idi.ntnu.no/emner/tdt4145 slik at dere slipper å registrere slike data manuelt.

Oppgaver Oppgavene går ut på å gjennomføre en praktisk databasekonstruksjon for systemet, med utgangspunkt i de fremsatte kravene. I praksis vil det si at dere lager en konseptuell datamodell for systemet, realiserer den i Oracle, og benytter denne databasen ved hjelp av JDBC i en implementasjon av deler av systemet. Praktiske opplysninger Denne prosjektoppgaven skal løses i grupper med maksimalt 5 studenter. Gruppene setter dere sammen selv. Send en e-post til tdt4145@idi.ntnu.no med navnet og e-postadressen på alle i gruppa. Hvis ikke annet er oppgitt i oppgaveteksten, skal øvingene leveres i en merket boks i vrimleområdet utenfor F1 før kl. 16.00 på innleveringsdagen. De tre innleveringene prosjektet er organisert på følgende måte: Innlevering Tidsfrist Oppgave 1 02.03.07 Oppgave 2 09.03.07 Oppgave 3 02.05.07 For å få prosjektet godkjent, må man ha alle delinnleveringene godkjent. Det er også en veldig god ide å få en delinnlevering godkjent før man leverer inn neste slik at man slipper å dra med seg feil. Oppgave 1: Konseptuell datamodell Dere skal lage en konseptuell databasemodell som oppfyller kravspesifikasjonen på alle punkter. Det er to ting som skal leveres: 1. Et diagram som viser datamodellen. Det er valgfritt om dere vil bruke UML eller EER, og om dere vil tegne for hånd eller bruke modelleringsverktøy. Uansett skal modellen leveres på papir. Ta med alle entitetsklasser, relasjonsklasser, kardinaliteter og (eventuelle) eksistensavhengigheter og svake entitetsklasser. 2. Et dokument som beskriver hvordan modellen oppfyller kravspesifikasjonen. For hvert nummerert krav i kravspesifikasjonen skal det kort (et par linjer burde holde) forklares hvordan modellen deres oppfyller kravet. Dette skal også leveres på papir. For å bli godkjent må modellen deres oppfylle absolutt alle krav i kravspesifikasjonen. Kravoppfyllelsesdokumentet er en forutsetning for at vi skal kunne sjekke dette noenlunde enkelt, så innleveringer uten dette vil ikke bli godkjent. Husk å skrive gruppenummer og navn på alle i gruppa på innleveringen. Leveringsfrist: 2. mars

Oppgave 2: Logisk databaseskjema Den konseptuelle modellen fra Oppgave 1 skal omformes til et logisk databaseskjema, i form av et SQL-skript som skal kunne brukes til å generere en relasjonsdatabase i Oracle. Det er to ting som skal leveres: 1. Et kjørbart SQL-skript som genererer databasen. Husk alle primær- og fremmednøkler, og eventuelt andre restriksjoner (constraints). Dette skal leveres på papir. 2. Oppgave 1-innleveringen. Hvis dere har endret modellen siden oppgave 1, lag en revidert versjon av modellen. Dere står fritt til å endre datamodellen til enhver tid, men alle krav må alltid være oppfylt. Husk å oppdatere kravoppfyllelsedokumentet, og marker endringene slik at vi slipper å sjekke alt på nytt. Vitsen med å levere inn oppgave 1 igjen, er at vi skal kunne kontrollere at dere har laget SQL-koden korrekt i henhold til modellen. Det må derfor være samsvar mellom modellen og SQL-koden for at innleveringen skal bli godkjent. Husk å skrive gruppenummer og navn på alle i gruppa på innleveringen. Leveringsfrist: 9. mars Oppgave 3: Databaseprogrammering med Java/JDBC Dere skal lage en begrenset implementasjon som gjør det mulig for hobbyfotografer å bruke databasen til Digitalt Album & Sønn. Nøyaktig hvilke krav implementasjonen skal tilfredsstille er gitt under. Programmet skal lages som en Java-applikasjon som bruker JDBC for kommunikasjon med databasen. Det er tre ting som skal leveres: Et kjørbart program, helst i form av en kjørbar jar-fil. Leveres elektronisk pr e-post til tdt4145@idi.ntnu.no. (Les http://java.sun.com/docs/books/tutorial/jar/index.html for å lære om jar-filer.) Kildekoden til programmet. Leveres også elektronisk til tdt4145@idi.ntnu.no. En EER/UML-modell (med attributter) av de delene av databasen dere benytter I programmet. Denne kan være forskjellig fra den tilsvarende delen av det dere leverte I DB2, men alle relevante krav fra kravspesifikasjonen på være oppfylt (dvs. Modellen skal kunne inngå i en større modell som oppfyller alle kravene i kravspeken). Leveres elektronisk til tdt4145@idi.ntnu.no eller på papir. Kravspesifikasjon 1. Implementasjonen trenger kun å omfatte de delene av datamodellen som er dekket av følgende krav fra den opprinnelige kravspesifikasjonen: 1, 2, 5 og 6. Det vil med andre ord si bilder, utgaver, fotografer og kamera. 2. Implementasjonen trenger kun å omfatte uthenting av data - innlegging av data kan dere gjøre manuelt f.eks. ved bruk av SQL*Plus eller SqlClient 3. Ved oppstart av applikasjonen skal det vises en liste over bilder registrert i databasen. 4. For hvert av bildene skal det være mulig å få se hvem som har tatt bildet og med hvilket kamera samt en liste over registrerte utgaver av bildet. Det skal være mulig å velge en utgave for så å se det. 5. Det skal være mulig å søke på bildetittel, bildebeskrivelse, fotograf-fornavn, fotografetternavn og fotograf-beskrivelse. Resultatet skal være en liste med bilder.

Kildekode For å unngå at all tid går med på ikke-db-relatert Java-programmering, får dere utdelt kildekode til et nesten ferdig program. Kildekoden består av fire filer: DB3.java Hovedprogrammet Picture.java - Bilde-klasse Version.java - Utgave-klasse ImageLoader.java - Klasse for lasting av bilder inn i databasen I toppen av hver java-fil er det listet opp hva dere må gjøre. For å få programmet til å fungere trengs noen ekstra Oracle-klasser. Disse finnes i oracle9.jar, ordim.zip, ordimimg.jar og runtime12.zip. Alle filene finnes på http://elefant.idi.ntnu.no Husk å skrive gruppenummer og navn på alle i gruppa på innleveringen. Leveringsfrist: 2. mai Lagring av bilder i Oracle Når dere skal gjøre oppgave 2 og 3, trenger dere å vite hvordan man lagrer bilder i Oracle. Tidligere gjorde man dette ved å bruke datatypen BLOB (Binary Large Object), noe som gjorde at Oracle behandlet et bilde som en mengde med bytes. Nyere versjoner av Oracle inneholder derimot en komponent kalt intermedia som bl.a. innholder spesielle datatyper for bilder, lyd og video. Det gjør det mulig å tilby spesiell funksjonalitet som f.eks. formatkonvertering, skalering o.l. I tillegg finner Oracle selv ut ting som bildeformat og bildedimensjon slik at man ikke trenger å lagre dette selv. I denne prosjektoppgaven skal intermedias datatype ORDImage brukes til å lagre bildedata. Siden ORDImage skiller seg litt ut fra vanlige datatyper som NUMBER og VARCHAR, gir vi dere litt hjelp til å komme i gang. På http://www.idi.ntnu.no/emner/tdt4145 vil dere etter hvert finne Javakode for å legge inn og hente ut bilder som ORDImage. Husk også at dokumentasjon til Oracle ligger tilgjengelig på http://gigabase.idi.ntnu.no/oradoc/.