# DEL 1: Normalisering

Et firma som leier ut feriehus lagrer følgende informasjon knytet til utleie:

```
kundedata:                      navn, adresse, telefon
data om eiendommen:             adresse
data om eieren:                 navn, adresse, telefon
data om utleieforholdet:        fra og med uke, til og med uke, pris pr uke
```

Gitt at vi har én tabell med 13 attributter (kolonner) som ser altså slik ut (skrevet på relasjonell form uten nøkler):

__leieforhold (kunde_id, kunde_navn, kunde_adresse, kunde_tlf, eiendom_id, eiendom_adresse, eier_id, eier_navn, eier_adresse, eier_tlf, fra_uke, til_uke, pris)__


I tillegg til dataene nevnt innledningsvis er det lagt inn kunde_id, eier_id og en eiendoms_id, som entydig identifiserer henholdsvis en person og en eiendom.

#### Foreslå kandidatnøkler for denne tabellen.
Anta at en person kun kan leie en eiendom av gangen, og at en eiendom kan leies ut til kun en person av gangen.

> For å unikt identifisere et leieforhold kan man for eksempel bruke supernøkkelen (eiendoms_id, fra_uke). 
>
> Dette er mulig fordi den samme eiendommen bare kan leies ut til en person av gangen. Altså kan man definitivt finne den ene tuppelen som passer disse to nøklene, og derfra utlede til_uke, pris og all data om eieren og kunden.

> Riktignok setter ikke databasen noen begrensning på at samme kunde ikke kan leie flere eiendommer samtidig. Dette må sjekkes i kode eksternt uansett, siden det ikke er nok å sjekke likhet mellom endepunktene.

#### Tabellen er ikke problemfri mht til registrering og sletting av data. Forklar hvorfor.
> Mye av dataen vil dupliseres i denne tabellen, for eksempel om en kunde leier flere eiendommer, samme eiendom flere ganger, eller om en eier har flere eiendommer.

> Dersom data skal endres, for eksempel adresse/navn/telefonnummer til enten eier eller kunde, kan dataen måtte endcres mange steder.

> Dersom man sletter en eiendom, og det er den eneste eiendommen fra en gitt eier, så vil all dataen om eieren slettes.

> Det samme gjelder flere permutasjoner av de faktiske entitetene (leieforhold, eier, kunde, eiendom), at om man vil slette en kan man måtte slette flere.

#### Tegn ett (kun ett) diagram (tilsvarende figur som i læreboka kap. 3) som viser funksjonelle avhengigheter mellom alle attributtene.

Figuren viser avhengighetene slik den er i den opprinnelige tabellen. Blå piler avhenger av hele primærnøkkelen(blått rektangel), og svart pil avhenger av enkeltattributter eller enkeltnøkler. 

  ![Figur 1.1 ](figur_1_1.png)

### Du skal nå bruke funksjonelle avhengigheter og BCNF til å foreslå en oppsplitting av tabellen i mindre tabeller slik at problemene vedr. registrering og sletting av data unngås. Sett opp, direkte fra figuren, relasjoner som er på BCNF.

__Kan vi løse denne oppgaven ved å gjennomføre prosessen 1NF --> 2NF --> 3NF? Begrunn svaret.__

Gitt at vi ikke trenger spørringer basert på deler av adresse (feks gruppering av eiendommer basert på postnummer), er databasen allerede på 1NF.

For å få den over til 2NF trenger vi da å fjerne funksjonelle avhengigheter fra **deler av** primærnøkkelen. I dette tilfellet ser vi at eiendom_adresse og all data om eier følger av eiendom_id.

Derfor trenger vi å dele denne fra en til tre tabeller.

#### Forslag på 2NF:

  ![Figur 2NF](2NF.png)

Her er det ingen partielle avhengigheter, altså avhenger ingen attributter av __deler__ av primærnøkkelen.
Med 2NF er noen av de tidligere problemene løst, for eksempel er det mulig å endre dataen til en eier (navn,tlf,adresse) ved å bare gjøre endringer ett sted. Det er også mulig å slette eiendommer uten fare for å slette data om eieren. 

Altså er flere problemer ved både innsetting, redigering og slettet fikset, men for eksempel problemer tilknyttet å redigere en kunde er fortsatt tilstede. 

For eksempel er det ikke sikkert at man kan endre adressen til en kunde uten flere endringer.
Den bryter fortsatt 3NF, fordi kunde_navn, adresse og telefon avhenger av kunde_id.

#### Forslag på 3NF:

  ![Figur 3NF](3NF.png)

Her er avhengigheten fra kunde_id til de andre kundeattributtene flyttet ut til en egen tabell, slik at alle f.d. utgår av primærnøkkelen. Dette er kravet for 3NF.

I dette tilfellet kan man både sette inn og endre kunder, eiere og eiendommer uten at de påvirker hverandre. For eksempel kan man registrere en ny kunde, uten at den har leid noe enda.

Sletting avhenger av cascading i tabellen, og er ikke garantert å virke uten sideeffekter. Man kan alltid slette leieforhold. Kunder kan slettes om de ikke har noen leieforhold. Eiendommer kan slettes om de ikke er i et leieforhold. Eiere kan slettes om de ikke har noen eiendom.

Her har jeg altså vist at man kan ta denne tabellen fra 1NF til 3NF via 2NF. Dette er ikke gitt for alle relasjoner, men det fungerer for denne.

Skrevet på relasjonsform:
```
kunde(id, navn, adresse, telefon)

eier(id, navn, adresse, telefon)

eiendom(id, adresse, eier_id)

leieforhold(eiendom_id, kunde_id, fra_uke, til_uke, pris)
```