Niko-Petteri Alanko
DATAN LAADUN VARMISTAMINEN TIETOVARASTOPROJEKTIN ERI VAIHEISSA
Informaatioteknologian ja viestinnän tiedekunta Kandidaattitutkielma Tammikuu 2021
TIIVISTELMÄ
Niko-Petteri Alanko: Datan laadun varmistaminen tietovarastoprojektin eri vaiheissa Kandidaattitutkielma
Tampereen yliopisto
Tietojenkäsittelytieteiden tutkinto-ohjelma Tammikuu 2021
Tämä työ käsittelee datan laatua tietovarastoprojektin eri vaiheissa. Työn tarkoituksena on tarkastella tietovarastoprojektin vaiheita datan laadun näkökulmasta ja vastata kysymykseen: mitä keinoja on olemassa datan laadun varmistamiseen tietovarastoprojektin eri vaiheissa. Työ pyrkii esittelemään mitä datan laatu on ja miten huonolaatuista dataa voidaan välttää.
Tietovarastoprojektissa on useita vaiheita. Näissä vaiheissa voidaan tehdä toimenpiteitä datan laadun varmistamiseen joko konkreettisin ohjelmoinnillisin keinoin tai parantamalla prosessimalleja huomioimalla datan laatu kussakin vaiheessa. Huonolaatuinen data on kallista ja useimmiten tahtotila dataa hyödyntävissä organisaatioissa onkin saavuttaa datan laadussa vähintään käyttötarkoitusta tyydyttävä taso, jotta voidaan välttyä ylimääräiseltä työltä ja kustannuksilta.
Eri vaiheiden datan laadun varmistamisen keinot ovat hyvin paljon sidoksissa kuhunkin vaiheeseen. Tietovaraston vaatimusmäärittelyssä pääpaino on prosessien mallintamisella ja parantamisella kun taas esimerkiksi latausvaiheessa lähestytään asiaa enemmän teknisestä näkökulmasta. Suunnittelussa ja määrittelyssä tekninen ajattelu ei ole niin hallitsevassa asemassa.
Tarkasteltujen tutkimusten perusteella voidaan todeta, että datan laatuun vaikuttaa moni muukin asia kuin data itse. Datan laadun määreet, jotka riippuvat paljolti vuorovaikutuksesta ihmisen kanssa, ovat yllättävänkin tärkeässä roolissa datan laatua määriteltäessä ja keinot näiden määreiden täyttämiseen ovat pitkälti prosessimalleissa. Toisaalta myös datassa itsessään olevat ominaisuudet määrittelevät datan laatua, eikä niitä sovi unohtaa, vaikka niiden tekninen huomioiminen onkin helpompi mallintaa.
Kirjallisuudessa keinoja datan laadun varmistamiseen on olemassa, mutta erilaisia keinoja datan laadun varmistamiseen on kovin vähän. Eritoten latausvaiheen keinojen vähyys on harmillista, koska tässä vaiheessa tehdään suurin työ tietovarastoprojekteissa.
Työ on tehty kirjallisuuskatsauksena tämän hetkiseen kirjallisuuteen. Tarkoituksena on esitellä lukijalle mahdollisuuksia datan laadun varmistamiseen tietovarastoprojektin eri vaiheissa.
Avainsanat: Tietovarasto, Datan laatu, ETL, ELT, Business intelligence,
Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck –ohjelmalla.
Sisällysluettelo
1 Johdanto ... 1
2 Käsitteistö ... 2
2.1 Datan laatu 2
2.2 Datan integrointi 3
2.3 Tietovarasto 5
2.4 Business intelligence 6
3 Keinoja datan laadun varmistamiseen ... 7
3.1 Tietovaraston vaatimusmäärittely 7
3.2 Tietovarastoarkkitehtuuri datan laadun näkökulmasta 8
3.3 Lähdejärjestelmän datan laatu tietovarastossa 10
3.4 Tiedon lataaminen tietovarastoon 11
3.5 Huonolaatuisen datan huomiointi raportoinnissa 13
4 Keskustelu ... 15 5 Yhteenveto ... 16 LÄHDELUETTELO ... 17
1 Johdanto
Modernissa maailmassa yritykset käyttävät tietoa ja informaatiota jatkuvasti lisääntyvissä määrin liiketoiminnan apuna ja mahdollisesti myöskin tuotteena. Tästä syystä on tärkeää tarkastella datan laatua ja tehdä toimenpiteitä varmistuakseen, että käytetty data on laadukasta. On arvioitu, että huonolaatuinen data maksaa 600 miljardia dollaria yhdysvaltalaisille yrityksille kollektiivisesti vuosittain (Fan, 2015). Huonolaatuinen data on siis merkittävän kallista.
Nykypäivänä varsinkin isommissa yrityksissä käytetään tietovarastoratkaisuja ison tietomäärän hallinnassa ja sen jalostamisessa päätöksenteon apuvälineeksi. Tietovarastoa käytetään myös analytiikkamoottorina, jonka avulla rakennetaan erilaisia raportteja ja ennusteita yrityksen liiketoiminnoista.
Tämän tutkielman tavoitteena on vastata kysymykseen: minkälaisia keinoja tiede tietää datan laadun varmistamisesta tietovarastoprojekteissa.
On monenlaisia tapoja säilyttää ja analysoida dataa. Tässä työssä keskitytään tietovarastokokonaisuuksiin ja katsotaan minkälaisia keinoja on olemassa datan laadun varmistamiseen tietovarastoprojektin eri vaiheissa. Työssä tutustutaan tietovarastoprojektin vaiheisiin yleisesti ja esitellään mahdollisuuksia datan laadun varmistamiseen kussakin vaiheessa. Tutustuttaessa tietovarastoprojektiin kokonaisuutena, voidaan tunnistaa tämän tutkielman hyödyt. Se, että tietovarastoprojektissa huomioidaan datan laatu osana jokaista työvaihetta saadaan varmasti suurin hyöty myös erilaisista keinoista irti. Työssä edetään kronologisessa järjestyksessä tietovarastoprojektissa, eli ajatellaan datan kulkua. Työ etenee seuraavasti:
luvussa 2 esitellään työn kannalta oleellisimpia käsitteitä, luvussa 3.1 aloitetaan tietovaraston vaatimusmäärittelystä, luvussa 3.2 tarkastellaan tietovarastoarkkitehtuurien eroja datan laadun näkökulmasta, luvussa 3.3 tutustutaan lähdejärjestelmien merkitykseen tietovarastossa, luvussa 3.4 tutkitaan tiedon lataamisvaiheen mahdollisuuksia ja luvussa 3.5 katsotaan datan laadun vaikutusta raportoinnissa. Luvussa 4 pohditaan työn tuloksia ja luvussa 5 on yhteenveto.
Työ on tehty kirjallisuuskatsauksen keinoin hakemalla lähteitä pääosin ACM:n ja IEEE:n tietokannoista. Pääsääntöisesti lähteitä on etsitty seuraavilla avainsanoilla:
”data quality” AND ”ETL”
”data quality” AND ”data warehouse”
“data quality” AND “business intelligence”
“data warehouse” AND “business intelligence”
Lähteitä on valittu valitsemalla tutkimuksia avainsanojen ja otsikoiden perusteella.
Tämän jälkeen on tarkasteltu tiivistelmiä ja valittu jatkoon ne tutkimukset, joissa käsitellään datan laatua osana kyseisiä tutkimuksia. Viimeinen seulonta on tehty lukemalla töitä. Joitakin käsitteitä paremmin avaavia lähteitä on haettu muilla termeillä ja vähemmän tieteellisiä lähteitä on haettu Googlen haulla.
2 Käsitteistö
Tässä luvussa avataan työn kannalta tärkeimpiä käsitteitä laajemmin. Käsitteiden avaaminen on merkityksellistä työn ymmärrettävyyden vuoksi, koska monet käsitteet ovat hyvin teknisiä ja sisältävät isoja kokonaisuuksia.
2.1 Datan laatu
Datan laatu on määritelty suhteeksi, jolla datan ominaisuudet täyttävät tiettyjä määreitä (ISO/IEC 25012, 2020). Viisi näistä tietyistä määreistä on järjestelmäriippumattomia, eli ominaisuudet ovat datassa itsessään eivätkä riipu käyttötarkoituksesta tai -järjestelmästä (Auer & Felderer, 2019). Nämä määreet ovat:
Tarkkuus, virheettömyys (Accuracy): ISO/IEC 25012 standardin mukaan tämä kuvaa astetta, jolla tietoalkiot kuvaavat todellista arvoa syntaktisesti ja semanttisesti (Auer & Felderer, 2019). Tämä tarkoittaa esimerkiksi sitä, että datatyypit kuvaavat tarkasti kenttään tallennettua tietoa. Voidaan määritellä päivämääräkenttä käyttäen merkkijono-datatyyppiä, mutta todellisuutta kuvaa paremmin päivämäärä-datatyyppi.
Täydellisyys (Completeness): ISO/IEC 25012 standardin mukaan tämä kuvaa astetta, jolla tietoalkioissa on arvoja (Auer & Felderer, 2019). Tämä tarkoittaa esimerkiksi sitä, että tyhjäarvoja ei voi olla sellaisissa kentissä, joihin niitä ei ole erikseen määritelty hyväksyttävän.
Johdonmukaisuus (Consistency): ISO/IEC 25012 standardin mukaan tämä kuvaa astetta, jolla tietoalkioissa ei ole ristiriitaisuuksia ja ne ovat ymmärrettäviä (Auer & Felderer, 2019). Tämä voi tarkoittaa esimerkiksi sitä, että päivämääräkentät sisältävät odotetun kaltaisia päivämääriä. Jos on odotettavaa päivämääräkentässä A olevan päivämäärä X, niin päivämääräkentässä B tulee olla päivämäärä > X.
Uskottavuus (Credibility): ISO/IEC 25012 standardin mukaan tämä kuvaa astetta, jolla tietoalkion arvot ovat uskottavia (Auer & Felderer, 2019).
Esimerkiksi summakentässä on oltava uskottava summa, eikä summa ole tavattoman suuri ilman, että se on uskottava.
Ajankohtaisuus (Currentness): ISO/IEC 25012 standardin mukaan tämä kuvaa astetta, jolla tietoalkion arvot ovat ajan tasalla (Auer & Felderer, 2019).
Tämä tarkoittaa sitä, että kentät päivitetään vastaamaan mahdollisia muuttuneita arvoja niin, että ne ovat tarkasteltaessa ajan tasalla. Päivitysväli saattaa riippua käyttötarkoituksesta.
Näiden lisäksi ISO/IEC 25012 standardissa määritellään useita muita datan laadun määreitä. Muut määreet ovat järjestelmäriippuvaisia. Standardin mukaan järjestelmäriippuvaisuus tarkoittaa sitä, että määreet ovat vahvasti kytköksissä käytettäviin järjestelmiin tai datan käyttöön, eikä näitä voida mitata datasta itsestään kuten järjestelmäriippumattomia määreitä. Järjestelmäriippuvaisten datan laadun määreiden mittaaminen vaatii osaamista käyttökontekstista ja joitain näistä ei voi mitata merkityksekkäästi ilman vuorovaikutusta ihmisen kanssa (Auer & Felderer, 2019).
2.2 Datan integrointi
Datan integrointi on prosessi, jossa dataa tuodaan yleensä monista lähteistä osaksi yhtenäistä tietojoukkoa operatiivista- ja analyyttista käyttöä varten. Datan integrointi on yksi datan hallinnan pääelementeistä. (Rouse, 2021)
Tyypillisesti dataa integroidaan joko ETL (Extract, transform, load) tai ELT (Extract, load, transform) pohjaisesti. Hallitseva datan integroinnin metodi on ETL, jota käytetään tietovarastotoiminnassa. Toisaalta, vaihtoehtoista ELT (Extract, load, transform) metodia käytetään usein big data -järjestelmissä. (Rouse, 2021)
ETL tarkoittaa yksinkertaisuudessaan datan siirtämistä, muokkaamista ja lataamista. ETL:ssä yhdistetään kolme vaihetta osaksi yhtä työkalua, jolla noudetaan dataa tietokannasta tai muusta lähteestä ja ladataan noudettu tieto toiseen tietokantaan (Adnan et al., 2017). Lähdejärjestelmä ja tietovarasto eivät välttämättä ole suoraan yhteensopivia keskenään, usein eri tietokannoissa on erilaisia määrittelyjä eri datatyypeille. Tietoa ladataan usein monista eri lähteistä ja kaikista lähteistä ladattu tieto on saatava sopimaan tietovaraston määrittelyihin (Vassiliadis et al., 2002).
Kuvassa 1 on esitetty tavanomainen ETL-prosessin eteneminen yksinkertaistetusti.
Kuvasta selviää, että tieto ladataan tietovarastoon vasta prosessin lopussa ja käsittely tehdään yleensä tietovaraston ulkopuolella.
Kuva 1. Havainnollinen kuva ETL-prosessista (mukaillen Vassiliadis et al., 2002)
ELT on tarkoitukseltaan samankaltainen kuin ETL, mutta toteutus siihen, miten ja missä dataa muutetaan on erilainen. Kun ETL-työssä data muutetaan ennen lataamista tietovarastoon, ELT-työssä data ladataan ensin raakana tietovarastoon ja käytetään tietovaraston tietokantaa muuttamaan tieto haluttuun datatyyppiin (Dayal et al., 2009).
Esimerkkinä voi toimia aikaleima. Kun tietokannasta ladataan aikaleiman sisältämä kenttä, ladataan se sellaisenaan merkkijonona tietovarastoon. Tämän jälkeen tietovaraston tietokantamoottoria käytetään muuttamaan merkkijono sopimaan aikaleima-datatyyppiin.
Kuvassa 2 on esitettynä ELT-prosessia yksinkertaistetusti. Erona ETL-prosessiin on siis se, että data ladataan tietovarastoon ennen muokkaamista. Tieto ladataan tietovaraston sisään erikseen määrätylle alueelle, jossa dataa muokataan. Tämän jälkeen tieto siirretään tietovaraston tietokannan sisäisesti lopulliseen säilöön.
Kuva 2. Havainnollinen kuva ELT-prosessista (mukaillen Dayal et al., 2009)
2.3 Tietovarasto
Tietovarasto eli data warehouse (tai DW). Tietovarasto on iso tietokanta, jonne tallennetaan massiivinen määrä tietoa. Sitä on tarkoitus säilyttää tietovarastossa pidempään kuin mahdollisissa tuotantojärjestelmien tietokannoissa. Erona tavallisiin tietokantoihin on se, että DW-tietokanta on optimoitu isoihin laskentatöihin ja analyyttisien mallien rakentamiseen (Munawar et al., 2011). Tietovarasto nähdään usein tärkeänä osana BI (Business intelligence) kokonaisuutta (Dedic. & Stanier., 2016).
Parhaassa tapauksessa tietovarastosta saadaan rakennettua automatisoituja raportointimalleja käyttäen BI-työkaluja, joilla voidaan vähentää raportointiin käytettävää manuaalisen työn määrää ja vähentää myös manuaalisessa työssä aiheutuvia virheitä raportoinnissa (Bagambiki, 2018).
Kuvassa 3 on esitetty tavallisimpiin lukeutuva kaksikerroksinen tietovarasto, jossa data ladataan lähdejärjestelmistä ETL-työkaluilla tietovarastoon. Tietovarastoon rakennetaan erilaisia tietopankkeja (Data mart). Näistä otetaan tietoa hyötykäyttöön erilaisilla työkaluilla, jotka ovat tavallisimmin analytiikka- ja BI-työkaluja.
Kuva 3. Kaksikerroksisen tietovaraston rakenne (Golfarelli & Rizzi, 2009, viitattu Blažić et al., 2017).
Blažić ja muut (2017) esittävät työssään useita tietovarastoarkkitehtuureja.
Tietovarasto voidaan rakentaa monella eri tavalla, mutta pääkomponenttina tietovarastoarkkitehtuureissa on suurimmassa osassa tapauksia yksi tietovarastotoimintaan erikoistunut tietokantamoottori.
2.4 Business intelligence
BI pitää sisällään teknologiaa ja strategioita, joilla liiketoiminnan dataa analysoidaan. BI- työkalut voivat pitää sisällään muun muassa tiedon louhinnan (data mining) välineitä, erilaisia raportointityökaluja, tiedon visualisointimahdollisuuksia ja erilaisia laskentamoottoreita suurien datamassojen laskentaan (de Carvalho et al., 2016).
Lisääntyvä kiinnostus BI:tä kohtaan ainoastaan lisää tarvetta tietovarastoille, BI- työkaluille ja laadukkaalle datalle. Kuvassa 4 on esitelty hakumääriä aiheesta business intelligence. Kiinnostus aihetta kohtaan on nousevassa trendissä.
¨
Kuva 4. Hakumäärät aiheesta Business intelligence (Google Trends, 2021).
3 Keinoja datan laadun varmistamiseen
Datan laatu vaikuttaa moneen asiaan. Esimerkiksi avaruussukkula Challengerin räjähtäminen (Zellal & Zaouia, 2015). Huonolaatuinen data aiheuttaa vääriin liiketoimintapäätöksiin ja yritysten tehokkuuteen (Zellal & Zaouia, 2015). Datan laatuun vaikuttaa myös moni asia. Tietovarastoprojektin jokaisessa vaiheessa on mahdollisuus tehdä vääriä päätöksiä datan laadun kannalta. Tästä syystä toimivien keinojen löytäminen on elintärkeää kasvavan BI-trendin tueksi.
Tässä luvussa tarkastellaan yksityiskohtaisemmin tietovaraston eri vaiheisiin liittyviä mahdollisuuksia datan laadun varmistamiseen. Luvussa edetään kronologisessa järjestyksessä, seuraten datan matkaa lähdejärjestelmästä tietovarastoon ja lopulta raportointiin.
3.1 Tietovaraston vaatimusmäärittely
Tietovarasto-projekti alkaa tavallisimmin suunnittelusta. Käyttötarve on kartoitettava ja on suunniteltava toimiva ratkaisu nimenomaiseen käyttötapaukseen. Kumar ja muut (2011) kertovat työssään, että projektin vaatimusten laadulla saattaa olla vaikutusta
tietovaraston mallin laatuun. Tästä syystä vaatimusmäärittely on tehtävä niin, että laatu huomioidaan vaatimuksissa.
Kumar ja muut (2011) ehdottavat työssään ratkaisuksi vaatimusmäärittelyyn laatuorientoitunutta vaatimusmallia tietovarastolle (quality oriented requirements model for DW). Heidän esittämänsä laatuorientoitunut vaatimusmalli on laajennos AGDI- mallista (Agent-Goal-Decision-Information), joka puolestaan on laajennos GDI-mallista (Goal-Decision-Information). GDI- ja AGDI-mallit ovat luotu tietovaraston vaatimusmäärittelyyn. AGDI-mallissa kuvataan vaatimuksia tietovarastossa organisaation, päätöksenteon ja tiedon kuvaamisen kautta, mutta malli ei ota huomioon laadullisia rajoitteita (Kumar et al., 2011).
GDI-mallissa määritellään ensin organisaation tavoite päätöksentekijöiden avustuksella ja oletetaan, että ainoastaan päätöksentekijät kuuluvat tietovaraston ja käyttötapauksien sidosryhmään (Kumar et al., 2011). AGDI-malli laajentaa GDI-mallia tuomalla mukaan myös niin kutsutun agentin (Kumar et al., 2011). Agentin tarkoituksena on kuvata kokonaisuutta ja sidosryhmiä tarkemmin. Mallilla voidaan ottaa huomioon myös sidosryhmien riippuvuudet muista organisaatioon kuuluvista elimistä tai henkilöistä. Työssään Kumar ja muut (2011) jatkavat AGDI-mallia entisestään tuomalla mukaan laadullisia rajoitteita osaksi agenttien päätöksentekoa. Agentin tarkoituksena organisaatiossa on saavuttaa tietty tavoite. Agentilla saattaa esimerkiksi olla tavoite lisätä myyntiä 50%. AGDI:n laadullisen laajennoksen avulla voidaan tuoda tähän tavoitteeseen laadullisia rajoitteita, esimerkiksi budjetti- tai aikarajoitteita, jonka jälkeen voidaan arvioida vielä tarkemmin päätöksentekoa.
Käytännössä ylläesitelty vaatimusmäärittelyn malli tietovarastolle tuo mukaan tiettyjä laaturajoitteita päätöksenteon tueksi. Kun nämä osataan huomioida tietovarastoprojektissa mallin avulla, osataan myös tarkastella tietovaraston rakentamista uudesta näkökulmasta ja saada uusia näkökulmia esimerkiksi tietovarastoon tarvittavaan dataan.
Kumarin ja muiden (2011) esittelemä malli parantaa järjestelmäriippuvaisten datan laadun määreiden täyttämistä. Esimerkiksi budjettirajoitteet ovat liiketoiminnan rajoituksia, eikä näitä voida sanoa olevan datassa itsessään.
3.2 Tietovarastoarkkitehtuuri datan laadun näkökulmasta
Tietovarasto voidaan rakentaa monella eri tavalla. Ei ole olemassa yhtä ainoaa tapaa tehdä tietovarasto oikein, sillä kaikissa arkkitehtuureissa on hyvät ja huonot puolensa. Ennen
tietovaraston rakentamista on hyvä tarkastella kriteerejä, joita tietovaraston tulee täyttää ja valita sillä perusteella käyttötarkoitukseen oikea arkkitehtuuri (Blažić et al., 2017).
Blažić ja muut (2017) työssään esittelevät ja vertailevat tunnetuimpia ja käytetyimpiä tietovarastoarkkitehtuureja.
Arvioitaessa tiedon- ja järjestelmän laatua Bus-, Hub-And-Spoke- ja keskitetty teitovarastoarkkitehtuuri ovat suoriutuneet arvioinneista parhaimmin tuloksin (Blažić et al., 2017). Kuvassa 5 on esitelty graafisesti tietovarastoarkkitehtuurien pisteytyksen eroja.
Kuva 5. Tietovarastoarkkitehtuurien eroja (Blažić et al., 2017).
Bus-arkkitehtuuri muistuttaa Blažićin ja muiden (2017) mukaan itsenäistä tietopankkiarkkitehtuuria. Itsenäisessä tietopankkiarkkitehtuurissa tietopankit ovat itsenäisiä, ne on suunniteltu ja implementoitu erillään toisistaan, eli toisinsanoen ne eivät ole keskenään integroituja (Blažić et al., 2017). Tietopankeissa voi olla toisistaan poikkeavia dimensioiden ja laskennan määrittelyjä, mikä tekee analyysien tekemisestä hankalaa (Blažić et al., 2017). Bus-arkkitehtuuri tekee eron itsenäisten tietopankkien arkkitehtuuriin integroinnissa. Blažićin ja muiden (2017) mukaan tietopankit (bus- arkkitehtuurissa) ovat integroituja yhteen tietokantaan ja saatavilla on koko yritystä kuvaava näkymä tiedosta.
Hub-and-spoke -arkkitehtuuri koostuu lähdejärjestelmistä, täsmäytetystä datasta ja tietopankeista (Blažić et al., 2017). Hub (tai keskiö) on yrityksen tietovarasto, josta eriytetään tietopankkeja (spoke eli pinna) (Blažić et al., 2017). Atominen, normalisoitu data säilytetään täsmäytyskerroksessa, joka syöttää tietoa tietopankeille summatussa ja
monidimensionaalisessa muodossa (Blažić et al., 2017). Tämä tarkoittaa esimerkiksi sitä, että data on sellaisessa muodossa, jossa sitä voidaan laskea ja tarkastella useasta eri näkökulmasta, esimerkiksi usean eri päivämäärän kautta. Hub-and-spoke - arkkitehtuurissa keskeisenä asiana on skaalautuminen ja suurten tietomassojen hakeminen (Blažić et al., 2017).
Keskitetty tietovarastoarkkitehtuuri voidaan nähdä eräänlaisena hub-and-spoke - arkkitehtuurin toteutuksena (Blažić et al., 2017). Blažićin ja muiden (2017) mukaan erona keskitetyssä tietovarastoarkkitehtuurissa hub-and-spoke -arkkitehtuuriin nähden on se, että keskitetyssä tietovarastoarkkitehtuurissa ei rakenneta erillisiä, mutta toisistaan riippuaisia tietopankkeja. Blažićin ja muiden (2017) mukaan koko toteutus on yksi iso tietovarasto, joka sisältää kaiken datan ja jonne on sisäänrakennettu tietopankkeja.
Blažić ja muut (2017) uskovat bus-, hub-and-spoke ja keskitetty tietovarasto arkkitehtuuri ovat saaneet parhaat tulokset tiedon ja järjestelmän laadussa siksi, koska ajan kuluessa arkkitehtuurit ovat kehittyneet hyvin samankaltaisiksi. He myös toteavat odottavansa arkkitehtuurien jatkavan kehittymistä samaan suuntaan ja erot erilaisten arkkitehtuurien välillä tulevat pienenemään. Heidän mukaansa tämä johtaa siihen, että eri arkkitehtuurit pystyvät tulevaisuudessa täyttämään paremmin niille asetetut tavoitteet.
Datan laadun näkökulmasta tietovarastoarkkitehtuureilla pyritään vastaamaan pääsääntöisesti järjestelmäriippumattomiin datan laadun määreisiin ja toissijaisesti järjestelmäriippuvaisiin datan laadun määreisiin. Tietovaraston tekninen toteutus saattaa esimerkiksi rikkoa johdonmukaisuuden määrettä, jos tietoa ei täsmäytetä oikein. Blažićin ja muiden (2017) työssä mainitaankin esimerkiksi tiedon täydellisyydestä eri arkkitehtuureissa, joka on yksi järjestelmäriippumaton datan laadun määre.
3.3 Lähdejärjestelmän datan laatu tietovarastossa
Datan laatu ja datan lähdejärjestelmien hallinnointi ovat yksiä tärkeimmistä asioista onnistuneissa tietovarastoprojekteissa (Idris & Ahmad, 2011). Idrisin ja Ahmadin (2011) mukaan yksi suurimmista tekijöistä epäonnistuneissa tietovarastoprojekteissa on huonolaatuinen data. Uskotaan, että ongelmat voidaan korjata myöhemmin ja siinä vaiheessa ongelmien korjaamiseen käytetään todella paljon aikaa (Idris & Ahmad, 2011).
Tietovaraston lähdejärjestelmien datanlaatuongelmat johtuvat usein monista syistä, joita voivat olla esimerkiksi epäonnistuminen tietojen päivittämisessä, odottamattomat muutokset järjestelmissä, riittämätön lähteiden valinta tai riittämätön lähdejärjestelmän sisäisten riippuvuuksien tunteminen (Ranjit & Kawaljeet, 2010).
Idris ja Ahmad (2011) työssään toteavat, että estääkseen datan laatu -ongelmien syntymisen, lähdejärjestelmiä tulee hallita oikein varmistaakseen tietovarastoprojektin etenemisen ongelmitta. He ehdottavat ratkaisuksi prosessimallia lähdejärjestelmien hallintaan. Mallissa on useita vaiheita optimaalisen datan laadun saavuttamiseen, joihin on lisätty datan laadun hallinnan (DQM) erillisiä vaiheita siksi, että saadaan täytettyä datan laadun vaatimukset (Idris & Ahmad, 2011). Idrisin ja Ahmadin (2011) mukaan datan lähdejärjestelmien hallinnassa on kaksi tärkeää vaihetta: tunnistaminen ja ymmärtäminen. Tunnistaminen tarkoittaa prosessia, jossa tunnistetaan lähde ja lähteen ominaisuuksia: mistä data tulee, mikä on asiayhteys (Idris & Ahmad, 2011), mikä on dimensionaalista dataa (eli sarakkeita joiden perusteella laskentaa tehdään) ja mikä on faktadataa (eli raakatietoa, josta laskenta tehdään). Nämä on tunnistettava, jotta voidaan varmistua siitä, että kaikki datan tärkeät elementit tulee siirretyksi tietovarastoon.
Tunnistamisen jälkeen pyritään ymmärtämään datan elementtejä. Ymmärtämisen prosessissa on tarkoitus ymmärtää datan tarkoitusta (Idris & Ahmad, 2011).
Jos lähdejärjestelmä on hyvin dokumentoitu, auttaa se vastuuhenkilöä hallitsemaan projektia onnistuneesti (Idris & Ahmad, 2011). Idrisin ja Ahmadin (2011) mukaan toinen mahdollinen tekniikka lähdejärjestelmän ymmärtämiseen on sen sisääntulojen mallintaminen. Heidän mukaansa tämä helpottaa kehittäjää aloittamaan projektin. He toteavat myös huonolaatuisen datan olevan yksi isoimpia lähdejärjestelmien ongelmia yleisesti, sillä tuotantojärjestelmien käyttäytyminen on usein erilaista esimerkiksi datatyyppien määrittelyyn nähden.
Datan laadun määreisiin nähden Idrisin ja Ahmadin (2011) työssä keskitytään kokonaisuutena enemmän järjestelmäriippumattomiin datan laadun määreisiin, sillä heidän mallissaan syvennytään lähdejärjestelmien tekniseen toteutukseen mallintamisen tasolla. Painotettakoon myös järjestelmäriippuvaisten datan laadun määreiden kulkevan osittain käsi kädessä myös lähdejärjestelmien, esimerkiksi ohjelmistojen, kanssa.
3.4 Tiedon lataaminen tietovarastoon
Tietovarasto rakennetaan usein joko ETL (extract - transform - load) tai ELT (extract - load - transform) pohjaisesti. Tietovaraston perusrakenne tietokantana pysyy samanlaisena, mutta sen sisäinen arkkitehtuuri on erilainen toisiinsa nähden. Latausvaihe on tärkein vaihe tietovarastoprojektissa ja vaihe, jossa nähdään suurin vaiva datan laadun kannalta (Zellal & Zaouia, 2015). Zellalin ja Zaouian (2015) mukaan tässä vaiheessa saattaa tapahtua kompromisseja datan laadussa tai huonossa tapauksessa olla jopa datan
laatuongelmien lähde. Tässä vaiheessa myös tavalla tai toisella käsitellään suurin osa tiedosta jota tietovarastoon tallennetaan, joten myös teknisesti suurin työ tehdään tässä vaiheessa.
Huonolaatuinen data aiheuttaa ongelmia liiketoiminnassa, mutta tämän lisäksi se aiheuttaa ongelmia myös tietovarastossa teknisellä tasolla. On mahdollista, että ETL- lataukset eivät toimi oikein tai jättävät osan tiedosta hakematta, koska data rikkoo tietovarastoon määriteltyjä ehtoja tai määreitä (Rodic & Baranovic, 2009).
Rodicin ja Baranovicin (2009) ehdotuksessa SA (staging area) on tietovarastossa erikseen määritelty väliaikainen säiliö datalle, jossa dataa käsitellään tai tarkistetaan niin, että voidaan varmistua sen sopivan lopulliseen kohdetauluun. SA-tauluihin ei määritellä tietokantarajoitteita, jotta voidaan varmistua siitä, että kaikki tietokantarivit saadaan ladattua lähteestä. Rajoitteiden sijaan SA-tauluihin asetetaan tietokantasääntöjä, jotka tarkistavat sääntörikkomuksia latausten edetessä. Tietovarasto on lopullinen alue, jonne data ladataan ja josta sitä myös käytetään esimerkiksi analyyttisiin tarkoituksiin. (Rodic
& Baranovic, 2009) Rodic ja Baranovic (2009) esittelevät työssään SA-alueelle sovellettavia tietokantasääntöjä, joiden avulla datan laatua tarkastellaan. Nämä säännöt voidaan jakaa kolmeen pääkategoriaan.
Tietokannan eheyssäännöt tarkistavat ladattavaa dataa tietovarastoon määriteltyjä ehtoja ja datatyyppimäärityksiä vastaan. Tarkoituksena on löytää tai huomata ajoissa ne tietokantarivit, jotka rikkovat tietovaraston tietokantaan asetettuja datatyyppejä tai rajoitteita, jotka voidaan merkitä tarkastusta varten. (Rodic & Baranovic, 2009)
Täsmäys- ja yhdistyssäännöt käsittelevät useista lähteistä useisiin aikoihin tulevaa dataa ja tekevät tarvittavia täsmäyksiä ja yhdistyksiä (Rodic & Baranovic, 2009). Nämä voivat tarkoittaa esimerkiksi seuraavia tapauksia: tietoa ladataan tietovarastoon kahdesta lähdejärjestelmästä, mutta tietovarastossa tarvitaan näistä yhdistetty summarivi, jolloin säännöt yhdistävät kahden rivin summan yhden ID:n alle lopullisessa tietovarastotaulussa. Toisena esimerkkinä voi toimia perinteisempi täsmääminen.
Yhdestä lähdejärjestelmästä ladataan tietoa useisiin aikoihin ja joissakin latauksissa tulee mukaan päivittyneitä rivejä. Tietovarastossa tarvitaan vain tuorein tieto, joten on tarve päivittää vanha tieto uudella.
Liiketoimintasäännöt ovat sääntöjä, jotka määritellään liiketoiminnan tarpeiden mukaan ja tarkoituksena on löytää datasta sinne kuulumattomia arvoja. Näitä arvoja voivat olla esimerkiksi tyhjäarvot tai selvästi väärät arvot. (Rodic & Baranovic, 2009)
Yllä mainittujen sääntöjen soveltamisen avulla voidaan määritellä sääntörikkomuksia kategorioihin, jotka mahdollistavat tehokkaan tavan tarkastella datan laatua automaattisesti, manuaalisesti tai tarvittaessa lopettaa lataukset, jos vastaan tulee tavattoman suuri määrä sääntörikkomuksia. Tapa, jonka Rodic ja Baranovic (2009) esittelevät työssään, muistuttaa pohjimmiltaan ELT:n perusrakennetta. He kertovat, että tällainen tapa toimia voi vähentää lähdejärjestelmiin kohdistuvaa rasitusta.
Datan laadun kannalta Rodicin ja Baranovicin (2009) työssä keskitytään järjestelmäriippumattomiin datan laadun määreisiin. Toisaalta Zellal ja Zaouia (2015) mainitsevat jatkuvien lataustöiden (ETL-job) ajoittamisen vaikuttavan datan laatuun, mikä onkin järjestelmäriippumaton datan laadun määre, mutta käyttötapauksesta riippuen, oikea-aikaisuus saattaa olla myös kontekstista riippuvainen, eli järjestelmäriippuvainen.
3.5 Huonolaatuisen datan huomiointi raportoinnissa
Tämän päivän maailmassa tietoa kertyy jatkuvasti ja suurissa määrin. Tietoa käytetään yrityksissä, organisaatioissa ja henkilökohtaisessa elämässä enemmän kuin koskaan.
Organisaatiot käyttävät tietoa määrittelemään sisäisiä toimintojaan, päätöksentekijät analysoivat useista lähteistä tulevaa dataa tehdäkseen päätöksentekoprosessista nopean ja luotettavan organisaation hyväksi (Gyulgyulyan et al., 2018). Joskus kuitenkin huonolaatuista dataa pääsee toimenpiteistä huolimatta tietovarastoon ja sitä kautta käyttöön. Gyulgyulyan ja muut (2018) esittävät työssään mallin datan laadun tarkasteluun ja huonolaatuisen datan havaitsemiseen BI:ssä. Esittelemässään työssä he tutkivat mallia loppukäyttäjän näkökulmasta, jossa tämä loppukäyttäjä ei ole datan ammattilainen.
Loppukäyttäjä on henkilö, joka tekee päätöksiä tai analyysejä noudetusta datasta.
Gyulgyulyan ja muiden (2018) esittelemä malli rakentuu erilaisista luokista.
Luokille esitellään ominaisuuksia ja kuvauksia, jotka helpottavat käyttäjiä päätöksentekoprosesseissa (Gyulgyulyan et al., 2018).
Päätösprosessivaihe (Decisional process step): Luokassa määritellään missä vaiheessa laatutavoite muodostetaan ja laatudimensioista keskustellaan (Gyulgyulyan et al., 2018).
Operatiivinen konteksti (Operational context): Luokka kertoo, missä laatu on määritelty ja käsitelty, kirjataan ylös määrittelyn päivämäärä ja ala (esimerkiksi liiketoiminnallinen- tai hallinnollinen määrittely)(Gyulgyulyan et al., 2018).
Mitattava kohde (Measurable object): Luokassa määritellään mitä mitataanlaadun osalta (esimerkiksi dataa). Mittausta tehdään operatiivisessa kontekstissa laadun tavoitteiden ja kyseenalaistamisen avulla (Gyulgyulyan et al., 2018).
Toimija (Actor): Luokassa määritellään kuka asettaa tavoitteita.
Operatiivisessa kontekstissa se, joka asettaa laadun tavoitteet ja kyseenalaistaa ne (Gyulgyulyan et al., 2018).
Laatutavoite (Quality goal): Luokassa määriteellään miksi mitataan mitattavaa kohdetta ja tarkastellaan mitattavaa kohdetta laadun näkökulmasta (Gyulgyulyan et al., 2018).
Tavoitekysymys (Goal Question): Luokan tarkoituksena on jalostaa laatutavoitetta ja varmistaa se (Gyulgyulyan et al., 2018). Jokaiselle laatutavoitteelle määritellään useampia tavoitekysymyksiä ja vastaamalla tavoitekysymyksiin voidaan saavuttaa laatutavoite (Gyulgyulyan et al., 2018).
Laatudimensio (Quality dimension): Luokassa mitataan mitattavaa kohdetta erilaisilla laatumittareilla tavoitekysymysten kautta. Luokka tarkentaa laatutavoitetta antamalla sille tarkemman määritelmän (Gyulgyulyan et al., 2018).
Laatumittarit, laatumittausmetodi (Quality metric & Quality measurement method): nämä luokat määrittävät kaavan, jota sovelletaan mitattaviin kohteisiin (Gyulgyulyan et al., 2018). Laatumittari jalostaa tavoitekysymyksiä matemaattisesti ja tämä on kvantitatiivinen datan käsittelyn tapa lähestyä laadullisia ongelmia (Gyulgyulyan et al., 2018).
Laatumittausmetodi puolestaan esittää fyysistä toteutusta.
Gyulgyulyan ja muut (2018) väittävät yllä esitellyn luokkamallin parantavan päätöksenteon prosessia havaitsemalla huonolaatuisen datan laatudimensioiden avulla.
He myös kertovat tämän mallin soveltamisen vähentävän laatuongelmien ratkaisemisen vaikutusta integraatioissa. Tämän mallin avulla yritys voi tehdä analyysejä datasta tuhlaamatta aikaa kaikkien datan laadun ongelmien ratkaisemiseen vaan keskittyä vain niihin, jotka vaikuttavat kyseiseen tehtävään analyysiin (Gyulgyulyan et al., 2018).
Esitellyssä mallissa datan laatua tarkkaillaan kokonaisuutena, eikä malli ota suoraan kantaa siihen ratkotaanko järjestelmäriippumattomia vai järjestelmäriippuvaisia datan laadun määreitä. Mallissa eri luokissa siis huomioidaan eri määreitä.
Aiemmin tässä työssä esiteltyjen datan laadun varmistamisen keinojen valossa voidaan olettaa, että tilannetta jossa huonolaatuista dataa olisi lopullisissa sovelluksissa käytössä, ei olisi. Kuitenkin todellisuus saattaa olla toinen. Usein ihminen tekee vaatimusmäärittelyn, ihminen suunnittelee tietovaraston, ihminen tekee integraatioita ja inhimillisiä virheitä tai epähuomioita tulee. Usein myös ihminen, joka tekee analyysejä datasta on eri ihminen kuin se, joka suunnittelee tietovaraston tai toteuttaa integraatioita.
Tästä syystä on hyvä ymmärtää, että datan loppukäyttäjällä ei välttämättä ole taitoa tai edes mahdollisuutta korjata datan laadussa ilmenneitä ongelmia. Tästä syystä on hyvä tietää myös mitä mahdollisuuksia datan käyttäjällä on oman datansa laadun varmistamiseen.
4 Keskustelu
Tämän työn tarkoituksena oli löytää konkretiaa datan laadun varmistamiseen ja datan laadun varmistamisen keinoihin. Kuten yleisessä tiedossakin on, datan laadulla on suuri merkitys onnistuneessa tietovarastoprojektissa (Idris & Ahmad, 2011). Kirjallisuutta aiheesta datan laatu löytyy paljon, mutta konkreettisia keinoja datan laadun varmistamiseen tietovarastoprojektin eri vaiheissa löytyy yllättävän vähän ja nämä keinot vaiheittain muistuttavat perusrakenteeltaan toinen toisiaan. Erityisesti latausvaiheen konkreettiset keinot olisivat olleet erityisen kiinnostavia tämän työn kannalta, koska latausvaihe käsittelee teknisesti tietoa eniten tavalla tai toisella ja on myös Zellalin ja Zaouian (2015) mukaan vaihe, jossa suurin vastuu datan laadusta kannetaan.
Lähes kaikissa töissä nousi esiin tarpeiden ymmärtäminen. Määrityksillä ja suunnittelulla on tarkasteltujen töiden perusteella iso merkitys onnistuneissa ja ennen kaikkea toimivissa tietovarastoissa. Jatkuvasti monimutkaistuvissa tietovarastoissa on huomioitava laadun tarkkailu niiden suunnittelussa ja kehittämisessä (Kumar et al., 2011).
Tarkastelemieni tutkimusten perusteella voidaan olettaa järjestelmäriippumattomien datan laadun määreiden täyttämisen olevan helpompaa verrattuna järjestelmäriippuvaisiin datan laadun määreisiin. Teknisellä tasolla voidaan helposti todeta esimerkiksi datatyyppirikkomuksia, mutta teknisesti on vaikeampi todeta rikkomuksia käyttäjän kannalta oleellisissa asioissa. Kuten Auer ja Felderer (2019)
tutkimuksessaan mainitsivatkin, järjestelmäriippuvaisia datan määreitä saattaa olla vaikea mitata ilman vuorovaikutusta ihmisen kanssa. Se, miksi järjestelmäriippuvaiset määreet ovat niin keskeisessä asemassa datan laadun kokonaisuuden kannalta käy selväksi tarkastelluissa tutkimuksissa. Se, miksi konkreettinen tapa määritellä datan laatua esimerkiksi matemaattisilla malleilla on niin hankalaa, jäi hieman epäselväksi siitä huolimatta, että useissa tutkimuksissa käsiteltiin ihmisen roolia datan käyttäjänä.
Tässä työssä ei ole syvennytty erilaisiin ETL- ja ELT-työkaluihin, joita on tällä hetkellä markkinoilla useita. Näiden ohjelmistojen tarkastelun rajaaminen työn ulkopuolelle on tehty tietoisesti, jotta saataisiin tarkempi kuva laadun tarkkailun perusteista. Useat näistä työkaluista sisältävät monimutkaisia komponenttikokonaisuuksia, joiden avulla dataa siivotaan ja valvotaan. Nämä komponentit pitävät sisällään peruselementtejä, joita tässä työssä haluttiin tarkastella.
Kuten Idris ja Ahmad (2011) työssään toteavat, useat tietovarastoprojektit kaatuvat huonolaatuiseen dataan. Mielestäni tässä työssä esiteltyä kokonaiskuvaa tulisi hyödyntää tietovarastoprojekteissa kokonaisuutena. Tästä voi olla suuri hyöty tietovaraston tarpeiden määrittelyssä ja vaatimusten teknisen toteutuksen suunnittelussa.
Kokonaisuutena tämä työ soveltuu käytäntöön parhaiten alkuvaiheessa olevaan projektiin. Suunnittelun ja määrittelyn aloittaminen myöhemmin projektissa saattaa olla jo liian myöhäistä.
5 Yhteenveto
Tutkielman päätavoitteena oli tutkia mahdollisuuksia datan laadun varmistamiseen tietovarastoprojektin eri vaiheissa. Suurimpana teemana tutkimuksissa nousi esiin tarpeiden ymmärtäminen ja datan laadun määreisiin viitaten järjestelmäriippuvaisten datan laadun ominaisuuksien tärkeys. Tarpeiden kokonaisuuden ymmärtäminen ja sen johdolla tietovaraston suunnittelu ja rakentaminen sai yllättävänkin isot mittasuhteet.
Ymmärtämällä tietovaraston suunnittelun tärkeyden tietovarastoprojekteissa, voidaan välttyä datan laadun ongelmilta suuressa osassa tapauksia. Datan laatu tai pikemminkin laadukas data näyttäytyy käytännössä parantuneena tehokkuutena ja analyysien tarkkuutena, mikä toisaalta hyödyttää dataa käyttävää organisaatiota.
LÄHDELUETTELO
Adnan, Ilham, A. A., & Usman, S. (2017). Performance analysis of extract, transform, load (ETL) in apache Hadoop atop NAS storage using ISCSI. 2017 4th
International Conference on Computer Applications and Information Processing Technology (CAIPT), 1–5. 8-10.8.2017, Kuta Bali, Indonesia.
https://doi.org/10.1109/CAIPT.2017.8320716
Auer, F., & Felderer, M. (2019). Addressing Data Quality Problems with Metamorphic Data Relations. Proceedings of the 4th International Workshop on Metamorphic Testing, 76–83. 26.5.2019, Montreal, QC, Canada.
https://doi.org/10.1109/MET.2019.00019
Bagambiki, E. (2018). Enterprise Data Warehouse and Business Intelligence Solution.
Proceedings of the 11th International Conference on Theory and Practice of Electronic Governance, 665–666. 4-6.4.2018, Galway, Ireland.
https://doi.org/10.1145/3209415.3209420
Blažić, G., Poščić, P., & Jakšić, D. (2017). Data warehouse architecture classification.
2017 40th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 1491–1495. 22- 26.5.2017, Opatija, Croatia. https://doi.org/10.23919/MIPRO.2017.7973657 Dayal, U., Castellanos, M., Simitsis, A., & Wilkinson, K. (2009). Data Integration
Flows for Business Intelligence. Proceedings of the 12th International Conference on Extending Database Technology: Advances in Database Technology, 1–11. 24- 26.3.2009, Saint Petersburg, Russia. https://doi.org/10.1145/1516360.1516362 de Carvalho, D., Rocha, R., Fernandes, V., & Neves, S. (2016). Business Intelligence:
Future Perspectives (April, 2016). Proceedings of the Ninth International C*
Conference on Computer Science & Software Engineering, 89–92. 20- 22.7.2016, Porto, Portugal. https://doi.org/10.1145/2948992.2949011
Dedic., N., & Stanier., C. (2016). An Evaluation of the Challenges of Multilingualism in Data Warehouse Development. Proceedings of the 18th International Conference on Enterprise Information Systems - Volume 1: ICEIS, 196–206. 25-28.4.2016.
Rome, Italy. https://doi.org/10.5220/0005858401960206
Fan, W. (2015). Data Quality: From Theory to Practice. ACM SIGMOD Record, 44(3), 7–18. https://doi.org/10.1145/2854006.2854008
Google Trends. (2021). Google Trends.
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F016jq3 (Haettu 16.1.2021)
Gyulgyulyan, E., Ravat, F., Astsatryan, H., & Aligon, J. (2018). Data Quality Impact in Business Inteligence. 2018 Ivannikov Memorial Workshop (IVMEM), 47–51. 3- 4.5.2018, Yerevan, Armenia. https://doi.org/10.1109/IVMEM.2018.00016 Idris, N., & Ahmad, K. (2011). Managing Data Source quality for data warehouse in
manufacturing services. Proceedings of the 2011 International Conference on Electrical Engineering and Informatics, 1–6. 17-19.7.2011, Bandung, Indonesia.
https://doi.org/10.1109/ICEEI.2011.6021598 ISO/IEC 25012. (2020). ISO25000.
https://iso25000.com/index.php/en/iso-25000-standards/iso-25012 (Haettu 4.12.2020)
Kumar, M., Gosain, A., & Singh, Y. (2011). Quality-Oriented Requirements
Engineering for a Data Warehouse. SIGSOFT Software Engineering Notes, 36(5), 1–4. https://doi.org/10.1145/2020976.2020990
Munawar, Salim, N., & Ibrahim, R. (2011). Towards Data Quality into the Data Warehouse Development. 2011 IEEE Ninth International Conference on Dependable, Autonomic and Secure Computing, 1199–1206. 12-14.12.2011, Sydney, NSW, Australia. https://doi.org/10.1109/DASC.2011.194
Ranjit, S., & Kawaljeet, S. (2010). A Descriptive Classification of Causes of Data Quality Problems in Data Warehousing. International Journal of Computer Science Issues, 7. 41-50.
Rodic, J., & Baranovic, M. (2009). Generating Data Quality Rules and Integration into ETL Process. Proceedings of the ACM Twelfth International Workshop on Data Warehousing and OLAP, 65–72. 6.11.2009, Hong Kong, China.
https://doi.org/10.1145/1651291.1651303 Rouse, M. (2021). DEFINITION data integration.
https://searchdatamanagement.techtarget.com/definition/data-integration (Haettu 16.1.2021)
Vassiliadis, P., Simitsis, A., & Skiadopoulos, S. (2002). Conceptual Modeling for ETL Processes. Proceedings of the 5th ACM International Workshop on Data
Warehousing and OLAP, 14–21. 8.11.2002, Virginia, McLean, USA.
https://doi.org/10.1145/583890.583893
Zellal, N., & Zaouia, A. (2015). An exploratory investigation of Factors Influencing Data Quality in Data Warehouse. 2015 Third World Conference on Complex Systems (WCCS), 1–6. 23-25.11.2015, Marrakech, Morocco
https://doi.org/10.1109/ICoCS.2015.7483222
