HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring Kandidatnr: Eksamensdato: 7.desember 2011 Varighet: 0900-1200 Fagnummer: Fagnavn: Klasse(r): LC238D Datamodellering og databaser HING2010HA Studiepoeng: 6 Faglærer(e): Hjelpemidler: Oppgavesettet består av: Vedlegg består av: Faglærer: Else Lervik. Lærebøker, alle håndskrevne og trykte hjelpemidler. 3 oppgaver og 6 sider (inkludert forside og vedlegg) 2 sider Merknad: Oppgaveteksten kan beholdes av studenter som sitter eksamenstiden ut. Lykke til! OBS! Dersom du mener det mangler opplysninger, setter du dine egne betingelser. 1
Oppgave 1 - vekt 40% En database er laget med scriptet i vedlegg 1. Relasjonsmodellen ser slik ut: kategori(kategorinavn) stilling(stillingsnr, tittel, tekst, fra_dato, til_dato, tilbys_av*, status); stilling_kategori(stillingsnr*, kategorinavn*) kunde(kundenr, navn, epost) tilbyder(kundenr_tilbyder*, bransje) søker(kundenr_søker*, url_cv, status) søker_interesse(kundenr_søker*, kategorinavn*) søknad(kundenr_søker*, stillingsnr*, dato, søknadstekst, resultat_intervju, prioritet) Primærnøkler er streket under, mens fremmednøkler er markert med stjerne. (Fremmednøkkelen tilbys_av i tabellen stilling refererer til kundenr_tilbyder i tabellen tilbyder.) Dette er en rekrutteringsdatabase for stillinger. Kundene er av to typer: De som tilbyr stillinger, og de som er potensielle søkere til stillingene. Sammenhengen mellom tabellene kunde, tilbyder og søker framgår av følgende EER-diagram: kunde +kundenr {PK} +navn +epost tilbyder +bransje +url_cv +status søker Tilbyderne oppgir fagområder (kategorier) for stillingene de lyser ut. Det samme gjør søkerne når de registrerer seg. På denne måten er det mulig å matche en søker med aktuelle stillinger eller omvendt. I første deloppgave nedenfor skal du tegne resten av EER-diagrammet. Deretter følger en rekke oppgaver med SQL-spørringer. Du står fritt til å lage virtuelle tabeller (views) for å løse oppgavene. a) Utvid figuren over slik at modellen omfatter hele databasen (du må tegne figuren over på nytt). Bruk UML-notasjon. (Husk at primærnøkler alltid skal markeres i EER-modellen. Fremmednøkler hører strengt tatt ikke hjemme i denne modellen, men om du ønsker kan du ta dem med. Da må du i tilfelle ta med alle, og du må markere dem med stjerne.) b) SQL-spørring: Skriv ut kundenummer, navn, epostadresse og prioritet på alle prioriterte søkere (dvs. prioritet > 0) til stilling nr 5634. Listen skal være sortert etter prioritet. c) SQL-spørring: Finn ut hvor mange (antall) kategorier det ikke eksisterer noen aktuelle stillinger (status = ledig ) innen. 2
d) SQL-spørring: Setningen nedenfor skal være svar på følgende oppgave: Lag en oversikt over antall søknader pr dag i november. SELECT stillingsnr, dato, count(*) "Antall pr dag" FROM søknad WHERE MONTH(dato) = 11 -- anta at månedssyntaksen er riktig GROUP BY dato; Setningen kompilerer ikke. Hvorfor ikke? Skriv den om slik at den blir korrekt. e) SQL-spørring: Skriv ut en liste over aktuelle søkere (status = 'aktiv') til stillinger. En søker er aktuell til en stilling dersom han/hun har minst én kategori i tabellen søker_interesse som er felles med minst én kategori tabellen stilling_kategori for denne stillingen. Stillingen skal også skrives ut dersom det ikke er noen aktuelle søkere til den. Om stillingen skal du skrive ut stillingsnr og tittel. Om søkeren skal du skrive ut kundenummer, søkerens navn og epostadresse. Listen skal sorteres på stillingsnr, slik at alle aktuelle søkere til den samme stillingen kommer etter hverandre. Oppgave 2 vekt 20 % Du skal lage en trigger som sender en epost til aktuelle søkere når nye stillinger registreres i databasen. Anta at følgende java-klasse eksisterer og er lagret i databasen: public class Epost { public static String sendepost(string epostadresse, String stillingstekst) { System.out.println("Skal sende epost til " + epostadresse); System.out.println("Tekst: " + stillingstekst); // her ligger kode for sending av epost, den skal du bare anta at fungerer return "Epost sendt."; } } Å registrere en ny stilling i databasen innebærer å legge inn én rad i tabellen stilling og et visst antall rader i tabellen stilling_kategori. Triggeren skal knyttes til tabellen stilling_kategori og aktiviseres hver gang det legges inn en ny rad i denne tabellen. Metoden sendepost() tar to argumenter: 1. Epostadressen skal hentes fra tabellen kunde 2. Stillingsteksten skal settes sammen av stillingsnr, tittel og tekst fra tabellen stilling. Det skal være kolon etter stillingsnr, og tittelen skal skrives med store bokstaver (bruk funksjonen UPPER()). Eposten skal sendes til en søker dersom søkerens status er lik aktiv og den kategorien som legges inn i tabellen stilling_kategori er identisk med en av de kategoriene som er registrert for søkeren i tabellen søker_interesse. Det skal ikke være nødvendig med ytterligere Java-programmering for å løse oppgaven. Bruk SQL! 3
Oppgave 3 vekt 40% I denne oppgaven skal du arbeide med en datamodell for en treningssenterkjede. Et senter identifiseres med et nummer. I tillegg skal navn og adresse lagres. Kjeden har medlemmer som kan trene på alle sentrene. Et medlem identifiseres med et nummer. I tillegg lagres navn, tlf, epostadresse og dato for innmelding i kjeden. Ved utmelding settes denne datoen lik NULL. Historikk over medlemskapene til den enkelte skal ikke lagres. Det er mange typer ansatte ved sentrene, men vi begrenser oss kun til instruktørene. Det er flere instruktører ved hvert senter, men hver enkelt instruktør har tilknytning til kun ett senter. Om instruktørene lagrer vi et entydig identifikasjonsnummer, navn, tlf, epostadresse og en tekstlig beskrivelse av vedkommendes kompetanse. Databasen skal inneholde en oversikt over treningsrommene ved de enkelte sentrene. Her er det tilstrekkelig å lagre navnet på rommet og arealet. Romnavnet er entydig innenfor det enkelte senteret og skal, sammen med senternummeret, brukes til å identifisere rommet. Treningssentrene tilbyr flere ulike typer aktiviteter: Egentrening. Her trener medlemmet på egen hånd med for eksempel vekter eller kondisjon. Sted (senternummer), dato, klokkeslett for start og slutt, samt en forklarende tekst skal kunne legges inn i databasen. En person kan trene flere ganger pr. dag i samme senter. Spesielle aktiviteter. Dette er for eksempel «Tren 15 ganger i mai og vinn fin premie. Tren 20 ganger og vinn en enda finere premie.» Disse aktivitetene er ikke knyttet til noe bestemt senter. Medlemmene må melde seg på disse aktivitetene. Aktivitetene har et entydig nummer, et navn, en startdato, en sluttdato og poengkrav til 1.premie og til 2.premie (vi ser bort fra andre typer premier). Systemet har en algoritme for å gi poeng til deltakerne som melder seg på, avhengig av hvor mye de trener. Denne algoritmen skal du ikke tenke på i denne oppgaven. Men resultatet fra beregningene er et antall poeng som akkumuleres hos den enkelte deltakeren for den aktuelle aktiviteten. Gruppetrening. Dette er timer med instruktør. Aktuelle aktiviteter er spinning, zumba, vanngym, yoga og forskjellige typer styrketimer. Det fins en fast mengde slike aktiviteter. Gruppetimene er satt opp i en timeplan mandag søndag med starttidspunkt, varighet, et visst antall plasser, rom og instruktør. Anta at varighet og antall plasser er det samme for alle forekomster av samme type aktivitet på et gitt rom. Instruktørene kan være forskjellig avhengig av tidspunkt (dato og klokkeslett). Det er altså ikke slik at det nødvendigvis er samme instruktør selv om timen går på samme tid hver uke. Medlemmene må melde seg på hver enkelt av disse timene. Oppgave Lag datamodell (EER) for problemstillingen. Bruk UML-notasjon. Husk at primærnøkler alltid skal markeres i EER-modellen. Fremmednøkler hører strengt tatt ikke hjemme i denne modellen, men om du ønsker kan du ta dem med. Da må du i tilfelle ta med alle, og du må markere dem med stjerne. Oversett datamodellen til relasjonsmodellen. Strek under primærnøkler og marker fremmednøkler med stjerne. 4
Vedlegg 1 CHECK() er brukt for noen av kolonnene. Det betyr at kolonnen kun kan ha én av de oppgitte verdiene. Eksempelvis kan status i tabellen stilling kun ha verdien ledig, besatt, deaktivert eller NULL. DROP TABLE søker_interesse; DROP TABLE søknad; DROP TABLE stilling_kategori; DROP TABLE stilling; DROP TABLE kategori; DROP TABLE tilbyder; DROP TABLE søker; DROP TABLE kunde; CREATE TABLE kategori ( kategorinavn VARCHAR(20) PRIMARY KEY); CREATE TABLE stilling ( stillingsnr INTEGER NOT NULL PRIMARY KEY, tittel VARCHAR(30) NOT NULL, tekst VARCHAR(200) NOT NULL, fra_dato DATE NOT NULL, til_dato DATE, tilbys_av INTEGER NOT NULL, status VARCHAR(10) CHECK (status = 'ledig' OR status = 'besatt' OR status = 'deaktivert' OR status IS NULL)); CREATE TABLE stilling_kategori ( stillingsnr INTEGER NOT NULL, kategorinavn VARCHAR(20) NOT NULL, CONSTRAINT stilling_kategori_pk PRIMARY KEY (stillingsnr, kategorinavn)); CREATE TABLE kunde ( kundenr INTEGER PRIMARY KEY, navn VARCHAR(20) NOT NULL, epost VARCHAR(30) NOT NULL UNIQUE); CREATE TABLE tilbyder( kundenr_tilbyder INTEGER NOT NULL PRIMARY KEY, bransje VARCHAR(20) NOT NULL); CREATE TABLE søker( kundenr_søker INTEGER NOT NULL PRIMARY KEY, url_cv VARCHAR(100), status VARCHAR(10) DEFAULT 'aktiv' CHECK (status = 'aktiv' OR status = 'ikke aktiv')); CREATE TABLE søker_interesse( kundenr_søker INTEGER NOT NULL, kategorinavn VARCHAR(20) NOT NULL, CONSTRAINT søker_interesse_pk PRIMARY KEY (kundenr_søker, kategorinavn)); CREATE TABLE søknad( kundenr_søker INTEGER NOT NULL, stillingsnr INTEGER NOT NULL, dato DATE NOT NULL, søknadstekst VARCHAR(1000) NOT NULL, resultat_intervju VARCHAR(200), prioritet INTEGER DEFAULT 0, CONSTRAINT søknad_pk PRIMARY KEY (kundenr_søker, stillingsnr)); ALTER TABLE stilling ADD CONSTRAINT stilling_fk1 FOREIGN KEY(tilbys_av) REFERENCES tilbyder; ALTER TABLE stilling_kategori 5
ADD CONSTRAINT stilling_kategori_fk1 FOREIGN KEY(kategorinavn) REFERENCES kategori; ALTER TABLE stilling_kategori ADD CONSTRAINT stilling_kategori_fk2 FOREIGN KEY(stillingsnr) REFERENCES stilling; ALTER TABLE tilbyder ADD CONSTRAINT tilbyder_fk1 FOREIGN KEY(kundenr_tilbyder) REFERENCES kunde; ALTER TABLE søker ADD CONSTRAINT søker_fk1 FOREIGN KEY(kundenr_søker) REFERENCES kunde; ALTER TABLE søker_interesse ADD CONSTRAINT søker_interesse_fk1 FOREIGN KEY(kundenr_søker) REFERENCES søker; ALTER TABLE søker_interesse ADD CONSTRAINT søker_interesse_fk2 FOREIGN KEY(kategorinavn) REFERENCES kategori; ALTER TABLE søknad ADD CONSTRAINT søknad_fk1 FOREIGN KEY(kundenr_søker) REFERENCES søker; ALTER TABLE søknad ADD CONSTRAINT søknad_fk2 FOREIGN KEY(stillingsnr) REFERENCES stilling; 6