behovet av nosql- databaser hos business...
TRANSCRIPT
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
Gottfrid Wännberg och André Forslöf
Innehåll ABSTRACT ........................................................................................................................................................ 4
1. INLEDNING ................................................................................................................................................... 5
1.1 PROBLEMFORMULERING ...................................................................................................................................... 6
1.2 SYFTE .............................................................................................................................................................. 6
1.3 AVGRÄNSNING .................................................................................................................................................. 6
2. METOD ......................................................................................................................................................... 7
2.1 VETENSKAPLIG METOD OCH ANSATS ....................................................................................................................... 7
2.2 FORSKNINGSETISKA STÄLLNINGSTAGANDEN ............................................................................................................. 7
2.3 LITTERATURINSAMLING ....................................................................................................................................... 8
2.4 DATAINSAMLINGSMETODER ................................................................................................................................. 8
2.5 FALLSTUDIE ....................................................................................................................................................... 8
3. BAKGRUND OCH RELATERAD FORSKNING .................................................................................................... 9
3.1 NOSQL-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.2 DE 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.3 BUSINESS INTELLIGENCE .................................................................................................................................... 17
3.3.1 Extraction, Transformation, Loading (ETL) .......................................................................................... 18
3.3.2 OLAP och data mining ......................................................................................................................... 18
3.4 NOSQL INOM BUSINESS INTELLIGENCE ................................................................................................................ 19
3.5 TRENDER INOM BUSINESS INTELLIGENCE ............................................................................................................... 19
3.5.1 Big Data ............................................................................................................................................... 20
3.5.2 Big Data Analytics................................................................................................................................ 21
3.6 THE RED QUEEN EFFECT.................................................................................................................................... 22
4. RESULTAT OCH ANALYS .............................................................................................................................. 22
4.1 ENKÄTUNDERSÖKNING ...................................................................................................................................... 22
4.1.1 RESULTAT AV ENKÄT ...................................................................................................................................... 23
4.1.2 Analys av enkät ................................................................................................................................... 23
4.2 INTERVJUER .................................................................................................................................................... 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
5.1 METODKRITIK .................................................................................................................................................. 32
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
medarbetare som ingick i vår fallstudie.
4
Abstract This study presents perceptions towards non-relational, or just NoSQL, databases in IT- and
Business Intelligence companies, where we try to determine the need for NoSQL databases
in these areas. Earlier studies indicate that the rise of Big Data will force companies to sooner
or later expand their data storages to be able to handle the vast amount of data that will
emerge, and to find ways to easily manage it. With this in mind, we wanted to determine why
some Business Intelligence-companies still had not implemented non-relational databases in
their systems, what this would implicate and how necessary it actually is. Our study included
a case study at a Business Intelligence-company that still had not adopted these relatively
new kinds of databases. First we used a survey to get an idea of what kind of knowledge
concerning NoSQL-databases the employees at the company actually had, and to help us
create questions for the interviews that would be the next step in our study. Through the
interviews we had with three consultants and two developers we gathered a lot of interesting
data concerning the company’s attitude towards implementing alternative databases in the
system as a complement to their current SQL-based databases. For example, the low level of
knowledge about NoSQL-databases of the employees showed a lot of preconceptions and
assumptions about these alternative databases, that by extension led to a very skeptical
attitude towards them. We learned however that the employees, especially the consultants,
worried about the growing amount of data, which already was becoming laborious, and we
estimate that companies that has not adopted a solution for this will eventually reach an
inflection point where the amount of data will exceed the company’s ability to handle it.
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?
Big Data är något som det pratas om mycket idag och skapar nya utmaningar för hur man
ska kunna lagra och analysera de enorma datamängder som Big Data innebär. Även inom
området Business Intelligence (förkortas BI) är detta också aktuellt då den datamängd som
genereras i verksamheten hos många företag och organisationer idag är mycket stor, och de
önskar att kunna analysera denna data för att kunna ta bättre beslut. Business Intelligence är
ett samlingsbegrepp över mjukvara, plattformar, teknologier och verktyg som används till att
utforska affärsdata, trender och relationer mellan data. Beslutsfattare kan sedan analysera
denna information och få en inblick i hur deras verksamhet presterar, identifiera problem,
upptäcka trender och hitta nya affärsmöjligheter. I dagens IT-samhälle där utvecklingen går
mycket snabbt är detta viktigt då det hjälper företagen att kunna ligga steget före
konkurrenterna genom att ta snabbare, mer välavvägda och bättre affärsbeslut.
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.
Figur 1 - Illustrerar vår avgränsning
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 Denna studie följer de forskningsetiska principer inom humanistisk-samhällsvetenskaplig
forskning som Vetenskapsrådet (1990) tagit fram. Detta innebär att studien utgått från de fyra
principerna: Informationskravet, samtyckeskravet, konfidentialitetskravet och
nyttjandekravet. Detta innebär bland annat att deltagarna kommer informeras om vad syftet
med studien är, att deltagandet är helt frivilligt samt att hen när som helst kan avbryta sin
medverkan. Deltagarna informeras även om att studien kommer publiceras i det Digitala
Vetenskapliga Arkivet (DiVA). Samtycket till deltagandet ska godkännas av deltagaren och
påtryckningar från oss som skapat studien får under inga som helst omständigheter
förekomma. Vidare ska även högsta möjliga konfidentialitet ges till de deltagare som är med i
denna studie vilket innebär att det inte ska gå att identifieras i vare sig arbetsmaterial eller i
slutrapport. Det material som studien producerar ska även förvaras på ett sådant sätt att
obehöriga ej kan få tillgång till detta. Slutligen får uppgifter om deltagare i studien endast
användas i forskningssyfte.
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
två grupper är de som arbetar mest med företagets databaser. Skillnaden mellan dem är att
utvecklare arbetar med att utveckla och förbättra beslutsstödsprodukten och jobbar
framförallt mot databaser som innehåller intern information från företaget.
Verksamhetskonsulterna arbetar direkt mot kund och är de som levererar BI-lösningen. Detta
innebär att de till skillnad från utvecklarna arbetar med databaser som innehåller data från
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
Figur 2 - SQL-databaser
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
Figur 3 - Databasers skalbarhet
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).
Detta beslut väger tungt för ett systems funktionalitet, speciellt storskaliga system som
hanterar så kallad Big-Data (stora mängder data), eftersom ett sådant felaktigt beslut kan
komma att kosta företag mycket pengar om något skulle gå fel. Den största utmaningen för
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).
Figur 5 - Polyglot Persistence
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
Figur 6 - SQL Injection
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 Voldemort3,
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 - Nyckelvärdesbaserade databaser
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)
Figur 8 - Dokumentbaserade databaser
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 Bigtable7
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 databaser
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
8 ArangoDB (https://www.arangodb.com/why-arangodb/sql-aql-comparison)
9 Apache TinkerPop (https://tinkerpop.apache.org/gremlin.html)
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
För att kunna använda den data som finns lagrad i datavaruhuset för att ta bättre beslut krävs
analysverktyg. Två vanliga verktyg som används är OLAP (Online Analytical Processing) och
verktyg för data-mining (Chaudhuri, Dayal & Narasayya 2011). OLAP är ett koncept där man
använder sig av multidimensionell datastruktur som bygger på den data som finns i
datavaruhuset (Chaudhuri, Dayal & Narasayya 2011). En vanligt förekommande term är
OLAP-kuber, vilket innehåller ett antal dimensioner av data som möjliggör att användare kan
vrida, vända och filtrera informationen i kuben. OLAP ger fördelar som att vi kan snabbt
analysera aggregerad data, analysera informationen från flera olika perspektiv och
dimensioner, samt analysera specifika tidsserier.
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
NoSQL-databaser istället för SQL. De har jämfört NoSQL-databasen 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 Det finns en rad olika trender inom Business Intelligence. En av dessa är Big Data och Big
Data Analytics. Enligt Holst (2019) var marknaden för Big Data och Big Data Analytics 2018
värderad till 168,8 miljarder dollar och beräknas att år 2022 vara värderad till 274,3 miljarder
dollar vilket är en årlig ökning på 13,2 procent. Att kunna implementera denna typ av
avancerad analys av Big Data i Business Intelligence-systemen är därför intressant då de
kompletterar varandra på det sätt att Big Data Analytics kan ge ett perspektiv på data som är
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.
Figur 11 - Big Data
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 Hadoop12, Apache HBase13, Apache Hive14, Apache Thrift15, 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.
10 https://www.imdb.com/title/tt7775622
11 https://www.8bitmen.com/what-database-does-facebook-use-a-1000-feet-deep-dive
12 hadoop.apache.org
13 hbase.apache.org
14 hive.apache.org
15 thrift.apache.org
16 prestodb.io
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.
Enkätens innehåll var en blandning av slutna och öppna frågor. Innan enkäten skickades ut
testades den först på tre handplockade personer som fick representera målgruppen utan att
vara en del av den, för att se att respondenterna förstod frågorna och att de svar vi fick in var
av värde för studien. När denna pilotenkät var avklarad distribuerades den slutgiltiga
versionen ut via företagets intranät till tjugotvå utvecklare och verksamhetskonsulter och låg
öppen för svar i fem dagar.
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
NoSQL-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
Som vi tidigare nämnt så hade vi för avsikt att med enkäten skapa oss en bild över fallets
verksamhet, samt ge oss vägledning vid framtagandet av intervjufrågor som skulle vara den
primära metoden för att samla in data till vår studie. Vi var intresserade av att ta reda på om
det fanns någon korrelation mellan åldern hos respondenterna och det värde de ansåg att
NoSQL-databaser skulle innebära för företaget. Genom enkäten framgick det dock att
respondenterna som innefattas av medarbetare hos företaget för vår fallstudie huvudsakligen
var i åldrarna 21–39 år, och därmed betydligt yngre än vad vi hade behövt för att kunna besvara
just detta. Det enda vi kunde se var att respondenterna som avvek från denna kategori inte
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 I studien utfördes fem intervjuer på plats hos företaget. Där intervjuades tre
verksamhetskonsulter samt två utvecklare. Intervjuerna genomfördes alla under samma dag
och valet av informanter skedde genom ett rent bekvämlighetsurval. Anledningen till detta
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
17 https://www.umu.se/covid-19
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.
“På senare tid har vi börjat med, eller jobbat fram ett underhållsscript eller ett program
som rensar och som bygger upp eller optimerar tabellerna och index och sådant, för att
databaserna blir ju gigantiska” -IO3
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
“Just det att vi kan ha så fantastiska volymer ibland där allting behöver ha koppling till
varandra för att de ska slå i alla möjliga vinklar.” -I04
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
Under intervjuernas gång så uppenbarade det sig flera saker som vi inte hade tänkt på eller
räknat med. Till att börja med så märkte vi hur de vi intervjuade, på samma sätt som
respondenterna hos enkätundersökningen, uppfattade det som att vi menade att ersätta de
traditionella databaserna med nya alternativa databaser - vilket ju inte var fallet då vi menade
att komplettera SQL-databaser med NoSQL-databaser där det passar, som är i enlighet med
vad Khine och Wang (2019) och även Fowler och Sadalage (2013) skriver om Polyglot
Persistence. Vi förstod därför att vissa av våra frågeställningar hade varit för diffusa och att vi
borde ha varit mer konkreta vad vi menade med implementation av NoSQL-databaser hos BI-
företag. Vi valde vidare att lägga till intervjufrågor om NoSQL-databaser (eftersom det är
29
kärnan i vår studie) trots att det av enkätundersökningen hade visats att kunskapsnivån för
dessa var låg hos medarbetarna i vår fallstudie, vilket ledde till att en del av svaren som vi fick
av intervjuobjekten var rena gissningar och spekulationer.
Något som var återkommande i intervjuerna var antagandet att NoSQL-databaser inte
skulle passa in i företagets system på grund av att de förlitade sig alldeles för mycket på
relationer i databasen, och sanningen är den att hos NoSQL-databaser, dvs. icke-relationella
databaser, så saknar vi relationer i den aspekten. Då de traditionella databaserna bygger på
relationer, så måste vi i dessa nyare databaser själva skapa relationer mellan till exempel
dokument hos MongoDB. Däremot så nämns det upprepade gånger att systemet hanterar
många olika typer av databaser, och att vissa, om än något tveksamt, bekräftar att det finns
områden där NoSQL-databaser skulle passa in.
Med tanke på den låga kunskapsnivån om NoSQL-databaser som bekräftades i både
enkäten och i intervjuerna, så anser vi att det finns utrymme för ett antagande om att områden
i företagets system förekommer där det skulle vara lämpligt att implementera alternativa
databaser. Däremot betyder också detta att det skulle krävas mycket av företaget för att utbilda
sina medarbetare, både konsulterna och utvecklarna, för att kunna komplettera med
alternativa databaser på bästa sätt i linje med de svårigheter som Desmarets (2018) och
Fernando (2018) tar upp och som vi nämnt tidigare. Det kan vidare bli svårare att hitta rätt
kompetens, då den låga kunskapen hos företaget visar att kunskap om NoSQL inte är lika
självklar som kunskap om de traditionella databaserna.
För majoriteten av företagets kunder fungerar dagens lösningar mycket bra men för ett
antal börjar datavolymen som genereras bli ett prestandaproblem. Detta är i enlighet med vad
Bonnet et al (2011) studie visar, att SQL-databaser har svårt att kunna aggregera data vid stora
datavolymer.
Ett exempel på denna problematik berättar IO5 om, att det är en kund som vill analysera
försäljningsdata flera år bakåt i tiden samt jämföra den mellan olika kostnadsställen. Detta
leder till stora prestandaproblem för kunden när den ska ladda de olika vyerna i
analysprogrammet men även att det tar mycket lång tid att kunna aggregera data och bygga
OLAP-kuberna för konsulterna. Här finns det ett behov av att använda en annan typ av
databaslösning för kunder som har stor datavolym. Detta stöds av Bonnet et al (2011) och deras
tester mellan relationella och icke-relationella databaser som visar på att den senare är
snabbare på att aggregera och läsa ut data från stora datavolymer.
Slutligen blir det alltså allt viktigare för företaget i vår fallstudie, på grund av The Red Queen
Effect, att se till att implementera rätt (ny) teknik före sina konkurrenter för att kunna
bibehålla ett övertag gentemot dem (Derfus et al. 2008) (Tiwana, 2014). Att kunna hantera Big
Data och Big Data Analytics genom en implementation av någon form av NoSQL-databas
skulle kunna ge ett övertag över konkurrerande BI-företag. IO4 nämner att hantering av Big
Data hade varit ett bra säljargument och det tror även vi att det hade varit då detta hade skapat
möjlighet för företagets kunder att själva kunna få så bra förutsättningar att överleva i hårt
konkurrensutsatta branscher där The Red Queen Effect råder. Denna analys är i enlighet med
vad Côrte-Real, Oliveira och Ruivo (2017) kommit fram till i deras studie om vikten av Big
Data Analytics. Att detta skulle vara fördelaktigt rent ekonomiskt och värt att investera tid och
30
resurser på är något som även stöds av Holst (2019) statistik om vad denna sektor är värderad
och hur den beräknas öka.
5. Diskussion och slutsats I början av vår studie hade vi en del antaganden som vi hade för avsikt att bekräfta eller
avfärda. Till att börja med så ville vi ta reda på varför en del företag inom BI inte hade valt att
bygga ut sina system med alternativa databaser för att kunna hantera den allt mer växande
datamängden, eftersom vi, genom vår utbildning, kommit till den insikten att NoSQL-
databaser lämpar sig ypperligt för just detta ändamål. Vårt antagande om detta var att de helt
enkelt hade för lite kunskap om NoSQL-databaser, och därför inte kunde se förutsättningarna
för en sådan implementation, eller kunde det vara så att de ägde kunskapen och ändå hade valt
att inte använda sig av dem - och vad var då anledningen till detta?
Dessa antaganden utmynnade i studiens frågeställningar:
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?
För att besvara dessa frågor skickades en enkätundersökning ut till utvecklare och
verksamhetskonsulter, samt genomfördes kvalitativa intervjuer. Resultatet av studien visar på
att det idag finns ett behov av alternativa databasmodeller när det kommer till större kunder
som har stora mängder data som ska analyseras. Detta påverkar verksamhetskonsulterna
eftersom det tar lång tid att processa data, samt skapa OLAP-kuberna, men resulterar även i
försämringar i analystjänstens prestanda för slutkunden. Idag har man försökt komma runt
problemen när det kommer till stora datavolymer genom att skapa program som rensar i
databaserna och selekterat bort data i högre utsträckning än tidigare. Kunskapsnivån bland de
anställda gällande NoSQL-databaser är låg - både bland utvecklare och verksamhetskonsulter.
En implementation av NoSQL-databaser för att täcka nuvarande och framtida behov skulle
vara en krävande utmaning för företaget.
Vi är medvetna om att de konsulter och utvecklare som svarat på enkäten, och de som
senare blev intervjuade, inte har så stora möjligheter att förändra verksamheten med den
magnitud som skulle behövas för denna typ av implementering - vilket eventuella IT-arkitekter
och chefer har. Trots detta är vår studie ändå relevant, då den speglar verksamhetens generella
bild av vad icke-relationella databaser egentligen innebär och dess medarbetares defensiva
inställning till deras befintliga system och databaser.
Även om det var uppenbart att de flesta av respondenterna var skeptiska inför en
implementation av alternativa databaser, på grund av bland annat bristen av relationer, så var
det lika uppenbart att det fanns begränsningar hos deras nuvarande databaser som riskerade
att ställa till med stora bekymmer för företaget i framtiden. En av dessa begränsningar, som
bland annat IO4 vittnar om, var att balansen mellan tiden det tar att processa data och tiden
som kunderna är villiga att betala för börjar närma sig en brytpunkt.
Det vittnas vidare om att mycket av den data som gör att det tar lång tid att processa också
är gammal, men ingen vågar riktigt att ta bort denna data. För att kunna göra något åt detta så
skulle konsulterna behöva sitta och gå igenom all data och sortera ut det som inte längre
31
behövs, men detta är något som skulle ta mycket tid, och det är tid som ingen av företagets
kunder skulle vara villiga att betala för.
Allt detta indikerar att det finns ett behov, om inte just idag så i framtiden, för företaget i
vår fallstudie, och andra företag i en liknande situation, att utveckla sina system och databaser
så att de kan möta kundernas krav och behov. Om företaget väljer att inte utveckla så att de
kan möta kunderna, så finns det en risk för att konsulterna måste arbeta under så pass högt
tryck att det orsakar stress och risk för deras hälsa, eftersom arbetsbelastning och påtvingad
upprepad övertid, är en av de fem faktorerna som representerar en dålig arbetsmiljö (Modak
& Joshi, 2019). Annars så finns risken att kunderna helt enkelt väljer något annat företag som
kan processa deras data snabbare. Så för att gynnas i The Red Queen Effect så skulle företaget,
som vi anser det, gynnas av att se sig om efter moderna lösningar på detta annalkande problem.
Detta skulle kunna handla om en implementation av någon form av NoSQL-databas för att
kunna hantera Big Data och kunna erbjuda sina kunder möjlighet till Big Data Analytics. Det
hade varit värt den investering som skulle krävas då det öppnar upp möjligheter till att slå sig
in på en ny, högt värderad marknad, vars värde dessutom beräknas fortsätta öka. Det hade
även både hjälpt företaget att utvecklas och skapa sig en konkurrensfördel men även kunnat
ge dess kunder ökad möjlighet till att själva få bästa förutsättningar för att överleva och öka
chansen till att skapa fördelar över sina konkurrenter.
Vid intervjuerna framkom det att det finns en stor skillnad mellan verksamhetskonsulter
och utvecklare, vilket egentligen inte är så konstigt eftersom utvecklarna inte arbetar lika
mycket med databaser som verksamhetskonsulterna gör, då databashantering är själva kärnan
i konsulternas arbete. Detta gjorde att kunskapen om NoSQL-databaser naturligt nog var lägre
hos utvecklarna, och vi anade betydligt mer skepticism hos dessa inför implementation av
alternativa databaser. Den största anledningen till detta har att göra med att medan
konsulterna hanterar kunddata som yttrar sig i kolossala volymer, så arbetar utvecklarna mest
med de interna databaserna som sparar information för den specifika produkt de arbetar med,
vilket bara handlar om “100 MB eller nånting” och inte skulle bli någon större prestandavinst
enligt IO2. Så resultatet blev i slutändan att de utvecklare vi intervjuade var de som gav de
mest spekulativa svaren och inte ansåg att det fanns någon större mening att implementera
databaser - även fast dessa kände till den växande datamängden hos konsulternas databaser.
Något som iakttogs under intervjuerna, samt av de svar vi fick, var att kraven på
verksamhetskonsulternas prestation ökat i samband med att datavolymen blivit allt större. Det
var tydligt både genom deras kroppsspråk och hur de uttryckte sig, att de var pressade över
den nuvarande situationen. Detta tog sig uttryck både i form av att det tar längre tid att
processa kundernas data, vilket gör att det blir fler konsulttimmar, vilket i sin tur ökar
kostnaderna för kunden, men även i att beräkningarna som ska programmeras måste vara mer
genomtänkta och analyserade för att inte påverka prestandan på vyerna för slutkunden.
Utifrån den data som samlats in kan vi se att de istället för att börja titta på andra
databaslösningar valt att försöka komma förbi de utmaningar som ökade datamängder skapat.
Detta genom att i högre grad selektera vilken data som ska importeras, samt åldern på denna.
De har även skapat program som rensar gammal data från databaserna som ett led i att försöka
öka prestandan. En aning varför dessa åtgärder gjorts, framför att börja titta på exempelvis
NoSQL-databaser, är något som kan ha att göra med kunskapen om dessa är mycket låg på
32
företaget som resultatet från intervjuerna och enkätundersökningen visade. En annan
anledning kan vara att det helt enkelt är den billigaste och snabbaste lösningen utan att behöva
göra några förändringar i befintlig arkitektur.
5.1 Metodkritik I denna del kommer vi att gå igenom de metoder vi använt oss av i studien och utvärdera
utfallet av dem, samt ställa dessa mot kritik som finns från litteraturen.
Vi använde enkätundersökningen för att ge oss en övergripande bild av företaget, samt
skapa ett underlag som skulle hjälpa oss att ta fram frågor till intervjuerna. Dock skriver
Eriksson och Hultman (2014) att det är bra att ha ett flertal olika datakällor för att kunna få en
heltäckande bild av det sammanhang vi har valt att analysera, något som benämns som
“triangulering”. Vi hade till en början tänkt att ta en betydligt större del av företagets produkt,
t.ex. för att kunna försöka förstå hur en implementation av NoSQL-databaser skulle göra sig
rent praktiskt, men på grund av den knappa tiden vi hade på oss för vår studie, samt den
rådande pandemin, så valde vi bort detta för att kunna fokusera på den data vi fick in genom
enkäten och intervjuerna. Att vi använder få datakällor gör att det enligt Eriksson och Hultman
(2014) finns risk till en beskrivning som är obalanserad och resultera i att man drar
onyanserade slutsatser.
Även fast det företag som vi skulle studera var inom IT-området, så upptäckte vi dock att
några av de termer som vi använde vid enkäten och intervjuerna inte var lika självklara för
informanterna. Vi hade nyligen avslutat en kurs på universitetsnivå om NoSQL-databaser, så
för oss var kunskapen väldigt färsk, medan för många av medarbetarna på företaget så hade
det gått några år sedan de läst om alternativa databaser, och vissa hade aldrig läst om dem alls.
Detta ledde till något som Eriksson och Hultman (2014) varnar för, nämligen att vi måste
förklara facktermer (om NoSQL-databaser) för respondenterna.
Vi är dock väldigt nöjda med valet av fallstudie, eftersom den gav oss verklighetsnära
beskrivningar av det område vi ville studera och ett sammanhang som annars hade haft svårt
att greppa i enlighet med Eriksson och Hultman (2014). Under den tid vi spenderade hos
företaget uppkom en mängd frågor och begrepp som vi kunde använda oss av, och
vidareutveckla vår studie ytterligare.
När vi tog del av resultatet av enkäten så insåg vi att några av de frågor vi hade ställt hade
varit en aning diffusa, då svaren blev något spekulerande. Det hade, till exempel framstått som
att vi ämnade att byta ut de traditionella databaserna och ersätta dem med nya alternativa
databaser. Detta gjorde förstås att många som besvarade enkäten antagligen blev skeptiska till
en sådan förändring på deras arbetsplats.
När det kommer till bortfallet av svarsfrekvensen så menar Japec (1997) i en studie av
Statistiska centralbyrån (SCB) att det kan vara svårt att säga vad som är ett acceptabelt bortfall,
då ett bortfall på 10% i en undersökning kan vara mer förödande än 25% i en annan. Av den
andel konsulter och utvecklare som fick möjligheten att svara på vår enkät hade vi ett bortfall
på ca 32 %, vilket vi anser vara ett acceptabelt bortfall för vårt ändamål med enkäten.
Något som vi visserligen inte kunde råda över, men som likväl begränsade oss i vår studie
var den rådande pandemin som vid tiden för intervjuerna började göra det allt svårare för oss.
Som nämnts tidigare så var det många på företaget som vid den här tiden som hade valt att
jobba hemifrån, så när vi väl skulle utföra våra intervjuer så handlade det mer om att hitta
33
tillräckligt många att intervjua, än att välja ut specifika medarbetare med specifika
befattningar.
Vi uppfattade också att många av de svar vi fick var väldigt spekulativa och nästan något
undvikande. Anledningen till detta kan ha varit att de visste att vi var där för att ta reda på
varför de inte hade implementerat NoSQL-databaser, och därmed antog att vi föredrar dessa
framför de traditionella och på så vis inte önskade att kliva oss på tårna. Därför ville de inte
använda negativa extremvärden, något som Eriksson och Hultman (2014) benämner som
centraltendensen och tar upp som en fallgrop i intervjustudie. Vad vi kunde ha gjort
annorlunda idag, baserat på denna erfarenhet, är nog att vi inte skulle ha arbetat på plats hos
företaget innan intervjuerna och inte varit lika öppna med vad vår studie gick ut på för att
minska centraltendensen. Detta skulle emellertid i viss mån påverka vår möjlighet att uppfylla
informationskravet, som bland annat innebär att deltagarna informeras om studiens syfte. En
sådan metodjustering hade därför behövts utföras med försiktighet.
Något som vi däremot insåg var väldigt positivt med att utföra intervjuer, var att vi hade
möjlighet att justera dem beroende på den respons vi fick av respondenterna. Som ett exempel
så fann vi redan vid första intervjun att en fråga som hade tagits med var helt pleonastisk, för
då den första respondenten hade svarat på den, behövde vi inte de andras svar på den frågan.
6. Vidare forskning Resultatet av studien tyder på att det finns ett behov av alternativa databasmodeller inom BI-
området och med framtidens ökade datamängder kommer behovet med stor sannolikhet inte
minska. Därför är det av stor vikt att vidare studier utförs där det undersöks hur en
implementation av dessa databaser inom BI-företag skulle genomföras och vilka utmaningar
detta skulle generera.
34
Referenser Bonnet, L, Laurent, A, Sala, M, Laurent, B and Sicard, N 2011. Reduce, You Say: What NoSQL
Can Do for Data Aggregation and BI in Large Repositories In: 2011 22nd International
Workshop on Database and Expert Systems Applications. IEEE, pp.483–488.
Carroll, L. and Tenniel, J. 1899. Through the looking-glass and what Alice found there 63. Tsd..
London : Macmillan.
Chaudhuri, S., Dayal, U. and Narasayya, V. 2011. An overview of business intelligence
technology. Communications of the ACM. 54(8), pp.88–98.
Connolly, T.M. and Begg, C.E. 2015. Database systems : a practical approach to design,
implementation, and management 6. ed., global ed.. Harlow : Pearson Education
Limited.
Côrte-Real, N., Oliveira, T. and Ruivo, P. 2017. Assessing business value of Big Data Analytics
in European firms. Journal of Business Research. 70, pp.379–390.
Derfus, P., Maggitti, P., Grimm, C. and Smith, K. 2008. The red queen effect: competitive
actions and firm performance. Academy of Management journal. 51(1), pp.61–80.
Desmarets, Pascal. 2018-03-21. Non-Relational Databases Have Relationships Too. The Data
Administration Newsletter. https://tdan.com/non-relational-databases-have-
relationships-too/22965 (Hämtad 2020-04-22)
Enlyft. Enlyft 2020. 2020. https://enlyft.com/tech/database-management-system (Hämtad
2020-04-02)
Eriksson, L.T. and Hultman, J. 2014. Kritiskt tänkande : utan tvivel är man inte riktigt klok 2.
uppl.. Stockholm : Liber.
Fernando, Ashan. 2018-11-24. Why Adopting NoSQL is Difficult for Beginners. Hackernoon.
https://hackernoon.com/why-adopting-nosql-is-difficult-for-beginners-511659fb79d9
(Hämtad 2020-03-03)
Fowler, M. and Sadalage, P.J. 2013. NoSQL distilled : a brief guide to the emerging world of
polyglot persistence. Upper Saddle River, NJ: Upper Saddle River, NJ : Addison-Wesley.
Hartman, J. 2004. Vetenskapligt tänkande : från kunskapsteori till metodteori 2., [utök. och
kompletterade] uppl.. Lund : Studentlitteratur.
Hedin, Anna. 1996. Liten lathund om kvalitativ metod med tonvikt på intervju. HT 2011.
Uppsala Universitet. https://studentportalen.uu.se/uusp-filearea-
tool/download.action?nodeId=459535&toolAttachmentId=108197 (Hämtad 2020-04-
06)
Holst, Arne. 2020-03-02. Revenue from Big Data and business analytics worldwide from 2015
to 2022. Statista. https://www.statista.com/statistics/551501/worldwide-big-data-
business-analytics-revenue (Hämtad 2020-04-21)
IBM. 2020. What is business intelligence? IBM. https://www.ibm.com/topics/business-
intelligence (Hämtad 2020-04-17)
Japec, L. and Sverige. Statistiska centralbyrån 1997. Minska bortfallet. Stockholm: Stockholm :
Statistiska centralbyrån SCB.
Karavasilev, T., & Somova, E.. 2018. Overcoming the Security Issues of NoSQL Databases.
Technical University - Sofia, Plovdiv branch, Bulgaria.
35
Khine, P.P.P. and Wang, Z. 2019. A review of polyglot persistence in the big data world.
Information (Switzerland). 10(4).
Klein, J., Gorton, I., Ernst, N., Donohoe, P., Pham, K. and Matser, C. 2015. Performance
Evaluation of NoSQL Databases: A Case Study In: Proceedings of the 1st Workshop on
performance analysis of big data systems. ACM, pp.5–10.
Krenn, P.. 2018-02-04. NoSQL Means No Security? [online video]. FOSDEM.
https://www.youtube.com/watch?v=5zUmmE38SAU (Hämtad 2020-03-17)
Lynkova, Darina. 2019-09-02. 39+ Big Data Statistics for 2020. Leftronic.
https://leftronic.com: https://leftronic.com/big-data-statistics (Hämtad 2020-04-01)
Modak, Kali & Joshi, DR.. 2018. A Study On Stress Management In IT Sector With Special
Reference To Indore. Journal of Emerging Technologies and Innovative Research
(JETIR). Vol. 5, Issue 8, August 2018. pp.441-447
MongoDB, Inc. 2020. NoSQL Database Security. Mongodb.com.
https://www.mongodb.com/scale/nosql-database-security (Hämtad den 2020-03-18)
Negash, Solomon., Gray, Paul. 2008. Business Intelligence. I Frada Burstein och Clyde W.
Holsapple (red.). Handbook on Decision Support Systems 2. International Handbooks
Information System. Berlin : London. 175-193.
Okman, L., Gal-Oz, N., Gonen, Y., Gudes, E. and Abramov, J. 2011. Security Issues in NoSQL
Databases In: 2011IEEE 10th International Conference on Trust, Security and Privacy in
Computing and Communications. IEEE, pp.541–547.
Pereira, José Luís. and Costa, Marco.. 2019. From NoSQL databases to decision support
systems: Developing a business intelligence. International Journal for Quality Research.
13(4), pp.769–782.
Ptiček, M. and Vrdoljak, B. 2017. Big Data and New Data Warehousing Approaches In:
Proceedings of the 2017 International Conference on cloud and big data computing.
ACM, pp.6–10.
Sugam Sharma; Udoyara Sunday Tim; Shashi Gadia; Johnny Wong; Ritu Shandilya; Sateesh
K. Peddoju 2015. Classification and comparison of NoSQL big data models. Int. J. of Big
Data Intelligence. 2(3), pp.201–221.
Tiwana, A. 2014. Platform ecosystems : aligning architecture, governance, and strategy.
Waltham, MA : MK.
UCL. 2020-03-05. Evaluating resources: CRAAP Test. UCL Institute of Education.
https://libguides.ioe.ac.uk/evaluating/craap (Hämtad 2020-03-10)
Vetenskapsrådet. 2020. Forskningsetiska principer inom humanistisk-samhällsvetenskaplig
forskning. Stockholm: Vetenskapsrådet. http://www.codex.vr.se/texts/HSFR.pdf
(Hämtad 2020-03-02)
Yin, R.K. and Retzlaff, J. 2013. Kvalitativ forskning från start till mål 1. uppl.. Lund :
Studentlitteratur.
Yin, R.K. 2009. Case study research : design and methods 4. ed.. London : SAGE.
Tabeller Tabell 1 - Informanternas yrkesverksamma roll, längd på intervjun ...................................... 25
36
Figurer Figur 1 - Illustrerar vår avgränsning .......................................................................................... 6
Figur 2 - SQL-databaser ................................................ Fel! Bokmärket är inte definierat.
Figur 3 - Databasers skalbarhet ............................................................................................... 10
Figur 4 - CAP-teoremet ............................................................................................................. 11
Figur 5 - Polyglot Persistence ................................................................................................... 12
Figur 6 - SQL Injection ............................................................................................................. 13
Figur 7 - Nyckelvärdesbaserade databaser .............................................................................. 14
Figur 8 - Dokumentbaserade databaser....................................................................................15
Figur 9 - Kolumnbaserade databaser ....................................................................................... 16
Figur 10 - Grafbaserade databaser ........................................................................................... 16
Figur 11 - Big Data ......................................................... Fel! Bokmärket är inte definierat.
37
Bilaga 1: Sammanställning av Enkäten Totalt antal svar: 15/22
Juridiskt kön: Majoriteten av respondenter var män
Ålder: De flesta av respondenterna var mellan 21-29 år gamla.
Befattnings hos [Företaget]
38
FRÅGA: Känner du till NoSQL-databaser?
Av respondenterna var det precis hälften (50%) som kände till NoSQL-databaser sedan
tidigare.
Svar från de som ägde någon form av kunskap om NoSQL-databaser (8 st respondenter)
FRÅGA: Hur har du kommit över dina kunskaper om NoSQL-databaser?
Denna fråga hade respondenterna möjlighet att välja flera alternativ, och resultatet visar
att 37.5% hade läst en kurs på universitet/högskola och 37.5% hade kommit över
kunskapen genom eget intresse och initiativ. 25% hade en yrkesmässig bakgrund i ämnet
medan 12.5% hade läst diverse artiklar och dylikt på nätet.
FRÅGA: Hur skulle du uppskatta dina kunskaper om NoSQL-databaser, där 1 är
låg kunskapsnivå (nybörjare) och 5 är hög kunskapsnivå (expert)?
Denna fråga visade att kunskapsnivån om NoSQL-databaser hos respondenterna var
relativt låg, då de uppskattade sin kunskapsnivå ligga mellan 1-2 av 5.
39
FRÅGA: Vilka typer av NoSQL-databaser känner du till sedan förut?
Denna fråga blev något felformulerad, då svaren blandas mellan olika NoSQL-familjer
och NoSQL-databastyper:
Nyckelvärdesbaserade databaser: 2 svar Riak (1 svar)
Dokumentbaserade databaser: 5 svar
MongoDB (4 svar)
DynamoDB (1 svar)
MariaDB (1 svar)
Kolumnbaserade databaser: 3 svar (Cassandra)
Grafbaserade databaser: 1 svar
FRÅGA: Tror du att en implementering av NoSQL-databaser skulle vara
värdefullt för [Företaget] och dess datahantering?
FRÅGA: Om Ja: varför?
“Viss typ av data som är utan direkta relationer skulle kunna hanteras snabbare i NoSQL.”
“Det beror på. I lösningar där vi har enorma datamängder tror jag att det nog skulle
fungera.”
“Det är mycket relationer i våra tabeller och om jag förstått noSql så är det bra då man har
stora datamängder med få relationer.”
FRÅGA: Om Nej: Varför inte?
“[Företaget]s system är för små för att motivera utvecklingskostnaden. Ett mer
decentraliserat system medför även vissa säkerhetsrisker, risker som troligtvis är
alldeles för stora relativa till fördelarna med NoSQL. Då [Företaget]s kunder
innefattar t.ex. tullverker och åklagarmyndigheten så läggs väldigt stor vikt på att
känslig information i systemet är väl skyddad. NoSQL är kort och gott för osäkert.”
“Vet inte om allt skulle lira trots det positiva med Big Data hanteringen.”
Frågor om Relationella databaser (SQL) och BI
Samtliga respondenter kände till relationella databaser (SQL).
40
FRÅGA: Har du under din tid hos [Företaget] någon gång stött på ett tillfälle där
ni inte har kunnat bemöta en kunds önskemål på grund av begränsningar
hos SQL-databaser?
FRÅGA: Om du svarat Ja på den föregående fråga, ber vi dig att kort beskriva kort
det tillfället du tänker på.
“Ruttoptimering”
“En brist som finns med SQL-databaser kan vara prestanda. I det här fallet så har det att
göra med en tabell som innehåller 100miljoner + rader. Är jag intresserad av specifik
data t.ex. data mellan ett visst datum intervall så kan queryplanen välja en tokig väg
för att läsa ut det. Den kan exempelvis vilja läsa igenom hela tabellen för att ta ut det
efterfrågade data. Här är det indexering som blir oerhört viktigt i SQL-databaser.
Beroende på vilken fråga man väljer att ställa för att läsa ut data är det inte
nödvändigtvis att man kan bygga ett index som är optimalt.”
FRÅGA: Vilka trender tror du kommer vara de främsta inom Business
Intelligence-området de närmsta åren? (Välj två alternativ)