(fig.1. Eksempel på en almindelig entity)

Transkript

1 Formål Formålet med denne opgave var, at designe et database system for et fiktivt universitet, ved hjælp af ER-model, for derefter at oversætte det til SQL tabeller. Og dernæst lave en assertion så der skulle forbyde specialestuderende at være instruktorer. Opg. 1 Beskrivelse af ER-model og SQL-tabeller Databasen består af fire almindelige entities; forsker, studerende, institut og hold. Disse fire entities har hver en PRIMARY KEY, så f.eks. en forsker ikke kan blive ansat to gang, og en studerende ikke kan indskrives to gange. Derudover er der to entities mere, som nedarver sin PRIMARY KEY fra en anden entity, studerende, da disse stadig er studerende, men også har en anden funktion, her instruktor og/eller speciale studerende. CREATE TABLE forsker ( f_navn CHAR(30), f_stilling CHAR(20), PRIMARY KEY(f_cpr) (fig.1. Eksempel på en almindelig entity) De fire entities er bundet sammen af seks relations. De relations, hvor en forsker, en studerende eller et institut kun kan være repræsenteret én gang, er der defineret en PRIMARY KEY, så den enkelte kun findes én gang i hver relation. Desuden er der relations hvor der ikke er en PRIMARY KEY, da den enkelte gerne må forekomme flere gange. Ansat-relationen er et eksempel, hvor en forsker gerne må være ansat på flere institutter og institutter gerne må have flere ansatte. CREATE TABLE ansat ( i_id CHAR(10), a_dato DATE, FOREIGN KEY(f_cpr) REFERENCES forsker, FOREIGN KEY(i_id) REFERENCES institut (fig. 2. Ansat-relation) De forskellige relations har en eller flere FOREIGN KEY, hvilket bevirker at den pågældende relation kan blive ændret, i tilfælde af at den data som den består af bliver ændret, dvs. den/de entities som data tages fra. Et eksempel kan være at en ansat på et institut dør og slettes fra forsker entityen, så vil FOREIGN KEY gøre at ansat relationen for den pågældende forsker slettes, da FOREIGN KEY er efterfulgt af, så den slettes. Der er dog andre muligheder end bare at slette, men dette har ikke vist sig oplagt i vores tilfælde. Den sidste entity, hold, som endnu ikke er beskrevet, er et såkaldt weak entity set. Det vil sige at der er en relation mellem to entities, hvor den ene entity ikke har en PRIMARY KEY, men kun en partial key. Det vil sige at bliver den entity, som har en PRIMARY KEY slettet, vil den svage entity også blive slettet, da den er afhængig af den anden, og kun eksisterer som en del af den anden. CREATE TABLE hold ( h_nr Integer, h_tid TIME, h_lokale CHAR(10) CREATE TABLE hold_til ( h_nr Integer, k_kode CHAR(20), PRIMARY KEY (h_nr, k_kode),

2 Tests (fig. 3. Weak entity set hold) For at teste vores database, har vi indtastet den i programmet PostGreSQL. Her har vi prøvet at tilføje studerende, forskere, institutter osv. Da dette ikke har givet nogle problemer og ved slet af studerende, blev den pågældende studerende også slettet i speciale studerende. Dette har vi gjort i hele databasen, som test af alle relations og entitys. Vedlagt som bilag X er en udskrift fra programmet, med alt hvad databasen indeholder. Opg. 2 For at sikre at alle speciale studerende bliver færdige til tiden, besluttes det at de ikke kan være instruktorer. Dette modeleres i databasen som en assertion. Koden er som følger: CREATE ASSERTION ikke_inst CHECK (NOT EXISTS (SELECT I.s_cpr FROM instruktor S)= (SELECT S.s_cpr FROM speciale S) Test: Det som denne assertion gør er, at tjekke at de samme cpr-nr. ikke findes i både instruktor og speciale. Da PostGreSQL ikke understøtter assertions, har vi ikke haft mulighed for at kontrollerer at dette virker, men er dog sikker på at den pågældende kode er rigtig og virker. Konklusion: Da vores SQL i indtastet PostGreSQL virker efter hensigten, og da det er oversat ud fra vores ERmodel, mener vi at have opfyldt opgavens krav. Dog er der flere ting vi ikke har taget stilling til, da dette ikke var opgivet i opgaven. Hvad er relationen mellem instruktor og hold? Skal et institut egentlig have en ansat? Skal en leder af et institut være ansat på det pågældende institut? Dette er dog noget ting som hurtigt kan laves, med et par relations og et par constraints. Dog må vi konstaterer at det er ikke alt fra et ER-diagram man kan overfører direkte til SQL, så som participation constraints.

3

4 CREATE TABLE forsker ( f_navn CHAR(30), f_stilling CHAR(20), PRIMARY KEY(f_cpr) CREATE TABLE studerende ( s_cpr s_studie CHAR(30), s_iaar INTEGER, PRIMARY KEY(s_cpr) CHAR(11), CREATE TABLE institut ( i_adresse CHAR(40), i_budget INTEGER, i_tlf INTEGER, PRIMARY KEY (i_id) CREATE TABLE kurser ( k_kode CHAR(20), k_titel CHAR(30), k_tid CHAR(5), k_lokale CHAR(10), PRIMARY KEY(k_kode) CREATE TABLE ansat ( a_dato DATE, FOREIGN KEY(f_cpr) REFERENCES forsker, FOREIGN KEY(i_id) REFERENCES institut CREATE TABLE leder ( l_dato DATE, PRIMARY KEY (i_id),, FOREIGN KEY (i_id) REFERENCES institut CREATE TABLE tilhoere ( s_cpr CHAR(11),, FOREIGN KEY (i_id) REFERENCES institut CREATE TABLE projekt ( p_start_dato DATE, p_slut_dato DATE, p_omfang CHAR(40), s_cpr CHAR(11),

5 kode CHAR(20),,, CREATE TABLE hold ( h_nr Integer, h_tid TIME, h_lokale CHAR(10) CREATE TABLE hold_til ( h_nr Integer, k_kode CHAR(20), PRIMARY KEY (h_nr, k_kode), CREATE TABLE instruktor ( s_cpr CHAR(11), kontor CHAR(11), CREATE TABLE speciale ( s_cpr CHAR(11), s_dato DATE, s_omfang CHAR(40), CREATE TABLE h_vejleder ( s_cpr CHAR(11), PRIMARY KEY (f_cpr),, CREATE TABLE m_vejleder ( s_cpr CHAR(11), PRIMARY KEY (f_cpr),, CREATE ASSERTION ikke_inst CHECK (NOT EXISTS (SELECT I.s_cpr FROM instruktor S)= (SELECT S.s_cpr FROM speciale S)