Çoka çok ilişkiler kılavuzuMany-to-many relationship guidance

Bu makale, Power BI Desktop'la çalışan veri modelleyicilerine yöneliktir.This article targets you as a data modeler working with Power BI Desktop. Üç farklı çoka çok modelleme senaryosu açıklanır.It describes three different many-to-many modeling scenarios. Ayrıca modellerinizde bunların tasarımının nasıl yapılacağına ilişkin yönergeler sağlanır.It also provides you with guidance on how to successfully design for them in your models.

Not

Model ilişkilerine giriş konusu bu makalenin kapsamı dışındadır.An introduction to model relationships is not covered in this article. İlişkileri, onların özelliklerini ve nasıl yapılandırılacağını tam olarak bilmiyorsanız, önce Power BI Desktop'ta model ilişkileri makalesini okumanızı öneririz.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.

Ayrıca yıldız şeması tasarımını anlamış olmanız da önemlidir.It's also important that you have an understanding of star schema design. Daha fazla bilgi için bkz. Yıldız şemasını ve Power BI için önemini anlama.For more information, see Understand star schema and the importance for Power BI.

Aslında üç çoka çok senaryosu vardır.There are, in fact, three many-to-many scenarios. Şunlara ihtiyacınız olduğunda bu senaryolar gerçekleşir:They can occur when you're required to:

Çoka çok boyutları ilişkilendirmeRelate many-to-many dimensions

Şimdi ilk çoka çok senaryo türünü bir örnekle gözden geçirelim.Let's consider the first many-to-many scenario type with an example. Klasik senaryo iki varlıkla ilişkilidir: banka müşterileri ve banka hesapları.The classic scenario relates two entities: bank customers and bank accounts. Müşterilerin birden çok hesabı olabildiğini ve hesapların birden çok müşterisi olabildiğini düşünün.Consider that customers can have multiple accounts, and accounts can have multiple customers. Hesabın birden çok müşterisi olduğunda bunlar yaygın olarak ortak hesap sahipleri olarak adlandırılır.When an account has multiple customers, they're commonly called joint account holders.

Bu varlıkların modellenmesi basit bir işlemdir.Modeling these entities is straight forward. Boyut türündeki bir tabloda hesaplar, boyut türündeki diğer bir tabloda da müşteriler depolanır.One dimension-type table stores accounts, and another dimension-type table stores customers. Boyut türündeki tabloların bir özelliği olarak, her tabloda bir Kimlik sütunu bulunur.As is characteristic of dimension-type tables, there's an ID column in each table. İki tablo arasındaki ilişkiyi modellemek için üçüncü bir tablo gereklidir.To model the relationship between the two tables, a third table is required. Bu tablo yaygın olarak köprü oluşturma tablosu olarak adlandırılır.This table is commonly referred to as a bridging table. Bu örnekte söz konusu tablonun amacı her müşteri-hesap ilişkisi için bir satır depolamasıdır.In this example, it's purpose is to store one row for each customer-account association. İlginç olan bu tablonun yalnızca Kimlik sütunları içerdiğinde olgusuz olgu tablosu olarak adlandırılmasıdır.Interestingly, when this table only contains ID columns, it's called a factless fact table.

Burada üç tablonun basitleştirilmiş bir model diyagramı verilmiştir.Here's a simplistic model diagram of the three tables.

Üç tablo içeren bir modeli gösteren diyagram.

İlk tablo Account adlı tablodur ve iki sütun içerir: AccountID ve Account.The first table is named Account, and it contains two columns: AccountID and Account. İkinci tablo AccountCustomer adlı tablodur ve iki sütun içerir: AccountID ve CustomerID.The second table is named AccountCustomer, and it contains two columns: AccountID and CustomerID. Üçüncü tablo Customer adlı tablodur ve iki sütun içerir: CustomerID ve Customer.The third table is named Customer, and it contains two columns: CustomerID and Customer. Tablolardan hiçbiri arasında ilişki yoktur.Relationships don't exist between any of the tables.

Tabloları ilişkilendirmek için iki tane bire çok ilişkisi eklenir.Two one-to-many relationships are added to relate the tables. Burada ilişkili tabloların güncelleştirilmiş bir model diyagramı bulunur.Here's an updated model diagram of the related tables. Transaction adlı olgu türündeki tablo eklenmiştir.A fact-type table named Transaction has been added. Hesap işlemlerini kaydeder.It records account transactions. Köprü oluşturma tablosu ve tüm kimlik sütunları gizlenmiştir.The bridging table and all ID columns have been hidden.

Modelin dört tablo içerdiğini gösteren diyagram.

İlişki filtresi yayma işleminin çalışmasını açıklamaya yardımcı olmak için, model diyagramı tablo satırlarını ortaya koymak için değiştirilmiştir.To help describe how the relationship filter propagation works, the model diagram has been modified to reveal the table rows.

Not

Power BI Desktop model diyagramında tablo satırlarını görüntülemek mümkün değildir.It's not possible to display table rows in the Power BI Desktop model diagram. Bu makalede açıklamayı net örneklerle desteklemek için yapılmıştır.It's done in this article to support the discussion with clear examples.

Modelin tablo satırlarını ortaya çıkardığını gösteren diyagram.

Dört tablonun satır ayrıntıları aşağıdaki madde işaretli listede açıklanır:The row details for the four tables are described in the following bulleted list:

  • Account tablosunun iki satırı vardır:The Account table has two rows:
    • AccountID 1, Account-01 içindirAccountID 1 is for Account-01
    • AccountID 2, Account-02 içindirAccountID 2 is for Account-02
  • Customer tablosunun iki satırı vardır:The Customer table has two rows:
    • CustomerID 91, Customer-91 içindirCustomerID 91 is for Customer-91
    • CustomerID 92, Customer-92 içindirCustomerID 92 is for Customer-92
  • AccountCustomer tablosunun üç satırı vardır:The AccountCustomer table has three rows:
    • AccountID 1, CustomerID 91 ile ilişkilendirilmiştirAccountID 1 is associated with CustomerID 91
    • AccountID 1, CustomerID 92 ile ilişkilendirilmiştirAccountID 1 is associated with CustomerID 92
    • AccountID 2, CustomerID 92 ile ilişkilidirAccountID 2 is associated with CustomerID 92
  • Transaction tablosunun üç satırı vardır:The Transaction table has three rows:
    • Date 1 Ocak 2019, AccountID 1, Amount 100Date January 1 2019, AccountID 1, Amount 100
    • Date 2 Şubat 2019, AccountID 2, Amount 200Date February 2 2019, AccountID 2, Amount 200
    • Date 3 Mart 2019, AccountID 1, Amount -25Date March 3 2019, AccountID 1, Amount -25

Model sorgulandığında neler olduğuna bakalım.Let's see what happens when the model is queried.

Aşağıda Transaction tablosundaki Amount sütununu özetleyen iki görsel vardır.Below are two visuals that summarize the Amount column from the Transaction table. İlk görsel hesaba göre gruplandırır ve Amount sütunlarının toplamı hesap bakiyesini temsil eder.The first visual groups by account, and so the sum of the Amount columns represents the account balance. İkinci görsel müşteriye göre gruplandırır ve Amount sütunlarının toplamı müşteri bakiyesini temsil eder.The second visual groups by customer, and so the sum of the Amount columns represents the customer balance.

Yan yana duran iki rapor görselini gösteren diyagram.

İlk görsel Account Balance başlığına sahiptir ve iki sütunu vardır: Account ve Amount.The first visual is titled Account Balance, and it has two columns: Account and Amount. Aşağıdaki sonucu görüntüler:It displays the following result:

  • Account-01 bakiye tutarı 75'tirAccount-01 balance amount is 75
  • Account-02 bakiye tutarı 200'dürAccount-02 balance amount is 200
  • Toplam 275'tirThe total is 275

İkinci görsel Customer Balance başlığına sahiptir ve iki sütunu vardır: Customer ve Amount.The second visual is titled Customer Balance, and it has two columns: Customer and Amount. Aşağıdaki sonucu görüntüler:It displays the following result:

  • Customer-91 bakiye tutarı 275'tirCustomer-91 balance amount is 275
  • Customer-92 bakiye tutarı 275'tirCustomer-92 balance amount is 275
  • Toplam 275'tirThe total is 275

Tablo satırlarına Account Balance görseline hızlı bir bakış her hesap ve toplam tutar için sonucun doğru olduğunu ortaya koyar.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. Bunun nedeni her hesap gruplandırmasının, bu hesap için Transaction tablosuna filtre yayılması sonucu vermesidir.It's because each account grouping results in a filter propagation to the Transaction table for that account.

Öte yandan Customer Balance görselinde doğru görünmeyen bir şey vardır.However, something doesn't appear correct with the Customer Balance visual. Customer Balance görselindeki her müşterinin bakiyesi toplam bakiyeyle aynıdır.Each customer in the Customer Balance visual has the same balance as the total balance. Bu sonuç ancak her müşteri her hesabın ortak hesap sahibi olması durumunda doğru olabilir.This result could only be correct if every customer was a joint account holder of every account. Bu örnekte durum böyle değildir.That's not the case in this example. Sorun filtre yayılmasıyla ilgilidir.The issue is related to filter propagation. Filtre Transaction tablosuna kadar akıtılmaz.It's not flowing all the way to the Transaction table.

İlişki filtresi yönlerini Customer tablosundan Transaction tablosuna kadar izleyin.Follow the relationship filter directions from the Customer table to the Transaction table. Account ile AccountCustomer tablosu arasındaki ilişkinin yanlış yönde yayıldığı açıkça anlaşılabilir.It should be apparent that the relationship between the Account and AccountCustomer table is propagating in the wrong direction. Bu ilişkinin filtre yönü Her İkisi olarak ayarlanmalıdır.The filter direction for this relationship must be set to Both.

Modelin güncelleştirildiğini gösteren diyagram.

Aynı iki rapor görselini yan yana gösteren diyagram.

Beklendiği gibi Account Balance görselinde hiçbir değişiklik yoktur.As expected, there has been no change to the Account Balance visual.

Öte yandan Customer Balance görselinde artık aşağıdaki sonuç görüntülenir:The Customer Balance visuals, however, now displays the following result:

  • Customer-91 bakiye tutarı 75'tirCustomer-91 balance amount is 75
  • Customer-92 bakiye tutarı 275'tirCustomer-92 balance amount is 275
  • Toplam 275'tirThe total is 275

Customer Balance görseli artık doğru sonucu görüntüler.The Customer Balance visual now displays a correct result. Filtre yönlerini kendiniz izleyin ve müşteri bakiyelerinin nasıl hesaplandığına bakın.Follow the filter directions for yourself, and see how the customer balances were calculated. Ayrıca görsel toplamının tüm müşteriler anlamına geldiğini de anlamalısınız.Also, understand that the visual total means all customers.

Model ilişkilerini tanımayan biri sonucun yanlış olduğunu düşünebilir.Someone unfamiliar with the model relationships could conclude that the result is incorrect. Şu soruyu sorabilir: Customer-91 ve Customer-92 için toplam bakiye neden 350'ye (75 + 275) eşit değil?They might ask: Why isn't the total balance for Customer-91 and Customer-92 equal to 350 (75 + 275)?

Bu sorunun yanıtı çoka çok ilişkisini anlamayı gerektirir.The answer to their question lies in understanding the many-to-many relationship. Her müşteri bakiyesi birden çok hesap bakiyesinin toplamını temsil ettiğinden, müşteri bakiyeleri toplanabilir değildir.Each customer balance can represent the addition of multiple account balances, and so the customer balances are non-additive.

Çoka çok boyutları ilişkilendirme yönergeleriRelate many-to-many dimensions guidance

Boyut türündeki tablolarınız arasında çoka çok ilişkisi varsa aşağıdaki yönergeleri sağlarız:When you have a many-to-many relationship between dimension-type tables, we provide the following guidance:

  • Çoka çok ilişkili her varlığı bir model tablosu olarak ekleyin ve benzersiz tanımlayıcı sütunu içerdiğinden emin olunAdd each many-to-many related entity as a model table, ensuring it has a unique identifier (ID) column
  • İlişkili varlıkları depolamak üzere bir köprü oluşturma tablosu ekleyinAdd a bridging table to store associated entities
  • Üç tablo arasında bire çok ilişkileri oluşturunCreate one-to-many relationships between the three tables
  • Filtre yayılmasının olgu türündeki tablolara doğru devam etmesini sağlamak için tek bir çift yönlü ilişki yapılandırınConfigure one bi-directional relationship to allow filter propagation to continue to the fact-type tables
  • Eksik kimlik değerleri olmasının uygun olmadığı durumlarda kimlik sütunlarının Null atanabilir özelliğini FALSE olarak ayarlayın; kaynakta eksik değerler olduğunda veri yenileme başarısız olacaktırWhen 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
  • Köprü oluşturma tablosunu gizleyin (raporlama için gereken ek sütunlar veya ölçümler içermiyorsa)Hide the bridging table (unless it contains additional columns or measures required for reporting)
  • Raporlamaya uygun olmayan tüm kimlik sütunlarını gizleyin (örneğin, kimlikler vekil anahtarlar olduğunda)Hide any ID columns that aren't suitable for reporting (for example, when IDs are surrogate keys)
  • Kimlik sütununu görünür durumda bırakmak anlamlıysa, bunun ilişkinin "bir" tarafında olmasına dikkat edin; "çok" tarafı sütunu her zaman gizleyin.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. Bu yöntem en iyi filtre performansını sağlar.It results in the best filter performance.
  • Karışıklıktan veya yanlış yorumlamaktan kaçınmak için, rapor kullanıcılarınıza açıklamaları iletin; açıklamaları metin kutularıyla veya görsel üst bilgisi araç ipuçlarıyla ekleyebilirsinizTo avoid confusion or misinterpretation, communicate explanations to your report users—you can add descriptions with text boxes or visual header tooltips

Çoka çok boyut türündeki tabloları doğrudan ilişkilendirmenizi önermiyoruz.We don't recommend you relate many-to-many dimension-type tables directly. Bu tasarım yaklaşımı ilişkiyi çoka çok kardinalitesiyle yapılandırmayı gerektirir.This design approach requires configuring a relationship with a many-to-many cardinality. Kavramsal olarak bu mümkündür ama ilişkili sütunların yinelenen değerler içereceğine işaret eder.Conceptually it can be achieved, yet it implies that the related columns will contain duplicate values. Öte yandan boyut türündeki tabloların bir kimlik sütunu olması yaygın olarak kabul edilen bir tasarım uygulamasıdır.It's a well-accepted design practice, however, that dimension-type tables have an ID column. Boyut türündeki tablolar kimlik sütununu her zaman ilişkinin "bir" tarafı olarak kullanmalıdır.Dimension-type tables should always use the ID column as the "one" side of a relationship.

Çoka çok olguları ilişkilendirmeRelate many-to-many facts

İkinci çoka çok senaryo türü iki olgu türünde tablo içerir.The second many-to-many scenario type involves relating two fact-type tables. İki olgu türünde tablo doğrudan ilişkilendirilebilir.Two fact-type tables can be related directly. Bu tasarım tekniği hızlı ve basit veri araştırmalarında kullanışlı olabilir.This design technique can be useful for quick and simple data exploration. Öte yandan, açıkça belirtmek gerekirse bu tasarım yaklaşımını önermiyoruz.However, and to be clear, we generally don't recommend this design approach. Nedenini bu bölümün devamında açıklayacağız.We'll explain why later in this section.

Şimdi iki olgu türünde tablo içeren bir örneği gözden geçirelim: Order ve Fulfillment.Let's consider an example that involves two fact-type tables: Order and Fulfillment. Order tablosu sipariş satırı başına bir satır içerir ve Fulfillment tablosu da sipariş satırı başına sıfır veya daha fazla satır içerebilir.The Order table contains one row per order line, and the Fulfillment table can contains zero or more rows per order line. Order tablosundaki satırlar satış siparişlerini temsil eder.Rows in the Order table represent sales orders. Fulfillment tablosundaki satırlar gönderilen sipariş öğelerini temsil eder.Rows in the Fulfillment table represent order items that have been shipped. Çoka çok ilişki iki OrderID sütununu ilişkilendirir; filtre yayılması yalnızca Order tablosundan gerçekleşir (Order tablosu Fulfillment tablosunu filtreler).A many-to-many relationship relates the two OrderID columns, with filter propagation only from the Order table (Order filters Fulfillment).

İki tablo içeren bir modeli gösteren diyagram: Order ve Fulfillment.

Her iki tabloda da yinelenen OrderID değerlerinin depolanmasını desteklemek için ilişki kardinalitesi çoka çok olarak ayarlanır.The relationship cardinality is set to many-to-many to support storing duplicate OrderID values in both tables. Order tablosunda yinelenen OrderID değerleri bulunabilir çünkü bir siparişin birden çok satırı olabilir.In the Order table, duplicate OrderID values can exist because an order can have multiple lines. Fulfillment tablosunda yinelenen OrderID değerleri bulunabilir çünkü siparişlerin birden çok satırı olabilir ve sipariş satırları birçok gönderimle karşılanabilir.In the Fulfillment table, duplicate OrderID values can exist because orders may have multiple lines, and order lines can be fulfilled by many shipments.

Şimdi tablo satırlarını gözden geçirelim.Let's now take a look at the table rows. Fulfillment tablosunda sipariş satırlarının birden çok gönderimle karşılanabileceğine dikkat edin.In the Fulfillment table, notice that order lines can be fulfilled by multiple shipments. (Bir sipariş satırının eksik olması, siparişin henüz karşılanmadığını gösterir.)(The absence of an order line means the order is yet to be fulfilled.)

Modelin tablo satırlarını ortaya çıkardığını gösteren diyagram.

İki tablonun satır ayrıntıları aşağıdaki madde işaretli listede açıklanır:The row details for the two tables are described in the following bulleted list:

  • Order tablosunun beş satırı vardır:The Order table has five rows:
    • OrderDate 1 Ocak 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 1 Ocak 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 2 Şubat 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 2 Şubat 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 3 Mart 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
  • Fulfillment tablosunun dört satırı vardır:The Fulfillment table has four rows:
    • FulfillmentDate 1 Ocak 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2FulfillmentDate January 1 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2
    • FulfillmentDate 2 Şubat 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5FulfillmentDate February 2 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5
    • FulfillmentDate 2 Şubat 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3FulfillmentDate February 2 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3
    • FulfillmentDate 1 Ocak 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10FulfillmentDate January 1 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10

Model sorgulandığında neler olduğuna bakalım.Let's see what happens when the model is queried. Burada Order tablosunun OrderID sütununa göre sipariş ve karşılama miktarlarının karşılaştırıldığı bir tablo görseli verilmiştir.Here's a table visual comparing order and fulfillment quantities by the Order table OrderID column.

Üç sütunlu bir tablo görselini gösteren diyagram: OrderID, OrderQuantity ve FulfillmentQuantity.

Görsel doğru bir sonuç göstermektedir.The visual presents an accurate result. Öte yandan modelin kullanışlılığı sınırlıdır çünkü yalnızca Order tablosunun OrderID sütununa göre filtreleyebilir veya gruplandırabilirsiniz.However, the usefulness of the model is limited—you can only filter or group by the Order table OrderID column.

Çoka çok olguları ilişkilendirme yönergeleriRelate many-to-many facts guidance

Genel olarak çoka çok kardinalitesi kullanılarak iki olgu türünde tablonun doğrudan ilişkilendirilmesi önerilmez.Generally, we don't recommend relating two fact-type tables directly using many-to-many cardinality. Bunun ana nedeni modelin rapor görsellerini filtreleme veya gruplandırma yolları konusunda esneklik sağlamamasıdır.The main reason is because the model won't provide flexibility in the ways you report visuals filter or group. Örnekte görselleri yalnızca Order tablosunun OrderID sütununa göre filtrelemek veya gruplandırmak mümkündür.In the example, it's only possible for visuals to filter or group by the Order table OrderID column. Bir diğer nedeni de verilerinizin kalitesiyle ilgilidir.An additional reason relates to the quality of your data. Verilerinizde bütünlük sorunları varsa, sınırlı ilişkinin doğasına bağlı olarak sorgulama sırasında bazı satırlar atlanabilir.If your data has integrity issues, it's possible some rows may be omitted during querying due to the nature of the limited relationship. Daha fazla bilgi için bkz. Power BI Desktop’ta model ilişkileri (İlişki değerlendirmesi).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

Olgu türündeki tabloları doğrudan ilişkilendirmek yerine Yıldız Şeması tasarım ilkelerini benimsemenizi öneririz.Instead of relating fact-type tables directly, we recommend you adopt Star Schema design principles. Bunu, boyut türünde tablolar ekleyerek yaparsınız.You do it by adding dimension-type tables. Sonra boyut türündeki tablolar bire çok ilişkileri kullanılarak olgu türündeki tablolarla ilişkilendirilir.The dimension-type tables then relate to the fact-type tables by using one-to-many relationships. Bu tasarım yaklaşımı esnek raporlama seçenekleri getirdiğinden güçlü bir yaklaşımdır.This design approach is robust as it delivers flexible reporting options. Boyut türündeki sütunlardan herhangi birini kullanarak filtrelemenize veya gruplandırmanıza ve ilişkili olgu türündeki tabloları özetlemenize olanak tanır.It lets you filter or group using any of the dimension-type columns, and summarize any related fact-type table.

Şimdi daha iyi bir çözüm düşünelim.Let's consider a better solution.

Bir modelin altı tablo içerdiğini gösteren diyagram: OrderLine, OrderDate, Order, Fulfillment, Product ve FulfillmentDate.

Aşağıdaki tasarım değişikliklerine dikkat edin:Notice the following design changes:

  • Modelin şimdi dört tablosu daha vardır: OrderLine, OrderDate, Product ve FulfillmentDateThe model now has four additional tables: OrderLine, OrderDate, Product, and FulfillmentDate
  • Dört ek tablonun hepsi boyut türündeki tablolardır ve bu tablolarla olgu türündeki tablolar arasında bire çok ilişkileri vardırThe four additional tables are all dimension-type tables, and one-to-many relationships relate these tables to the fact-type tables
  • OrderLine tablosunda, 100 ile çarpılan OrderID değerini, artı OrderLine değerini (her sipariş satırı için benzersiz tanımlayıcı) temsil eden bir OrderLineID sütunu bulunurThe 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
  • Order ve Fulfillment tabloları şimdi bir OrderLineID sütunu içerir ve bu tablolar artık OrderID ve OrderLine sütunlarını içermezThe Order and Fulfillment tables now contain an OrderLineID column, and they no longer contain the OrderID and OrderLine columns
  • Fulfillment tablosu şimdi OrderDate ve ProductID sütunlarını içerirThe Fulfillment table now contains OrderDate and ProductID columns
  • FulfillmentDate tablosu yalnızca Fulfillment tablosuyla ilişkilidirThe FulfillmentDate table relates only to the Fulfillment table
  • Tüm benzersiz tanımlayıcı sütunları gizlenirAll unique identifier columns are hidden

Zaman ayırıp yıldız şeması tasarım ilkelerinin uygulanması aşağıdaki avantajları sağlar:Taking the time to apply star schema design principles delivers the following benefits:

  • Rapor görselleriniz boyut türündeki tabloların tüm görünür sütunlarına göre filtrelenebilir veya gruplandırılabilirYour report visuals can filter or group by any visible column from the dimension-type tables
  • Rapor görselleriniz olgu türündeki tabloların tüm görünür sütunlarına göre özetlenebilirYour report visuals can summarize any visible column from the fact-type tables
  • OrderLine, OrderDate veya Product tablolarına uygulanan filtreler olgu türündeki her iki tabloya da yayılırFilters applied to the OrderLine, OrderDate, or Product tables will propagate to both fact-type tables
  • İlişkilerin tümü bire çok ilişkisidir ve her ilişki normal ilişkidir.All relationships are one-to-many, and each relationship is a regular relationship. Veri bütünlüğü sorunları maskelenmez.Data integrity issues won't be masked. Daha fazla bilgi için bkz. Power BI Desktop’ta model ilişkileri (İlişki değerlendirmesi).For more information, see Model relationships in Power BI Desktop (Relationship evaluation).

Daha yüksek dilimli olguları ilişkilendirmeRelate higher grain facts

Bu çoka çok senaryosu, bu makalede daha önce açıklanan diğer iki senaryodan çok farklıdır.This many-to-many scenario is very different from the other two already described in this article.

Şimdi dört tablo içeren bir örneği gözden geçirelim: Date, Sales, Product ve Target.Let's consider an example involving four tables: Date, Sales, Product, and Target. Date ve Product boyut türünde tablolardır; bunlardan her biri bire çok ilişkisi kullanılarak olgu türündeki Sales tablosuyla ilişkilendirilir.The Date and Product are dimension-type tables, and one-to-many relationships relate each to the Sales fact-type table. Şimdi kadar iyi bir yıldız şeması tasarımını temsil eder.So far, it represents a good star schema design. Öte yandan Target tablosu henüz diğer tablolarla ilişkilendirilmemiştir.The Target table, however, is yet to be related to the other tables.

Bir modelin dört tablo içerdiğini gösteren diyagram: Date, Sales, Product ve Target.

Target tablosu üç sütun içerir: Category, TargetQuantity ve TargetYear.The Target table contains three columns: Category, TargetQuantity, and TargetYear. Tablo satırları yıl ve ürün kategorisinin ayrıntılarını ortaya koyar.The table rows reveal a granularity of year and product category. Diğer bir deyişle hedefler (satış performansını ölçmek için kullanılır) her yıl her ürün kategorisi için ayarlanır.In other words, targets—used to measure sales performance—are set each year for each product category.

Target tablosunun üç sütunu olduğunu gösteren diyagram: TargetYear, Category ve TargetQuantity.

Target tablosunda veriler, boyut türündeki tablolardan daha üst düzeyde depolandığından, bire çok ilişkisi oluşturulamaz.Because the Target table stores data at a higher level than the dimension-type tables, a one-to-many relationship cannot be created. Bu, ilişkilerden yalnızca biri için geçerlidir.Well, it's true for just one of the relationships. Şimdi Target tablosunun boyut türündeki tablolarla nasıl ilişkilendirilebileceğini gözden geçirelim.Let's explore how the Target table can be related to the dimension-type tables.

Daha yüksek dilimli dönemleri ilişkilendirmeRelate higher grain time periods

Date ile Target tabloları arasındaki ilişki bire çok ilişkisi olmalıdır.A relationship between the Date and Target tables should be a one-to-many relationship. Bunun nedeni TargetYear sütunundaki değerlerin tarih değerleri olmasıdır.It's because the TargetYear column values are dates. Bu örnekte her TargetYear sütunu değeri, hedef yılın ilk tarihidir.In this example, each TargetYear column value is the first date of the target year.

İpucu

Olguları bir günden daha yüksek bir zaman aralığı diliminde depolarken sütun veri türünü Tarih (veya tarih anahtarları kullanıyorsanız Tamsayı) olarak ayarlayın.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). Sütunda zaman aralığının ilk gününü temsil eden değeri depolayın.In the column, store a value representing the first day of the time period. Örneğin yıl zaman aralığı yılın 1 Ocak günü olarak ve ay zaman aralığı da söz konusu ayın ilk günü olarak kaydedilir.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.

Öte yandan ay veya tarih düzeyi filtrelerinin anlamlı bir sonuç verdiğinden emin olmak için özen gösterilmelidir.Care must be taken, however, to ensure that month or date level filters produce a meaningful result. Özel bir hesaplama mantığı olmadan, rapor görselleri hedef tarihleri her yılın ilk günü olarak raporlayabilir.Without any special calculation logic, report visuals may report that target dates are literally the first day of each year. Diğer tüm günler (ve Ocak dışındaki tüm aylar) hedef miktarı BOŞLUK olarak özetler.All other days—and all months except January—will summarize the target quantity as BLANK.

Aşağıdaki matris görselinde, rapor kullanıcısı yıldan o yılın aylarına detaya gittiğinde neler olduğu gösterilir.The following matrix visual shows what happens when the report user drills from a year into its months. Görsel TargetQuantity sütunu özetlemektedir.The visual is summarizing the TargetQuantity column. (Matris satırları için Veri içermeyen öğeleri göster seçeneği etkinleştirilmiştir.)(The Show items with no data option has been enabled for the matrix rows.)

2020 yılının hedef miktarının 270 olduğunu ortaya çıkaran matris görselini gösteren diyagram.

Bu davranışı önlemek için ölçüleri kullanarak olgu verilerinizin özetlemesini denetlemenizi öneririz.To avoid this behavior, we recommend you control the summarization of your fact data by using measures. Özetlemeyi denetlemenin yollarından biri düşük düzeyli zaman aralıkları sorgulandığında BOŞLUK döndürmektir.One way to control the summarization is to return BLANK when lower-level time periods are queried. Gelişmiş DAX ile tanımlanan bir diğer yol da düşük düzeyli zaman aralıkları arasında değerleri paylaştırmaktır.Another way—defined with some sophisticated DAX—is to apportion values across lower-level time periods.

ISFILTERED DAX işlevinin kullanıldığı aşağıdaki ölçü tanımını düşünün.Consider the following measure definition that uses the ISFILTERED DAX function. Yalnızca Date veya Month sütunları filtrelenmediğinde değer döndürür.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])
)

Aşağıdaki matris görseli şimdi Target Quantity ölçüsünü kullanır.The following matrix visual now uses the Target Quantity measure. Tüm aylık hedef miktarlarının BOŞ olduğunu gösterir.It shows that all monthly target quantities are BLANK.

2020 yılının hedef miktarının 270 olduğunu boş aylık değerlerle birlikte ortaya çıkaran matris görselini gösteren diyagram.

Daha yüksek dilimi ilişkilendirme (tarih dışı)Relate higher grain (non-date)

Boyut türündeki tablonun tarih dışı bir sütununu olgu türündeki tabloyla (ayrıca boyut türündeki tablodan daha yüksek dilimde) ilişkilendirirken farklı bir tasarım yaklaşımı gereklidir.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).

Category sütunları (hem Product hem de Target tablosundan) yinelenen değerler içerir.The Category columns (from both the Product and Target tables) contains duplicate values. Dolayısıyla bire çok ilişkisinin "bir" tarafı yoktur.So, there's no "one" for a one-to-many relationship. Bu örnekte bir çoka çok ilişkisi oluşturmanız gerekir.In this case, you'll need to create a many-to-many relationship. İlişki filtreleri tek yönde, boyut türündeki tablodan olgu türündeki tabloya yaymalıdır.The relationship should propagate filters in a single direction, from the dimension-type table to the fact-type table.

Target ve Ürün tablolarının modelini gösteren diyagram.

Şimdi tablo satırlarını gözden geçirelim.Let's now take a look at the table rows.

İki tablo içeren bir modeli gösteren diyagram: Target ve Product.

Target tablosunda dört satır vardır: her hedef yıl (2019 ve 2020) için iki satır ve iki kategori (Clothing ve Accessories).In the Target table, there are four rows: two rows for each target year (2019 and 2020), and two categories (Clothing and Accessories). Product tablosunda üç ürün vardır.In the Product table, there are three products. Ürünlerden ikisi giysi (Clothing) kategorisine ve biri de aksesuar (Accessories) kategorisine aittir.Two belong to the clothing category, and one belongs to the accessories category. Giysilerden birinin rengi yeşil diğer ikisinin mavidir.One of the clothing colors is green, and the remaining two are blue.

Product tablosundaki Category sütununa göre yapılan bir tablo görsel gruplandırması aşağıdaki sonucu verir.A table visual grouping by the Category column from the Product table produces the following result.

İki sütunlu bir tablo görselini gösteren diyagram: Category ve TargetQuantity.

Bu görsel doğru sonucu üretir.This visual produces the correct result. Şimdi hedef miktarı gruplandırmak için Product tablosunun Color sütunu kullanıldığında ne olduğuna bakalım.Let's now consider what happens when the Color column from the Product table is used to group target quantity.

İki sütunlu bir tablo görselini gösteren diyagram: Color ve TargetQuantity.

Görsel verilerin hatalı bir gösterimini üretir.The visual produces a misrepresentation of the data. Orada neler oluyor?What is happening here?

Product tablosunun Color sütununa uygulanan bir filtrenin sonucunda iki satır elde edilir.A filter on the Color column from the Product table results in two rows. Satırlardan biri Clothing kategorisi ve diğeri de Accessories kategorisi içindir.One of the rows is for the Clothing category, and the other is for the Accessories category. Bu iki kategori değeri filtre olarak Target tablosuna yayılır.These two category values are propagated as filters to the Target table. Diğer bir deyişle iki kategorideki ürünler mavi (Blue) rengi kullandığından, hedefleri filtrelemek için bu kategoriler kullanılır.In other words, because the color blue is used by products from two categories, those categories are used to filter the targets.

Bu davranışı önlemek için, daha önce açıklandığı gibi ölçüleri kullanarak olgu verilerinizin özetlemesini denetlemenizi öneririz.To avoid this behavior, as described earlier, we recommend you control the summarization of your fact data by using measures.

Aşağıdaki ölçü tanımını göz önünde bulundurun.Consider the following measure definition. Kategori düzeyinin altındaki tüm Product tablosu sütunlarının filtreler için test edildiğine dikkat edin.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])
)

Aşağıdaki tablo görseli şimdi Target Quantity ölçüsünü kullanır.The following table visual now uses the Target Quantity measure. Tüm renk hedefi miktarlarının BOŞ olduğunu gösterir.It shows that all color target quantities are BLANK.

İki sütunlu bir tablo görselini gösteren diyagram: Color ve TargetQuantity.

Son model tasarımı aşağıdakine benzer.The final model design looks like the following.

Aralarında bire çok ilişkisi bulunan Date ve Target tablolarına sahip bir modeli gösteren diyagram.

Daha yüksek dilimli olgular kılavuzuRelate higher grain facts guidance

Boyut türünde bir tabloyu olgu türünde bir tabloyla ilişkilendirmeniz gerektiğinde ve olgu türündeki tablo boyut türündeki tablonun satırlarından daha yüksek dilimde satırlar depoladığında, aşağıdaki yönergeleri sağlarız: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:

  • Daha yüksek dilimli olgu tarihleri için:For higher grain fact dates:
    • Olgu türündeki tabloda zaman aralığının ilk tarihini depolayınIn the fact-type table, store the first date of the time period
    • Tarih tablosuyla olgu türündeki tablo arasında bire çok ilişkisi oluşturunCreate a one-to-many relationship between the date table and the fact-type table
  • Diğer daha yüksek dilimli olgular için:For other higher grain facts:
    • Boyut türündeki tabloyla olgu türündeki tablo arasında çoka çok ilişkisi oluşturunCreate a many-to-many relationship between the dimension-type table and the fact-type table
  • Her iki tür için de:For both types:
    • Ölçü mantığıyla özetlemeyi denetleyin; filtrelemek veya gruplandırmak için düşük düzeyli boyut türündeki sütunlar kullanıldığında BOŞLUK döndürünControl summarization with measure logic—return BLANK when lower-level dimension-type columns are used to filter or group
    • Özetlenebilir olgu türündeki tablo sütunlarını gizleyin; bu şekilde olgu türündeki tabloyu özetlemek için yalnızca ölçüler kullanılabilirHide summarizable fact-type table columns—this way, only measures can be used to summarize the fact-type table

Sonraki adımlarNext steps

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara bakın:For more information related to this article, check out the following resources: