Klasyczne podejście projektowania procesów ETL, 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 powyższe zalety przestają przynosić korzyści wówczas, gdy poziom skomplikowania procesów zaczyna znacząco rosnąć. Wówczas 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 takie 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ć?
Niejednokrotnie pisałem już 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 tychże procesów do zmieniającego się otoczenia biznesowego. W swojej wieloletniej praktyce zdobytej przy realizacji projektów związanych z budową hurtowni danych czy też 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 – na przykład 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 takiego 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 to ma jakiś większy sens?
Odpowiedź będzie brzmiała: „zdecydowanie tak”, jeżeli do zarządzania takim słownikiem użyjemy Metastudio DRM. Dlaczego? Mianowicie 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, wówczas 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.
Dzięki powyższemu możliwe będzie udostępnienia takiego słownika do utrzymania przez użytkowników biznesowych, 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, czy wprowadzone przez niego zmiany są poprawne.
Mówiąc o walidacji składni, być może zainteresuje Cię przetwarzanie danych, które odgrywa kluczową rolę w procesie ETL. Natomiast warto zapoznać się również z narzędziami ETL, które mogą ułatwić i usprawnić analizę oraz przesyłanie danych.
