Data som lagras behöver kunna användas senare. Det innebär att all data som lagras i en transaktionsdatabas behöver kunna läsas och analyseras någon gång i framtiden. Det låter enkelt. Men många gånger är det inte så enkelt. Data lagras ofta i en normaliserad form som tillåter snabb och säker lagring, men som ofta kan vara svår att förstå. Av samma anledning kan även själva datat vara kodat, med samma resultat.
Det kan även vara svårt eller omöjligt att få ställa frågor direkt till källdatabasen, antingen för att den är hårt belastad eller att den är låst av säkerhetsskäl. Vid analys av data vill man dessutom ofta kombinera data från olika källsystem, som ofta använder helt olika strukturer, kodningar och andra egenskaper. Ibland sparas inte heller historik i källsystemet, vilket ofta är viktigt vid analys.
Vid analys är det även idealt om datat är tillgängligt i en form som är lätt att förstå och använda. Att lösa dessa problem kallas data integration:
Det finns några olika metoder för att läsa data i en databas. Normalt finns det någon form av applikation kopplad till databasen, och en sådan applikation har ofta någon form av metod visa data i databasen, tex med hjälp av en lista inuti applikationen. Det är förstås möjligt att hämta data därifrån, men det är ineffektivt och normalt en manuell metod som inte är felfri.
Det vanligaste sättet är att använda frågespråket SQL, som ställer frågor direkt till databasen. Det kan av olika anledningar vara svårt eller omöjligt att få ställa frågor direkt till källdatabasen, antingen för att den är hårt belastad eller att den är låst av säkerhetsskäl. Dessa skäl kan ofta lösas om frågorna först har granskats och godkänts av de som är ansvariga för databasen och dess data, och sedan körs under övervakning. De kommer ändå att innebära en belastning för databasens motor.
Frågorna måste normalt sett dessutom innehålla logik för att enbart hämta de senaste ändringarna i datat. Vanligtvis lagras all historik i ett datalager, och därmed behöver enbart förändringarna i datat hämtas för att läggas till den samlade historiken innan analys.
Ett tredje sätt är att använda databasens interna transaktionslogg. Nästan alla relationsdatabaser använder en intern transaktionslogg för att dess databasadminstratör skall kunna bevisa vad som är gjort och eventuellt kunna återställa data till en tidigare version. Det finns lösningar som kan tolka dessa loggar och därmed hämta alla förändringar utan att belasta databasens motor, vilket kallas för CDC (Catch Data Capture). En sådan lösning tillhandahålls av Qlik.
Data som kommer från olika källsystem har normalt olika struktur och kodning. Ett källsystem lagrar ofta data ett normaliserat format som passar sitt data. På samma sätt används ofta olika typer av kodning av datat, som passar detta data. Dessa strukturer och kodningar måste sammanställas och integreras för att det skall gå att kombinera data i en analys.
Eftersom en analytiker gärna vill slippa att göra denna, ofta tidsödande, sammanställning vid varje analys är det mer effektivt att transformera data innan det lagras i ett integrerat datalager. Själva transformationen är beroende på respektive källsystem, men det finns generella angreppssätt som kan vara användbara. Exempelvis bör man hantera eventuella datafel på samma sätt.
Datafel kan vara allt ifrån att en datatyp inte stämmer överens (och därmed inte kan lagras alls), data som saknas (tex är NULL), en kodning som saknar förklaring, manuella skrivfel till siffror som är orimliga. Det är mest effektivt om alla fel kan rättas i källdatasen, men ibland är det inte möjligt. Då bör man använda samma metod för att hantera alla datafel. Skall de sparas utan åtgärd (och lösas senare), skall de korrigeras automatiskt (så långt som möjligt), skall de läggas undan för manuell åtgärd, eller skall hela integrationen stoppas?
Många källsystem sparar inte på historik, huvudsakligen för att historiken inte används av det operativa systemet. Däremot är historik ofta viktig vid analys, eftersom man ofta vill se vad som händer över tiden. Det är lämpligt att spara på historik när man sammanställer data i ett integrerat datalager, eftersom man samtidigt transformerar och lagrar datat.
Enklast är att använda lägga till två kolumner för radens giltighet, ett startdatum och ett stoppdatum, för varje rad, vilket kallas för typ 2. När en post förändras uppdateras radens stoppdatum i datalagret, vilket indikerar att raden inte är aktiv längre, och samtidigt skapas en helt ny rad med samma datum i den nya radens startdatum, vilket indikerar att den är aktiv.
Mer: DW, se Slowly Changing Dimensions.
För att underlätta möjligheterna att analysera datat bör man tillhandahålla data på ett lättillgängligt sätt. Analytikern skall enkelt kunna förstå och använda, samt lita på, datat. Det kan göras på olika sätt, som bland annat är beroende på hur data är tillgängligt, hur analysen går till, vilka verktyg som används, vilken kunskap som analytikern har, med mera.
Om datalagret är baserat på en relationsdatabas finns det två huvudprinciper för att tillgängliggöra det. Antingen finns det lättförståeliga databasvyer, ett semantiskt lager, som läser data direkt från datalagrets själva hjärta, eller kopierar man delar av datat till Dataförråd (Data Marts), som är mindre kopior av datalagret avsedda för fokuserade frågor och analyser. Den första metoden kräver en mycket snabb databas som tex Teradata, och den andra metoden kommer duplicera stora datamängder vilket kräver mycket diskutrymme.
Det uppstod tidigt problem med att kombinera data från heterogena källsystem, även kallade för information silos, och på 1980-talet jobbade forskare med att ta fram metoder för interoperabilitet mellan olika system, bland annat med hjälp av metadata (data om data) som beskriver respektive källsystem.
En metod är att en användare kan skriva frågor som automatiskt hämtar data från olika källor, vilket kan sammanfattas under begreppet data virtualisering. Det är en teoretiskt tilltalande metod, som ibland kan används för specifika situationer, men i praktiken fungerar den dåligt för större datamängder.
Det första systemet för data integration baserat på strukturerad metadata skapades 1991 på University of Minnesota, Integrated Public Use Microdata Series (IPUMS). Systemet använde ett datalager, som uppdaterades med hjälp av en ETL-process (Extract, Transform & Load) som extraherade data, transformerade det och sedan laddade det i ett gemensamt schema i datalagret.
Därefter har det kommit att bli en norm att använda en ETL-process för att uppdatera ett datalager, och de flesta DI-verktyg är baserade på samma typ av ETL. Det innebär att datat hämtas från källdatabasen till en separat ETL-server där datat transformeras till önskat format, och slutligen laddas till datalagret. Eftersom de flesta ETL-processer hanterar stora datamängder, innebär det att ETL-servern måste vara mycket kraftfull.
För att undvika att bearbetning av data på en separat ETL-server (istället för inuti en databas) har en annan metod blivit populär på senare tid, ELT (Extract, Load & Transform), vilket innebär att själva transformeringen görs inuti databasen där datalagret finns. Detta är ofta en mer effektiv metod, eftersom en databas är konstruerad för att hantera stora datamängder.
Speciellt i molnbaserade databaser som Amazon Redshift, Google BigQuery, Microsoft Fabric och Snowflake fungerar denna metod, även kallad Push-down SQL, väl. På liknande sätt är det möjligt att transformera data i källdatabasen innan det hämtas och skrivs till ett datalager, TEL (Transform, Extract & Load), men det belastar förstås källsystemet och används inte inom data integration för analys.
Mer: ETL
Sidan skapad 4 december 2024 (egen sida om DI)
Sammanställt av Christer Tärning.