Tietokantoja hallitaan aina tietokantajärjestelmien (Database Management System, DBMS) avulla. Sandvikin tapauksessa kyse on Lean-nimisestä ERP-relaatiotietokannasta, jota hallitaan erittäin yleisellä Oracle-järjestelmällä (Solid IT, 2020). Leanin relaatiotietokannan taulusta on esi-merkki kuvassa 1. Lisäksi tässä tutkimuksessa tullaan tarvitsemaan Kardex-varastoautomaattien tietokantaa, joka on myös relaatiotietokanta. Kardex toimii Power Pick Global nimisen järjestel-män pohjalta (Sandvik Mining and Construction Oy, 2020), minkä kautta on myös mahdollista päästä käsiksi Kardexin relaatiotietokantaan. Relaatiotietokanta itsessään on toteutettu Microsof-tin SQL Server - tietokantajärjestelmälle.
2.1.2 Muita tietokantatyyppejä
Relaatiotietokantojen lisäksi on olemassa useita muitakin tietokantatyyppejä. Relaatiotietokannat ovat tämän tutkimuksen kannalta tärkeässä roolissa, mutta on hyvä ymmärtää, että tietokantoja voidaan hallita myös monilla muilla tavoilla. Käsittelemme seuraavaksi esimerkkeinä avain - arvo, dokumentti-, ja verkkotietokantoja. Nämä ovat kaikki ns. NoSQL-tietokantoja.
Avain-arvotietokannat tarjoavat erittäin rajoitetun tietomallin. Kantaan talletetaan arvoja sekä ar-von yksilöiviä avaimia. Tietokannan suhteen talletettavilla arvoilla ei ole (yleensä) mitään skee-maa eli rakennetta. Sovellusten on tulkittava kantaan talletettavat arvot haluamallaan tavalla esim. tietyn tyyppisenä oliona. Koska tietokanta on täysin skeematon, eivät avain-arvotietokannat tue viitteitä kantaan talletettujen arvojen välillä, eli mitään relaatiotietokantojen liitosta vastaavaa käsitettä ei avain-arvotietokannoilla ole. Avain-arvotietokantojen tarjoamat kyselymahdollisuudet ovat erittäin rajoittuneet, yleensä on ainoastaan mahdollista hakea kannasta tiettyä avainta vas-taava arvo. (Helsingin Yliopisto, 2018)
Mitä järkeä avain-arvotietokannoissa on? Ne vaikuttavat ominaisuuksiltaan erittäin rajoittuneilta ja relaatiotietokannoilla pystyy tekemään varmasti kaikki ne asiat, joihin avain-arvotietokannat pystyvät. Rajoituksistaan johtuen avain-arvotietokannat ovat kuitenkin suorituskyvyltään ja skaa-lautuvuudeltaan huomattavasti parempia kuin relaatiotietokanta, ja niiden avulla pystytään kui-tenkin ratkaisemaan monia sovellusten käyttötarpeita. (Helsingin Yliopisto, 2018)
Eräs hyvin yleinen käyttötarkoitus avain-arvotietokannoille on raskaiden operaatioiden tulosten väliaikainen talletus (engl. caching) mahdollisia uusia saman operaatioiden suorituksia varten (Helsingin Yliopisto, 2018). Esimerkiksi sääpalvelut voidaan toteuttaa avain-arvotietokantaan, koska käyttäjien määrä on todella suuri ja tiedot pysyvät tietokannassa suunnilleen samoina esi-merkiksi kahden päivän ajan.
Dokumentti-tietokantojen voi ajatella sijoittuvan jonnekin relaatiotietokantojen ja avain-arvotieto-kantojen puolen välin tienoille. Dokumenttikannat perustuvat avain-arvotietoavain-arvotieto-kantojen tapaan ar-vojen tallettamiseen avaimen perusteella. Arvot tai dokumentit kuten niitä dokumenttikantojen kontekstissa nimitetään voivat kuitenkin olla itsessään hyvin monimutkaisia oliota, jotka sisältävät kenttiä, joiden arvona voi olla joko normaaleja arvoja kuten lukuja ja merkkijonoja tai muita olioita.
Toisin kuin avain-arvotietokannoissa, dokumenttikannat "näkevät" tietokantaan talletettujen do-kumenttien sisään, ja mahdollistavat talletettujen dodo-kumenttien sisällön suhteen tehdyt kyselyt.
(Helsingin Yliopisto, 2018)
Dokumentti-tietokannassa dokumentit on lajiteltu kokoelmiin (engl. collection). Kokoelman merki-tys on suunnilleen sama kuin taulun relaatiotietokannassa. Yhdessä kokoelmassa olevien doku-menttien ei kuitenkaan tarvitse olla kentiltään samanlaisia. Kenttiä voi olla vaihteleva määrä ja saman nimiset kentät voivat sisältää eri dokumenteilla erityyppisen arvon. Kokoelmille ei määri-tellä dokumenttikannoissa minkäänlaista skeemaa, eli on täysin sovellusten vastuulla, että kan-taan talletekan-taan järkevää dataa, ja että kannasta luettava data tutkikan-taan oikein. Toisin kuin re-laatiotietokantojen tapauksessa, dokumenttikannat eivät tarjoa tietokannan tasolla tapahtuvia lii-tosoperaatiota. (Helsingin Yliopisto, 2018)
Relaatiotietokannat ja esittelemämme NoSQL-kantatyypit keskittyvät ns. dataentiteettien esittä-miseen. Relaatiotietokannat esittävät entiteetit taulujen riveinä, esim. Henkilö-taulussa jokainen ihminen esitettään omana rivinään. Yhteydet ja suhteet eri entiteettien välillä esitetään epäsuo-rasti vierasavaimien ja liitostaulujen avulla. Itse yhteys, esim. ”missä henkilö Arto on töissä” saa-daan selville vasta kyselyn aikana tapahtuvan liitosoperaation avulla. Joissain tilanteissa entiteet-tien suhteiden selvittäminen relaatiotietokannassa saattaa olla erittäin hankalaa. (Helsingin Yliopisto, 2018)
Ratkaisun ongelmaan tuovat verkkotietokannat, jotka mallintavat eksplisiittisesti sekä entiteetit eli esim. henkilöt ja niiden ominaisuudet, että entiteettien väliset suhteet kuten sukulaisuuden hen-kilöiden välillä. Kuten nimestä voi päätellä, on verkkotietokannan pohjalla olevana tietorakenteena verkko (engl. graph), joka koostuu entiteettejä kuvaavista solmuista (engl. node) ja niiden välisiä suhteita kuvaavista kaarista (engl. edge). Sekä solmuilla, että kaarilla voi olla attribuutteja.
(Helsingin Yliopisto, 2018)
Verkkotietokannat tarjoavat kyselykielen, jonka avulla on helppo "navigoida" verkossa. Toisin kuin relaatiotietokannoissa, jotka edellyttävät yhteyden muodostamiseen laskennallisesti kallista joi-noperaatiota, yhteyksien navigointi verkkotietokannassa on nopeaa. Verkkotietokannoille ei ole olemassa yhtä vakiintunutta kyselykieltä. On kuitenkin tiettyjä kyselykieliä, kuten tämän hetken suosituimman verkkotietokannan Neo4J:n käyttämä Cypher, joita jotkut muutkin verkkotietokan-nat tukevat. (Helsingin Yliopisto, 2018)
2.2 Business Intelligence Sandvikilla
Kuten muissakin tieteenaloissa, termejä malli ja mallintaminen käytetään usein myös liiketoimin-taan liittyvässä tietomallinnuksessa (Business Intelligence, BI). Business intelligencen päätavoit-teena on tarjota tukea yrityksen päätöksenteolle ja tavoitteille läpi organisaation. Tietoja voidaan mallintaa usealla eri tavalla, esimerkiksi prosessi-, organisaatio-, regressio-, luokitus-, graafiikka- ja ohjelmistomalleilla. Kaikkien mallintamistekniikoiden tarkoituksena on empiiristen asioiden ja ilmiöiden selittäminen loogisella ja objektiivisella tavalla, jotta tietojen avulla voidaan siirtyä suo-raan käytännön toimiin (Springer, 2015). Business intelligence sisältää tietojen hankintaa, tallen-nusta sekä analysointia. Termi itsessään on hyvin laaja ja siksi sen määrittely on myös haastavaa.
Business intelligence toimii niin sanotun ”ETL-prosessin” (kuva 2) pohjalta, mikä tarkoittaa datan siirtämistä, muokkaamista ja lataamista: tiedot haetaan (Extract) lähdejärjestelmästä, niitä muo-kataan (Transform) ja ladataan (Load) lopulta tietovarastoon. Latausprosessissa tiedot muunne-taan tietovaraston rakenteen muotoon ja integroiden samalla eri lähtöjärjestelmien tietoja. Pro-sessi sisältää yleensä myös tietojen historioinnin. Tyypillinen ETL-proPro-sessi voisi esimerkiksi kä-sittää asiakastietojen integroimisen asiakassovelluksesta yrityksen keskitettyyn tietovarastoon (Hovi, 2018).
Tietovarasto (data warehouse, DW) on erillinen tietokanta, johon eri järjestelmissä hajallaan oleva data poimitaan ja ladataan raportointia, analytiikkaa ja muuta käyttöä varten. Idea on yhdistellä datat ja tuoda ne helposti saataville ja kyseltäviksi. Tietovarastojen suunnittelussa käytetään nii-hin tarkoitettuja erillisiä menetelmiä, esimerkiksi tähtimalli ja Data Vault. Tietovarastossa tiedot ovat tyypillisesti ajan tasalla esimerkiksi päivätasolla tai jopa reaaliaikaisena. Tietovaraston avulla voidaan hoitaa myös tietojen historiointi. (Hovi, 2018)