Vi har haft en frustreret formand for en Trivial Pursuit forening 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 elektronisk 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 der indgår og hvilken struktur data har. Vi opbygger herefter 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

Opgave 1

Hvorfor er ovenstående tre kriterier vigtige for at kunne tale om en god database?

Ovenstående tre kriterier 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.

Opgave 2

Hvilke aktører, begivenheder og objekter er medtaget i ovenstående analyse i forhold til oplysningerne fra telefonopringningen?

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

2 Design

Vi har nu analyseret vores domæne og fundet ud af, hvilke oplysninger vi vil have med i trivial pursuit databasen. Næste skridt er at modellere og designe databasen, inden vi konkret opretter databasen elektronisk.

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.

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:

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

Relation: Deltager i

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

Relation: Ejer

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

2.2 Fra E/R diagram til tabeller

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 3

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 4

Giv et eksempel på en primærnøgle i fx tabellen Turnering.

Opgave 5

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 6

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

Turnering

Spil

Deltager i

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.

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.

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

Definition 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:

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 en mulig fejl når vi opretter den nye 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.

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

Definition på 2NF 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 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:

Den anden med Planet som nøgle:

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

Definition på 3NF 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 7

Hvorfor kan det være en fordel at sikre, at ens tabeller overholder de forskellige normalformer?

3 Implementering

Nu mangler det bare at realisere vores design elektronisk. dette kan gøres i et vilkårligt databasesystem.