Çoka çok ilişki kılavuzu

Bu makale, Power BI Desktop ile çalışan bir veri modelleyicisi olarak sizi hedefler. Üç farklı çoka çok modelleme senaryosu açıklanmaktadır. Ayrıca, modellerinizde bunlar için nasıl başarılı bir şekilde tasarım yapılacağınız konusunda size rehberlik sağlar.

Not

Model ilişkilerine giriş bu makalede ele alınmamıştır. İlişkiler, özellikleri veya bunların nasıl yapılandırıldığını tam olarak bilmiyorsanız, önce Power BI Desktop'ta Model ilişkileri makalesini okumanızı öneririz.

Yıldız şeması tasarımını anlamanız da önemlidir. Daha fazla bilgi için bkz . Yıldız şemasını ve Power BI'ın önemini anlama.

Aslında üç çoka çok senaryosu vardır. Bunlar, şu durumlarda ortaya çıkabilir:

• İki boyut türü tabloyu ilişkilendirme
• Olgu türündeki iki tabloyu ilişkilendirme
• Olgu türündeki tablo satırları boyut türündeki tablo satırlarından daha yüksek bir dilimde depoladığında, daha yüksek taneli olgu türündeki tabloları ilişkilendirme

Not

Power BI artık çoka çok ilişkileri yerel olarak destekliyor. Daha fazla bilgi için bkz . Power BI Desktop'ta çoka çok ilişkileri uygulama.

Çoka çok boyutları ilişkilendirme

Örnek içeren ilk çoka çok senaryo türünü ele alalım. Klasik senaryo iki varlıkla ilgilidir: banka müşterileri ve banka hesapları. Müşterilerin birden çok hesabı ve hesapların birden çok müşterisi olabileceğini göz önünde bulundurun. Bir hesabın birden çok müşterisi olduğunda, bunlar genellikle ortak hesap sahipleri olarak adlandırılır.

Bu varlıkları modellemek çok kolaydır. Boyut türünde bir tablo hesapları, başka bir boyut türündeki tablo ise müşterileri depolar. Boyut türündeki tabloların özelliğinde olduğu gibi, her tabloda bir kimlik sütunu vardır. İki tablo arasındaki ilişkiyi modellemek için üçüncü bir tablo gerekir. Bu tablo genellikle köprü oluşturma tablosu olarak adlandırılır. Bu örnekte amaç, her müşteri hesabı ilişkisi için bir satır depolamaktır. İlginçtir ki, bu tablo yalnızca kimlik sütunları içerdiğinde olgu içermeyen olgu tablosu olarak adlandırılır.

Üç tablonun basit bir model diyagramı aşağıda verilmiştir.

İlk tablo Account olarak adlandırılır ve iki sütun içerir: AccountID ve Account. İkinci tablo AccountCustomer olarak adlandırılır ve iki sütun içerir: AccountID ve CustomerID. Üçüncü tablo Customer olarak adlandırılır ve iki sütun içerir: CustomerID ve Customer. Tabloların hiçbiri arasında ilişki yoktur.

Tabloları ilişkilendirmek için iki bire çok ilişki eklenir. İlgili tabloların güncelleştirilmiş model diyagramı aşağıda verilmiştir. Transaction adlı olgu türündeki bir tablo eklendi. Hesap işlemlerini kaydeder. Köprü oluşturma tablosu ve tüm kimlik sütunları gizlendi.

İlişki filtresi yayma işleminin nasıl çalıştığını açıklamaya yardımcı olmak için model diyagramı tablo satırlarını gösterecek şekilde değiştirilmiştir.

Not

Power BI Desktop model diyagramında tablo satırlarını görüntülemek mümkün değildir. Tartışmayı net örneklerle desteklemek için bu makalede yapılır.

Dört tablonun satır ayrıntıları aşağıdaki madde işaretli listede açıklanmıştır:

• Account tablosunun iki satırı vardır:
  • AccountID 1, Account-01 içindir
  • AccountID 2, Account-02 içindir
• Customer tablosunun iki satırı vardır:
  • CustomerID 91, Customer-91 içindir
  • CustomerID 92, Customer-92 içindir
• AccountCustomer tablosunun üç satırı vardır:
  • AccountID 1, CustomerID 91 ile ilişkilendirilir
  • AccountID 1, CustomerID 92 ile ilişkilendirilir
  • AccountID 2, CustomerID 92 ile ilişkilendirilir
• transaction tablosunun üç satırı vardır:
  • Tarih 1 Ocak 2019, Hesap Kimliği 1, Tutar 100
  • Tarih 2 Şubat 2019, Hesap Kimliği 2, Tutar 200
  • Tarih 3 Mart 2019, Hesap Kimliği 1, Tutar -25

Şimdi model sorgulandığında ne olacağını görelim.

Aşağıda Transaction tablosundaki Amount sütununu özetleyen iki görsel yer almaktadır. İlk görsel hesaba göre gruplandırdığından Amount sütunlarının toplamı hesap bakiyesini temsil eder. İkinci görsel müşteriye göre gruplandırdığından Amount sütunlarının toplamı müşteri bakiyesini temsil eder.

İlk görsel Hesap Bakiyesi başlıklıdır ve iki sütunu vardır: Hesap ve Tutar. Aşağıdaki sonucu görüntüler:

• Hesap-01 bakiye tutarı 75'tir
• Hesap-02 bakiye tutarı 200'dür
• Toplam 275'tir

İkinci görsel Müşteri Bakiyesi başlıklıdır ve iki sütunu vardır: Müşteri ve Tutar. Aşağıdaki sonucu görüntüler:

• Customer-91 bakiye tutarı 275'tir
• Customer-92 bakiye tutarı 275'tir
• Toplam 275'tir

Tablo satırlarına ve Hesap Bakiyesi görsellerine hızlı bir bakış, her hesap ve toplam tutar için sonucun doğru olduğunu gösterir. Bunun nedeni, her hesap gruplandırma işleminin bu hesabın transaction tablosuna bir filtre yayılması ile sonuçlanmasıdır.

Ancak, Customer Balance görselinde bir şey doğru görünmüyor. Müşteri Bakiyesi görselindeki her müşteri toplam bakiyeyle aynı bakiyeye sahiptir. Bu sonuç ancak her müşteri her hesabın ortak hesap sahibiyse doğru olabilir. Bu örnekte böyle bir durum söz konusu değildir. Sorun, filtre yayma ile ilgilidir. İşlem tablosuna kadar akmıyor.

Customer tablosundan Transaction tablosuna ilişki filtresi yol tariflerini izleyin. Account ve AccountCustomer tablosu arasındaki ilişkinin yanlış yönde yayıldığının açık olması gerekir. Bu ilişkinin filtre yönü Her İkisi olarak ayarlanmalıdır.

Beklendiği gibi Hesap Bakiyesi görselinde herhangi bir değişiklik yapılmamıştır.

Ancak Müşteri Bakiyesi görselleri şimdi aşağıdaki sonucu görüntüler:

• Customer-91 bakiye tutarı 75'tir
• Customer-92 bakiye tutarı 275'tir
• Toplam 275'tir

Müşteri Bakiyesi görseli artık doğru sonucu görüntüler. Filtre yönergelerini kendiniz için izleyin ve müşteri bakiyelerinin nasıl hesaplandığını görün. Ayrıca, görsel toplamın tüm müşteriler anlamına geldiğini de anlayın.

Model ilişkilerine aşina olmayan biri sonucun yanlış olduğu sonucuna varabilir. Şu soruyu sorabilirler: Customer-91 ve Customer-92 için toplam bakiye neden 350'ye (75 + 275) eşit değil?

Sorularının yanıtı, çoka çok ilişkisini anlamaktır. Her müşteri bakiyesi birden çok hesap bakiyesinin eklenmesini temsil edebilir ve bu nedenle müşteri bakiyeleri eklenebilir değildir.

Çoka çok boyutları ilişkilendirme kılavuzu

Boyut türündeki tablolar arasında çoka çok ilişkiniz olduğunda aşağıdaki yönergeleri sağlarız:

• Çoka çok ilişkili her varlığı bir model tablosu olarak ekleyerek benzersiz bir tanımlayıcı (KIMLIK) sütununa sahip olduğundan emin olmak
• İlişkili varlıkları depolamak için köprü oluşturma tablosu ekleme
• Üç tablo arasında bire çok ilişkiler oluşturma
• Filtre yayma işleminin olgu türündeki tablolara devam etmesini sağlamak için çift yönlü bir ilişki yapılandırma
• Eksik kimlik değerlerinin olması uygun olmadığında, Kimlik sütunlarının Null Atanabilir özelliğini YANLIŞ olarak ayarlayın; eksik değerler kaynaklandığında veri yenileme başarısız olur
• Köprü oluşturma tablosunu gizleyin (raporlama için gereken ek sütunlar veya ölçüler içermediği sürece)
• Raporlama için uygun olmayan kimlik sütunlarını gizleyin (örneğin, kimlikler vekil anahtar olduğunda)
• Kimlik sütununu görünür bırakmak mantıklıysa, ilişkinin "bir" slaydında olduğundan emin olun; her zaman "çok" yan sütunu gizleyin. En iyi filtre performansını elde eder.
• Karışıklığı veya yanlış yorumlamayı önlemek için, rapor kullanıcılarınıza açıklamaları iletin; metin kutuları veya görsel üst bilgi araç ipuçlarıyla açıklama ekleyebilirsiniz

Çoka çok boyut türündeki tabloları doğrudan ilişkilendirmenizi önermiyoruz. Bu tasarım yaklaşımı, çoka çok kardinalitesine sahip bir ilişki yapılandırmayı gerektirir. Kavramsal olarak elde edilebilir, ancak ilgili sütunların yinelenen değerler içereceğini gösterir. Ancak boyut türündeki tabloların bir kimlik sütunu olması iyi kabul edilmiş bir tasarım uygulamasıdır. Boyut türündeki tablolar, kimlik sütununu her zaman ilişkinin "bir" tarafı olarak kullanmalıdır.

Çoka çok olguları ilişkilendirme

İkinci çoka çok senaryo türü, olgu türündeki iki tabloyu ilişkilendirmeyi içerir. Olgu türündeki iki tablo doğrudan ilişkilendirilebilir. Bu tasarım tekniği, hızlı ve basit veri keşfi için yararlı olabilir. Ancak açıkçası bu tasarım yaklaşımını genellikle önermiyoruz. Nedenini bu bölümün ilerleyen bölümlerinde açıklayacağız.

Olgu türünde iki tablo içeren bir örneği ele alalım: Order ve Fulfillment. Sipariş tablosu sipariş satırı başına bir satır içerir ve Fulfillment tablosu sipariş satırı başına sıfır veya daha fazla satır içerebilir. Sipariş tablosundaki satırlar satış siparişlerini gösterir. Fulfillment tablosundaki satırlar, sevk edilmiş sipariş öğelerini temsil eder. Çoka çok ilişkisi iki OrderID sütununu ilişkilendirir ve yalnızca Order tablosundan filtre yayma (Sipariş, Fulfillment'ı filtreler).

İki tabloda da yinelenen OrderID değerlerinin depolanmasını desteklemek için ilişki kardinalitesi çoka çok olarak ayarlanır. Sipariş tablosunda, bir siparişin birden çok satırı olabileceğinden yinelenen OrderID değerleri bulunabilir. Siparişlerin birden çok satırı olabileceği ve sipariş satırları birçok sevkiyat tarafından karşılanabildiği için, Fulfillment tablosunda yinelenen OrderID değerleri bulunabilir.

Şimdi tablo satırlarına göz atalım. Fulfillment tablosunda, sipariş satırlarının birden çok sevkiyat tarafından karşılanabildiğine dikkat edin. (Sipariş satırının olmaması, siparişin henüz karşılanmamış olduğu anlamına gelir.)

İki tablonun satır ayrıntıları aşağıdaki madde işaretli listede açıklanmıştır:

• Order tablosunun beş satırı vardır:
  • OrderDate 1 Ocak 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 80
  • OrderDate 2 Şubat 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 20
  • OrderDate 3 Mart 2019, OrderID 3, OrderLine 1, ProductID Prod-C, OrderQuantity 5, Sales 100
• Fulfillment tablosunun dört satırı vardır:
  • FulfillmentDate 1 Ocak 2019, FulfillmentID 50, OrderID 1, OrderLine 1, FulfillmentQuantity 2
  • FulfillmentDate 2 Şubat 2019, FulfillmentID 51, OrderID 2, OrderLine 1, FulfillmentQuantity 5
  • FulfillmentDate 2 Şubat 2019, FulfillmentID 52, OrderID 1, OrderLine 1, FulfillmentQuantity 3
  • FulfillmentDate 1 Ocak 2019, FulfillmentID 53, OrderID 1, OrderLine 2, FulfillmentQuantity 10

Şimdi model sorgulandığında ne olacağını görelim. Sipariş tablosu OrderID sütununa göre sipariş ve karşılama miktarlarını karşılaştıran bir tablo görseli aşağıdadır.

Görsel doğru bir sonuç sunar. Ancak, modelin kullanışlılığı sınırlıdır; yalnızca Order tablosu OrderID sütununa göre filtreleyebilir veya gruplandırabilirsiniz.

Çoka çok olguları ilişkilendirme kılavuzu

Genel olarak, iki olgu türündeki tablonun çoka çok kardinalitesini kullanarak doğrudan ilişkilendirmesini önermeyiz. Bunun temel nedeni, modelin görselleri filtreleme veya gruplandırma yöntemlerinizde esneklik sağlamayacağındandır. Örnekte yalnızca görsellerin Order tablosu OrderID sütununa göre filtrelemesi veya gruplandırması mümkündür. Ek bir neden, verilerinizin kalitesiyle ilgilidir. Verilerinizde bütünlük sorunları varsa, sınırlı ilişkinin yapısı nedeniyle sorgulama sırasında bazı satırlar atlanabilir. Daha fazla bilgi için bkz . Power BI Desktop'ta model ilişkileri (İlişki değerlendirmesi).

Olgu türündeki tabloları doğrudan ilişkilendirmek yerine Yıldız Şeması tasarım ilkelerini benimsemenizi öneririz. Boyut türünde tablolar ekleyerek bunu yaparsınız. Daha sonra boyut türündeki tablolar, bire çok ilişkileri kullanarak olgu türündeki tablolarla ilişkilendirilir. Esnek raporlama seçenekleri sunan bu tasarım yaklaşımı sağlamdır. Boyut türündeki sütunlardan herhangi birini kullanarak filtrelemenize veya gruplandırmanıza ve ilgili olgu türündeki tabloları özetlemenize olanak tanır.

Şimdi daha iyi bir çözüm düşünelim.

Aşağıdaki tasarım değişikliklerine dikkat edin:

• Modelde artık dört tablo daha vardır: OrderLine, OrderDate, Product ve FulfillmentDate
• Ek dört tablonun tümü boyut türünde tablolardır ve bire çok ilişkiler bu tabloları olgu türündeki tablolarla ilişkilendiriyor
• OrderLine tablosu, OrderID değerinin 100 ile çarpıldığını ve OrderLine değerini (her sipariş satırı için benzersiz bir tanımlayıcı) temsil eden bir OrderLineID sütunu içerir
• Order ve Fulfillment tabloları artık bir OrderLineID sütunu içeriyor ve artık OrderID ve OrderLine sütunlarını içermiyor
• Fulfillment tablosu artık OrderDate ve ProductID sütunlarını içeriyor
• FulfillmentDate tablosu yalnızca Fulfillment tablosuyla ilgilidir
• Tüm benzersiz tanımlayıcı sütunları gizlenir

Yıldız şeması tasarım ilkelerini uygulamak için zaman ayırarak aşağıdaki avantajları sağlar:

• Rapor görselleriniz boyut türündeki tablolardan herhangi bir görünür sütuna göre filtreleyebilir veya gruplandırabilir
• Rapor görselleriniz olgu türündeki tablolardaki görünür sütunları özetleyebilir
• OrderLine, OrderDate veya Product tablolarına uygulanan filtreler olgu türündeki her iki tabloya da yayılır
• Tüm ilişkiler bire çok ilişkidir ve her ilişki normal bir ilişkidir. Veri bütünlüğü sorunları maskelenmez. Daha fazla bilgi için bkz . Power BI Desktop'ta model ilişkileri (İlişki değerlendirmesi).

Daha yüksek taneli olguları ilişkilendirme

Bu çoka çok senaryosu, bu makalede açıklanan diğer iki senaryodan çok farklıdır.

Dört tablo içeren bir örneği ele alalım: Tarih, Satış, Ürün ve Hedef. Tarih ve Ürün boyut türündeki tablolardır ve bire çok ilişkiler her biri Sales olgu türündeki tabloyla ilişkilendirilir. Şimdiye kadar iyi bir yıldız şeması tasarımını temsil ediyor. Ancak Hedef tablosu henüz diğer tablolarla ilgili değildir.

Target tablosu üç sütun içerir: Category, TargetQuantity ve TargetYear. Tablo satırları, yıl ve ürün kategorisinin ayrıntı düzeyini gösterir. Başka bir deyişle, satış performansını ölçmek için kullanılan hedefler her yıl her ürün kategorisi için ayarlanır.

Target tablosu verileri boyut türündeki tablolardan daha yüksek bir düzeyde depoladığı için bire çok ilişkisi oluşturulamaz. İlişkilerden biri için doğru. Şimdi Hedef tablonun boyut türündeki tablolarla nasıl ilişkilendirilebileceğini inceleyelim.

Daha yüksek taneli zaman aralıklarını ilişkilendirme

Tarih ve Hedef tabloları arasındaki ilişki bire çok ilişki olmalıdır. Bunun nedeni TargetYear sütun değerlerinin tarih olmasıdır. Bu örnekte her TargetYear sütun değeri hedef yılın ilk tarihidir.

İpucu

Olguları günden daha yüksek bir zaman ayrıntı düzeyinde depolarken, sütun veri türünü Tarih (veya tarih anahtarları kullanıyorsanız Tam sayı) olarak ayarlayın. sütununda, zaman aralığının ilk gününü temsil eden bir değer depolayın. Örneğin, bir yıl dönemi yılın 1 Ocak'ı olarak kaydedilir ve bir ay dönemi o ayın ilk günü olarak kaydedilir.

Ancak ay veya tarih düzeyi filtrelerinin anlamlı bir sonuç elde etmesini sağlamak için dikkatli olunmalıdır. Herhangi bir özel hesaplama mantığı olmadan rapor görselleri hedef tarihlerin her yılın ilk günü olduğunu bildirebilir. Ocak hariç diğer tüm günler ve tüm aylar hedef miktarı BLANK olarak özetler.

Aşağıdaki matris görselinde rapor kullanıcısı bir yıldan aylara kadar detaya gittiğinde ne olacağı gösterilmektedir. Görsel TargetQuantity sütununu özetliyor. (Matris satırları için veri içermeyen öğeleri göster seçeneği etkinleştirildi.)

Bu davranışı önlemek için ölçüleri kullanarak olgu verilerinizin özetlemesini denetlemenizi öneririz. Özetlemeyi denetlemenin bir yolu, alt düzey dönemler sorgulandığında BLANK döndürmektir. Bazı gelişmiş DAX'larla tanımlanan bir diğer yol da, değerleri alt düzey zaman aralıklarında takdir etmektir.

ISFILTERED DAX işlevini kullanan aşağıdaki ölçü tanımını göz önünde bulundurun. Yalnızca Tarih veya Ay sütunları filtrelenmediğinde bir değer döndürür.

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

Aşağıdaki matris görseli artık Hedef Miktar ölçüsünü kullanır. Tüm aylık hedef miktarlarının BLANK olduğunu gösterir.

Daha yüksek taneli (tarih olmayan) ilişkilendirme

Boyut türündeki bir tablodan olgu türündeki tabloya tarih olmayan bir sütun ilişkilendirilirken farklı bir tasarım yaklaşımı gerekir (ve boyut türündeki tablodan daha yüksek bir dilimdedir).

Kategori sütunları (hem Product hem de Target tablolarından) yinelenen değerler içerir. Yani bire çok ilişkisi için "bir" yok. Bu durumda, çoka çok ilişki oluşturmanız gerekir. İlişki, filtreleri boyut türündeki tablodan olgu türündeki tabloya tek bir yönde yaymalıdır.

Şimdi tablo satırlarına göz atalım.

Hedef tablosunda dört satır vardır: her hedef yıl için iki satır (2019 ve 2020) ve iki kategori (Giyim ve Aksesuarlar). Product tablosunda üç ürün vardır. İkisi giyim kategorisine, biri aksesuar kategorisine ait. Giyim renklerinden biri yeşil, kalan ikisi mavi.

Product tablosundaki Category sütununa göre bir tablo görseli gruplandırması aşağıdaki sonucu verir.

Bu görsel doğru sonucu verir. Şimdi Product tablosundaki Color sütunu hedef miktarı gruplandırmak için kullanıldığında ne olacağını düşünelim.

Görsel, verilerin yanlış tanıtılma işlemini oluşturur. Burada neler oluyor?

Product tablosundaki Color sütunundaki bir filtre iki satırla sonuçlanır. Satırlardan biri Giyim kategorisine, diğeri de Donatılar kategorisine yöneliktir. Bu iki kategori değeri Hedef tablosuna filtre olarak yayılır. Başka bir deyişle, mavi rengi iki kategorideki ürünler tarafından kullanıldığından, hedefleri filtrelemek için bu kategoriler kullanılır.

Daha önce açıklandığı gibi bu davranışı önlemek için ölçüleri kullanarak olgu verilerinizin özetlemesini denetlemenizi öneririz.

Aşağıdaki ölçü tanımını göz önünde bulundurun. Kategori düzeyinin altındaki tüm Product tablosu sütunlarının filtreler için test edilmiş olduğuna dikkat edin.

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

Aşağıdaki tablo görseli artık Hedef Miktar ölçüsünü kullanır. Tüm renk hedefi miktarlarının BLANK olduğunu gösterir.

Son model tasarımı aşağıdaki gibi görünür.

Daha ayrıntılı olguları ilişkilendirme kılavuzu

Boyut türündeki bir tabloyu olgu türündeki bir tabloyla ilişkilendirmeniz gerektiğinde ve olgu türündeki tablo satırları boyut türündeki tablo satırlarından daha yüksek bir dilimde depoladığında, aşağıdaki kılavuzu sağlarız:

• Daha yüksek taneli olgu tarihleri için:
  • Olgu türündeki tabloda, dönemin ilk tarihini depolayın
  • Tarih tablosu ile olgu türündeki tablo arasında bire çok ilişkisi oluşturma
• Diğer daha yüksek taneli olgular için:
  • Boyut türündeki tablo ile olgu türündeki tablo arasında çoka çok ilişki oluşturma
• Her iki tür için:
  • Ölçü mantığıyla özetlemeyi denetleme— filtrelemek veya gruplandırmak için alt düzey boyut türündeki sütunlar kullanıldığında BLANK döndürür
  • Ö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ılabilir

İlgili içerik

Bu makaleyle ilgili daha fazla bilgi için aşağıdaki kaynaklara göz atın:

• Power BI Desktop'ta model ilişkileri
• Yıldız şemasını ve Power BI'ın önemini anlama
• İlişki sorunlarını giderme kılavuzu
• Sorularınız var mı? Power BI Topluluğu sormayı deneyin
• Öneri? Power BI'ı geliştirmek için fikirlere katkıda bulunma