Vi vil tage udgangspunkt i en konkret case og vil modellere databasen, så de tabeller med data, der indgår i databasen, er relateret til hinanden. Dette kaldes en relationel database.
Formanden for karateklubben Ten Chi Ji har indtil nu forsøgt at have overblik over almindelige medlemmer, bestyrelsesmedlemmer, forskellige typer arrangementer og meget andet i et regneark.
Som det ses, er situationen ved at være helt uoverskuelig, og formanden tager kontakt til en systemudvikler. Han ønsker et it-system, der kan opbevare de relevante data, og som kan bruges til at administrere de opgaver, der løbende kommer.
For at analysere problemet og for at systemudvikleren kan blive sat grundigt ind i opgaven med at udvikle en it-løsning, laver formanden og systemudvikleren en brainstorm sammen.
De finder alle mulige ord, der på en eller anden måde relaterer sig til formandens opgave. Derefter skriver de dem ind i en tabel. Ordene skal ind under den rigtige overskrift, og overskrifterne dækker over følgende:
En entitet er en enhed, der ofte er en enhed i fysisk forstand. Fx. en bil, en person eller en sparkepude.
En relation er en sammenkobling af to entiteter. Fx. medlem ejer bil - her er ejer relationen.
En attribut er en egenskab ved en entitet.
Som det ses, er bil udeladt. Senere kan det være en mulighed at udvide it-systemet, så det også kan håndtere, hvem der ejer en bil. Så vil dette kunne indgå, fx når der skal køres til turneringer.
Udfyld ovenstående tabel med flere ord og flere krydser (du kan finde tabellen her. Brug funktionen Lav en kopi...)
Sørg for, at der er mindst tre entiteter, og at de hænger sammen via mindst to relationer. Sørg også for, at der er mindst to attributter til hver entitet.
Udover brainstorm med formanden nedskrives også de krav, som formanden har til det færdige it-system. Det kan f.eks. være mulighed for at
indskrive nye medlemmer
slå en sparkepude eller andet udstyr op og se, hvem der ejer det
slette et medlem, der melder sig ud af klubben
Efter udarbejdelsen af databasen skal den evalueres med henblik på at sikre, at formandens krav er opfyldt.
I sidste afsnit fik vi analyseret vores database med formålet at finde de entiteter, relationer og attributter, der skal med i vores it-system til klubformanden. Nu vil vi lave et E/R-diagram ud fra entiteterne og relationerne fra vores brainstorm. Det gør vi ved at følge følgende punkter:
For hver entitet skrives entitetsnavnet i en kasse
For hver relation skrives relationsnavnet i en diamant
Den enkelte relation placeres mellem to entiteter, og der tegnes streger mellem dem.
Det vil i vores it-system se sådan ud:
Man vælger navnene på relationerne, så de nogenlunde giver mening, når man læser dem. Hvis vi ser på relationen "deltager i", læses den fra den ene side:
medlem deltager i turnering
og fra den anden side:
turnering har deltagende medlem
Som det ses, er det ikke sprogligt helt godt begge veje. Alligevel vælger man ikke at have to navne til en relation.
Opskriv de to sætninger, der hører til relationen ejer.
Når vi har lavet vores E/R-diagram, skal relationsgraden bestemmes.
Relationsgraden beskriver antalsforholdet mellem til relationer. Der er tre typer relationsgrader:
1-M (en-til-mange)
M-M (mange-til-mange)
1-1 (en-til-en)
Symbolerne 1 og M placeres på E/R-diagrammet ved entiteterne og ved den linje, der hører til den relevante relation. I vores it-system skal de placeres sådan:
Man læser relationsgraderne som følger. Bemærk, at der er ét symbol pr. sætning, og at man læser symbolet så sent som muligt i sætningen.
1-M relationen på ovenstående figur læses:
medlem ejer mange sparkepuder
sparkepude ejes af et medlem
og M-M relationen læses:
medlem deltager i mange turnering(er)
turnering har mange medlem(mer)
Lav et E/R-diagram med entiteterne patient og journal. Lav relationen "har". Her er tale om relationsgraden 1-1.
Lav et nyt eksempel på et E/R-diagram med relationsgraden 1-1.
Er der for hver relation altid kun én mulighed for valg af relationsgrad?
Nu mangler vi at bestemme medlemstypen - så er E/R-diagrammet færdigt
Medlemstypen beskriver, om en entitet kan eller skal deltage i en relation.
Symbolet for medlemstypen skal er en sort blok placeret inde i en entitet. Symbolet for medlemstypen kan er en sort blok placeret uden for entiteten.
I vores it-system kommer det til at se sådan ud:
Man læser medlemstyperne som følger. Bemærk, at man læser én type pr. sætning, og man læser typen så tidligt som muligt i sætningen:
medlem kan eje sparkepude
sparkepude skal ejes af medlem
medlem kan deltage i turnering
turnering skal have medlem
Kan du se en fejl i ovenstående diagram?
Lav et E/R-diagram med entiteterne dyrlæge og hund. Lav relationen har besøgt.
Indtegn medlemstyperne.
Er der her kun én mulighed for valg af medlemstyper?
I analysefasen blev der valgt en række attributter. Vi kan ikke i tabellen over brainstorm se, hvilke attributter der hører til hvilke entiteter. Vi vil starte med at få dette på plads. Vi opskriver entiteternes navne efterfulgt af de tilhørende attributter i en parentes.
I vores it-system kunne det se sådan ud:
Sparkepude (Udgave, Årgang)
Medlem (Fornavn, Efternavn, Alder)
Turnering (TurneringsDato, TurneringsSted, TurneringsNavn)
Som det ses, er der særligt for entiteten Sparkepude et problem. Der kan i klubben være adskillige sparkepuder med samme udgave og fra samme årgang. Her er med andre ord et problem med entydighed. Klubformanden har allerede opdaget dette problem, så han har bedt sparkedpudernes ejere om, at sparkepuderne bliver nummereret. Her klarer vi problemet ved at tilføje attributten SparkepudeNummer til entiteten Sparkepude. Attributten spil er en såkaldt nøgle, fordi den entydigt definerer det enkelte spil. Her vil vi skrive nøgler med fed skrift.
Sparkepude (Udgave, Årgang, SparkepudeNummer)
Ved entiteten Medlem er der også et problem. Hverken attributten Fornavn, Efternavn eller Alder sikrer entydighed. Problemet løses ved at tildele et medlemsnummer i form af nøglen MedlemsNummer:
Medlem (Fornavn, Efternavn, Alder, MedlemsNummer)
Entiteten Turnering har også problemet med, at entydighed ikke er sikret. Her løser vi ikke problemet ved at tildele en ekstra attribut. I stedet slår vi to attributter sammen og laver den koblede nøgle TurneringsDato, TurneringsSted:
Turnering (TurneringsDato, TurneringsSted, TurneringsNavn)
Entiteten Person kan have nøglen CPR-nummer.
Er denne nøgle entydig?
Er der tilfælde, hvor man ændrer en persons CPR-nummer?
Som opgaven ovenfor viser, er det ikke smart at vælge nøgler, der er informationsbærende.
Nu vil vi lave tabelskitser. Disse skitser bruges til at lave de endelige tabeller til databasen.
Tabelskitsen til entiteten elev er
Elev (Navn, Adresse, Fag, Klasse)
og den vil blive til følgende tabel. Bemærk, at der er skrevet data i tabellen i form af eksempler på elever og deres data:
Elev
Når man laver tabelskitser til et helt E/R-diagram, gennemgår man følgende punkter:
For hver entitet laves en tabelskitse med en nøgle.
For hver M-M-relation laves en tabelskitse med nøglerne fra de to relationer som nøgle.
For hver 1-M-relation tages en kopi af nøglen i entiteten ved 1, og denne skrives i entiteten ved M.
Nøglen kaldes da en fremmednøgle i entiteten med M.
For hver 1-1-relation slås de to tabelskitser sammen til en tabelskitse med alle attributterne.
I vores eksempel med it-systemet til klubben Ten Chi Ji er punkt 1 færdigt, og foreløbig ser tabelskitserne sådan ud:
Spil(Version, Årgang, SparkedpudeNummer)
Medlem(Fornavn, Efternavn, Alder, Medlemsnummer)
Turnering(TurneringsDato, TurneringsSted, TurneringsNavn)
Nu udføres punkt 2, og tabelskitserne ser sådan ud:
Spil(Version, Årgang, SparkepudeNummer)
Medlem(Fornavn, Efternavn, Alder, Medlemsnummer)
Turnering(TurneringsDato, TurneringsSted, TurneringsNavn)
Deltager I(Medlemsnummer,TurneringsDato, TurneringsSted)
Efter punkt 3 ser tabelskitserne sådan ud:
Spil(Version, Årgang, SparkepudeNummer, MedlemsNummer)
Medlem(Fornavn, Efternavn, Alder, Medlemsnummer)
Turnering(TurneringsDato, TurneringsSted, TurneringsNavn)
Deltager I(Medlemsnummer,TurneringsDato, TurneringsSted)
Punkt 4 er med vores E/R-diagram unødvendigt, da vi ikke har 1-1-relationer.
Se på 1-1-relationen patient har journal.
Find nogle attributter til entiteterne patient og entiteten journal.
Tegn 1-1-relationen som E/R-diagram.
Lav den tilhørende tabelskitse.