Lektion 3 E/R-modellering

E/R-modellering

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.

Database til televirksomhed

En nystartet televirksomhed ønsker at oprette en database i forbindelse med deres opstart. De skal bruge en database til at drive deres virksomhed, som tilbyder telefon- og internetabonnementer samt salg af mobiltelefoner til både privat- og mindre erhvervskunder.

De skal bruge databasen til at få overblik over deres kunder, varer, abonnementer, ansatte og lignende. De ønsker kort sagt et it-system, der kan opbevare de relevante data, og som kan bruges til at administrere de opgaver, der løbende kommer.

Entiteter og attributter

For at analysere problemet og for at systemudvikleren (jer) kan blive sat grundigt ind i opgaven med at udvikle en it-løsning, laver televirksomhedens it-chef og systemudvikleren en brainstorm sammen.

De indleder med at finde alle de mulige entiteter, som database skal give overblik over. Husk at en entitet er en enhed, der ofte er en enhed i fysisk forstand, fx en kunde, et teleabonnement eller en mobiltelefon.
Dernæst skal I finde på alle de attributter, som hver entitet skal have. Som en regel skal attributterne navngives med entitetens navn efterfulgt af attributten, fx medlemsNavn, medlemsAdresse, osv. Husk at en attribut er en egenskab ved en entitet, fx navn og adresse.

Øvelse 1a: Brainstorm til databasen - model over entiteter og attributter

Som det ses på denne indledende model, er entiteterne tildelt hver sin boks og der kan tilføjes attributter nedenunder. Der er mangler en del entiteter og disses attributter. Disse skal I selv tilføje i jeres egen udgave. Desuden er der ikke tilføjet relationer. Dem kommer vi til senere.

Udfyld ovenstående model med flere entiteter og passende attributter. Husk at navngive attributterne korrekt (se ovenstående). (du kan finde modellen her. Brug funktionen Opret en kopi...)
Sørg for, at der er mindst 6 entiteter. Sørg også for, at der er mindst to attributter til hver entitet.

Øvelse 1b: Brainstorm til databasen - krav til databasen

Udover entiteter og attributter nedskrives også de krav, som en bruger kan tænkes at have til det færdige it-system. Det kan f.eks. være mulighed for at...

indskrive nye kunder
slå en kunde eller et abonnement op og se, hvilken abonnement en kunde har.
slette en kunde, som skifter selskab.

Efter udarbejdelsen af databasen skal den evalueres med henblik på at sikre, at kravene er opfyldt.

Relationer

I sidste afsnit fik vi analyseret vores database med formålet at finde de entiteter og attributter, der skal med i televirksomhedens database. Nu skal vi fortsætte vores E/R-diagram over entiteterne og attributterne og se nærmere på de relationerne der skal være imellem vores entiteter. Vi fortsætter med modellen fra øvelse 1a.

Relationerne betyder kort sagt, at der er en forbindelse mellem to entiteter. Det har en en betydning for nøglerne, som vi skal se nærmere på senere. Det er derfor meget vigtigt, at vi for skabt de rigtige relationer mellem de forskellige entiteter.

Øvelse 2: Lav simple relationer mellem entiteterne

Start med at "tegne" en simpel streg mellem de entiteter, som skal have en forbindelse med hinanden. Tænk nøje over om det giver mening og om det er nødvendigt, at der er en relation mellem entiteterne.

Relationsgrad

Når vi har lavet vores relationer, skal relationsgraden bestemmes. En relationsgrad defineres som antalsforholdet mellem entiteterne, altså om en relationer kan have mange af den anden relation. Fx i en webshop, kan en kunde have mange ordrer, men en ordre kan kun haves af en kunde (ellers kommer man jo til at sælge den samme vare til flere forskellige kunder).

Relationsgraden beskriver antalsforholdet mellem til relationer. Der er fire typer relationsgrader og de illustreres på følgende måde...

En-til-mange

Mange-til-en

Mange-til-mange

En-til-en

En-til-mange

Mange-til-en

Mange-til-mange

En-til-en

Øvelse 3: Tilføj relationsgraden til jeres E/R-model

I skal tilføje de forskellige relationsgrader til jeres model, altså om der skal stå 1 eller M ud for relationen.

Medlemstype

Nu mangler vi at bestemme medlemstypen - så er E/R-diagrammet færdigt. Medlemstype definerer om en relation kan eller skal være tilstede. Det har en betydning for hvordan databasen oprettes. Fx kan en kunde have en relation til ordrer (relationsgraden er kan), men ordrer skal have en relation (relationsgraden er skal), fordi en kunde kan jo godt være en del af databasen uden at købe noget fra webshoppen lige nu, men en ordre må ikke oprettes uden en kunde (fordi så er der jo ingen til at hverken betale eller modtage ordren).

Kan-skal(-til-en)

Kan-skal(-til-mange)

Skal(-til-en)-kan

Skal(-til-mange)-kan

Øvelse 4: Tilføj medlemstypen til jeres E/R-model

I skal analysere hvilken medlemstype der skal være på de forskellige relationer og tilføje dem til jeres model.

Tabelskitser med eksempler

(Tjek din model inden databasen)

Tabelskitser er et mere eller mindre endeligt udkast til tabellerne i databasen. Dvs. de skal optimalt set indeholde de kolonner (attributter), som tabellen kommer til at indeholde.

En tabelskitse er et entitetsnavn efterfulgt af de relevante attributter i en parentes.

Dog er det værd at bemærke, at tabelskitsernes funktioner netop er, at skabe et overblik over de endelige tabeller og dermed fungerer som en form for tjekliste. Man kan derfor bruge dem til at spørge sig selv...

Ser tabellen rigtig ud, når den er udfyldt med eksempler?
Mangler der nogle kolonner, altså attributter, som burde være der?
Er der nogle af kolonnerne, som burde deles op i flere tabeller, fx adresse til vejnavn, husnummer og postnummer?
Burde by have sin egen tabel, hvor postnummer fungerer som primærnøgle? Kan man spare plads i databasen på denne måde? (se fx hvor mange gange man skal skrive en by i samme tabel, hvis flere kunder kommer fra samme by)

Eksempel: Fra tabelskitse til tabeleksempel

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:

Øvelse 5: Lav en tabelskitse over en til to af jeres entiteter (tabeller)

Har skitsen de nødvendige kolonner? Er der nogle af kolonnerne, som skal deles op? Mangler vi viden om entiteten (skal der flere kolonner på)?

Nøgler (keys)

En nøgle er en eller flere attributter, der entydigt definerer et medlem af en entitet.

Der er to former for nøgler i en database: Primær nøgler (primary keys) og fremmednøgler (foreign keys).

En primær nøgle er en attribut i en tabel, der har en unik værdi og identificerer en enhed i tabellen. En primær nøgle kan f.eks. være et kundeId, vareId eller postnummer.

En fremmednøgle er et felt i en tabel, der bruges til at forbinde to tabeller. På den måde henviser en fremmed nøgle til en unik kolonne for at identificere rækker fra en eller samme tabel. En fremmednøgle er altså en (primær)nøgle fra en anden tabel. Når den bruges i en anden tabel, som har sin egen primørnøgle, kaldes den en fremmednøgle, da den refererer til en anden tabel.

I eksemplet nedenfor er "Department_Id" primærnøgle i tabellen "Department".

Samtidig er "Department_Id" fremmednøgle i tabellen nedenunder. I tabellen "Karyawan" er "Karyawan_Id" primær nøgle. Og "Department_Id" er fremmednøgle.

Det betyder, at "Department_Id" er en attribut i tabellen "Karyawan" og forbinder/skaber en relation mellem de to tabeller.

Der er regler for, hvordan nøgler skal navngives og skrives. De navngives altid med tabellens navn først efterfulgt af enten Id eller nummer, fx kundeId, teleAbonnementId, internetAbonnementId, etc.

Nøgler sammenskrives lige som alle andre kolonnenavne enten i camelCase eller snake_case.

camelCase: kundeId

snake_case: kunde_id eller kunde_Id

Spørgsmål til overvejelse!

Hvilke fordele er der ved at have en primær nøgle?
Hvorfor er det godt at have en fremmednøgle?

Entiteten Person kan have nøglen CPR-nummer. Men er det en god ide?
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.

Report abuse