Качеството на данните в склада е важна предпоставка за получаване на ценна информация. Лошото качество води до негативна верижна реакция в дългосрочен план.
Първо, доверието в предоставената информация се губи. Хората започват да използват приложенията за бизнес разузнаване по-малко; потенциалът на приложенията остава непотърсен.
В резултат на това по-нататъшните инвестиции в аналитичния проект са поставени под въпрос.
Отговорност за качеството на данните
Аспектът, свързан с подобряване на качеството на данните, е мега важен в 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
В изданието са използвани материали от кн
Роналд Бахман, д-р. Гуидо Кемпер
Raus aus der BI-Falle
Wie Business Intelligence zum Erfolg wird
Източник: www.habr.com