Якість даних у сховищі є важливою передумовою для отримання цінної інформації. Погана якість веде до негативної ланцюгової реакції у довгостроковій перспективі.
Спочатку втрачається довіра до наданої інформації. Люди починають менше використовувати 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