Качеството на данните в хранилище е важна предпоставка за получаване на ценна информация. Лошото качество води до негативна верижна реакция в дългосрочен план.
Първо, доверието в предоставената информация се губи. Хората започват да използват по-малко приложения за бизнес интелигентност, потенциалът на приложенията остава неизползван.
В резултат на това се поставя под въпрос по-нататъшното инвестиране в аналитичния проект.
Отговорността за качеството на данните
Аспектът, свързан с подобряване на качеството на данните, е изключително важен в проектите за BI. Но той не е привилегия само на техническите специалисти.
На качеството на данните влияят също и такива аспекти като
Корпоративна култура
- Интересуват ли се самите служители от произвеждането на добро качество?
- Ако не, защо? Може би има конфликт на интереси.
- Може би има корпоративни правила, които определят отговорните за качеството?
Процеси
- Какви данни се създават в края на тези вериги?
- Може би операционните системи са настроени така, че е необходимо да се "приспособяваме", за да отразим тази или онази ситуация в реалността.
- Извършват ли операционните системи сами проверка и сверка на данните?
За качеството на данните в отчетните системи са отговорни всички в организацията.
Определение и значение
Качеството е потвърдена удовлетвореност на очакванията на клиента.
Но качеството на данните не съдържа определение. То винаги отразява контекста на използване. Хранилището на данни и системата BI служат за различни цели от операционната система, от която са взети данните.
Например, в операционната система атрибутът на клиента може да бъде незадължително поле. В хранилището този атрибут може да се използва като измерение и неговото попълване е задължително. Което от своя страна въвежда необходимостта от попълване с подразбиращи се стойности.
Изискванията към хранилището на данни постоянно се променят и те, като правило, са по-високи от тези към операционните системи. Но може да е и обратното, когато в хранилището не е необходимо да се съхранява подробна информация от операционната система.
За да направим качеството на данните измеримо, стандартите му трябва да бъдат описани. Хората, които използват информация и цифри в работата си, трябва да бъдат ангажирани в процеса на описание. Резултатът от това участие може да бъде правило, следвайки което, от един поглед на таблицата може да се каже дали има грешка или не. Това правило трябва да бъде формулирано под формата на скрипт/код за последваща верификация.
Подобряване на качеството на данните
Невъзможно е да се почистят и поправят всички хипотетични грешки по време на зареждането на данни в хранилището. Добро качество на данните може да се постигне само чрез тясно сътрудничество на всички участници. Хората, които въвеждат данни в операционните системи, трябва да научат какви действия водят до грешки.
Качеството на данните е процес. За съжаление, много организации нямат стратегия за постоянното му подобряване. Мнозина се ограничават само до запазване на данните и не използват целия потенциал на аналитичните системи. Както обикновено, при разработването на хранилища за данни 70-80% от бюджета отива за реализация на интеграцията на данните. Процесът на контрол и подобряване остава недоразвит, ако изобщо остане.
Инструменти
Приложението на софтуерни инструменти може да помогне в процеса на автоматизация на подобряване и мониторинг на качеството на данните. Например, с тях може напълно да се автоматизира техническата проверка на структурите на хранилището: формат на полетата, наличие на стойности по подразбиране, съответствие на изискванията за имената на полетата в таблиците.
По-трудно може да бъде с проверката на съдържанието. Тъй като изискванията към хранилището се променят, може да се промени и интерпретацията на данните. Инструментът сам може да се превърне в огромен проект, изискващ поддръжка.
Съвет
Релационните бази данни, в които обикновено се проектират хранилищата, имат забележителната възможност да създават представления (views). Те могат да се използват за бърза проверка на данните, ако знаеш особеностите на съдържанието. Всеки случай на откритие на грешка или проблем в данните може да се фиксира под формата на заявка към базата данни.
Така се формира база знания за съдържанието. Разбира се, такива заявки трябва да бъдат бързи. Обикновено обработката на изгледи отнема по-малко човешко време, отколкото инструментите, организирани на таблици. Изгледът винаги е готов да покаже резултата от проверката.
В случай на важни отчети, изгледът може да съдържа колона с получателя. Има смисъл същите 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 (-- Тест сам
SELECT
'DIM_PRODUCT' AS TABLE_NAME,
'Брой празни полета' AS DESCRIPTION,
COUNT(*) AS OUTPUT,
0 AS T_MIN,
10 AS T_MAX
FROM DIM_PRODUCT
WHERE DIM_PRODUCT_ID != -1 -- не е стойност по подразбиране
AND ATTRIBUTE IS NULL ); -- брой на празни полета
В публикацията са използвани материали от книгата
Роналд Бахман, д-р Гвидо Кемпер
Излезте от BI капана
Как бизнес интелигентността става успешна
Източник: habr.com
