Varastossa olevien tietojen laatu on tärkeä edellytys arvokkaan tiedon saamiselle. Huono laatu johtaa pitkällä aikavälillä negatiiviseen ketjureaktioon.
Ensinnäkin luottamus annettuun tietoon menetetään. Ihmiset alkavat käyttää Business Intelligence -sovelluksia vähemmän, sovellusten potentiaali on edelleen käyttämätön.
Tämän seurauksena lisäinvestoinnit analyyttiseen projektiin asetetaan kyseenalaiseksi.
Vastuu tiedon laadusta
Tietojen laadun parantamiseen liittyvä näkökohta on BI-projekteissa mega tärkeä. Se ei kuitenkaan ole vain teknisten asiantuntijoiden etuoikeus.
Tiedon laatuun vaikuttavat myös mm
Yrityskulttuuri
- Ovatko työntekijät itse kiinnostuneita hyvän laadun tuottamisesta?
- Jos ei, miksi ei? Voi olla eturistiriita.
- Ehkä on olemassa yrityssääntöjä, jotka määräävät, kuka on vastuussa laadusta?
prosessit
- Mitä tietoja näiden ketjujen lopussa luodaan?
- Ehkä käyttöjärjestelmät on konfiguroitu siten, että sinun on "kierrettävä" kuvastamaan tätä tai tuota tilannetta todellisuudessa.
- Suorittavatko käyttöjärjestelmät itse tietojen tarkistuksen ja täsmäytyksen?
Jokainen organisaatiossa on vastuussa raportointijärjestelmien tietojen laadusta.
Määritelmä ja merkitys
Laatu on todistetusti asiakkaiden odotusten tyydyttämistä.
Tietojen laatu ei kuitenkaan sisällä määritelmää. Se kuvastaa aina käyttökontekstia. Tietovarasto ja BI-järjestelmä palvelevat eri tarkoituksia kuin käyttöjärjestelmä, josta tiedot tulevat.
Esimerkiksi käyttöjärjestelmässä asiakasmäärite voi olla valinnainen kenttä. Arkistossa tätä attribuuttia voidaan käyttää mittana ja sen täyttö vaaditaan. Mikä puolestaan tuo mukanaan tarpeen täyttää oletusarvot.
Tietojen tallennusvaatimukset muuttuvat jatkuvasti ja ne ovat yleensä korkeammat kuin käyttöjärjestelmillä. Mutta se voi olla myös päinvastoin, kun käyttöjärjestelmän yksityiskohtaisia tietoja ei tarvitse tallentaa muistiin.
Jotta tiedon laatu olisi mitattavissa, sen standardit on kuvattava. Tietoa ja lukuja työhönsä käyttävien tulee olla mukana kuvausprosessissa. Tämän osallistumisen seurauksena voi olla sääntö, jota noudattamalla voidaan yhdellä vilkaisulla taulukkoon päätellä, onko virhe vai ei. Tämä sääntö on muotoiltava komentosarjaksi/koodiksi myöhempää vahvistusta varten.
Tietojen laadun parantaminen
On mahdotonta puhdistaa ja korjata kaikkia hypoteettisia virheitä prosessin aikana, kun tietoja ladataan varastoon. Hyvä tiedon laatu voidaan saavuttaa vain kaikkien osallistujien tiiviillä yhteistyöllä. Käyttäjien, jotka syöttävät tietoja käyttöjärjestelmiin, on opittava, mitkä toimet johtavat virheisiin.
Tietojen laatu on prosessi. Valitettavasti monilla organisaatioilla ei ole jatkuvan parantamisen strategiaa. Monet rajoittuvat vain tietojen tallentamiseen eivätkä käytä analyyttisten järjestelmien koko potentiaalia. Tyypillisesti tietovarastoja kehitettäessä budjetista 70-80 % käytetään dataintegraation toteuttamiseen. Seuranta- ja parannusprosessi on edelleen kesken, jos ollenkaan.
Työkalut
Ohjelmistotyökalujen käyttö voi auttaa automatisoimaan tietojen laadun parantamista ja seurantaa. Ne voivat esimerkiksi täysin automatisoida tallennusrakenteiden teknisen tarkastuksen: kentän muoto, oletusarvojen olemassaolo, taulukkokenttien nimien noudattaminen.
Sisällön tarkistaminen voi olla vaikeampaa. Tallennusvaatimusten muuttuessa tietojen tulkinta voi myös muuttua. Itse työkalusta voi tulla valtava projekti, joka vaatii tukea.
neuvosto
Relaatiotietokannat, joihin myymälät tyypillisesti suunnitellaan, omaavat huomattavan kyvyn luoda näkymiä. Niitä voidaan käyttää tietojen nopeaan tarkistamiseen, jos tiedät sisällön yksityiskohdat. Jokainen virheen tai ongelman löytäminen tiedoista voidaan tallentaa tietokantakyselyn muodossa.
Näin muodostuu tietopohja sisällöstä. Tietysti tällaisten pyyntöjen on oltava nopeita. Näkymien ylläpito vaatii yleensä vähemmän aikaa kuin taulukkopohjaiset työkalut. Näkymä on aina valmis näyttämään testin tuloksen.
Tärkeiden raporttien tapauksessa näkymä voi sisältää sarakkeen, jossa on vastaanottaja. On järkevää käyttää samoja BI-työkaluja varaston tietojen laadun raportointiin.
Esimerkki
Kysely kirjoitettiin Oracle-tietokantaa varten. Tässä esimerkissä testit palauttavat numeerisen arvon, joka voidaan tulkita halutulla tavalla. T_MIN- ja T_MAX-arvoja voidaan käyttää hälytystason säätämiseen. RAPORTTI-kenttää käytettiin kerran viestinä kaupallisessa ETL-tuotteessa, joka ei osannut lähettää sähköposteja oikein, joten rpad on "sauva".
Suuren taulukon tapauksessa voit lisätä esimerkiksi AND RIVINUMERO <= 10, ts. jos virheitä on 10, tämä riittää hälyttämään.
CREATE OR REPLACE VIEW V_QC_DIM_PRODUCT_01 AS
SELECT
CASE WHEN OUTPUT>=T_MIN AND OUTPUT<=T_MAX
THEN 'OK' ELSE 'ERROR' END AS RESULT,
DESCRIPTION,
TABLE_NAME,
OUTPUT,
T_MIN,
T_MAX,
rpad(DESCRIPTION,60,' ') || rpad(OUTPUT,8,' ') || rpad(T_MIN,8,' ') || rpad(T_MAX,8,' ') AS REPORT
FROM (-- Test itself
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Count of blanks' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- not default value
AND ATTRIBUTE IS NULL ); -- count blanks
Julkaisussa on käytetty kirjan materiaalia
Ronald Bachmann, tohtori Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Lähde: will.com