Jakość danych w magazynie jest istotnym warunkiem uzyskania cennych informacji. Słaba jakość prowadzi do negatywnej reakcji łańcuchowej w dłuższej perspektywie.
Najpierw traci się zaufanie do podanych informacji. Ludzie zaczynają rzadziej korzystać z aplikacji Business Intelligence, potencjał tych aplikacji pozostaje niewykorzystany.
W rezultacie stawiane są pod znakiem zapytania dalsze inwestycje w projekt analityczny.
Odpowiedzialność za jakość danych
Aspekt związany z poprawą jakości danych jest niezwykle ważny w projektach BI. Jednak nie jest on przywilejem wyłącznie specjalistów technicznych.
Na jakość danych wpływ mają również takie aspekty, jak
Kultura korporacyjna
- Czy sami pracownicy są zainteresowani wytwarzaniem dobrej jakości?
- Jeśli nie, to dlaczego? Może istnieje konflikt interesów.
- Może istnieją zasady korporacyjne określające odpowiedzialnych za jakość?
Procesy
- Jakie dane powstają na końcu tych łańcuchów?
- Może systemy operacyjne są skonfigurowane w taki sposób, że trzeba się „wykonywać”, aby odzwierciedlić daną sytuację w rzeczywistości.
- Czy systemy operacyjne same przeprowadzają weryfikację i porównanie danych?
Za jakość danych w systemach raportowych odpowiadają wszyscy w organizacji.
Definicja i znaczenie
Jakość to potwierdzone spełnienie oczekiwań klienta.
Ale jakość danych nie zawiera w sobie definicji. Zawsze odzwierciedla kontekst użycia. Hurtownia danych i system BI mają inne cele niż system operacyjny, z którego dane zostały pobrane.
Na przykład w systemie operacyjnym atrybut klienta może być polem nieobowiązkowym. W hurtowni ten atrybut może być używany jako miara, a jego wypełnienie jest obowiązkowe. Co z kolei wprowadza konieczność wypełnienia wartościami domyślnymi.
Wymagania dotyczące hurtowni danych stale się zmieniają i co do zasady są wyższe niż w przypadku systemów operacyjnych. Ale może być też odwrotnie, gdy w hurtowni nie trzeba zachowywać szczegółowych informacji z systemu operacyjnego.
Aby uczynić jakość danych mierzalną, muszą być opisane jej standardy. Osoby korzystające z informacji i danych w swojej pracy powinny być zaangażowane w proces opisywania. Efektem tego zaangażowania może być zasada, na podstawie której na pierwszy rzut oka przy spojrzeniu na tabelę można stwierdzić, czy wystąpił błąd, czy nie. Zasadę tę należy sformalizować w postaci skryptu/kodu do późniejszej weryfikacji.
Poprawa jakości danych
Nie można wyczyścić ani naprawić wszystkich hipotetycznych błędów podczas ładowania danych do magazynu. Dobrych jakości danych można osiągnąć jedynie w wyniku bliskiej współpracy wszystkich uczestników. Osoby wprowadzające dane do systemów operacyjnych powinny dowiedzieć się, jakie działania prowadzą do błędów.
Jakość danych to proces. Niestety, w wielu organizacjach nie ma strategii dla jej ciągłego doskonalenia. Wiele ogranicza się jedynie do zachowania danych i nie wykorzystuje pełnego potencjału systemów analitycznych. Zazwyczaj, podczas tworzenia magazynów danych, 70-80% budżetu przeznaczone jest na realizację integracji danych. Proces kontrolowania i poprawy pozostaje niedopracowany, jeśli w ogóle istnieje.
Narzędzia
Zastosowanie narzędzi programowych może pomóc w automatyzacji poprawy i monitorowania jakości danych. Na przykład, można w pełni zautomatyzować techniczną weryfikację struktur magazynu: format pól, obecność wartości domyślnych, zgodność z wymaganiami dla nazw pól tabel.
Trudniej może być z weryfikacją zawartości. Ponieważ wymagania dotyczące magazynu się zmieniają, może zmienić się również interpretacja danych. Narzędzie samo może stać się ogromnym projektem wymagającym wsparcia.
Rada
Relacyjne bazy danych, w których zazwyczaj projektuje się magazyny, mają niezwykłą zdolność do tworzenia widoków (view). Można je wykorzystać do szybkiej weryfikacji danych, jeśli zna się szczegóły zawartości. Każdy przypadek znalezienia błędu lub problemu w danych można rejestrować w postaci zapytania do bazy danych.
W ten sposób będzie tworzona baza wiedzy na temat zawartości. Oczywiście takie zapytania muszą być szybkie. Zazwyczaj obsługa widoków zajmuje mniej czasu niż narzędzia zorganizowane w tabelach. Widok zawsze jest gotowy do wyświetlenia wyniku sprawdzenia.
W przypadku ważnych raportów, widok może zawierać kolumnę z adresatem. Warto wykorzystać te same narzędzia BI do raportowania stanu jakości danych w magazynie.
Przykład
Zapytanie jest napisane dla bazy Oracle. W tym przykładzie testy zwracają wartość liczbową, którą można odpowiednio zinterpretować. Wartości T_MIN i T_MAX służą do regulacji stopnia alarmu. Pole REPORT było kiedyś używane jako wiadomość w komercyjnym produkcie ETL, który nie potrafił wysyłać e-maili w prawidłowy sposób, dlatego rpad to „tymczasowe obejście”.
W przypadku dużej tabeli można dodać na przykład AND ROWNUM <= 10, tzn. jeśli wystąpiło 10 błędów, to wystarczy do alarmu.
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 same w sobie
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 -- nie wartość domyślna
AND ATTRIBUTE IS NULL ); -- liczba pustych
W publikacji wykorzystano materiały książki
Ronald Bachmann, Dr. Guido Kemper
Wyjście z pułapki BI
Jak Business Intelligence staje się sukcesem
Źródło: habr.com
