Çoka çok ilişki kılavuzu

Bu makalede Power BI Desktop ile çalışan bir veri modelleyicisi olarak hedefleniyorsunuz. Üç 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.

Üç farklı çoka çok senaryosu vardır. Bunlar, şu durumlarda ortaya çıkabilir:

• İki boyut tablosunu ilişkilendirme
• İki olgu tablosunu ilişkilendirme
• olgu tablosu satırları boyut tablosu satırlarından daha yüksek bir tanecikte depoladığındayüksek taneli olgu tablolarını ilişkilendirin

Çoka çok boyutları ilişkilendirme

Klasik çoka çok senaryosu, banka müşterileri ve banka hesapları gibi iki varlıkla ilgilidir. 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 genellikleortak hesap sahipleri olarak adlandırılır.

Bu varlıkları modellemek çok kolaydır. Bir boyut tablosu hesapları, başka bir boyut tablosu ise müşterileri depolar. Boyut tablolarının özelliğinde olduğu gibi, her tabloda benzersiz bir tanımlayıcı (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 tablosuolarak adlandırılır. Bu örnekte amaç, her müşteri hesabı ilişkisi için bir satır depolamaktır. İlginç bir şekilde, bu tablo yalnızca tanımlayıcı sütunları içerdiğinde,olgu içermeyen olgu tablosu olarak adlandırılır.

Burada üç model tablosunun basit bir diyagramı verilmiştir.

Üç model tablosunu gösteren

İlk tablo Accountolarak adlandırılır ve iki sütun içerir: AccountID ve Account. İkinci tablo AccountCustomerolarak adlandırılır ve iki sütun içerir: AccountID ve CustomerID. Üçüncü tablo Customerolarak 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ı bir olgu tablosu eklendi. Hesap işlemlerini kaydeder. Köprüleme tablosu ve tüm tanımlayıcı 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.

Model tablolarını ve satırlarını gösteren

Dört tablonun satır ayrıntıları aşağıdaki madde işaretli listede gösterilir:

• Account tablosunun iki satırı vardır:
  • AccountID 1, Hesap-01 içindir.
  • AccountID 2Account-02 içindir
• Customer tablosunun iki satırı vardır:
  • CustomerID 91Müşteri-91 içindir
  • CustomerID 92Müşteri-92 içindir
• AccountCustomer tablosunun üç satırı vardır:
  • AccountID 1 ile ilişkili CustomerID91
  • AccountID 1, CustomerID92 ile ilişkilidir.
  • AccountID 2 ile ilişkilidir CustomerID92
• Transaction tablosunun üç satırı vardır:
  • Date Ocak 2019, AccountID1Amount100
  • Date 2 Şubat 2019, AccountID2Amount200
  • Date 3 Mart 2019, AccountID1Amount-25

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

Aşağıdaki görüntüde, Transaction tablosunun Amount sütununu özetleyen iki tablo görseli vardır. İlk görsel, hesaba göre gruplandırıldığı için, sütunlarının toplamıhesap bakiyesini temsil eder. İkinci görsel müşterilere göre gruplandırıldığı için Amount sütunlarının toplamı müşteri bakiyesini temsil eder.

yan yana oturan iki tablo görseli gösteren

İlk tablo görselinin (Hesap Bakiyesi) iki sütunu vardır: Account ve Amount. Aşağıdaki sonucu görüntüler:

• Account-01 bakiye tutarı 75.
• Account-02 bakiye tutarı 200.
• Toplam 275.

İkinci tablo görselinin (Customer Balance) iki sütunu vardır: Customer ve Amount. Aşağıdaki sonucu görüntüler:

• Customer-91 bakiye tutarı 275.
• Customer-92 bakiye tutarı 275.
• Toplam 275.

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. Bu görseldeki her müşterinin bakiyesi toplam bakiyeyle aynı. 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. Bir sorun var ve bu filtre yayılımı ile ilgili. Filtreler tam anlamıyla Transaction tablosuna ulaşmıyor.

Customer tablosundan Transaction tablosuna ilişki filtresi yönergelerini izlerseniz, Account ve AccountCustomer tabloları arasındaki ilişkinin yanlış yönde yayıldığını belirleyebilirsiniz. Bu ilişkinin filtre yönü Botholarak ayarlanmalıdır.

Yan yana oturan iki rapor görselini gösteren

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

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

• Customer-91 bakiye tutarı 75.
• Customer-92 bakiye tutarı 275.
• Toplam 275.

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 anlamının tüm müşterilerolduğunu da anlayın.

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

Sorularının yanıtı, çoka çok ilişkisini anlamakta yatar. Her müşteri bakiyesi birden çok hesap bakiyesinin eklenmesini temsil edebilir ve bu nedenle müşteri bakiyeleri toplanamayan.

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

Boyut tabloları arasında çoka çok ilişkiniz varsa şu yönergeleri izleyin:

• Çoka çok ilişkili her varlığı bir model tablosu olarak ekleyin ve ID sütununa sahip olmasını sağlayın.
• İlişkili varlıkları depolamak için köprü oluşturma tablosu ekleyin.
• Üç tablo arasında bire çok ilişkiler oluşturun.
• Filtre yayma işleminin olgu tablosuna devam etmesini sağlamak için, için bir çift yönlü ilişki ayarlayın.
• Eksik kimlik değerlerinin olması uygun olmadığında Is Nullable özelliğini devre dışı bırakın; eksik değerler kaynaklandığında veri yenileme başarısız olur.
• Köprü oluşturma tablosunu gizleyin (raporlama için gereken diğer sütunları veya ölçüleri içermediği sürece).
• Raporlama için uygun olmayan kimlik sütunlarını gizleyin (örneğin, sütunlar vekil anahtar değerlerini depoladığında).
• Kimlik sütununu görünür bırakmak mantıklıysa, ilişkinin "bir" tarafında olduğundan emin olun; her zaman "çok" taraf sütununu gizleyin. Bunun nedeni, "bir" slayda uygulanan filtrelerin daha iyi filtre performansına neden olmasıdır.
• Karışıklığı veya yanlış yorumlamayı önlemek için, açıklamalarınızı rapor kullanıcılarınıza iletin. Metin kutuları veya görsel üst bilgi araç ipuçlarıile açıklamalar ekleyebilirsiniz.

Çoka çok boyut tablolarını doğrudan ilişkilendirmenizi önermiyoruz. Bu tasarım yaklaşımı, çoka çok kardinalitesine sahip bir ilişki ayarlamayı gerektirir. Kavramsal olarak elde edilebilir, ancak ilgili sütunların yinelenen değerler içerebileceği anlamına gelir. Bununla birlikte, boyut tablolarında kimlik sütunu olması iyi kabul edilmiş bir tasarım uygulamasıdır. Boyut tabloları, kimlik sütununu her zaman ilişkinin "bir" tarafı olarak kullanmalıdır.

Çoka çok olguları ilişkilendirme

Farklı bir çoka çok senaryo türü, iki olgu tablosu arasında ilişki kurulmasını kapsar. İki olgu tablosu 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.

İki olgu tablosu içeren bir örneği ele alalım: Order ve Fulfillment. Order 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. Order tablosundaki satırlar satış siparişlerini gösterir. Fulfillment tablosundaki satırlar, sevk edilmiş sipariş öğelerini temsil eder. Çoka çok ilişkisi, her tablodaki OrderID sütunlarını yalnızca Order tablosundan filtre yaymayla ilişkilendirir (Order tablo Fulfillment tabloyu filtreler).

Diyagram, Sipariş ve Teslimat adlı iki tablo içeren bir modeli gösteriyor.

İlişki kardinalitesi, yinelenen OrderID sütun değerlerinin her iki tabloda da depolanmasını desteklemek için Many-to-many olarak ayarlanır. Order tablosunda, bir siparişin birden çok satırı olabileceğinden yinelenen kimlik (ID) değerleri bulunabilir. Fulfillment tablosunda yinelenen kimlik değerleri bulunabilir çünkü siparişler birden çok satıra sahip olabilir ve sipariş satırları birçok sevkiyatla gönderilebilir.

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

Model tablo satırlarını gösteren

İ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, OrderID1, OrderLine1, ProductIDProd-A, OrderQuantity5, Sales50
  • OrderDate 1 Ocak 2019, OrderID1, OrderLine2, ProductIDProd-B, OrderQuantity10, Sales80
  • OrderDate 2 Şubat 2019, OrderID2, OrderLine1, ProductIDProd-B, OrderQuantity5, Sales40
  • OrderDate 2 Şubat 2019, OrderID2, OrderLine2, ProductIDProd-C, OrderQuantity1, Sales20
  • OrderDate 3 Mart 2019, OrderID3, OrderLine1, ProductIDProd-C, OrderQuantity5, Sales100
• Fulfillment tablosunun dört satırı vardır:
  • FulfillmentDate 1 Ocak 2019, FulfillmentID50, OrderID1, OrderLine1FulfillmentQuantity2
  • FulfillmentDate 2 Şubat 2019, FulfillmentID51, OrderID2, OrderLine1FulfillmentQuantity5
  • FulfillmentDate 2 Şubat 2019, FulfillmentID52, OrderID1, OrderLine1FulfillmentQuantity3
  • FulfillmentDate 1 Ocak 2019, FulfillmentID53, OrderID1, OrderLine2FulfillmentQuantity10

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

Üç sütunlu tablo görselini gösteren

Görsel doğru bir sonuç sunar. Ancak, yalnızca Order tablo OrderID sütununa göre filtreleyebileceğiniz veya gruplandırabildiğiniz için modelin kullanışlılığı sınırlıdır.

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

Genellikle, iki olgu tablosunu çoka çok kardinalitesini kullanarak doğrudan ilişkilendirmenizi önermeyiz. Bunun temel nedeni, modelin rapor görsellerinizin filtre veya grup oluşturma yöntemlerinde esneklik sağlamayacağındandır. Örnekte, görsellerin yalnızca Order tablo OrderID sütununa göre filtrelemesi veya gruplandırması mümkündür. Başka bir neden de verilerinizin kalitesiyle ilgilidir. Verilerinizde bütünlük sorunları varsa, çok kişilik kardinalite vesınırlı ilişkiler nedeniyle sorgulama sırasında bazı satırlar atlanabilir.

Olgu tablolarını doğrudan ilişkilendirmek yerine, yıldız şeması tasarım uygulamanızı öneririz. Bu, boyut tabloları eklediğiniz anlamına gelir. Bu boyut tabloları daha sonra bire çok ilişkileri kullanarak olgu tablolarına ilişkilendirilir. Bu tasarım yaklaşımı, esnek raporlama seçeneklerini verimli bir şekilde sunmasıyla sağlamdır. Boyut tablosu sütunlarından herhangi birini kullanarak filtrelemenize veya gruplandırmanıza ve ilgili olgu tablolarından herhangi birinin sütunlarını özetlemenize olanak tanır.

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

Altı tablodan oluşan modeli gösteren

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

• Modelde artık dört ek tablo vardır: OrderLine, OrderDate, Productve FulfillmentDate.
• Bu dört ek tablonun tümü, bire çok ilişkilerin olgu tablolarını ilişkilendirdiği boyut tablolarıdır.
• OrderLine tablosu, OrderID değerinin 100 ile çarpıldığı OrderLineID sütununu ve her sipariş satırı için bir kimlik olan OrderLine sütun değerini içerir.
• Order ve Fulfillment tabloları artık bir OrderLineID sütunu içerir ve artık OrderID ve OrderLine sütunlarını içermez.
• Fulfillment tablosu artık OrderDate ve ProductID sütunlarını içerir.
• FulfillmentDate tablosunun yalnızca Fulfillment tablosuyla ilişkisi vardır.
• Tüm kimlik sütunları gizlenir.

Yıldız şeması tasarımını benimsemeye zaman ayırarak aşağıdaki avantajları sağlar:

• Rapor görselleriniz boyut tablolarındaki görünür herhangi bir sütuna göre filtreleyebilir veya gruplandırabilir.
• Rapor görselleriniz olgu tablolarındaki görünür sütunlardan özetleyebilir.
• OrderLine, OrderDateveya Product tablolarına uygulanan filtreler her iki olgu tablosuna da yayılır.
• Tüm ilişkiler bire çok ilişkidir ve her ilişki düzenli ilişki'dir. Veri bütünlüğü sorunları maskelenmez. İlişki değerlendirmesi hakkında daha fazla bilgi için bkz. Power BI DesktopModel ilişkileri.

Daha yüksek taneli olguları ilişkilendirme

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

Dört tablo içeren bir örneği ele alalım: Date, Sales, Productve Target. Date ve Product tabloları boyut tablolarıdır ve bire çok ilişkiler her biri Sales olgu tablosuyla ilişkilendirilir. Şimdiye kadar iyi bir yıldız şeması tasarımını temsil ediyor. Ancak Target tablosu henüz diğer tablolarla ilişkili değildir.

Target tablosu üç sütun içerir: Category, TargetQuantityve 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.

Satış ve Hedef olgu tablolarını gösteren

Target tablosu verileri boyut tablolarından daha yüksek bir düzeyde depoladığı için bire çok ilişkisi oluşturulamaz. Aslında, bu sadece bir ilişki için geçerli. şimdi Target tablosunun boyut tablolarına nasıl bağlanabileceğini inceleyelim.

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

Date ve Target tabloları arasındaki ilişki bire çok bir ilişki olmalıdır. Bunun nedeni, TargetYear sütun değerlerinin tarih olmasıdır. Bu örnekte, her TargetYear sütunu hedef yılın ilk tarihini depolar.

Ancak ay veya tarih düzeyi filtrelerinin anlamlı bir sonuç elde etmesini sağlamak için dikkatli olunmalıdır. Ö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 özetler. (Matris satırları için Veri içermeyen öğeleri göster seçeneği etkinleştirilmiştir.)

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 seviye zaman dilimlerine dağıtmaktır.

ISFILTERED DAX işlevini kullanan aşağıdaki ölçü tanımını göz önünde bulundurun. Yalnızca Date ve Month 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 Target Quantity ölçüsünü kullanır. Tüm aylık hedef miktarlarının BLANK olduğunu gösterir.

İki matris görseli gösteren

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

Boyut tablosundaki tarih dışı bir sütunu, daha yüksek bir detay düzeyine sahip olan olgu tablosuna ilişkilendirirken farklı bir tasarım yaklaşımı gereklidir.

Category sütunları (hem Product hem de Target tablolarından) yinelenen değerler içerir. Yani bire çok ilişkisinin "bir" tarafı yoktur. Bu durumda, çoka çok ilişki oluşturmanız gerekir. İlişki, filtreleri boyut tablosundan olgu tablosuna tek bir yönde yaymalıdır.

Hedef ve Ürün tablolarının modelini gösteren

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

İki tablo içeren bir modeli gösteren

Target 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. Ancak bu görsel doğru sonucu verir. Şimdi hedef miktarı gruplandırmak için Product tablosundaki Color sütunu kullanıldığında ne olacağını düşünelim.

İki tablo görselini gösteren bir diyagram. İlki Kategoriye göre gruplandırır, ikincisi ise Renge göre gruplandırır. İkinci görsel yanlış sonuç verir.

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

Product tablosundaki Color sütununa uygulanan bir filtre, iki satır döndürür. Satırlardan biri Giyim kategorisine, diğeri de Donatılar kategorisine yöneliktir. Bu iki kategori değeri, Target 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 tablo 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 Target Quantity ölçüsünü kullanır. Tüm renk hedefi miktarlarının BLANK olduğunu gösterir.

İki tablo görselini gösteren

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

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

Boyut tablosunu olgu tablosu ile ilişkilendirmeniz gerektiğinde ve olgu tablosundaki satırlar boyut tablosundaki satırlardan daha yüksek bir detay seviyesinde depolandığında, şu yönergeleri izleyin:

• Daha yüksek taneli olgu tarihleri için
  • Olgu tablosunda, dönemin ilk tarihini depolayın.
  • Tarih tablosu ile olgu tablosu arasında bire-çok ilişkisi oluşturun.
• Diğer daha yüksek taneli olgular için
  • Boyut tablosu ile olgu tablosu arasında çoka çok ilişki oluşturun.
• her iki tür için de
  • Ölçü mantığıyla özetlemeyi denetleyin; filtrelemek veya gruplandırmak için alt düzey boyut sütunları kullanıldığında BLANK döndürür.
  • Özetlenebilir olgu tablosu sütunlarını gizleyin; bu, olgu tablosunu özetlemek için yalnızca ölçülerin kullanılabilmesini sağlar.

İlgili içerik

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

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