Skip to content

Latest commit

 

History

History
137 lines (95 loc) · 4.85 KB

relasjonsmodellen.md

File metadata and controls

137 lines (95 loc) · 4.85 KB

Øving1

Relasjonsmodellen, del 1

Her er database oppgavene om boligbyggerlaget Bygg & Bo.

a)

Unngå også å lagre data som kan avledes av andre data.

Inkluderte derfor ikke antall bygg i borettslag og antal leligheter i bygg fordi disse kan avledes gjennom å telle hvor mange bygg/leiligheter som referer tabellen.

b)

Oversatt til relasjonsmodellen får vi da:

borettslag(id, navn, adresse, etableringsår)

bygg(id, borettslag*, adresse)

leilighet(id, bygg*, antall_rom, areal, etasjer, leilighetsnummer)

medlem(id, leilighet*, navn, epost)

c)

CREATE TABLE `bygg_og_bo`.`borettslag` (
    `id` INT NOT NULL AUTO_INCREMENT ,
    `navn` VARCHAR(300) NOT NULL ,
    `adresse` VARCHAR(300) NOT NULL ,
    `etableringsår` INT NOT NULL ,
    PRIMARY KEY (`id`)
    ) 
CREATE TABLE `bygg_og_bo`.`bygg` ( 
    `id` INT NOT NULL AUTO_INCREMENT , 
    `borettslag` INT NOT NULL , 
    `adresse` VARCHAR(300) NOT NULL , 
    PRIMARY KEY (`id`), 
    INDEX `id` (`borettslag`)
    ) 
CREATE TABLE `bygg_og_bo`.`leilighet` ( 
    `id` INT NOT NULL AUTO_INCREMENT , 
    `bygg` INT NOT NULL , 
    `antall_rom` INT NOT NULL , 
    `areal` INT NOT NULL , 
    `etasjer` INT NOT NULL DEFAULT '1' , 
    `leilighetsnummer` INT NOT NULL DEFAULT '1' , 
    PRIMARY KEY (`id`), 
    INDEX `id` (`bygg`)
    )
CREATE TABLE `bygg_og_bo`.`medlem` ( 
    `id` INT NOT NULL AUTO_INCREMENT , 
    `leilighet` INT NOT NULL , 
    `navn` VARCHAR(300) NOT NULL , 
    `epost` VARCHAR(350) NOT NULL , 
    PRIMARY KEY (`id`), 
    INDEX `id` (`leilighet`)
    )

d)

Leilighet tabell:

id bygg antall_rom areal etasjer leilighetsnummer
1 2 9 137 3 1
2 1 5 96 1 1
3 1 5 97 1 2

Medlem tabell:

id leilighet navn epost
1 2 Ola Nordmann [email protected]
2 3 Bigga Borsann [email protected]

Gyldig INSERT setning:

INSERT INTO `medlem`(`leilighet`, `navn`, `epost`) VALUES (1, "Brason Manson", "[email protected]")

Id atributtet trengs ikke å refereres fordi det er en AUTO_INCREMENT verdi, altså vi trenger ikke å tenke på det og lar databasen håndtere det for oss.

Dårlig referanse INSERT setning:

INSERT INTO `medlem`(`leilighet`, `navn`, `epost`) VALUES (9, "Feilu Torsu", "[email protected]")

Dette er fordi det ikke finnes noe leilighet med id på 9 og vi får derfor et brudd på referanseintegritetsreglene.

Dårlig identitets INSERT setning:

INSERT INTO `medlem`(`id`,`leilighet`, `navn`, `epost`) VALUES (1 , 2, "Duplikatus Ideus", "[email protected]")

I databasen så har vi allerede et medlem med id av 1, så her får vi brudd på entitetsintegritetsreglene fordi det blir flere elementer med en id på 1. Dette er et problem fordi id skal være en unik identifikator, men det blir ikke lenger det i dette tilfellet.

e)

Når det kommer til at fremmednøkler kan være NULL får vi fra oppgaven at

Det er mulig å være medlem i et borettslag uten å eie en leilighet der

Fra dette kan vi se for oss at fremmednøkkelen til et medlem som peker til en leilighet burde kunne være NULL

Primærnøkkel har som jobb å identifisere et element i en database. Å ha denne primærnøkkelen som NULL betyr jo at vi ikke kan identifisere raden, defor gir det lite mening å sette en primærnøkkel som NULL

f)

I min implementasjon så brukte jeg et auto increment tall som id, hvis man brukte en annen implementasjon (som kombinasjon av adresse og navn) kunne update cascade vært nødvendig på flere steder, med det unnagjort kan vi se på vært tilfelle om vi burde bruke ON DELETE/UPDATE CASCADE

Medlem

Har en fremmednøkkel til leilighet. Hvis leiligheten rives eller brenner ned er det ikke logisk å måtte slette medlemmer fra registeret. Fordi fremmednøkkelen peker til en id som ikke forandres blir det også lite mening å implementere noe update cascade.

Leilighet

Har en fremmednøkkel til bygg. Hvis vi ser for oss den samme situasjonen med et bygg som rives/brennes ned er det da helt logisk at alle leilighetene i det bygget også forsvinner. Så i dette tilfellet kan vi se for oss at ON DELETE kunne vært smart å implementere.

Bygg

Har en fremmednøkkel til borettslag. Vi kan se for oss at et borettslag deles i to eller blir kombinert og da vil byggene forsatt eksistere, derfor blir det lite mening å implementere on delete. Pekes også til en konstant id så update cascade trengs heller ikke.