Glöm inte referensdata!

Referensdata är en särskild kategori av data som manifesterar centrala begrepp i verksamhetslogiken. De är därmed något som det är särskilt viktigt att ta kontroll över.

/Peter Tallungs, IRM, 2024-02-15

Att ha ordning på referensdata är grundläggande för datakvaliteten

Man kan dela in data i olika kategorier beroende på typ av företeelse de representerar och hur de därmed behöver hanteras. Masterdata är den kategori det talas mest om. Men referensdata är en besläktad och minst lika viktig och lika grundläggande kategori som dock inte fått samma uppmärksamhet. Och som jag därför vill lyfta fram här.

Datakategorier

Men först kanske vi kort behöver repetera vilka kategorier av data vi kan tala om.

• Masterdata representerar centrala objekt i verksamheten, med utsträckning i tiden som kunder, produkter med mera. Det är saker där man behöver hålla reda på egenskaper och livscykler.
• Referensdata är kategorisering av olika slag. Data som vi behöver för att sortera och ordna våra företeelser samt förankra dessa i en omvärld (Detta förklaras närmare i artikeln)
• Transaktionsdata representerar någon form av transaktion mellan parter, med någon utsträckning i tid som till exempel, offerter, fakturor, ärenden och avtal.
• Händelsedata representerar momentana händelser som att en kund blivit en aktiv kund, en offert blivit accepterad eller ett avtal löpt ut.

Vad är referensdata?

Referensdata är kategoriseringar eller indelningar av olika slag, listor av värden som finns till för att refereras till från annan data. Om man beskriver det som koder av olika slag; som statuskoder, typer och kategorier blir det nog tydligt vad det handlar om.

Observera att detta att referensdata finns till för att refereras inte betyder att andra kategorier av data inte också refereras. Masterdata refereras titt som tätt, till exempel varje offert, kundärende eller faktura refererar en kund. Samma gäller för transaktionsdata, som ofta refereras av händelsedata. En faktura kan till exempel refereras av den registrerade händelsen att den blir betald.

Skillnaden är att referensdata enkom är till för att kategorisera andra data. Referensdata refereras av data i övrigt.

Exempel:

• Refereras från masterdata
  Kunder kan ha kundtyp, kundstatus, postnummer och branschkod.
  Produkt kan ha produkttyp och produktstatus.
• Refereras från transaktionsdata
  Ordrar kan ha ordertyp och orderstatus.
• Refereras från händelsedata
  Händelse kan ha händelseorsak.
• Refereras från (annan) referensdata
  Produkttyp kan ha produktgrupp, produktkategori eller status.

Har referensdata någon livscykel?

Referensdata har inte någon livscykel på samma sätt som masterdata och transaktionsdata. Jo visst kan en kod bli överspelad och därmed byta status till ”ej gällande”, men det är inte att jämföra med en livscykelhändelse när en kund byter status. När en kund går från prospekt till aktuell kund är det en livscykelhändelse som omfattas av verksamhetsprocessen för kund. Men när regeln för hur vi definierar kundtyp ändras så är det en förändring på ett annat plan. Då är det själva den operativa verksamhetslogiken som ändras, uttryckt i verksamhetsregler och verksamhetsprocesser. Det är skillnad på en normal händelse i en verksamhetsprocess och händelsen att själva verksamhetsprocessen ändras. Referensdata beskriver själva verksamhetslogiken, medan data i övrigt beskriver verksamhetsobjekts tillstånd och händelser som sker inom verksamhetslogiken.

Det är som skillnaden mellan händelsen att Zlatan gör mål och händelsen att FIFA tar bort Offside-regeln. Det är båda händelser som händer, kanske inte i olika världar, men i varje fall på olika plan – på en fotbollsplan och i en regelbok. Låt oss hålla isär dessa.

Detta visar hur referensdata befinner sig på ett annat plan än andra data. Referensdata uttrycker reglerna för verksamheten, det vill säga själva spelplanen, den operativa verksamhetslogiken. Medan övrigt data uttrycker vad som hanteras och vad som sker i verksamheten, och detta inom ramen för verksamhetslogiken.

Referensdata = Masterdata?

I litteraturen klumpar man ibland ihop referensdata med masterdata som en och samma kategori. Vilket är förståeligt då de båda är grundläggande för att ge kontext och förankring av det som händer i verksamheten, det vill säga transaktionsdata. Ursprunget till termen ”masterdata” är att det i datorernas barndom var data som fanns på den mastertape som man först var tvungen att läsa in innan man kunde ladda all transaktionsdata. Och då måste vi ju innefatta inte bara kunder och produkter med mera utan även referensdata som kundtyper etcetera.

Men utöver likheten att båda kategorierna är grundläggande för övrigt data är det skillnad på dessa två kategorier, vilket jag beskrivit ovan. Masterdata representerar primära verksamhetsobjekt som organisationen hanterar medan referensdata representerar regler/kategoriseringar av olika slag.

Men se alltså upp med termerna. Termen ”masterdata” kan ibland inkludera referensdata och ibland inte, ofta till och med i samma text. Det har ibland påpekats att vi skulle behöva ett generellt begrepp för båda kategorierna, eftersom de har gemensamt att de båda är den grund som annat data refererar till. Samtidigt behöver vi separata begrepp, eftersom det är företeelser på olika plan och som delvis ställer olika krav på hanteringen.

Vi behöver ta hand om våra referensdata

Det är vanligt att man inte vill se referensdata som något centralt. Motiveringen kan vara att de bara är värdeförråd för attribut, det vill säga regler om vilka värden som en egenskap kan anta. Regler om attribut brukar ha sin plats i beskrivningen av attributet i fråga. Ibland finns referensdata inte som data i databasen utan bara i programkod, i case-satser, eller uppräknade värden (enumerated values, enums). De ses som en del av programlogiken och glöms då ofta bort.

Ofta när jag analyserar och kartlägger data är brister i referensdata det stora hindret. Det är nästan alltid oklart vad olika statuskoder står för. Ofta har ett och samma attribut överanvänts så att man med tiden blandat olika klassificeringar i samma koduppsättning. Man har inte sett referensdata som något viktig, trots att det rör sig om centrala verksamhetregler vilka ofta styr den operativa logiken och rapporteringen.

Jag menar att referensdata utgör manifestationen av våra verksamhetsregler. Verksamhetslogik som är central för att vi ska förstå verksamheten. Vi behöver lyfta fram, beskriva och vårda och förvalta våra referensdata. Oavsett var dessa finns rent fysiskt.

Observera att detta, i likhet med nästan allt inom Data Management, inte är ett tekniskt problem utan handlar om ansvar. Tro inte att det handlar om avancerade verktyg. Bara om ordning och reda, dokumentera, ta ansvar och hantera.

Typer av referensdata

Referensdata finns av två typer beroende på vilken funktion de fyller:

1. Referensdata med internt upphov
(internally authorized reference data)

Dessa är till för att vi ska kunna sortera och dela in det vi vill kunna hålla reda på, på ett sätt som vår verksamhet bestämmer över själv. Hur vi kategoriserar saker, som till exempel kundkategori, fakturastatus eller ärendetyp.

2. Referensdata som styrs externt
(externally mandated reference data)

Här handla det om hur vi förankrar företeelserna i vår verksamhet till omvärlden. Som till exempel postnummer eller landskoder. Det är kategoriseringar som inte ligger i vår makt att bestämma över, utan det är saker som finns i omvärlden och som vi behöver förankra våra företeelser mot.

Var hamnar referensdata i informationsmodellen?

Var man placerar referensdata beror på vad de handlar om och refereras från. De referensdata som används enkom inom ett visst ämnesområde, till exempel ”Kundtyp” som används som värdeförråd för ett attribut i entiteten Kund, hör hemma just i ämnesområdet ”Kunder”. De tillhör därmed regelplanet i det ämnesområdet, i detta fall utgör det regeln för vilka typer en kund kan vara av och vad dessa betyder.

Men sedan finns det referensdata som kan refereras från olika håll. Till exempel kan ”Land” (en lista med världens länder) utgöra värdeförråd för attribut i flera ämnesområden. Kanske refereras denna entitet både från ämnesområdet ”Kunder” (adressen för en kund), ämnesområdet ”Produkter” (vilka länder en viss produkt är tillgänglig i), och ämnesområdet ”Intern organisation” (vilket land en organisationsenhet finns i). Därmed har entiteten ”Land” en mer global räckvidd och kan därmed inte placeras i någon av dessa ämnesområden, utan placeras i ett eget. Kanske ett ämnesområde som heter ”Geografi” där det samsas med flera geografiska begrepp. Detta ämnesområde tillhör då ett regelplan som inte är lokalt för ett ämnesområde utan som bildar ett regelplan för hela modellen.

Detta avspeglar också hur man kan behöva fördela ansvaret för referensdata i sin verksamhet. Referensdata som hör till ett visst ämnesområde hanteras med övriga data i det ämnesområdet.

Referensdata som bildar egna ämnesområden behöver hanteras separat, som ett gemensamt intresse, på samma sätt som det brukar vara med masterdata och allt annat som alla behöver men ingen är ämnad att ta eget ansvar för.

Det blir som en stödfunktion som tar hand om gemensamma referensdata; dokumenterar, tillgängliggör, vårdar och håller aktuellt. Att ta hand om all gemensamma data, det vill säga både all masterdata samt gemensamma referensdata, blir lämpligen en egen verksamhetsförmåga. Denna verksamhetsförmåga är en del av den större verksamhetsförmågan för Data Management (Data- /Informationsförvaltning).

Vilka attribut kan referensdata ha?

Referensdata kan, som nämnts, beskrivas som koder av olika slag, men det är inte bara själva koderna. Det behövs alltid mer än en lista av koder, inte minst behöver vi veta vad koden står för.

Speciellt för referensdata, till skillnad från andra datakategorier, är att listan av attribut man kan behöva för att beskriva förekomsterna är i mycket hög grad generisk. Det vill säga att vi kan använda samma lista av attribut till alla entiteter av referensdata. Observera dock att det är en bruttolista. Exakt vilka av dessa du ska använda beror på behoven. Men det är ändå bra att ha listan till hands för att tänka igenom vilka av dessa du behöver för det enskilda fallet.

Här kommer mitt förslag på attribut:

Ska vi se värdeförråd för booleska attribut (Ja/Nej-flaggor) som referensdata?

Vanligt är att man har attribut som är påståenden som har två värden, Sant/Falskt ofta kodat som Y/N eller 1/0. Det kallas ibland för booleska attribut eller flaggor. Det är då ofta oklart om det verkligen är ett strikt tvåvärdigt attribut eller om det egentligen finns tre tillåtna värden, det vill säga om det är tillåtet att lämna fältet tomt. Då finns det i själva verket tre tillåtna värden: Y, N eller blankt. Det är då ofta oklart exakt vad ett ej angivet värde betyder. Det kan betyda att värdet är okänt eller att egenskapen i fråga inte är tillämplig just för denna förekomst. Detta leder till osäker tolkning och ställer ofta till besvär.

Det är alltid bättre att vara tydlig. Inte bara för att kommunicera utan också för att jag själv ska skärpa tanken och verkligen tänka igenom möjliga alternativ. Esaias Tegnér hade en poäng då han sa: ”Det dunkelt sagda är det dunkelt tänkta”.

Jag brukar därför hantera värdeförrådet för booleska attribut precis som vilka värdemängder som helst, det vill säga som en entitet med ett värdeförråd av två eller tre värden, ibland till och med fyra värden, det vill säga Sant, Falskt, Ej angivet (alternativt Okänt) och Ej tillämpligt.

Ofta kan det också vara lämpligt att byta ut värdeförrådet Sant/Falskt mot värden som mer står för sig själva som att i stället för attributet Aktiv, med möjliga värden Ja och Nej, ha attributet Status, med möjliga värden Aktiv och Inaktiv. Det bör åtminstone vara ett val man överväger då man utformar sin datamodell.

Sammanfattning

Sammanfattningen får bli att referensdata är en särskild kategori med egna egenskaper och krav som det är särskilt viktiga att hantera.

Jag hoppas att denna artikel kunnat ge lite inspiration till att komma i gång med referensdata. Jag har svårt att tänka mig något som ger bättre återbetalning på nedlagt arbete. Detta i form av gemensam förståelse, klarhet, tydlighet, skärpa. Speciellt gäller det för all typ av analys och rapportering.

Fundera! Hur hanterar ni referensdata idag? Vad kan du göra? Hör gärna av dig och berätta!