Datamodellering: eit crashkurs

I analyse- og designfasane av eit utviklingsprosjekt for eit datasystem er det nødvendig å definera kva slags modular og program ein behøver, og ikkje minst beskriva datastrukturen. Dette kallast for datamodellering, og gir viktig input til dei neste fasane. Ulike virksomheter har egne rutinar og rammer for korleis dette skal gjerast, og litteraturen er helle ikkje eintydig. Men for oss betyr datamodellering det å laga ein såkalt Entitet-Relasjonsmodell (ER modell) dvs. enten ein visuell representasjon eller ein beskrivelse som forklarer / viser entitetane (= tabellane*), relasjonane mellom entitetane, attributtane (= kolonnene) samt evt. også datatypar og begrensningar.

1. Finn entitetane: Entitetar er typisk eit substantiv som bil, bank eller produkt.

I eit ER-diagram, er entitetane den viktigste biten. Ein entitet er den "tingen" som vi vil lagra informasjon om. Det kan vera konkret som "person", "rom", "bil" osv. eller det kan vera meir abstrakt som hendelsar (fotballkamp, kurs osv.) Vi tenkjer oss at vi skal laga eit enkelt system som skal lagra informasjon om studentar og kva kurs dei går, samt om professorane som underviser på kursa. Her har vi altså tre entitetar: “Student,” “Kurs,” og “Professor.”

2. Finn relasjonane: Relasjonane viser samanhengen mellom entitetane.

Relasjonar er typisk verb som “kjøper,” “inneheld,” eller “bur i” I vårt eksempel kan vi lesa diagrammet frå venstre mot høgre når vi bruker den øverste merkelappen. Altså: ein Student går på Kurs, og Eit Kurs blir undervist av Professor. Hvis vi bruker dei nederste merkelappane, så kan vi lesa frå høgre mot venstre: Ein Professor underviser Kurs, og Eit Kurs blir tatt av Student. Dei to relasjonane er altså "blir tatt av / går på" og "underviser / bir undervist av".

Du merka nok at vi her hadde utelatt tallorda, fordi den første figuren viser ikkje det. Så vi må finna ut om ein bestemt forekomst av entiteten "Student" kan ha relasjone med ein eller fleire av entiteten "Kurs". Den neste figuren viser dette. Vi har lagt  til symbola "0" som står for ingen, "I" som står for ein, samt "kråkefoten" som står for mange. Frå venstre mot høgre kan vi derfor lesa:

Ein student kan gå på mange Kurs. Samtidig kan vi lesa motsatt vei og få: eit Kurs kan bli tatt av mange Studentar. Det betyr at den første relasjonen er ein mange-til-mange-relasjon. Den andre relasjonen kan også vera det, men la oss no bare bestemma oss for at ei Kurs blir undervist av ein Professor, men motsatt kan ein Professor undervisa i mange Kurs. Då får vi ein ein-til-mange-relasjon. Dermed kan vi tegna modellen vår slik:

Som vi ser er det to symboler i kvar ende av relasjonen. Det som er nærmast entiteten står for det maksimale antalet, og det ytterste for det minimale. Vi kan altså lesa dette slik: Ein Student kan gå på minst eitt kurs (ellers er ho ikkje student) og maks fleire. Heil til høgre i blidet er det to "ein"-symboler. Det kan vi lesa som at eit Kurs blir undervist av minimum ein (det bør det vera) og maksimum ein Professor. Med andre ord må det vera ein og bare ein professor slik vi har definert oppgava her. Men motsatt vei kan vi lesa at ein Professor underviser minimum 0, og maksimum mange Kurs. For det er jo slik at ikkje alle professorar underviser heile tida. (heldiggrisane) 

Ein slik modell som den vi har over, der bare entitetane og relasjonane er vist, kallast ofte for ein konseptuell datamodell. Den viser dei store linjene i datastrukturen , og er basis for neste steg i analysen.

3. Legg til attributtar: Attributtane viser egenskapane til ein entitet.

Så kjem vi til det som det heile handlar om, nemlig kva data vi er interessert i å lagra. For kvar entitet vil vi lagra informasjon om denne entiteten. Eksempel kan vera som vist på figuren under:

Oppgava, eller kva databasen skal brukast til, vil bestemma kva egenskaper vi treng å lagra. Men vi treng alltid ein måte å identifisera kvar forekomst av ein entitet. Derfor må kva entitet ha ein nøkkel. Her er ID nøkkel i Student-tabellen. Det betyr at den må vera unik. I kurs er nøkkelen Kode og i Professor er det også ID. Hvis vi seinare skal skilja mellom disse to ID-ane, kan vi gjera det ved å ta med tabellnavnet. Det vil sei at vi kan referera til den første som Student.ID og den andre som Professor.ID.

4. Entitetisering

Mange beskrivelsar av datamodellering stoppar her. Men for å kunna realisera modellen som ein SQL-database, så må vi jobba vidare med mange-til-mange-relasjonen Student - Kurs. Som figuren over viser, kan relasjonen Kurs - Professor realiserast ved å legga inn fremmednøkkelen ProfessorID i Kurs. Den fortel kva professor som underviser i kvart kurs. Men mellom Student og Kurs kan ikkje vi gjera det slik. For prøver vi å leggja KursID som fremmednøkkel i Student, så betyr det at ein student bare kan ta eit kurs. Og hvis vi prøver motsatt, dvs. å leggja inn ein fremmednøkkel StudentID i Kurs, så får vi samme problemet, nemlig at eit kurs bare kan bli tatt av ein student. Ein mange-til-mange-relasjonar må altså realiserast på ein annan måte:

Her har vi altå introdusert ein ny tabell "Kursdeltagelse", som skal ta seg av relasjonen Student - Kurs. Ein slik tabell kallast ofte for ein koblingstabell, og det å introdusera ein koblingstabell kallast for entitetisering. Her har vi to kolonner, StudentID og KursKode, som begge er fremmednøklar. Disse fortel altså kva kurs ein student går på. Til saman blir disse to også primærnøkkelen i denne tabellen, og derfor treng vi ingen ID eller liknande. 

På dette stadiet av analysen vil ein som regel gjera ein normalisering av modellen for å fjerna redundans, feil og konflikter. Sjå egen artikkel om dette.

No har vi laga det som kallast ein logisk datamodell, der vi altså har tatt med alle nøklar og fremmednøklar og alle nødvendige tabellar. Det neste vi treng å gjera er å laga ein fysisk datamodell. Det inkluderer å bestemma datatypar og begrensningar osv. Ofte vil vi gjera dette i eit verktøy som Workbench. es meir om datamodellering i Workbench. 

NOTER

* Spørsmålet er om alle tabellane i ein database også er entitetar? I dei tilfella vi ikkje brukar tabellen til anna enn som kobling, så kan dette saktens diskuterast. Men ofte vil det vera hensiktsmessig å leggja inn fleire attributta her. For eksempel kan vi tenkja oss å leggje inn eit attributt "godkjent" som fortel om studenten har fått godkjent alle obligatoriske oppgaver, og kan melda seg opp til eksamen. I det tilfellet er det ingen tvil om at Kursdeltagelse også er ein entitet.