Útmutató egy-az-egyhez kapcsolatokhozOne-to-one 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. Az egy-az-egyhez típusú modellkapcsolatokkal végzett munkához nyújt útmutatást.It provides you with guidance on working with one-to-one model relationships. Egy-az-egyhez kapcsolat akkor hozható létre, ha mindkét tábla tartalmaz közös egyéni értékekből álló oszlopot.A one-to-one relationship can be created when both tables each contain a column of common and unique values.

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.

Egy-az-egyhez kapcsolat kétféle használati helyzetben szerepelhet:There are two scenarios that involve one-to-one relationships:

  • Ténybe ágyazott dimenziók: Ténybe ágyazott dimenzió ténytáblából származtatható.Degenerate dimensions: You can derive a degenerate dimension from a fact-type table.

  • Több táblára kiterjedő soradatok: Egyetlen üzleti entitás vagy tárgy kettő (vagy több) modelltáblaként van betöltve, például azért, mert az adatai különböző adattárakból származnak.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. Ez gyakran előfordulhat dimenziótáblák esetében.This scenario can be common for dimension-type tables. Lehetséges például, hogy a fő termékadatok az éles értékesítési rendszerben vannak tárolva, a kiegészítő termékadatokat viszont más forrás tárolja.For example, master product details are stored in an operational sales system, and supplementary product details are stored in a different source.

    Két ténytábla között azonban nem szokás egy-az-egyhez kapcsolatot kialakítani.It's unusual, however, that you'd relate two fact-type tables with a one-to-one relationship. Ennek az az oka, hogy a két ténytábla dimenziószámának és részletességének meg kell egyeznie.It's because both fact-type tables would need to have the same dimensionality and granularity. Emellett ahhoz, hogy a modellkapcsolat létrehozható legyen, mindkét ténytáblának egyedi oszlopokat kell tartalmaznia.Also, each fact-type table would need unique columns to allow the model relationship to be created.

Ténybe ágyazott dimenziókDegenerate dimensions

Ha egy ténytábla oszlopai alapján végez szűrést vagy csoportosítást, érdemes lehet azokat külön táblákként elérhetővé tenni.When columns from a fact-type table are used for filtering or grouping, you can consider making them available in a separate table. Így elkülönítheti a szűréshez vagy csoportosításhoz használt oszlopokat azoktól, amelyeket ténysorok összesítéséhez használ.This way, you separate columns used for filter or grouping, from those columns used to summarize fact rows. Az elkülönítés előnyei:This separation can:

  • Kisebb tárigényReduce storage space
  • Egyszerűbb modellbeli számításokSimplify model calculations
  • A jobb lekérdezési teljesítmény elősegítéseContribute to improved query performance
  • Szemléletesebb Mezők panel a jelentéskészítők számáraDeliver a more intuitive Fields pane experience to your report authors

Vegyünk például egy értékesítési táblát, amely két oszlopban tárolja az értékesítési rendelések adatait.Consider a source sales table that stores sales order details in two columns.

Értékesítési tábla sorai.

Az OrderNumber oszlop a rendelésszámot tartalmazza, az OrderLineNumber oszlop pedig a rendelésen belüli sor sorszámát.The OrderNumber column stores the order number, and the OrderLineNumber column stores a sequence of lines within the order.

Figyelje meg az alábbi modelldiagramon, hogy a rendelésszám és a sorszám nem lett betöltve a Sales táblába.In the following model diagram, notice that the order number and order line number columns haven't been loaded to the Sales table. Ehelyett az ezek értékéből létrehozott helyettes kulcs szerepel a SalesOrderLineID oszlopban.Instead, their values were used to create a surrogate key column named SalesOrderLineID. (A kulcs értéke úgy lett kiszámítva, hogy a rendelésszám 1000-szereséhez hozzáadjuk a sor számát.)(The key value is calculated by multiplying the order number by 1000, and then adding the order line number.)

A modelldiagram két táblázatot tartalmaz: Sales (Értékesítések) és Sales Order (Értékesítési rendelések).

A Sales Order tábla jól használható felületet kínál a jelentéskészítőknek három oszlopával: Sales Order (Értékesítési rendelés), Sales Order Line (Értékesítési megrendelés sora) és Line Number (Sor száma).The Sales Order table provides a rich experience for report authors with three columns: Sales Order, Sales Order Line, and Line Number. Hierarchiát is tartalmaz.It also includes a hierarchy. Az ilyen táblák támogatják az olyan jelentések tervezését, amelyekhez a rendelések és a rendelések sorai alapján kell szűrni, csoportosítani vagy részletezni.These table resources support report designs that need to filter, group by, or drill down through orders and order lines.

Mivel a Sales Order tábla az értékesítési adatokból van származtatva, mindkét táblának pontosan ugyanannyi sorból kell állnia.As the Sales Order table is derived from the sales data, there should be exactly the same number of rows in each table. Emellett a SalesOrderLineID oszlopokban biztosan vannak egyező értékek.Further, there should be matching values between each SalesOrderLineID column.

Több táblára kiterjedő soradatokRow data spans across tables

Vegyünk egy példát, amelyben két egy-az-egyhez kapcsolatban álló dimenziótábla szerepel: Product (Termék) és Product Category (Termékkategória).Consider an example involving two one-to-one related dimension-type tables: Product, and Product Category. Mindkét tábla importált adatokat jelenít meg, és tartalmaz egy egyedi értékekből álló SKU (Termékváltozat) oszlopot.Each table represents imported data and has a SKU (Stock-Keeping Unit) column containing unique values.

Az alábbi ábrán a két tábla modelldiagramja látható.Here's a partial model diagram of the two tables.

Két táblát tartalmazó modelldiagram.

Az első tábla neve Product, és három oszlopból áll: Color (Szín), Product (Termék) és SKU (Termékváltozat).The first table is named Product, and it contains three columns: Color, Product, and SKU. A második tábla neve Product Category, és két oszlopból áll: Category (Kategória) és SKU (Termékváltozat).The second table is named Product Category, and it contains two columns: Category, and SKU. Az egy-az-egyhez kapcsolat a két SKU oszlopot kapcsolja össze.A one-to-one relationship relates the two SKU columns. A kapcsolat mindkét irányba szűr, ami egy-az-egyhez kapcsolatok esetén mindig így van.The relationship filters in both directions, which is always the case for one-to-one relationships.

A kapcsolati szűrőpropagálás működésének bemutatása érdekében a modelldiagramot úgy módosítottuk, hogy láthatók legyenek benne a táblázat sorai.To help describe how the relationship filter propagation 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 modelldiagramban most látszanak a táblázatsorok.

A két táblázat sorainak adatai a következő listában találhatók:The row details for the two tables are described in the following bulleted list:

  • 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 Product Category táblának két sora van:The Product Category table has two rows:
    • SKU CL-01, Category Clothing (ruházat)SKU CL-01, Category Clothing
    • SKU AC-01, Category Accessories (kiegészítők)SKU AC-01, Category Accessories

Megfigyelheti, hogy a Product Category tábla nem tartalmaz a CL-02 SKU-hoz tartozó sort.Notice that the Product Category table doesn't include a row for the product SKU CL-02. A sor hiányának következményeit a cikk egy későbbi szakasza ismerteti.We'll discuss the consequences of this missing row later in this article.

A jelentéskészítők a két tábla termékekkel kapcsolatos mezőit találják meg a Mezők panelen: Product (Termék) és Product Category (Termékkategória).In the Fields pane, report authors will find product-related fields in two tables: Product and Product Category.

A Mezők panelen mindkét tábla kibontva jelenik meg, az oszlopok pedig mezőkként vannak felsorolva, a Termék és a Termékkategória kibontva.

Lássuk, mi történik, ha a két tábla mezőit egy táblázatos vizualizációhoz adjuk.Let's see what happens when fields from both tables are added to a table visual. Ebben a példában az SKU oszlop forrása a Product tábla.In this example, the SKU column is sourced from the Product table.

A táblázatvizualizáció négy oszlopból áll: SKU (Termékváltozat), Product (Termék), Color (Szín) és Category (Kategória).

Figyelje meg, hogy a CL-02 SKU-hoz tartozó termék Category értéke BLANK (üres).Notice that the Category value for product SKU CL-02 is BLANK. Ez azért van így, mert a Product Category tábla nem tartalmaz erre a termékre vonatkozó sort.It's because there's no row in the Product Category table for this product.

JavaslatokRecommendations

Ha csak lehetséges, ajánlott kerülni az egy-az-egyhez kapcsolatok létrehozását, ha a soradatok több modelltáblára terjednek ki.When possible, we recommend you avoid creating one-to-one model relationships when row data spans across model tables. Ezt az indokolja, hogy ez a kivitel a következőkhöz vezethet:It's because this design can:

  • A Mezők panel zsúfoltsága, a szükségesnél több tábla megjelenítésévelContribute to Fields pane clutter, listing more tables than necessary
  • A jelentéskészítők nehezen találják meg a kapcsolódó mezőket, mert azok több táblában vannak elosztvaMake it difficult for report authors to find related fields, because they're distributed across multiple tables
  • A hierarchiák létrehozásának lehetősége korlátozott, mert azok szintjei egyazon tábla oszlopain alapulnakLimit the ability to create hierarchies, as their levels must be based on columns from the same table
  • Váratlan eredmények előállítása, ha a táblák sorai között nem teljes az egyezésProduce unexpected results when there isn't a complete match of rows between the tables

A pontos javaslatok eltérőek aszerint, hogy az egy-az-egyhez kapcsolat forráscsoportokon belüli vagy forráscsoportok közötti.Specific recommendations differ depending on whether the one-to-one relationship is intra source group or cross source group. A kapcsolatok kiértékeléséről a Modellkapcsolatok a Power BI Desktopban (Kapcsolatok kiértékelése) című cikk nyújt bővebb információt.For more information about relationship evaluation, see Model relationships in Power BI Desktop (Relationship evaluation).

Forráscsoporton belüli egy-az-egyhez kapcsolatIntra source group one-to-one relationship

Ha forráscsoporton belüli egy-az-egyhez kapcsolat áll fenn a táblák között, ajánlott az adatokat egyetlen modelltáblában egyesíteni.When a one-to-one intra source group relationship exists between tables, we recommend consolidating the data into a single model table. Ez a Power Query-lekérdezések egyesítésével valósítható meg.It's done by merging the Power Query queries.

Az alábbi lépések az egy-az-egyhez kapcsolatú adatok egyesítésére és modellezésére kínálnak módot:The following steps present a methodology to consolidate and model the one-to-one related data:

  1. Lekérdezések egyesítése: A két lekérdezés egyesítésekor vegye figyelembe az egyes lekérdezésekben szereplő adatok teljességét.Merge queries: When combining the two queries, give consideration to the completeness of data in each query. Ha az egyik lekérdezés a sorok teljes halmazát tartalmazza (például egy fő lista), egyesítse ezzel a másik lekérdezést.If one query contains a complete set of rows (like a master list), merge the other query with it. Az egyesítési átalakítást konfigurálja úgy, hogy bal oldali külső illesztést használjon, amely az alapértelmezett illesztési típus.Configure the merge transformation to use a left outer join, which is the default join type. Ez az illesztési típus biztosítja, hogy az első lekérdezés összes sora megmarad, kiegészítve a második lekérdezés egyező soraival.This join type ensures you'll keep all rows of the first query, and supplement them with any matching rows of the second query. A második lekérdezés összes szükséges oszlopát bontsa ki az első lekérdezésbe.Expand all required columns of the second query into the first query.

  2. Lekérdezések betöltésének letiltása: Mindig tiltsa le a második lekérdezés betöltését.Disable query load: Be sure to disable the load of the second query. Így az nem tölti be az eredményét modelltáblaként.This way, it won't load its result as a model table. Ez a konfiguráció csökkenti az adatmodell tárolási méretét, és hozzájárul a Mezők panel zsúfoltságának csökkentéséhez.This configuration reduces the data model storage size, and helps to unclutter the Fields pane.

    Példánkban a jelentéskészítők már csak egyetlen, Product nevű táblát látnak a Mezők panelen.In our example, report authors now find a single table named Product in the Fields pane. Ez tartalmazza a termékekkel kapcsolatos összes mezőt.It contains all product-related fields.

    A Mezők panelen mindkét tábla kibontva jelenik meg, az oszlopok pedig mezőkként vannak felsorolva, a Termék kibontva.

  3. Hiányzó értékek pótlása: Ha a második lekérdezésben nem egyező sorok szerepelnek, NULL értékek jelennek meg az azokból származó oszlopokban.Replace missing values: If the second query has unmatched rows, NULLs will appear in the columns introduced from it. Ha mód van rá, a NULL értékeket ajánlott egységes értékre cserélni.When appropriate, consider replacing NULLs with a token value. A hiányzó értékek pótlása különösen akkor lényeges, ha a jelentéskészítők az oszlopértékek alapján végeznek szűrést vagy csoportosítást, ilyenkor ugyanis BLANK (üres) értékek jelenhetnek meg a jelentésvizualizációkon.Replacing missing values is especially important when report authors filter or group by the column values, as BLANKs could appear in report visuals.

    Figyelje meg, hogy az alábbi táblázatos vizualizációban a CL-02 termékváltozatú termék kategóriája [Undefined] (Nincs meghatározva).In the following table visual, notice that the category for product SKU CL-02 now reads [Undefined]. A lekérdezésben a NULL értékeket erre az egységes szöveges értékre cserélték.In the query, null categories were replaced with this token text value.

    A táblázatos vizualizáció négy oszlopból áll: SKU (Termékváltozat), Product (Termék), Color (Szín) és Category (Kategória).

  4. Hierarchiák létrehozása: Ha a már egyesített tábla oszlopai között kapcsolatok állnak fenn, érdemes hierarchiákat létrehozni.Create hierarchies: If relationships exist between the columns of the now-consolidated table, consider creating hierarchies. Így a jelentéskészítők könnyen felismerhetik a jelentésvizualizációk részletezési lehetőségeit.This way, report authors will quickly identify opportunities for report visual drilling.

    Ebben a példában a jelentéskészítők egy kétszintű hierarchiát használhatnak: Category (Kategória) és Product (Termék).In our example, report authors now can use a hierarchy that has two levels: Category and Product.

    A Mezők panelen mindkét tábla kibontva jelenik meg, az oszlopok pedig mezőkként vannak felsorolva, a Termékek kibontva.

Az egy táblában való egyesítés akkor is ajánlott, ha a mezőket szívesen rendszerezi külön táblák segítségével.If you like how separate tables help organize your fields, we still recommend consolidating into a single table. A mezők ugyanúgy rendszerezhetők a megjelenítési mappák használatával.You can still organize your fields, but by using display folders instead.

Ebben a példában a jelentéskészítők a Category mezőt a Marketing megjelenítési mappában találhatják meg.In our example, report authors can find the Category field within the Marketing display folder.

A Mezők panelen a Category mező látható a Marketing nevű megjelenítési mappában.

Ha ennek ellenére úgy dönt, hogy forráscsoporton belüli egy-az-egyhez kapcsolatokat definiál a modellben, lehetőség szerint ellenőrizze, hogy a kapcsolódó táblákban egyező sorok vannak.Should you still decide to define one-to-one intra source group relationships in your model, when possible, ensure there are matching rows in the related tables. Mivel a forráscsoporton belüli egy-az-egyhez kapcsolatok normál kapcsolatokként vannak kiértékelve, az adatintegritási problémák a jelentésvizualizációkban megjelenő BLANK értékekhez vezethetnek.As a one-to-one intra source group relationship is evaluated as a regular relationship, data integrity issues could surface in your report visuals as BLANKs. (A BLANK csoportosításra a cikkben elsőként bemutatott táblázatos vizualizációban láthat példát.)(You can see an example of a BLANK grouping in the first table visual presented in this article.)

Forráscsoportok közötti egy-az-egyhez kapcsolatCross source group one-to-one relationship

Ha a táblák között forráscsoportok közötti egy-az-egyhez kapcsolat áll fenn, akkor a modell csak abban az esetben építhető fel másként, ha az adatokat előre egyesítette az adatforrásokban.When a one-to-one cross source group relationship exists between tables, there's no alternative model design—unless you pre-consolidate the data in your data sources. A Power BI korlátozott kapcsolatként értékeli ki az egy-az-egyhez modellkapcsolatot.Power BI will evaluate the one-to-one model relationship as a limited relationship. Emiatt fontos ellenőrizni, hogy a kapcsolódó táblák illeszkedő sorokat tartalmaznak, a párosítatlan sorok ugyanis nem jelennek meg a lekérdezés eredményében.Therefore, take care to ensure there are matching rows in the related tables, as unmatched rows will be eliminated from query results.

Az alábbi ábrán annak eredménye látható, hogy a táblázatos vizualizációhoz mindkét táblából vettünk fel mezőket, a táblák között pedig korlátozott kapcsolat áll fenn.Let's see what happens when fields from both tables are added to a table visual, and a limited relationship exists between the tables.

A táblázatos vizualizáció négy oszlopból áll: SKU (Termékváltozat), Product (Termék), Color (Szín) és Category (Kategória).

A táblázatban csak két sor jelenik meg.The table displays two rows only. A CL-02 termékváltozat hiányzik, annak ugyanis nem felel meg sor a Product Category táblában.Product SKU CL-02 is missing because there's no matching row in the Product Category table.

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: