Wskazówki dotyczące relacji jeden do jednego

Ten artykuł jest przeznaczony dla Ciebie jako modeler danych, który współpracuje z programem Power BI Desktop. Zawiera on wskazówki dotyczące pracy z relacjami modelu jeden do jednego. Relację jeden do jednego można utworzyć, gdy obie tabele zawierają kolumnę wspólnych i unikatowych wartości.

Uwaga

Wprowadzenie do relacji modelu nie zostało omówione w tym artykule. Jeśli nie znasz całkowicie relacji, ich właściwości lub sposobu ich konfigurowania, zalecamy najpierw przeczytanie artykułu Relacje modelu w programie Power BI Desktop .

Ważne jest również, aby zrozumieć projekt schematu gwiazdy. Aby uzyskać więcej informacji, zobacz Omówienie schematu gwiazdy i znaczenia usługi Power BI.

Istnieją dwa scenariusze obejmujące relacje jeden do jednego:

• Degeneruj wymiary: można uzyskać zgenerować wymiar z tabeli faktów .

• dane wierszy obejmują wiele tabel: jedna jednostka biznesowa lub podmiot jest ładowany jako dwie (lub więcej) tabel modelu, prawdopodobnie ze względu na to, że ich dane pochodzą z różnych magazynów danych. Ten scenariusz może być typowy dla tabel wymiarów . Na przykład szczegóły produktu głównego są przechowywane w operacyjnym systemie sprzedaży, a dodatkowe szczegóły produktu są przechowywane w innym źródle.

  Zwykle jednak nie zdarza się, aby można było powiązać dwie tabele faktów w relacji jeden do jednego. Dzieje się tak, ponieważ obie tabele faktów musiałyby mieć taką samą wymiarowość i stopień szczegółowości. Ponadto każda tabela faktów wymaga unikatowych kolumn, aby umożliwić utworzenie relacji modelu.

Zdegeneruj wymiary

Gdy kolumny z tabeli faktów są używane do filtrowania lub grupowania, możesz rozważyć udostępnienie ich w oddzielnej tabeli. W ten sposób oddzielasz kolumny używane do filtrowania lub grupowania z tych kolumn używanych do podsumowywania wierszy faktów. To rozdzielenie może:

• Zmniejsz ilość miejsca do magazynowania.
• Upraszczanie obliczeń modelu.
• Przyczyń się do poprawy wydajności zapytań.
• Zapewnij autorom raportów bardziej intuicyjne środowisko okienka danych.

Rozważmy tabelę źródłową o nazwie Sales, która przechowuje szczegóły wiersza referencyjnego zamówienia sprzedaży w dwóch kolumnach.

Kolumna OrderNumber przechowuje numer zamówienia, a kolumna OrderLineNumber przechowuje sekwencję wierszy w ramach zamówienia.

Na poniższej ilustracji zwróć uwagę, że kolumny numer zamówienia i numer wiersza zamówienia nie zostały załadowane do tabeli Sales. Zamiast tego ich wartości zostały użyte do utworzenia kolumny klucza zastępczego o nazwie . (Wartość klucza jest obliczana przez pomnożenie numeru zamówienia przez 1000, a następnie dodanie numeru wiersza zamówienia).

Tabela wymiarów Sales Order oferuje bogate doświadczenie dla autorów raportów z dwiema kolumnami: Sales Order i Sales Order Line. Te konkretne kolumny obsługują projekty raportów, które muszą filtrować, grupować lub analizować szczegóły zamówień i pozycje zamówienia.

Ponieważ tabela Sales Order pochodzi z danych sprzedaży, w każdej tabeli powinna znajdować się dokładnie taka sama liczba wierszy. Ponadto między poszczególnymi OrderLineNumberID kolumnami powinny być zgodne wartości.

Dane wierszy obejmują wiele tabel

Rozważmy przykład obejmujący dwie tabele wymiarów powiązane relacją jeden do jednego: Product i Product Category. Każda tabela reprezentuje zaimportowane dane i ma kolumnę SKU (jednostka przechowywania zapasów), która zawiera unikatowe wartości.

Oto częściowy diagram modelu dwóch tabel.

Pierwsza tabela nosi nazwę Producti zawiera trzy kolumny: Color, Producti SKU. Druga tabela nosi nazwę Product Categoryi zawiera dwie kolumny: Category i SKU. Relacja jeden do jednego wiąże dwie kolumny o identyfikatorze SKU. Relacja jest filtruje w obu kierunkach, co zawsze dotyczy relacji jeden-do-jednego.

Aby ułatwić opisanie sposobu działania propagacji filtru relacji, na poniższej ilustracji przedstawiono niektóre wiersze tabeli. Wszystkie przykłady w tym artykule są oparte na tych danych.

Szczegóły wiersza dla dwóch tabel zostały opisane na następującej liście punktowanej:

• Tabela Product zawiera trzy wiersze:
  • SKU CL-01, ProductKoszulka, ColorZielony
  • SKU CL-02, ProductDżinsy, ColorNiebieski
  • SKU AC-01, ProductHat, ColorBlue
• Tabela Product Category ma dwa wiersze:
  • SKU CL-01, CategoryOdzież
  • SKU AC-01, CategoryAkcesoria

Zwróć uwagę, że tabela Product Category nie zawiera wiersza dla jednostki SKU produktu CL-02. W dalszej części tego artykułu omówimy konsekwencje tego brakującego wiersza.

W okienku danych autorzy raportów znajdą pola związane z produktem w dwóch tabelach: i . Zobaczmy, co się stanie, gdy pola z obu tabel zostaną dodane do wizualizacji tabeli. W tym przykładzie kolumna SKU pochodzi z tabeli Product.

Zwróć uwagę, że wartość Category dla jednostki SKU produktu CL-02 jest PUSTA. Dzieje się tak, ponieważ nie ma odpowiedniego wiersza w tabeli Product Category dla tego produktu.

Zalecenia

Jeśli to możliwe, zalecamy unikanie tworzenia relacji modelu jeden do jednego, gdy dane wierszy obejmują wiele tabel modelu. Dzieje się tak dlatego, że ten projekt może:

• Współtworzenie bałaganu w okienku Danych , wyświetlanie listy większej liczby tabel niż jest to konieczne.
• Utrudnij autorom raportów znajdowanie powiązanych pól, ponieważ są one dystrybuowane między wieloma tabelami.
• Ogranicz możliwość tworzenia hierarchii, ponieważ ich poziomy muszą być oparte na kolumnach z tej samej tabeli.
• Wygeneruj nieoczekiwane wyniki, gdy nie ma pełnego dopasowania wierszy między tabelami.

Konkretne zalecenia różnią się w zależności od tego, czy relacja "jeden do jednego" jest wewnątrz grupy źródłowej lub między grupami źródłowymi. Aby uzyskać więcej informacji na temat oceny relacji, zobacz relacje modelu w programie Power BI Desktop.

Relacja "jeden do jednego" wewnątrz grupy źródłowej

Gdy istnieje relacja "jeden do jednego " wewnątrz grupy źródłowej między tabelami, zalecamy skonsolidowanie danych w jedną tabelę modelu. Można to zrobić, scalając zapytania Power Query.

W poniższych krokach przedstawiono metodologię konsolidacji i modelowania danych w relacji jeden do jednego.

1. Scal zapytania: podczas łączenia dwóch zapytań należy wziąć pod uwagę kompletność danych w każdym zapytaniu. Jeśli jedno zapytanie zawiera pełny zestaw wierszy (na przykład listę główną), scal drugie zapytanie z nim. Ustaw przekształcenie scalania na użycie lewego sprzężenia zewnętrznego z, który jest domyślnym typem sprzężenia. Ten typ sprzężenia gwarantuje, że zachowasz wszystkie wiersze pierwszego zapytania i uzupełnisz je wszystkimi pasującymi wierszami drugiego zapytania. Rozwiń wszystkie wymagane kolumny drugiego zapytania do pierwszego zapytania.

   

2. Wyłącz ładowanie zapytań: pamiętaj, aby wyłączyć obciążenie drugiego zapytania. W ten sposób nie zostanie załadowany jego wynik jako tabela modelu. Ta konfiguracja zmniejsza rozmiar magazynu modelu danych i pomaga usunąć okienko Dane .

   W naszym przykładzie autorzy raportów znajdą teraz jedną tabelę o nazwie w okienku danych . Zawiera wszystkie pola związane z produktem.

3. Zamień brakujące wartości: jeśli drugie zapytanie ma niedopasowane wiersze, wartości null pojawiają się w wprowadzonych z niej kolumnach. W razie potrzeby rozważ zastąpienie wartości null wartością tokenu. Zastępowanie brakujących wartości jest szczególnie ważne, gdy autorzy raportów filtrują lub grupują według wartości kolumn, ponieważ zestawy BLAN mogą być wyświetlane w wizualizacjach raportu.

   Na poniższym obrazie zwróć uwagę, że kategoria dla jednostki SKU produktu CL-02 została teraz opisana jako [Undefined]. W zapytaniu kategorie null zostały zastąpione tą wartością tekstowymi tokenu.

   

4. Tworzenie hierarchii: jeśli istnieją relacje między kolumnami teraz skonsolidowanej tabeli, rozważ utworzenie hierarchii. Dzięki temu autorzy raportów szybko zidentyfikują możliwości przechodzenia do szczegółów wizualizacji raportu.

   W naszym przykładzie autorzy raportów mogą teraz używać hierarchii, która ma dwa poziomy: Category i Product.

   

Jeśli chcesz, jak oddzielne tabele ułatwiają organizowanie pól, nadal zalecamy skonsolidowanie w jedną tabelę. Nadal możesz organizować pola, ale zamiast tego przy użyciu folderów wyświetlania .

W naszym przykładzie autorzy raportów mogą znaleźć pole Category w folderze wyświetlania Marketing.

Jeśli nadal zdecydujesz się zdefiniować relacje "jeden do jednego" wewnątrz grupy źródłowej w modelu, jeśli to możliwe, upewnij się, że istnieją pasujące wiersze w powiązanych tabelach. Ponieważ relacja "jeden do jednego" wewnątrz grupy źródłowej jest oceniana jako zwykła relacja, problemy z integralnością danych mogą być udostępniane w wizualizacjach raportu jako BLANKs. (Przykład grupowania BLANK można zobaczyć w pierwszej wizualizacji tabeli przedstawionej w tym artykule).

Relacja jeden do jednego między grupami źródłowymi

Jeśli między tabelami istnieje relacja "jeden do jednego" między grupami źródłowymi, nie ma alternatywnego projektu modelu — chyba że dane zostaną wstępnie skonsolidowane w źródle danych. Usługa Power BI oceni relację modelu jeden do jednego jako ograniczoną relację. W związku z tym należy upewnić się, że w powiązanych tabelach istnieją pasujące wiersze, ponieważ niedopasowane wiersze są usuwane z wyników zapytania.

Zobaczmy, co się stanie, gdy pola z obu tabel zostaną dodane do wizualizacji tabeli, a między tabelami istnieje ograniczona relacja.

Pierwsza wizualizacja tabeli, która używa relacji między grupami źródłowymi, wyświetla tylko dwa wiersze. Brakuje pozycji SKU produktu CL-02, ponieważ w tabeli Product Category nie ma pasującego wiersza. Druga wizualizacja tabeli oparta na pojedynczej skonsolidowanej tabeli w modelu wyświetla trzy wiersze.

Powiązana zawartość

Aby uzyskać więcej informacji związanych z tym artykułem, zapoznaj się z następującymi zasobami:

• Relacje modelu w programie Power BI Desktop
• Omówienie schematu gwiazdy i znaczenia usługi Power BI
• Wskazówki dotyczące rozwiązywania problemów z relacjami
• Pytania? zapytaj społeczność Fabric
• Sugestie? Wnoszenie pomysłów na poprawę Fabric