Źle zdefiniowany słownik potrafi zatrzymać cały proces ETL – a drobny błąd składniowy powoduje duże konsekwencje w raportowaniu. Dlatego walidacja składni to prosta, ale niezwykle skuteczna kontrola jakości danych. W tym artykule pokazujemy, kiedy jej użycie naprawdę robi różnicę.
Klasyczne podejście projektowania procesów ETL (Extract, Transform, Load), w którym całość procesów implementowana jest w narzędziu, ma niezaprzeczalne zalety:
- całością przetwarzania zarządzamy z poziomu jednego narzędzia,
- możemy w prosty sposób przygotować dokumentację procesów,
- możemy prześledzić przepływy danych w obrębie procesów.
Cóż z tego, jeżeli wszystkie te „zalety” przestają przynosić korzyści wtedy, gdy poziom skomplikowania procesów zaczyna znacząco rosnąć. Zamiast pierwotnie czytelnego diagramu przepływu danych w procesie jak przykładowo poniższy:
Otrzymujemy kompletnie nieczytelny i nieużywalny schemat:
Dodatkowo dochodzą inne wady takiego podejścia:
- zmiana sposobu działania procesu wymaga wprowadzenia jej bezpośrednio w narzędziu ETL,
- zmianę wprowadzić mogą wyłącznie osoby:
- mające dostęp do narzędzia ETL,
- znające sposób jego działania,
- oraz mające odpowiednią wiedzę techniczną.
Jak możemy zatem temu zaradzić?
W poprzednich publikacjach wielokrotnie pisałem o tym, że wykorzystanie słowników parametryzujących procesy przetwarzania danych (np. przy zasilaniu hurtowni danych) jest skutecznym sposobem na rozwiązanie problemów związanych z bieżącym dostosowaniem procesów do zmieniającego się otoczenia biznesowego.
W wieloletniej praktyce przy realizacji projektów związanych z budową hurtowni danych, czy wdrażaniem systemów raportowych, przekonałem się, że tego typu podejście ma swoje zalety, które sprawiają, że stawiam go ponad innymi.
Jeżeli przygotujemy proces przetwarzania danych w taki sposób, że całość definicji biznesowej (np. mapowania danych wejściowych na struktury wyjściowe) przeniesiemy do zewnętrznego słownika w postaci tabeli bazodanowej, wówczas znakomicie zwiększymy elastyczności procesu.
No dobrze: przenieśliśmy definicję mapowań poza narzędzie ETL. Co dalej? Poprawiliśmy czytelność takiego procesu, możemy zmieniać jego kształt poprzez zmianę definicji mapowań bez konieczności używania interfejsu narzędzia ETL.
Czy przenoszenie definicji mapowań do zewnętrznego słownika ma sens?
Odpowiedź będzie brzmiała: „zdecydowanie tak”, jeżeli do zarządzania takim słownikiem użyjemy Metastudio DRM.
Dlaczego? Przyjrzyjmy się temu w szczegółach.
Dla kolumn, w których przechowywane są definicje mapowań (najczęściej są to fragmenty kodu w składni języka takiego jak SQL czy 4GL), możemy zdefiniować walidację poprawności składni.
Walidator składni umożliwia w pierwszej kolejności sprawdzenie poprawności pod względem formalnym: wbudowane funkcje, operatory logiczne, arytmetyczne etc. We wspomnianych fragmentach kodu używane są jednak często takie ciągi znaków, jak nazwy tabel i kolumn, nazwy własnych funkcji, procedur czy wreszcie zdefiniowanych stałych.
Aby mieć absolutną pewność, że wprowadzony fragment kodu zostanie poprawnie zinterpretowany w środowisku wykonawczym serwera ETL, możemy dodatkowo wzbogacić definicję walidatora składni o:
- listę poprawnych stałych, np. nazw obiektów (kolumn), które mogą być użyte
- listę nazw własnych funkcji, wraz z poprawną liczbą i formatem parametrów
- listę nazw zmiennych.
Podsumowanie
Dzięki temu możliwe będzie udostępnienie ww. słownika do utrzymania przez użytkowników biznesowych. Takich, którzy nie mają dostępu do narzędzia ETL, nie mogą samodzielnie przetestować czy przetwarzanie (oparte o ten słownik) wykona się poprawnie.
Natomiast funkcjonalność walidacji składni pozwoli na uzyskanie pożądanego efektu – użytkownik odpowiedzialny za aktualizację takiego słownika zostanie, już na etapie edycji poinformowany, o tym, czy wprowadzone przez niego zmiany są poprawne.
