BEHOVET AV NOSQL- DATABASER HOS BUSINESS INTELLIGENCE- FÖRETAG

Examensarbete på kandidatnivå, 15 hp Systemvetenskapliga programmet SPB 2020.18

BEHOVET AV

NOSQL-DATABASER HOS

BUSINESS

INTELLIGENCE-FÖRETAG

Studie som undersöker behovet

av alternativa databaser inom

Business Intelligence-området

Innehåll

2.1VETENSKAPLIG METOD OCH ANSATS ... 7

2.2FORSKNINGSETISKA STÄLLNINGSTAGANDEN ... 7

2.3LITTERATURINSAMLING ... 8

2.4DATAINSAMLINGSMETODER ... 8

2.5FALLSTUDIE ... 8

3. BAKGRUND OCH RELATERAD FORSKNING ... 9

3.1NOSQL-DATABASER ... 9

3.1.1 Horisontell skalbarhet ... 10

3.1.2 CAP-teoremet ... 10

3.1.3 Polyglot Persistence ... 12

3.1.4 Säkerhet och brister hos NoSQL-databaser ... 13

3.2DE FYRA FAMILJERNA AV NOSQL-DATABASER ... 14

3.2.1 Nyckelvärdesbaserade databaser ... 14

3.2.2 Dokumentbaserade databaser ... 15

3.2.3 Kolumnbaserade databaser ... 16

3.2.4 Grafbaserade databaser ... 16

3.3BUSINESS INTELLIGENCE ... 17

3.3.1 Extraction, Transformation, Loading (ETL) ... 18

3.3.2 OLAP och data mining ... 18

3.4NOSQL INOM BUSINESS INTELLIGENCE ... 19

3.5TRENDER INOM BUSINESS INTELLIGENCE ... 19

3.5.1 Big Data ... 20

3.5.2 Big Data Analytics... 21

3.6THE RED QUEEN EFFECT... 22

4. RESULTAT OCH ANALYS ... 22

4.1ENKÄTUNDERSÖKNING ... 22

4.1.1RESULTAT AV ENKÄT ... 23

4.1.2 Analys av enkät ... 23

4.2INTERVJUER ... 24

4.2.1 Behov av nya lösningar ... 25

4.2.2 Kunskap om NoSQL... 27

4.2.3 Framtidsutsikter ... 28

4.2.2 Analys av Intervjuer ... 28

5. DISKUSSION OCH SLUTSATS ... 30

3

6. VIDARE FORSKNING ... 33

REFERENSER ... 34

TABELLER ... 35

FIGURER ... 36

BILAGA 1: SAMMANSTÄLLNING AV ENKÄTEN ... 37

Ett särskilt tack till Dan Johansson som handledde och uppmuntrade oss på

vägen genom denna uppsats, samt ett hjärtligt tack till företaget och deras

4

Abstract

5

1. Inledning

NoSQL-databaser står för ”Not Only SQL” och härstammar från en rörelse som grundades 2009 som ett försök att utveckla alternativa databaser som skulle ersätta/komplettera de traditionella relationella SQL-baserade databaserna. Andra försök hade tidigare gjorts, som t.ex. objektorienterade databaser på 90-talet (Fowler & Sadalage, 2013), men dessa slog aldrig riktigt. Men NoSQL-databaserna fick ganska snabbt fäste, speciellt hos företag som insåg att Big Data (stora ostrukturerade datamängder) var en av framtidens utmaningar inom IT-branschen, och där NoSQL-databaserna lämpade sig bättre genom sin skalbarhet, snabbhet, effektiva lagringsstruktur och möjlighet att använda sig av de varianter som passar bäst för ändamålet.

Våra förkunskaper om NoSQL-databaser grundar sig först och främst i Fowler & Sadalage (2013) som lägger fram fenomenet som en mer eller mindre överlägsen ersättning för de gamla traditionella relationella databaserna (SQL). Det ska däremot förtydligas att Fowler & Sadalage (2013) inte menar att SQL-databaser har gjort sitt inom IT-branschen, då det fortfarande finns en hel del fördelar med de traditionella databaserna gentemot NoSQL-databaser, t.ex. säkerhet vid transaktioner, enkelheten i SQL-språket, samt vidden av SQLs implementationsmöjligheter. Men nu när datamängderna hos företag och organisationer växer i en rasande takt, höjs även kraven på datalagring, enkelheten hos hanterandet av data, samt möjligheten att expandera datalagring allteftersom. Detta utgör, menar Fowler & Sadalage (2013), att de traditionella databaserna helt enkelt inte räcker till. Det krävs dynamiska lösningar, som kan möta framväxten av sk. Big Data. Med detta i åtanke, blev vi förvånade då det började gå upp för oss att många företag och organisationer faktiskt inte använde sig av NoSQL-databaser, utan lagrade sin data i traditionella databaser. Vi hörde oss för informellt bland olika aktörer inom IT-branschen, och frågor började formuleras hos oss:

Var det kunskapsbrist som gjorde att företag och organisationer inte valde att implementera NoSQL-databaser?

Skulle kostnaden för en sådan implementation vara för hög i förhållande till värdet det skulle skapa?

Fanns det brister hos NoSQL-databaser som gjorde att företag och organisationer drog sig för att använda sig av dessa?

6

1.1 Problemformulering

I denna studie vill vi undersöka hur behovet av alternativa databasmodeller ser ut idag hos ett företag verksamt inom BI-området. Är den traditionella relationella modellen obsolet eller är datamängderna inte tillräckligt stora ännu för att det ska finnas något behov av att titta på alternativa databasmodeller. Vi ämnar även undersöka hur kunskap om NoSQL-databaser inom en organisation kan påverka dessa behov.

Våra frågeställningar är:

Hur ser behovet av alternativa databasmodeller ut inom BI-området?

Hur påverkar kunskap om NoSQL-databaser inom en organisation, eller bristen på densamma, nämnda behov?

1.2 Syfte

Syftet med denna studie är att öka förståelsen för hur behovet ser ut för alternativa databasmodeller när det kommer till företag verksamma inom Business Intelligence-området, samt hur stor kunskap företagen har om dessa modeller. Detta för att kunna skapa en bild av hur förberedda BI-företagen är inför den allt snabbare tillväxten av datamängd och hur de står sig i det så kallade “Red Queen's race” - alltså, hur snabbt de kan anpassa sig till förändringar i deras miljö.

1.3 Avgränsning

Avgränsning sker i form av att vi valt att fokusera studien på ett företag som är verksamt inom Business Intelligence-området och undersöka hur behovet av alternativa databasmodeller ser ut idag, och även hur kunskapsnivån är bland de anställda i detta ämne. Detta IT-företag erbjuder företag och organisationer lösningar för verksamhetsstyrning och beslutsstöd via en webbaserad tjänst och som använder sig av relationella databaser i sin hantering av den stora mängden data som ingår i deras tjänst. Det finns ett antal studier om behovet av alternativa databasmodeller inom Business Intelligence, men få där det undersöks hur behovet ser ut hos företag som säljer

Business Intelligence-tjänster och produkter, vilket är en av anledningarna till att göra denna avgränsning. Varför valet föll på detta företag var p.g.a. att de är en av de ledande aktörerna inom sin bransch och har ett stort antal kunder - alltifrån stora organisationer till mindre företag som är verksamma inom ett brett spektrum av branscher. Detta hoppas vi kunna ge oss en bred bild över hur behoven ser ut av alternativa databasmodeller ser ut inom Business Intelligence-området.

7

Vi börjar redan här att bygga upp ramar för vår studie för att kunna etablera ett fokus och en problemformulering, och på så vis skapa en frågeställning som rör Business Intelligence, relationella databaser, samt icke-relationella databaser, se figur 1, där frågetecknet representerar området för våra frågeställningar.

2. Metod

I denna del redogörs för vilka metoder som använts för att undersöka den frågeställning som studien har som mål att undersöka. Denna redogörelse inkluderar vilka datainsamlingsmetoder som använts, hur litteraturinsamling skett, vilka forskningsetiska ställningstaganden som gjorts och hur analys av den insamlade data sett ut.

2.1 Vetenskaplig metod och ansats

För att besvara den frågeställning som denna studie ämnat undersöka, har en kvalitativ metod valts samt ett induktivt tillvägagångssätt tillämpats i enlighet med vad Yin (2011) skriver om denna ansats och hur man använder det när man genomför kvalitativ forskning. Kvalitativa metoder ger ofta möjlighet till att undersöka ett fåtal objekt men att kunna göra det mer djupgående och kan appliceras på en rad olika ämnen (Hedin, 1996). Det som kännetecknar ett induktivt tillvägagångssätt menar Yin (2011) är att man låter den data som samlas in leda till begrepp och teorier, medan om man istället exempelvis jämför med ett deduktivt tillvägagångssätt, där man utifrån teorier eller exempelvis en modell formulera hypoteser som sedan testar mot verkligheten. Så istället för att exempelvis bevisa eller motbevisa en teori handlar det induktiva ansatsen om att försöka göra upptäckter, hitta mönster och kunna dra slutsatser från den data man samlar in. Varför valet att använda en induktiv ansats beror på att studiens frågeställning är av ett explorativt slag där liten kunskap fanns om hur behovet ser ut av alternativa databasmodeller hos BI-företag idag och hur kunskapsnivån hos de anställda påverkar behovet. Då denna studie inte handlar om att pröva en hypotes eller teori lämpar sig därför inte ett deduktivt tillvägagångssätt utan vi anser att en induktiv ansats kommer bidra till att ge en nyanserad bild och är mest lämplig för att besvara studiens frågeställningar.

2.2 Forskningsetiska ställningstaganden

8

2.3 Litteraturinsamling

Eftersom NoSQL-databaser är en relativt ny företeelse har litteraturinsamling framförallt skett via digitala källor, där den främsta har varit Google Scholar. Andra källor har varit biblioteket på Umeå universitet för att framförallt hitta litteratur som fungerat som stöd vid utformande av enkäten samt vid intervjufrågorna, men även till hjälp för vilken vetenskaplig metod som är lämplig att tillämpa vid studien. För att utvärdera kvalitén på de källor som använts har CRAAP-test (UCL, 2020) tillämpats. CRAAP är en akronym för Currency, Relevance, Authority, Accuracy och Purpose (UCL, 2020). I detta test analyseras källans aktualitet (Currency), hur väl källan motsvarar behoven (Relevance), vem det är som skrivit informationen (Authority), trovärdigheten i informationen (Accuracy) samt vad syftet är med information (Purpose) (UCL, 2020). Ett exempel på när en källa valts bort efter utvärdering med hjälp av CRAAP är artikeln “On the elasticity of NoSQL databases over cloud management platforms”, där man gjort kvantifierade mätningar på olika typer av NoSQL-databaser om dess elasticitet och prestanda. Denna källa svarar inte upp till behoven för denna studie, d.v.s. (Relevance), vilka inte är uppfyllda enligt CRAAP. En källa som däremot uppfyller kraven är “From NoSQL databases to decision support systems: Developing a Business Intelligence solution”. Den är skriven 2019 (C), Den studerar Big Data och Nosql (R), är publicerad i International Journal for Quality Research (A), det som skrivs styrks av andra artiklar i ämnet (A) och avslutningsvis är syftet med den att öka kunskapen om NoSQL inom Business Intelligence-området (P).

2.4 Datainsamlingsmetoder

För denna studie har några olika kvalitativa datainsamlingsmetoder valts. En fallstudie har använts där vi bland annat har vi valt att använda oss av semistrukturerade intervjuer där vi intervjuat utvecklare och verksamhetskonsulter på ett företag verksamma inom Business Intelligence för att få en förståelse över hur behovet av alternativa databasmodeller ser ut idag, samt hur kunskapen om dessa är bland de anställda. Enligt Yin (2009) kännetecknas fallstudier av att man detaljerat studerar ett samtida fenomen inom dess verkliga kontext. Ofta är fenomenet och kontexten nära sammankopplat och det kan vara svårt att dra en gräns mellan dem. Ofta används denna strategi i explorativa studier. Yin (2009) förespråkar att använda sig av fallstudier när man vill besvara hur- och varför-frågor, när forskaren inte kan kontrollera skeende, samt om studien fokuserar på aktuella händelser. Då studien uppfyller alla dessa kriterier valdes därför denna forskningsstrategi.

2.5 Fallstudie

Vår fallstudie bygger på en enkätundersökning och ett flertal intervjuer med utvecklare och verksamhetskonsulter på ett IT-företag, grundat i början av 2000-talet, som med sin egenhändigt skapade beslutsstödsprodukt fokuserar på lösningar för verksamhetsstyrning och beslutsstöd för företag. Utvecklare och verksamhetskonsulter valdes då dessa

9

kundens verksamhet, d.v.s. den data som analyserna baseras på. Företaget sysselsätter mellan 50–100 medarbetare över ett flertal kontor över hela Sverige och har hundratals genomförda beslutsstödsprojekt på sin meritlista. Företaget bygger sin verksamhet på relationella databaser, samt att de kunder som håller sina egna databaser för det mesta också använder sig av dessa.

3. Bakgrund och relaterad forskning

I denna del redogörs för tidigare forskning som är gjord inom områden som är av intresse för denna studie samt relevant litteratur. Detta avsnitt kommer bland annat behandla vad skillnaden är mellan den traditionella databasmodellen och NoSQL, vad som menas med Business Intelligence och tidigare studier som gjorts.

3.1 NoSQL-databaser

Benämningen “NoSQL” har en något lustig och slumpartad födelse. Benämningen härstammar nämligen från den hashtag som användes på Twitter för att få igång en rörelse som skulle utveckla nya typer av databaser som inte var baserade på SQL, dvs. “No SQL” eller snarare “Not Only SQL”. Hashtaggen myntades först av mjukvaruutvecklaren Johan Oskarsson (@skr på twitter.com) som då var bosatt i London och skulle organisera ett möte den 11 juni 2009 i San Francisco för att diskutera utvecklandet av alternativa databaser eller, mer precis, “open-source, distributed, nonrelational databases” (Fowler & Sadalage, 2013). Benämningen fastnade som den generella beskrivningen av de databaser som avvek från de traditionella relationella SQL-baserade databaserna, och innefattar en mängd databaser som tillhör en av de fyra familjerna inom NoSQL-databaser: Nyckelvärdesbaserade-, dokumentbaserade-, kolumnbaserade-, och grafbaserade databaser. Dessa nya typer av databaser identifieras genom att de inte använder “Structured Query Language” (SQL) som är ett standardiserat programspråk för att hämta och modifiera data i en relationsdatabas, utan andra typer av

10

programspråk. Vissa NoSQL-databaser använder dock fortfarande så kallade “query languages”, som t.ex. Cassandras “CQL” som beskrivs som “exactly like SQL (except where it’s not)”1_{, vilket gör dem enklare att lära (Fowler & Sadalage, 2013).}

Behovet av dessa alternativa databaser är sprunget ur ett allt mer växande behov av mer dynamiska databaser, som kan lagra och hantera stora mängder data på ett snabbt och framför allt enkelt sätt. Ett exempel på detta är något som beskrivs som ”Impedance Mismatch: the difference between the relational model and the in-memory data structures” (Fowler & Sadalage, 2013), och innebär att de traditionella SQL-baserade databaserna kräver att de sparas i olika tabeller genom normalisering till tredje normalformen, för att sedan översättas av ett UI (User Interface) (se Figur 2). Hos NoSQL-databaser sparas dock all information, om till exempel en kund i Figur 2, i en och samma tabell vilket både kräver mindre datalagringskapacitet, samt gör det enklare för ett UI att ta fram data.

3.1.1 Horisontell skalbarhet

En annan fördel som NoSQL har är möjligheten till “horisontell skalbarhet”. Detta ger möjligheten, till skillnad från de traditionella databasernas vertikala skalbarhet, att utöka datalagringskapaciteten genom ett kluster av flera separata databaser (se figur 3). På så vis når datalagringskapaciteten aldrig ett tak, utan kan ständigt byggas ut vid behov. Vid vertikal skalbarhet så måste datalagringskapaciteten istället ökas genom att expandera den redan existerande databasen, vilket slutligen måste nå en begränsning. Detta gör att NoSQL-databaser blir överlägsna då det kommer till stora datamängder (Big Data) vilket blir allt mer viktigt för dagens företag. Några exempel på företag som är kända för att hantera stora datamängder är t.ex. Amazon och LinkedIn, som båda använder nyckelvärdesbaserade NoSQL-databaser, Google och Netflix, som båda använder sig av kolumnbaserade NoSQL-databaser (mer om dessa nedan).

3.1.2 CAP-teoremet

CAP-teoremet (CAP = Consistency, Availability, Partition Tolerance), även benämnt “Brewer's theemem” efter datavetenskapsmannen Eric Brewer (Fowler & Sadalage, 2013), redogör hur det är omöjligt för oss att kunna räkna med mer än två av de tre egenskaperna som behandlar ett system. Det vill säga: Konsistens (C) , Tillgänglighet (A) och Partitionstolerans (P), och är inom NoSQL anledningen till varför det behövs en mer dynamisk konsistens hos system. Låt oss först titta på de tre olika benämningarna för CAP-teoremet:

Vi tänker oss först ett system som innefattar noder (A, B, C och D) som länkas samman genom relationer som går från A till B, B till C, C till D och slutligen D tillbaka till A. Till att

1 _{https://www.slideshare.net/jericevans/cql-sql-in-cassandra}

11

börja med innebär Konsistens (C) att alla noder i detta system tillhandahåller det senaste tillståndet av systemet, det vill säga säkerställer att alla data är uppdaterad och om det inte skulle vara det så kommer systemet av säkerhetsskäl inte att svara för att förhindra att utdaterad data kommer in i systemet.

Vidare har vi Tillgänglighet (A) som innebär att alla noder i kluster som går att kommunicera med kan också skriva- och läsa data. Slutligen har vi Partitionstolerans (P) som innebär att systemet kan överleva avbrott i relationerna mellan de olika noderna som skapar ett flertal partitioner av noder som gör det omöjligt för noderna att kommunicera mellan partitionerna - något som benämns som “Split Brain” (Fowler & Sadalage, 2013).

Figur 4 - CAP-teoremet

I Figur 4 illustreras hur de olika de tre olika benämningarna för CAP-teoremet kan te sig. Ponera att vi har ett kluster som de i Figur 4 (A, B, C och D) som innehåller den rådande temperaturen i Umeå måndag klockan 12.00: -3,5 grader. På tisdag klockan 12.00 ska en ny temperatur föras in i systemet: 1,2 grader.

Utan Konsistens (C) så kommer vi att kunna föra in informationen till alla noder, men

eftersom det har uppstått ett avbrott mellan nod B och C så når inte tisdagens temperatur fram till nod C och D, vilket gör att när vi vill plocka ut den rådande temperaturen för tisdagens mätning så kommer vi fortfarande få ut måndagens temperatur.

Utan Tillgänglighet (A) så kommer vi på samma sätt kunna föra in data för tisdagens

temperatur och den kommer inte nå nod C och D på grund av avbrottet, men istället för att få ut fel temperatur så kommer vi inte få ut någon temperatur alls från nod D.

Slutligen har vi utan Partitionstolerans (P), som innebär att vi kommer att kunna

föra in temperaturen från tisdagens mätning och den kommer att nå alla noder, men bara om det inte blivit några avbrott i relationerna mellan noderna - det vill säga att inga partitioner har skapats.

Så vad det hela handlar om i slutändan är att vi måste välja vilken av dessa kompromisser vi kan hantera eftersom vi inte kan räkna med alla tre benämningarna för CAP-teoremet. Vi måste således se till vad vi kan undvara hos systemet: Om vi t.ex. inte kan acceptera felaktig data, så kommer Konsistens (C) vara något vi inte kan tolerera i vårt system, då detta tillåter felaktig data att läsas ut från nod D. Om vi måste få ut någon data i huvudtaget, oavsett om den är fel eller inte, så kommer inte Tillgänglighet (A) kunna vara en del av vårt system. Slutligen, om vi vet att risken är hög att partitioner kommer att uppstå, så kommer vi måste se till att systemet stödjer Partitionstolerans (P).

12

företag är dock att ta detta beslut i ett tidigt stadium hos systemutvecklingen, eftersom det kan vara väldigt svårt att avgöra vilka behov ett system kommer att kräva (Klein, o.a., 2015).

3.1.3 Polyglot Persistence

Det kanske ibland framstår som att förespråkare för NoSQL-databaser vill slopa de gamla traditionella relationella databaserna och enbart implementera moderna NoSQL-databaser, men så är inte fallet. Tanken är inte att NoSQL-databaser ska ersätta de relationella databaserna, utan komplettera dem eftersom alla typer av databaser, relationella- och alla olika typer av icke-relationella databaser, har sina styrkor och sina användningsområden. På så vis kan vi använda oss av begreppet Polyglot Persistence (Sv. Ungefär ”flerspråkig uthållighet”) som används inom applikationsutvecklingen och hänvisar till de fördelar som finns med att använda olika programmeringsspråk, då avancerade applikationer ofta bjuder på en mängd olika utmaningar, som olika programmeringsspråk är olika lämpliga för att hantera. Samma sak gäller alltså de olika typerna av databaser - relationella- som icke-relationella. Om vi ser till några av de populäraste NoSQL-databaserna som exempel skriver och läser MongoDB kontinuerligt, medan Cassandra klarar av storskalig analys på stora kluster och Neo4J ger möjligheten att snabbt koppla samman en mängd noder i en överskådlig graf. Figur 5 nedan visar ett exempel på en e-handelsplattform som använder sig av olika databaser, både relationella- och icke-relationella, för de olika uppgifterna som passar dem bäst. Även om databasleverantörer från både SQL- och NoSQL kämpar för att en dag skapa en heltäckande lösning, så har ingen ännu lyckats (Khine & Wang, 2019).

13

3.1.4 Säkerhet och brister hos NoSQL-databaser

I framväxten av dessa nya databastyper så börjar även en oro växa fram som rör säkerheten hos den data som ska lagras. Okman (2011) menar t.ex. att “...as opposed to relational databases they trade consistency and security for performance and scalability.” (Okman, o.a., 2011). För att återgå till CAP-teoremet, så prioriterar traditionella databaser Konsistens (C) och Tillgänglighet (A), och ökningen av stora webbapplikationer och distribuerade datasystem gör att Partitionstolerans (P) är oundviklig, vilket påverkar antingen konsistens eller tillgänglighet (Okman, 2011).

Ett vanligt säkerhetsproblem hos de relationella databaser är något som kallas för “SQL Injection”. Kortfattat innebär detta att en hackare kan använda sig av speciella SQL-kommandon (se Figur 6) för att kunna logga in på hemsidor utan att faktiskt behöva kunna eller gissa lösenordet - eller till och med användarnamnet. Detta problem finns dock också hos NoSQL-databaser, som t.ex. MongoDB, fast då används istället JavaScript, och hos Cassandra används de väldigt SQL-lika CQL-kommandona (Okman, 2011).

Det finns däremot argument som menar att eftersom NoSQL-databaser är distribuerade horisontellt i kluster på en mängd olika servrar,

istället för en enda som i fallet med de traditionella databaserna, så kan en injection-attack inte göra så mycket skada, då attackerarna enbart får en bråkdel av den egentliga datamängden uppdelad i småbitar, samt att det också motverkar “single point of failure” - det vill säga att om det blir fel på ett ställe så kommer inte hela databasen att krascha. Det tog dock inte lång tid innan attackerarna hittade på ett sätt att tjäna pengar på detta ändå. Ett exempel är ett tyskt universitet som inte brydde sig om att skydda data hos deras MongoDB, och blev således offer för ett massiv attack som slog ut 27 000 MongoDB-servrar i januari 2017. När attackerarna sedan hade raderat data från servrarna och tagit kontroll över denna data, så krävde de helt enkelt universitet på pengar genom kryptovaluta för anonyma transaktioner som lösensumma för att universitetet skulle få tillbaka den (Krenn, 2018).

Vi har anat en viss misstro till NoSQL-databaserna säkerhet, och har i vår studie haft detta i åtanke. Dock får vi inte glömma att NoSQL-databaser inte har funnits speciellt länge, och har behövt anpassa sig till fantasifulla hackers och deras metoder, precis som de traditionella databaserna fick göra i sin barndom. Det arbetas ständigt för att göra databaser mer säkra, som t.ex. att sökningar direkt i krypterade fält via queries är endast tillgängligt när vi använder ursprungliga databaskrypteringsmotorer eller att bygga ett API kring NoSQL-lösningen och inrätta ett isolerat nätverk (Karavasilev & Somova, 2018). Även databasutvecklarna själva jobbar med att lösa diverse säkerhetsproblem. Hos MongoDB, Inc. t.ex. kan vi läsa om olika åtgärder som de föreslår som lösningar på säkerhetsproblemen, som att MongoDB-data kan krypteras i nätverket och på disken, samt tillhandahålla skydd av inaktiv data genom en

14

integrerad funktion i databasen i och med införandet av MongoDBs “Encrypted storage engine” (MongoDB, Inc., 2020).

Någonting vi också måste tänka på vid en eventuell implementation av NoSQL-databaser hos en organisation är att även om dessa besitter kraftfull flexibilitet och enkelhet, så krävs det också att utvecklarna som ska hantera dem besitter goda kunskaper redan då de börjar byggas upp från grunden, eftersom felhantering kan betyda stor förlust av data och ekonomiska resurser (Desmarets, 2018). För sanningen är den att det är en utmaning att lära sig att utveckla och underhålla NoSQL-databaser, vilket både IT-arkitekter och utvecklare vittnar om. Svårigheterna ligger i att veta var de alternativa databaserna är bäst lämpade och förstå skillnaden på relationella och icke-relationella databaser, så att vi på bästa sätt kan ta vara på de fördelar som NoSQL-databaser faktiskt har. De har inte heller, som i fallet med de relationella databaserna, ett standardfrågespråk (Standard Query Language), vilket kan leda till att även om någon i många år har arbetat med en typ av NoSQL-databas kan få svårigheter att börja arbeta med en annan. Så för de organisationer som ska implementera och/eller komplettera med icke-relationella databaser måste vara medveten om att utbildning av personal är av största vikt (Fernando, 2018).

3.2 De fyra familjerna av NoSQL-databaser

NoSQL-databaser kan, som nämnts tidigare, delas upp i fyra familjer av databaser: Nyckelvärdesbaserade-, Dokumentbaserade-, Kolumnbaserade-, samt Grafbaserade databaser. Dessa fyra varianter av NoSQL-databaser har alla egna styrkor (och svagheter) som gör dem lämpliga för vissa uppgifter och mindre lämpliga för andra, som tidigare beskrivits i avsnittet om Polyglot Persistence.

3.2.1 Nyckelvärdesbaserade databaser

Till att börja med har vi nyckelvärdesbaserade databaser, där den mest populära är den hashtabell-baserad databasen Riak (Sharma, o.a., 2015), men det finns även andra varianter som används av kända aktörer så som DynamoDB, som används av Amazon2 _{och Voldemort}3_,

som används av LinkedIn. I likhet med relationella databasers “primärnyckel”, så använder nyckelvärdesbaserade databaser också en “nyckel” för CRUD-operationer, som är unik och inte kan dubbleras inom samma samling. Den väsentliga skillnaden mot traditionella databaser är dock att nyckelvärdesbaserade databaser inte bryr sig om innehållet när den ska verkställa dessa operationer. Nyckelvärdesbaserade databaser är också den typen av databas som är bäst lämpad ur ett API-perspektiv (Fowler & Sadalage, 2013).

Syntaxen för att manipulera data i nyckelvärdesbaserade databaser är ungefär lika enkelt som i de traditionella, då vi använder anrop som till exempel GET, POST, PUT och DELETE, och kommunicerar enbart mot primärnyckeln i en “Bucket” (databas). Hos nyckelvärdesbaserade databaser råder även “Polyglot Persistence”, vilket vi nämnt tidigare, då

2 _{Amazon (https://aws.amazon.com/dynamodb)}

3 _{LinkedIn (https://web.archive.org/web/20110423183102/http://project-voldemort.com)}

Figur 7 -

15

dessa består av klientbibliotek som ger stöd för en rad olika programmeringsspråk, så som Erlang, Java, PHP, Python, Ruby, C / C ++, etc. som alla kan köra CRUD-operationer mot primärnycklar (Sharma, o.a., 2015). Nyckelvärdesbaserade databaser kan även skrivas ut i JSON-format (se Figur 7), vilket är väldigt användbart.

När det kommer till användningsområden så passar nyckelvärdesbaserade databaser framför allt för datalagring där det räcker att söka eller manipulera data bara genom en primärnyckel, till exempel persondata där primärnyckeln representeras av personnumret. På så vis behöver vi inte gå igenom all data som är lagrad, t.ex. namn, adresser, osv, utan kommunicerar enbart med personnumret (primärnyckeln), vilket ger en enkel och framförallt snabb respons. Och även om nyckelvärdesbaserade databaser liknar relationella databaser, med sina tabeller och nycklar, så är det just detta som gör nyckelvärdesbaserade databaser så mycket snabbare och smidigare än de traditionella databaserna. Ännu en skillnad är att i relationella databaser behöver vi dela upp sådan persondata i flera olika tabeller (en för namn, en för adress, en för telefonnummer osv), medan nyckelvärdesbaserade databaser inte bryr sig om vad som finns i tabellerna för att kunna jobba med dem genom primärnyckeln.

3.2.2 Dokumentbaserade databaser

Dokumentbaserade databaser är onekligen den populäraste varianten av NoSQL-databaserna, och då framförallt MongoDB4_{, som fått sitt namn från det}

engelska ordet ”humongous” (Sharma, o.a., 2015). Enligt en studie av B2B-företaget Enlyft, som spårat 98 olika databasvarianter hos 766 648 företag, så använder 4,12% MongoDB (37 516 st företag), vilket gör den till den mest använda NoSQL-databasen bland dessa företag. Av de databaser som spårats så var det Microsoft SQL Server (21.65%), MySQL (20.62%), Microsoft Access (11.34%) och PostgreSQL

(5.15%) som låg i topp. Vidare visar deras studie att de företag som använde MongoDB huvudsakligen är belägna i USA och är mjukvaruutvecklare (Enlyft, 2020). Ett annat exempel på en dokumentbaserad databas är Apache CouchDB5 _{som använder JavaScript som}

programmeringsspråk (Sharma, o.a., 2015).

Även om dokumentbaserade databaser kan likna traditionella databaser, så är de betydligt mer flexibla, som t.ex. att vi kan använda olika attributnamn i samma samling (Fowler & Sadalage, 2013), och hämta och lagra dokument i XML-, JSON-, och BSON-format osv. Fördelen med detta är att vi slipper lagra en massa tomma celler som i relationsdatabaser. Hos till exempel MongoDB använder vi querys som $set för att ändra värde och $orderby för att sortera, som kan kombineras på många olika sätt för att kommunicera med dokumentsamlingen (Fowler & Sadalage, 2013).

4 _{MongoDB (https://www.mongodb.com)} 5 _{Apache CouchDB (https://couchdb.apache.org)}

16

3.2.3 Kolumnbaserade databaser

Kolumnbaserade databaser är den snabbaste NoSQL-databasen (Fowler & Sadalage, 2013), och har vissa likheter med traditionella databaser, som att vi kan likna en kolumnfamilj med en behållare med rader i en tabell där nyckeln identifierar raden och raden består av flera kolumner. Vi använder även primärnycklar för CRUD-operationer hos kolumnbaserade databaser, samt göra attributer sökbara genom

att skapa index. Den väsentliga skillnaden är dock att vi i kolumnbaserade databaser kan lägga till kolumner i någon rad utan att behöva göra det i alla andra rader (Fowler & Sadalage, 2013). Kolumnbaserade databaser möjliggör att lagra data i rader med primärnycklar som är länkade till värden, medan värdena själva är grupperade i olika kolumnfamiljer som i sin tur är en datakarta (Fowler & Sadalage, 2013). Detta jämfört med relationell databas där data struktureras i form av tabeller.

Några exempel på stora aktörer som använder kolumnbaserade databaser är t.ex. Netflix och Yahoo som använder sig av Apache Druid6_{, samt Google som använder sin Cloud Bigtable}7

och Amazon som använder sin Amazon SimpleDB. Den kändaste är dock den kolumnbaserade databasen Cassandra som använder ett språk som heter CQL (Cassandra Query Language), och som är väldigt likt SQL som används i relationella databaser.

3.2.4 Grafbaserade databaser

Grafbaserade databaser är just vad namnet implicerar, dvs. en databas som baseras på grafer. Dessa grafer består av Noder, även kallade entiteter, som kan representeras av t.ex. människor, företag konton osv., och kan ses som objekt i en applikation. Mellan noderna finns det relationer (edges) som äger vissa egenskaper, som t.ex. vikt, längd, relationer osv. (se Figur 10), och baserat på informationen baserade på noderna och deras relationer kan vi på så vis tolka data på ett mycket effektivt och överskådligt sätt (Fowler & Sadalage, 2013). Dessa typer av databaser ter sig t.ex. väldigt användbara då vi behöver räkna ut kortaste vägen mellan olika noder, där relationerna mellan noderna har olika vikter/värden, som t.ex. antal km mellan två städer.

Det finns en del olika varianter av grafbaserade databasen som använder sig av olika programmeringsspråk, där Neo4J som använder språket Cypher (Cypher Query Language) och är den populäraste grafbaserade databasen (Fowler & Sadalage,

6 _{Apache Druid (https://druid.apache.org/druid-powered.html)} 7 _{Cloud Bigtable (https://cloud.google.com/bigtable)}

Figur 9 - Kolumnbaserade databaser

Figur 10 - Grafbaserade

17

2013). Andra exempel är ArangoDB8 _{som använder AQL (ArangoDB Query Language), och}

Amazon Neptune som använder sig av Apache TinkerPop Gremlin9 _{och SPARQL.}

Även om grafbaserade databaser, precis som de traditionella databaserna och till skillnad från de andra NoSQL-databaserna vi gått igenom, baseras på relationer (relationerna mellan noderna), så finns det en viss avgörande skillnad. Vi kan lagra en grafliknande struktur i en relationell SQL-databas i form av en relation, t.ex. ”Min Mamma”, men om jag sedan vill lägga till ännu en relation, kanske ”Min Pappa”, så kräver relationella databaser att vi gör många ändringar i schema och dataförflyttningar. Detta är dock något som inte behövs i grafbaserade NoSQL-databaser, vilket gör dem till ett användbart komplement för den typen av grafstrukturer (Fowler & Sadalage, 2013).

3.3 Business Intelligence

Business Intelligence är en term som först introducerades år 1989 av Howard Dressner på Gartner Group (Negash och Gray 2008). Denna term beskriver flera olika typer av koncept där man använder sig av stöd från fakta för att ta bättre beslut inom organisationen.

Idag har många organisationer stora mängder data från flera olika datakällor i verksamheten. Fastän de har dessa stora mängder data är det mycket svårt för ledningen att använda denna data för att förstå verksamheten. Det brukar sägas att det råder ett informationsgap mellan verksamhet och ledning. En stor anledning till att det är så beror på att data ofta ligger spridd över flera olika system i verksamheten och integrationen mellan dessa brukar många gånger vara bristfällig. En annan orsak är att det är svårt att extrahera data ur de olika systemen och kräver ofta experter inom området för att få ut den. Men även om de lyckas extrahera ut data, kan den vara svår att förstå. Det kan även vara som så att det finns delar av data som saknas och som gör att återstående data blir obrukbar. Business Intelligence är lösningen på detta och handlar idag om att de använder informationssystem för att stödja beslutsfattandet. De samlar in stora datavolymer om organisationen och dess processer från deras datasystem. Denna data sparas sedan i ett Datavaruhus. Därefter använder de tekniska verktyg för att processa data och analysera den. Resultatet kan sedan användas av organisationens ledning och dess analytiker för att kunna ta snabbare och bättre beslut.

De senaste två decennierna har Business Intelligence området vuxit enormt i både antal produkter och tjänster. En stor anledning till detta är kostnaden för lagring har blivit väsentligt mycket lägre under denna period, vilket har gjort det mer intressant för företag att använda sig av dessa teknologier (Chaudhuri, Dayal och Narasayya, 2011, 88–98). På grund av de ökade möjligheterna att kunna lagra stora datavolymer har gjort att företag kan spara data från många olika källor som exempelvis bokföringssystem, telefonsystem, kunddata, RFID-taggar för logistik-inventering m.m. Idag är det mycket svårt att hitta framgångsrika företag som inte använder sig av någon form av Business Intelligence-teknologi som stöd vid beslutsfattandet i deras verksamhet (Chaudhuri, Dayal och Narasayya 2011, 88–98). Exempel på användningsområden kan vara att en snabbmatsrestaurang vill förutspå hur mycket beläggning de behöver tisdagar under januari månad. Ett annat exempel skulle kunna vara att

18

ett företag vill veta hur mycket en viss vara kommer sälja under Black Friday. Ett tredje exempel skulle kunna vara att ett företag vill veta hur många som ringer in till deras kundtjänst en viss timme under mellandagarna.

Några av fördelarna med att använda Business Intelligence-system är:

• Riskkalkylering: Kan övervaka och upptäcka risker som kan hota organisationens strategiska mål.

• All data på ett ställe: BI-system integrerar flera olika typer av data för analys som exempelvis vanlig relationell data, Microsoft Excel-data och xml-strömmar o.s.v. och sparar det på ett enda ställe i ett datavaruhus. Detta gör att data ligger ständigt tillgänglig för BI-systemet för analys.

• Låg kostnad: Kostnaden för att implementera ett BI-system är låg. Stora investeringar i hårdvara till exempel är ej nödvändig och utbildning av användare i systemen går relativt snabbt och är en investering som ofta har betalat tillbaka sig på mycket kort tid.

• Beslutsfattande: Hjälper till att undvika problem vid beslutsfattande.

• Minimerar risken för maktspel: Hjälper till att minimera risken för att maktspel ska uppkomma inom organisationen.

3.3.1 Extraction, Transformation, Loading (ETL)

Som nämnts lagras all data från organisationen i ett datavaruhus för att kunna användas vid analys. Det är en rad steg som måste genomföras för att när vi ska föra in ny data i ett datavaruhus. Denna process kallas ETL (Connolly och Begg 2015, 1236).

Extraction: Detta steg innefattar extraktion av data från de olika datakällorna i

organisationens verksamhet, vilken typ av data som ska hämtas och hur mycket data som ska hämtas. Data som hämtas är ofta i flera olika typer av format som exempelvis xml, OLTP-databaser, loggfiler, diverse databasdumpar (Connolly och Begg 2015, 1236).

Transformation: Här tillämpar man regler eller funktioner på den extraherade data.

Detta kan t.ex. innebära att vi lägger samma data, lägger till tidsstämplar, omkodning av värden, data-aggregering och skapande av surrogatnycklar (Connolly och Begg 2015, 1236). Resultatet av transformering leder till data som är “ren” och konsistent med befintlig data som ligger i datavaruhus.

Load: I detta steg laddas data in i datavaruhuset. Detta inleds först efter att delar eller hela

transformationen av data är slutförd.

3.3.2 OLAP och data mining

19

Data mining är en process för att söka efter trender, korrelationer och mönster i stora mängder data med hjälp av tekniker som bygger på matematik, statistik och AI (Connolly & Begg 2015). Fokuset vid användandet av data mining är att hitta trender och mönster som ligger dolda i data då det ligger mest värde i detta mot för att hitta uppenbara mönster. För att data mining ska vara ett effektivt verktyg krävs det att data är strukturerad och “ren”. Det är därför det är att rekommendera att man utför data mining på data som ligger lagrade i ett datavaruhus då data genomgått ETL-processen. Den stora fördelen data mining har över OLAP-tekniken är att vi kan skapa förutsägande modeller istället för retroaktiva modeller (Connolly & Begg 2015).

3.4 NoSQL inom Business Intelligence

En av de främsta funktionerna som används i databaser är aggregering av data. Detta gäller särskilt inom Business Intelligence vid ETL-processen, skapandet av OLAP-kuber samt vid data mining (Bonnet et al. 2011). Ofta används SQL-databaser idag inom Business Intelligence och då är aggregering något som utförs för att visualisera data och göra den redo för djupare analyser. På större datavolymer är detta något som är mycket svårt att genomföra då det kommer till minneshantering samt att det tar mycket lång tid att genomföra (Bonnet et al. 2011). En lösning vid hantering av stora datavolymer menar Bonnet et al. (2011) är att använda Nodatabaser istället för SQL. De har jämfört Nodatabasen MongoDB mot en SQL-databas i form av MySQL. De utförde bland annat ett test där de gjorde en aggregation på 1.5 miljoner relationer. Resultatet var att det tog tre timmar för MySQL att slutföra testet medans det tog endast några minuter för MongoDB (Bonnet et al. 2011).

Bonnet et al (2011) kommer till slutsatsen att man bör överväga NoSQL-databaser när man jobbar med stora datavolymer inom Business Intelligence. De främsta styrkorna de lyfter fram var:

• NoSQL-databaser har högre skalbarhet och är bättre lämpade för operationer som sker över flertalet noder.

• Konstruerade för att klara av att processa stora datavolymer i distribuerade miljöer. • Hög läs/skrivhastighet och mycket snabbare aggregering av data mot för relationella

databaser.

• Schemalös design gör att man inte behöver vara orolig vid vidareutveckling av databasen.

De nämner dock att de finns nackdelar med NoSQL och en är att många system idag använder sig av SQL-databaser vilket medför att om man vill använda NoSQL måste man migrera över den och det innefattar att den konverteras från SQL-data till NoSQL-data, vilket både tar tid och måste administreras (Bonnet et al. 2011).

3.5 Trender inom Business Intelligence

20

mer djupgående och mer utforskande, medan traditionell Business Intelligence ger en användarupplevelse som är mer strukturerad i form av exempelvis visuella dashboards och rapporter.

3.5.1 Big Data

Idag lever vi i en tid där det genereras mer data än någonsin tidigare av både människor och maskiner, vilket har gjort att datavolymen växer sig allt större och i en allt snabbare takt. Termen “Big Data” refererar till just detta globala fenomen. Varje dag genereras över 2,5 quintillion data världen över, och mängden global datasfär som omfattas av dataanalys kommer att växa till 5,2 zettabyte fram till 2025 (Leftronic, 2020).

Data genereras från otroligt många källor idag i olika format, däribland sociala nätverk och nu senast med uppkomsten av Internet of Things (IoT), vilket genererar mycket stora mängder data och har potential att vara mycket värdefull för organisationerna då de kan ge en ökad insikt om vad människor behöver, åsikter och upptäcka trender (Pereira & Costa, 2019). För att kunna överleva och vara konkurrenskraftig menar Pereira och Costa (2019) att organisationerna måste utforska möjligheterna som finns i denna typ av data.

Detta har skapat nya utmaningar då den relationella databasmodellen har mycket svårt för att klara av dessa olika typer av data, samt den otroligt stora datavolymen som Big Data innebär. Detta är anledningen till NoSQL-databasernas uppkomst (Ptiček & Vrdoljak, 2017). Det finns tre typer av data som man brukar skilja åt. Strukturerad, semistrukturerad och ostrukturerad data:

• Strukturerad data: Detta är data som har en struktur som är rigid och känd sedan tidigare och där alla element delar samma format och storlek. Strukturerad data är den typ av data som vanligtvis genereras av applikationerna i verksamheten hos organisationerna.

• Semistrukturerad data: Är data som i hög grad inte delar samma format och egenskaper med varandra och som är svår att representera i datastrukturer som är fasta. Ofta lagras denna typ av data i format som XML (Extensible Markup Language) data, RDF (Resource Description Language) data, JSON (JavaScript Object Notation) m.f.l.

• Ostrukturerad data: Detta är data som inte har någon enhetlig struktur, exempelvis multimedia-data så som text, bilder och filmer.

21

Figur 11 ovan illustrerar hur företag (i detta fall Facebook) använder sig av en användares data för att ta kunna skapa riktade annonser mot denna användare. I exemplet ser vi en användare som gillar filmen Free Solo10 _{från 2018 som handlar om Alex Honnolds försök att}

bli den första att friklättra upp för El Capitan, en 910 meter hög vertikal klippformation i Yosemite nationalpark, USA. Denna användare gillar även en klättring-sida på Facebook, bor i Umeå och studerar vid Umeå Universitet. Den data som samlas in genom denna information om användaren riktar därmed en annons mot användaren för IKSU klättring, som ligger i Umeå, har förmånliga studentrabatter och tillhandahåller en klätterhall. Det som benämns som Big Data är alltså som detta exempel multiplicerat med varje individuell användare hos Facebook, Amazon, Google, Netflix, YouTube och så vidare. Facebook är dessutom ett bra exempel på ett företag som förstått fördelarna med att använda sig av olika databaser för olika ändamål11_{, som t.ex. Apache Hadoop}12_{, Apache HBase}13_{, Apache Hive}14_{, Apache Thrift}15_{, och}

PrestoDB16 _{för Big Data-hantering, medan de använder MySQL som primär databaser i}

grunden för den sociala data.

3.5.2 Big Data Analytics

I en tid av Big Data där företag i olika branscher måste hantera enorma mängder data, kan denna data ge mycket värdefulla insikter om verksamheten och skapa ett övertag över sina konkurrenter. Big Data Analytics kan definieras som en process där man använder avancerad analytisk teknik på stora datavolymer som kan innehålla strukturerad, semi-strukturerade och ostrukturerade data från olika källor och storlek, allt ifrån terabytes till zettabytes (IBM, 2020). Analys av Big Data gör det möjligt att upptäcka mönster, okända korrelationer, marknadstrender och få en bättre förståelse för vad deras kunder föredrar - detta ifrån tidigare obrukbara data eller som inte varit tillgänglig. Företagen kan använda avancerade analys-tekniker, såsom analys av text, machine learning, prediktiv analys, data mining, statistik och språkteknologi, som möjliggör att de kan få nya insikter från enskilda outnyttjade datakällor eller tillsammans med befintliga affärsdata från organisationen (IBM, 2020). Big Data Analytics möjliggör för företag att analysera den typ av data som konventionell Business Intelligence lämnar orörd på grund av dess storlek eller datastruktur. Big Data Analytics kan skapa en rad olika fördelar för organisationen, som exempelvis effektivare marknadsföring, ökad operationell effektivitet och bättre kundsupport. En annan fördel är att det kan skapa ett övertag över konkurrenter i branschen, vilket en studie av Côrte-Real, Oliveira och Ruivo (2017) kommit fram till. De undersökte värdet av Big Data Analytics hos ett stort antal europeiska företag. Slutsatsen som de kom fram till var att Big Data Analytics kan vara en strategisk investering för att göra organisationen mer agil och skapa förutsättningar till överlevnad i konkurrensutsatta branscher.

22

3.6 The Red Queen Effect

En viktig del i företagens utveckling i förhållande till växande trender är vad som kallas för “The Red Queen Effect”, “The Red Queen hypothesis” eller “The Red Queen's race”, som avser företagens förmåga att anpassa sig till den accelererade utvecklingen - och speciellt för att kunna anpassa sig snabbare än sina rivaler (Derfus et al. 2008). Red Queen-effekten är baserad på en konversation mellan den Röda Drottningen och flickan Alice i Lewis Carrolls “Through the Looking Glass” från 1899, där Alice inser att även om hon springer så fort hon kan kommer hon ändå ingenstans i förhållande till sin omgivning. Den Röda Drottningen säger då: ”Here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” (Carroll, 1899: 345). Analogin introducerades första gången av biologen Leigh Van Valen år 1973, där den syftade på tävlingen i hur enheter dynamiskt interagerar och samverkar med varandra inom evolutionära och ekologiska teorier. Inom IT-verksamheter så handlar det dock om hur väl företag lyckas hålla sig relevanta genom att adoptera nya trender inom området (Tiwana, 2014). Följderna ifall ett företag inte skulle hinna med i ett sådant race skulle kunna vara att företagets anställda skulle ha allt svårare att hinna med sina arbetsuppgifter om dessa berodde på den teknik som företaget tillhandahöll - inom t.ex. Business Intelligence. Det första som skulle ske vid ett sådant fall skulle alltså vara att de anställda skulle få en ökad arbetsbelastning och tvingas jobba övertid för att hinna med, vilket är en av de fem faktorerna som representerar en dålig arbetsmiljö (Modak & Joshi, 2019).

4. Resultat och Analys

I följande avsnitt redovisas den data som vi fått ut från den enkätundersökning som skickades ut till verksamhetskonsulter och utvecklare på företaget, samt från de intervjuer som utfördes. Den data som vi valt att presenteras är det vi anser relevant för att kunna besvara det som studien ämnar undersöka, samt det som är av intresse för vidare forskning inom det undersökta området. Resultatet från varje datainsamlingsmetod följs av en analys och tolkning av datamaterialet.

4.1 Enkätundersökning

Vår enkätundersökning ämnade både att hjälpa oss i arbetet att konstruera intervjufrågor, men också att skapa en bild av vad medarbetarna som ingick i vår fallstudie hade för kunskaper om både relationella- och icke-relationella databaser. Den ämnade däremot inte att på något vis hjälpa oss att dra några väsentliga statistiska slutsatser.

23

4.1.1 Resultat av enkät

Den population som enkäten innefattade var både kvinnor och män, men dock huvudsakligen män, i åldrarna 21–39 år. Denna iakttagelse ansåg vi hade betydelse, eftersom vi misstänkte att äldre medarbetare inom IT, som utbildats före eller under tiden då de traditionella databaserna utvecklades och redan hade jobbat med SQL-databaser i några decennier då NoSQL-databaserna började utvecklas, kanske hade en mer konservativ syn och kände en viss motvilja att lära sig om dessa. Denna misstanke bekräftades dock aldrig i vår studie, eftersom respondenterna huvudsakligen var betydligt yngre. Det enda vi kunde se var när vi analyserade rådata från enkäten, var att de som kände till NoSQL-databaser sedan tidigare var övervägande konsulterna som var yngre än 39 år.

De tjugotvå respondenterna hade huvudsakligen två befattningar på företaget, dessa var verksamhetskonsulter/beslutstödskonsulter och utvecklare, och av dessa var det ganska precis hälften som kände till NoSQL-databaser sedan tidigare, genom kurser på universitet/högskola eller att de läst om det på egen hand. Däremot så ansåg alla respondenter som kunde något om databaser att de ägde en väldigt grundläggande kunskap om dem, och de NoSQL-databaser de kände till var de mest kända (MongoDB, Cassandra osv.).

I enkäten bad vi respondenterna att bedöma behovet av implementation av alternativa databaser i deras system, varpå en övervägande andel av dem svarade “Ja” och “Kanske”. Av kommentarerna att döma så ansåg de framförallt att NoSQL-databaser skulle kunna hantera större mängder data på ett effektivare och snabbare sätt: “Viss typ av data som är utan direkta relationer skulle kunna hanteras snabbare i NoSQL”. En av respondenterna som var skeptisk till implementationen av NoSQL-databaser hos företaget menade att de innebar alldeles för dålig säkerhet, och att för vissa av företagets kunder var säkerheten av yttersta vikt: “NoSQL är kort och gott för osäkert”.

Det framgick dock av enkäten att det har funnits tillfällen där medarbetarna på företaget känt att de inte kunnat möta en kunds behov på grund av begränsningar hos deras relationella databaser, och då har det framförallt handlat om större datamängder där det helt enkelt har tagit för lång tid att processa data. Vidare var andra begränsningar databasens struktur, som till exempel “Ruttoptimering”.

Slutligen så frågade vi respondenterna vilka trender inom BI de trodde skulle vara mest framstående inom de närmsta åren. Här framgick det tydligt att de medarbetare som svarat på enkäten mest trodde att “AI och Machine-learning” skulle vara den skulle vara främsta, medan Big Data var på andra plats tillsammans med Self-Service BI.

4.1.2 Analys av enkät

24

kände till NoSQL-databaser, men respondenterna i denna grupp var alldeles för få för att äga någon signifikans.

Resultatet av enkäten visade oss att kunskapsnivån om NoSQL-databaser hos vår fallstudie var låg, det vill säga att ingen av respondenterna ansåg sina kunskaper överstiga en tvåa på en ett-till-fem-skala. Detta tolkar vi som att kunskapsnivån hos respondenterna handlade mest om grundläggande kunskaper genom kurser på universitet/högskola, genom yrket eller eget intresse. Vi noterade också att de som ansåg att företaget skulle gynnas av implementering av NoSQL-databaser var de som hade något mer än den mest grundläggande kunskap om dessa databasmodeller.

De som däremot inte ansåg att företaget skulle gynnas av komplettering av alternativa databaser, var de som bedömde sin kunskapsnivå som lägst, och de argument de presenterade för oss genom enkäten var till exempel att företagets system var för små för att “att motivera utvecklingskostnaderna”, att säkerheten var för dålig hos NoSQL-databaser, samt att företagets system bygger allt för mycket på “relationer” i databaserna.

Vad gäller företagets system, som vi fått ta del av, så kan det nog vara så att systemen helt enkelt inte är stora nog för att motivera en komplettering av NoSQL-databaser, då många av databaserna som medarbetarna arbetar med på daglig basis i själva verket är kundernas egna SQL-baserade databaser. Dock finns det belägg för att mängden data kommer att öka markant inom de närmaste åren, och detta gäller även data som BI-företag arbetar med (Lynkova, 2020). En annan anledning är att kostnaden för lagring har blivit lägre vilket gör att fler företag väljer att lagra mer data från sina system och även olika typer av data (Chaudhuri, Dayal & Narasayya, 2011). Det andra argumentet som de tog upp var att NoSQL-databaser inte skulle vara tillräckligt säkra, något som inte stöds i den relaterade forskningen (Karavasilev & Somova, 2018).

Men, som sagt, så handlar det inte om att ersätta SQL-databaserna utan att komplettera dem med NoSQL-databaser där just sådana dynamiska databaser passar bättre, och på så vis kan de företag som använder sig av SQL-databaser, och vill behålla dem på grund av att de anser att de är säkrare för just deras ändamål, också ha det alternativet. Detta gäller även argumenten om att verksamhetens databaser är så beroende av “relationer”, eftersom även detta argument tycks antyda att det handlar om att byta ut relationella mot icke-relationella databaser, vilket som sagt inte är fallet.

Att respondenterna inte ansåg att Big Data kommer att vara framstående inom de närmaste åren tyckte vi var intressant, eftersom Big Data har stor potential att kunna ge deras kunder ökade insikter om deras verksamhet och detta stöds av Pereira och Costa (2019) som menar på att denna typ av data måste utforskas för att man i framtiden ska kunna överleva och vara konkurrenskraftig. Vidare kommer Big data innebära nya utmaningar i framtiden för alla företag som hanterar data (Lynkova, 2020).

4.2 Intervjuer

25

berodde delvis på den pandemi17 _{som pågick under tiden för studien och många av de anställda}

på företaget valt att jobba hemifrån. Hartman (2004) menar på att det är en rekommenderad metod när vi har begränsade resurser och är också en av de anledningar vi valt bekvämlighetsurval eftersom denna studie pågått under en mycket begränsad tid. Vi valde att intervjua personer som fortfarande arbetade från den egentliga arbetsplatsen, för att lättare kunna identifiera ansiktsuttryck, tonlägen och reaktioner på ett annat sätt än via länk.

Semistrukturerad intervjumetod tillämpades under intervjuerna då det brukar kunna generera rikare svar eftersom frågorna är mer öppna (Hartman, 2004) och utformades bland annat med hjälp av svaren från den enkät som vi skickat ut. Ett exempel på detta var resultatet om vilka trender som respondenterna trodde skulle vara mest framträdande. Detta fick oss intresserade av att söka en mer fördjupad bild av hur stor deras kunskap är om Big Data och höra mer om detta. I och med att vi använde en semistrukturerad intervjumetod gjorde detta att ordningsföljden inte var fast och att följdfrågor ställdes där vi ansåg att det behövdes.

Intervjuerna spelades in digitalt för att sedan transkriberas. Då transkriberingen utfördes av oss båda bestämdes det i förväg hur transkriberingen skulle gå till och regler upprättades för att det skulle bli lättare att koda datamaterialet. Därefter utfördes kodning av den data vi samlat in för att reducera och organisera den. Detta gjordes i enlighet med hur Hartman (2004) samt Hedin (1996) beskriver hur detta ska utföras. Första steget i kodningen bestod i att ta ut begrepp eller nyckelord ur texten som ansågs vara mest framträdande och relevanta för studien. När detta steg var avklarat skapades teman/kategorier som dessa nyckelord sorterades i. Viktigt i denna kategorisering var att ett nyckelord endast fick finnas under en (1) kategori och inte passa in under flera. Resultatet presenteras utifrån de teman som tagits fram vid kodningen.

Tabell 1 - Informanternas yrkesverksamma roll, längd på intervjun samt benämning dessa har fått

4.2.1 Behov av nya lösningar

Alla respondenterna är eniga om att volymen av data har ökat mycket under tiden den tid de varit verksam i företaget.

“Ja, det ökar med flera miljoner rader varje dag” - IO1

Under intervjuerna noterades det att verksamhetskonsulterna upplever att det finns problem när det kommer till hur man ska hantera kunder som har stora datamängder. En stor

26

utmaning med nuvarande lösning är att det tar otroligt lång tid att processa data vid större volymer vilket gör att prestandan påverkas negativt.

“Vi har kunnat möta behoven, och kunnat lösa dom behoven som dom har haft, men dom lösningarna skulle kunnat ha fungerat bättre, exempelvis på om det skulle ha varit, om man kanske skulle använda nån annan teknik än den vi använder nu. Det fungerar, men, eh, det är eventuellt, så kan det ta… vad kan jag ta för exempel? Om det har med stora datamängder å göra, som det är i ett scenario som jag har, då fungerar det nu inte superbra. Det fungerar, men det kan ta lång tid”. - IO1

Respondenterna nämner att det är framförallt stora kunder som har dessa stora datavolymer. IO5 menar på att man snart kommit till en punkt där det inte är möjligt att använda nuvarande lösningar när det gäller dessa kunder.

“Vi har ju en kund som har väldigt väldigt väldigt mycket data, och det är data som ska fungera i nutid, ett år bakåt, två år bakåt och tre år bakåt. Och det blir jättemycket data, och som det är uppsatt nu så, alltså det kommer komma en breakpoint där vi inte kommer att kunna ha det så här, där vi måste byta hur det är”. - IO5.

Några av de problem som detta leder till är att det tar mycket lång tid vid inläsningen av data och vid skapandet av data-kuberna. Detta leder i sin tur att det tidsfönster inom vilket underhåll får ske blir större. Då tjänsten inte är tillgänglig under detta tidsfönster för kunden gör det att den tid som kunden kan använda systemet minskar när datamängden ökar.

“Då blir det som att, det påverkar ju kunden för att dem fönstrena kan inte vara… man stoppar ju deras verksamhet, eller den delen som använder tjänsten. Så har du rätt att göra saker som stänger man ned tjänsten. Den blir ju bara längre, längre och längre. För det tar ju längre och längre tid att processa.” - IO5

En av konsulterna som intervjuades menade på att det är pressande med dessa större datamängder då det kräver mer från deras yrkesroll. Beräkningarna måste programmeras smart annars leder det till en försämrad användarupplevelse för kunden. Vidare nämner de att det påverkar dem i form av att vyerna i tjänsten blir mer långsamma och att det tar längre tid att byta mellan dem och överlag ger som följd försämrad prestanda.

“Det påverkar ju kunden eftersom det påverkar ju hur vi måste hantera att det inte klarar av stora datavolymer vilket då slår på att prestandan blir sämre, och det slår ju ja men det är ju som kunden som sitter i produkten som får problem med det. Så det är ju pressande. Så det är ju som hur man hanterar det som då slår på kunden” -IO5

Flera av respondenterna pratade om hur de idag försökt hantera och jobba runt problemen som stora datavolymer ställer till. De nämner bland annat att man arbetar utifrån sin tjänsts begränsningar, vilket betyder att de ofta helt enkelt berättar för kunden att de beräkningar som kunden önskar inte är möjliga då prestandan kommer bli för låg. En utvecklare nämner att de på senare tid tagit fram ett script eller program som har till uppgift att underhålla och rensa gammal data i databaserna som mål att försöka lyckas att få ned datamängden och öka prestandan.

27

IO4 nämner att stora datamängder innebär fler konsulttimmar som kunderna måste betala vilket många inte är intresserade av.

“Dels, tenderar det att bli väldigt många fler konsulttimmar. Alltså vi måste verkligen försöka få ned det så kompakt det är möjligt, vilket så klart alltid är bra. I en bransch som IT-branschen ska det gärna gå så snabbt som möjligt och det ska vara så billigt som möjligt. Så då kan det oftast bli en diskussion med kunden att, ja men vi skulle behöva typ femton timmar till för att det här ska vara helt hållbart” -IO4

Det var framförallt de intervjuade verksamhetskonsulterna som jobbar med kunddata som upplever problem med dagens databaslösning medans utvecklarna inte alls upplever detta i samma grad.

“Vi jobbar mest med systemets inre databaser. Så vi har, eller många av oss har varit ganska nöjd med ja det som finns, men dem som jobbar mer mot kunden där kan jag inte svara. Men det jag kan säga att SQL-server var väldigt kompetent verktyg jämfört med exempelvis MySQL” - IO3

4.2.2 Kunskap om NoSQL

Efter att vi tagit del av resultatet från enkäten så framgick det tydligt att kunskapsnivån om NoSQL-databaser - och även Big Data - var relativt låg hos medarbetarna på företaget som ingick i vår fallstudie. Så när vi tog fram de frågor vi skulle använda under intervjuerna så förstod vi att frågan “Vad kan du om NoSQL-databaser” skulle leda till spekulativa svar och gissningar - vilket också blev fallet.

“Jag skulle inte säga att jag kan, kan mycket om det. Utan jag har ju naffsat lite på det.” - IO1

“Jo jag har ju läst det någon gång på universitetet men jag vet inte om jag labbade med det någonting. Så jag kan väl otroligt bas…, vet väl typ vad det handlar om precis.” - IO2

“Man har ju läst om dem [NoSQL-databaser] någon gång men det har inte blivit projekt av det så därför är kunskaperna väldigt bristfälliga.” -IO3

“Jag skulle lägga mig på en Basic-nivå.” -IO4

“Alltså de [kunskaper om NoSQL-databaser] är nästan obefintliga.” -IO5

Respondenterna försökte sedan, baserat på deras kunskap om alternativa databaser, att ge sitt utlåtande huruvida det skulle gynna företaget vid en implementering av dessa, och naturligt nog blev svaren spekulativa, vilket vi också hade räknat med. Något som återkom i dessa svar var vikten av relationer hos deras befintliga databaser, och de menade att detta var en anledning till varför NoSQL-databaser (alltså icke-relationella databaser) inte skulle passa in.

“Alltså, för det mesta är det oftast, så har ju data nån slags relation till andra. [...] Det är, är, oftast är det, har dom ju även på deras sida, för vi läser ju mycket från deras egna databaser som då även är relationsbaserade i stort sett det mesta av deras, ehm… kan väl va i enstaka fall, men för det mesta.” -I01

“...i vår produkt om man säger själva kärnan är mycket så här relationer i mellan grejer.” -IO3

28

Överlag var respondenterna skeptiska till en sådan implementation baserat på deras kunskap om NoSQL-databaser, även om de bekräftade att behovet av mer dynamiska databaser kommer att växa allt mer i takt med att den data de processar blir större. Då kommer företaget tvingas, menar de, att hitta andra lösningar så att de kan möta kunderna tidskrav.

“Det är snarare att det där att komma runt det eftersom Big Data inte riktigt stöds så bra av vanliga relationsdatabaser, så måste vi ju hitta på någonting. Vilket kanske är enklare med NoSQL-databaser men det vet jag inte.” -IO5

4.2.3 Framtidsutsikter

De flesta av intervjuobjekten nämner att många av databaserna de jobbar med ligger i deras kunders system, och blir på så vis helt omöjliga för dem att göra något åt även om de skulle vilja. Dessa relationella databaser är ofta väldigt stora och ligger i gamla traditionella system som skulle kräva stora summor pengar, tid och resurser för att förändra.

“Det är, är, oftast är det, har dom ju även på deras sida, för vi läser ju mycket från deras egna databaser som då även är relationsbaserade i stort sett det mesta av deras, ehm… kan väl va i enstaka fall, men för det mesta.” -IO1

Detta kan komma att bli en utmaning för företaget i framtiden, då respondenterna också förutspår att det närmar sig en brytpunkt för den mängd data de kan processa under den tid som kunderna är villiga att betala för.

“Vi har ju kunder där vi börjar nå en brytgräns där det börjar komma in så att vi kör igång nattjobbet klockan ett på natten och sen så tar det fem timmar och kunden ska in igen klockan sex. Ja men då är det ju kört och där börjar vi närma oss en brytgräns, och vi har ju vissa kunder som är verkligen alltså, några av våra första kunder där vi börjar brytgränsen men timmarna det skulle ta att liksom börja städa upp och göra allting rätt igen, vi har inte dem, kunden vill inte betala för dem och då börjar det se lite farligt ut. [...] Som sagt, det kan man ju gå igenom men det tar tid och antingen ska vi betala det genom att en konsult sitter med det eller ska kunden betala det och det är ganska svårt att argumentera för.” -IO4

Big Data är något som de flesta av intervjuobjekten har liten kunskap om. IO5 berättar att det pratas mycket sällan om Big Data på företaget, utan det är framförallt AI Machine Learning som de tror är den främsta trenden de närmsta åren. IO4 menar på att hantering av Big Data skulle kunna vara ett bra säljargument för att visa på att deras BI-produkt är mångsidig och att utveckling är något som är viktigt för att deras kunder ska fortsätta använda den.

4.2.2 Analys av Intervjuer