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

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 danych usługi Power BI zoptymalizowanych pod kątem wydajności i użyteczności.

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 opublikowaną zawartością, na przykład The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (wydanie 3013) autorstwa Ralpha Kimballa 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 kolumny opisowe.

Tabele faktów przechowują obserwacje lub zdarzenia i mogą być zamówieniami sprzedaży, saldami zapasów, kursami wymiany, temperaturami itp. 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 z dwiema kolumnami klucza wymiaru Date (Data ) i ProductKey (Klucz produktu). Ł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 kolumnie Date 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ć bardzo dużą liczbę wierszy i nadal rosnąć wraz z upływem czasu.

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 zawierającą unikatową kolumnę wartości klucza, taką jak klucz produktu, oraz dodatkowe kolumny opisujące charakterystykę produktu, w tym nazwę produktu, kategorię, 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.

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

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 danych 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 powinien zostać zdenormalizowany w celu utworzenia pojedynczej tabeli modelu.

Znaczenie schematu gwiazdy dla modeli 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 usługi Power BI (które usługa Power BI wywołuje model semantyczny — wcześniej znany jako zestaw danych). Te zapytania służą do filtrowania, grupowania i podsumowywania danych 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 obsługują filtrowanie i grupowanie
• Tabele faktów obsługują podsumowanie

Nie ma właściwości tabeli, która modeluje, aby skonfigurować 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ść 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. Aby uzyskać więcej informacji na temat relacji, zobacz Relacje modelu w programie Power BI Desktop.

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

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 dodatkowych pojęć związanych z projektem schematu gwiazdy, które można zastosować do modelu usługi Power BI. Te pojęcia obejmują:

• Środki
• Klucze zastępcze
• Wymiary płatka śniegu
• Wymiary odgrywania ról
• Powolne zmienianie wymiarów
• Wymiary śmieci
• Zdegeneruj wymiary
• Tabele faktów bez faktów

Miary

W projekcie schematu gwiazdy miara jest kolumną tabeli faktów, która przechowuje wartości do podsumowania.

W modelu usługi Power BI miara ma inną , ale podobną definicję. Jest to formuła napisana w języku Data Analysis Expressions (DAX), która osiąga podsumowanie. Wyrażenia miar często wykorzystują funkcje agregacji języka DAX, takie jak SUM, MIN, MAX, AVERAGE itp., 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 artykuł Podstawy języka DAX w programie Power BI Desktop .

Ważne jest, aby zrozumieć, że modele usługi Power BI obsługują drugą metodę podsumowywania. Dowolna kolumna — i zazwyczaj kolumny liczbowe — może być podsumowana przez wizualizację raportu lub pytania i odpowiedzi. Te kolumny są określane jako miary niejawne. Oferują one wygodę dla Ciebie jako dewelopera modelu, ponieważ w wielu przypadkach nie trzeba tworzyć miar. Na przykład kolumna Sales Amount (Kwota sprzedaży odsprzedawcy firmy Adventure Works) może być podsumowana na wiele sposobów (suma, liczba, średnia, mediana, minimalna, maksymalna itp.) bez konieczności tworzenia miary dla każdego możliwego typu agregacji.

Istnieją jednak trzy przekonujące powody tworzenia miar, nawet w przypadku prostych podsumowań na poziomie kolumny:

• Jeśli wiesz, że autorzy raportów będą wykonywać zapytania dotyczące modelu przy użyciu wielowymiarowych wyrażeń (MDX), model musi zawierać jawne miary. Jawne miary są definiowane przy użyciu języka DAX. Takie podejście projektowe jest bardzo istotne, gdy zestaw danych usługi Power BI jest badany przy użyciu rozwiązania MDX, ponieważ rozwiązanie MDX nie może osiągnąć podsumowania wartości kolumn. W szczególności funkcja MDX będzie 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 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.
• Gdy musisz upewnić się, że autorzy raportów mogą podsumowywać tylko kolumny na określony sposób. Na przykład kolumna sales Unit Price (cena jednostkowa odsprzedawcy), która reprezentuje stawkę jednostkową, może zostać podsumowana, ale tylko przy użyciu określonych funkcji agregacji. Nie należy jej sumować, ale należy je podsumować przy użyciu innych funkcji agregacji, takich jak min, maksimum, średnia itp. W tym przypadku modeler może ukryć kolumnę Unit Price (Cena jednostkowa) 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 Pola , 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.

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 nie zawiera jednej unikatowej kolumny, należy dodać unikatowy identyfikator, aby stać się "jedną" stroną relacji. W programie Power BI Desktop można łatwo osiągnąć to wymaganie, tworząc kolumnę indeksu dodatku 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 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, DimProductSubcategory i DimProduct.

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.

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 zintegrować (denormalizować) tabele źródłowe w jedną tabelę 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.
• Dłuższe łańcuchy propagacji filtru relacji muszą zostać przejeżdone, co prawdopodobnie będzie mniej wydajne niż filtry zastosowane do pojedynczej tabeli.
• Okienko Pola przedstawia więcej tabel modelu autorom 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 obejmującej tabele.

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 bardzo dużych tabel wymiarów.

Powolne zmienianie wymiarów

Wolno zmieniający się wymiar (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ę w czasie i w sposób ad hoc. Dobrym przykładem wolno zmieniającego się wymiaru jest wymiar klienta, w szczególności kolumny szczegółów kontaktu, takie jak adres e-mail i numer telefonu. 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 albo obsługiwać oba typy jednocześnie dla różnych kolumn.

Typ 1 SCD

Typ 1SCD 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.

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

Typ 2 SCD

Typ 2SCD 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 sprzedawców 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ż zdefiniować klucz zastępczy, ponieważ klucz biznesowy (w tym przypadku identyfikator pracownika) nie będzie unikatowy.

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 wartość EndDate i wstawiając nową wersję z wartością StartDate rozpoczynającą się od poprzedniej wartości EndDate. Ponadto powiązane fakty muszą używać wyszukiwania opartego na czasie, aby pobrać wartość klucza wymiaru odpowiedniego dla daty faktów. Model usługi Power BI korzystający z dodatku Power Query nie może wygenerować tego wyniku. Może jednak ładować dane ze wstępnie załadowanej tabeli wymiarów SCD Type 2.

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 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 "Michael Blythe (12/15/2008-06/26/2019)" lub "Michael Blythe (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 również uwzględnienie hierarchii, która umożliwia wizualizacjom przechodzenie do szczegółów na poziomie wersji.

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.

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 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. Chociaż ten projekt jest możliwy, ważne jest, aby zrozumieć, że między dwiema tabelami modelu usługi Power BI może istnieć tylko jedna aktywna relacja. 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óre w firmie Adventure Works to relacja 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ż okienko Pola z nadmiarem miar. Istnieją również inne ograniczenia:

• Gdy autorzy raportów polegają na podsumowywanych kolumnach, a nie na definiowaniu miar, nie mogą osiągnąć podsumowania 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ę. Zazwyczaj dodatkowe tabele wymiarów są tworzone jako tabele obliczeniowe przy użyciu języka DAX. Korzystając z tabel obliczeniowych, model może zawierać tabelę Date (Data wysyłki), Ship Date (Data wysyłki) i tabelę Date (Data dostawy), z których każda ma jedną i aktywną relację z odpowiednimi kolumnami tabeli sprzedaży odsprzedawcy.

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.

Podczas tworzenia tabel wymiarów modelu dla każdej roli należy przestrzegać następujących dobrych rozwiązań projektowych:

• Upewnij się, że nazwy kolumn są samoopisujące. Chociaż istnieje możliwość posiadania kolumny Year we wszystkich tabelach dat (nazwy kolumn są unikatowe w tabeli), nie opisuje się domyślnie tytułów wizualizacji. Rozważ zmianę nazw kolumn w każdej tabeli roli wymiarów, aby tabela Ship Date (Data wysyłki) zawierała kolumnę rok o nazwie Ship Year itd.
• W razie potrzeby upewnij się, że opisy tabel zawierają opinie autorów raportów (za pośrednictwem etykietek narzędzi okienka Pola ) dotyczące 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 "Filtruje sprzedaż odsprzedawcy według daty zamówienia".

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 (płeć, grupa wiekowa itp.).

Celem projektowania wymiaru śmieci jest skonsolidowanie wielu "małych" wymiarów w jeden wymiar, aby zmniejszyć rozmiar magazynu modelu, a także zmniejszyć ilość okienka Pola , przeglądając mniej tabel modelu.

Tabela wymiarów śmieci jest zazwyczaj kartezjańskim produktem wszystkich składowych atrybutów wymiaru z kolumną klucza zastępczego. Klucz zastępczy zawiera unikatowe odwołanie do każdego wiersza w tabeli. 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).

To zapytanie jest ładowane do modelu jako tabela wymiarów. Należy również scalić to zapytanie z zapytaniem faktów, więc 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 takim przypadku nie ma dobrego sensu projektowania modelu, aby utworzyć niezależną tabelę składającą się tylko z tej jednej kolumny, ponieważ zwiększyłoby to rozmiar magazynu modelu i spowodowałoby zaśmiecanie okienka Pola .

W modelu 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).

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, degenerowana tabela wymiarów byłaby 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, a podejście do projektowania modelu usługi Power BI zalecamy zdefiniowanie 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.

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 modelu usługi Power BI, zobacz następujące artykuły:

• Artykuł w wikipedii dotyczący modelowania wymiarowego
• Tworzenie relacji i zarządzanie nimi w programie Power BI Desktop
• Wskazówki dotyczące relacji jeden do jednego
• Wskazówki dotyczące relacji wiele do wielu
• Wskazówki dotyczące relacji dwukierunkowych
• Wskazówki dotyczące aktywnej i nieaktywnej relacji
• Pytania? Spróbuj zadać Społeczność usługi Power BI
• Sugestie? Współtworzenie pomysłów na ulepszanie usługi Power BI