Якасць дадзеных у сховішчы з'яўляецца важнай перадумовай да атрымання каштоўнай інфармацыі. Дрэнная якасць вядзе да негатыўнай ланцуговай рэакцыі ў доўгатэрміновай перспектыве.
Спачатку губляецца давер да прадстаўленай інфармацыі. Людзі пачынаюць менш выкарыстоўваць Business Intelligence прыкладання, патэнцыял прыкладанняў застаецца не запатрабаваным.
У выніку пад пытанне ставяцца далейшыя інвестыцыі ў аналітычны праект.
Адказнасць за якасць дадзеных
Аспект, звязаны з паляпшэннем якасці даных, з'яўляецца мегаважным ў BI праектах. Аднак ён не з'яўляецца прывілігіяй толькі тэхнічных спецыялістаў.
На якасць дадзеных уплываюць таксама такія аспекты, як
Карпаратыўная культура
- Ці зацікаўлены самі работнікі ў вытворчасці добрай якасці?
- Калі не, то чаму? Можа быць прысутнічае канфлікт інтарэсаў.
- Можа быць есць карпаратыўныя правілы, якія вызначаюць адказных за якасць?
працэсы
- Якія дадзеныя ствараюцца ў канцы гэтых ланцужкоў?
- Можа быць аперацыйныя сістэмы настроены так, што трэба "выкручвацца", каб адлюстраваць тую ці іншую сітуацыю ў рэальнасці.
- Ці праводзяць аперацыйныя сістэмы самі праверку і зверку дадзеных?
За якасць дадзеных у справаздачных сістэмах адказныя ўсё ў арганізацыі.
Вызначэнне і значэнне
Якасць - гэта пацверджанае задавальненне чаканняў кліента.
Але якасць дадзеных не ўтрымоўвае ў сабе азначэнні. Яно заўсёды адлюстроўвае кантэкст выкарыстання. Сховішча дадзеных і сістэма BI выконваюць іншыя мэты, чым аперацыйная сістэма, адкуль дадзеныя ўзяты.
Напрыклад, у аперацыйнай сістэме атрыбут кліента можа быць не абавязковым полем. У сховішчы гэты атрыбут можа выкарыстоўвацца як вымярэнне і яго запаўненне абавязкова. Што, у сваю чаргу, уводзіць неабходнасць запаўнення значэннямі па-змаўчанні.
Патрабаванні да сховішча дадзеных увесь час змяняюцца і яны, як правіла, вышэй, чым да аперацыйных сістэм. Але можа быць і наадварот, калі ў сховішча не патрабуецца захоўваць падрабязнай інфармацыі з аперацыйнай сістэмы.
Каб зрабіць якасць дадзеных вымяраным, павінны быць апісаны яго стандарты. Людзі, якія выкарыстоўваюць інфармацыю і лічбы для сваёй працы, павінны быць уцягнуты ў працэс апісання. Вынікам гэтага ўцягвання можа быць правіла, прытрымліваючыся якому, можна з аднаго погляду на табліцу сказаць, ёсць памылка ці не. Гэтае правіла трэба аформіць у выглядзе скрыпту/кода для наступнай верыфікацыі.
Паляпшэнне якасці дадзеных
Немагчыма пачысціць і выправіць усе гіпатэтычныя памылкі падчас загрузкі дадзеных у сховішча. Добрай якасці дадзеных можна дасягнуць толькі падчас цеснай працы ўсіх удзельнікаў. Людзі, якія ўводзяць дадзеныя ў аперацыйныя сістэмы павінны пазнаць, якія дзеянні прыводзяць да памылак.
Якасць дадзеных - гэта працэс. Нажаль, у шматлікіх арганізацыях няма стратэгіі для яго сталага паляпшэння. Многія абмяжоўваюць сябе толькі захаваннем дадзеных і не выкарыстоўваюць увесь патэнцыял аналітычных сістэм. Як правіла, пры распрацоўцы сховішчаў даных 70-80 працэнтаў бюджэту ідзе на рэалізацыю інтэграцыі даных. Працэс кантролю і паляпшэння застаецца недапрацаваным, калі ўвогуле застаецца.
Інструменты
Ужыванне праграмных прылад можа дапамагчы падчас аўтаматызацыі паляпшэння і маніторынгу якасці дадзеных. Напрыклад, імі можна цалкам аўтаматызаваць тэхнічную праверку структур сховішчы: фармат палёў, наяўнасць значэнняў па-змаўчанні, адпаведнасць патрабаванням назваў палёў табліц.
Больш складана можа быць з праверкай змесціва. Бо патрабаванні да сховішча змяняюцца, можа змяніцца і інтэрпрэтацыя дадзеных. Інструмент сам можа ператварыцца ў вялізны праект, які патрабуе падтрымкі.
Савет
Рэляцыйныя базы дадзеных, у якіх звычайна праектуюцца сховішчы, маюць выдатную магчымасць ствараць паданні (люткі). Іх можна выкарыстоўваць для хуткай праверкі дадзеных, калі ведаць асаблівасці змесціва. Кожны выпадак знаходжання памылкі ці праблемы ў дадзеных можна фіксаваць у выглядзе запыту да базы дадзеных.
Такім чынам, будзе фармавацца база ведаў пра змесціва. Канешне, такія запыты павінны быць хуткімі. Як правіла, абслугоўванне ўяўленняў займае менш чалавечага часу, чым інструментаў, арганізаваных на табліцах. Прадстаўленне заўсёды гатова адлюстраваць вынік праверкі.
У выпадку важных справаздач, прадстаўленне можа змяшчаць калонку з адрасатам. Мае сэнс тымі ж сродкамі BI рабіць справаздачнасць аб стане якасці дадзеных у сховішчы.
Прыклад
Запыт напісаны для базы Oracle. У дадзеным прыкладзе тэсты вяртаюць лікавае значэнне, якое можна патрэбнай выявай інтэрпрэтаваць. Значэннямі T_MIN і T_MAX можна рэгуляваць ступень трывогі. Поле REPORT калісьці выкарыстоўвалася як паведамленне ў камерцыйным ETL прадукце, які не ўмеў годна адпраўляць емейлы, паэтам rpad – гэта «мыліца».
У выпадку вялікай табліцы можна дадаць, напрыклад, AND ROWNUM <= 10, г.зн. калі набралася 10 памылак, то гэтага дастаткова для трывогі.
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
У публікацыі скарыстаны матэрыялы кнігі
Ronald Bachmann, Dr. Guido Kemper
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Крыніца: habr.com