Zdarzenia
31 mar, 23 - 2 kwi, 23
Ostateczne wydarzenie prowadzone przez społeczność w usłudze Microsoft Fabric, Power BI, SQL i sztucznej inteligencji. Od 31 marca do 2 kwietnia 2025 r.
Zarejestruj się już dziśTa przeglądarka nie jest już obsługiwana.
Przejdź na przeglądarkę Microsoft Edge, aby korzystać z najnowszych funkcji, aktualizacji zabezpieczeń i pomocy technicznej.
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.
Porada
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.
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.
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.
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.
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.
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.
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:
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.
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ą:
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.
SUM
, MIN
, MAX
, AVERAGE
i 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.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 (∑).
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.
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.
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.
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 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:
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.
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 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 daje wynik typu 1 SCD. Odświeża dane tabeli, aby upewnić się, że są ładowane najnowsze wartości.
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.
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.
Porada
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.
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 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.
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:
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.
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:
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 Year
i tak dalej.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.
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).
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".
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).
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).
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.
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).
Aby uzyskać więcej informacji na temat projektowania schematu gwiazdy lub projektowania semantycznego modelu usługi Power BI, zobacz następujące artykuły:
Zdarzenia
31 mar, 23 - 2 kwi, 23
Ostateczne wydarzenie prowadzone przez społeczność w usłudze Microsoft Fabric, Power BI, SQL i sztucznej inteligencji. Od 31 marca do 2 kwietnia 2025 r.
Zarejestruj się już dziśSzkolenie
Moduł
Projektowanie modelu semantycznego w usłudze Power BI - Training
Proces tworzenia skomplikowanego modelu semantycznego w usłudze Power BI jest prosty. Jeśli dane pochodzą z więcej niż jednego systemu transakcyjnego, w celu zapoznania się z nimi może być konieczna praca z wieloma tabelami. Tworzenie doskonałego modelu semantycznego polega na uproszczeniu chaosu. Schemat star jest jednym ze sposobów uproszczenia modelu semantycznego, a w tym module poznasz terminologię i implementację. Dowiesz się też, dlaczego wybór poprawnej szczegółowości danych jest istotny dla wydajno
Certyfikacja
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.