Útmutató a több-a-többhöz kapcsolatokhozMany-to-many 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. Három különböző több-a-többhöz típusú modellezési forgatókönyvet ismertet.It describes three different many-to-many modeling scenarios. Emellett útmutatást nyújt a kapcsolatok sikeres kialakításához.It also provides you with guidance on how to successfully design for them in your models.

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.

Valójában a több-a-többhöz típus használata három helyzetben képzelhető el.There are, in fact, three many-to-many scenarios. Ezek a következő esetekben merülhetnek fel:They can occur when you're required to:

Több-a-többhöz típusú dimenziók összekapcsolásaRelate many-to-many dimensions

Tekintsünk meg egy példát az első több-a-többhöz típusú forgatókönyvről.Let's consider the first many-to-many scenario type with an example. A klasszikus forgatókönyv két entitást kapcsol össze: banki ügyfeleket és bankszámlákat.The classic scenario relates two entities: bank customers and bank accounts. Az ügyfelek több bankszámlával is rendelkezhetnek, egy bankszámlához pedig több ügyfél is tartozhat.Consider that customers can have multiple accounts, and accounts can have multiple customers. Ha egy számlához több ügyfél tartozik, őket általában közös számlatulajdonosnak nevezzük.When an account has multiple customers, they're commonly called joint account holders.

Az ilyen entitások modellezése egyszerű.Modeling these entities is straight forward. Egy dimenzió típusú tábla tárolja a számlákat, és egy másik az ügyfeleket.One dimension-type table stores accounts, and another dimension-type table stores customers. Ahogy a dimenzió típusú tábláknál ez jellemző, minden tábla tartalmaz egy azonosító oszlopot.As is characteristic of dimension-type tables, there's an ID column in each table. A két tábla közötti kapcsolat modellezéséhez egy harmadik táblára van szükség.To model the relationship between the two tables, a third table is required. Ezt a táblázatot általában áthidaló táblának nevezzük.This table is commonly referred to as a bridging table. Ebben a példában ez egy-egy sorban tárolja az ügyfél–számla párokat.In this example, it's purpose is to store one row for each customer-account association. Érdekes módon, ha ez a tábla csak azonosító oszlopokat tartalmaz, tények nélküli ténytáblának nevezzük.Interestingly, when this table only contains ID columns, it's called a factless fact table.

Íme egy egyszerű modelldiagram a három tábláról.Here's a simplistic model diagram of the three tables.

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

Az első táblázat neve Account, és két oszlopot tartalmaz: AccountID és Account.The first table is named Account, and it contains two columns: AccountID and Account. A második táblázat neve AccountCustomer, és két oszlopot tartalmaz: AccountID és CustomerID.The second table is named AccountCustomer, and it contains two columns: AccountID and CustomerID. A harmadik táblázat neve Customer, és két oszlopot tartalmaz: CustomerID és Customer.The third table is named Customer, and it contains two columns: CustomerID and Customer. A táblák között nincs kapcsolat.Relationships don't exist between any of the tables.

Kettő egy-a-többhöz kapcsolatot adunk a táblákhoz, hogy összekössük azokat.Two one-to-many relationships are added to relate the tables. Íme az összekapcsolt táblák frissített modelldiagramja.Here's an updated model diagram of the related tables. Hozzáadtunk egy Transaction nevű ténytáblát is.A fact-type table named Transaction has been added. Ez fióktranzakciókat tartalmaz.It records account transactions. Az áthidaló táblázat és az összes azonosító oszlop rejtve van.The bridging table and all ID columns have been hidden.

A már négy táblázatot tartalmazó modellt ábrázoló diagram.

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.

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 négy táblázat sorainak adatai a következő listában találhatók:The row details for the four tables are described in the following bulleted list:

  • Az Account táblázat két sorból áll:The Account table has two rows:
    • Az AccountID 1 az Account-01-hez tartozikAccountID 1 is for Account-01
    • Az AccountID 2 az Account-02-höz tartozikAccountID 2 is for Account-02
  • A Customer táblázat két sort tartalmaz:The Customer table has two rows:
    • A CustomerID 91 a Customer-91-hez tartozikCustomerID 91 is for Customer-91
    • A CustomerID 92 a Customer-92-höz tartozikCustomerID 92 is for Customer-92
  • Az AccountCustomer táblázat három sorból áll:The AccountCustomer table has three rows:
    • Az AccountID 1 a CustomerID 91-hez van társítvaAccountID 1 is associated with CustomerID 91
    • Az AccountID 1 a CustomerID 92-höz van társítvaAccountID 1 is associated with CustomerID 92
    • A 2-es AccountID a 92-es CustomerID-hoz van társítva.AccountID 2 is associated with CustomerID 92
  • A Transaction táblázat három sort tartalmaz:The Transaction table has three rows:
    • Date January 1 2019, AccountID 1, Amount 100Date January 1 2019, AccountID 1, Amount 100
    • Date February 2 2019, AccountID 2, Amount 200Date February 2 2019, AccountID 2, Amount 200
    • Date March 3 2019, AccountID 1, Amount -25Date March 3 2019, AccountID 1, Amount -25

Nézzük meg, mi történik a modell lekérdezése esetén.Let's see what happens when the model is queried.

Az alábbiakban a Transaction tábla Amount oszlopát összegző két vizualizációt láthat.Below are two visuals that summarize the Amount column from the Transaction table. Az első vizualizáció bankszámla szerint csoportosít, az Amount oszlopok összege így a számlaegyenlegnek felel meg.The first visual groups by account, and so the sum of the Amount columns represents the account balance. A második vizualizáció ügyfél szerint csoportosít, az Amount oszlopok összege így az ügyfélegyenlegnek felel meg.The second visual groups by customer, and so the sum of the Amount columns represents the customer balance.

Két egymás melletti jelentésvizualizációt ábrázoló diagram.

Az első vizualizáció neve Account Balance (Számlaegyenleg), és két oszlopot tartalmaz: Account és Amount.The first visual is titled Account Balance, and it has two columns: Account and Amount. Ennek eredménye a következő:It displays the following result:

  • Az Account-01 egyenlege 75Account-01 balance amount is 75
  • Az Account-02 egyenlege 200Account-02 balance amount is 200
  • Az összeg 275The total is 275

A második vizualizáció neve Customer Balance (Ügyfélegyenleg), és két oszlopot tartalmaz: Customer és Amount.The second visual is titled Customer Balance, and it has two columns: Customer and Amount. Ennek eredménye a következő:It displays the following result:

  • A Customer-91 egyenlege 275Customer-91 balance amount is 275
  • A Customer-92 egyenlege 275Customer-92 balance amount is 275
  • Az összeg 275The total is 275

A táblázatsorokra és az Account Balance vizualizációra pillantva láthatjuk, hogy az eredmény helyes a bankszámlák és a végösszeg szempontjából is.A quick glance at the table rows and the Account Balance visual reveals that the result is correct, for each account and the total amount. Ez azért van, mert a számlacsoportosítások a számla Transaction táblázatának szűrőpropagálását eredményezik.It's because each account grouping results in a filter propagation to the Transaction table for that account.

Azonban valami nem stimmel a Customer Balance vizualizációval.However, something doesn't appear correct with the Customer Balance visual. A Customer Balance vizualizáció minden ügyfelének egyenlege megegyezik az egyenlegek összegével.Each customer in the Customer Balance visual has the same balance as the total balance. Ez csak akkor lehetne pontos, ha minden ügyfél minden bankszámla közös tulajdonosa lenne.This result could only be correct if every customer was a joint account holder of every account. Ebben a példában azonban nem erről van szó.That's not the case in this example. A probléma a szűrőpropagáláshoz köthető.The issue is related to filter propagation. Ez ugyanis nem jut el a Transaction tábláig.It's not flowing all the way to the Transaction table.

Kövesse a kapcsolati szűrő irányát a Customer táblától a Transaction tábláig.Follow the relationship filter directions from the Customer table to the Transaction table. Látnia kell, hogy az Account és az AccountCustomer tábla közti kapcsolat nem a megfelelő irányba van propagálva.It should be apparent that the relationship between the Account and AccountCustomer table is propagating in the wrong direction. A kapcsolat szűrőjének irányát Both (Mindkettő) beállításra kell állítani.The filter direction for this relationship must be set to Both.

A frissített modellt ábrázoló diagram.

Ugyanazt a két jelentésvizualizációt egymás mellett ábrázoló diagram.

Ahogy vártuk, az Account Balance vizualizáció nem módosult.As expected, there has been no change to the Account Balance visual.

A Customer Balance vizualizációk azonban már az alábbi eredményt mutatják:The Customer Balance visuals, however, now displays the following result:

  • A Customer-91 egyenlege 75Customer-91 balance amount is 75
  • A Customer-92 egyenlege 275Customer-92 balance amount is 275
  • Az összeg 275The total is 275

A Customer Balance vizualizáció már a megfelelő eredményt mutatja.The Customer Balance visual now displays a correct result. Kövesse a szűrő irányát, és tekintse meg az ügyfélegyenlegek kiszámításának módját.Follow the filter directions for yourself, and see how the customer balances were calculated. Tartsa észben, hogy a vizualizáció összege minden ügyfélre vonatkozik.Also, understand that the visual total means all customers.

Akik nem ismerik a modellkapcsolatokat, azt gondolhatják, hogy az eredmény hibás.Someone unfamiliar with the model relationships could conclude that the result is incorrect. Az alábbi kérdés merülhet fel bennük: A Customer-91 és Customer-92 egyenlegének összege miért nem 350 (75 + 275)?They might ask: Why isn't the total balance for Customer-91 and Customer-92 equal to 350 (75 + 275)?

A válasz a több-a-többhöz típusú kapcsolatban rejlik.The answer to their question lies in understanding the many-to-many relationship. Minden ügyfélegyenleg képviselheti több számlaegyenleg összegét, így az ügyfélegyenlegek nem additívak.Each customer balance can represent the addition of multiple account balances, and so the customer balances are non-additive.

Több-a-többhöz típusú dimenziók összekapcsolása – útmutatóRelate many-to-many dimensions guidance

Dimenzió típusú táblázatok közötti, több-a-többhöz típusú kapcsolatokhoz kövesse az alábbi útmutatást:When you have a many-to-many relationship between dimension-type tables, we provide the following guidance:

  • Adja hozzá a több-a-többhöz típusú, kapcsolódó entitásokat modelltáblázatként, és győződjön meg róla, hogy tartalmaz egy egyéni azonosítóval rendelkező oszlopotAdd each many-to-many related entity as a model table, ensuring it has a unique identifier (ID) column
  • Adjon hozzá egy áthidaló táblázatot a társított entitások tárolása érdekébenAdd a bridging table to store associated entities
  • Hozzon létre egy-a-többhöz típusú kapcsolatokat a három tábla közöttCreate one-to-many relationships between the three tables
  • Konfiguráljon egy kétirányú kapcsolatot a ténytáblázatok irányába haladó szűrőpropagálás engedélyezéséhezConfigure one bi-directional relationship to allow filter propagation to continue to the fact-type tables
  • Ha nem szerepelhetnek hiányzó azonosítóértékek, állítsa az azonosítóoszlopok Is Nullable tulajdonságát FALSE (HAMIS) értékre. Az adatfrissítés így meghiúsul hiányzó értékek eseténWhen it isn't appropriate to have missing ID values, set the Is Nullable property of ID columns to FALSE—data refresh will then fail if missing values are sourced
  • Rejtse el az áthidaló táblázatot (kivéve, ha az a jelentéshez szükséges további oszlopokat vagy mértékeket tartalmaz)Hide the bridging table (unless it contains additional columns or measures required for reporting)
  • Rejtse el a jelentéshez nem használható azonosítóoszlopokat (például a helyettes kulcsként használt azonosítók esetében)Hide any ID columns that aren't suitable for reporting (for example, when IDs are surrogate keys)
  • Ha úgy dönt, hogy láthatóként szeretne hagyni egy azonosítóoszlopot, ügyeljen rá, hogy az a kapcsolat „egy” oldalán legyen, és mindig rejtse el a „több” oldali oszlopot.If it makes sense to leave an ID column visible, ensure that it's on the "one" slide of the relationship—always hide the "many" side column. Ez garantálja az optimális szűrőteljesítményt.It results in the best filter performance.
  • A zavar és félreértések elkerülése végett nyújtson magyarázatokat a jelentésfelhasználóknak – szövegmezővel rendelkező leírásokat, vagy vizualizáció-fejlécben található elemleírásokat adhat hozzáTo avoid confusion or misinterpretation, communicate explanations to your report users—you can add descriptions with text boxes or visual header tooltips

Nem ajánlott a több-a-többhöz típusú dimenziótáblákat közvetlenül összekapcsolni.We don't recommend you relate many-to-many dimension-type tables directly. Ehhez a kialakításhoz egy több-a-többhöz számosságú kapcsolatot kell konfigurálni.This design approach requires configuring a relationship with a many-to-many cardinality. Ez elméletileg lehetséges, azonban azt feltételezi, hogy az összekapcsolt oszlopok ismétlődő értékeket tartalmaznak.Conceptually it can be achieved, yet it implies that the related columns will contain duplicate values. Általánosan elfogadott kialakítási gyakorlat azonban, hogy a dimenzió típusú táblák rendelkeznek egy azonosítóoszloppal.It's a well-accepted design practice, however, that dimension-type tables have an ID column. A dimenziótábláknak mindig a kapcsolat „egy” oldalaként kell használniuk az azonosítóoszlopot.Dimension-type tables should always use the ID column as the "one" side of a relationship.

Több-a-többhöz típusú tények összekapcsolásaRelate many-to-many facts

A második több-a-többhöz típusú forgatókönyvben két tény típusú táblát kapcsolunk össze.The second many-to-many scenario type involves relating two fact-type tables. Ezek közvetlenül is összekapcsolhatók.Two fact-type tables can be related directly. Ez a kialakítási technika hasznos gyors és egyszerű adatfeltáráshoz.This design technique can be useful for quick and simple data exploration. Azonban általában nem javasoljuk ezt a módszert.However, and to be clear, we generally don't recommend this design approach. Ennek okát a szakasz egy későbbi részében magyarázzuk meg.We'll explain why later in this section.

Vegyünk például egy két tény típusú táblát tartalmazó esetet: Order és Fulfillment.Let's consider an example that involves two fact-type tables: Order and Fulfillment. Az Order tábla rendeléssoronként egy sort tartalmaz, a Fulfillment tábla pedig nulla vagy több sort tartalmazhat rendeléssoronként.The Order table contains one row per order line, and the Fulfillment table can contains zero or more rows per order line. Az Order tábla sorai az értékesítési megrendelések.Rows in the Order table represent sales orders. A Fulfillment tábla sorai a kézbesített megrendelések.Rows in the Fulfillment table represent order items that have been shipped. Egy több-a-többhöz kapcsolat összekapcsolja a két OrderID oszlopot, a szűrőpropagálás pedig csak az Order táblából indul ki (az Order szűri a Fulfillmentet).A many-to-many relationship relates the two OrderID columns, with filter propagation only from the Order table (Order filters Fulfillment).

Két táblázatból álló modellt ábrázoló diagram: Order és Fulfillment.

A kapcsolat számossága több-a-többhöz értékre van állítva, hogy támogassa mindkét táblában az ismételt OrderID értékek tárolását.The relationship cardinality is set to many-to-many to support storing duplicate OrderID values in both tables. Az Order táblában szerepelhetnek ismétlődő OrderID értékek, mivel egy rendeléshez több sor is tartozhat.In the Order table, duplicate OrderID values can exist because an order can have multiple lines. A Fulfillment táblában szerepelhetnek ismétlődő OrderID értékek, mivel a rendelésekhez több sor is tartozhat, a rendeléssorok pedig teljesíthetők több csomaggal.In the Fulfillment table, duplicate OrderID values can exist because orders may have multiple lines, and order lines can be fulfilled by many shipments.

Most tekintsük meg a táblasorokat.Let's now take a look at the table rows. A Fulfillment tábla rendeléssorai több csomaggal teljesíthetők.In the Fulfillment table, notice that order lines can be fulfilled by multiple shipments. (A rendeléssor hiánya azt jelenti, hogy a megrendelés még nem teljesült.)(The absence of an order line means the order is yet to be fulfilled.)

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

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:

  • Az Order táblázat öt sorral rendelkezik:The Order table has five rows:
    • OrderDate January 1 2019, OrderID 1, OrderLine 1, ProductID Prod-A, OrderQuantity 5, Sales 50OrderDate January 1 2019, OrderID 1, OrderLine 1, ProductID Prod-A, OrderQuantity 5, Sales 50
    • OrderDate January 1 2019, OrderID 1, OrderLine 2, ProductID Prod-B, OrderQuantity 10, Sales 80OrderDate January 1 2019, OrderID 1, OrderLine 2, ProductID Prod-B, OrderQuantity 10, Sales 80
    • OrderDate February 2 2019, OrderID 2, OrderLine 1, ProductID Prod-B, OrderQuantity 5, Sales 40OrderDate February 2 2019, OrderID 2, OrderLine 1, ProductID Prod-B, OrderQuantity 5, Sales 40
    • OrderDate February 2 2019, OrderID 2, OrderLine 2, ProductID Prod-C, OrderQuantity 1, Sales 20OrderDate February 2 2019, OrderID 2, OrderLine 2, ProductID Prod-C, OrderQuantity 1, Sales 20
    • OrderDate March 3 2019, OrderID 3, OrderLine 1, ProductID Prod-C, OrderQuantity 5, Sales 100OrderDate March 3 2019, OrderID 3, OrderLine 1, ProductID Prod-C, OrderQuantity 5, Sales 100
  • A Fulfillment táblázat négy sorral rendelkezik:The Fulfillment table has four rows:
    • FulfillmentDate January 1 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2FulfillmentDate January 1 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2
    • FulfillmentDate February 2 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5FulfillmentDate February 2 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5
    • FulfillmentDate February 2 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3FulfillmentDate February 2 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3
    • FulfillmentDate January 1 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10FulfillmentDate January 1 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10

Nézzük meg, mi történik a modell lekérdezése esetén.Let's see what happens when the model is queried. Íme egy táblavizualizáció, amely az Order táblázat OrderID oszlopának rendelési és teljesítési mennyiségeit hasonlítja össze.Here's a table visual comparing order and fulfillment quantities by the Order table OrderID column.

Háromoszlopos táblavizualizációt ábrázoló diagram: OrderID, OrderQuantity, és FulfillmentQuantity.

A vizualizáció pontos eredményt ad.The visual presents an accurate result. A modell hasznossága azonban korlátozott – szűrést vagy csoportosítást csak az Order tábla OrderID oszlopa alapján végezhet.However, the usefulness of the model is limited—you can only filter or group by the Order table OrderID column.

Több-a-többhöz típusú tények összekapcsolása – útmutatóRelate many-to-many facts guidance

Általában nem ajánlott két tény típusú táblát közvetlenül, több-a-többhöz típusú számossággal összekapcsolni.Generally, we don't recommend relating two fact-type tables directly using many-to-many cardinality. Ennek legfőbb oka, hogy a modell nem lesz rugalmas a jelentésvizualizációk szűrésekor vagy csoportosításakor.The main reason is because the model won't provide flexibility in the ways you report visuals filter or group. A példában a vizualizációk csak az Order tábla OrderID oszlopa alapján szűrhetnek vagy csoportosíthatnak.In the example, it's only possible for visuals to filter or group by the Order table OrderID column. A másodlagos ok az adatok minőségére vonatkozik.An additional reason relates to the quality of your data. Ha az adatintegritással problémák adódnak, előfordulhat, hogy bizonyos sorok kimaradnak a lekérdezés során a korlátozott kapcsolatok miatt.If your data has integrity issues, it's possible some rows may be omitted during querying due to the nature of the limited relationship. További információ: Modellkapcsolatok a Power BI Desktopban (Kapcsolatok kiértékelése).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

A tény típusú táblák közvetlen összekapcsolása helyett csillagséma típusú tervezési alapelvek bevezetését javasoljuk.Instead of relating fact-type tables directly, we recommend you adopt Star Schema design principles. Ezt dimenzió típusú táblák hozzáadásával teheti meg.You do it by adding dimension-type tables. A dimenzió típusú táblák ezután egy-a-többhöz típusú kapcsolatokkal összekapcsolhatók a tény típusúakkal.The dimension-type tables then relate to the fact-type tables by using one-to-many relationships. Ez egy robusztus tervezési módszer, amely rugalmas jelentéskészítési lehetőségeket nyújt.This design approach is robust as it delivers flexible reporting options. Így Ön bármilyen dimenzió típusú oszlop alapján szűrhet vagy csoportosíthat, és bármilyen kapcsolódó, tény típusú táblát összegezhet.It lets you filter or group using any of the dimension-type columns, and summarize any related fact-type table.

Vizsgáljunk meg egy jobb megoldást.Let's consider a better solution.

Hat táblázatból álló modellt ábrázoló diagram: OrderLine, OrderDate, Order, Fulfillment, Product, és FulfillmentDate.

Figyelje meg a következő tervbeli változásokat:Notice the following design changes:

  • A modell négy táblával bővült: OrderLine, OrderDate, Product, és FulfillmentDateThe model now has four additional tables: OrderLine, OrderDate, Product, and FulfillmentDate
  • A négy további tábla mind dimenzió típusú, és egy-a-többhöz kapcsolattal kapcsolódik a tény típusú táblákhozThe four additional tables are all dimension-type tables, and one-to-many relationships relate these tables to the fact-type tables
  • Az OrderLine tábla egy OrderLineID oszlopot, amely az OrderID 100-zal megszorzott értékét képviseli, valamint az OrderLine értéket tartalmazza, amely a rendeléssorok egyedi azonosítójaThe OrderLine table contains an OrderLineID column, which represents the OrderID value multiplied by 100, plus the OrderLine value—a unique identifier for each order line
  • Az Order és a Fulfillment tábla már tartalmaz egy OrderLineID oszlopot, az OrderID és OrderLine oszlopot pedig nemThe Order and Fulfillment tables now contain an OrderLineID column, and they no longer contain the OrderID and OrderLine columns
  • A Fulfillment tábla már tartalmazza az OrderDate és ProductID oszlopotThe Fulfillment table now contains OrderDate and ProductID columns
  • A FulfillmentDate tábla csak a Fulfillment táblához kapcsolódikThe FulfillmentDate table relates only to the Fulfillment table
  • Mindegyik egyedi azonosítót tartalmazó oszlop el van rejtveAll unique identifier columns are hidden

A csillagsémás tervezési alapelvek alkalmazása a következő előnyökkel jár:Taking the time to apply star schema design principles delivers the following benefits:

  • A jelentésvizualizációk a dimenzió típusú táblák bármelyik látható oszlopa alapján szűrhetnek vagy csoportosíthatnakYour report visuals can filter or group by any visible column from the dimension-type tables
  • A jelentésvizualizációk a tény típusú táblák bármelyik látható oszlopa alapján összegezhetnekYour report visuals can summarize any visible column from the fact-type tables
  • Az OrderLine, OrderDate, vagy Product táblára alkalmazott szűrők mindkét tény típusú táblához propagálhatnakFilters applied to the OrderLine, OrderDate, or Product tables will propagate to both fact-type tables
  • Mindegyik kapcsolat egy-a-többhöz típusú, és mindegyik normál kapcsolat.All relationships are one-to-many, and each relationship is a regular relationship. Az adatintegritásbeli problémák nem lesznek elrejtve.Data integrity issues won't be masked. További információ: Modellkapcsolatok a Power BI Desktopban (Kapcsolatok kiértékelése).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

Részletesebb tények összekapcsolásaRelate higher grain facts

Ez a több-a-többhöz típusú forgatókönyv nagyban eltér a két korábbitól.This many-to-many scenario is very different from the other two already described in this article.

Vegyük alapul az alábbi négy táblát tartalmazó példát: Date, Sales, Product, és Target.Let's consider an example involving four tables: Date, Sales, Product, and Target. A Date és a Product dimenzió típusú táblák, és egy-a-többhöz típusú kapcsolatokkal kapcsolódnak a Sales tény típusú táblához.The Date and Product are dimension-type tables, and one-to-many relationships relate each to the Sales fact-type table. Ez eddig egy jó csillagsémás kialakítás.So far, it represents a good star schema design. A Target tábla azonban még nincs másikhoz kapcsolva.The Target table, however, is yet to be related to the other tables.

Négy táblázatból álló modellt ábrázoló diagram: Date, Sales, Product, és Target.

A Target tábla három oszlopot tartalmaz: Category, TargetQuantity, és TargetYear.The Target table contains three columns: Category, TargetQuantity, and TargetYear. A táblázat sorai évek és termékkategóriák szintű részletességgel rendelkeznek.The table rows reveal a granularity of year and product category. Más szóval célok – amelyek az értékesítési teljesítményt mérik – vannak megadva minden évben minden termékkategóriához.In other words, targets—used to measure sales performance—are set each year for each product category.

A három oszlopból álló Target táblázatot ábrázoló diagram: TargetYear, Category, és TargetQuantity.

Mivel a Target tábla magasabb szinten tárolja az adatokat a dimenzió típusú tábláknál, nem hozható létre egy-a-többhöz kapcsolat.Because the Target table stores data at a higher level than the dimension-type tables, a one-to-many relationship cannot be created. Ez csak a kapcsolatok egyikére igaz.Well, it's true for just one of the relationships. Tekintsük meg, hogyan kapcsolható össze a Target tábla a dimenzió típusú táblákkal.Let's explore how the Target table can be related to the dimension-type tables.

Részletesebb időszakok összekapcsolásaRelate higher grain time periods

A Date és a Target tábla kapcsolatának egy-a-többhöz típusúnak kell lennie.A relationship between the Date and Target tables should be a one-to-many relationship. Ez amiatt van, hogy a TargetYear oszlop értékei dátumok.It's because the TargetYear column values are dates. Ebben a példában a TargetYear oszlop minden értéke a célul szolgáló év első dátuma.In this example, each TargetYear column value is the first date of the target year.

Tipp

Ha a napi szintnél részletesebben tárol tényeket, állítsa az oszlop adattípusát Date (vagy dátum típusú kulcsok esetén Whole number) értékre.When storing facts at a higher time granularity than day, set the column data type to Date (or Whole number if you're using date keys). Az oszlopban az időszak első napját képviselő érték szerepeljen.In the column, store a value representing the first day of the time period. Egy egy éves időszak például január 1-ként legyen rögzítve, egy egy hónapos időszak pedig a hónap első napjaként.For example, a year period is recorded as January 1 of the year, and a month period is recorded as the first day of that month.

Ügyeljen azonban arra, hogy a hónap vagy dátum szintű szűrők értelmes eredményt adjanak.Care must be taken, however, to ensure that month or date level filters produce a meaningful result. Speciális számítási logika nélkül a jelentésvizualizációk azt mutathatják, hogy a céldátumok az egyes évek első napjai.Without any special calculation logic, report visuals may report that target dates are literally the first day of each year. Az összes többi nap – és január kivételével hónap – BLANK (ÜRES) értékként összegzi a célmennyiséget.All other days—and all months except January—will summarize the target quantity as BLANK.

Az alábbi mátrixvizualizáció bemutatja, mi történik, ha a jelentés felhasználója egy évet részletez hónapok szerint.The following matrix visual shows what happens when the report user drills from a year into its months. A vizualizáció a TargetQuantity oszlopot foglalja össze.The visual is summarizing the TargetQuantity column. (Az Adatot nem tartalmazó elemek megjelenítése lehetőség engedélyezve van a mátrixsorokhoz.)(The Show items with no data option has been enabled for the matrix rows.)

Mátrixvizualizációt ábrázoló diagram, amelyen az látható, hogy a 2020. évi célmennyiség 270.

Ennek elkerülése érdekében azt javasoljuk, hogy mértékekkel vezérelje a tényadatok összegzését.To avoid this behavior, we recommend you control the summarization of your fact data by using measures. Ennek egyik módja a BLANK eredményezése alacsonyabb szintű időszakok lekérdezésekor.One way to control the summarization is to return BLANK when lower-level time periods are queried. Egy másik módszer – amelyet kifinomult DAX definiál – az értékek felosztása az alacsonyabb szintű időszakok között.Another way—defined with some sophisticated DAX—is to apportion values across lower-level time periods.

Vegyük például az ISFILTERED DAX-függvényt használó mértékdefiníciót.Consider the following measure definition that uses the ISFILTERED DAX function. Ez csak akkor ad vissza értéket, ha a Date vagy a Month oszlop nincs szűrve.It only returns a value when the Date or Month columns aren't filtered.

Target Quantity =
IF(
    NOT ISFILTERED('Date'[Date])
        && NOT ISFILTERED('Date'[Month]),
    SUM(Target[TargetQuantity])
)

Az alábbi mátrixvizualizáció már a Target Quantity mértéket használja.The following matrix visual now uses the Target Quantity measure. Ezen láthatjuk, hogy minden havi célmennyiség BLANK.It shows that all monthly target quantities are BLANK.

Mátrixvizualizációt ábrázoló diagram, amelyen az látható, hogy a 2020. évi célmennyiség 270, a havi értékek pedig üresek.

Részletesebb, nem dátum típusú adatok összekapcsolásaRelate higher grain (non-date)

Dimenzió típusú tábla nem dátum típusú oszlopainak (a dimenzió típusú táblánál részletesebb) tény típusú táblához való összekapcsolásakor eltérő kialakítási megközelítésre van szükség.A different design approach is required when relating a non-date column from a dimension-type table to a fact-type table (and it's at a higher grain than the dimension-type table).

A Product és a Target tábla Category oszlopai ismétlődő értékeket tartalmaznak.The Category columns (from both the Product and Target tables) contains duplicate values. Így nincs „egy” oldala az egy-a-többhöz típusú kapcsolatnak.So, there's no "one" for a one-to-many relationship. Ebben az esetben több-a-többhöz típusú kapcsolatot kell létrehozni.In this case, you'll need to create a many-to-many relationship. A kapcsolatnak egyetlen irányba kell propagálnia a szűrőket: a dimenzió típusú táblától a tény típusú tábla felé.The relationship should propagate filters in a single direction, from the dimension-type table to the fact-type table.

A Target és a Product táblázat modelljét ábrázoló diagram.

Most tekintsük meg a táblasorokat.Let's now take a look at the table rows.

Két táblázatból álló modellt ábrázoló diagram: Target és Product.

A Target táblában négy sor található: célévenként (2019 és 2020) két sor, valamint két kategória (Clothing és Accessories).In the Target table, there are four rows: two rows for each target year (2019 and 2020), and two categories (Clothing and Accessories). A Product táblában három termék található.In the Product table, there are three products. Kettő a Clothing (Ruházat) kategóriába tartozik, egy pedig az Accessories (Kiegészítők) kategóriába.Two belong to the clothing category, and one belongs to the accessories category. A ruhaszínek egyike zöld, míg a másik kettő kék.One of the clothing colors is green, and the remaining two are blue.

A Product tábla Category oszlopa alapján csoportosító táblavizualizáció az alábbi eredményt adja.A table visual grouping by the Category column from the Product table produces the following result.

Kétoszlopos táblavizualizációt ábrázoló diagram: Category és TargetQuantity.

A vizualizáció helyes eredményt ad.This visual produces the correct result. Most vizsgáljuk meg, mi történik, ha a Product tábla Color oszlopát használjuk a célmennyiség csoportosításához.Let's now consider what happens when the Color column from the Product table is used to group target quantity.

Kétoszlopos táblavizualizációt ábrázoló diagram: Color és TargetQuantity.

A vizualizáció helytelenül reprezentálja az adatokat.The visual produces a misrepresentation of the data. Mi történik?What is happening here?

A Product tábla Color oszlopának egyik szűrője két sort eredményez.A filter on the Color column from the Product table results in two rows. Az egyik sor a Clothing kategóriához tartozik, a másik pedig az Accessories kategóriához.One of the rows is for the Clothing category, and the other is for the Accessories category. A két kategóriaérték szűrőként van propagálva a Target táblához.These two category values are propagated as filters to the Target table. Más szóval: mivel a kék színt két kategória termékei használják, ezek a kategóriák szűrik a célokat.In other words, because the color blue is used by products from two categories, those categories are used to filter the targets.

Ennek elkerülése érdekében azt javasoljuk, hogy mértékekkel vezérelje a tényadatok összegzését.To avoid this behavior, as described earlier, we recommend you control the summarization of your fact data by using measures.

Vizsgáljuk meg a következő mértékdefiníciót.Consider the following measure definition. Így a Product tábla minden, a kategóriaszint alatti oszlopát teszteljük szűrőkhöz.Notice that all Product table columns that are beneath the category level are tested for filters.

Target Quantity =
IF(
    NOT ISFILTERED('Product'[ProductID])
        && NOT ISFILTERED('Product'[Product])
        && NOT ISFILTERED('Product'[Color]),
    SUM(Target[TargetQuantity])
)

Az alábbi táblavizualizáció már a Target Quantity mértéket használja.The following table visual now uses the Target Quantity measure. Ezen láthatjuk, hogy minden szín célmennyisége BLANK.It shows that all color target quantities are BLANK.

Kétoszlopos táblavizualizációt ábrázoló diagram: Color és TargetQuantity.

A végső modellterv az alábbihoz hasonlít.The final model design looks like the following.

A Date és a Target tábla között egy-a-többhöz kapcsolattal rendelkező modellt ábrázoló diagram.

Részletesebb tények összekapcsolása – útmutatóRelate higher grain facts guidance

Ha dimenzió típusú táblát kell tény típusú táblával összekapcsolnia, az utóbbi pedig nagyobb részletességű sorokat tárol, mint az előbbi, kövesse az alábbi útmutatást:When you need to relate a dimension-type table to a fact-type table, and the fact-type table stores rows at a higher grain than the dimension-type table rows, we provide the following guidance:

  • Részletesebb ténydátumok esetén:For higher grain fact dates:
    • A tény típusú táblában az időszak első dátumát tároljaIn the fact-type table, store the first date of the time period
    • Hozzon létre egy egy-a-többhöz típusú kapcsolatot a dátumtábla és a tény típusú tábla közöttCreate a one-to-many relationship between the date table and the fact-type table
  • Egyéb részletesebb tények esetén:For other higher grain facts:
    • Hozzon létre egy több-a-többhöz típusú kapcsolatot a dimenzió típusú tábla és a tény típusú tábla közöttCreate a many-to-many relationship between the dimension-type table and the fact-type table
  • Mindkét típus esetén:For both types:
    • Az összegzést mértéklogikával vezérelje – ha alacsonyabb szintű, dimenzió típusú oszlopokkal szűr vagy csoportosít, eredményezzen BLANK értéketControl summarization with measure logic—return BLANK when lower-level dimension-type columns are used to filter or group
    • Rejtse el az összefoglalható, tény típusú táblák oszlopait – így csak mértékekkel összegezhető a tény típusú táblaHide summarizable fact-type table columns—this way, only measures can be used to summarize the fact-type 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: