Informationsmodellering: Från att designa databaser till att förstå verksamheter

Historien om informationsmodellering började med hur man skulle designa en databas men är idag så mycket mer. Hur kom vi hit och hur går vi vidare?

/Peter Tallungs, IRM, 2024-05-23

Hur växte modelleringstekniken fram?

Idag används data- och informationsmodeller för en rad olika ändamål. De kan exempelvis användas för att kravställa ett informationsbehov eller för att skapa en fysisk datalagring eller datastruktur för ett specifikt syfte. Syftet och därmed strukturen på dessa modeller kan variera avsevärt.

Syftet kan också vara att skapa en gemensam förståelse och ett språk för det som verksamheten hanterar. I det senare fallet kan man mer se det som begreppsmodellering, men i praktiken är det svårt att helt separera arbetet med informationsmodellering från begreppsmodellering. Att förstå och strukturera information går hand i hand med att definiera och benämna det som informationen står för.

Men hur kom vi dit vi är idag med hur vi jobbar med informationsmodeller? Låt oss göra en snabbresa genom det senaste halvseklet.

Relationsdatabaser

På 70-talet kom relationsdatabasen, den typ av databas som ännu idag dominerar i våra verksamheter. Den bygger på en modell för databasstruktur som kallas relationsmodellen, vilken utvecklades av den engelska datavetaren Edgar F. Codd år 1969. Codd baserade relationsmodellen på predikatlogik.

Centralt för relationsmodellen är att datastrukturen är normaliserad, vilket betyder att varje fakta finns på endast ett ställe. Det är viktigt i den produktion av data som sker i en verksamhets operativa/transaktionella processer. Där, i produktionsdatabaserna, består datahanteringen i stort av det som brukar kallas CRUD, Create, Read, Update och Delete. Det vill säga att man typiskt skapar, läser, uppdaterar eller raderar en eller ett fåtal dataposter åt gången. Då behövs en datastruktur som är anpassad till detta. Strukturen behöver vara fri från redundans, vilket innebär att en uppgift, till exempel kundens aktuella adress, bara bör finnas på ett ställe så att när den ska ändras bara behöver ändras där. Då slipper vi risk för inkonsistens, det vill säga motsägelsefulla uppgifter. Normalisering kan ske till olika grader, där den vanligaste är den som kallas tredje normalformen (3NF).

Entity-Relational Modeling (ER-diagram) för databasdesign

Tanken från början när relationsmodellen togs fram var att man skulle ta den datamängd man ville hantera, ostrukturerad som den var. På denna skulle man tillämpa ett antal normaliseringsregler en efter en tills man uppnådde den normalform man behövde. Åtminstone var det så det framställdes i läroböcker. Men de visade sig vara ett opraktiskt arbetssätt.

Snart kom man i stället på att man kunde använda en grafisk modelleringsteknik som gav samma resultat, på ett enklare sätt. Den kom att kallas Entity-Relationship Modelling och Entity Relationsship Diagrams (ERD eller ER-diagram), och fanns snart i ett otal dialekter med små skillnader. Det sättet att modellera har sedan dess blivit mer eller mindre blivit synonymt med data- och informationsmodellering.

Det sättet att designa transaktionella databaser är det helt förhärskande idag. Jag känner ingen som ”normaliserar” data i sitt arbete det vill säga tillämpar normaliseringsreglerna en efter en. Dock gör man det i utbildningssituationer för att skapa en förståelse för vad normaliseringsreglerna innebär. Ty det är fortfarande lika viktigt att datastrukturer för transaktionella system är normaliserade. Det är bara metoden som är annorlunda, man skapar normaliserade strukturer med hjälp av informationsmodellering med ER-diagram.

Entity-Relational Modeling (ER-diagram) för verksamheter

I början av åttiotalet upptäckte man, oberoende av varandra och på olika ställen i världen, att normaliserade ER-diagram inte bara kunde användas för att designa en databas utan också för att beskriva allt det som en verksamhet hanterar. Inte bara företeelserna och egenskaperna i sig, utan även terminologin och vilken data som behövs för att representera allt detta. Det vill säga det som vi ofta kallar för konceptuell informationsmodell. Kanske kan man se det som en domänmodell, eftersom den i grunden beskriver verksamhetens domän, det vill säga allt det som verksamheten hanterar, och därmed behöver hålla data om.

Några av de som upptäckte hur man kunde använda ER-diagram för att modellera den aspekten av en verksamhet var tre unga killar på SAS huvudkontor i Stockholm. De experimenterade med detta tillsammans med en professor från Stockholms universitet. Med den idén startade de 1982 vårt företag IRM, som står för Information Resource Management. Budskapet var att vi bör hantera verksamhetens information som den värdefulla resurs det är.

På så sätt blev informationsmodellering med hjälp av ER-diagram inte bara en angelägenhet för databasdesigners utan en del av verksamhetsarkitektur och verksamhetsutveckling. Sedan dess är informationsmodellering med ER-diagram en bas i våra kurser för verksamhetsarkitekter.

Alternativ till ER-diagram

ER-diagram är således fortfarande basen för data- och informationsmodellering, överallt och i olika sammanhang, och används ofta även för begreppsmodellering. Vidare är den typ av diagram som är vanligast för design av programkod, det vill säga Klassmodeller i UML, bara en lätt anpassning av ER-diagram, det vill säga mer eller mindre en dialekt av ER-diagram.

Det finns de som har experimenterat med alternativ till ER-diagram men dessa har aldrig fått något större genomslag. Mest känt är nog NIAM (Natural language Information Analysis Method) med varianten ORM (Object-Role Modeling). Den australiske datavetaren Terry Halpin kom år 2001 ut med en 760 sidor tjock bok, Information Modeling and Relational Database – From Conceptual Analysis to Logical Design, där han gick igenom ett stort antal modelleringstekniker och jämförde en efter en med ORM. Han kom varje gång fram till att ORM var överlägset. Argumentet var att man bara modellerade språkliga utsagor, och inte gjorde några tidiga antaganden om vad som var entiteter och egenskaper. Jag förstår det argumentet men jag tycker inte att resultatet visar på någon framkomlig väg.

Jag har verkligen försökt utforska ORM men givit upp. Jag tror att vi som kognitiva varelser är gjorda för att se och uppfatta företeelserna i världen som klasser av objekt med olika egenskaper och förekomster av dessa klasser. Det vill säga inte bara som ett antal språkliga utsagor, utan tolkning i form av klasser och förekomster av objekt med egenskaper. ORM-diagram breder ut sig på ett svåröverskådligt sätt som inte bidrar till förståelsen.

Likhet mellan konceptuell informationsstruktur och fysisk struktur i databas

Den konceptuella informationsstrukturen (vad verksamhetens data representerar) och den logisk/fysiska datastrukturen (hur data är strukturerat i transaktionella databaser) följer varandra väl. I varje fall idealt, ty det kan hända att man av organisatoriska, historiska eller tekniska orsaker inte har kunnat synka dessa två perspektiv helt. Till exempel att modellerna gjordes vid skilda tillfällen och av olika personer, utan samverkan. Eller att kontext har ändrats med tiden. Eller att man av prestandaskäl har föredragit en annan fysisk struktur än den konceptuella.

Det är mycket praktisk att det finns en likhet mellan hur vi beskriver verksamhetens domän (det som verksamheten hanterar) och den data vi använder för att representera detta, det vill säga mellan konceptuella informationsmodeller och motsvarande fysiska datamodeller. Den stora fördelen är att vi då har ett och samma språk över verksamhet och it, samma begrepp samt samma bild i huvudet. Vi slipper då den mentala ansträngning som krävs för att översätta mellan två olika perspektiv på samma företeelse.

Det handlar inte bara om att vi använder samma modelleringstekniker utan också att de färdiga resultaten, själva modellerna, överensstämmer med varandra i hög grad.

Detta gäller också för det fall då domänen inte är representerad i en databas utan i programkod, särskilt objektorienterad programkod, vilket ju är standard sedan länge. Där finns det ett ideal som kallas Domain Driven Design som säger att den struktur i programkoden som representerar verksamhetsdomänen i absolut möjligaste mån ska avspegla den bild man vill att verksamheten ska ha av det som man hanterar. Det är mycket klokt och är något vi försöker tillämpa även då det gäller andra fysiska strukturer som till exempel operationella databaser.

Informationsmodeller idag

Idag, så där ett halvt sekel senare, baserar vi fortfarande våra informationsmodeller på ER-diagram. Men jag menar att metoden har stelnat sedan länge och behöver utvecklas. Vi behöver utöka och utveckla beskrivningssätten på många sätt, vilket vi också gör på IRM.

Vi kompletterar ER-diagrammen med andra diagramtyper för att uttrycka det som ER-diagram inte kan uttrycka, så som tillståndsdiagram för regler, tillstånd, händelser, tillståndsövergångar och händelseorsaker, samt förekomstdiagram (instansdiagram) för att analysera och exemplifiera komplicerade strukturer.

Vi uttrycker också saker i text som namn, synonymer, definitioner, beskrivningar, regler och noteringar. En informationsmodell för oss är alltså mycket mer än ett ER-diagram, även om ett eller flera ER-diagram även fortsatt är basen i varje modell.

Dessutom har vi jobbat mycket med gestaltningen av modellerna så att de effektivt uttrycker allt det vi vill kunna uttrycka. Vi uppfattar att skillnaden blir avsevärd, både i användningen och betydelserna av våra modeller i verksamheten. Och det med enkla medel!

I den analytiska världen är det annorlunda

Det kan tyckas märkligt att en ideal databasstruktur så väl sammanfaller med hur vi vill se konceptuellt på det som dessa data representerar. Är det ett lyckligt sammanträffande, eller finns det en bakomliggande orsak? Jag vet inte riktigt. Men intressant är att denna överensstämmelse bara gäller för de operativa och transaktionella processerna och de informationssystem som hanterar detta. Så överensstämmelsen kan inte vara som en naturlag utan måste vara en lycklig slump.

Ty om vi tar oss över till den analytiska världen, det vill säga Business Intelligence- och Data Warehouse-teamet där längst in på it-avdelningen så upphör likheten. Där är de konceptuella modellerna och de fysiska strukturerna väsensskilda från varandra. Men det får bli nästa artikel!