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



26.08.2021

Firma Fortinet rozszerzyła...

Firma Fortinet rozszerzyła ofertę o usługę FortiTrust, która dołączyła do innych usług...
26.08.2021

Aplikacje biznesowe

Ready_™ AppStore
26.08.2021

Automatyzacja chmur...

Integracja z Red Hat Ansible
26.08.2021

Backup kodu źródłowego

GitProtect.io dostępny na Github
26.08.2021

Wsparcie pracy hybrydowej

Zdalny SD WAN
26.08.2021

Nowy monitor Philips 498P9Z

Nowy monitor Philips 498P9Z to model wyposażony w 49-calowy, zakrzywiony panel VA o...
26.08.2021

Wytrzymały punkt dostępowy

D-Link DIS-2650AP
26.08.2021

Ekonomiczne dyski

SSD bez DRAM
26.08.2021

Petabajty pojemności

Serwery QNAP

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.

.

Transmisje online zapewnia: StreamOnline

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