Jeśli czytając ten tytuł widzisz przed oczami coś oprócz ptaków gniazdowników stojących w kolejce po lody rzemieślnicze, czy sceny otwarcia testamentu to może być temat dla Ciebie. Zaawansowany, ciekawy i dający nowe przestrzenie analizy w Tableau. LOD -Gwarantowany poziom Jedi.
Przypomnienie – czym są kalkulacje LOD
Kiedy dane wpadają do Tableau (i każdego innego narzędzia BI), podlegają specyficznemu procesowi. Najpierw Tableau rozdziela je na kolumny zawierające miary i wymiary. Miary to wszystko to, co da się dodać, pomnożyć i w jakikolwiek inny sposób wykorzystać w wyliczeniach. Wymiary to to, co te liczby charakteryzuje np. nazwa produkty, działu czy numer faktury. Kiedy z danych zaczynamy rysować obrazy, wymiary pojawiają się jako nagłówki np. nazwy kategorii. Natomiast liczby z wszystkich wierszy pasujących do danej kategorii są agregowane, najczęściej sumowane. Dzięki temu możemy narysować np. wykres słupkowy sprzedaży w poszczególnych kategoriach.
Ok. Tyle spraw oczywistych. Ważne w tym jest, że każdy wymiar rozbija nam obraz na elementy i one tworzą wspólnie poziom szczegółowości tego obrazu. A każda miara jest agregowana. I to co do zasady dokładnie jeden raz.
Widać tu dwa problemy:
- Po pierwsze możemy chcieć pokazać na wykresie liczby, bądź fragmenty wykresów na innym poziome szczegółowości niż ten którym dysponujemy. Przykładowo na mapie powiatów, wyświetlić wartość sprzedaży dla województw. Ten problem możemy rozwiązać za pomocą bazowych kalkulacji LOD.
Jeśli nie miałeś jeszcze do czynienia z kalkulacjami LOD – przed przeczytaniem dalszej części artykułu zajrzyj koniecznie do:
www.newdatalabs.com/kalkulacje-level-of-details-w-tableau/
- Możemy chcieć też skorzystać z dwóch agregacji. To mogłoby oznaczać choćby wyliczenie sumy sprzedaży w każdym z powiatów, a następnie średniej tych wartości na poziomie regionu. I o tym właśnie dziś opowiem, bo rzecz nie jest trywialna.
Zagnieżdżone LOD, czyli o czym właściwie mowa
Klasyczna kalkulacja LOD może wyglądać tak:
Albo tak:
Lub też tak:
Od czasu do czasu potrzebujemy jednak skorzystać z połączonych sił dwóch kalkulacji. Co może wyglądać na przykład tak:
W tym wypadku kalkulacja jest podwójna. Składa się z części wewnętrznej i zewnętrznej. Wewnętrzna
dorzuca do szczegółowości wykresu wymiar [Ship Mode]. Ponieważ na szczegółowość składają się tu już [Segment] i [Ship Mode] kalkulacja jej nie zmienia. W efekcie wylicza ona dla danego Segmentu i rodzaju dostawy sumę sprzedaży. Ciekawe rzeczy zaczynają się dziać, gdy dodajemy część zewnętrzną. Uchylamy bowiem założenie o pojedynczej agregacji. Otaczamy poprzednią kalkulację dopiskiem:
W efekcie tym razem ignorując wymiar [Ship Mode] wyliczamy średnią z wcześniej wyliczonych sum. Jest ona wyświetlana na poziomie samego Segmentu. W tabeli wprawdzie są i segment i rodzaj dostawy, ale tak skonstruowana kalkulacja oznacza, że dla każdego rodzaju dostawy w segmencie powtórzona jest ta sama liczba.
I chciałoby się powiedzieć: i tyle. Niestety drugi poziom kalkulacji oznacza też drugie dno.
Dziedziczenie szczegółowości, czyli drugie dno
Budowanie zagnieżdżonych kalkulacji LOD jest relatywnie łatwe, póki nie dotrzemy do takich danych hierarchicznych, w których wartości mogą się powtarzać. Najczęściej dotyczy to hierarchii geograficznej, ale nie zawsze. Co mam na myśli?
Jeśli analizujemy dane ze zbioru Sample Superstore, możemy skorzystać z hierarchii Region/ Stan/ Miasto. Każdy region zawiera kilka stanów, których nazwy się nie powtarzają. Natomiast nazwy miast mogą występować zarówno w różnych stanach, jak i w różnych regionach. W Polsce jest podobnie. Mamy niezliczone ilości Nowych Miast, Starych Wsi i aż 28 miejscowości o nazwie Ameryka, w tym jedną Północną.
Aby ułatwić analizę posłużę się wizualizację, która wygląda tak:
Na początku odpowiem na pytanie, jaka jest średnia wartość sprzedaży w stanach poszczególnych regionów. Mogę to napisać np. tak:
W wewnętrznej kalkulacji wyliczam sumy dla poszczególnych stanów. W zewnętrznej ustalam poziom szczegółowości na to, co na obrazku czyli stan i region, minus stan. Czyli dalej liczę na poziomie regionu i wyliczam średnią z wyników wewnętrznej kalkulacji. Jeśli sprawdzimy to w tabeli wszystko jest ok.
Sprawa komplikuje się znacząco, gdy przejdziemy na poziom stanu i miasta. By to pokazać będę pracować na tabeli zawierającej stany i miasta, już bez regionów. Kalkulacja może wyglądać np. tak:
Szybkie spojrzenie na tabelę z wynikami tej kalkulacji pokazuje, że coś się nie zgadza. Wartości średnich w podsumowaniach nie mają nic wspólnego z wynikami kalkulacji. Poprzednio niemal identyczna kalkulacja działała. Co się stało tym razem?
Otóż wewnętrzna kalkulacja zsumowała nam wyniki sprzedaży dla miast o danej nazwie. Jeśli więc Lafayette mamy zarówno w Indianie, jak i na Florydzie, sprzedaże które miały miejsce w obu tych miastach zostały zsumowane. Jak łatwo się domyślić podobnych powtórek jest mnóstwo. Dlatego średnie z kalkulacji wyszły znacznie wyższe od tych, w podsumowaniach dla poszczególnych stanów.
Problem można rozwiązać pisząc kalkulację tak, by jej wewnętrzna część uwzględniała nie tylko nazwę miasta, ale też to, w który stanie ono leży. Te samą kalkulację można napisać na kilka różnych sposobów, z różnymi kombinacjami FIXED, INCLUDE, EXCLUDE i wymiarów. I tu pojawia się temat dziedziczenia poziomu szczegółowości. Zasady są ty następujące:
Co to oznacza? Zakładając, że wciąż mamy do czynienia z tabelą zawierającą stany, miasta i sprzedaż przeanalizujmy kilka możliwych kalkulacji:
//TEST 1 – na zewnątrz
{EXCLUDE [[City]] :AVG({FIXED [[City]]: sum([Sales])})}
Tu mamy do czynienia z dziedziczeniem na zewnątrz. Wewnętrzna kalkulacja ma więc poziom miasta. Brak stanu. Wyniki z miast o tych samych nazwach zostaną dodane. To da nam złe wyniki.
//TEST 2 – na zewnątrz, EXCLUDE wyłącza miasto w zewnętrznej
{EXCLUDE [City] :AVG({FIXED [City], [State]: sum([Sales])})}
Tu nadal dziedziczenie przebiega na zewnątrz. Kalkulacja wewnętrzna ma takie wymiary jak potrzeba. Kalkulacja zewnętrzna dziedziczy szczegółowość, ale EXCLUDE „kasuje” z niej miasto i wynik będzie prawidłowy.
//TEST 3 – do środka, [State] z poziomu szczegółowości tabeli
{EXCLUDE [City] :AVG({INCLUDE [City]: sum([Sales])})}
Tym razem dziedziczenie przebiega do środka. Zewnętrzna kalkulacja wyłącza z poziomu szczegółowości wizualizacji miasto. Zostaje stan. I dobrze. Wewnętrzna do poziomu szczegółowości dorzuca miasto, a więc jest miasto i stan. Wszystko się zgadza i wynik będzie prawidłowy.
//TEST 4 – do środka
{FIXED [State] :AVG({INCLUDE [City]: sum([Sales])})}
Tu także mamy do czynienia z dziedziczeniem do środka. Stan z kalkulacji zewnętrznej jest dorzucany do wewnętrznej. Tu też wszystko się zgadza.
//TEST 5 – do środka
{FIXED [State] :AVG({INCLUDE [City], [State]: sum([Sales])})}
Ta kalkulacja również jest poprawna.
//TEST 6 – bez dziedziczenia, brak stanu w wewnętrznej kalkulacji
{FIXED [State] :AVG({FIXED [City]: sum([Sales])})}
Przy dwóch FIXED dziedziczenia nie ma. A więc w wewnętrznej kalkulacji brak stanu. To nie zadziała poprawnie.
//Test 7 – bez dziedziczenia
{FIXED [State] :AVG({FIXED [City], [State]: sum([Sales])})}
Za to – jak łatwo się domyśleć – przy braku dziedziczenia ta kalkulacja zadziała idealnie.
W tabeli wygląda to tak:
Puenta – jak zapamiętać zasady dziedziczenia LOD
Jak zapamiętać zasady dziedziczenia LOD? Ja mam na to swoją technikę. Dla mnie naturalny kierunek to od lewej do prawej i tak to działa przy samych INCLUDE i EXCLUDE. Poza tym kierunek zawsze ucieka od FIXED. Gdy FIXED jest na zewnątrz, biegnie do środka, gdy w środku – biegnie na zewnątrz. Gdy są same FIXED kierunki znoszą się i nie ma dziedziczenia.
O ile jednak nie planujecie zdawać egzaminu Tableau na poziomie Professional, czyli Tableau Certified Consultant, nie warto wkuwać tego na pamięć. Wystarczy zapamiętać, gdzie znaleźliście ten post i wracać do niego w razie potrzeby. Powiedzmy to sobie szczerze – nie korzysta się z tego często. To poziom Jedi. Jeśli jednak kilka razy spróbujecie, wiedza z Wami zostanie i na pewno będzie się przydawać. W przypadku, gdy staniesz przed podobnym problemem, to już wiesz, gdzie szukać wsparcia – sprawdź co jeszcze możemy dla Ciebie zrobić na www.newdatalabs.com
Agata Mężyńska, Tableau Desktop Certified Professional
