Udostępnij za pośrednictwem

Omówienie schematu gwiazdy i znaczenia usługi Power BI

  • Artykuł

Ten artykuł jest przeznaczony dla osób modelujących dane programu Power BI Desktop. Opisuje on projekt schematu gwiazdy i jego znaczenie dla opracowywania modeli semantycznych usługi Power BI zoptymalizowanych pod kątem wydajności i użyteczności.

Ważne

Semantyczne modele usługi Power BI zależą od dodatku Power Query do importowania lub nawiązywania połączenia z danymi. Oznacza to, że musisz użyć dodatku Power Query , aby przekształcić i przygotować dane źródłowe, co może być trudne, jeśli masz duże ilości danych lub musisz zaimplementować zaawansowane pojęcia, takie jak powolne zmienianie wymiarów (opisane w dalszej części tego artykułu).

Po wystąpieniu tych wyzwań zalecamy najpierw opracowanie procesów magazynu danych i wyodrębniania, przekształcania i ładowania (ETL) w celu okresowego ładowania magazynu danych. Model semantyczny może następnie nawiązać połączenie z magazynem danych. Aby uzyskać więcej informacji, zobacz Modelowanie wymiarowe w usłudze Microsoft Fabric Warehouse.

Napiwek

Ten artykuł nie jest przeznaczony do zapewnienia pełnej dyskusji na temat projektowania schematu gwiazdy. Aby uzyskać więcej informacji, zapoznaj się bezpośrednio z powszechnie opublikowaną zawartością, na przykład The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (trzeci wydanie, 2013) autorstwa Ralph Kimball i innych.

Omówienie schematu gwiazdy

Schemat gwiazdy to dojrzałe podejście do modelowania powszechnie stosowane przez magazyny danych relacyjnych. Wymaga to, aby modeliści sklasyfikowali swoje tabele modelu jako wymiar lub fakt.

  • Tabele wymiarów opisują jednostki biznesowe — elementy , które modelujesz. Jednostki mogą obejmować produkty, osoby, miejsca i pojęcia, w tym czas. Najbardziej spójną tabelą, którą znajdziesz w schemacie gwiazdy, jest tabela wymiarów dat. Tabela wymiarów zawiera kolumnę klucza (lub kolumny), która działa jako unikatowy identyfikator i inne kolumny. Inne kolumny obsługują filtrowanie i grupowanie danych.
  • Tabele faktów przechowują obserwacje lub zdarzenia i mogą być zamówieniami sprzedaży, saldami zapasów, kursami wymiany, temperaturami i nie tylko. Tabela faktów zawiera kolumny kluczy wymiarów, które odnoszą się do tabel wymiarów i kolumn miar liczbowych. Kolumny klucza wymiaru określają wymiarowość tabeli faktów, podczas gdy wartości klucza wymiaru określają stopień szczegółowości tabeli faktów. Rozważmy na przykład tabelę faktów przeznaczoną do przechowywania celów sprzedaży, która ma dwie kolumny kluczy wymiarów Date i ProductKey. Łatwo zrozumieć, że tabela ma dwa wymiary. Nie można jednak określić stopnia szczegółowości bez uwzględniania wartości klucza wymiaru. W tym przykładzie należy wziąć pod uwagę, że wartości przechowywane w Date kolumnie są pierwszym dniem każdego miesiąca. W tym przypadku stopień szczegółowości jest na poziomie produktu miesięcznego.

Ogólnie rzecz biorąc, tabele wymiarów zawierają stosunkowo małą liczbę wierszy. Tabele faktów, z drugiej strony, mogą zawierać dużą liczbę wierszy i nadal rosnąć wraz z upływem czasu.

Diagram przedstawiający ilustrację schematu gwiazdy.

Normalizacja a denormalizacja

Aby zrozumieć niektóre pojęcia schematu gwiazdy opisane w tym artykule, ważne jest, aby znać dwa terminy: normalizację i denormalizację.

Normalizacja to termin używany do opisywania danych przechowywanych w sposób, który zmniejsza repetytucyjne dane. Rozważ tabelę produktów, która zawiera unikatową kolumnę wartości klucza, taką jak klucz produktu, oraz inne kolumny opisujące cechy produktu, takie jak nazwa produktu, kategoria, kolor i rozmiar. Tabela sprzedaży jest uważana za znormalizowaną, gdy przechowuje tylko klucze, takie jak klucz produktu. Na poniższej ilustracji zwróć uwagę, że tylko kolumna ProductKey rejestruje produkt.

Diagram przedstawiający tabelę danych zawierającą kolumnę Klucz produktu.

Jeśli jednak tabela sprzedaży przechowuje szczegóły produktu poza kluczem, jest uważana za zdenormalizowaną. Na poniższej ilustracji zwróć uwagę, że ProductKey kolumny i inne kolumny związane z produktem rejestrują produkt.

Diagram przedstawiający tabelę danych zawierającą klucz produktu i inne kolumny związane z produktem, w tym Kategoria, Kolor i Rozmiar.

W przypadku źródła danych z pliku eksportu lub wyodrębniania danych prawdopodobnie reprezentuje on zdenormalizowany zestaw danych. W tym przypadku użyj dodatku Power Query , aby przekształcić i ukształtować dane źródłowe w wiele znormalizowanych tabel.

Jak opisano w tym artykule, należy dążyć do opracowania zoptymalizowanych modeli semantycznych usługi Power BI z tabelami reprezentującymi znormalizowane dane faktów i wymiarów. Istnieje jednak jeden wyjątek, w którym wymiar płatka śniegu może zostać zdenormalizowany w celu utworzenia pojedynczej tabeli modelu.

Znaczenie schematu gwiazdy dla modeli semantycznych usługi Power BI

Projekt schematu gwiazdy i wiele powiązanych pojęć wprowadzonych w tym artykule jest bardzo istotne w przypadku tworzenia modeli usługi Power BI zoptymalizowanych pod kątem wydajności i użyteczności.

Należy wziąć pod uwagę, że każda wizualizacja raportu usługi Power BI generuje zapytanie wysyłane do modelu semantycznego usługi Power BI. Ogólnie rzecz biorąc, zapytania filtruj, grupuj i podsumowują dane modelu. Dobrze zaprojektowany model to taki, który udostępnia tabele do filtrowania i grupowania oraz tabele do podsumowania. Ten projekt dobrze pasuje do zasad schematu gwiazdy:

  • Tabele wymiarów umożliwiają filtrowanie i grupowanie.
  • Tabele faktów umożliwiają podsumowywanie.

Nie ma właściwości tabeli, która modeluje, aby ustawić typ tabeli jako wymiar lub fakt. Jest on w rzeczywistości określany przez relacje modelu. Relacja modelu ustanawia ścieżkę propagacji filtru między dwiema tabelami i jest to właściwość kardynalności relacji, która określa typ tabeli. Typowa kardynalność relacji to jeden do wielu lub jego odwrotność wiele do jednego. Strona "jeden" jest zawsze tabelą wymiarów, a strona "wiele" jest zawsze tabelą faktów.

Diagram przedstawiający koncepcyjną ilustrację schematu gwiazdy.

Dobrze ustrukturyzowany projekt modelu obejmuje tabele wymiarów lub tabele faktów. Unikaj łączenia dwóch typów ze sobą dla pojedynczej tabeli. Zalecamy również staranie się zapewnić odpowiednią liczbę tabel z odpowiednimi relacjami. Ważne jest również, aby tabele faktów zawsze ładowały dane ze spójnym ziarnem.

Na koniec ważne jest, aby zrozumieć, że optymalny projekt modelu jest częścią nauki i sztuki częściowej. Czasami można zerwać z dobrymi wskazówkami, gdy ma to sens.

Istnieje wiele pojęć związanych z projektem schematu gwiazdy, które można zastosować do modelu semantycznego usługi Power BI. Te pojęcia obejmują:

Miary

W projekcie schematu gwiazdy miara jest kolumną tabeli faktów, która przechowuje wartości do podsumowania. W modelu semantycznym usługi Power BI miara ma inną , ale podobną definicję. Model obsługuje zarówno miary jawne, jak i niejawne.

  • Jawne miary są tworzone jawnie i są oparte na formule napisanej w języku DAX (Data Analysis Expressions), która umożliwia podsumowanie. Wyrażenia miar często używają funkcji agregacji języka DAX, takich jak SUM, MIN, MAX, AVERAGEi innych, aby wygenerować wynik wartości skalarnej w czasie zapytania (wartości nigdy nie są przechowywane w modelu). Wyrażenie miary może zawierać zakres od prostych agregacji kolumn po bardziej zaawansowane formuły, które zastępują kontekst filtru i/lub propagację relacji. Aby uzyskać więcej informacji, przeczytaj temat Podstawy języka DAX w programie Power BI Desktop.
  • Miary niejawne to kolumny, które można podsumować za pomocą wizualizacji raportu lub pytań i pytań. Oferują one wygodę dla Ciebie jako dewelopera modelu, ponieważ w wielu przypadkach nie trzeba tworzyć (jawnych) miar. Na przykład kolumna sprzedaży Sales Amount odsprzedawcy firmy Adventure Works może być podsumowana na wiele sposobów (suma, liczba, średnia, mediana, minimalna, maksymalna i inne) bez konieczności tworzenia miary dla każdego możliwego typu agregacji.

W okienku Dane jawne miary są reprezentowane przez ikonę kalkulatora, podczas gdy miary niejawne są reprezentowane przez symbol sigma (∑).

Diagram przedstawiający ikony znalezione w okienku Dane.

Istnieją jednak trzy przekonujące powody, dla których można tworzyć miary, nawet w przypadku prostych podsumowań na poziomie kolumny:

  • Jeśli wiesz, że autorzy raportów będą wykonywać zapytania dotyczące modelu semantycznego przy użyciu wielowymiarowych wyrażeń (MDX), model musi zawierać jawne miary. Dzieje się tak, ponieważ rozwiązanie MDX nie może uzyskać podsumowania wartości kolumn. W szczególności funkcja MDX jest używana podczas wykonywania funkcji Analizuj w programie Excel , ponieważ tabele przestawne wystawiają zapytania MDX.

  • Jeśli wiesz, że autorzy raportów będą tworzyć raporty podzielone na strony usługi Power BI przy użyciu projektanta zapytań MDX, model semantyczny musi zawierać jawne miary. Tylko projektant zapytań MDX obsługuje agregacje serwera. Dlatego jeśli autorzy raportów muszą mieć miary oceniane przez usługę Power BI (zamiast przez aparat raportów podzielonych na strony), muszą użyć projektanta zapytań MDX.

  • Jeśli chcesz kontrolować sposób, w jaki autorzy raportów podsumowują kolumny w określony sposób. Na przykład można podsumować kolumnę sprzedaży odsprzedawcy Unit Price (która reprezentuje stawkę jednostkową), ale tylko przy użyciu określonych funkcji agregacji. Nigdy nie należy sumować, ale należy je podsumować przy użyciu innych funkcji agregacji, takich jak minimalna, maksymalna lub średnia. W tym przypadku modeler może ukryć kolumnę Unit Price i utworzyć miary dla wszystkich odpowiednich funkcji agregacji.

    Takie podejście projektowe dobrze sprawdza się w przypadku raportów utworzonych w usługa Power BI i w przypadku pytań i pytań. Jednak połączenia na żywo programu Power BI Desktop umożliwiają autorom raportów wyświetlanie ukrytych pól w okienku Dane, co może spowodować obejście tego podejścia projektowego.

Klucze zastępcze

Klucz zastępczy jest unikatowym identyfikatorem dodanym do tabeli w celu obsługi modelowania schematu gwiazdy. Zgodnie z definicją nie jest ona zdefiniowana ani przechowywana w danych źródłowych. Często klucze zastępcze są dodawane do tabel wymiarów magazynu danych relacyjnych w celu udostępnienia unikatowego identyfikatora dla każdego wiersza tabeli wymiarów.

Semantyczne relacje modelu usługi Power BI są oparte na jednej unikatowej kolumnie w jednej tabeli, która propaguje filtry do jednej kolumny w innej tabeli. Jeśli tabela wymiarów w modelu semantycznym nie zawiera jednej unikatowej kolumny, należy dodać unikatowy identyfikator, aby stać się "jedną" stroną relacji. W programie Power BI Desktop możesz osiągnąć to wymaganie, dodając kolumnę indeksu Power Query.

Diagram przedstawiający polecenie Utwórz kolumnę indeksu w Edytor Power Query.

Należy scalić to zapytanie z zapytaniem po stronie "wiele", aby można było również dodać do niej kolumnę indeksu. Podczas ładowania tych zapytań do modelu semantycznego można utworzyć relację jeden do wielu między tabelami modelu.

Wymiary płatka śniegu

Wymiar płatka śniegu to zestaw znormalizowanych tabel dla pojedynczej jednostki biznesowej. Na przykład firma Adventure Works klasyfikuje produkty według kategorii i podkategorii. Produkty są przypisywane do podkategorii, a podkategorie są z kolei przypisywane do kategorii. W magazynie danych relacyjnych firmy Adventure Works wymiar produktu jest znormalizowany i przechowywany w trzech powiązanych tabelach: DimProductCategory, DimProductSubcategoryi DimProduct.

Diagram przedstawiający przykład diagramu płatka śniegu składającego się z trzech powiązanych tabel.

Jeśli używasz wyobraźni, możesz na zdjęciu znormalizowane tabele umieszczone na zewnątrz z tabeli faktów, tworząc projekt płatka śniegu.

Diagram przedstawiający koncepcyjny przykład diagramu płatka śniegu składającego się z trzech powiązanych tabel.

W programie Power BI Desktop możesz naśladować projekt wymiaru płatka śniegu (na przykład dlatego, że dane źródłowe działają) lub połączyć tabele źródłowe w celu utworzenia pojedynczej, zdenormalizowanej tabeli modelu. Ogólnie rzecz biorąc, korzyści wynikające z pojedynczej tabeli modelu przewyższają korzyści wynikające z wielu tabel modelu. Najbardziej optymalna decyzja może zależeć od ilości danych i wymagań dotyczących użyteczności modelu.

Gdy zdecydujesz się naśladować projekt wymiaru płatka śniegu:

  • Usługa Power BI ładuje więcej tabel, co jest mniej wydajne z perspektywy magazynu i wydajności. Te tabele muszą zawierać kolumny do obsługi relacji modelu i mogą spowodować większy rozmiar modelu.
  • Należy przejść przez dłuższe łańcuchy propagacji filtrów relacji, co może być mniej wydajne niż filtry stosowane do pojedynczej tabeli.
  • Okienko Dane zawiera więcej tabel modelu dla autorów raportów, co może spowodować mniej intuicyjne środowisko, zwłaszcza gdy tabele wymiarów płatka śniegu zawierają tylko jedną lub dwie kolumny.
  • Nie można utworzyć hierarchii składającej się z kolumn z więcej niż jednej tabeli.

Po wybraniu integracji z jedną tabelą modelu można również zdefiniować hierarchię obejmującą najwyższe i najniższe ziarno wymiaru. Prawdopodobnie magazyn nadmiarowych zdenormalizowanych danych może spowodować zwiększenie rozmiaru magazynu modelu, szczególnie w przypadku dużych tabel wymiarów.

Diagram przedstawiający przykład hierarchii w tabeli wymiarów, która zawiera kolumny takie jak Category (Kategoria), Subcategory (Podkategoria) i Product (Produkt).

Powolne zmienianie wymiarów

Wolno zmieniający się wymiar (lub SCD) to taki, który odpowiednio zarządza zmianą elementów członkowskich wymiaru w czasie. Ma zastosowanie, gdy wartości jednostek biznesowych zmieniają się powoli w czasie w sposób nieplanowany. Dobrym przykładem scD jest wymiar klienta, ponieważ jego kolumny szczegółów kontaktu, takie jak adres e-mail i numer telefonu, zmieniają się rzadko. Z kolei niektóre wymiary są uważane za szybko zmieniające się, gdy atrybut wymiaru zmienia się często, jak cena rynkowa akcji. Typowym podejściem projektowym w tych wystąpieniach jest przechowywanie szybko zmieniających się wartości atrybutów w mierze tabeli faktów.

Teoria projektowania schematu gwiazdy odnosi się do dwóch typowych typów SCD: Typ 1 i Typ 2. Tabela wymiarów może mieć typ 1 lub typ 2 lub obsługiwać oba typy jednocześnie dla różnych kolumn.

Typ 1 SCD

Typ 1 SCD zawsze odzwierciedla najnowsze wartości, a po wykryciu zmian w danych źródłowych dane tabeli wymiarów są zastępowane. Takie podejście projektowe jest typowe w przypadku kolumn, które przechowują dodatkowe wartości, takie jak adres e-mail lub numer telefonu klienta. Gdy zmieni się adres e-mail klienta lub numer telefonu, tabela wymiarów aktualizuje wiersz klienta nowymi wartościami. To tak, jakby klient zawsze miał te informacje kontaktowe.

Diagram przedstawiający przykład wolno zmieniającego się typu wymiaru 1, na którym jest aktualizowany numer telefonu pracownika.

Odświeżanie nieskrementalne tabeli wymiarów modelu usługi Power BI daje wynik typu 1 SCD. Odświeża dane tabeli, aby upewnić się, że są ładowane najnowsze wartości.

Typ 2 SCD

Typ 2 SCD obsługuje przechowywanie wersji elementów członkowskich wymiaru. Jeśli system źródłowy nie przechowuje wersji, zazwyczaj jest to proces ładowania magazynu danych, który wykrywa zmiany i odpowiednio zarządza zmianami w tabeli wymiarów. W takim przypadku tabela wymiarów musi użyć klucza zastępczego, aby zapewnić unikatowe odwołanie do wersji elementu członkowskiego wymiaru. Zawiera również kolumny definiujące ważność zakresu dat wersji (na przykład StartDate i EndDate) oraz kolumnę flagi (na przykład IsCurrent), aby łatwo filtrować według bieżących elementów członkowskich wymiaru.

Na przykład firma Adventure Works przypisuje każdego sprzedawcy do regionu sprzedaży. Gdy sprzedawca przenosi region, należy utworzyć nową wersję sprzedawcy, aby upewnić się, że fakty historyczne pozostają skojarzone z poprzednim regionem. Aby zapewnić dokładną analizę historyczną sprzedaży według sprzedawcy, tabela wymiarów musi przechowywać wersje sprzedawców i skojarzonych z nimi regionów. Tabela powinna również zawierać wartości daty rozpoczęcia i zakończenia, aby zdefiniować ważność czasu. Bieżące wersje mogą definiować pustą datę zakończenia (lub 12/31/9999), która wskazuje, że wiersz jest bieżącą wersją. Tabela musi również mieć klucz zastępczy, ponieważ klucz biznesowy (w tym przypadku identyfikator pracownika) nie będzie unikatowy.

Diagram przedstawiający przykład wolno zmieniającego się typu wymiaru 2, w którym region sprzedaży pracownika jest aktualizowany przez utworzenie nowej wersji.

Ważne jest, aby zrozumieć, że gdy dane źródłowe nie przechowują wersji, należy użyć systemu pośredniego (takiego jak magazyn danych), aby wykrywać i przechowywać zmiany. Proces ładowania tabeli musi zachowywać istniejące dane i wykrywać zmiany. Po wykryciu zmiany proces ładowania tabeli musi wygasnąć bieżącą wersję. Rejestruje te zmiany, aktualizując EndDate wartość i wstawiając nową wersję z StartDate wartością rozpoczynającą się od poprzedniej EndDate wartości. Ponadto powiązane fakty muszą używać wyszukiwania opartego na czasie, aby pobrać wartość klucza wymiaru odpowiedniego dla daty faktów. Semantyczny model usługi Power BI używa dodatku Power Query i nie może wygenerować tego wyniku. Może jednak ładować dane ze wstępnie załadowanej tabeli wymiarów SCD Type 2.

Napiwek

Aby dowiedzieć się, jak zaimplementować tabelę wymiarów SCD typu 2 w magazynie sieci szkieletowej, zobacz Zarządzanie zmianami historycznymi.

Semantyczny model usługi Power BI powinien obsługiwać wykonywanie zapytań dotyczących danych historycznych dla elementu członkowskiego, niezależnie od zmiany i wersji elementu członkowskiego, która reprezentuje określony stan elementu członkowskiego w czasie. W kontekście firmy Adventure Works ten projekt umożliwia wykonywanie zapytań dotyczących sprzedawcy niezależnie od przypisanego regionu sprzedaży lub dla określonej wersji sprzedawcy.

Aby osiągnąć to wymaganie, tabela wymiarów semantycznego modelu usługi Power BI musi zawierać kolumnę do filtrowania sprzedawcy oraz inną kolumnę do filtrowania określonej wersji sprzedawcy. Ważne jest, aby kolumna wersji zawiera niejednoznaczny opis, taki jak David Campbell (12/15/2008-06/26/2019) lub David Campbell (06/27/2019-Current). Ważne jest również, aby edukować autorów raportów i konsumentów o podstawach typu SCD Type 2 i sposobie osiągnięcia odpowiednich projektów raportów przez zastosowanie poprawnych filtrów.

Dobrym rozwiązaniem jest uwzględnienie hierarchii, która umożliwia przechodzenie do szczegółów wizualizacji na poziomie wersji.

Diagram przedstawiający okienko Dane z kolumnami Salesperson (Sprzedawca) i Salesperson Version (Wersja sprzedawcy).

Wymiary związane z pełnieniem ról

Wymiar odgrywający rolę to wymiar, który może filtrować powiązane fakty inaczej. Na przykład w firmie Adventure Works tabela wymiarów daty zawiera trzy relacje z faktami sprzedaży odsprzedawcy. Ta sama tabela wymiarów może służyć do filtrowania faktów według daty zamówienia, daty wysyłki lub daty dostawy.

Diagram przedstawiający koncepcyjny przykład pojedynczego wymiaru i relacji odgrywających rolę. Tabela Date (Data) zawiera dwie relacje z tabelą faktów dla daty zamówienia i daty wysyłki.

W magazynie danych zaakceptowane podejście projektowe polega na zdefiniowaniu pojedynczej tabeli wymiarów daty. W czasie zapytania "rola" wymiaru daty jest określana przez kolumnę faktów używaną do łączenia tabel. Na przykład podczas analizowania sprzedaży według daty zamówienia sprzężenie tabeli jest powiązane z kolumną data zamówienia sprzedaży odsprzedawcy.

W modelu semantycznym usługi Power BI ten projekt można naśladować, tworząc wiele relacji między dwiema tabelami. W przykładzie Adventure Works tabele daty i odsprzedawcy będą miały trzy relacje.

Diagram przedstawiający przykład jednego wymiaru i relacji odgrywających rolę. Tabela Date (Data) zawiera trzy relacje z tabelą faktów.

Chociaż ten projekt jest możliwy, może istnieć tylko jedna aktywna relacja między dwiema semantycznymi tabelami modelu usługi Power BI. Wszystkie pozostałe relacje muszą być ustawione na nieaktywne. Posiadanie jednej aktywnej relacji oznacza, że istnieje domyślna propagacja filtru od daty do sprzedaży odsprzedawcy. W tym przypadku aktywna relacja jest ustawiona na najbardziej typowy filtr używany przez raporty, który w firmie Adventure Works jest relacją daty zamówienia.

Jedynym sposobem użycia nieaktywnej relacji jest zdefiniowanie wyrażenia języka DAX używającego funkcji USERELATIONSHIP . W naszym przykładzie deweloper modelu musi utworzyć miary, aby umożliwić analizę sprzedaży odsprzedawcy według daty wysyłki i daty dostawy. Ta praca może być żmudna, zwłaszcza gdy tabela odsprzedawcy definiuje wiele miar. Tworzy również zaśmiecone okienko Dane , które ma nadmiarowe miary. Istnieją również inne ograniczenia:

  • Gdy autorzy raportów korzystają z podsumowania kolumn, a nie definiowania miar, nie mogą osiągnąć podsumowania dla nieaktywnych relacji bez konieczności pisania miary na poziomie raportu. Miary na poziomie raportu można definiować tylko podczas tworzenia raportów w programie Power BI Desktop.
  • W przypadku tylko jednej aktywnej ścieżki relacji między datą a sprzedażą odsprzedawcy nie można jednocześnie filtrować sprzedaży odsprzedawców według różnych typów dat. Na przykład nie można utworzyć wizualizacji, która wykreśli sprzedaż daty zamówienia według wysłanej sprzedaży.

Aby przezwyciężyć te ograniczenia, powszechną techniką modelowania usługi Power BI jest utworzenie tabeli wymiarów dla każdego wystąpienia odgrywającego rolę. Każdą tabelę wymiarów można utworzyć jako zapytanie odwołujące się do dodatku Power Query lub tabelę obliczeniową przy użyciu języka DAX. Model może zawierać tabelę Date , tabelę Ship Date i tabelę Delivery Date , z których każda ma jedną i aktywną relację z odpowiednimi kolumnami tabeli sprzedaży odsprzedawcy.

Diagram przedstawiający przykład wymiarów i relacji odgrywających rolę. Istnieją trzy różne tabele wymiarów dat powiązane z tabelą faktów.

Takie podejście projektowe nie wymaga zdefiniowania wielu miar dla różnych ról daty i umożliwia jednoczesne filtrowanie według różnych ról dat. Niewielka cena do zapłaty przy użyciu tego podejścia projektowego polega jednak na duplikowaniu tabeli wymiarów daty, co spowoduje zwiększenie rozmiaru magazynu modelu. Ponieważ tabele wymiarów zwykle przechowują mniej wierszy względem tabel faktów, rzadko jest to problemem.

Zalecamy stosowanie dobrych rozwiązań projektowych podczas tworzenia tabel wymiarów modelu dla każdej roli:

  • Upewnij się, że nazwy kolumn są samoopisujące. Chociaż istnieje możliwość, że kolumna Year we wszystkich tabelach dat (nazwy kolumn są unikatowe w tabeli), nie jest to domyślnie opisywane tytuły wizualizacji. Rozważ zmianę nazw kolumn w każdej tabeli roli wymiaru, tak aby Ship Date tabela zawiera kolumnę rok o nazwie Ship Yeari tak dalej.
  • W razie potrzeby upewnij się, że opisy tabel zawierają opinie autorów raportów (za pośrednictwem etykietek narzędzi okienka danych ) na temat sposobu konfigurowania propagacji filtru. Ta jasność jest ważna, gdy model zawiera ogólnie nazwaną tabelę, na przykład Date, która służy do filtrowania wielu tabel faktów. W przypadku, gdy ta tabela zawiera na przykład aktywną relację z kolumną daty zamówienia sprzedaży odsprzedawcy, rozważ podanie opisu tabeli, takiego jak Filters reseller sales by order date.

Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące aktywnej i nieaktywnej relacji.

Wymiary śmieci

Wymiar wiadomości-śmieci jest przydatny, gdy istnieje wiele wymiarów, zwłaszcza składających się z kilku atrybutów (być może jeden), a gdy te atrybuty mają kilka wartości. Dobrzy kandydaci obejmują kolumny stanu zamówienia lub kolumny demograficzne klientów, takie jak płeć lub grupa wiekowa.

Celem projektowania wymiaru śmieci jest skonsolidowanie wielu małych wymiarów w jeden wymiar w celu zmniejszenia rozmiaru magazynu modelu, a także zmniejszenia bałaganu okienka danych przez utworzenie mniejszej liczby tabel modelu.

Tabela wymiarów śmieci jest zazwyczaj kartezjańskim produktem wszystkich składowych atrybutów wymiaru, z kolumną klucza zastępczego w celu unikatowego zidentyfikowania każdego wiersza. Wymiar można utworzyć w magazynie danych lub za pomocą dodatku Power Query, aby utworzyć zapytanie, które wykonuje pełne sprzężenia zapytania zewnętrznego, a następnie dodaje klucz zastępczy (kolumnę indeksu).

Diagram przedstawiający przykład tabeli wymiarów śmieci. Stan zamówienia ma trzy stany, a stan dostawy ma dwa stany. Tabela wymiarów śmieci przechowuje wszystkie sześć kombinacji tych dwóch stanów.

To zapytanie należy załadować do modelu jako tabelę wymiarów. Należy również scalić to zapytanie z zapytaniem faktów, aby kolumna indeksu jest ładowana do modelu w celu obsługi tworzenia relacji modelu "jeden do wielu".

Zdegeneruj wymiary

Wymiar degeneracji odnosi się do atrybutu tabeli faktów wymaganej do filtrowania. W firmie Adventure Works numer zamówienia sprzedaży odsprzedawcy jest dobrym przykładem. W tym przypadku nie ma sensu utworzyć niezależnej tabeli składającej się tylko z tej jednej kolumny, ponieważ zwiększyłoby to rozmiar magazynu modelu i spowodowałoby zaśmiecanie okienka danych .

W modelu semantycznym usługi Power BI można dodać kolumnę numer zamówienia sprzedaży do tabeli faktów, aby umożliwić filtrowanie lub grupowanie według numeru zamówienia sprzedaży. Jest to wyjątek od wcześniej wprowadzonej reguły, że nie należy mieszać typów tabel (zazwyczaj tabele modelu powinny być wymiarami lub faktami).

Diagram przedstawiający okienko Dane i tabelę faktów sprzedaży, która zawiera pole Numer zamówienia.

Jeśli jednak tabela sprzedaży firmy Adventure Works zawiera kolumny numer zamówienia i numer wiersza zamówienia i są one wymagane do filtrowania, utworzenie tabeli wymiarów degeneracyjnych byłoby dobrym projektem. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące relacji jeden do jednego (Degeneruj wymiary).

Tabele faktów bez faktów

Tabela faktów bez faktów nie zawiera żadnych kolumn miar. Zawiera tylko klucze wymiarów.

Tabela faktów bez faktów może przechowywać obserwacje zdefiniowane przez klucze wymiarów. Na przykład w określonej dacie i godzinie określony klient zalogował się do witryny internetowej. Można zdefiniować miarę, aby zliczać wiersze tabeli faktów bez faktów w celu przeprowadzenia analizy, kiedy i ilu klientów się zalogowało.

Bardziej atrakcyjnym zastosowaniem tabeli faktów bez faktów jest przechowywanie relacji między wymiarami i jest to semantyczne podejście do projektowania modelu usługi Power BI, które zalecamy do definiowania relacji wymiarów wiele do wielu. W projekcie relacji wymiarów wiele-do-wielu tabela faktów jest nazywana tabelą pomostową.

Rozważmy na przykład, że sprzedawcy mogą być przypisani do co najmniej jednego regionu sprzedaży. Tabela mostkowania zostałaby zaprojektowana jako tabela faktów bez faktów składająca się z dwóch kolumn: klucz sprzedawcy i klucz regionu. Zduplikowane wartości można przechowywać w obu kolumnach.

Diagram przedstawiający nieistniejącą faktów tabelę faktów pomostową wymiarów Salesperson (Sprzedawca) i Region (Region). Tabela faktów bez faktów zawiera dwie kolumny, które są kluczami wymiarów.

To podejście projektowe wiele-do-wielu jest dobrze udokumentowane i można je osiągnąć bez tabeli pomostowej. Jednak podejście tabeli pomostowej jest uznawane za najlepsze rozwiązanie w przypadku łączenia dwóch wymiarów. Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące relacji wiele-do-wielu (Powiązanie dwóch tabel wymiarów).

Powiązana zawartość

Aby uzyskać więcej informacji na temat projektowania schematu gwiazdy lub projektowania semantycznego modelu usługi Power BI, zobacz następujące artykuły: