na przykładzie Pentaho DI część 6 I. Czyszczenie danych. Jednym z podstawowych zarzutów dotyczących skrótu ETL jest to, że wyjątkowo złożone transformacje występujące w procesach ETL obejmujące także, a może przede wszystkim, czyszczenie danych i ich ujednolicanie, objęte zostały tylko jedną z liter - T. W ramach bieżącego ćwiczenia zajmiemy się właśnie czyszczeniem danych. Generalnie procedury czyszczenia danych niekoniecznie muszą odbywać na drodze pomiędzy systemami źródłowymi a hurtownią danych. Bardzo często wynikają one z analizy jakościowej źródeł i dotyczą właśnie danych występujących w źródłach. Na początku, w ramach naszych ćwiczeń, zajmiemy się adresami pocztowymi. Przypomnijmy sobie zadanie polegające na uzupełnianiu wymiaru klienci w oparciu o stany i okręgi. Już wtedy pojawiły się sygnały, że coś z tymi danymi (a dokładnie z kodami pocztowymi i nazwami miast) jest nie tak. Do uzupełnienia informacji na temat stanów i okręgów wykorzystaliśmy zewnętrzne dane referencyjne pochodzące z www.geonames.org. Do weryfikacji danych adresowych i ewentualnej ich naprawy możemy skorzystać z tych samych danych. 1. Aby uzmysłowić sobie z jakimi problemami mamy do czynienia zbudujemy prostą transformację porównującą dane adresowe naszego pierwszego źródła danych shop1 z danymi referencyjnymi. a. Utwórzmy nową transformację, a następnie wstawmy do niej pierwszy krok Table input, którym będzie zapytanie wydobywające dane z tabeli adresy. Nazwę kroku ustawmy na Adresy - shop1. Dane posortujmy w celu ich późniejszego połączenia z danymi referencyjnymi. b. Dodajmy do naszej transformacji kolejny krok Table input, który będzie pobierał dane z naszej tabeli referencyjnej. Pamiętajmy o analogicznym sortowaniu. Nazwą tego kroku niech będzie geonames.org
c. W kolejnym kroku połączmy oba źródła danych za pomocą komponentu Merge Join i za pomocą własności tego komponentu zdefiniujmy następujący sposób tego połączenia. d. W celu dokonania krótkiej analizy problemu dołóżmy do naszej transformacji jeszcze trzy komponenty: 1 x Filter rows oraz 2 x Dummy (do nothing). Połączmy je analogicznie do rysunku poniżej: e. Warunek zdefiniowany w ramach komponentu Filter rows powinien mieć następującą postać: f. Jesteśmy przygotowani do analizy źródła shop1. Na komponencie Dummy (do nothing), do którego trafiają wiersze spełniające warunek selekcji wywołaj menu kontekstowe, a następnie wybierz opcję Preview. Wynik powinien być analogiczny do poniższego. g. Okazuje się, że problem nie jest duży (kilkanaście wierszy błędnych na ponad 550), nie chcemy go jednak bagatelizować. Dlatego postaramy się teraz oczyścić nasze dane przy pomocy danych referencyjnych.
2. To, że w danych referencyjnych nie jesteśmy w stanie znaleźć wiersza posiadającego ten sam kod pocztowy oraz tę samą nazwę miejscowości, może wynikać z kilku przyczyn. Mógł się pojawić błąd w kodzie pocztowym, mogła także zostać błędnie wprowadzona nazwa miejscowości. W najgorszym przypadku błędy mogły się pojawić w obu składowych. Najczęściej błędy tego typu mogą występować ze względu na pomyłkę podczas wprowadzania danych np. w wyniku tradycyjnej literówki. W takich przypadkach różnica pomiędzy wartością wprowadzoną a wartością poprawną nie powinna być duża. W naszej transformacji spróbujemy wychwycić takie drobne błędy i w takich przypadkach będziemy chcieli automatycznie poprawić zawartość źródła. a. Zanim rozpoczniemy dalsze działania zmienimy nazwę komponentu Dummy (do nothing), który przechwytuje błędne adresy na Adresy z problemami. b. Zaczniemy od znalezienia drobnych błędów w nazwach miast. W tym celu umieśćmy na naszej transformacji komponent Database lookup z katalogu Lookup. Połączmy go z krokiem Adresy z problemami. c. Wejdźmy do własności tego komponentu i określmy, że będzie on wyszukiwał w tabeli geonames_org wszystkie wiersze posiadające taki sam kod pocztowy jak ten, którego nie udało się nam znaleźć (porównując kod i nazwę miasta) d. We własnościach tego samego komponentu określmy, że do strumienia będziemy dokładali pole miasto_lookup, w którym umieszczone zostaną znalezione w ten sposób nazwy miast (może być ich wiele w przypadku, gdy kody nie będą unikalne). Określmy także wartość domyślną ***brak***. Taka wartość ma dwie zalety, po pierwsze łatwo ją zauważymy, po drugie będzie znacząco się różniła od innych.
e. Na zakończenie edycji własności zmieńmy jego nazwę na Szukaj miast. f. Aby wybrać ze znalezionych nazw miast to, które różni się w najmniejszym stopniu od oryginalnej (być może błędnej) nazwy miasta wykorzystamy świetnie nadający się do tego celu komponent Fuzzy match również z katalogu Lookup. Wejściem do tego komponent będzie wyjście z Szukaj miast oraz wyjście z na Adresy z problemami. Dodając wyjście z Szukaj miast określmy, że do elementu Fuzzy match będzie kierowany główny wynik. Natomiast dodając wyjście z Adresy z problemami zdefiniujmy że dane z Adresy z problemami mają być kopiowane i przesyłane do obu wynikowych komponentów. g. Przejdźmy do edycji własności komponentu Fuzzy match. Na zakładce General określmy krok, który jest krokiem lookup, oraz pole, które jest wynikiem jego działania. Podajemy także pole z głównego strumienia, do którego znalezione w kroku lookup wartości będą porównywane. h. Następnie zastanówmy się nad algorytmem znajdowania najlepszego dopasowania. Nazwy miast mogą mieć różne długości. Dlatego wykorzystanie odległości Livenshteina nie byłoby najlepsze. Dwie zmienione litery w 10 literowym słowie, nie znaczą to samo co w słowie składającym się z 3 liter, dlatego w tym kroku wykorzystamy Jaro Winkler. Daje on wyniki od 0 do 1, gdzie 1 oznacza największe podobieństwo a 0 najmniejsze. My będziemy zgadzali się na przekazywanie do dalszego działania przypadków, w których podobieństwo nie będzie mniejsze od 0.5.
i. Na zakładce Fields zmieńmy nazwy pól tworzonych przez ten krok na najblizsze_miasto oraz wynik_porownania_miasta. Na zakończenie edycji własności zmieńmy nazwę kroku na Znajdz miasto. Wywołajmy za pomocą menu kontekstowego podgląd wyniku transformacji. j. Przeanalizujmy uzyskane wyniki. W kilku przypadkach literówki są ewidentne i algorytm Jaro Winkler jednoznacznie to wykazał (wynik porównania równy 1). W przypadku wyniku porównania równego 0.9 również możemy zaryzykować automatyczną naprawę takich wartości. W pozostałych przypadkach będziemy starali się nasze problematyczne adresy przetwarzać w inny sposób. k. Aby odpowiednio pokierować dalszym przetwarzaniem naszego strumienia wierszy dodajmy jako kolejny krok komponent Filter rows. Przekierujmy do niego główny wynik ze Znajdz miasto. l. Przejdźmy do własności tego kroku i określmy warunek będący wynikiem wykonanej chwilę temu analizy. m. Jako nazwę kroku wprowadźmy blad w miasto, a następnie zamknijmy własności tego komponentu.
n. Wiersze, które będą spełniały przed chwilą zdefiniowany warunek będą wykorzystane do automatycznej naprawy naszego źródła danych poprzez modyfikację nazwy miasta. Dlatego dodajmy do naszej transformacji nowy komponent Update a na jego wejście niech będzie wyjście z filtra krotek obejmujące te krotki, które spełniają warunek filtra. o. Definiując własności nowego kroku naszej transformacji wskażmy tabelę, która będzie aktualizowana, warunek aktualizacji oraz pola, które będą aktualizowane. p. Nazwę komponentu zmieńmy na Popraw miasto. 3. W kolejnych krokach naszej transformacji powtórzymy naszą próbę naprawy automatycznej adresów poszukując drobnych usterek w kodach pocztowych. a. Dodajmy do naszej transformacji kolejny krok Dummy (do nothing). Pozwoli on nam rozwidlić strumień (tak jak to dokonywaliśmy już wcześniej w tej transformacji. Skierujmy na niego wyjście z kroku blad w miasto w zakresie krotek, których nazwy miasta nie powinniśmy automatycznie poprawiać. b. Podobnie jak w przypadku poszukiwaniu błędów w nazwach miast, tak i teraz dodajmy dwa komponenty z katalogu Lookup: Database lookup oraz Fuzzy match. Przekierujmy do obu kroków dane z dane z dodanego przed chwilą komponentu Dummy (do nothing) przy wykorzystaniu metody kopiowania danych.
c. Wejdźmy do edycji właściwości komponentu Database lookup. Ponownie wprowadźmy tabelę geonames_org jako źródło danych lookup, przy czym tym razem będziemy poszukiwali wierszy, które mają identyczną nazwę miasta. Wynikiem będzie znaleziony w ten sposób kod pocztowy. d. Zmieńmy nazwę komponentu Database lookup na Szukaj kodu. Zakończmy edycję jego własności, a następnie połączmy jego główne wyjście z wejściem komponentu Fuzzy match. e. Wejdźmy do własności komponentu Fuzzy match. Zmieńmy jego nazwę na Znajdz kod. Określmy wartości własności analogicznie jak to zrobiliśmy poprzednio pamiętając, że ty razem szukamy najbardziej dopasowanego kodu. W związku z tym, że kody pocztowe mają bardzo podobną długość możemy zaryzykować i wykorzystać odległość Levenshteina do wyznaczenia miary podobieństwa pomiędzy oryginalnym kodem a znalezionym na podstawie nazwy miasta. Maksymalna odległość jaką będziemy rozważali tym razem to 4 (co dla 5 literowego kodu jest bardzo dużą odległością). f. Na zakładce Fields określmy nazwy pól wynikowych porównania jako najblizszy_kod oraz wynik_porownania_kodu. Zamknij własności tego kroku.
g. Czas na filtr, który odróżni krotki, których aktualizację możemy wykonać automatycznie, od tych, które ostatecznie należy zgłosić do osób odpowiedzialnych za źródło celem ich ręcznej naprawy. Na wejście filtra skierujemy główny wynik kroku Znajdz kod. h. Warunek filtra będzie kwalifikował wiersze do automatycznej naprawy jeżeli odległość Levenshteina pomiędzy znalezionym kodem a istniejącym w źródle nie jest większa niż 2. i. Zmieńmy nazwę kroku filtra na Blad w kod. Następnie dołóżmy do naszej transformacji krok Update i skierujmy do niego krotki, które spełniają warunek filtra. j. Nazwę kroku Update zmieńmy na Popraw kod, a we własnościach zdefiniujmy właściwą poprawę źródłowego kodu pocztowego. k. Ostatnim krokiem będzie zapisanie w pliku tych adresów, które muszą być poprawione ręcznie, gdyż automatyczna poprawa nie jest możliwa nie można określić właściwego sposobu poprawy. Wstawmy do naszej transformacji krok Text file output, a następnie połączmy go z wynikiem kroku Blad w kod dotyczącym tych krotek, które nie spełniają warunku.
l. Wejdźmy do własności tego kroku. Na zakładce File wprowadźmy nazwę pliku /home/etl/results/adresy_do_poprawy oraz jego rozszerzenie txt. Na zakładce Fields przy wykorzystaniu przycisku Get Fields wprowadźmy wszystkie pola jakie znajdują się w przetwarzanym strumieniu. Powinny one być pomocne podczas aktualizacji źródłowej bazy danych. m. Na zakładce Content zaznaczmy dwie opcje n. Zmieńmy jeszcze nazwę tego kroku na Rejestracja blednych adresow i zamknijmy edycję własności teko kroku. o. Ostatecznie nasza transformacja powinna być podobna do poniższej: p. W związku z tym, że nasza transformacja ma odmienny typ od poprzednich utworzymy nowy katalog. Otwórzmy narzędzie Repository explorer i utwórzmy katalog /wypozyczalnie/data_cleaner.
q. Zapiszmy naszą transformację jako OczyszczanieAdresow-shop1 w nowoutworzonym katalogu /wypozyczalnie/data_cleaner. Czas na jej uruchomienie. r. Jak widać 7 adresów udało się poprawić ze względu na znalezione w nich problemy z nazwą miasta (kod był prawidłowy, a nazwa miasta pasowała do danych referencyjnych), 3 adresy zostały poprawione ze względu na błędny kod pocztowy. Jednego adres nie udało się naprawić automatycznie i trafił on ostatecznie do pliku z błędnymi adresami. s. Korzystając z przeglądarki plików otwórzmy wygenerowany plik. t. Jego zawartość podpowie nam jakie adresy powinniśmy poprawić w źródle danych. u. Z oczywistych powodów analogiczna naprawa kodów i nazw miejscowości powinna być dokonana również dla drugiego źródła. Możemy to zrobić na dwa sposoby: Możemy zapisać naszą transformację pod nazwą OczyszczanieAdresow-shop2 w tym samym katalogu co poprzednio, a następnie zmienić własność Connection (połączenie) komponentów takich jak Adresy shop, Popraw miasto oraz Popraw kod na shop2, ponadto należy błędne adresy, których nie uda się naprawić automatycznie umieścić w oddzielnym pliku np. /home/etl/results/adresy_do_poprawy2.txt albo Możemy poprawić tę transformację tak aby czytała adresy z obu źródeł odpowiednio oznaczając ich pochodzenie, a następnie dokonywała modyfikacji zależnych od pochodzenia Zaletą pierwszego wariantu jest jego mniejsza złożoność w stosunku do wariantu drugiego. Natomiast zaletą drugiego rozwiązania jest bardzo istotna łatwość pielęgnacji zmiany dla wariantu pierwszego musiałyby być wprowadzane w dwóch miejscach, podczas gdy w wariancie drugim mamy zawsze tylko jedno zadanie. Ponieważ nie planujemy zmian przetwarzania, wykorzystajmy pierwszy wariant.
Zapiszmy zatem naszą transformację jako OczyszczanieAdresow-shop2 w katalogu /wypozyczalnie/data_cleaner, dokonajmy stosownych poprawek (wspomnianych wyżej) a następnie, gdy transformacja będzie już gotowa zapiszmy ją jeszcze raz i uruchommy. Wynik powinien być jak poniżej. Jego podobieństwo do poprzedniego wyniku nie powinno nas dziwić wszak, w założeniach naszych ćwiczeń, dane pomiędzy źródłami były replikowane. 4. Wykorzystanie danych referencyjnych to jedna z metod wykorzystywanych do poprawy jakości danych źródłowych, czy też oczyszczania (lub uzupełniania) danych transformowanych w ramach procesów ETL. Takich metod jest oczywiście bardzo wiele. Jedną z prostszych jest weryfikacja poprawności formatu danych. Taka weryfikacja dobrze sprawdza się w przypadku adresów e-mail, numerów telefonów, numerów kart kredytowych itp. W tym krótkim poniższym ćwiczeniu sprawdzimy poprawność adresów email klientów z pierwszego źródła danych. a. Utwórzmy nową transformację. Pierwszym jej krokiem będzie zapytanie wydobywające adresy e-mail klientów, którzy je posiadają. b. Do analizy formatów, świetnie się nadają funkcje operujące na wyrażeniach regularnych. Jednak w przypadku Pentaho DI i analizy adresów email istnieje specjalizowany komponent. Jako drugi krok naszej transformacji wstawimy komponent Mail Validator z katalogu Validation. Połączmy go z krokiem poprzednim c. Wejdźmy do własności komponentu Mail Validator. Wskażmy pole zawierające adres e-mail podlegający weryfikacji. d. Analizując pozostałe własności tego komponentu możemy stwierdzić, że analiza poprawności adresu e-mail wykracza poza prostą analizę formatu. My jednak nie będziemy z tego korzystali. Zamknijmy własności.
e. Dołóżmy jeszcze trzy komponenty pozwalające zignorować poprawne adresy email oraz zarejestrować błędne ich wystąpienia. f. We własnościach filtru określmy warunek g. We własnościach komponentu Text file output. określmy nazwę pliku wynikowego jako: /home/etl/results/email_do_poprawy oraz rozszerzenie txt. Na zakładce Content ponownie zaznaczmy dwie opcje h. Na zakładce Fields wprowadźmy pola strumienia przy pomocy przycisku Get Fields. i. Zapiszmy w katalogu /wypozyczalnie/data_cleaner naszą transformację jako AnalizaAdresowEmail, a następnie ją uruchommy. Wynik jako poniżej świadczy to tym, że wszystkie adresy spełniają reguły walidacji. j. Aby to sprawdzić otwórzmy przeglądarkę i zalogujmy się do phpmyadmin jako użytkownik shop1 z hasłem shop1, a następnie wyświetlmy naszych klientów.
k. A następnie dokonajmy małych modyfikacji. W jednym z adresów nazwę domeny skróćmy do jednego członu. W drugim adresie skasujmy znak @. l. Ponownie uruchommy naszą transformację. Tym razem wynik świadczy o tym, że nie wszystko jest w porządku. m. Otwórzmy plik z wykrytymi problemami. Jak widać oba adresy zostały wyłapane jako niewłaściwie zbudowane. n. Wróćmy do źródła danych i przywróćmy oryginalne wartości adresów e-mail.
5. Skoro nasze źródła uległy zmianie poprawiliśmy jakość naszych źródeł, dokonamy odświeżenia naszej hurtowni danych. Zanim to jednak zrobimy zintegrujemy wykonane ostatnio zadania z głównym zadaniem odpowiedzialnym za odświeżanie hurtowni. a. Na początku przypomnijmy sobie co udało się nam wykonać ostatnio. W tym celu uruchommy narzędzie Repository explorer. Na zakładce Browse wybierzmy katalog /wypozyczalnie/ext->dwh. b. A zatem, utworzyliśmy ostatnio LadowanieStanowKrajow oraz LadowanieFilmow. Oba zadania powinny być uruchamiane po załadowaniu nowej porcji danych pochodzących ze źródeł shop1 i shop2. Otwórzmy zatem zadanie OdswiezDWH z katalogu /wypozyczalnie/shop->dwh. c. W związku z tym, że po wszystkich znajdujących się tam transformacjach chcielibyśmy wywołać wspomniane wcześniej dwa zadania dołóżmy z katalogu General dwa komponenty Job, a następnie przesuńmy komponent Success jak na rysunku poniżej.
d. Wejdźmy do własności pierwszego z komponentów Job i wskażmy, że będzie się on odnosił do zadania LadowanieStanowOkregow z katalogu /wypozyczalnie/ext->dwh. e. Wejdźmy do własności drugiego z komponentów Job i wskażmy, że będzie się on odnosił do zadania LadowanieFilmow z katalogu /wypozyczalnie/ext->dwh. f. Zamknijmy własności a następnie przeciągnijmy LadowanieStanowOkregow na połączenie pomiędzy ZaladujFakty a Success. g. Gdy pojawi się pytanie, czy wybrane połączenie ma być rozdzielone przesuniętym na nie komponentem odpowiedzmy Yes.
h. W sposób analogiczny umieśćmy LadowanieFilmow pomiędzy LadowanieStanowOkregow a Success. Ostatecznie ustawmy względem siebie nasze komponenty i zapiszmy nasz OdswiezODH. i. Możemy teraz uruchomić procedurę odświeżenia całej hurtowni danych. II. Slowly Changing Dimension. Powróćmy teraz pamięcią do procedur ETL, które zasilają wymiary naszej hurtowni danych. W chwili obecnej zasilanie wymiarów, a w szczególności wymiaru klienci (bo nim się w tym ćwiczeniu zajmiemy) w bardzo prosty sposób rozwiązuje problem zmieniających się wartości atrybutów wymiarów. Każda zmiana w danych źródłowych propagowana jest do hurtowni danych nadpisując poprzednie wartości, a tym samym zmieniając historię. Przykładowo, to co kiedyś było uwzględniane w kontekście miasta Nowy York (bo tam było miejsce zamieszkania jednego z naszych klientów) teraz może być uwzględniane w kontekście miasta Los Angeles (bo tam ostatnio przeprowadził się nasz klient). Wg Ralpha Kimballa ten sposób postępowania ze zmianami w wymiarach to SCD typu 1. Takie postępowanie nie zawsze jest do zaakceptowania zmiany danych historycznych w niektórych przypadkach mogą prowadzić do błędnych wniosków. Dlatego teraz zajmiemy się tym problemem w naszej transformacji dotyczącej wymiaru klienci zmieniając SCD typu 1 na SCD typu 2, który zachowuje historię wartości wymiaru. 6. Na początku zaobserwujmy rzeczywiste zmiany w danych dotyczących wymiarów. a. Uruchommy kolejną procedurę symulującą upływ czasu w naszych źródłach. Otwórzmy w tym celu terminal b. Przejdźmy do katalogu labs za pomocą polecenia cd labs.
c. Następnie uruchommy następujące polecenie./zasilanie3.sh. Dane z kolejnego okresu trafią do naszych źródeł. d. Procedura upływu czasu może trochę potrwać, dlatego my nie czekając na jej zaskoczenie zaimportujemy do Pentaho DI transformację, która pokaże nam fakt zmienionych danych. W tym celu w Pentaho DI za pomocą menu File->Import from an XML file zaimportujmy plik /home/etl/labs/zmienioneadresy.ktr. e. Zaimportowana transformacja pobiera dane dotyczące klientów z hurtowni danych oraz ze źródła shop1 łączy je na podstawie identyfikatora klienta, a następnie odfiltrowuje tych klientów, u których adres (ulica) uległ zmianie. f. Zanim przejdziemy dalej upewnijmy się, że upływ czasu się zakończył. g. Aby zobaczyć zmienione dane zaznaczmy komponent Adres zmieniony, a następnie wywołajmy prawym klawiszem jego menu kontekstowe, wybierzmy pozycję Preview. Przycisk Quick Lauch pozwoli nam uruchomić potrzebne działania. Jak widać, zmian nie ma dużo, jednak mimo wszystko nie chcemy ich zignorować. h. Zamknijmy tę pomocniczą transformację nie zapisując jej.
7. Przejdźmy do zmiany naszej transformacji związanej z wymiarem klienci. a. Otwórzmy transformację ZaladujKlientow z katalogu /wypozyczalnie/shop->dwh w naszym repozytorium. Przypomnijmy sobie jaki komponent dokonuje ostatecznej aktualizacji tabeli reprezentującej wymiar klienci. Jest nim Insert/Update, który dodaje nowych klientów i ewentualnie aktualizuje już istniejących o ile pojawią się jakieś zmiany. b. Zanim zaczniemy modyfikację naszej transformacji przypomnijmy sobie najważniejsze informacje dotyczące SCD typu 2. Pozwala on na przechowywanie historii poprzednich wartości instancji elementu wymiaru w kolejnych wierszach. W efekcie tego tzw. klucz biznesowy odpowiadający za identyfikację instancji elementu wymiaru przestaje być unikalny (instancja elementu posiada wiele wierszy odnoszących się do różnych wersji) i konieczne jest wprowadzenie nowego klucza sztucznego (surrogate key). Ponadto tabela wymiaru uzupełniana jest zazwyczaj o dodatkową kolumnę, która przechowuje dla każdego elementu wymiaru numer jego wersji oraz dwie kolumny przechowujące datę rozpoczęcia i zakończenia obowiązywania wersji. c. Ta zmiana sposobu obsługi wymiaru będzie wymagała stosownych modyfikacji w schemacie hurtowni danych. Jest to o tyle trudniejsze, że w naszej hurtowni znajdują się już dane. Wykonamy stosowne zmiany wykorzystując narzędzie SQL Plus. Uruchommy je wykorzystując menu startowe. d. Połączmy się jako właściciel schematu hurtowni danych: connect dwh@xe/dwh
e. Na początku utwórzmy w tabeli KLIENCI nową kolumnę, która będzie ostatecznie pełniła rolę sztucznego klucza głównego (surrogate key) alter table KLIENCI add KL_KLIENT_SID NUMBER(10); f. Klucz ten będziemy aktualizowali w oparciu o naturalną w przypadku bazy danych Oracle sekwencję. Dlatego w kolejnym poleceniu ją utworzymy create sequence SEQ_KLIENT_SID; g. Dokonamy aktualizacji wartości nowej kolumny w oparciu o stworzoną sekwencję update KLIENCI set KL_KLIENT_SID = SEQ_KLIENT_SID.nextval; h. W kolejnym kroku uzupełnimy naszą tabelę o kolumnę przechowującą numery kolejnych wersji naszych klientów alter table KLIENCI add KL_KLIENT_VER NUMBER(5) DEFAULT 1; i. Pozostały nam jeszcze do utworzenia dwie kolumny wyznaczające okres obowiązywania wersji elementu wymiaru. alter table KLIENCI add KL_START_VER TIMESTAMP(6); alter table KLIENCI add KL_STOP_VER TIMESTAMP(6); j. Ustawmy wartość rozpoczynającą obowiązywanie obecnej wersji danych. update KLIENCI set KL_START_VER = timestamp '1900-01-01 00:00:00';
k. Ustawmy wartość kończącą obowiązywanie obecnej wersji danych. update KLIENCI set KL_STOP_VER = timestamp '2199-12-31 23:59:59'; l. Czas na zmianę klucza głównego. Na początku skasujemy istniejący klucz główny włącznie z kluczem obcym w tabeli faktów. alter table KLIENCI drop primary key cascade; m. Utwórzmy klucz główny na nowododanym sztucznym identyfikatorze. alter table KLIENCI add primary key(kl_klient_sid); n. Dokonajmy stosownej aktualizacji wartości atrybutu WY_KLIENT_ID w tabeli faktów WYPOZYCZENIA. update WYPOZYCZENIA set WY_KLIENT_ID = (select KL_KLIENT_SID from KLIENCI where KL_KLIENT_ID = WY_KLIENT_ID); o. A następnie zmieńmy wartość atrybutu WY_KLIENT_ID na WY_KLIENT_SID i utwórzmy nowy klucz obcy odpowiadający rzeczywistej zależności pomiędzy tabelą faktów i wymiarów. alter table WYPOZYCZENIA rename column WY_KLIENT_ID to WY_KLIENT_SID; alter table WYPOZYCZENIA add foreign key(wy_klient_sid) references KLIENCI(KL_KLIENT_SID);
p. Na zakończenie działań w SQL*Plus dołóżmy jeszcze techniczny wiersz do tabeli wymiaru jest on wymagany przez komponent, z którego za chwilę skorzystamy (w przypadku gdyby go nie było byłby on wstawiany automatycznie przez komponent, a to prowadziłoby do wystąpienia błędu podczas transformacji ze względu na obowiązkowość pól wymiaru klienci. insert into KLIENCI(KL_KLIENT_ID, KL_KOD_POCZTOWY, KL_MIASTO, KL_IMIE, KL_NAZWISKO, KL_EMAIL, KL_ULICA, KL_OSTATNIA_MODYFIKACJA, KL_KLIENT_SID, KL_KLIENT_VER, KL_START_VER, KL_STOP_VER ) values (0,'****','****', '****','****','****', '****', TIMESTAMP '2000-01-01 00:00:00', 0, 1, TIMESTAMP '2000-01-01 00:00:00', TIMESTAMP '2000-01-01 00:00:00'); q. Nie zapomnijmy zatwierdzić naszej ostatniej zmiany. commit; r. Po powyższych zmianach przygotowujących schemat hurtowni na SCD typu 2 możemy przystąpić do aktualizacji naszych transformacji. Wróćmy do transformacji ZaladujKlientow. Usuńmy ostatni z komponentów transformacji Aktualizuj klientów komponent typu Insert/Update. W jego miejsce wstawmy komponent idealnie nadający się do SCD typu 2 komponent Dimension lookup/update z katalogu Data Warehouse. s. Niestety komponent ten wymaga (w wykorzystywanej przez nas wersji) aby pola w strumieniu, które do niego trafiają miały dokładnie takie same nazwy jak te, które będą w kolumnach docelowej tabeli. Dlatego wstawmy pomiędzy komponent Wyszukaj adres a Dimension lookup/update komponent Select values z katalogu Transform.
t. Otwórzmy własności komponentu Select values. Na początku zmieńmy jego nazwę na Dostosowanie nazw pol. Następnie na zakładce Select & Alter za pomocą przycisku Get fields to select wprowadź do sekcji Fields pola ze strumienia wejściowego. Usuń z niego pole ktory_sklep, a dla pozostałych pól zdefiniuj nowe nazwy jak poniżej. Zwróć uwagę na nazwę pola KL_ULICA, która różni się znacząco od nazwy oryginalnego pola. u. Zakończmy edycję własności dla Dostosowanie nazw pol i otwórzmy własności komponentu Dimension lookup/update. Na początku sprawdźmy czy pole wyboru Update the dimension jest zaznaczone dzięki temu komponent ten będzie spełniał swoje zadanie będzie aktualizował wymiar. Następnie wybierzmy połączenie i tabelę, która będzie podlegała aktualizacji. v. Na zakładce Keys wskażmy klucz biznesowy pozwalający na identyfikację tych samych instancji elementu wymiaru. w. Następnie wskażmy atrybut tabeli pełniący rolę sztucznego klucza głównego (Technical key field). Jeśli nie jest on dostępny na liście wyboru, zamknij własności tego komponentu, następnie z menu Tools narzędzia wybierz opcję Database->Clear cache, po czym powróć do własności dodanego komponentu.
x. Jako źródło dla sztucznego klucza głównego wskażmy utworzoną specjalnie do tego celu sekwencję SEQ_KLIENT_SID. y. Ustawmy także własności dotyczące kolumny zawierającej numery wersji, pole strumienia informujące o dacie modyfikacji, a także kolumny przechowujące informacje o okresie obowiązywania wersji danych. z. Przejdźmy na zakładkę Fields i korzystając z przycisku Get Fields, który znajduje się na dole okna własności, wstawmy pary odpowiadających sobie kolumn i pól strumienia. aa. Zamknijmy edycję własności komponentu. I zapiszmy naszą transformację. bb. W celu jej przetestowania dokonajmy jej uruchomienia.
8. Z oczywistych względów rewolucja w sposobie utrzymania wymiaru klienci powinna mieć swoje odzwierciedlenie podczas ładowania tabeli faktów. a. Otwórzmy transformację ZaladujFakty z katalogu /wypozyczalnie/shop->dwh w naszym repozytorium. b. W chwili obecnej transformacja ta zupełnie nie zajmuje się identyfikatorem klienta. Wynika to z faktu, iż oryginalny klucz biznesowy pochodzący ze źródeł trafiał do hurtowni danych w niezmienionej postaci. Teraz to się zmieniło. Dlatego dokonamy małej modyfikacji. c. Komponent, który wykorzystaliśmy przy transformacji ZaladujKlientow - Dimension lookup/update posiada w rzeczywistości dwie funkcjonalność. Pierwszą z nich update już wykorzystaliśmy, teraz wykorzystamy drugą lookup. Dołóżmy zatem do transformacji ZaladujFakty komponent Dimension lookup/update z katalogu Data Warehouse. Umieśćmy go w ramach naszej transformacji tuż przed ostatnim jej krokiem. d. Wejdźmy do jego własności. Na samym początku zdefiniujmy połączenie oraz nazwę tabeli, z której nasz nowy identyfikator klienta będziemy pobierali. e. Następnie ustawmy właściwą wartość dla pola Version field. f. Odznaczmy Update the dimension ze względu na sposób użycia naszego komponentu w ramach tej transformacji.
g. Na zakładce Keys określmy warunek identyfikujący instancję elementu wymiaru klienci h. Podobnie jak to było poprzednio, wskażmy atrybuty dotyczące sztucznego klucza głównego tego wymiaru (w tym, w szczególności, nazwę pola w strumieniu, który zostanie przez ten komponent utworzone klient_sid), pochodzenia jego wartości, a także atrybutów związanych z zakresem obowiązywania wersji instancji elementu wymiaru. i. Przejdźmy na zakładkę Fields. Tym razem zakładka ta pozwoliłaby nam zdefiniować jakie to dodatkowe atrybuty ze źródłowej tabeli wymiaru odpowiadające przetwarzanemu składnikowi faktów chcemy wydobyć. W naszym przypadku wystarczającym dodatkowym składnikiem strumienia będzie, wcześniej wspomniane, pole klient_sid, dlatego niczego dodatkowego na tej zakładce nie dodajemy. j. Na zakończenie edycji właściwości tego komponentu zmieńmy jego nazwę na Okresl id klienta.
k. Pozostaje nam uwzględnić uzyskany w ten sposób sztuczny identyfikator klienta podczas ostatecznego ładowania danych do tabeli faktów. Otwórzmy własności komponentu Zapisz fakty. Przejdźmy na zakładkę Database fields. I zamieńmy wpis dotyczący kolumny WY_KLIENT_ID na właściwy dotyczący nowej kolumny WY_KLIENT_SID. => l. Zamknijmy edycję własności komponentu Zapisz fakty i zapiszmy zmienioną transformację. m. Pozostaje nam już tylko ją uruchomić.