W poprzednim artykule mówiłem o podstawach DATA VAULT, opisałem główne elementy DATA VAULT i ich przeznaczenie. Nie można tego uważać za wyczerpany temat DATA VAULT, należy porozmawiać o kolejnych krokach w ewolucji DATA VAULT.
I w tym artykule skupię się na rozwoju DATA VAULT i przejściu na BUSINESS DATA VAULT lub po prostu BUSINESS VAULT.
Powody pojawienia się BIZNESOWEJ DANYCH VAULT
Należy zauważyć, że DATA VAULT, choć ma pewne mocne strony, nie jest pozbawiony wad. Jedną z tych wad jest trudność w pisaniu zapytań analitycznych. Zapytania mają znaczną liczbę JOIN, kod jest długi i uciążliwy. Również dane wchodzące do DATA VAULT nie podlegają żadnym przekształceniom, zatem z biznesowego punktu widzenia DATA VAULT w czystej postaci nie ma wartości bezwzględnej.
Chcąc wyeliminować te niedociągnięcia, metodykę DATA VAULT rozszerzono o takie elementy jak:
- Tabele PIT (punkt w czasie);
- stoły BRIDGE;
- PREDEFINIOWANE WYCHODY.
Przyjrzyjmy się bliżej celowi tych elementów.
Tabele PIT
Zwykle jeden podmiot gospodarczy (HUB) może zawierać dane z różną częstotliwością aktualizacji, przykładowo jeśli mówimy o danych charakteryzujących osobę, to możemy powiedzieć, że informacja o numerze telefonu, adresie czy adresie e-mail ma wyższą częstotliwość aktualizacji niż powiedzmy, imię i nazwisko, dane paszportowe, stan cywilny lub płeć.
Dlatego przy ustalaniu satelitów należy mieć na uwadze częstotliwość ich aktualizacji. Dlaczego to jest ważne?
Jeśli w tej samej tabeli przechowujesz atrybuty o różnej częstotliwości aktualizacji, będziesz musiał dodać wiersz do tabeli za każdym razem, gdy aktualizowany będzie najczęściej zmieniany atrybut. Efektem jest zwiększenie przestrzeni dyskowej i wydłużenie czasu wykonania zapytania.
Teraz, gdy podzieliliśmy satelity według częstotliwości aktualizacji i możemy niezależnie wczytywać do nich dane, powinniśmy zadbać o to, aby móc otrzymywać aktualne dane. Lepiej, bez użycia niepotrzebnych złączeń.
Wyjaśnię np., że trzeba pozyskiwać aktualne (wg daty ostatniej aktualizacji) informacje z satelitów, które mają różną częstotliwość aktualizacji. Aby to zrobić, będziesz musiał nie tylko wykonać JOIN, ale także utworzyć kilka zagnieżdżonych zapytań (dla każdego satelity zawierającego informacje) z wyborem maksymalnej daty aktualizacji MAX (data aktualizacji). Z każdym nowym JOIN taki kod rośnie i bardzo szybko staje się trudny do zrozumienia.
Tablica PIT ma na celu uproszczenie tego typu zapytań, wypełnianie tabel PIT odbywa się jednocześnie z zapisywaniem nowych danych do SKLEPU DANYCH. Tabela PIT:
Dzięki temu mamy informację o istotności danych dla wszystkich satelitów w każdym momencie. Stosując JOIN do tabeli PIT możemy całkowicie wyeliminować zapytania zagnieżdżone, oczywiście pod warunkiem, że PIT będzie wypełniany codziennie i bez luk. Nawet jeśli w PIT-ie są luki, najnowsze dane można uzyskać tylko za pomocą jednego zagnieżdżonego zapytania do samego PIT-u. Jedno zagnieżdżone zapytanie będzie przetwarzane szybciej niż zagnieżdżone zapytania do każdego satelity.
BRIDGE
Tabele BRIDGE służą również do uproszczenia zapytań analitycznych. Jednak to, co różni się od PIT, to sposób na uproszczenie i przyspieszenie żądań pomiędzy różnymi węzłami, łączami i ich satelitami.
Tabela zawiera wszystkie niezbędne klucze dla wszystkich satelitów, które są często używane w zapytaniach. Dodatkowo, w razie potrzeby, zaszyfrowane klucze biznesowe można uzupełnić kluczami w formie tekstowej, jeśli do analizy potrzebne są nazwy kluczy.
Faktem jest, że bez użycia BRIDGE, w procesie odbioru danych znajdujących się na satelitach należących do różnych hubów, konieczne będzie wykonanie JOIN nie tylko samych satelitów, ale także łączy łączących huby.
O obecności lub braku BRIDGE decyduje konfiguracja pamięci i potrzeba optymalizacji szybkości wykonywania zapytań. Trudno o uniwersalny przykład BRIGE.
PREDEFINIOWANE WYCHODY
Innym rodzajem obiektów przybliżających nas do BIZNESOWEJ DATA VAULT są tabele zawierające wstępnie wyliczone wskaźniki. Tabele takie są bardzo ważne w biznesie, zawierają informacje zagregowane według zadanych reguł i sprawiają, że dostęp do nich jest stosunkowo łatwy.
Architektonicznie PREDEFINIOWANE POCHODY to nic innego jak kolejny satelita określonego koncentratora. Zawiera on, podobnie jak zwykły satelita, klucz biznesowy oraz datę utworzenia zapisu w satelicie. Na tym jednak podobieństwa się kończą. Dalszy skład atrybutów takiego „specjalistycznego” satelity określany jest przez użytkowników biznesowych w oparciu o najpopularniejsze, wstępnie obliczone wskaźniki.
Przykładowo hub zawierający informacje o pracowniku może zawierać satelitę ze wskaźnikami takimi jak:
- Płaca minimalna;
- Maksymalne wynagrodzenie;
- Średnia wypłata;
- Łączna suma naliczonych wynagrodzeń itp.
Logiczne jest uwzględnienie PREDEFINIOWANYCH WYLICZEN w tabeli PIT tego samego huba, wtedy można łatwo uzyskać wycinki danych dla pracownika w specjalnie wybranym dniu.
WNIOSKI
Jak pokazuje praktyka, korzystanie z DATA VAULT przez użytkowników biznesowych jest dość trudne z kilku powodów:
- Kod zapytania jest złożony i uciążliwy;
- Obfitość połączeń JOIN wpływa na wydajność zapytań;
- Pisanie zapytań analitycznych wymaga wyjątkowej wiedzy z zakresu projektowania pamięci masowych.
Aby ułatwić dostęp do danych, DATA VAULT został rozszerzony o dodatkowe obiekty:
- Tabele PIT (punkt w czasie);
- stoły BRIDGE;
- PREDEFINIOWANE WYCHODY.
Następny Mam zamiar opowiedzieć, moim zdaniem, najciekawszą rzecz 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:
- Na Kenta Graziano, która oprócz szczegółowego opisu zawiera schematy modelowe;
- Książka: „Budowa skalowalnej hurtowni danych z DATA VAULT 2.0”;
- Artykuł .
Źródło: www.habr.com