Több-a-többhöz kapcsolatok alkalmazása a Power BI DesktopbanApply many-many relationships in Power BI Desktop

A Power BI Desktop több-a-többhöz számosságú kapcsolatok funkciójával több-a-többhöz számosságot használó táblák kapcsolhatók össze.With relationships with a many-many cardinality in Power BI Desktop, you can join tables that use a cardinality of many-to-many. A kettő vagy több adatforrást tartalmazó adatmodellek így egyszerűbb és intuitívabb módon hozhatók létre.You can more easily and intuitively create data models that contain two or more data sources. A több-a-többhöz számosságú kapcsolatok a Power BI Desktop tágabb összetett modellek funkciójának része.Relationships with a many-many cardinality are part of the larger composite models capabilities in Power BI Desktop.

Egy több-a-többhöz kapcsolat a Power BI Desktop „Kapcsolat szerkesztése” paneljén

A Power BI Desktopban beállítható több-a-többhöz számosságú kapcsolatok három összefüggő funkció együttesének egy részét képezik:A relationship with a many-many cardinality in Power BI Desktop is composed of one of three related features:

  • Összetett modellek: Az összetett modellek lehetővé teszik, hogy egy jelentés kettő vagy több adatkapcsolattal, köztük DirectQuery-kapcsolatokkal és importálással, vagy ezek bármilyen kombinációjával rendelkezzen.Composite models: A composite model allows a report to have two or more data connections, including DirectQuery connections or Import, in any combo. További információ: Összetett modellek használata a Power BI Desktopban.For more information, see Use composite models in Power BI Desktop.

  • Több-a-többhöz számosságú kapcsolatok: Az összetett modellekkel a táblák között több-a-többhöz számosságú kapcsolatok hozhatók létre.Relationships with a many-many cardinality: With composite models, you can establish relationships with a many-many cardinality between tables. Ez a megközelítés kiküszöböli, hogy egyedi értékeket kelljen használni a táblákban.This approach removes requirements for unique values in tables. Korábbi áthidaló megoldásokat is szükségtelenné tesz, például új táblák bevezetését a kapcsolatok létrehozásához.It also removes previous workarounds, such as introducing new tables only to establish relationships. A funkcióról ez a cikk szolgáltat további információt.The feature is described further in this article.

  • Tárolási mód: Mostantól megadható, hogy mely vizualizációk igényelnek a háttér-adatforrásokba irányuló lekérdezéseket.Storage mode: You can now specify which visuals require a query to back-end data sources. Azok a vizualizációk, amelyekhez nincs szükség lekérdezésre, importálva lesznek még akkor is, ha DirectQuery-alapúak.Visuals that don't require a query are imported even if they're based on DirectQuery. Ez a funkció segíti a teljesítmény javulását, és csökkenti a háttérrendszerek leterheltségét.This feature helps improve performance and reduce back-end load. Korábban még az egyszerű vizualizációk, például a szeletelők is kezdeményeztek a háttérbeli forrásokba irányuló lekérdezéseket.Previously, even simple visuals, such as slicers, began queries that were sent to back-end sources. További információt a Tárolási mód a Power BI Desktopban című cikkben talál.For more information, see Storage mode in Power BI Desktop.

Erre nyújtanak megoldást a több-a-többhöz számosságú kapcsolatokWhat a relationship with a many-many cardinality solves

A két tábla közötti kapcsolat már definiálva volt a Power BI-ban, mielőtt a több-a-többhöz számosságú kapcsolatok funkciója elérhetővé vált volna.Before relationships with a many-many cardinality became available, the relationship between two tables was defined in Power BI. A kapcsolatot alkotó táblák legalább egyik oszlopának tartalmaznia kellett egyedi értékeket,At least one of the table columns involved in the relationship had to contain unique values. gyakran azonban egyetlen oszlopban sem voltak egyedi értékek.Often, though, no columns contained unique values.

Például lehetséges, hogy két tábla is tartalmazott egy Country (Ország) nevű oszlopot.For example, two tables might have had a column labeled Country. A Country értékei azonban egyik táblában sem voltak egyediek.The values of Country weren't unique in either table, though. Két ilyen tábla összekapcsolásához áthidaló megoldásra volt szükség.To join such tables, you had to create a workaround. Az egyik megoldás az lehet, ha új táblákat vezet be a szükséges egyedi értékekkel.One workaround might be to introduce extra tables with the needed unique values. A több-a-többhöz számosságú kapcsolatok funkciójával ilyen táblákat közvetlenül is összekapcsolhat a több-a-többhöz számosságú kapcsolat segítségével.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.

Több-a-többhöz számosságú kapcsolatok használataUse relationships with a many-many cardinality

Amikor kapcsolatot definiál két tábla között a Power BI-ban, meg kell adnia a kapcsolat számosságát.When you define a relationship between two tables in Power BI, you must define the cardinality of the relationship. Például a ProductSales (értékesítések) és Product (termék) táblák közötti kapcsolat — a ProductSales[ProductCode] és a Product[ProductCode] oszlop alapján — több-az-egyhez kapcsolatként lenne definiálva.For example, the relationship between ProductSales and Product—using columns ProductSales[ProductCode] and Product[ProductCode]—would be defined as Many-1. A kapcsolat azért definiálható így, mert egy termékhez több értékesítés is tartozhat, és a Product tábla ProductCode (termékkód) oszlopa egyedi.We define the relationship in this way, because each product has many sales, and the column in the Product table (ProductCode) is unique. Amikor egy kapcsolat számosságaként több-az-egyhez, egy-a-többhöz vagy egy-az-egyhez van megadva, a Power BI ellenőrzi, hogy a megadott számosság megfelel-e a tényleges adatoknak.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.

Vegyük például az alábbi képen látható egyszerű modellt:For example, take a look at the simple model in this image:

ProductSales és Product tábla, Kapcsolat nézet, Power BI Desktop

Tegyük fel, hogy a Product tábla csak két sorból áll, ahogyan a kép mutatja:Now, imagine that the Product table displays just two rows, as shown:

A Product tábla vizualizációja két sorral, Power BI Desktop

Tegyük fel továbbá, hogy a Sales (Értékesítések) tábla csak négy sorból áll, köztük egy C termékhez tartozó sorból. Egy hivatkozási integritási hiba következtében a Product táblában a C termékhez tartozó sor nem létezik.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.

A Sales tábla vizualizációja négy sorral, Power BI Desktop

A ProductName (terméknév) és a Price (Ár) (a Product táblából), valamint az egyes termékek összes mennyiségét tartalmazó Qty (mennyiség) (a ProductSales táblából) a következő módon jelenne meg: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:

A termék nevének, árának és mennyiségének vizualizációja, Power BI Desktop

Amint az előző képen látható, van egy üres ProductName sor, amely a C termék értékesítéséhez tartozik. Ez az üres sor a következőkre van hatással: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:

  • A ProductSales tábla minden olyan sorára, amelyhez nincs megfeleltethető sor a Product táblában.Any rows in the ProductSales table for which no corresponding row exists in the Product table. Ez egy hivatkozási integritási hiba, amelyet példánkban a C termék esetében látunk.There's a referential integrity issue, as we see for product C in this example.

  • A ProductSales tábla minden sorára, amely a külsőkulcs-oszlopban null értéket tartalmaz.Any rows in the ProductSales table for which the foreign key column is null.

A fenti okokból az üres sor mindkét esetben olyan értékesítéseknek felel meg, ahol a ProductName és a Price ismeretlen.For these reasons, the blank row in both cases accounts for sales where the ProductName and Price are unknown.

Olykor az is előfordul, hogy a táblák két oszlop alapján vannak összekapcsolva, de egyik oszlop sem egyedi.Sometimes the tables are joined by two columns, yet neither column is unique. Vegyük például a következő két táblát:For example, consider these two tables:

  • A Sales tábla államonként (State) mutatja az értékesítéseket, soronként tartalmazva az adott módon értékesített mennyiséget az államban.The Sales table displays sales data by State, and each row contains the sales amount for the type of sale in that state. Az államok a következők: CA, WA, TX (Kalifornia, Washington és Texas).The states include CA, WA, and TX.

    Értékesítési tábla az államonkénti értékesítésekkel, Power BI Desktop

  • A CityData tábla városok adatait mutatja, köztük a lakosságot és az államot, amelyben megtalálhatók (például CA, WA és New York államot).The CityData table displays data on cities, including the population and state (such as CA, WA, and New York).

    Értékesítési tábla a várossal, az állammal és a lakossággal, Power BI Desktop

A State (Állam) oszlop mindkét táblában megtalálható.A column for State is now in both tables. Célszerű mindkét teljes értékesítésről jelentést készíteni állam és az államok népessége alapján.It's reasonable to want to report on both total sales by state and total population of each state. Itt azonban problémába ütközhet: a State oszlop egyik táblában sem egyedi.However, a problem exists: the State column isn't unique in either table.

A korábbi áthidaló megoldásThe previous workaround

A Power BI Desktop 2018. júliusi kiadását megelőző verziókban a felhasználók nem tudtak ezek között a táblák között közvetlen kapcsolatot létrehozni.Before the July 2018 release of Power BI Desktop, you couldn't create a direct relationship between these tables. Egy gyakran alkalmazott áthidaló megoldás a következő lépésekből állt:A common workaround was to:

  • Létre kellett hozni egy harmadik táblát, amely csak az egyedi államazonosítókat tartalmazta.Create a third table that contains only the unique State IDs. A tábla a következők közül bármelyik lehetett:The table could be any or all of:

    • Egy számított tábla (Data Analysis Expressions-referencia [DAX] használatával definiálva).A calculated table (defined by using Data Analysis Expressions [DAX]).
    • Egy Lekérdezésszerkesztőben definiált lekérdezésen alapuló tábla, amely meg tudta jeleníteni a valamelyik táblából kinyert egyedi azonosítókat.A table based on a query that's defined in Query Editor, which could display the unique IDs drawn from one of the tables.
    • A teljes kombinált készlet.The combined full set.
  • Össze kellett kapcsolni a két eredeti és az új táblát a szokásos több-az-egyhez kapcsolatokkal.Then relate the two original tables to that new table by using common Many-1 relationships.

A harmadik táblát megjelenítve hagyhatta.You could leave the workaround table visible. Igény szerint el is rejthette, hogy az ne jelenjen meg a Mezők listában.Or you may hide the workaround table, so it doesn't appear in the Fields list. A tábla elrejtésekor a több-az-egyhez kapcsolatok gyakran kétirányú szűrésre voltak beállítva, és bármelyik tábla State mezőjét használni lehetett.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. Ezt aztán keresztszűrés vitt át a másik táblára.The later cross filtering would propagate to the other table. Ez a megközelítés az alábbi képen látható:That approach is shown in the following image:

Az elrejtette State tábla, Kapcsolat nézet, Power BI Desktop

Az államokat (State) (a CityData táblából) a teljes lakossággal (Population) és az összes értékesítéssel (Sales) együtt megjelenítő vizualizáció ekkor az alábbihoz hasonló módon néz ki:A visual that displays State (from the CityData table), along with total Population and total Sales, would then appear as follows:

Képernyőkép az állam, a népesség és az értékesítés adatait mutató tábláról.

Megjegyzés

Mivel ez az áthidaló megoldás az államot a CityData táblából emeli ki, csak az ebben a táblában szereplő államok jelennek meg, ezért TX kimaradt.Because the state from the CityData table is used in this workaround, only the states in that table are listed, so TX is excluded. Ezen felül, a több-az-egyhez kapcsolatoktól eltérően, bár az összegző sor minden Sales értéket figyelembe vesz (a TX államhoz tartozókat is), a részletezésben nincs a nem egyező soroknak megfelelő üres sor.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. Ugyanígy azoknak a Sales értékeknek sem felelne meg üres sor, amelyekhez null érték tartozik a State oszlopban.Similarly, no blank row would cover Sales for which there's a null value for the State.

Tegyük fel, hogy a City (Város) oszlopot is hozzáadja a vizualizációhoz.Suppose you also add City to that visual. Ekkor bár az egyes városok lakossága ismert, a City mellett feltüntetett Sales értékek a megfelelő államhoz (State) tartozó Sales értékek ismétlései lennének.Although the population per City is known, the Sales shown for City simply repeats the Sales for the corresponding State. Ez a forgatókönyv akkor fordul elő, ha az oszlopcsoportosítás nem kapcsolódik egy összesített mértékhez, az alábbi módon:This scenario normally occurs when the column grouping is unrelated to some aggregate measure, as shown here:

Állam, városok népessége és értékesítés, Power BI Desktop

Tegyük fel, hogy az új Sales táblát az összes itt látható állam kombinációjaként definiálja, majd láthatóvá teszi a Mezők listában.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. Ez a vizualizáció megjelenítené a State oszlopot (az új táblán), a teljes Population, valamint a teljes Sales értékeket:The same visual would display State (on the new table), the total Population, and total Sales:

Állam, népesség és értékesítés vizualizációja, Power BI Desktop

Amint látható, így a TX—ismert Sales adatokkal, de ismeretlen Population adatokkal—,és New York—ismert Population adatokkal, de Sales adatok nélkül—szintén szerepelne.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. Ez az áthidaló megoldás nem optimális, és számos problémával jár.This workaround isn't optimal, and it has many issues. A több-a-többhöz számosságú kapcsolatok megjelenésének köszönhetően orvosolhatóvá váltak a problémák, a következő bekezdésben leírtak szerint.For relationships with a many-many cardinality, the resulting issues are addressed, as described in the next section.

A több-a-többhöz számosságú kapcsolatok használata a kerülő megoldás helyettUse a relationship with a many-many cardinality instead of the workaround

A Power BI Desktop 2018. júliusi verziójától kezdve az előzőekben leírtakhoz hasonlóan közvetlenül összekapcsolhatók a táblák, anélkül, hogy áthidaló megoldásokra lenne szükség.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. A kapcsolatokat mostantól több-a-többhöz számosságúra is lehet állítani.It's now possible to set the relationship cardinality to many-to-many. Ez a beállítás jelzi, hogy egyik tábla sem tartalmaz egyedi értékeket.This setting indicates that neither table contains unique values. Az ilyen kapcsolatok esetén is megadhatja, hogy mely tábla szűrje a másik táblát.For such relationships, you may still control which table filters the other table. Ehelyett kétirányú szűrést is alkalmazhat, amelyben a táblák egymást szűrik.Or you can apply bidirectional filtering, where each table filters the other.

A Power BI Desktop alapértelmezés szerint több-a-többhöz számosságot állít be, ha a meghatározása szerint egyik tábla sem tartalmaz egyedi értékeket a kapcsolatban részt vevő oszlopokban.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. Az ilyen esetekben egy figyelmeztető üzenet ellenőrzi, hogy valóban be akar-e állítani egy kapcsolatot, és a módosítás nem csak egy adatprobléma véletlen következménye.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.

Amikor például közvetlen kapcsolatot hozunk létre a CityData és a Sales táblák között—ahol a szűrés a CityData felől a Sales táblára irányul—, akkor a Power BI Desktop megjeleníti a Kapcsolat szerkesztése párbeszédpanelt: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:

Kapcsolat szerkesztése párbeszédpanel, Power BI Desktop

Az így keletkező Kapcsolat nézet ekkor a két tábla közötti közvetlen több-a-többhöz kapcsolatot jelenítené meg.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. A táblák megjelenése a Mezők listában, valamint a vizualizációk létrehozása utáni viselkedésük hasonló lesz ahhoz, mint amikor az áthidaló megoldást alkalmaztuk.The tables' appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. Az áthidaló megoldásban az egyedi State adatokat megjelenítő plusz tábla nincs láthatóvá téve.In the workaround, the extra table that displays the distinct State data isn't made visible. Ahogy korábban ismertettük, a State, Population, és Sales adatokat tartalmazó vizualizáció az alábbiként jelenne be:As described earlier, a visual that shows State, Population, and Sales data would be displayed:

A State, Population, és Sales táblák, Power BI Desktop

A több-a-többhöz számosságú kapcsolatok és a gyakoribb több-az-egyhez kapcsolatok közötti főbb eltérések a következők:The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • A megjelenő értékek nem tartalmaznak üres sort, amely a másik tábla nem egyező sorainak felel meg.The values shown don't include a blank row that accounts for mismatched rows in the other table. Olyan soroknak megfelelő értékek sincsenek, ahol a kapcsolatban használt oszlop a másik táblában null értéket tartalmaz.Also, the values don't account for rows where the column used in the relationship in the other table is null.

  • A RELATED() függvény nem használható, mert egynél több sor is kapcsolódhat.You can't use the RELATED() function, because more than one row could be related.

  • Az ALL() függvény használata egy táblán nem távolítja el a vele több-a-többhöz kapcsolatban álló, más táblákra alkalmazott szűrőket.Using the ALL() function on a table doesn't remove filters that are applied to other, related tables by a many-to-many relationship. Az előző példában az alábbi szkriptben látható módon definiált mérték nem távolítaná el a kapcsolódó CityData tábla oszlopaira alkalmazott szűrőket:In the preceding example, a measure that's defined as shown here wouldn't remove filters on columns in the related CityData table:

    Példaszkript

    Egy State, Sales és Sales total (összes értékesítés) adatokat feltüntető vizualizáció az alábbi eredményt mutatná:A visual showing State, Sales, and Sales total data would result in this graphic:

    Táblavizualizáció

Az előbbi eltéréseket szem előtt tartva győződjön meg arról, hogy az ALL(<Table>) függvényt használó számítások, amilyen a végösszeg %-a, a kívánt eredményt adják.With the preceding differences in mind, make sure the calculations that use ALL(<Table>), such as % of grand total, are returning the intended results.

Korlátozások és szempontokLimitations and considerations

A több-a-többhöz számosságú kapcsolatoknak és az összetett modelleknek erre a verziójára érvényes néhány korlátozás.There are a few limitations for this release of relationships with a many-many cardinality and composite models.

Az alábbi Live Connect- (többdimenziós) források nem használhatók összetett modellekkel: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
  • Power BI-adathalmazokPower BI datasets
  • Azure Analysis ServicesAzure Analysis Services

Ha ezekhez a többdimenziós forrásokhoz a DirectQuery használatával csatlakozik, nem tud más DirectQuery-forráshoz csatlakozni vagy importált adatokkal kombinálni.When you connect to these multidimensional sources by using DirectQuery, you can't connect to another DirectQuery source or combine it with imported data.

A DirectQuery használatára vonatkozó korlátozások a több-a-többhöz számosságú kapcsolatokra is érvényesek.The existing limitations of using DirectQuery still apply when you use relationships with a many-many cardinality. Sok ilyen korlátozás jelenleg táblánként értendő, a tábla tárolási módjától függően.Many limitations are now per table, depending upon the storage mode of the table. Egy importált tábla egy számított oszlopa például hivatkozhat más táblákra, egy DirectQuery-tábla számított oszlopai viszont továbbra is csak a táblán belüli oszlopokra hivatkozhatnak.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. Más korlátozások a modell egészére vonatkoznak, ha a modellen belül bármelyik tábla DirectQuery módban van.Other limitations apply to the whole model if any tables within the model are DirectQuery. A QuickInsights- és a Q&A-funkciók például nem érhetők el a modellben, ha a táblák bármelyikének tárolási módja 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.

Következő lépésekNext steps

Az összetett modellekkel és a DirectQueryvel kapcsolatos további információkért tekintse meg a következő cikkeket:For more information about composite models and DirectQuery, see the following articles: