Použití relací M:N v Power BI DesktopuApply many-many relationships in Power BI Desktop

Pomocí relací s kardinalitou M:N v Power BI Desktopu můžete propojovat tabulky, které používají kardinalitu M:N.With relationships with a many-many cardinality in Power BI Desktop, you can join tables that use a cardinality of many-to-many. Umožní vám to snadněji a intuitivněji vytvářet datové modely, které obsahují dva nebo více zdrojů dat.You can more easily and intuitively create data models that contain two or more data sources. Relace s kardinalitou M:N jsou součástí širších možností složených modelů v Power BI Desktopu.Relationships with a many-many cardinality are part of the larger composite models capabilities in Power BI Desktop.

Relace M:N v podokně Upravit relaci v Power BI Desktopu

Relace s kardinalitou M:N v Power BI Desktopu představuje jednu ze tří souvisejících funkcí:A relationship with a many-many cardinality in Power BI Desktop is composed of one of three related features:

  • Složené modely: Složený model umožňuje, aby sestava měla dvě nebo více datových připojení, včetně připojení DirectQuery nebo Import, a to v libovolné kombinaci.Composite models: A composite model allows a report to have two or more data connections, including DirectQuery connections or Import, in any combo. Další informace najdete v článku Použití složených modelů v Power BI Desktopu .For more information, see Use composite models in Power BI Desktop.

  • Relace s kardinalitou M:N: Ve složených modelech můžete mezi tabulkami vytvářet relace s kardinalitou M:N.Relationships with a many-many cardinality: With composite models, you can establish relationships with a many-many cardinality between tables. Tím odpadají požadavky na jedinečné hodnoty v tabulkách.This approach removes requirements for unique values in tables. Odpadají také předchozí alternativní řešení, jako je zavádění nových tabulek jenom kvůli relacím.It also removes previous workarounds, such as introducing new tables only to establish relationships. Funkce je popsána dále v tomto článku.The feature is described further in this article.

  • Režim úložiště: Teď můžete zadat, jaké vizuály vyžadují dotazy do back-endových zdrojů dat.Storage mode: You can now specify which visuals require a query to back-end data sources. Vizuály, které nevyžadují dotaz, se importují, i když jsou založené na režimu úložiště DirectQuery.Visuals that don't require a query are imported even if they're based on DirectQuery. Tato funkce pomáhá zlepšit výkon a snižuje zatížení back-endu.This feature helps improve performance and reduce back-end load. V předchozích verzích iniciovaly dotazy do back-endových zdrojů dokonce i jednoduché vizuály, jako jsou průřezy.Previously, even simple visuals, such as slicers, began queries that were sent to back-end sources. Další informace najdete v článku Režim úložiště v Power BI Desktopu.For more information, see Storage mode in Power BI Desktop.

Co řeší relace s kardinalitou M:NWhat a relationship with a many-many cardinality solves

Než byly relace s kardinalitou M:N dostupné, definovala se relace mezi dvěma tabulkami v Power BI.Before relationships with a many-many cardinality became available, the relationship between two tables was defined in Power BI. Alespoň jeden ze sloupců tabulky zapojené do relace musel obsahovat jedinečné hodnoty.At least one of the table columns involved in the relationship had to contain unique values. Často se ale stávalo, že žádný sloupec jedinečné hodnoty neobsahoval.Often, though, no columns contained unique values.

Dvě tabulky mohou například mít sloupec označený jako Země.For example, two tables might have had a column labeled Country. Hodnoty Země ale nejsou jedinečné ani v jedné tabulce.The values of Country weren't unique in either table, though. Abyste mohli tyto tabulky spojit, musíte vytvořit alternativní řešení.To join such tables, you had to create a workaround. Jedním z možných alternativních řešení je zavedení dalších tabulek s potřebnými jedinečnými hodnotami.One workaround might be to introduce extra tables with the needed unique values. U relací s kardinalitou M:N můžete tyto tabulky spojit přímo, pokud použijete relaci s kardinalitou M:N.With relationships with a many-many cardinality, you can join such tables directly, if you use a relationship with a cardinality of many-to-many.

Použití relací s kardinalitou M:NUse relationships with a many-many cardinality

Při definování relace mezi dvěma tabulkami v Power BI je nutné definovat kardinalitu této relace.When you define a relationship between two tables in Power BI, you must define the cardinality of the relationship. Například relace mezi ProductSales a Product – s použitím sloupců ProductSales[ProductCode] a Product[ProductCode] – by se definovala jako N:1.For example, the relationship between ProductSales and Product—using columns ProductSales[ProductCode] and Product[ProductCode]—would be defined as Many-1. Relaci definujeme tímto způsobem, protože každý produkt se prodá mnohokrát a sloupec v tabulce Product (ProductCode) je jedinečný.We define the relationship in this way, because each product has many sales, and the column in the Product table (ProductCode) is unique. Při definování kardinality relace jako N:1, 1:N nebo 1:1 provede služba Power BI ověření, aby vámi vybraná kardinalita odpovídala skutečným datům.When you define a relationship cardinality as Many-1, 1-Many, or 1-1, Power BI validates it, so the cardinality that you select matches the actual data.

Podívejte se například na jednoduchý model na tomto obrázku:For example, take a look at the simple model in this image:

Tabulka ProductSales a Product, zobrazení relace, Power BI Desktop

Teď si představte, že tabulka Product zobrazuje jenom dva řádky:Now, imagine that the Product table displays just two rows, as shown:

Vizuál tabulky Product se dvěma řádky, Power BI Desktop

Představte si také, že tabulka Sales obsahuje jenom čtyři řádky, včetně řádku pro produkt C. Kvůli chybě referenční integrity řádek produktu C v tabulce Product neexistuje.Also imagine that the Sales table has just four rows, including a row for a product C. Because of a referential integrity error, the product C row doesn't exist in the Product table.

Vizuál tabulky Sales se čtyřmi řádky, Power BI Desktop

ProductName a Price (z tabulky Product) společně s celkovým Qty pro každý produkt (z tabulky ProductSales) se zobrazí tak, jak je vidět na obrázku:The ProductName and Price (from the Product table), along with the total Qty for each product (from the ProductSales table), would be displayed as shown:

Vizuál zobrazující název produktu, cenu a množství, Power BI Desktop

Jak můžete vidět na předchozím obrázku, prázdný řádek ProductName je spojený s prodejem produktu C. Tento prázdný řádek dokládá následující:As you can see in the preceding image, a blank ProductName row is associated with sales for product C. This blank row accounts for the following:

  • Všechny řádky v tabulce ProductSales, pro které v tabulce Product neexistuje odpovídající řádek.Any rows in the ProductSales table for which no corresponding row exists in the Product table. Vyskytla se chyba referenční integrity, jak můžeme vidět u produktu C v tomto příkladu.There's a referential integrity issue, as we see for product C in this example.

  • Všechny řádky v tabulce ProductSales, pro které má sloupec cizího klíče hodnotu null.Any rows in the ProductSales table for which the foreign key column is null.

Z těchto důvodů prázdný řádek v obou případech dokládá prodeje, kde jsou ProductName a Price neznámé.For these reasons, the blank row in both cases accounts for sales where the ProductName and Price are unknown.

Někdy jsou tabulky spojené dvěma sloupci, ale ani jeden z nich není jedinečný.Sometimes the tables are joined by two columns, yet neither column is unique. Podívejte se třeba na tyto dvě tabulky:For example, consider these two tables:

  • Tabulka Sales zobrazuje data prodeje podle parametru State a každý řádek obsahuje výši obratu pro typ prodeje v daném státu.The Sales table displays sales data by State, and each row contains the sales amount for the type of sale in that state. Státy zahrnují CA, WA a TX.The states include CA, WA, and TX.

    Tabulka Sales zobrazující prodeje podle státu, Power BI Desktop

  • Tabulka CityData zobrazuje data o městech, včetně počtu obyvatel a státu (například CA, WA a New York).The CityData table displays data on cities, including the population and state (such as CA, WA, and New York).

    Tabulka Sales zobrazující město, stát a počet obyvatel, Power BI Desktop

Sloupec State je nyní v obou tabulkách.A column for State is now in both tables. Je vhodné vytvořit sestavu s celkovými tržbami podle stavu a celkovou populací pro každý stav.It's reasonable to want to report on both total sales by state and total population of each state. Existuje však problém: sloupec State není v obou tabulkách jedinečný.However, a problem exists: the State column isn't unique in either table.

Předchozí alternativní řešeníThe previous workaround

V Power BI Desktopu před verzí z června 2018 nemohli uživatelé mezi těmito tabulkami vytvořit přímou relaci.Before the July 2018 release of Power BI Desktop, you couldn't create a direct relationship between these tables. Běžné alternativní řešení bylo toto:A common workaround was to:

  • Vytvořte třetí tabulku obsahující jenom jedinečná ID State.Create a third table that contains only the unique State IDs. Tabulkou mohla být jakákoli z následujících možností nebo všechny z nich:The table could be any or all of:

    • Počítaná tabulka (definovaná pomocí jazyka DAX (Data Analysis Expressions))A calculated table (defined by using Data Analysis Expressions [DAX]).
    • Tabulka založená na dotazu definovaném v Editoru dotazů, která by mohla zobrazovat jedinečná ID načtená z jedné z tabulekA table based on a query that's defined in Query Editor, which could display the unique IDs drawn from one of the tables.
    • Kombinovaná úplná sadaThe combined full set.
  • Potom vytvořte relaci mezi dvěma původními tabulkami a novou tabulkou pomocí běžné relace N:1.Then relate the two original tables to that new table by using common Many-1 relationships.

Tabulku s alternativním řešením nechte viditelnou.You could leave the workaround table visible. Případně můžete tabulku alternativního řešení skrýt, takže se nezobrazí v seznamu Pole.Or you may hide the workaround table, so it doesn't appear in the Fields list. Pokud tabulku skryjete, relace N:1 se obvykle nastaví na obousměrné filtrování a vy můžete použít pole State z některé z nich.If you hide the table, the Many-1 relationships would commonly be set to filter in both directions, and you could use the State field from either table. Pozdější křížové filtrování by se pak rozšířilo do druhé tabulky.The later cross filtering would propagate to the other table. Tento přístup je vidět na následujícím obrázku:That approach is shown in the following image:

Skrytá tabulka State, zobrazení relace, Power BI Desktop

Vizuál zobrazující State (z tabulky CityData) společně s celkovým Population a celkovým Sales by pak vypadal následovně:A visual that displays State (from the CityData table), along with total Population and total Sales, would then appear as follows:

Snímek obrazovky zobrazuje tabulku se státem, obyvatelstvem a daty o prodeji.

Poznámka

Kvůli použití státu z tabulky CityData jsou v tomto alternativním řešení uvedené jenom státy z této tabulky, takže stát TX je vyloučený.Because the state from the CityData table is used in this workaround, only the states in that table are listed, so TX is excluded. Na rozdíl od relací N:1 také platí, že zatímco řádek celkových hodnot zahrnuje všechny Sales (včetně těch ze státu TX), podrobnosti neobsahují prázdný řádek pokrývající takové neshodující se řádky.Also, unlike Many-1 relationships, while the total row includes all Sales (including those of TX), the details don't include a blank row covering such mismatched rows. Podobně by žádný prázdný řádek nepokrývající jakékoli Sales, u kterých byla hodnota null pro State.Similarly, no blank row would cover Sales for which there's a null value for the State.

Předpokládejme také, že do tohoto vizuálu přidáte City.Suppose you also add City to that visual. I když je počet obyvatel na City známý, Sales pro City jednoduše opakuje Sales pro příslušný State.Although the population per City is known, the Sales shown for City simply repeats the Sales for the corresponding State. K tomuto scénáři obvykle dochází v případě, že seskupení sloupců nesouvisí s určitou agregovanou mírou, jak je znázorněno zde:This scenario normally occurs when the column grouping is unrelated to some aggregate measure, as shown here:

Stát, populace měst a prodej, Power BI Desktop

Řekněme, že novou tabulku Sales definujete jako kombinaci všech States, a my ji zpřístupníme v seznamu Pole.Let's say you define the new Sales table as the combination of all States here, and we make it visible in the Fields list. Stejný vizuál zobrazí State (v nové tabulce), celkovou hodnotu Population a celkový prodej Sales:The same visual would display State (on the new table), the total Population, and total Sales:

Vizuál obsahující State, Population a Sales, Power BI Desktop

Jak můžete vidět, zahrne se: stát TX s daty Sales ale neznámými daty Population a —New York— se známými daty Population ale bez dat Sales.As you can see, TX—with Sales data but unknown Population data—and New York—with known Population data but no Sales data—would be included. Toto alternativní řešení není optimální a má spoustu problémů.This workaround isn't optimal, and it has many issues. U relací s kardinalitou M:N se výsledné problémy řeší postupem popsaným v následující části.For relationships with a many-many cardinality, the resulting issues are addressed, as described in the next section.

Použití relací s kardinalitou M:N místo alternativního řešeníUse a relationship with a many-many cardinality instead of the workaround

S verzí Power BI Desktopu z července 2018 můžete mezi tabulkami vytvářet přímé relace, jako jsou ty, které jsme si popsali dříve, aniž byste se museli uchylovat k podobným alternativním řešením.With the July 2018 version of Power BI Desktop, you can directly relate tables, such as the ones we described earlier, without having to resort to similar workarounds. Kardinalitu relace teď můžete nastavit na M:N.It's now possible to set the relationship cardinality to many-to-many. Toto nastavení určuje, že žádná tabulka neobsahuje jedinečné hodnoty.This setting indicates that neither table contains unique values. U takových vztahů můžete stále řídit, která tabulka filtruje druhou tabulku.For such relationships, you may still control which table filters the other table. Nebo můžete použít obousměrné filtrování, kde každá tabulka filtruje tu druhou.Or you can apply bidirectional filtering, where each table filters the other.

V Power BI Desktopu se jako výchozí nastaví kardinalita M:N, když se zjistí, že žádná tabulka neobsahuje jedinečné hodnoty pro sloupce v relaci.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. V takových případech potvrdí zpráva upozornění, že chcete nastavit relaci, a změna není nezamýšleným výsledkem problému s daty.In such cases, a warning message confirms you want to set a relationship, and the change isn't the unintended effect of a data issue.

Například při vytváření relace přímo mezi CityData a Sales – kde je směr filtrování od CityData k Sales – zobrazí Power BI Desktop dialogové okno Upravit relaci:For example, when you create a relationship directly between CityData and Sales—where filters should flow from CityData to Sales—Power BI Desktop displays the Edit relationship dialog box:

Dialogové okno Upravit relaci, Power BI Desktop

Výsledné zobrazení Relace by pak zobrazovalo přímou relaci M:N mezi oběma tabulkami.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. Zobrazení tabulek v seznamu Pole a jejich pozdější chování při vytvoření vizuálů se podobá situaci při použití alternativního řešení.The tables' appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. V alternativním řešení se dodatečná tabulka zobrazující jedinečná data State nezobrazuje.In the workaround, the extra table that displays the distinct State data isn't made visible. Jak bylo popsáno výše, zobrazí se vizuál, který zobrazuje data State, Population a Sales:As described earlier, a visual that shows State, Population, and Sales data would be displayed:

Tabulky State, Population a Sales, Power BI Desktop

Hlavní rozdíly mezi relacemi s kardinalitou M:N a typičtějšími relacemi N:1 jsou následující:The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • Zobrazené hodnoty neobsahují prázdný řádek představující neshodující se řádky ve druhé tabulce.The values shown don't include a blank row that accounts for mismatched rows in the other table. Tyto hodnoty také nezohledňují řádky, ve kterých má sloupec použitý v relaci v druhé tabulce hodnotu null.Also, the values don't account for rows where the column used in the relationship in the other table is null.

  • Není možné použít funkci RELATED(), protože může souviset více než jedním řádkem.You can't use the RELATED() function, because more than one row could be related.

  • Při použití funkce ALL() na tabulku se neodeberou filtry použité na ostatní tabulky, které s ní jsou v relaci M:N.Using the ALL() function on a table doesn't remove filters that are applied to other, related tables by a many-to-many relationship. V předchozím příkladu by míra definovaná zde uvedeným způsobem neodebrala filtry u sloupců v související tabulce CityData:In the preceding example, a measure that's defined as shown here wouldn't remove filters on columns in the related CityData table:

    Ukázkový skript

    Výsledek vizuálu zobrazujícího data State, Sales a Sales total by tak vypadal jako tento obrázek:A visual showing State, Sales, and Sales total data would result in this graphic:

    Vizuál tabulky

Ujistěte se, že výpočty používající ALL(<Table>), jako například procento z celkového součtu, vrací požadované výsledky. Zároveň mějte na paměti výše uvedené rozdíly.With the preceding differences in mind, make sure the calculations that use ALL(<Table>), such as % of grand total, are returning the intended results.

Omezení a důležité informaceLimitations and considerations

Pro tuto verzi relací s kardinalitou M:N a složených modelů existuje pár omezení.There are a few limitations for this release of relationships with a many-many cardinality and composite models.

U složených modelů nejde používat tyto (multidimenzionální) zdroje Live Connect:The following Live Connect (multidimensional) sources can't be used with composite models:

  • SAP HANASAP HANA
  • SAP Business WarehouseSAP Business Warehouse
  • SQL Server Analysis ServicesSQL Server Analysis Services
  • Datové sady Power BIPower BI datasets
  • Azure Analysis ServicesAzure Analysis Services

Pokud se k těmto multidimenzionálním zdrojům připojíte v režimu DirectQuery, nebudete se moct připojit k jinému zdroji DirectQuery ani toto připojení kombinovat s importovanými daty.When you connect to these multidimensional sources by using DirectQuery, you can't connect to another DirectQuery source or combine it with imported data.

Při použití relací s kardinalitou M:N stále platí stávající omezení používání DirectQuery.The existing limitations of using DirectQuery still apply when you use relationships with a many-many cardinality. Pro každou tabulku nyní platí řada omezení v závislosti na režimu úložiště tabulky.Many limitations are now per table, depending upon the storage mode of the table. Například počítaný sloupec v importované tabulce může odkazovat do dalších tabulek, ale počítaný sloupec v tabulce DirectQuery může odkazovat jenom na sloupce stejné tabulky.For example, a calculated column on an imported table can refer to other tables, but a calculated column on a DirectQuery table can still refer only to columns on the same table. Další omezení budou platit pro celý model, pokud kterékoli z tabulek v rámci modelu jsou v režimu DirectQuery.Other limitations apply to the whole model if any tables within the model are DirectQuery. Například funkce Rychlé přehledy a Q&A nejsou v modelu dostupné, pokud kterákoli tabulka v rámci něj má režim úložiště DirectQuery.For example, the QuickInsights and Q&A features are unavailable on a model if any table within it has a storage mode of DirectQuery.

Další krokyNext steps

Další informace o složených modelech a režimu DirectQuery najdete v následujících článcích:For more information about composite models and DirectQuery, see the following articles: