Database Modellering

Vi har haft en frustreret formand for en Trivial Pursuit formand i røret: "Jeg kan ikke overskue at administrere alle vores turneringer!, Hjælp mig kære iftek elever!". Vi vil gerne hjælpe ham ved at oprette en database til administrationen af turneringerne. Men inden vi kan oprette databasen skal vi erhverve viden om dette domæne. Denne viden opbygger vi igennem en analyse og en modellering af Trivial Pursuit turnerings domænet.

Analyse og modellering af et domæne går overordnet ud på, at undersøge hvilke data og hvilken struktur data har. Vi opbygger herfefter en model, der repræsenterer en forsimplet del af virkeligheden. Denne model bliver i databasen realiseret ved tabeller, søjler i tabellerne, og relationer mellem tabeller.

De følgende kriterier skal helst være opfyldt af modellen:

  • Data skal svare til virkeligheden - kaldes også konsistens
  • Det samme data skal kun forekomme et sted - det modsatte kaldes redundans
  • Data skal være relateret til hinanden

Disse punkter vil blive gennemgået i det følgende, samt en forklaring på hvordan, vi netop opnår disse egenskaber i Trivial Pursuit databasen.

1 Analyse

Først skal vi opbygge en viden omkring domænet ved at analysere det. Formanden for Trivial Pursuit Klubben har fortalt os at: "Klubben består af en række medlemmer, og nogle af dem ejer et Trivial Pursuit spil. På træningsaftener har vi svært ved at styre, hvilke medlemmer der tager spil med. Samtidigt vil vi gerne lave træningsaftener i forskellige udgaver fx Genus-udgaven, 1985. Ved turneringer vindes pokaler, som man har, indtil man taber den tilsvarende turnering året efter."

Formanden har yderligere forklaret os at det er i orden at antage at alle turneringer navngives efter den by, de foregår i. Fx hedder turneringer i Odense ”Odense Cup”. Medlemmerne skiftes til at køre til turneringerne.

Ved en analyse starter vi med at brainstorme hvilke oplysninger, der skal kunne trækkes ud af databasen. Analysen indeholder aktører, begivenheder og objekter, der indgår i domænet. Vi skriver disse ned på et stykke papir med cirkler rundt om, resultatet er gengivet nedenfor.

db-analyse.jpg

Opgave/spørgsmål: Hvilke aktører, begivenheder og objekter indgår i domænet for bloggen?

I stedet for aktører, begivenheder og objekter, benyttes inden for emnet databaser typisk begreberne entitet, relation og attribut.

Entitet En entitet er en enhed, der ofte repræsenterer en enhed i fysisk forstand. Fx personer, biler, bøger mv. (typisk navneord)
Relation En relation er en kobling mellem entiteter. Fx ejer et medlem et spil - ejer er relationen mellem medlem og spil. (typisk udsagnsord)
Attribut En attribut er en egenskab, der knytter sig til en entitet. Fx har et medlem et navn, medlemsnummer, adresse mv.

2 Modellering

Vi har nu analyseret vores domæne og fundet ud af, hvilke oplysninger vi overordnet vil kunne trække ud af trivial pursuit databasen.
Næste skridt er at modellere og designe databasen, inden vi konkret opretter en fysisk database.

2.1 E/R diagram

E/R-diagrammer (Entitets/Relations-diagram) er et værktøj til at modellere databaser. E/R diagrammer viser alle entiteter i en database samt relationerne imellem dem. Informationerne herfra benyttes, når databasen oprettes.

erdiagram1.jpg

Entiteterne er illustreret som rektangler og relationerne som romber med streger imellem. I vores eksempel for Trivial Pursuit klubben er medlem, turnering og spil entiteterne.
Relationerne er: ét medlem deltager i en turnering, og ét medlem ejer et spil. Der findes tre forskellige typer relationer:

1-1 en til en
1-M en til mange
M-M mange til mange

Relationsgraden, der står ud for entiteterne, skal fortolkes således:

Relation: Deltager i

M'et ved turnering Fortolkning: "Et medlem deltager i op til mange turneringer"
M'et ved medlem Fortolkning: "I en turnering deltager op til mange medlemmer"

Her er relationen "deltager i" altså en M - M relation.

Relation: Ejer

M'et ved spil Fortolkning: "Et medlem ejer op til mange spil"
1-tallet ved medlem Fortolkning: "Et spil ejes af et medlem"

Her er relationen "ejer" altså en 1 - M relation.

2.2 Fra E/R diagram til database

Det næste skridt er at afgøre, hvordan vi overfører ovenstående E/R-diagram til en database. Entiteterne giver direkte anledning til, hvilke tabeller databasen skal bestå af. Hver tabel består af attributter, som kan defineres ved at opstille såkaldte tupler:

Medlem(MedlemsID, Navn, Adresse, Postnummer, By)
Turnering(TurneringsID, Dato, Sted, Turneringsnavn)

Et spil har en 1-M relation til et medlem, idet et spil kun kan ejes af præcist et medlem, og omvendt at et medlem kan have mange spil. Relationen mellem de to entiteter opnåes ved at angive en reference til medlemmet i Spil tabellen. Da medlemmet er identificeret med et MedlemsId, er det denne attribut der referes til i spil tabellen. Den attribut der et et id for en tabel og benyttes i referencer til tabellen kaldes en primærnøgle.

Vores spil tabel ser ud som følger:

Spil(SpilID, Sværhedsgrad, Årgang, MedlemsID)

I tabellen Medlem er MedlemsID primærnøgle. Når der refereres til primærnøglen MedlemsID i tabellen Spil, kaldes den for en en fremmednøgle.

M-M relationen mellem Medlem og Turnering kræver en ekstra tabel for at blive realiseret. Den nye tabel skal indholde en reference til begge tabeller i form af en fremmednøgle til en primærnøgle i hver tabel.

Deltager i(MedlemsID, TurneringsID)

Opgave/spørgsmål: Hvorfor kan TurneringsID ikke blot indgå i Medlems tabellen ligesom tabellen Spil indholder et MedlemsID, og dermed undgå den ekstra tabel?

2.3 Nøgler

I ovenstående afsnit blev begrebet primærnøgle og fremmednøgle benyttet. Alle primærnøgler er markeret med en streg under navnet.

En primærnøgle er en eller flere attributter, der entydigt identificerer en entitet. Med andre ord skal en primærnøgle være unik for hele tabellen. Det kan fx være et unikt ID, CPR-nummer, telefonnummer, ISBN-nummer mv. En primærnøgle kan også være sammensat af flere attributter, der tilsammen gør entiteten unik, men dette benyttes sjældent i rigtige databaser. En fremmednøgle er en reference til en anden tabels primærnøgle.

Opgave/spørgsmål: Giv et eksempel på en primærnøgle i fx tabellen Turnering.

Opgave/spørgsmål: Giv et eksempel på en sammensat primærnøgle, der består af flere attributter. Tag fx udgangspunkt i tabellen Turnering, hvor du ser bort fra TurneringsID.

Opgave/spørgsmål: Giv eksempler på hvilke fordele det fx giver, at man kun benytter en attribut som primærnøgle? Alternativt hvilke ulemper kan det give at benytte flere attributter som primærnøgle?

Tabellerne kommer herefter til at se således ud:

Medlem

MedlemsID Navn Adresse Postnummer By
1 Helle Holm Odensevej 1 5000 Odense
2 Per Nielsen Aarhusvej 2 8000 Aarhus
3 Vibe Høst Lyngbyvej 3 2800 Lyngby
4 Søren Øst Københavnervej 4 1000 København K
5 Ib Jensen Aalborgvej 5 9000 Aalborg
6 Herta Sørensen Aabenraavej 4 6200 Aabenraa

Turnering

TurneringsID Dato Sted TurneringsNavn
1 01-04-2012 Odense Odense Cup
2 01-03-2012 Miami Miami Cup
3 06-09-2012 Aarhus Aarhus Cup
4 20-11-2012 Lyngby Lyngby Cup

Spil

SpilID Sværhedsgrad Årgang MedlemsID
1 Genus 1985 2
2 Genus 1985 4
3 Familie 1990 1
4 Familie 1990 2
5 Ungdom 1989 5
6 Ungdom 1989 3
7 Ungdom 2008 6
8 Familie 2010 4

Deltager i

MedlemsID TurneringsID
1 1
2 1
4 1
5 1
6 1
1 2
2 2
3 2
5 2
3 3
4 3
6 3
1 4
5 4

2.4 Normalformer

Det er muligt at modellere det samme domæne i en database på mange forskellige måder. Der findes en række kvalitetskriterier der gør det muligt at måle kvaliteten af ens database design. Hvis kriterierne er opfyldt undgås nogle klassiske database problemer. Lad os se på et eksempel:

Problem 1
Vi tager udgangspunkt i vores tabel med medlemmer. I medlemstabellen ønsker vi at lave et dataudtræk på efternavne i stedet for medlemmernes fulde navne. Dataudtrækket er ikke direkte muligt, da efternavnet er placeret i attributten Navn i stedet for i en attribut for sig selv.

Løsning: Del attributten Navn op i attributterne Fornavn og Efternavn.

Problem 2
Følgende tabel indholder en tabel over byer, folk har boet i.

PersonID Fornavn Efternavn Bopæl
1 Helle Holm Struer
2 Per Nitten Århus, København K, Horsens
3 Vibe Høst Århus, Kolding

Attributten Bopæl har flere værdier, hvis en person har boet i mere end en by. Dette databasedesign skaber problemer ved søgninger der inkluderer attributten Bopæl. Problemet kan løses ved at opdele tabellen i to tabeller.

PersonID Fornavn Efternavn
1 Helle Holm
2 Per Nitten
3 Vibe Høst
PersonID Bopæl
1 Struer
2 Århus
2 København K
2 Horsens
3 Århus
3 Kolding

Løsningen til problem 1 og 2 gør, at vores tabel kommer på første normalform (1NF). Definitionen på 1NF er:

  1. Enhver række har en unik nøgle
  2. Søjler indeholder præcis en værdi. Ovenfor var det problematisk at Bopæl indeholdte flere værdier.
  3. Der må ikke være flere søjler der indfanger det samme domæne. Hvis vi havde tilføjet et ekstra bopæls søjle ovenover vil vi være stødt på denne.

Der er flere fordele ved at bringe database designet på 1NF:

  • Søgninger i tabeller bliver lettere, da det bliver lige til at oprette forespøgsler til fx "Hvilke brugere har efternavn lig Holm?" og "Hvilke brugere har boet i Struer?".
  • Opdateringer af en type data influerer ikke på andre typer data, fx opdatering af Efternavn påvirker ikke opdatering af Fornavn.
  • Der kan ikke forekomme redundante (duplikerede) rækker.

Problem 3

Vi tager nu udgangspunkt i turnerings-tabellen i en lettere modificeret udgave bestående af attributterne TurneringsDato, Sted og TurneringsNavn:

TurneringsDato Sted TurneringsNavn
01-04-2012 Odense Odense Cup
01-03-2012 Miami Miami Cup
06-09-2012 Aarhus Aarhus Cup
20-11-2012 Lyngby Lyngby Cup
12-12-2012 Odense Odense Cup

Den primær nøgle er en sammensat nøgle bestående af TurneringsDato og TurneringsSted. Tilsammen udgør de en unik nøgle, da der kun kan afholdes en turnering i samme by på samme dato. Attributten TurneringsNavn er kun afhængig af sted og ikke dato.

Ovenstående design giver anledning til fejl, hvis vi opretter en ny turnering i Odense; så skal vi indtaste "Odense Cup" igen. Desuden, er det besværligt, hvis vi skal ændre navnet på turneringerne. En rettelse i turneringsnavnet vil føre til rettelser i flere rækker.

Problemet kan løses ved at splitte tabellen op i to tabeller. Turneringssted fungerer som fremmednøgle i den nye tabel.

TurneringsDato Sted
01-04-2012 Odense
01-03-2012 Miami
06-09-2012 Aarhus
20-11-2012 Lyngby
12-12-2012 Odense
Sted TurneringsNavn
Odense Odense Cup
Miami Miami Cup
Aarhus Aarhus Cup
Lyngby Lyngby Cup

Vores tabeller er herefter på anden normalform (2NF). Definitionen på anden normalform er:

  1. Databasen skal være på første normalform
  2. Ingen attributter, der ikke selv tilhører en primærnøgle, må afhænge af en del af nøglen (Dette kan ofte forekomme, hvis man har en primær nøgle, som er sammensat af flere attributter)

I det ovenstående eksempel afhang attributten TurneringsNavn kun af turneringssted, og ikke hele nøglen som var Sted og Dato, og derfor spilltedes tabellen op i to.

Problem 4

Tag udgangspunkt i følgende tabel, der indholder planeters måner og afstanden fra planeten til solen.

Måne Planet Afstand Planet/Solen
Jo Jupiter 671000
Europa Jupiter 671000
Dione Saturn 377400

Måne er primærnøgle i tabellen. Attributten Planet er afhængig af Måne. Afstanden er afhængig af planeten. Dermed er afstanden indirekte afhængig af den primærnøgle. Det kan give problemer, hvis der opdages en ny måne til en af planeterne. Når den nye måne skal tilføjes tabellen, skal den henvise til planeten, men samtidigt skal planetens afstand til solen også tilføjes igen med fare for fejl. Et andet problem kunne være, hvis man opdagede, at afstanden var forkert udregnet, og senere skulle ændres. Det vil betyde, at afstanden skal rettes i flere rækker.

Problemet kan løses ved at splitte tabellen op i to. Den første med Måne som nøgle igen:

Måne Planet
Jo Jupiter
Europa Jupiter
Dione Saturn

Den anden med Planet som nøgle:

Planet Afstand Planet/Solen
Jupiter 671000
Saturn 377400

Løsningen på dette problem, hvor en attribut er indirekte afhængig af primærnøglen, kaldes for tredje normalform (3NF). Definitionen på denne normalform er:

  1. Databasen skal være på anden normalform
  2. Ingen attributter i tabellen må være indirekte afhængige af nøglen

Der findes flere normalformer - men vi stopper her.

**Opgave/spørgsmål: ** Hvorfor kan det være en fordel at sikre, at ens tabeller overholder de forskellige normalformer?

Medmindre andet er angivet, er indholdet af denne side licenseret under Creative Commons Attribution-NonCommercial 3.0 License