Pokyny k relaci 1:1One-to-one relationship guidance

Tento článek je určený pro modelátory dat, kteří pracují s Power BI Desktopem.This article targets you as a data modeler working with Power BI Desktop. Poskytuje pokyny pro práci s relacemi modelu 1:1.It provides you with guidance on working with one-to-one model relationships. Relaci 1:1 lze vytvořit, když obě tabulky obsahují sloupec společných a jedinečných hodnot.A one-to-one relationship can be created when both tables each contain a column of common and unique values.

Poznámka

Článek neobsahuje úvod do relací v modelu.An introduction to model relationships is not covered in this article. Pokud se ještě nevyznáte v relacích, jejich vlastnostech a způsobu jejich konfigurace, doporučujeme si napřed přečíst článek Relace modelů v Power BI Desktopu.If you're not completely familiar with relationships, their properties or how to configure them, we recommend that you first read the Model relationships in Power BI Desktop article.

Je také důležité, abyste uměli navrhnout hvězdicové schéma.It's also important that you have an understanding of star schema design. Další informace najdete v článku Vysvětlení hvězdicového schématu a jeho důležitosti pro Power BI.For more information, see Understand star schema and the importance for Power BI.

Existují dva scénáře, které zahrnují relace 1:1:There are two scenarios that involve one-to-one relationships:

  • Degenerované dimenze: Degenerované dimenze můžete odvodit z tabulky typu fakta.Degenerate dimensions: You can derive a degenerate dimension from a fact-type table.

  • Data řádku jsou rozložená mezi tabulkami: Jedna obchodní entita nebo subjekt se načte jako dvě nebo více tabulek modelů, což může být způsobeno tím, že zdrojem dat můžou být různá úložiště dat.Row data spans across tables: A single business entity or subject is loaded as two (or more) model tables, possibly because their data is sourced from different data stores. Toto může být běžný scénář pro tabulky typu dimenze.This scenario can be common for dimension-type tables. Hlavní podrobnosti o produktech jsou třeba uloženy v operačním systému prodejů a další podrobnosti o produktech jsou uloženy v jiném zdroji.For example, master product details are stored in an operational sales system, and supplementary product details are stored in a different source.

    Je ale neobvyklé propojit dvě tabulky typu fakta pomocí relace 1:1.It's unusual, however, that you'd relate two fact-type tables with a one-to-one relationship. Je to proto, že obě tabulky typu fakta by musely mít stejnou dimenzionalitu a členitost.It's because both fact-type tables would need to have the same dimensionality and granularity. Každá tabulka typu fakta by proto potřebovala jedinečné sloupce, aby bylo možné vytvořit relaci modelu.Also, each fact-type table would need unique columns to allow the model relationship to be created.

Degenerované dimenzeDegenerate dimensions

Když se sloupce z tabulky typu fakta použijí pro filtrování nebo seskupení, můžete je zpřístupnit v samostatné tabulce.When columns from a fact-type table are used for filtering or grouping, you can consider making them available in a separate table. Tímto způsobem oddělíte sloupce používané pro filtrování nebo seskupení od sloupců, které se používají k sumarizaci řádků faktů.This way, you separate columns used for filter or grouping, from those columns used to summarize fact rows. Toto oddělení může:This separation can:

  • Zmenšit prostor úložištěReduce storage space
  • Zjednodušit výpočty modeluSimplify model calculations
  • Přispět k vylepšení výkonu dotazůContribute to improved query performance
  • Poskytovat autorům sestav intuitivnější prostředí podokna PoleDeliver a more intuitive Fields pane experience to your report authors

Předpokládejme zdrojovou tabulku prodejů, která obsahuje podrobnosti o prodejních objednávkách ve dvou sloupcích.Consider a source sales table that stores sales order details in two columns.

Řádky tabulky pro tabulku prodejů

Sloupec OrderNumber (ČísloObjednávky) ukládá číslo objednávky a sloupec OrderLineNumber (ČísloŘádkuObjednávky) ukládá posloupnost řádků v objednávce.The OrderNumber column stores the order number, and the OrderLineNumber column stores a sequence of lines within the order.

V následujícím diagramu modelu si všimněte, že sloupce čísel objednávek a čísel řádků objednávek se do tabulky Sales (Prodeje) nenačetly.In the following model diagram, notice that the order number and order line number columns haven't been loaded to the Sales table. Místo toho se jejich hodnoty použily k vytvoření sloupce náhradního klíče s názvem SalesOrderLineID (IDŘádkuProdejníObjednávky).Instead, their values were used to create a surrogate key column named SalesOrderLineID. (Hodnota klíče se vypočítá vynásobením čísla objednávky číslem 1000 a následným přidáním čísla řádku objednávky.)(The key value is calculated by multiplying the order number by 1000, and then adding the order line number.)

Diagram modelu obsahuje dvě tabulky: Sales (Prodeje) a Sales Order (Prodejní objednávka).

Tabulka Sales Order (Prodejní objednávka) poskytuje autorům sestav komplexní prostředí se třemi sloupci: Sales Order (Prodejní objednávka), Sales Order Line (Řádek prodejní objednávky) a Line Number (Číslo řádku).The Sales Order table provides a rich experience for report authors with three columns: Sales Order, Sales Order Line, and Line Number. Zahrnuje také hierarchii.It also includes a hierarchy. Tyto prostředky tabulek podporují návrhy sestav, které potřebují filtrovat, seskupovat nebo procházet podrobnosti objednávek a řádků objednávek.These table resources support report designs that need to filter, group by, or drill down through orders and order lines.

Vzhledem k tomu, že je tabulka Sales Order (Prodejní objednávka) odvozená od údajů o prodejích, měl by být v každé tabulce přesně stejný počet řádků.As the Sales Order table is derived from the sales data, there should be exactly the same number of rows in each table. V jednotlivých sloupcích SalesOrderLineID (IDŘádkuProdejníObjednávky) by také měly být odpovídající hodnoty.Further, there should be matching values between each SalesOrderLineID column.

Data řádku jsou rozložená mezi tabulkamiRow data spans across tables

Vezměte v úvahu příklad zahrnující dvě tabulky typu dimenze propojené relací 1:1: Product (Produkt) a Product Category (Kategorie produktu).Consider an example involving two one-to-one related dimension-type tables: Product, and Product Category. Každá tabulka představuje importovaná data a má sloupec SKU (Skladová položka), který obsahuje jedinečné hodnoty.Each table represents imported data and has a SKU (Stock-Keeping Unit) column containing unique values.

Tady je částečný diagram modelu těchto dvou tabulek.Here's a partial model diagram of the two tables.

Diagram modelu obsahuje dvě tabulky.

První tabulka se jmenuje Product (Produkt) a obsahuje tři sloupce: Color (Barva), Product (Produkt) a SKU (Skladová položka).The first table is named Product, and it contains three columns: Color, Product, and SKU. Druhá tabulka se jmenuje Product Category (Kategorie produktu) a obsahuje dva sloupce: Category (Kategorie) a SKU (Skladová položka).The second table is named Product Category, and it contains two columns: Category, and SKU. Relace 1:1 propojuje dva sloupce SKU (Skladová položka).A one-to-one relationship relates the two SKU columns. Relace filtruje v obou směrech, což se u relací 1:1 děje vždy.The relationship filters in both directions, which is always the case for one-to-one relationships.

Abychom si mohli popsat, jak funguje šíření relačního filtru, upravíme diagram modelu, aby zobrazoval řádky tabulek.To help describe how the relationship filter propagation works, the model diagram has been modified to reveal the table rows. Všechny příklady v tomto článku jsou založené na těchto datech.All examples in this article are based on this data.

Poznámka

V diagramu modelu v Power BI Desktopu nejdou řádky tabulek zobrazit.It's not possible to display table rows in the Power BI Desktop model diagram. Uděláme to v tomto článku, abychom výklad doplnili jasnými příklady.It's done in this article to support the discussion with clear examples.

V diagramu modelu se teď zobrazují řádky tabulek.

Podrobnosti o řádcích obou tabulek jsou popsané v následujícím seznamu s odrážkami:The row details for the two tables are described in the following bulleted list:

  • Tabulka Product (Produkt) má tři řádky:The Product table has three rows:
    • SKU (Skladová položka) CL-01, Product (Produkt) T-shirt (Tričko), Color (Barva) Green (Zelená)SKU CL-01, Product T-shirt, Color Green
    • SKU (Skladová položka) CL-02, Product (Produkt) Jeans (Džíny), Color (Barva) Blue (Modrá)SKU CL-02, Product Jeans, Color Blue
    • SKU (Skladová položka) AC-01, Product (Produkt) Hat (Klobouk), Color (Barva) Blue (Modrá)SKU AC-01, Product Hat, Color Blue
  • Tabulka Product Category (Kategorie produktu) má dva řádky:The Product Category table has two rows:
    • SKU (Skladová položka) CL-01, Category (Kategorie) Clothing (Oblečení)SKU CL-01, Category Clothing
    • SKU (Skladová položka) AC-01, Category (Kategorie) Accessories (Doplňky)SKU AC-01, Category Accessories

Všimněte si, že tabulka Product Category (Kategorie produktu) neobsahuje řádek pro skladovou položku produktu CL-02.Notice that the Product Category table doesn't include a row for the product SKU CL-02. Důsledky tohoto chybějícího řádku si probereme později v tomto článku.We'll discuss the consequences of this missing row later in this article.

V podokně Pole najdou autoři sestav pole související s produktem ve dvou tabulkách: Product (Produkt) a Product Category (Kategorie produktu).In the Fields pane, report authors will find product-related fields in two tables: Product and Product Category.

Podokno Pole zobrazuje obě tabulky rozbalené a sloupce jsou uvedené jako pole s vyvolanými položkami Product a Product Category

Pojďme se podívat, co se stane, když se pole z obou tabulek přidají do vizuálu tabulky.Let's see what happens when fields from both tables are added to a table visual. V tomto příkladu je zdrojem sloupce SKU (Skladová položka) tabulka Product (Produkt).In this example, the SKU column is sourced from the Product table.

Vizuál tabulky obsahuje čtyři sloupce: SKU (Skladová položka), Product (Produkt), Color (Barva) a Category (Kategorie).

Všimněte si, že hodnota Category (Kategorie) skladové položky produktu CL-02 je prázdná.Notice that the Category value for product SKU CL-02 is BLANK. Je to proto, že v tabulce Product Category (Kategorie produktu) není pro tento produkt žádný řádek.It's because there's no row in the Product Category table for this product.

DoporučeníRecommendations

Pokud je to možné, doporučujeme vyhýbat se vytváření relací modelu 1:1, když jsou data řádku rozložena mezi tabulkami modelu.When possible, we recommend you avoid creating one-to-one model relationships when row data spans across model tables. Tento návrh totiž může:It's because this design can:

  • Přispět k zahlcení podokna Pole tím, že se zobrazí více tabulek, než je potřebaContribute to Fields pane clutter, listing more tables than necessary
  • Znesnadnit autorům sestav vyhledání souvisejících polí, protože se distribuují ve více tabulkáchMake it difficult for report authors to find related fields, because they're distributed across multiple tables
  • Omezit možnost vytváření hierarchií, protože jejich úrovně musí být založené na sloupcích ze stejné tabulkyLimit the ability to create hierarchies, as their levels must be based on columns from the same table
  • Produkovat neočekávané výsledky v případě, že nedošlo k úplné shodě řádků mezi tabulkamiProduce unexpected results when there isn't a complete match of rows between the tables

Konkrétní doporučení se liší v závislosti na tom, jestli je relace 1:1 uvnitř ostrůvku nebo mezi ostrůvky.Specific recommendations differ depending on whether the one-to-one relationship is intra-island or inter-island. Další informace o vyhodnocení relace najdete v tématu Relace modelu v Power BI Desktopu (vyhodnocení relace).For more information about relationship evaluation, see Model relationships in Power BI Desktop (Relationship evaluation).

Relace 1:1 uvnitř ostrůvkuIntra-island one-to-one relationship

Pokud mezi tabulkami existuje relace 1:1 uvnitř ostrůvku, doporučujeme konsolidovat data do jedné tabulky modelu.When a one-to-one intra-island relationship exists between tables, we recommend consolidating the data into a single model table. Dělá se to sloučením dotazů Power Query.It's done by merging the Power Query queries.

Následující kroky představují metodologii pro konsolidaci a modelování dat v relaci 1:1:The following steps present a methodology to consolidate and model the one-to-one related data:

  1. Sloučení dotazů: Při kombinování dvou dotazů mějte na paměti úplnost dat v každém dotazu.Merge queries: When combining the two queries, give consideration to the completeness of data in each query. Pokud jeden dotaz obsahuje úplnou sadu řádků (například hlavní seznam), slučte s ním druhý dotaz.If one query contains a complete set of rows (like a master list), merge the other query with it. Nakonfigurujte transformaci sloučení tak, aby používala levé vnější spojení, což je výchozí typ spojení.Configure the merge transformation to use a left outer join, which is the default join type. Tento typ spojení zajistí, že budete uchovávat všechny řádky prvního dotazu a doplníte je všemi odpovídajícími řádky druhého dotazu.This join type ensures you'll keep all rows of the first query, and supplement them with any matching rows of the second query. Rozbalte všechny požadované sloupce druhého dotazu do prvního dotazu.Expand all required columns of the second query into the first query.

  2. Zakažte načítání dotazu: Nezapomeňte zakázat načítání druhého dotazu.Disable query load: Be sure to disable the load of the second query. Jeho výsledek se pak nenačte jako tabulka modelu.This way, it won't load its result as a model table. Tato konfigurace zmenšuje velikost úložiště datového modelu a pomáhá zestručnit podokno Pole.This configuration reduces the data model storage size, and helps to unclutter the Fields pane.

    V našem příkladu teď najdou autoři sestav v podokně Pole jednu tabulku s názvem Product (Produkt).In our example, report authors now find a single table named Product in the Fields pane. Obsahuje všechna pole související s produktem.It contains all product-related fields.

    Podokno Pole zobrazuje obě tabulky rozbalené a sloupce jsou uvedené jako pole s vyvolanou položkou Product.

  3. Nahraďte chybějící hodnoty: Pokud nemá druhý dotaz shodné řádky, zobrazí se ve sloupcích, které z něj pochází, hodnoty NULL.Replace missing values: If the second query has unmatched rows, NULLs will appear in the columns introduced from it. V případě potřeby zvažte nahrazení hodnot NULL hodnotou tokenu.When appropriate, consider replacing NULLs with a token value. Nahrazování chybějících hodnot je obzvlášť důležité, když autoři sestav filtrují nebo seskupují hodnoty sloupců. Ve vizuálech sestav by se totiž mohly zobrazit prázdné znaky.Replacing missing values is especially important when report authors filter or group by the column values, as BLANKs could appear in report visuals.

    V následujícím vizuálu tabulky si všimněte, že kategorie pro skladovou položku produktu CL-02 teď je [Undefined] (Nedefinováno).In the following table visual, notice that the category for product SKU CL-02 now reads [Undefined]. V dotazu se nulové kategorie nahradily touto textovou hodnotou tokenu.In the query, null categories were replaced with this token text value.

    Vizuál tabulky obsahuje čtyři sloupce: SKU (Skladová položka), Product (Produkt), Color (Barva) a Category (Kategorie).

  4. Vytvořte hierarchie: Pokud mezi sloupci nyní konsolidované tabulky existují relace, zvažte možnost vytvoření hierarchií.Create hierarchies: If relationships exist between the columns of the now-consolidated table, consider creating hierarchies. Autoři sestav tak budou moct rychle identifikovat příležitosti pro procházení vizuálů sestav.This way, report authors will quickly identify opportunities for report visual drilling.

    V našem příkladu teď můžou autoři sestav použít hierarchii, která má dvě úrovně: Category (Kategorie) a Product (Produkt).In our example, report authors now can use a hierarchy that has two levels: Category and Product.

    Podokno Pole zobrazuje obě tabulky rozbalené a sloupce jsou uvedené jako pole s vyvolanou úrovní Products.

I když se vám může líbit, jak samostatné tabulky pomáhají organizovat vaše pole, přesto doporučujeme, abyste je konsolidovali do jedné tabulky.If you like how separate tables help organize your fields, we still recommend consolidating into a single table. Pole můžete místo toho uspořádat pomocí zobrazených složek.You can still organize your fields, but by using display folders instead.

V našem příkladu můžou autoři sestav najít pole Category (Kategorie) v zobrazené složce Marketing.In our example, report authors can find the Category field within the Marketing display folder.

Podokno Pole zobrazuje pole Category (Kategorie) v zobrazené složce s názvem Marketing.

Pokud je to možné, měli byste i nadále definovat v modelu relace 1:1 uvnitř ostrůvku a zajistit, aby v souvisejících tabulkách byly odpovídající řádky.Should you still decide to define one-to-one intra-island relationships in your model, when possible, ensure there are matching rows in the related tables. Vzhledem k tomu, že se relace 1:1 uvnitř ostrůvku vyhodnocuje jako normální relace, můžou se problémy s integritou dat projevit ve vizuálech sestavy jako prázdné hodnoty.As a one-to-one intra-island relationship is evaluated as a regular relationship, data integrity issues could surface in your report visuals as BLANKs. (Příklad seskupení prázdných hodnot si můžete prohlédnout ve vizuálu první tabulky uvedené v tomto článku.)(You can see an example of a BLANK grouping in the first table visual presented in this article.)

Relace 1:1 mezi ostrůvkyInter-island one-to-one relationship

Pokud mezi tabulkami existuje relace 1:1 mezi ostrůvky, neexistuje žádný alternativní návrh modelu – pokud ovšem data ve zdrojích dat předem nekonsolidujete.When a one-to-one inter-island relationship exists between tables, there's no alternative model design—unless you pre-consolidate the data in your data sources. Power BI vyhodnotí relaci modelu 1:1 jako omezenou relaci.Power BI will evaluate the one-to-one model relationship as a limited relationship. Proto se ujistěte, že jsou v souvisejících tabulkách odpovídající řádky. Neodpovídající řádky budou totiž z výsledků dotazu eliminovány.Therefore, take care to ensure there are matching rows in the related tables, as unmatched rows will be eliminated from query results.

Pojďme se podívat, co se stane, když se pole z obou tabulek přidají do vizuálu tabulky a mezi tabulkami existuje omezená relace.Let's see what happens when fields from both tables are added to a table visual, and a limited relationship exists between the tables.

Vizuál tabulky obsahuje čtyři sloupce: SKU (Skladová položka), Product (Produkt), Color (Barva) a Category (Kategorie).

Tabulka zobrazuje pouze dva řádky.The table displays two rows only. SKU produktu CL-02 chybí, protože v tabulce Product Category (Kategorie produktu) neexistuje žádný odpovídající řádek.Product SKU CL-02 is missing because there's no matching row in the Product Category table.

Další krokyNext steps

Další informace související s tímto článkem najdete v následujících tématech:For more information related to this article, check out the following resources: