Útmutatás kétirányú kapcsolatokhozBi-directional relationship guidance

Ez a cikk a Power BI Desktopot használó adatmodellezőknek szól.This article targets you as a data modeler working with Power BI Desktop. Ahhoz nyújt útmutatást, hogy mikor érdemes kétirányú modellkapcsolatot létrehozni.It provides you with guidance on when to create bi-directional model relationships. Kétirányú kapcsolat az, amely mindkét irányban szűr.A bi-directional relationship is one that filters in both directions.

Megjegyzés

A modellkapcsolatok bemutatása nem képezi a cikk részét.An introduction to model relationships is not covered in this article. Ha nincs tisztában a kapcsolatokkal, azok tulajdonságaival és konfigurálási módjával, először olvassa el a Modellbeli kapcsolatok a Power BI Desktopban című cikket.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.

Emellett fontos, hogy ismerje a csillagséma-kialakítást is.It's also important that you have an understanding of star schema design. További információ: A csillagséma és a Power BI-ban játszott szerepének a bemutatása című cikkben talál további információt.For more information, see Understand star schema and the importance for Power BI.

Általában ajánlott minél kevesebb kétirányú kapcsolatot használni.Generally, we recommend minimizing the use of bi-directional relationships. Ezek károsan befolyásolhatják a modell lekérdezési teljesítményét, és akár megtévesztő eredményeket is megjeleníthetnek a jelentés felhasználói számára.They can negatively impact on model query performance, and possibly deliver confusing experiences for your report users.

Három olyan helyzet van, ahol a kétirányú szűrés megoldás lehet bizonyos követelményekre:There are three scenarios when bi-directional filtering can solve specific requirements:

Speciális modellkapcsolatokSpecial model relationships

A kétirányú kapcsolatok fontos szerepet játszanak az alábbi két speciális modellkapcsolat-típus létrehozásakor:Bi-directional relationships play an important role when creating the following two special model relationship types:

  • Egy-az-egyhez: Minden egy-az-egyhez kapcsolatnak kétirányúnak kell lennie – másként nem konfigurálható.One-to-one: All one-to-one relationships must be bi-directional—it isn't possible to configure otherwise. Ilyen típusú kapcsolatokat általában nem ajánlott létrehozni.Generally, we don't recommend creating these types of relationships. Ennek teljes leírását és a helyette alkalmazható kiviteli módokat az Útmutató egy-az-egyhez kapcsolatokhoz című cikk tartalmazza.For a complete discussion and alternative designs, see One-to-one relationship guidance.
  • Több-a-többhöz: Két dimenzió típusú tábla illesztéséhez egy köztes táblára van szükség.Many-to-many: When relating two dimension-type tables, a bridging table is required. Kétirányú szűrő szükséges annak biztosításához, hogy a szűrők tovább legyenek adva a köztes táblán keresztül.A bi-directional filter is required to ensure filters propagate across the bridging table. További információ: Útmutató a több-a-többhöz kapcsolatokhoz (Több-a-többhöz dimenziók összekapcsolása).For more information, see Many-to-many relationship guidance (Relate many-to-many dimensions).

Szeletelőelemek „adatokkal”Slicer items "with data"

Kétirányú kapcsolatokkal olyan szűrők állíthatók elő, amelyek az adatok tárolási helyén korlátozzák az elemeket.Bi-directional relationships can deliver slicers that limit items to where data exists. (Ha jól ismeri az Excel-kimutatásokat és -szeletelőket, ez az alapértelmezett viselkedés, ha az adatok forrása egy Power BI-adathalmaz vagy egy Analysis Services-modell.) Hogy ez mit jelent, annak magyarázatához először vizsgáljuk meg a következő modelldiagramot.(If you're familiar with Excel PivotTables and slicers, it's the default behavior when sourcing data from a Power BI dataset, or an Analysis Services model.) To help explain what it means, first consider the following model diagram.

Három táblázatból álló modellt ábrázoló diagram.

Az első tábla neve Customer, és három oszlopból áll: Country-Region (Ország-Régió), Customer (Ügyfél) és CustomerCode (Ügyfélkód).The first table is named Customer, and it contains three columns: Country-Region, Customer, and CustomerCode. A második tábla neve Product, és három oszlopból áll: Color (Szín), Product (Termék) és SKU (Termékváltozat).The second table is named Product, and it contains three columns: Color, Product, and SKU. A harmadik tábla neve Sales, és négy oszlopból áll: CustomerCode (Ügyfélkód), OrderDate (Rendelés dátuma), Quantity (Mennyiség) és SKU (Termékváltozat).The third table is named Sales, and it contains four columns: CustomerCode, OrderDate, Quantity, and SKU. A Customer és a Product tábla dimenzió típusú, és mindkettő egy-az-egyhez kapcsolatban áll a Sales táblával.The Customer and Product tables are dimension-type tables, and each has a one-to-many relationship to the Sales table. Mindegyik kapcsolat egy irányban szűr.Each relationship filters in a single direction.

A kétirányú szűrés működésének bemutatása érdekében a modelldiagramot úgy módosítottuk, hogy láthatók legyenek benne a tábla sorai.To help describe how bi-directional filtering works, the model diagram has been modified to reveal the table rows. A cikkben szereplő összes példa ezekre az adatokra épül.All examples in this article are based on this data.

Megjegyzés

A táblázatsorok nem jeleníthetők meg a Power BI Desktop modelldiagramjában.It's not possible to display table rows in the Power BI Desktop model diagram. Ebben a cikkben az egyértelmű példák jegyében jelenítettük meg őket.It's done in this article to support the discussion with clear examples.

A táblák sorait megjelenítő modellt ábrázoló diagram.

A három tábla sorainak adatai a következő listában találhatók:The row details for the three tables are described in the following bulleted list:

  • A Customer táblázat két sort tartalmaz:The Customer table has two rows:
    • CustomerCode CUST-01, Customer Customer-1, Country-Region United StatesCustomerCode CUST-01, Customer Customer-1, Country-Region United States
    • CustomerCode CUST-02, Customer Customer-2, Country-Region AustraliaCustomerCode CUST-02, Customer Customer-2, Country-Region Australia
  • A Product táblának három sora van:The Product table has three rows:
    • SKU CL-01, Product T-shirt (póló), Color Green (zöld)SKU CL-01, Product T-shirt, Color Green
    • SKU CL-02, Product Jeans (farmer), Color Blue (kék)SKU CL-02, Product Jeans, Color Blue
    • SKU AC-01, Product Hat (sapka), Color Blue (kék)SKU AC-01, Product Hat, Color Blue
  • A Sales táblának három sora van:The Sales table has three rows:
    • OrderDate 2019.01.01., CustomerCode CUST-01, SKU CL-01, Quantity 10OrderDate January 1 2019, CustomerCode CUST-01, SKU CL-01, Quantity 10
    • OrderDate 2019.02.02., CustomerCode CUST-01, SKU CL-02, Quantity 20OrderDate February 2 2019, CustomerCode CUST-01, SKU CL-02, Quantity 20
    • OrderDate 2019.03.03., CustomerCode CUST-02, SKU CL-01, Quantity 30OrderDate March 3 2019, CustomerCode CUST-02, SKU CL-01, Quantity 30

Vizsgáljuk meg a következő jelentésoldalt.Now consider the following report page.

Három vizualizációt tartalmazó jelentésoldalt ábrázoló diagram.

Az oldal két szeletelőből és egy kártyavizualizációból áll.The page consists of two slicers and a card visual. Ez első szeletelő a Country-Region mezőre vonatkozik, és két eleme van: Australia (Ausztrália) és United States (USA).The first slicer is for Country-Region and it has two items: Australia and United States. Jelenleg Ausztrália szerint szeletel.It currently slices by Australia. A második szeletelő a Product mezőre vonatkozik, és három eleme van: Hat (sapka), Jeans (farmer) és T-shirt (póló).The second slicer is for Product, and it has three items: Hat, Jeans, and T-shirt. Egy elem sincs kijelölve (tehát nincs termék szerinti szűrés).No items are selected (meaning no products are filtered). A kártyavizualizáción leolvasható mennyiség 30.The card visual displays a quantity of 30.

Amikor a jelentés felhasználója Ausztrália szerint szeletel, a Product szeletelőt érdemes az olyan elemek megjelenítésére korlátozni, amelyeknél az adatok kapcsolódnak az ausztráliai értékesítésekhez.When report users slice by Australia, you might want to limit the Product slicer to display items where data relates to Australian sales. Ezt jelenti az „adatokkal rendelkező” szeletelőelemek mutatása.It's what's meant by showing slicer items "with data". Ez a viselkedés úgy idézhető elő, hogy a Product és a Sales tábla közötti kapcsolatot kétirányú szűrésre konfigurálja.You can achieve this behavior by configuring the relationship between the Product and Sales table to filter in both directions.

Egy modellnek a Product és a Sales tábla közötti, most már kétirányú kapcsolatot ábrázoló diagramja.

A Product szeletelőn csak egyetlen elem látható: T-shirt.The Product slicer now lists a single item: T-shirt. Ez az elem felel meg az egyetlen olyan terméknek, amelyet ausztrál ügyfélnek adtak el.This item represents the only product sold to Australian customers.

Három vizualizációt tartalmazó jelentésoldalt ábrázoló diagram, kiemelt Product szeletelővel. Ezek részleteit a következő bekezdés ismerteti.

Ajánlott először gondosan mérlegelni, hogy ez a kivitel megfelel-e a jelentés felhasználóinak.We first suggest you consider carefully whether this design works for your report users. Néhány felhasználó következetlennek találhatja a felületet.Some report users find the experience confusing. Nem értik, hogy miért jelennek meg és tűnnek el szeletelőelemek dinamikusan, amíg ők a másik szeletelőt kezelik.They don't understand why slicer items dynamically appear or disappear when they interact with other slicers.

Ha úgy dönt, hogy az „adatokkal rendelkező” szeletelőelemeket jeleníti meg, nem javasolt a kétirányú kapcsolatok konfigurálása.If you do decide to show slicer items "with data", we don't recommend you configure bi-directional relationships. A kétirányú kapcsolatok számításigénye nagyobb, ezért hátrányosan befolyásolhatják a lekérdezési teljesítményt – különösen akkor, h a modellen belüli kétirányú kapcsolatok száma tovább nő.Bi-directional relationships require more processing and so they can negatively impact on query performance—especially as the number of bi-directional relationships in your model increases.

Ugyanez az eredmény jobb módszerrel is elérhető: Kétirányú szűrők használata helyett vizualizációszintű szűrőt alkalmazhat magára a Product szeletelőre.There's a better way to achieve the same result: Instead of using bi-directional filters, you can apply a visual-level filter to the Product slicer itself.

Most tegyük fel, hogy Product és a Sales tábla közötti kapcsolat már nem szűr mindkét irányban.Let's now consider that the relationship between the Product and Sales table no longer filters in both directions. A Sales táblához ugyanakkor felvettük az alábbi mértéket.And, the following measure definition has been added to the Sales table.

Total Quantity = SUM(Sales[Quantity])

A Product szeletelő „adatokkal rendelkező” elemeinek megjelenítéséhez elég a Total Quantity mértékre szűrni az „is not blank” (nem üres) feltétellel.To show the Product slicer items "with data", it simply needs to be filtered by the Total Quantity measure using the "is not blank" condition.

Diagram, amelyen az látható, hogy a Product szeletelő Szűrők panelje már a „Total Quantity is not blank” feltétellel szűr.

Dimenziók közötti elemzésDimension-to-dimension analysis

A kétirányú kapcsolatokat szerepeltető másik helyzet köztes táblaként kezel egy ténytáblát.A different scenario involving bi-directional relationships treats a fact-type table like a bridging table. Ezen a módon támogatja egy dimenziótábla adatainak elemzését egy másik dimenziótábla szűrőkörnyezetében.This way, it supports analyzing dimension-type table data within the filter context of a different dimension-type table.

A cikk példamodellje alapján gondolja át, hogy válaszolhatók meg a következő kérdések:Using the example model in this article, consider how the following questions can be answered:

  • Hányféle színt értékesítettek ausztráliai ügyfeleknek?How many colors were sold to Australian customers?
  • Hány országban vásároltak farmert?How many countries purchased jeans?

Mindkét kérdés megválaszolható a köztes ténytábla adatainak összesítése nélkül.Both questions can be answered without summarizing data in the bridging fact-type table. Arra azonban szükség van, hogy a szűrők tovább legyenek adva az egyik dimenziótáblából a másikba.They do, however, require that filters propagate from one dimension-type table to the other. Ha a szűrők a ténytáblán keresztül tovább vannak adva, a dimenziótáblák oszlopainak összesítése megvalósítható a DISTINCTCOUNT DAX-függvénnyel – és akár a MIN és a MAX DAX-függvénnyel is.Once filters propagate via the fact-type table, summarization of dimension-type table columns can be achieved using the DISTINCTCOUNT DAX function—and possibly the MIN and MAX DAX functions.

Mivel a ténytábla köztes táblaként szerepel, a két dimenziótábla illesztésekor eljárhat a több-a-többhöz kapcsolatokhoz nyújtott útmutatás alapján.As the fact-type table behaves like a bridging table, you can follow the many-to-many relationship guidance to relate two dimension-type tables. Ehhez legalább egy kapcsolatot úgy kell konfigurálni, hogy mindkét irányba szűrjön.It will require configuring at least one relationship to filter in both directions. További információ: Útmutató a több-a-többhöz kapcsolatokhoz (Több-a-többhöz dimenziók összekapcsolása).For more information, see Many-to-many relationship guidance (Relate many-to-many dimensions).

Ez a megoldás azonban a cikkben korábban leírtak alapján feltehetően károsan befolyásolja a teljesítményt, és a felhasználó a szeletelőelemek „adatokkal” esettel járó következményeket tapasztalja.However, as already described in this article, this design will likely result in a negative impact on performance, and the user experience consequences related to slicer items "with data". Ezért ajánlott a kétirányú szűrést inkább egy mértékdefinícióban aktiválni a CROSSFILTER DAX-függvénnyel.So, we recommend that you activate bi-directional filtering in a measure definition by using the CROSSFILTER DAX function instead. A CROSSFILTER felhasználható a szűrési irány módosítására – vagy akár a kapcsolat letiltására – egy kifejezés kiértékelése során.The CROSSFILTER function can be used to modify filter directions—or even disable the relationship—during the evaluation of an expression.

Figyelje meg a Sales táblához felvett alábbi mértékdefiníciót.Consider the following measure definition added to the Sales table. Ebben a példában a Customer és a Sales tábla közötti modellkapcsolat egyirányú szűrésre van konfigurálva.In this example, the model relationship between the Customer and Sales tables has been configured to filter in a single direction.

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

A Different Countries Sold mértékkifejezés kiértékelése során a Customer és a Sales tábla közötti kapcsolat mindkét irányban szűr.During the evaluation of the Different Countries Sold measure expression, the relationship between the Customer and Sales tables filters in both directions.

Az alábbi táblázatos vizualizáció az egyes értékesített termékek statisztikáit mutatja be.The following table visual present statistics for each product sold. A Quantity oszlop egyszerűen a mennyiségek összege.The Quantity column is simply the sum of quantity values. A Different Countries Sold oszlop a terméket megvásároló összes ügyfél eltérő ország-régió értékeinek a darabszáma.The Different Countries Sold column represents the distinct count of country-region values of all customers who have purchased the product.

Diagram, amelyen az látható, hogy a táblázatos vizualizációban két termék van felsorolva.

Következő lépésekNext steps

Ezzel a cikkel kapcsolatosan a következő forrásanyagokban talál további információt:For more information related to this article, check out the following resources: