Datamodellering

Ein database skal vere ei gjenspegling av verkelegheita, men han skal samtidig ikkje innehalde meir data enn det som er nødvendig. Vi treng å strukturere dataet på ein måte som gjer det effektivt å finne, leggje til og endre data. For å komme fram til ein slik struktur er det nyttig å lage ein visuell modell av databasen. Då kan ein sjå kva forhold dei ulike dataa har til kvarandre og på den måten lage ein solid struktur for databasen. Å lage ein visuell modell av databasen gjer det òg enklare å sørgje for at databasen er robust og godt designa. Med eit godt databasedesign kan vi sørgje for at det ikkje så lett oppstår feil i databasen.

Før du lagar ein datamodell, må du stille deg sjølv ein del spørsmål og sjå for deg korleis databasen skal brukast.

Den vanlegaste typen datamodell blir kalla ER-diagram. ER står for Entity-Relationship og blir brukt for å planleggje relasjonsdatabasar. I ER-diagram har vi entitetar, eller tabellar, som er kopla saman med relasjonar.

Nokon gonger kan vi ha all informasjonen vi treng i éin tabell, men som oftast treng vi fleire tabellar for å halde orden på informasjonen.

Viss du skal lage ein database med informasjon om venene dine, treng du kanskje berre éin tabell, slik som denne:

Datamodellen for denne tabellen kan sjå ut som på biletet til høgre. Legg merke til at i tillegg til namn på kolonnane i tabellen er det lagt inn informasjon om kva type data som skal lagrast i dei ulike felta. Vi kjem tilbake til datatypar seinare.

Du kan òg sjå at vi har lagt til eit felt i datamodellen som heiter VeneID, og denne har ein liten nøkkel ved sida av seg. Dette er eit identifikasjonsnummer som er unikt for kvar person som blir lagd inn i databasen. Ut frå denne ID-en kan vi finne all annan info om ein person i tabellen. Dette feltet med unike data blir kalla primærnøkkelen til tabellen. Vi kunne òg brukt eit eksisterande felt som primærnøkkel, men då må vi vere sikre på at dataet som skal leggjast inn i det feltet, er heilt unik. Det bør heller ikkje vere data som kan endrast, då primærnøkkelen òg blir brukt til å kople tabellar saman. Telefonnummer kan vere eit døme på eit slikt felt som er unikt for kvar person, men som likevel ikkje passar som primærnøkkel. Ein primærnøkkel bør heller ikkje vere noko som kan endrast. Derfor er det vanleg å opprette ein slik ID. Vi skal komme meir tilbake til primærnøklar etterkvart.

I tabellen over ser du at vi har lagt inn postnummer og poststad. Dette er to felt som heng saman, då alle radene i tabellen med same poststad alltid vil ha same postnummer. Vi seier at det er ein avhengnad mellom dei to felta. Når du lagar databasar, bør du unngå avhengnader i tabellen, då det enkelt kan føre til at ukorrekte data kan leggjast inn, til dømes viss du stavar ein poststad feil. For å unngå avhengnad skil vi ut postnummer og poststad i ein eigen tabell. Vi får då to tabellar:

Kopl saman tabellane

No har du to tabellar med informasjon: éin med informasjon om vener og éin med informasjon om postnummer. For å bruke denne informasjonen i praksis må du kople tabellane saman med ein relasjon. Det gjer vi både visuelt i ein datamodell og praktisk ved å setje inn ein framandnøkkel i den eine tabellen. For å forklare korleis dette blir gjort teiknar vi opp ein datamodell med dei to tabellane og ein relasjon imellom.

Her ser du datamodellen med postnummer skilt ut i ein eigen tabell. I postnummer-tabellen er det feltet postnummer som er primærnøkkelen, då det vil vere unikt for kvar linje i tabellen. Når eit felt har informasjon som er heilt unik og som må fyllast ut, treng vi ikkje lage ein eigen ID.

Mellom dei to tabellane ser du ei linje med nokre teikn på endane. Denne linja blir kalla ein relasjon og angir at desse to tabellane er kopla saman. Teikna på endane angir at dette er ein éin-til-mange-relasjon. Vi skal komme tilbake til dei ulike typane relasjonar seinare, men i dette tilfellet betyr det at éin ven kan ha eitt og berre eitt postnummer, medan eitt postnummer kan høyre til null eller fleire vener.

Når vi lagar ein éin-til-mange-relasjon, må vi leggje inn primærnøkkelen frå tabellen på "éin-sida" inn som eit ekstra felt i tabellen på "mange-sida". Dette er for å kunne kople saman informasjonen i praksis. Det ekstra feltet på mange-sida blir kalla ein framandnøkkel og er ei direkte kopling til primærnøkkelen på éin-sida. I figuren over kan du sjå at feltet postnummer i Vener-tabellen har ein raud firkant føre seg. Det angir at dette feltet er ein framandnøkkel. Det betyr at postnummer i Vener-tabellen er kopla til primærnøkkelen postnummer i postnummer-tabellen, og det er denne koplinga som blir brukt for å finne poststad som høyrer til postnummeret.

Tenk deg at du skal lage eit bilregister der du skal lagre informasjon om ei rekkje bilar og kven som eig dei. Då treng du både informasjon om personar og om bilar. I tillegg veit du at ein person kan eige éin eller fleire bilar, og at ein bil kan berre ha éin eigar. Då veit du allereie at det her dreier seg om ein éin-til-mange-relasjon med to tabellar, éin for informasjon om bilen og éin for informasjon om bileigaren.

For å lage ER-modellen over må du først spørje kva slags informasjon som er nødvendig. Når du skal lagre informasjon om kven som eig ein bil, treng du informasjon om namn og telefonnummer, men du treng ikkje informasjon om kjønn, årsinntekt og skostorleik. Når du skal lagre informasjon om ein bil, er det svært mykje informasjon du kan leggje inn, og då må du avgjere kva slags info som er nødvendig. Til dømes bør du alltid ha med informasjon som registreringsnummer, bilmerke, modell og årsmodell, men informasjon som farge, talet på sete og hjuldimensjon kjem an på kva du skal bruke informasjonen til.

Når du har laga tabellane og lagt inn felta, står berre att det å lage ein relasjon mellom tabellane. Denne kan vere éin-til-éin (1:1), én-til-mange (1:n) eller mange-til-mange (n:m). I dette tilfellet bruker vi éin-til-mange-relasjon, då vi kan seie at ein bil har berre éin eigar, men ein eigar kan eige mange bilar.