Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.04.2021

Lubelskie Dni Informatyki

Koło Naukowe Informatyków już po raz XIII zorganizuje Lubelskie Dni Informatyki.
07.04.2021

Bariery językowe przełamane

Cisco Webex
06.04.2021

Nowość w portfolio Bakotech

Progress Software
06.04.2021

Kontrola służbowych urządzeń

Hexnode MDM
02.04.2021

Red Hat Inc.

Firma Red Hat Inc. udostępniła Red Hat OpenShift 4.7 – najnowszą wersji czołowej...
02.04.2021

Rozpoznawanie twarzy

QNAP QVR
02.04.2021

Układy EPYC Serii 7003

Firma AMD zaprezentowała nowe wydajne procesory serwerowe, czyli układy EPYC Serii 7003,...
02.04.2021

Mobilna wydajność

Satellite Pro C50-G
01.04.2021

Nowa linia monitorów

AOC V4

Wzbogacanie modelu

Data publikacji: 01-04-2021 Autor: Marcin Szeliga

Do tej pory utworzyliśmy fakt z miarami i wymiary z atrybutami. Teraz dodamy do przykładowego modelu sprzedaży drugi fakt o innym poziomie szczegółowości, zdefiniujemy relację pomiędzy wymiarami i faktami oraz ułatwimy użytkownikom pracę z modelem, wzbogacając go o hierarchie, formatowanie i miary wyliczeniowe.

 

Bardzo rzadko model biznesowy zawiera pojedynczą tabelę faktów. Dodatkowe fakty albo opisują powiązane procesy biznesowe, albo ten sam proces, ale inaczej zamodelowany, na przykład na innym poziomie szczegółowości. Załóżmy, że do modelu chcemy dodać fakt opisujący kwartalne plany sprzedażowe.


> Dodatkowe fakty


Dane załadujemy z pliku SalesTarget.xlsx, który dostępny jest pod adresem bit.ly/3vG3wn4. Są one zapisane w formacie tabeli przestawnej i muszą zostać przygotowane, zanim załadujemy je do modelu. Po kliknięciu przycisku Przekształć dane należy:

 

  • zmienić nazwę zapytania na Target;
  • zaznaczyć kolumny Q1 do Q4 i z menu kontekstowego wybrać opcję Anuluj przestawienie kolumn. W ten sposób utworzymy dwie kolumny: jedną o nazwie Atrybut, zawierającą kwartały, i drugą o nazwie Wartość, w której zapisane będą plany sprzedażowe;
  • zmienić nazwę kolumny Atrybut na Quarter, a Wartość na TargetAmount.


Ten fakt można połączyć relacją z wymiarem Reseller, bo zawiera on klucz obcy Reseller ID. Chociaż należałoby go zastąpić kluczem sztucznym ResellerKey, to w wypadku tak małej tabeli faktów użycie klucza biznesowego jest dopuszczalne. Niestety fakt nie zawiera klucza obcego, który pozwoliłby na jego powiazanie relacją z wymiarem kalendarzowym. Musimy więc go wyliczyć:

 

  • po kliknięciu prawym przyciskiem myszy kolumny Quarter należy z menu kontekstowego wybrać opcję Zamień wartości i usunąć Q (zostawiamy pustą wartość);
  • typ kolumny możemy teraz zmienić na liczbę całkowitą.

 

Pozostało nam wyliczyć pierwszy dzień kwartału. Potrzebujemy danych na tym poziomie szczegółowości, bo kluczem wymiaru kalendarzowego jest dzień. Aby tego dokonać, należy:

 

  • dodać niestandardową kolumnę wyliczeniową, nazwąć ją DateKey i zdefiniować za pomocą następującego wyrażenia: ([Year] * 10000) + ((([Quarter] * 3) – 2) * 100) + 1;
  • zmienić typ kolumny na liczbę całkowitą;
  • usunąć kolumny Year i Quarter.

 

Teraz zamykamy okno edytora Power Query i zastosowujemy wprowadzone zmiany – fakt Target zostanie zaimportowany do modelu. Wszystkie pozostałe operacje przeprowadzimy w edytorach Power BI.

 

> Relacje

 

Po prawej stronie ekranu znajdują się trzy przyciski pozwalające przełączać się pomiędzy edytorami Power BI. Dolny (Model) wyświetla model w postaci diagramu, środkowy (Dane) pozwala wyświetlić zawartość wybranej tabeli, a górny (Raport) – tworzyć wizualizacje. Wzbogacanie modelu zaczniemy od zdefiniowania relacji, czego dokonuje się w widoku modelu. Efekty naszych prac będziemy sprawdzać, tworząc na bieżąco odpowiednie wizualizacje.


Relacje pozwalają filtrować wiersze powiązanych tabel. Na przykład automatycznie utworzona relacja pomiędzy wymiarem Reseller a faktem Sales powoduje, że jeśli do pierwszej strony raportu dodamy kolumnę SalesAmount i kolumnę BussinesType, zobaczymy wykres słupkowy pokazujący wartość sprzedaży dla poszczególnych kategorii. Warto zauważyć, że domyślnie kolumny liczbowe są sumowane, a więc wysokość słupków będzie reprezentowała sumę sprzedaży. Warto przy tym zwrócić uwagę na prawdopodobnie błędną wartość atrybutu BussinesType. Jeśli ta sama kategoria zapisana jest pod dwiema różnymi nazwami, wyniki analiz będą błędne. Jeśli jednak spróbujemy na wykresie umieścić sprzedawców (atrybut Salesperson) i miarę SalesAmount, każdy słupek wykresu będzie miał tę samą długość i pokaże całkowitą wartość sprzedaży, czyli 78 milionów. Wynika to z tego, że wymiar Salesperson nie jest powiązany relacją z faktem Sales.


Relacje wiele-do-wielu

 

W celu dodania brakującej relacji należy przełączyć się na widok modelu i przeciągnąć klucz główny wymiaru Salesperson (kolumnę EmployeeKey) na kolumnę klucza obcego EmployeeKey faktu Sales. Wyświetlone zostanie ostrzeżenie o próbie utworzenia relacji typu wiele–do–wielu. Relacja nie została utworzona automatycznie, gdyż klucz EmployeeKey zawiera duplikaty. Relacje typu wiele-do-wielu z reguły są wynikiem błędnych danych. Jednak czasami są zamierzone i prawidłowo reprezentują związek pomiędzy wymiarami i faktami. Na przykład konto może mieć wielu właścicieli, a ta sama osoba może posiadać wiele kont. W naszym wypadku ten sam sprzedawca może być przydzielony do różnych regionów, a więc jego dane powtarzają się tyle razy, w ilu regionach pracuje. W efekcie, choć mamy 18 sprzedawców, całkowita liczba sprzedawców pracujących we wszystkich regionach wynosi 39 (rys. 1).


Wymiary wielokrotnego stosowania

 

Ten sam wymiar może być używany w wielu różnych kontekstach do filtrowania tego samego faktu. Na przykład sprzedaż można analizować w kontekście daty złożenia zamówienia, daty wysyłki towaru oraz daty zapłaty. Zalecanym sposobem modelowania wymiarów wielokrotnego stosowania jest utworzenie kopii wymiaru i połączenie ich odpowiednimi relacjami z faktem. W ten sposób nie będziemy musieli aktywować dodatkowych relacji za pomocą funkcji DAX i – co ważniejsze – będziemy mogli odpowiednio nazwać kopie wymiaru i ich atrybuty. Tworzenie relacji zaczniemy od powiązania kolumny klucza podstawowego wymiaru kalendarzowego (DateKey) z kolumną klucza obcego DueDateKey faktu Sales. Ponieważ w ten sposób określiliśmy kontekst wymiaru jako datę zapłaty, należy zmienić jego nazwę na DueDate.

 

[...]

 

Pracownik naukowy Wyższej Szkoły Bankowej w Poznaniu Wydział Zamiejscowy w Chorzowie, jest autorem książek poświęconych analizie danych i posiada tytuł Microsoft Most Valuable Professional.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"