Wprowadzenie
Tworzenie doskonałego modelu semantycznego to jedno z najważniejszych zadań, które analityk danych może wykonać w usłudze Microsoft Power BI. Dobre wykonanie tego zadania ułatwia użytkownikom zrozumienie danych, dzięki czemu będą oni mogli łatwiej tworzyć cenne raporty usługi Power BI dla siebie i dla Ciebie.
Strony w tym module są tylko instrukcjami, nie są udostępniane żadne pliki danych. Masz szansę pracować z rzeczywistymi danymi w laboratoriach.
Dobry model semantyczny oferuje następujące korzyści:
Eksploracja danych jest szybsza.
Tworzenie agregacji jest prostsze.
Raporty są dokładniejsze.
Pisanie raportów zabiera mniej czasu.
Raporty będą łatwiejsze do konserwacji w przyszłości.
Zapewnienie reguł zestawu dla tego, co sprawia, że dobry model semantyczny jest trudny, ponieważ wszystkie dane są różne, a użycie tych danych różni się. Ogólnie rzecz biorąc, mniejszy model semantyczny jest lepszy, ponieważ działa szybciej i będzie prostszy w użyciu. Jednak zdefiniowanie, co wiąże się z mniejszym modelem semantycznym, jest równie problematyczne, ponieważ jest to koncepcja heurystyczna i subiektywna.
Zazwyczaj mniejszy model semantyczny składa się z mniejszej liczby tabel i mniejszej liczby kolumn w każdej tabeli, którą widzi użytkownik. Jeśli zaimportujesz wszystkie niezbędne tabele z bazy danych sprzedaży, lecz łącznie będzie to 30 tabel, dla użytkownika nie będzie to intuicyjne. Zwijanie tych tabel w pięć tabel sprawia, że model semantyczny jest bardziej intuicyjny dla użytkownika, natomiast jeśli użytkownik otworzy tabelę i znajdzie 100 kolumn, może okazać się przytłaczające. Usunięcie niepotrzebnych kolumn w celu zapewnienia większej liczby możliwej do zarządzania zwiększa prawdopodobieństwo odczytu wszystkich nazw kolumn przez użytkownika. Podsumowując, należy dążyć do uproszczenia podczas projektowania modeli semantycznych.
Na poniższej ilustracji przedstawiono przykładowy model semantyczny. Pola zawierają tabele danych, gdzie każdy element wiersza w polu jest kolumną. Linie łączące pola reprezentują relacje między tabelami. Relacje te mogą być złożone nawet w przypadku takiego prostego modelu. Model semantyczny może stać się łatwo zdezorganizowany, a łączna liczba tabel w modelu może stopniowo rosnąć. Utrzymywanie prostego, kompleksowego i dokładnego modelu semantycznego wymaga stałego nakładu pracy.
Relacje między tabelami są definiowane przez klucze podstawowe i obce. Klucze podstawowe to kolumny, które identyfikują każdy unikatowy wiersz danych bez wartości null. Na przykład w przypadku tabeli Klienci może istnieć indeks, który identyfikuje każdego unikatowego klienta. Pierwszy wiersz ma identyfikator 1, drugi wiersz o identyfikatorze 2 itd. Każdemu wierszowi jest przypisana unikatowa wartość, którą można przywołać za pomocą tej prostej wartości: klucza podstawowego. Ten proces staje się ważny, gdy przywołujesz wiersze w innej tabeli, a to robią klucze obce. Relacje między tabelami są tworzone, gdy istnieją wspólne klucze podstawowy i obcy w różnych tabelach.
Usługa Power BI zezwala na tworzenie relacji między tabelami z różnymi źródłami danych. Jest to zaawansowana funkcja, która umożliwia ściągnięcie jednej tabeli z programu Microsoft Excel, a innej z relacyjnej bazy danych. Następnie utworzysz relację między tymi dwiema tabelami i traktujesz je jako ujednolicony model semantyczny.
Teraz, gdy znasz już relacje tworzące schemat danych, możesz zapoznać się z konkretnym typem projektu schematu, schematem star zoptymalizowanym pod kątem wysokiej wydajności i użyteczności.
Schematy gwiazdy
Możesz zaprojektować schemat gwiazdy, aby uprościć dane. Nie jest to jedyny sposób upraszczania danych, ale jest to popularna metoda. Dlatego każdy analityk danych usługi Power BI powinien ją rozumieć. W schemacie star każda tabela w modelu semantycznym jest definiowana jako wymiar lub tabela faktów, jak pokazano w poniższej wizualizacji.
Tabele faktów zawierają dane obserwacyjne lub zdarzeń: zamówienia sprzedaży, ilości produktów, ceny, daty i godziny transakcji oraz ilości. Tabele faktów mogą zawierać kilka powtórzonych wartości. Na przykład jeden produkt może występować wiele razy w wielu wierszach dla różnych klientów i dat. Te wartości można agregować w celu utworzenia wizualizacji. Na przykład wizualizacja łącznej liczby zamówień sprzedaży jest agregacją wszystkich zamówień sprzedaży w tabeli faktów. Tabele faktów często mają kolumny wypełnione liczbami i datami. Te liczby mogą być jednostkami miary, takimi jak kwota sprzedaży, lub kluczami takimi jak identyfikator klienta. Daty reprezentują zarejestrowany czas, na przykład datę zamówienia lub datę wysyłki.
Tabele wymiarów zawierają szczegóły dotyczące danych w tabelach faktów: produkty, lokalizacje, pracowników i typy zamówień. Te tabele są połączone z tabelą faktów za pomocą kolumn kluczy. Tabele wymiarów są używane do filtrowania i grupowania danych w tabelach faktów. Z drugiej strony tabele faktów zawierają dane mierzalne, takie jak sprzedaż i przychód, a każdy wiersz reprezentuje unikatową kombinację wartości z tabel wymiarów. W przypadku wizualizacji łącznej liczby zamówień sprzedaży można grupować dane, tak aby zobaczyć łączną liczbę zamówień sprzedaży według produktu, który jest reprezentowany przez dane w tabeli wymiarów.
Tabele faktów są znacznie większe niż tabele wymiarów, ponieważ wiele zdarzeń występuje w tabelach faktów, takich jak indywidualna sprzedaż. Tabele wymiarów są zwykle mniejsze, ponieważ są ograniczone do elementów, których można używać do filtrowania i grupowania. Na przykład rok zawiera tylko tyle miesięcy, a Stany Zjednoczone składają się tylko z określonej liczby stanów.
Biorąc pod uwagę te informacje dotyczące tabel faktów i tabel wymiarów, możesz zastanawiać się nad tym, jak utworzyć tę wizualizację w usłudze Power BI.
Odpowiednie dane znajdują się w dwóch tabelach Employee (Pracownik) i Sales (Sprzedaż), jak pokazano w poniższym modelu semantycznym. Ponieważ tabela Sales zawiera wartości zamówień sprzedaży, które mogą być agregowane, jest traktowana jako tabela faktów. Tabela Employee (Pracownik) zawiera imiona i nazwiska poszczególnych pracowników, na podstawie których są filtrowane zamówienia — a więc jest to tabela wymiarów. Kolumną wspólną dla obu tabel, stanowiącą klucz podstawowy w tabeli Employee, jest kolumna EmployeeID (Identyfikator pracownika), a więc można użyć tej kolumny do utworzenia relacji między tabelami.
Dzięki utworzeniu relacji można zbudować wizualizację zgodnie z wymaganiami, jak pokazano na poniższej ilustracji. Gdyby nie utworzono relacji, choć te dwie tabele mają elementy wspólne, znacznie trudniej byłoby zbudować wizualizację.
Schematy gwiazdy i podstawowy model semantyczny są podstawą zorganizowanych raportów; tym więcej czasu poświęcasz na tworzenie tych połączeń i projektowanie, tym łatwiej będzie tworzyć i obsługiwać raporty.