Datamodellering 101 En tenkt høgskoledatabase

Transkript

1 Datamodellering 101 En tenkt høgskoledatabase Spesifikasjoner for databasen vi skal modellere: Oversikt over studenter med: Fullt navn Klasse Studium Avdeling Brukernavn Fødselsdag Adresse Telefonnummer Oversikt over studier ("linjer") med: Studiekode Navn Avdeling Studenter Fag Studieansvarlig Oversikt over avdelinger med: Navn Studier Studenter Begrensninger og tydeliggjøringer: En student kan kun ta ett studium. En lærer hører kun til én avdeling (men kan naturligvis undervise i flere studier.) Etter vi har gjort oss kjent med spesifikasjonen: Denne spesifikasjonen er skrevet uten hensyn på hvordan modellen faktisk kommer til å se ut. Den forholder seg ikke til hvordan databasen teknisk sett vil henge sammen, men er en rå fremstilling av hvilke data som skal være med. Den kunne like gjerne vært skrevet 1 Datamodellering Dag Rune Ørebech v/ Høgskolen i Østfold Databaser 2009

2 som en vanlig norsk tekst (i motsetning til punktliste). Dette avsløres fort ved å for eksempel se på hva som er med under hvert punkt studie og avdeling går igjen selv om disse sannsynligvis har en logisk sammenheng. Et studie tilhører jo nødvendigvis én avdeling, så det er ingen grunn til at avdelig er spesifisert direkte i studenttabellen. Dette kommer vi tilbake til. Fyfy #1: Den mest naive løsningen på denne oppgaven er åpenbart å se på hvert hovedpunkt som en tabell og hvert underpunkt som en attributt. Det er ikke nødvendigvis så veldig langt fra sannheten, men er langt nok fra til at en slik løsning nesten garantert vil skape et uhåndterlig kaos av duplikater og tvetydig informasjon så fort datamengden vokser. Å lage en datamodell ut ifra en slik spesifikasjon består i høy grad av å: Forstå spesifikasjonen og å (mentalt) oversette den til en mer formell fremstilling som egner seg til å sette opp en datamodell. Det er selvfølgelig vanskelig å få et fullstendig bilde, men det lønner seg å prøve å forstå omtrent hvordan databasen vil se ut og hvor de betydelige problemene befinner seg. Bestemme hvilke tabeller man trenger: Tilhørende attributter med datatyper. Hvordan tabellene forholder seg til hverandre. (I første omgang bestemme primærnøkler og fremmednøkler.) Hele tiden forholde seg til prinsippene for normalisering. Dette blir intuitivt og naturlig etterhvert som man møter problemene ved å ikke normalisere, eller ikke normalisere godt nok. Det handler ikke nødvendigvis så mye om å slavisk følge reglene for normalformlene (selv om dette er fornuftig i starten), men kanskje mer å se nøyaktig hvilke problemer man møter underveis om man ikke tenker seg godt om. Dette henger sterkt sammen med Fyfy #1. Så til selve datamodelleringen: Vi begynner i dette tilfellet med å se hvordan man modellerer en student. Det består i å finne en abstrakt beskrivelse av hva entiteten student er. En entitet i en database er en tabell. Hva skal identifikatoren, eller primærnøkkelen være? Med andre ord, har student noen attributter som med sikkerhet er unike for hver enkelt student? I vårt tilfelle, ja: Brukernavnet! Dette er den absolutt eneste attributten som garantert ikke beskriver mer enn én student. Hvis ikke denne attributten hadde vært med i spesifikasjonen, måtte vi lagd vår egen identifikator, typisk StudentID (eller ofte StudentNR i dette kurset) rett og slett en integer for hver enkelt student. Men: Det er ingenting i veien for å lage en egen identifikator som f.eks. StudentID, til tross for at brukernavn allerede er garantert unikt. Vi velger å gjøre dette her, selv om det ikke finnes noen absolutt svar på hva som er korrekt. Attributtene navn, fødselsdag, adresse og telefonnummer har ingen sammenheng med 2 Datamodellering Dag Rune Ørebech v/ Høgskolen i Østfold Databaser 2009

3 resten av tabellen, så disse kan vi kaste rett inn. Entiteten student ser foreløpig slik ut: Understrekingen betyr primærnøkkel. Jeg benytter konsekvent kråkefotnotasjon i dette eksempelet. Fornavn og etternavn er separert fordi man ofte er ute etter kun fornavnet til en person. Vi bryr oss ikke om en lang debatt rundt hvilke datatyper alt er, det er ikke viktig før CREATE TABLE-setningene. Så til de ikke-trivielle attributtene. Dette er de som bør henge sammen med en ekstern tabell. Vi begynner med studium. studentid etternavn fornavn adresse telefon fødselsdag studium 1 Olsen Ole Blavn Dataingeniør 5 Jensen Jens Blavn Informatikk 3 Paulsen Paul Blavn Dataingeniør Osv... Her er det ganske tydelig at studium kan separeres ut til en egen entitet. Å ikke gjøre det medfører: At det er mulig å registrere en student i et studium som ikke finnes. At man skriver feil navn på studiet, f.eks. Dataingeniørstudiet i stedet for bare dataingeniør, noe som medfører tvetydighet (siden de skal bety det samme). Fyfy #2: "Men det er da ikke noe problem at det står litt forskjellig, det er åpenbart hva som menes." For oss mennesker er det ikke noe problem å se at disse to sannsynligvis betyr det samme, gitt at vi ser et utsnitt av tabellen som inneholder begge deler. Men det er det ingen som sier at man alltid gjør. Typisk: WHERE studium = "dataingeniør" vil ikke få med noen som er feilregistrert som "dataingeiørstudie". Og en maskin vil i alle fall ikke ha muligheten til å se at de er like av seg selv. 3 Datamodellering Dag Rune Ørebech v/ Høgskolen i Østfold Databaser 2009

4 Se for deg et GUI der man har muligheten til å søke rundt i denne databasen. Det smarteste hadde vært å ha en liste over hvert studium, så man slipper å bry seg med nøyaktig hvordan hvert studie staves, og om det finnes unntakstilfeller som over. Nøyaktig slik funksjonalitet oppnår vi med å være nøye på å separere ut de riktige attributene til egne entiteter: Riktig løsning: Ny tabell! Denne vil altså se slik ut: Studiumid navn 1 Informatikk 2 Dataingeniør 3 IT og ledelse Osv... Så studium-attributten til Student, markert med fete typer på forrige side skal fra nå av være (strengt tatt refferere til) studiumid i Studium-tabellen. Modellen vår så langt ser slik ut: Litt mer kråkefotnotasjon: Vi vet allerede at understreking betyr primærnøkkel. * betyr fremmednøkkel. Den reffererer her til primærnøkkelen i Studium. Streken mellom tabellene og symbolene på den betyr følgende: Én student er i minimum ett og maksimum ett ( ), eller på godt norsk nøyaktig ett studium. Ett studium har minimum null og maksimum "mange" ( > 0) studenter, det vil si at et studium kan ha et hvilket som helst 4 Datamodellering Dag Rune Ørebech v/ Høgskolen i Østfold Databaser 2009

5 antall studenter, inkludert ingen i det hele tatt. > her har ingenting med større/mindre enn å gjøre, det betyr "mange" eller "flere", altså alt fra 2 til uendelig. Men vi trenger altså en kurstabell. Et kurs har en kursid, et navn, og tilhører et studium. Nei, vent! Et kurs kan jo være på flere studier! Hvis det ikke hadde vært tilfellet, hadde det vært mye enklere: Men dette blir altså feil. Det er fristende å bare si at det er et mange-til-mange-forhold, men hvordan ville tabellene da sett ut? Det er umulig å vise et mange-til-mange-forhold i en normalisert database uten en tredje tabell, en mellomtabell som holder oversikten over hvilke studium som har hvilke kurs: studiumid kursid Studium 1, som altså er informatikk har kurs 3, f.eks. OOP. Studium 2, dataingeniør, har også kurs 3. 5 Datamodellering Dag Rune Ørebech v/ Høgskolen i Østfold Databaser 2009