W poprzednim artykule opisałem podstawy DATA VAULT, omówiłem główne elementy DATA VAULT i ich przeznaczenie. To jednak nie wyczerpuje tematu DATA VAULT, należy porozmawiać o następnych etapach ewolucji DATA VAULT.
W tym artykule skoncentruję się na rozwoju DATA VAULT i przejściu do BUSINESS DATA VAULT, czyli po prostu BUSINESS VAULT.
Przyczyny powstania BUSINESS DATA VAULT
Należy zauważyć, że DATA VAULT, mimo swoich mocnych stron, ma także słabości. Jedną z takich słabości jest trudność w pisaniu zapytań analitycznych. Zapytania mają znaczną liczbę JOIN’ów, a kod staje się długi i nieczytelny. Dane, które trafiają do DATA VAULT, nie są poddawane żadnym transformacjom, dlatego z perspektywy biznesowej DATA VAULT w czystej postaci nie ma bezwarunkowej wartości.
Właśnie w celu wyeliminowania tych słabości metodologia DATA VAULT została rozszerzona o takie elementy jak:
- tabele PIT (punkt w czasie);
- tabele BRIDGE;
- ZAAWANSOWANE ODPOWIEDNIO.
Przyjrzyjmy się bliżej przeznaczeniu tych elementów.
Tabele PIT
Zazwyczaj jeden obiekt biznesowy (HUB) może zawierać dane o różnej częstotliwości aktualizacji, na przykład, jeśli mówimy o danych charakteryzujących osobę, możemy powiedzieć, że informacje o numerze telefonu, adresie czy e-mailu mają wyższą częstotliwość aktualizacji niż, powiedzmy, nazwisko, dane paszportowe, stan cywilny lub płeć.
Dlatego, przy określaniu satelitów, warto uwzględnić częstotliwość ich aktualizacji. Dlaczego to jest ważne?
Jeśli w jednej tabeli przechowujemy atrybuty o różnej częstotliwości aktualizacji, będziemy musieli dodać wiersz do tabeli przy każdej aktualizacji najczęściej zmienianego atrybutu. W konsekwencji nastąpi wzrost objętości przestrzeni dyskowej oraz wydłużenie czasu wykonania zapytań.
Teraz, gdy podzieliliśmy satelity według częstotliwości aktualizacji i możemy ładować do nich dane niezależnie, należy zapewnić możliwość uzyskania aktualnych danych. Lepiej, bez zbędnych JOIN’ów.
Przykładowo, konieczne jest uzyskanie aktualnych (na podstawie daty ostatniej aktualizacji) informacji z satelitów o różnej częstotliwości aktualizacji. W tym celu trzeba nie tylko wykonać JOIN, ale także stworzyć kilka zagnieżdżonych zapytań (do każdego satelity zawierającego informacje) z wyborem maksymalnej daty aktualizacji MAX(Data aktualizacji). Z każdym nowym JOIN-em taki kod się rozrasta i bardzo szybko staje się trudny do zrozumienia.
Tabela PIT ma na celu uproszczenie takich zapytań, tabele PIT są wypełniane równocześnie z zapisaniem nowych danych w DATA VAULT. Tabela PIT:
W ten sposób mamy informacje o aktualności danych we wszystkich satelitach w każdym momencie. Używając JOIN-ów do tabeli PIT, możemy całkowicie wykluczyć zagnieżdżone zapytania, oczywiście pod warunkiem, że PIT jest wypełniana codziennie i bez przerw. Nawet jeśli występują przerwy w PIT, można uzyskać aktualne dane tylko używając jednego zagnieżdżonego zapytania do samego PIT-u. Jedno zagnieżdżone zapytanie wykona się szybciej niż zagnieżdżone zapytania do każdego satelity.
BRIDGE
Tabele typu BRIDGE są również używane do uproszczenia zapytań analitycznych. Jednak w odróżnieniu od PIT mają na celu uproszczenie i przyspieszenie zapytań między różnymi hubami, linkami i ich satelitami.
Tabela zawiera wszystkie niezbędne klucze dla wszystkich satelitów, które są często używane w zapytaniach. Ponadto, w razie potrzeby, haszowane klucze biznesowe mogą być uzupełniane kluczami w formie tekstowej, jeśli nazwy kluczy są potrzebne do analizy.
Faktem jest, że bez użycia BRIDGE, w procesie uzyskiwania danych z satelitów należących do różnych hubów, konieczne będzie wykonanie JOIN nie tylko samych satelitów, ale także linków łączących huby.
Obecność lub brak BRIDGE zależy od konfiguracji magazynu, potrzeby optymalizacji prędkości wykonywania zapytań. Trudno wymyślić uniwersalny przykład BRIDGE.
PREDEFINED DERIVATIONS
Innym typem obiektów, który przybliża nas do BUSINESS DATA VAULT, są tabele zawierające wcześniej obliczone wskaźniki. Tego typu tabele są naprawdę ważne dla biznesu, zawierają informacje zebrane według określonych zasad i pozwalają na stosunkowo prosty dostęp do nich.
Architektoniczne PREDEFINED DERIVATIONS to nic innego jak kolejny satelita określonego hubu. Zawiera on, podobnie jak zwykły satelita, klucz biznesowy i datę utworzenia wpisu w satelicie. Na tym jednak kończą się podobieństwa. Dalszy skład atrybutów takiego „specjalizowanego” satelity jest określany przez użytkowników biznesowych na podstawie najbardziej pożądanych, wstępnie obliczonych wskaźników.
Na przykład, hub zawierający informacje o pracowniku może zawierać satelitę z takimi wskaźnikami jak:
- Minimalne wynagrodzenie;
- Maksymalne wynagrodzenie;
- Średnie wynagrodzenie;
- Suma naliczonego wynagrodzenia itd.
Logiczne jest włączenie PREDEFINED DERIVATIONS do tabeli PIT tego samego hubu, dzięki czemu można bez trudu uzyskać dane dotyczące pracownika na konkretną datę.
WNIOSEK
Jak pokazuje praktyka, korzystanie z DATA VAULT przez użytkowników biznesowych jest nieco trudne z kilku powodów:
- Kod zapytań jest skomplikowany i rozbudowany;
- Obfitość JOIN-ów wpływa na wydajność zapytań;
- Do pisania zapytań analitycznych wymagana jest znakomita znajomość struktury magazynu.
Aby uprościć dostęp do danych, DATA VAULT jest rozszerzane o dodatkowe obiekty:
- tabele PIT (punkt w czasie);
- tabele BRIDGE;
- ZAAWANSOWANE ODPOWIEDNIO.
W następnej Zamierzam opowiedzieć, moim zdaniem, o najciekawszych aspektach dla tych, którzy pracują z BI. Przedstawię sposoby tworzenia tabel faktów i tabel wymiarów w oparciu o DATA VAULT.
Materiały artykułu opierają się:
- Na Kenta Grazziano, w której oprócz szczegółowego opisu znajdują się schematy modelu;
- Na książce: „Building a Scalable Data Warehouse with DATA VAULT 2.0”;
- Artykuł .
Źródło: habr.com
