För att flytta information från en databas till ett datalager används det idag olika tekniker. Existerande transformeringstekniker baseras på att en applikation hanterar detta. Detta examensarbete går ut på att skapa och undersöka en metod som istället genomför transformeringen i en databas. Denna transformering är metadatadriven, eftersom metadata är den information om data som krävs för att en transformering ska vara möjlig. Arbetet bygger därför på en metadatastudie som behandlar representation och struktur av metadata. Målet med arbetet är att få fram en så generell transformeringsmetod som möjligt och metoden går ut på att transformera data från en normaliserad databasstruktur till en denormaliserad datalagersstruktur.

Abstract Nowadays, companies and organizations manage large amounts of data to be used as support in decision making. A good solution for data management is in the form of data warehouses. A data warehouse is used to gather information from multiple sources within a company and arrange the information in a way that makes it easy to retrieve and analyze.   Designing a data warehouse is not a simple task. The study herein will focus on what a data warehouse is and how the ETL process is used for data storage in the data warehouse. ETL stands for Extract, Transform and Load and is the process that retrieves data, transforms it and finally loads it into the data warehouse. In addition to gathering information from literature we have also conducted an interview with data architect Rasmus Lindén with Know IT AB. During this interview Lindén described how Know IT AB had constructed a data warehouse for Upplands Lokaltrafik, with primary focus on how they used the ETL process to treat data to be stored in UL’s data warehouse.   The purpose of this paper is to examine the theory behind the ETL process and subsequently investigate how it may be applied by comparing the theory and how the company Know IT AB has applied it when designing data warehouses. One of the observations we made is that the theory we have studied fails to mention or illustrate some factors we during our interview found were considered important in designing data warehouses. / Sammanfattning Företag och organisationer hanterar idag stora mängder data som används som beslutsunderlag. För att hantera all data kan ett datalager vara en bra lösning. Ett datalagers uppgift är att samla information från flera olika källor inom företaget och ordna informationen så att den senare är lätt att ta fram och analysera.   Att konstruera ett datalager är ingen enkel uppgift. Den här studien kommer att fokusera på vad ett datalager är och hur ETL-processen används för att lagra data i datalagret. ETL står för ”Extract” ”Transform” och ”Load” och är den process som hämtar data, transformerar och slutligen laddar in det i datalagret. Förutom att ha samlat information från litteratur har vi även gjort en intervju med dataarkitekten Rasmus Lindén på Know IT AB. Under intervjun beskrev Lindén hur Know IT AB hade konstruerat ett datalager åt Upplands Lokaltrafik och fokus låg på hur de använde ETL-processen för att behandla den data som skulle lagras i UL:s datalager.   Syftet med uppsatsen är att undersöka hur ETL-processen ser ut i teorin och att därefter undersöka hur det kan se ut i praktiken, genom att jämföra hur företaget Know IT AB har tillämpar det när de bygger datalager. Något vi upptäckte i våra jämförelser är att den teorin som vi har tagit del av inte nämner eller belyser vissa saker som vi under vår intervju fann var viktiga då man byggde ett datalager.

Nowadays, the amount of data generated by users within an Internet product is increasing exponentially, for instance, clickstream for a website application from millions of users, geospatial information from GIS-based APPs of Android and IPhone, or sensor data from cars or any electronic equipment, etc. All these data may be yielded billions every day, which is not surprisingly essential that insights could be extracted or built. For instance, monitoring system, fraud detection, user behavior analysis and feature verification, etc.Nevertheless, technical issues emerge accordingly. Heterogeneity, massiveness and miscellaneous requirements for taking use of the data from different dimensions make it much harder when it comes to the design of data pipelines, transforming and persistence in data warehouse. Undeniably, there are traditional ways to build ETLs from mainframe [1], RDBMS, to MapReduce and Hive. Yet with the emergence and popularization of Spark framework and AWS, this procedure could be evolved to a more robust, efficient, less costly and easy-to-implement architecture for collecting, building dimensional models and proceeding analytics on massive data. With the advantage of being in a car transportation company, billions of user behavior events come in every day, this paper contributes to an exploratory way of building and optimizing ETL pipelines based on AWS and Spark, and compare it with current main Data pipelines from different aspects. / Mängden data som genereras internet-produkt-användare ökar lavinartat och exponentiellt. Det finns otaliga exempel på detta; klick-strömmen från hemsidor med miljontals användare, geospatial information från GISbaserade Android och iPhone appar, eller från sensorer på autonoma bilar.Mängden händelser från de här typerna av data kan enkelt uppnå miljardantal dagligen, därför är det föga förvånande att det är möjligt att extrahera insikter från de här data-strömmarna. Till exempel kan man sätta upp automatiserade övervakningssystem eller kalibrera bedrägerimodeller effektivt. Att handskas med data i de här storleksordningarna är dock inte helt problemfritt, det finns flertalet tekniska bekymmer som enkelt kan uppstå. Datan är inte alltid på samma form, den kan vara av olika dimensioner vilket gör det betydligt svårare att designa en effektiv data-pipeline, transformera datan och lagra den persistent i ett data-warehouse. Onekligen finns det traditionella sätt att bygga ETL’s på från mainframe [1], RDBMS, till MapReduce och Hive. Dock har det med upptäckten och ökade populariteten av Spark och AWS blivit mer robust, effektivt, billigare och enklare att implementera system för att samla data, bygga dimensions-enliga modeller och genomföra analys av massiva data-set. Den här uppsatsen bidrar till en ökad förståelse kring hur man bygger och optimerar ETL-pipelines baserade på AWS och Spark och jämför med huvudsakliga nuvarande Data-pipelines med hänsyn till diverse aspekter. Uppsatsen drar nytta av att ha tillgång till ett massivt data-set med miljarder användar-events genererade dagligen från ett bil-transport-bolag i mellanöstern.

<p>Detta arbete har sin utgångspunkt i Tekniska Verkens och Östkrafts integrerade operationella system. Dessa är utvecklade för att stödja beslutsprocesser för bl.a. fysisk och finansiell elhandel. Integreringen har gjorts genom annamandet av en IRM-baserad lösning, av verksamheterna benämnt "datavaruhus". </p><p>Avregleringen av elmarknaden medförde större krav på elleverantörerna med avseende på flexibilitet och funktionalitet när kunderna fick välja elbolag själva. Det som främst bidrar till komplexiteten gällande elhandel är de många olika sorters elavtal som kan tecknas och det ständigt varierande inköpspriset på nordiska kraftbörsen. </p><p>För fallstudiens företag gäller att deras datavaruhuslösning lider av osedvanligt dåliga prestanda. Syftet med uppsatsen är att utifrån en kvalitativ studie försöka identifiera primära faktorer för dessa prestandaproblem. Vidare vill vi belysa hur man bör integrera befintliga operationella system för att uppnå goda prestanda. </p><p>Arbetets slutsats är att prestandaproblemen kan härledas både till det arkitekturella och det strukturella planet såväl som till valet att egenutveckla den logik som bearbetar data genom att hämta, transformera och uppdatera datavaruhuset. Ytterligare en faktor utgörs av den höga detaljeringsgrad som kännetecknar data i datavaruhuset.</p>

<p>System som bygger på en underliggande databas behöver ett abstraktionslager mellan databasen och applikationen. Detta kallas för systemets datalager.</p><p>Det är inte ovanligt att en stor del av programmerarnas tid går åt för att skriva programkod som hanterar datalagrets egenheter och för att transformera data mellan applikationen och datalagret.</p><p>I ett objektorienterat datalager kan systemets domänmodell integreras i datalagret så att det blir betydligt enklare och mer effektivt att arbeta med. Ett objektorienterat datalager låter dessutom applikationen navigera mellan objekten i databasen som om hela objektgrafen vore tillgänglig i applikationens primärminne. Hur information hämtas, när den hämtas och precis vilken information som hämtas från databasen är transparent för applikationen.</p><p>Det är också transparent när uppdateringar som görs på objekt i applikationens primärminne når den underliggande databasen. Datalagret ger garantin att alla objekt, som förändrats inom loppet av en transaktion och som är nåbara via navigering från något objekt i databasen, kommer att finnas i databasen med korrekt tillstånd då transaktionen avslutas.</p><p>Ett objektorienterat datalager erbjuder således en striktare form av abstraktion än vad ett traditionellt datalager gör.</p><p>Inom ramen för examensarbetet har jag utvecklat en prototyp av ett objektorienterat datalager, och i den här rapporten presenterar jag: några allmänna koncept som rör datalager i allmänhet och objektorienterade datalager i synnerhet; hur dessa koncept kan designas; samt en kort översikt av prototypen.</p>

Detta arbete har sin utgångspunkt i Tekniska Verkens och Östkrafts integrerade operationella system. Dessa är utvecklade för att stödja beslutsprocesser för bl.a. fysisk och finansiell elhandel. Integreringen har gjorts genom annamandet av en IRM-baserad lösning, av verksamheterna benämnt "datavaruhus". Avregleringen av elmarknaden medförde större krav på elleverantörerna med avseende på flexibilitet och funktionalitet när kunderna fick välja elbolag själva. Det som främst bidrar till komplexiteten gällande elhandel är de många olika sorters elavtal som kan tecknas och det ständigt varierande inköpspriset på nordiska kraftbörsen. För fallstudiens företag gäller att deras datavaruhuslösning lider av osedvanligt dåliga prestanda. Syftet med uppsatsen är att utifrån en kvalitativ studie försöka identifiera primära faktorer för dessa prestandaproblem. Vidare vill vi belysa hur man bör integrera befintliga operationella system för att uppnå goda prestanda. Arbetets slutsats är att prestandaproblemen kan härledas både till det arkitekturella och det strukturella planet såväl som till valet att egenutveckla den logik som bearbetar data genom att hämta, transformera och uppdatera datavaruhuset. Ytterligare en faktor utgörs av den höga detaljeringsgrad som kännetecknar data i datavaruhuset.

<p>Det här arbetet har som huvudsyfte att belysa och ta fram vilka motiv det finns till att implementera datalager. Datalager är en teknik för att ta fram beslutsstödssystem där slutanvändarna själva tar fram sin information. Ett beslutsstödssystem har till uppgift att ge beslutsfattare (slutanvändare) information om en hel eller delar av en organisation. I introduktionen förklaras närmare vad ett beslutsstödssystem och datalager är för någonting samt ges exempel på i vilka sammanhang datalager används. En förklaring ges också till den historiska utvecklingen mot datalager</p><p>För att få fram motiven har intervjuer genomförts hos fyra stycken företag som implementerat datalager. Hos de här företagen har projektledare som ansvarat för implementationerna intervjuats samt hos ett företag har fyra stycken slutanvändare intervjuats.</p><p>Resultatet från intervjuerna visar att de vanligaste motiven finns betraktat ur en slutanvändares perspektiv. Motiven är bland annat att tillgängliggöra information och slutanvändarna kan anpassa sin information i förhållande till sitt verksamhetsområde.</p>

<p>Syftet med denna rapport är att undersöka om datalager, en sorts databas som fungerar som beslutsstödssystem, kan användas av mindre företag och organisationer inom en snar framtid. Datalager har tidigare varit en fråga främst för stora företag. Mindre företag nämns sällan i datalagersammanhang. Datalagerteknologin är ny vilket gör att den fortfarande utvecklas i hög takt.</p><p>Svaret söks genom en litteraturstudie samt en empirisk studie. I den senare tillfrågas ett antal datalagerutvecklare. Litteraturstudien fokuserar på fyra synvinklar: en storleksmässig synvinkel, en nyttomässig synvinkel, en ekonomisk synvinkel och framtida möjligheter. Ur dessa synvinklar studeras mindre företags möjligheter att använda datalager. Den empiriska studien fokuserar på spridningen av datalager i Sverige och mindre företags möjlighet att använda datalager.</p><p>Resultatet visar att det redan idag finns möjligheter för mindre företag att använda datalager. Även om möjligheterna finns är det en komplex process att implementera ett datalager och arbetet med datalagret upphör inte efter implementationen.</p>

<p>Syfte med detta arbete är att undersöka huruvida avkastningsberäkning för en datalagerinvestering bör göras, hur det kan göras och om det görs. Vidare avses att undersöka om generella kalkylmetoder kan användas av företag, oavsett storlek, som avser att starta datalagerinvesteringsprojekt. Datalagerteknologin har ännu en hög utvecklingstakt och detta medför ofta höga utvecklingskostnader i samband med investeringar inom datalager.</p><p>Undersökningen baseras på en kombinerad dokumentstudie och enkätundersökning. Dokumentstudien belyser den problematik vilken förknippas med problemområdet. Enkätundersökningen fokuseras mot olika större organisationer såsom banker, post och dagligvaruhandeln, vilka idag använder sig av datalager. De tillfrågas om huruvida avkastningsberäkning görs i deras organisation och, i så fall, hur den utförs.</p><p>Analysen och resultatet tyder på att problemområdet inte har en enkel lösning och att någon typ av avkastningsberäkning bör användas. Svårigheterna ligger i att värdera de potentiella fördelar som ett datalager kan generera.</p>

<p>Ett datalager är ett beslutstödssystem som integrerar stora mängder data från interna och externa källor. Dessutom är datalagret subjektorienterat, vilket innebär att det är organsierat kring ett antal betydelsefulla affärsdomäner som företaget lagrar data om. Många menar att det börjar bli allt viktigare för företag att söka information utanför verksamheten. Detta kan göras genom att de externa affärsdomänerna skannas av på information.</p><p>Syftet med detta arbete är att ta reda på i vilken utsträckning i nuläget som organisationer lagrar data om affärsdomäner i sitt datalager. För att ta reda på detta har företag som använder datalager kontaktats och intervjuats.</p><p>Resultatet visar att företag lagrar data om externa affärsdomäner, fast i ganska liten utsträckning. Däremot visar resultatet att intresset för att lagra information om dessa externa affärsdomäner håller på att öka bland företag.</p>