Avanserte databaser (øving 9, 10, 11 & 12) Tore Mallaug 25.01.2008 Opphavsrett:Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO326D Avanserte Databaser INNLEVERINGSFRISTER (Obligatorisk innlevering innen??): Fredag??: Forstudierapport Fredag??: Utkast til prosjektrapport Fredag??: Ferdig prosjektrapport (ABSOLUTT frist, utsettelse dessverre ikke mulig uten fremvising av legeattest). 1. Innledning Arbeidet med prosjektoppgaven skal gi hver student muligheten til å fordype seg i et, evt. flere, av fagets hovedemner. Studenten kan da velge emner han/hun finner spesielt interessante, og få tilbakemeldinger fra veileder. Generelt deles prosjektet inn i tre deler: 1. Forstudierapport 2. Teoristudium med minst en litteraturhenvisning 3. Et (praktisk) case med løsning(er). Først skrives en kort forstudierapport hvor målene (hvilke resultat ønsker man å oppnå) for oppgaven klargjøres, samt omfanget / begrensninger for case-et. Valg av verktøy (f.eks. Oracle) må også gjøres i denne fasen. Forstudierapporten må så godkjennes av faglærer. Etter forstudien får hver student 3 uker til å gjøre selve prosjektoppgaven og evt. implementasjon (f.eks. SQL-setninger). I denne fasen kan veileder komme med innspill underveis. Arbeidet skal munne ut i en prosjektrapport (inkl. forstudierapporten). Det godtas at 2-3 studenter jobber sammen og leverer et felles prosjekt, hvis gruppearbeidet avtales med faglærer ved prosjektstart. Ved gruppearbeid må det komme klart frem i prosjektrapporten hvem på gruppa som har gjort hva. Det gies individuelle karakterer ut fra arbeidsinnsatsen også ved gruppearbeid dette for å unngå blindpassasjerer. Dette prosjektarbeidet er obligatorisk og teller 40% av sluttkarakteren (eksamen teller 60%). 2. Beskrivelse av mulige prosjektoppgaver MERK DEG: Uansett valg av oppgave under må oppgaveforslaget ditt godkjennes av faglærer for å få karakter i prosjektdelen av faget. Du skal velge en av oppgavene på de neste sidene.
2.1. Egen oppgave 2.1.1. Problemstilling Foreslå en egen prosjektoppgave innen ett av følgende hovedemner: 1. Databaser og XML 2. Datavarehus 3. Temporale databaser (se leksjon 10) 4. Bruk av ontologier (se leksjon 9) Emnene i prosjektet trenger ikke å være tema som er beskrevet i leksjonene. F.eks. er XQuery et mulig emne. Et poeng her er at du/dere kan velge tema som er interessante i f.eks. en jobbsituasjon. Jeg har ikke laget noe forslag til datavarehusoppgave, så her må du evt. finne på noe selv. 2.1.2. Oppgavens deler Forstudie: I tillegg til det generelle nevnt i pkt.3 må det komme klart fram hva du faktisk har tenkt å gjøre og hvorfor. Teoridel: Det kreves minst en litteraturhenvisning i prosjektrapporten til en fagartikkel på web, evt. en webside eller en del av Oracle-manualen o.l. relatert til prosjektoppgaven. Case: Oppgaven skal inneholde et praktisk eksempel (mindre case) som er relatert til en SQLdatabase i Oracle, evt. en annen SQL-databasesystem (MySQL, PostgreSQL...). side 2 av 5
2.2. XML-DB i Oracle for å lagre data om FU-fag 2.2.1. Problemstilling Slik fjernundervisningen ved AITeL kjøres i dag, lages det som dere vet en HTML-side eller php-script, men vi konsentrerer oss her om del delen av sida som inneholder ren HTML-kode) for hver leksjon. Denne siden inneholder læremål, lærestoff og relevante lenker til tilleggslitteratur og web-sider (se f.eks. http://www.aitel.hist.no/fag/dbs/lek01/index.php). Læremål er ren tekst. Lærestoff er selve leksjonen(e) og øvinga, samt evt. referanse til lærebok eller annet pensumstoff (kan være lenker til Web). Lenker er ren tekst eller URL-er til web-sider. I tillegg til dette datainnholdet lages det et løsningsforslag til hver øving. Slik det er i dag lagres alle data over på div. filer på skolens web-tjener. Vi kan tenke oss at vi har en database som lagrer alle disse dataene enten som XML og/eller data på relasjonell form i vanlige tabeller i en SQL-database. Foreslå en løsning for å lagre og representere disse dataene i en database, fortrinnsvis i Oracle (men bruken av Oracle er ikke noe absolutt krav her). En del av oppgaven er å se på bruken av XML-teknologi vs. bruken av vanlige tabeller i en relasjonsdatabase. Hvilke data bør representeres og evt. lagres som XML? Eller bør en ha alle data i vanlige tabeller? Du skal ikke vektlegge brukergrensesnittet, eller applikasjoner, mot sluttbrukere (lærere og studenter). Anta at det implementeres applikasjoner som lagrer og henter ut data fra databaseløsningen din (du skal altså ikke programmere i Java o.l., da dette ikke er et programmeringskurs). En mulig utvidelse av oppgaven er å lagre og evt. representere besvarelser fra studentene i tillegg til leksjonene og øvingene. 2.2.2. Oppgavens deler Forstudie: I tillegg til det generelle nevnt i pkt.3 må du begrense omfanget av oppgaven. Skriv derfor hvilke begrensninger du velger og gjøre, og hvorfor. Teoridel: Det kreves minst en litteraturhenvisning i prosjektrapporten til en fagartikkel på web, evt. en webside eller en del av Oracle-manualen o.l. relatert til prosjektoppgaven. Case: Oppgaven skal inneholde et praktisk eksempel (mindre case) som er relatert til problematikken beskrevet over. 2.3. Normalisering av XML-dokumenter 2.3.1. Problemstilling Et generelt problem vedr. ulike XML-dokumenter, eller XML-meldinger, sendt mellom ulike aktører i et større informasjonssystem er at mange dokumenter typisk vil inneholde en del overlappende data. Et spørsmål er hvordan man bør, eller kan, designe en databaseløsning som er mest mulig normalisert til tross for at man har ulike XML-dokumenter med en del felles data. En komplisert løsning her er å lage et system som oppdager like tags i dokumenter, og som renser vekk dobbeltlagringen fra databasen. Men dette vil kreve programmering og er derfor utenfor pensum i dette faget. Derfor holder det i denne oppgaven at du viser konkrete side 3 av 5
eksempler på XML-dokumenter med like data, f.eks. like persondata eller kundedata, og foreslår en normalisert databaseløsning for eksemplene. 2.3.2. Oppgavens deler Forstudie: I tillegg til det generelle nevnt o pkt. 3 må du beskrive faktiske case på dobbeltlagring. Disse casene må nevnes her. Teoridel: Du bør her søke etter fagartikler o.a. som ser på problematikk knyttet til normalisering av XML-dokumenter. Jeg har sett eksempler på dette. MERK DEG: Jeg forventer ikke at du setter deg inn i kompliserte algoritmer eller formell logikk her. Vi fokuserer på problemet dobbeltlagring i denne oppgaven, ikke formelle metoder for normalisering. Case: Oppgaven bør inneholde minst ett større (evt. flere små) praktisk eksempel på to eller flere XML-dokumenter som inneholder en del felles data, og tanker om hvordan disse dokumentene kan lagres i en database for å oppnå en mest mulig normalisert database. Det er nærliggende å relatere løsninger opp mot en normalisert SQL-database. 2.4. W3C XQuery vs. Oracle SQL 2.4.1. Problemstilling W3C har laget sitt eget spørrespråk spesielt beregnet for å søke i XML-data - se http://www.w3c.org/xml/query. Et spørsmål er hvordan dette spørrespråket er i forhold til vanlig SQL som må sies å være en industristandard i dag. I denne oppgaven skal du forsøke å sette deg inn i XQuery og finne fordeler og ulemper med å bruke dette språket framfor SQL-løsninger. Du kan bruke Oracle s muligheter til å søke og hente ut data fra XML-objekter som et praktisk case. Har du Oracle versjon 10g tilgjengelig sies det at den har støtte for XQuery. Et alternativ er å se på rene XML-databasesystem du finner på Web som har støtte for XQuery. De fleste kommersielle DBMS i dagens marked har i likhet med Oracle løsninger for å lagre og hente ut XML-data, så du kan også vurdere ulike kommersielle løsninger opp mot mulighetene i XQuery - trenger vi egentlig XQuery hvis vi har et utvidet (objektrelasjonelt) SQL evt. SQL/XML tilgjengelig? 2.4.2. Oppgavens deler Forstudie: Se de generelle punktene i pkt. 3. Teoridel: Her bør du studere forskjeller på struktur og syntaks mellom de to spørrespråkene. Case: Lag et databaseeksempel og forsøk å sette opp noen eksempler på spørringer i SQL med tilsvarende spørringer i XQuery (helst testet i samme DBMS om mulig). side 4 av 5
3. Hva skal leveres inn? 3.1. Delrapportering 1: Forstudierapport. Forstudierapporten må inneholde: Kort introduksjon til problemstillingen - hva er problemet og hvorfor? Resultatmål (evt. hovedmål og delmål) Omfanget av oppgaven (hva må du gjøre?) og begrensninger av oppgaven (du kan ikke løse alt, så velg bort noe til fordel for det du vil jobbe med...). Valg av verktøy En kort risikoanalyse - hva kan gå galt? Hva kan påvirke resultatet? 3.2. Delrapportering 2: Prosjektrapport. Prosjektrapporten kommer i tillegg til forstudierapporten over, og må inneholde (minimumskrav) En oversikt over hva som ble gjort. En teoridel. Skriv om minst en fagartikkel, evt. en webside eller en del av Oraclemanualen o.l. relatert til prosjektoppgaven. En oversikt over resultatet fra et praktisk eksempel (case) med dine egne kommentarer Evt. utskrift av implementert database eller annet (SQL-setninger, XML-dokumenter, DTDer, XML-skjema,...). Oppsummering og forslag til videre arbeid (hva kunne ha vært gjort om du skulle ha jobbet videre med oppgaven?). 3.3. Krav til innlevering Forstudierapport og sluttrapport som doc-fil, rtf eller pdf-fil lagt ut på Its Learning innen fredag?? (absolutt frist). Evt. andre dokumenter ved behov (lag i så fall ei zip-fil). Lykke til med prosjektet. Hilsen Tore Mallaug Faglærer side 5 av 5