Power BI Desktop’ta çoka çok ilişkilerini uygulamaApply many-many relationships in Power BI Desktop

Power BI Desktop'daki çoka çok kardinalitesine sahip ilişkiler ile çoka çok kardinalitesini kullanan tabloları birleştirebilirsiniz.With relationships with a many-many cardinality in Power BI Desktop, you can join tables that use a cardinality of many-to-many. Kolayca ve sezgisel bir şekilde iki veya daha fazla veri kaynağı içeren veri modelleri oluşturabilirsiniz.You can more easily and intuitively create data models that contain two or more data sources. Çoka çok kardinalitesine sahip ilişkiler, Power BI Desktop'taki daha kapsamlı bileşik modeller özelliğinin bir parçasıdır.Relationships with a many-many cardinality are part of the larger composite models capabilities in Power BI Desktop.

"İlişkiyi düzenle" bölmesindeki bir çoka çok ilişkisi, Power BI Desktop

Power BI Desktop'taki çoka çok kardinalitesine sahip ilişkiler, birbiriyle ilişkili üç özellikten birinden oluşur:A relationship with a many-many cardinality in Power BI Desktop is composed of one of three related features:

  • Bileşik modeller: Bileşik modeller, raporda DirectQuery bağlantıları ve içeri aktarma da dahil olmak üzere herhangi bir birleşimde iki veya daha fazla veri bağlantısına izin verir.Composite models: A composite model allows a report to have two or more data connections, including DirectQuery connections or Import, in any combo. Daha fazla bilgi için bkz. Power BI Desktop’ta bileşik modelleri kullanma.For more information, see Use composite models in Power BI Desktop.

  • Çoka çok kardinalitesine sahip ilişkiler: Bileşik modeller sayesinde tablolar arasında çoka çok kardinalitesine sahip ilişkiler kurabilirsiniz.Relationships with a many-many cardinality: With composite models, you can establish relationships with a many-many cardinality between tables. Bu yaklaşım tablolardaki benzersiz değer gereksinimlerini ortadan kaldırır.This approach removes requirements for unique values in tables. Ayrıca yalnızca ilişki kurmak için yeni tablo eklenmesi gibi eski geçici çözümleri de devre dışı bırakır.It also removes previous workarounds, such as introducing new tables only to establish relationships. Bu özellik bu makalede ayrıntılı olarak açıklanmaktadır.The feature is described further in this article.

  • Depolama modu: Artık arka uç veri kaynaklarını sorgulaması gereken görselleri belirtebilirsiniz.Storage mode: You can now specify which visuals require a query to back-end data sources. Sorgu gerektirmeye görseller DirectQuery tabanlı olsa dahi içeri aktarılmaz.Visuals that don't require a query are imported even if they're based on DirectQuery. Bu özellik, performansı artırmanıza ve arka uç yükünü azaltmanıza yardımcı olur.This feature helps improve performance and reduce back-end load. Daha önce, sorguları başlatan dilimleyiciler gibi basit görseller bile arka uç kaynaklara gönderiliyordu.Previously, even simple visuals, such as slicers, began queries that were sent to back-end sources. Daha fazla bilgi için bkz. Power BI Desktop’ta depolama modu.For more information, see Storage mode in Power BI Desktop.

Çoka çok kardinalitesine sahip ilişkiler neye çözüm getirir?What a relationship with a many-many cardinality solves

Çoka çok kardinalitesine sahip ilişkiler kullanıma sunulmadan önce iki tablo arasındaki ilişki Power BI’da tanımlanıyordu.Before relationships with a many-many cardinality became available, the relationship between two tables was defined in Power BI. İlişkideki tablo sütunlarından en az birinde benzersiz değerlerin bulunması şarttı.At least one of the table columns involved in the relationship had to contain unique values. Ancak genellikle benzersiz değer içeren sütun bulunmuyordu.Often, though, no columns contained unique values.

Örneğin, iki tabloda da Ülke etiketine sahip bir sütun bulunabiliyordu.For example, two tables might have had a column labeled Country. Ancak Ülke değerleri iki tabloda da benzersiz olmuyordu.The values of Country weren't unique in either table, though. Bu tabloları birleştirmek için geçici bir çözüme ihtiyaç duyuluyordu.To join such tables, you had to create a workaround. Geçici çözümlerden biri, ihtiyaç duyulan benzersiz değerleri içeren tablolar eklemekti.One workaround might be to introduce extra tables with the needed unique values. Çoka çok kardinalitesine sahip ilişkiler sayesinde bu tür tabloları çoka çok kardinalitesine sahip bir ilişki kullanarak doğrudan birleştirebilirsiniz.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.

Çoka çok kardinalitesine sahip ilişkileri kullanmaUse relationships with a many-many cardinality

Power BI'da iki tablo arasındaki ilişkiyi tanımlarken, ilişkinin kardinalitesini tanımlamanız gerekir.When you define a relationship between two tables in Power BI, you must define the cardinality of the relationship. Örneğin ProductSales ve Product arasında ProductSales[ProductCode] ve Product[ProductCode] sütunları kullanılarak kurulan ilişkinin kardinalitesi Çok-1 olacaktır.For example, the relationship between ProductSales and Product—using columns ProductSales[ProductCode] and Product[ProductCode]—would be defined as Many-1. Her ürün için birden fazla satış olduğundan ve Product tablosundaki (ProductCode) sütunu benzersiz olduğundan ilişkiyi bu şekilde tanımlıyoruz.We define the relationship in this way, because each product has many sales, and the column in the Product table (ProductCode) is unique. Bir ilişkinin kardinalitesini Çok-1, 1-Çok veya 1-1 olarak tanımladığınızda Power BI doğrulama gerçekleştirerek seçtiğiniz kardinalitenin gerçek verilerle eşleşmesini sağlar.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.

Örneğin, şu görüntüde yer alan basit modele göz atalım:For example, take a look at the simple model in this image:

ProductSales ve Product tablosu, İlişki görünümü, Power BI Desktop

Şimdi Product tablosunda aşağıdaki gibi yalnızca iki satır görüntülendiğini düşünelim:Now, imagine that the Product table displays just two rows, as shown:

İki satırlı Product tablosu görseli, Power BI Desktop

Aynı zamanda Sales tablosunda C ürünü için bir satırın da bulunduğu yalnızca dört satır olduğunu düşünelim. Bilgi tutarlılığı hatası nedeniyle C ürününün satırı Product tablosunda mevcut değildir.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.

Dört satırlı Sales tablosu görseli, Power BI Desktop

ProductName ve Price (Product tablosundan) ile her ürün için toplam Qty değeri (ProductSales tablosundan) şu şekilde gösterilecektir: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:

Ürün adını, fiyatını ve miktarını gösteren görsel, Power BI Desktop

Yukarıdaki görüntüde gördüğünüz gibi C ürünüyle ilişkilendirilmiş boş bir ProductName satırı vardır. Bu boş satır aşağıdakileri gösterir: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:

  • Product tablosunda karşılık gelen satırları bulunmayan ProductSales tablosu satırları.Any rows in the ProductSales table for which no corresponding row exists in the Product table. Bu örnekte C ürünü için gördüğümüz gibi bir bilgi tutarlılığı sorunu vardır.There's a referential integrity issue, as we see for product C in this example.

  • ProductSales tablosunda, yabancı anahtar sütunu null olan herhangi bir satır.Any rows in the ProductSales table for which the foreign key column is null.

Bu nedenlerden dolayı, her iki durumda da boş satır ProductName ve Price değerlerinin bilinmediği satışları gösterir.For these reasons, the blank row in both cases accounts for sales where the ProductName and Price are unknown.

Bazen tablolar iki sütunla birleştirilebilir ama sütunlardan hiçbiri benzersiz değildir.Sometimes the tables are joined by two columns, yet neither column is unique. Örneğin, şu iki tabloyu inceleyin:For example, consider these two tables:

  • Sales tablosu State temelinde satış verilerini gösterir ve her satır o eyaletin satış türüne ilişkin satış tutarını gösterir.The Sales table displays sales data by State, and each row contains the sales amount for the type of sale in that state. Eyaletler CA, WA ve TX olarak belirlenmiştir.The states include CA, WA, and TX.

    Eyalete göre satışları gösteren satış tablosu, Power BI Desktop

  • CityData tablosu, şehirlerin nüfus ve eyalet (CA, WA ve New York gibi) verilerini gösterir.The CityData table displays data on cities, including the population and state (such as CA, WA, and New York).

    Şehir, eyalet ve nüfus bilgilerini gösteren satış tablosu, Power BI Desktop

State sütunu iki tabloda da bulunmaktadır.A column for State is now in both tables. Hem eyalete göre toplam satış miktarını hem de her bir eyaletin toplam nüfusunu rapora dahil etmek isteyebilirsiniz.It's reasonable to want to report on both total sales by state and total population of each state. Ancak burada bir sorun vardır: State sütunu iki tabloda da benzersiz değildir.However, a problem exists: the State column isn't unique in either table.

Eski geçici çözümThe previous workaround

Power BI Desktop'ın Temmuz 2018 sürümünden önce bu tablolar arasında doğrudan ilişki oluşturmak mümkün değildi.Before the July 2018 release of Power BI Desktop, you couldn't create a direct relationship between these tables. Yaygın bir geçici çözüm olarak şunlar yapılırdı:A common workaround was to:

  • Yalnızca benzersiz State kimliklerini içeren üçüncü bir tablo oluşturulurdu.Create a third table that contains only the unique State IDs. Tablo şunlardan biri veya hepsi olabilirdi:The table could be any or all of:

    • Hesaplanan tablo (Veri Çözümleme İfadeleri [DAX] kullanılarak tanımlanmış).A calculated table (defined by using Data Analysis Expressions [DAX]).
    • Tabloların birinden çekilen benzersiz kimlikleri görüntüleyebilecek ve Sorgu Düzenleyicisinde tanımlanan bir sorguyu temel alan bir tablo.A table based on a query that's defined in Query Editor, which could display the unique IDs drawn from one of the tables.
    • Birleştirilmiş tam küme.The combined full set.
  • Ardından iki özgün tablo, yaygın Çok-1 ilişkileri kullanılarak yeni tabloyla ilişkilendirilirdi.Then relate the two original tables to that new table by using common Many-1 relationships.

Geçici çözüm tablosunu görünür durumda tutabilirdiniz.You could leave the workaround table visible. Ya da geçici çözüm tablosunu gizleyerek Alanlar listesinde görünmemesini sağlayabilirdiniz.Or you may hide the workaround table, so it doesn't appear in the Fields list. Tabloyu gizlediğinizde Çok-1 ilişkileri genellikle iki yönde de filtreleme yapacak şekilde ayarlanırdı ve iki tablodaki State alanını da kullanmanız mümkün olurdu.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. Sonraki çapraz filtreleme işlemleri diğer tabloya da yayılırdı.The later cross filtering would propagate to the other table. Bu yaklaşım aşağıdaki görüntüde gösterilmiştir:That approach is shown in the following image:

Hidden State tablosu, İlişki görünümü, Power BI Desktop

State (CityData tablosundan) ile toplam Population ve toplam Sales değerlerini gösteren bir görsel aşağıdaki gibi olacaktır:A visual that displays State (from the CityData table), along with total Population and total Sales, would then appear as follows:

Eyalet, Popülasyon ve Satış verilerini içeren tablonun ekran görüntüsü.

Not

Bu geçici çözümde CityData tablosundan eyalet değerinin kullanılmasıyla, yalnızca söz konusu tablodaki eyaletlerin listelendiğine (ve dolayısıyla TX eyaletinin hariç tutulduğuna) dikkat edin.Because the state from the CityData table is used in this workaround, only the states in that table are listed, so TX is excluded. Aynı zamanda, Çok-1 ilişkilerinden farklı olarak, toplam satırı tüm Sales değerlerini (TX eyaletininkiler de dahil) içerirken ayrıntılar bu tür eşleşmeyen satırları kapsayan boş satırı içermez.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. Benzer biçimde, State için null değeri olan bir Sales değerini kapsayacak boş bir satır yoktur.Similarly, no blank row would cover Sales for which there's a null value for the State.

Bu görsele City verilerini de eklediğinizi varsayalım.Suppose you also add City to that visual. City başına nüfus değeri biliniyor olsa da City için gösterilen Sales değeri yalnızca ilgili State için gösterilen Sales değerini tekrarlar.Although the population per City is known, the Sales shown for City simply repeats the Sales for the corresponding State. Bu senaryo, burada gösterildiği gibi sütun gruplama belirli bir toplama ölçüsü ile ilgili olmadığında ortaya çıkar:This scenario normally occurs when the column grouping is unrelated to some aggregate measure, as shown here:

Eyalet ve şehir nüfusu ve satışlar, Power BI Desktop

Yeni Sales tablosunu buradaki tüm State girişlerinin toplamı olarak tanımladığınızı ve bunu Alanlar listesinde görünür hale getirdiğinizi düşünün.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. Aynı görselde State (yeni tabloda), Population toplamı ve Sales toplamı görüntülenir:The same visual would display State (on the new table), the total Population, and total Sales:

Eyalet, nüfus ve satış görseli, Power BI Desktop

Gördüğünüz gibi Sales verileri bilinen ancak Population verileri bilinmeyen TX ve Population verileri bilinen ancak Sales verileri bilinmeyen New York dahil edilecektir.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. Bu geçici çözüm çok uygun bir çözüm değildir ve birçok sorun barındırmaktadır.This workaround isn't optimal, and it has many issues. Çoka çok kardinalitesine sahip ilişkilerle, aşağıdaki bölümde açıklandığı gibi bu sorunlara çözüm getirilmiştir.For relationships with a many-many cardinality, the resulting issues are addressed, as described in the next section.

Geçici çözüm yerine çoka çok kardinalitesine sahip ilişkileri kullanmaUse a relationship with a many-many cardinality instead of the workaround

Power BI Desktop'ın Temmuz 2018 sürümünden başlayarak yukarıda bahsedilenler gibi tabloları benzer geçici çözümler aramadan doğrudan birbirine bağlayabilirsiniz.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. Artık ilişki kardinalitesini çoka çok olarak ayarlamak mümkündür.It's now possible to set the relationship cardinality to many-to-many. Bu ayar, iki tabloda da benzersiz değerler olmadığını belirtir.This setting indicates that neither table contains unique values. Bu tür ilişkilerde de diğer tabloya filtre uygulayan tabloyu denetleyebilirsiniz.For such relationships, you may still control which table filters the other table. Ya da her tablonun diğerini filtrelediği çift yönlü filtreleme uygulayabilirsiniz.Or you can apply bidirectional filtering, where each table filters the other.

Power BI Desktop'ta, hiçbir tablonun ilişki sütunları için benzersiz değerler içermediği saptandığında kardinalite varsayılan olarak çoka çok olarak ayarlanır.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. Bu gibi durumlarda ilişki oluşturma isteğini onaylamanızı ve değişikliğin istenmeyen bir veri sorunu olmadığını kabul etmenizi isteyen bir uyarı iletisi görüntülenir.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.

Örneğin CityData ile Sales arasında filtrelerin CityData alanından Sales alanına akış gerçekleştireceği bir ilişki oluşturduğunuzda Power BI Desktop'ta İlişkiyi düzenle penceresi görüntülenir: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:

İlişkiyi düzenle iletişim kutusu, Power BI Desktop

Sonuçta elde edilen İlişki görünümü, iki tablo arasında doğrudan çok-çok ilişkisini gösterecektir.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. Tabloların Alanlar listesindeki görünümü ve görseller oluşturulduktan sonraki davranışları, geçici çözümün uygulandığı örneğe benzer olacaktır.The tables' appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. Geçici çözümde, benzersiz State verilerini görüntüleyen ek tablo görünür hale getirilmez.In the workaround, the extra table that displays the distinct State data isn't made visible. Daha önce de açıklandığı gibi State, Population ve Sales verilerini gösteren bir görsel görüntülenir:As described earlier, a visual that shows State, Population, and Sales data would be displayed:

State, Population ve Sales tabloları, Power BI Desktop

Çoka çok kardinalite ilişkileri ile daha tipik olan Çoka bir ilişkileri arasındaki en Önemli farklar şunlardır:The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • Gösterilen değerlerde diğer tablodaki eşleşmeyen satırları gösteren boş satır bulunmaz.The values shown don't include a blank row that accounts for mismatched rows in the other table. Ayrıca değerler, diğer tablodaki ilişki için kullanılan sütunun null olduğu satırları dikkate almaz.Also, the values don't account for rows where the column used in the relationship in the other table is null.

  • Birden fazla satır arasında ilişki bulunabileceğinden RELATED() işlevini kullanamazsınız.You can't use the RELATED() function, because more than one row could be related.

  • Tabloda ALL() işlevinin kullanılması çok-çok ilişkisiyle ilgili diğer tablolara uygulanan filtreleri kaldırmaz.Using the ALL() function on a table doesn't remove filters that are applied to other, related tables by a many-to-many relationship. Önceki örnekte, burada gösterildiği gibi tanımlanmış bir ölçü, ilişkili CityData tablosundaki sütunlarda bulunan filtreleri kaldırmaz:In the preceding example, a measure that's defined as shown here wouldn't remove filters on columns in the related CityData table:

    Betik örneği

    State, Sales ve Sales total değerlerini gösteren bir görselde şu grafik yer alacaktır:A visual showing State, Sales, and Sales total data would result in this graphic:

    Tablo görseli

Yukarıda anlatılan farklılıkları göz önünde bulundurarak genel toplamın yüzdesi gibi ALL(<Table>) kullanan hesaplamaların istenen sonuçları döndürdüğünden emin olun.With the preceding differences in mind, make sure the calculations that use ALL(<Table>), such as % of grand total, are returning the intended results.

Sınırlamalar ve önemli noktalarLimitations and considerations

Çoka çok kardinaliteye sahip ilişkiler ile bileşik modellerin bu sürümünde birkaç sınırlama vardır.There are a few limitations for this release of relationships with a many-many cardinality and composite models.

Aşağıdaki Live Connect (çok boyutlu) kaynaklar bileşik modellerle kullanılamaz: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 veri kümeleriPower BI datasets
  • Azure Analysis ServicesAzure Analysis Services

Söz konusu çok boyutlu kaynaklara DirectQuery kullanarak bağlandığınızda, başka bir DirectQuery kaynağına bağlanamaz veya içeri aktarılan verilerle birleştiremezsiniz.When you connect to these multidimensional sources by using DirectQuery, you can't connect to another DirectQuery source or combine it with imported data.

Çoka çok kardinalitesine sahip ilişkileri kullanırken DirectQuery’yi kullanmakla ilgili mevcut sınırlamalar yine geçerlidir.The existing limitations of using DirectQuery still apply when you use relationships with a many-many cardinality. Sınırlamaların birçoğu şimdi tablonun depolama moduna bağlı olarak tablo başına uygulanır.Many limitations are now per table, depending upon the storage mode of the table. Örneğin, içeri aktarılan tablodaki hesaplanan sütun başka tablolara başvurabilir ama DirectQuery tablosundaki hesaplanan sütun yine aynı tablodaki sütunlara başvurabilir.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. Model içindeki tablolardan herhangi biri DirectQuery ise, diğer sınırlamalar modelin tamamına uygulanır.Other limitations apply to the whole model if any tables within the model are DirectQuery. Örneğin, modelin içindeki tablolardan herhangi birinin depolama modu DirectQuery olduğunda, modelde QuickInsights ve Soru ve Yanıt özellikleri kullanılamaz.For example, the QuickInsights and Q&A features are unavailable on a model if any table within it has a storage mode of DirectQuery.

Sonraki adımlarNext steps

Bileşik modeller ve DirectQuery hakkında daha fazla bilgi için aşağıdaki makalelere bakın:For more information about composite models and DirectQuery, see the following articles: