Ç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.
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 Modeli 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 için önemini anlama.
Üç 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
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,
Burada üç model tablosunun basit bir diyagramı verilmiştir.
Üç model tablosunu gösteren
İ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ı 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şkiliCustomerID
91 -
AccountID
1,CustomerID
92 ile ilişkilidir. -
AccountID
2 ile ilişkilidirCustomerID
92
-
-
Transaction
tablosunun üç satırı vardır:-
Date
Ocak 2019,AccountID
1Amount
100 -
Date
2 Şubat 2019,AccountID
2Amount
200 -
Date
3 Mart 2019,AccountID
1Amount
-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, 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ü Both
olarak 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,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
1FulfillmentQuantity
2 -
FulfillmentDate
2 Şubat 2019,FulfillmentID
51,OrderID
2,OrderLine
1FulfillmentQuantity
5 -
FulfillmentDate
2 Şubat 2019,FulfillmentID
52,OrderID
1,OrderLine
1FulfillmentQuantity
3 -
FulfillmentDate
1 Ocak 2019,FulfillmentID
53,OrderID
1,OrderLine
2FulfillmentQuantity
10
-
Ş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
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
,Product
veFulfillmentDate
. - 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 olanOrderLine
sütun değerini içerir. -
Order
veFulfillment
tabloları artık birOrderLineID
sütunu içerir ve artıkOrderID
veOrderLine
sütunlarını içermez. -
Fulfillment
tablosu artıkOrderDate
veProductID
sütunlarını içerir. -
FulfillmentDate
tablosunun yalnızcaFulfillment
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
,OrderDate
veyaProduct
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
, Product
ve 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
, 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.
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.
Bahşiş
Olguları günden daha yüksek bir zaman ayrıntı düzeyinde depolarken, sütun veri türünü Tarih
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
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