1 Modelleringsterminologi enligt IRM

Transkript

1 1.1 Informationsmodellering Vad ska man kalla det vi gör och resultatet av vad vi gjort? Orden har genom åren varit många, exempelvis informationsstrukturer, begreppsmodeller, konceptuella modeller, datamodeller, objektmodeller, informationsmodeller med liknande verb som informationsstrukturera, datamodellera och objektmodellera. Detta är en fråga som initialt kan leda till många och långa diskussioner med rutinerade modellerare. Så i denna bok används följande terminologi för de viktigaste begreppen. Resultatet kallar vi en Informationsmodell (Data Model eller Business Information Model). Informationsmodeller finns på olika nivå. En verksamhetsarkitekt jobbar ofta med helhet och behöver en Övergripande informationsmodell (Overall Business Information Model) medan en kravspecificerare utformar en Detaljerad informationsmodell (Detailed Business Information Model). Ytterligare detaljering behövs vid systemutveckling så då tas en Logisk informationsmodell (Logical Data Model) fram. Slutligen måste man utforma en Databasmodell (Physical Data Model) när man ska skapa en databas. Först kan konstateras att alla typer av informationsmodeller har samma grafiska utseende men skiljer sig åt framförallt avseende detaljeringsgrad. Databasmodellen har dock ofta ett helt eget beskrivningssätt baserat på valt databashanteringssystem. För en Övergripande informationsmodell försöker man hitta objekt med ungefär samma detaljeringsnivå för hela verksamheten och för en Detaljerad informationsmodell handlar det ofta om en detaljering av informationsbehovet för någon eller några processer. Den Logiska informationsmodellen bygger vidare på den Detaljerade informationsmodellen men måste kompletteras med alla önskade egenskaper och även med objekt som beskriver de grupperingsnivåer som verksamheten har behov av. Dessa grupperingsnivåer kommer även sannolikt att behövas för 11

2 att man i det färdiga systemets användargränssnitt ska kunna använda sig av fördefinierade valboxar. I den logiska modellen analyserar man även behov av ytterligare generaliseringar. De ingående huvudkomponenterna i alla informationsmodeller kallar vi Objekt (Entity) och Relation (Relationship). Processen att ta fram en informationsmodell kallar vi Informationsmodellering (Data Modelling eller Business Information Modelling). För att komplettera den grafiska modellen behövs även en detaljering av objekt och M:M-relationer. Detta görs i Tabellexempel (Tables). Tilläggas kan att det beskrivningssätt vi använder, såväl i den grafiska beskrivningen som i olika texter, väl ansluter till vanligt förekommande metoder, speciellt olika dialekter som baseras på ER-modeller (Entity Relationship Model). Gentemot klassdiagram enligt UML-notation (Unified Modelling Language), uppvisas något större skillnader men ändå inte större än att man på ett fåtal timmar kan konvertera en modell mellan dessa beskrivningssätt. Skillnaden mellan notationerna är som sagt liten vad gäller uttryckskraft. Däremot kommer de från olika håll, har sin kulturella bakgrund i olika yrkessammanhang och känns därför mer eller mindre hemtama hos olika yrkesgrupper. ER-modeller användes ursprungligen för att designa databaser. Senare har de spridit sig till annan datanära verksamhet och till verksamhetsmodellering. UML har sitt ursprung i programmering och har fortfarande sitt fäste i dessa sammanhang, även om försök gjorts till användning inom verksamhetsarkitektur. Därför känner sig databasfolk, liksom verksamhetsarkitekter, ofta mest hemma med ER-notation och programmerare med UML-notation. Genom att vi på IRM i olika kundprojekt tagit fram mer än informationsmodeller har vårt beskrivningssätt i samarbete med våra kunder utvecklats till dagens standard. 12

3 1.2 Dimensionsmodellering På motsvarande sätt kallar vi resultatet när vi modellerar för beslutsstöd en Dimensionsmodell (Star join schema) och processen för Dimensionsmodellering (Dimensional modelling). Ingående huvudkomponenter i dimensionsmodellen kallar vi Faktatabell (Fact table) och Dimensionstabell (Dimension Table). En faktatabell innehåller förutom alla mätvärden (Facts) även främmande nycklar (Foreign Keys) från alla omgivande dimensionstabeller. Genom att man kallar huvudkomponenterna för tabeller gör man också klart att en dimensionsmodell bygger på befintliga data i regel lagrade som databastabeller i befintliga system. 13

4 1.3 Inledande exempel För att ge en överblick över grunderna i Informationsmodellering ges ett exempel nedan. Exemplet, vars verklighet alla på ett eller annat sätt kommit i kontakt med, visar hur man på en lokal skola håller ordning på elevernas klasstillhörighet och närvaro. Informationsmodellering för en klass KLASS 1 tillhör ELEV 2 4 ELEVNÄRVARO LEKTION 3 figur 1 Tolkning av modell Det finns tre objekt, en relation av typen ett till många (1:M) samt en relation av typen många till många (M:M). Genom relationen tillhör ser vi att varje elev tillhör en klass och att varje klass har många elever. Relationen elevnärvaro visar att en elev är närvarande på många lektioner och på en lektion finns det många elever närvarande. Relationen elevnärvaro beskriver alltså varje elevs närvaro/frånvaro för varje enskild lektion. 14

5 Tabellexempel I samband med informationsmodellering exemplifierar vi objekt och relationer med hjälp av tabellexempel. Tabellexempel är till för att underlätta förståelsen av informationsmodellen eftersom vi kan kontrollera att vi tänkt och ritat rätt. Tabellexempel ger med andra ord en uppfattning om hur enskilda förekomster av objekt och relationer passar in i modellen. Genom att sätta in realistiska värden kan man även se om informationsmodellen verkar stämma överens med den tänkta verksamheten. Tabellexemplen och dess innehåll representerar då den information som finns eller kommer att finnas lagrad i en databas. Ett tabellexempel har ett antal rader och kolumner där varje tabellrad representerar en förekomst av ett objekt eller M:M-relation och varje tabellkolumn representerar en egenskap. Metoden för att överföra en modell till tabellexempel finns närmare beskriven i kapitlet 2.11 Regelverk för översättning från informationsmodell till tabellexempel och vice versa, sidan 66. Nedan följer en kort sammanfattning. Alla objekt har ett id-begrepp eller nyckel (Primary key) som i tabellexemplet visas genom att man har ett heldraget streck ovanför detta begrepp, exempelvis Klasskod. Som id-begrepp kan man antingen använda en väl känd egenskap, en verksamhetsnyckel, som unikt identifierar varje rad i tabellexemplet. Om en sådan egenskap inte existerar, kan man introducera en fiktiv nyckel (Surrogate key) som oftast bara är ett löpnummer som räknas upp för varje ny rad. Alla objekt som har en ett till många-relation (1:M) där många-sidan slutar i objektet lånar in nyckeln från objektet på ett-sidan. Denna inlånade nyckel kallar vi för en relationsegenskap (Foreign key). Exempelvis är Klasskod inlånad till tabellexemplet för objektet elev. Detta exemplifieras med ett streckat tak. Alla relationer av typen många till många (M:M) visas som ett tabellexempel som identifieras av de inlånade nycklarna från objekten som binds samman av relationen. Relationen elevnärvaro har följaktligen lånat sina nycklar från objekten lektion och elev. 15

6 1 KLASS Klasskod Klasstyp Klassföreståndare Antal elever 7A Musikklass Sven F 28 7B Matematikklass Maria K 26 8A Ekonomiklass Lars E 30 2 ELEV Elev nr Klasskod Kön Namn Adress 100 7A Pojke Lennart L Lilla gatan A Pojke Mathias L Stora gatan A Flicka Eva R Nya gatan 14 3 LEKTION Lektion Id Datum Ämne Lärare Musik Sven F Matematik Maria K Matematik Maria K Ekonomi Lars E 4 ELEVNÄRVARO Lektion Id Elev nr Status Närvarande Närvarande Sjuk Ledig Närvarande Sjuk figur 2 Tolkning av tabellexempel Objektet klass har fyra egenskaper varav en utgör objektets nyckel. Klasskod är en verksamhetsnyckel som alla känner till. Objektet elev har en känd nyckel, Elev nr, som skapas individuellt, en relationsegenskap, Klasskod, och ytterligare tre egenskaper, Kön, Namn och Adress. Objektet lektion har tre egenskaper. Till lektion finns dock ingen väl känd nyckel. Därför skapar vi en fiktiv nyckel i form av ett löpnummer som räknas upp för varje ny lektionsförekomst. Relationen elevnärvaro lånar sina nycklar från objekten elev och lektion samt har en egenskap som visar status för elevernas när- eller frånvaro på en specifik lektion. 16

7 Fortsatt arbete med modellen När man kommit så här långt i modelleringsarbetet bör man undersöka sina tabellexempel lite närmare. En rutinerad modellerare upptäcker då att det finns lärare i två olika kolumner med olika namn, dels som Klassföreståndare i klass och dels som Lärare i lektion. När man noterat detta och inser att risken för olikheter i till exempel stavning är stor och att man säkerligen har ytterligare egenskaper till varje lärare, blir det naturligt att även lärare borde vara ett objekt. Men lärare och elever har väldigt snarlika egenskaper. För att modellera detta finns möjligheten att samla objekten lärare och elev i ett gemensamt objekt person. person blir då ett ramobjekt (Supertype Entity) och lärare respektive elev blir rollobjekt (Subtype Entity) med samma identifierare. En annan egenskap som man bör vara extra uppmärksam på är Status. Mitt förslag är att alltid lyfta ut status som ett eget objekt för att tydliggöra vilka olika statuslägen som finns. Relationen elevnärvaro visar egentligen händelsen om en elev är närvarande på en lektion. Händelser brukar vi dock vanligtvis konvertera till objekt. I dessa fall införs en fiktiv nyckel eftersom elevnärvaro inte har någon naturlig identifierare. När lärare tillkommit som ett eget rollobjekt ska man också lägga till samband som berör läraren, till exempel vilka lektioner han/hon hållit samt i vilken klass han/hon är klassföreståndare. Vi har även kompletterat lektion med information om vilken klass denna lektion. Därigenom tillkommer ytterligare en relationsegenskap, Klasskod till objektet lektion. Några lärare som registrerar resultatet av sina prov i Excel-filer på sin hemdator tycker att man borde registrera resultatet av alla prov som eleverna gör i klassens olika ämnen. Då tillkommer ytterligare två händelseobjekt, prov och provresultat, och med samma resonemang som ovan om möjligheten att stava till exempel ämnet matematik på olika sätt, inser man att även ämne kvalificerar sig som ett objekt. Sammantaget leder detta till följande utbyggda version av föregående exempel. (En mer strukturerad metod för att bygga upp sin informationsmodell finner du i kapitlet 2.6 Arbetssätt på sidan 56.) 17

8 ges i STATUS 7 KLASS 1 klassföreståndare ges till ÄMNE 8 närvarostatus tillhör ges i PERSON LEKTION 3 ELEV- NÄRVARO 4 ELEV 2 LÄRARE RE 5 ansvaras av PROV 9 6 undervisning ges av gäller för PROV- RESULTAT 10 figur 3 1 KLASS Klasskod Klasstyp klassföreståndare Person nr Antal elever 7A Musikklass B Matematikklass A Ekonomiklass ELEV Person nr tillhör Klasskod Kön 100 7A Pojke 101 7A Pojke 102 8A Flicka 3 LEKTION Lektion Id Datum Ämne underv. ges av Person nr Klasskod A A A A 4 ELEVNÄRVARO Elevnärvaro Id Lektion Id Person nr Status S S S S S S2 18

9 5 LÄRARE 6 PERSON Person nr Antal anst. År Person nr Namn Adress Lennart L Lilla Gatan Mathias L Stora gatan Lars K Ekv 2 7 STATUS 8 ÄMNE Statuskod Beskrivning Ämneskod Beskrivning 9 PROV Prov nr S1 Närvarande 1 Musik S2 Sjuk 2 Matematik S3 Ledig 3 Fysik Datum ges i Ämne ges till Klass ansvaras av Person nr Maxpoäng A B A PROVRESULTAT Provresultat id Prov nr figur 4 gäller för Person nr Resultat Betyg Dimensionsmodellering enligt IRM För att redan i detta tidiga stadium få en översiktlig kunskap om vad som menas med dimensionsmodellering visas ett exempel på hur man från modellen ovan bygger upp en dimensionsmodell. I kapitlet 3.15 En strukturerad metod för att fi nna fakta- och dimensionstabeller, sidan 105, beskrivs en metod för att på ett strukturerat sätt återfinna de olika tabellerna. Metoden baseras på att i informationsmodellen finna händelseobjekt. prov, provresultat och elevnärvaro är tre händelseobjekt som skulle kunna vara händelser som man bygger sin dimensionsmodell på. Vi väljer objektet provresultat. 19

10 Exempel på en dimensionsmodell ÄMNE ELEV Ämne_Id PROVRESULTAT Elev_Id Kod Beteckning Lärare_Id LÄRARE Namn Adress Antal anst.år KLASS 203 Ämne_Id Elev_Id Lärare_Id Klass_Id Datum_Id 201 Maxpoäng på provet Poäng Betyg Namn Adress Kön Datum_Id DATUM Datum Veckonr Månad Kvartal År Dag_i_vecka Klass_Id Beteckning Klasstyp figur 5 Tolkning av dimensionsmodellen Objektet provresultat blir modellens faktatabell. I denna tabell samlas de mätvärden (Facts) som man vill göra beräkningar på. Beräkningarna är vanliga operationer av typen summera, beräkna medelvärde och räkna förekomster. För att modellera en korrekt dimensionsmodell måste man förstå vad faktatabellen beskriver. Detta brukar vi kalla faktatabellens granularitet (Granularity eller Grain). De olika mätvärdena beskriver varje enskild elevs poäng och betyg på varje enskilt prov. Observera att maxpoäng inte finns i objektet provresultat, på grund av normaliseringsreglerna (se kapitlet 2.4 Normalisering på sidan 49), men är bra att ta med i faktatabellen provresultat för att kunna göra enkla procentfördelningar. Faktatabellen omges av fem dimensionstabeller. Dessa kan återanvändas i många dimensionsmodeller och baseras ofta på objekt som finns i informationsmodellen. Dimensionstabellen datum återfinns i de allra flesta dimensionsmodeller och är speciell i så måtto att den sällan återfinns som objekt i informationsmodellen utan baseras ofta på en datumegenskap i det händelseobjekt som utgör faktatabellen. 20

11 I en dimensionsmodell skapar man vanligtvis dimensionstabeller av alla rollobjekt. Ramobjektet person har därigenom delats upp i de två dimensionstabellerna lärare och elev. Från denna modell kan man till exempel få svar på vilken klass som har bäst genomsnittsresultat i matematik under vårterminen 2009 eller om flickor i musikklass har bättre resultat på måndagar än torsdagar. Modellen medger dock inte analys av varje enskild uppgift i provet. För att uppnå detta måste man alltså detaljera sin informationsmodell ytterligare genom att införa händelseobjektet provresultat/uppgift. Exempel Nedan visas ett exempel på hur ett önskemål från dimensionsmodelleringsseminariet påverkar den totala informationsmodellen. ges i STATUS 7 KLASS 1 klassföreståndare ges till ÄMNE 8 närvarostatus tillhör ges i PERSON LEKTION 3 ELEV- NÄRVARO 4 ELEV 2 LÄRARE RE 5 ansvaras av PROV 9 6 undervisning ges av gäller för PROV- RESULTAT 10 Nytt objekt PROV- RESULTAT / UPPGIFT 11 21

12 figur 6 Ämne_Id ÄMNE Kod Beteckning 202 LÄRARE 203 Lärare_Id Namn Adress Antal anst.år Klass_Id KLASS Beteckning Klasstyp 204 PROVRESULTAT PER UPPGIFT 207 ProvresultatPerUppgift_Id Ämne_Id Elev_Id Lärare_Id Klass_Id Datum_Id Uppgiftnummer_Id Maxpoäng per uppgift Poäng på uppgiften Elev_Id Namn Adress Kön ELEV 205 DATUM 206 Datum_Id Datum Veckonr Månad Kvartal År Dag_i_vecka UPPGIFT NUMMER 208 Uppgiftnummer_Id Uppgiftnummer figur 7 Tolkning av modellen Faktatabellen har förändrat sin granularitet, från resultatet för en elev på ett speciellt prov till resultatet för en elev på en speciell uppgift i provet. Då kan man inte ta med mätvärdet maxpoäng på provet till den senare modellen, däremot maxpoängen just för denna uppgift. Dimensionstabellen uppgift nummer innehåller bara ett heltal som talar om vilket nummer i provet denna fråga har. Se även avsnittet Degenererade dimensioner sidan 87 (kapitel 3.7 Olika typer av dimensionstabeller). Från denna dimensionsmodell kan man förstås aggregera informationen så att man får fram exakt samma information som i den första modellen. En slutsats är då att man bör utforma sin dimensionsmodell på så låg nivå som det bara är möjligt för man kan alltid sammanställa och gruppera information till en högre nivå. 22