Power BI Desktop'ta model ilişkileri

Bu makale, Power BI Desktop ile çalışan içeri aktarma veri modelleyicilerini hedefler. Sezgisel, doğru ve en uygun modelleri sunmak için gerekli olan önemli bir model tasarımı konusudur.

Tablo rolleri ve ilişkiler de dahil olmak üzere en uygun model tasarımı hakkında daha ayrıntılı bir tartışma için bkz. Yıldız şemasını ve Power BI'ın önemini anlama.

İlişki amacı

Model ilişkisi, bir model tablosunun sütununa uygulanan filtreleri bir başka model tablosuna aktarır. Filtreler, izlenecek bir ilişki yolu olduğu sürece yayılır ve bu da birden çok tabloya yayılmayı içerebilir.

İlişki yolları belirleyicidir, yani filtreler her zaman aynı şekilde ve rastgele varyasyon olmadan yayılır. Ancak ilişkiler devre dışı bırakılabilir veya belirli DAX işlevlerini kullanan model hesaplamaları tarafından filtre bağlamı değiştirilebilir. Daha fazla bilgi için bu makalenin devamında yer alan İlgili DAX işlevleri konusuna bakın.

Önemli

Model ilişkileri veri bütünlüğünü zorlamaz. Daha fazla bilgi için bu makalenin devamında yer alan ve verilerinizde veri bütünlüğü sorunları olduğunda model ilişkilerinin nasıl davrandığını açıklayan İlişki değerlendirme konusuna bakın.

İlişkilerin animasyonlu bir örnekle filtreleri yayma şekli aşağıda verilmiştir.

Bu örnekte model dört tablodan oluşur: Kategori, Ürün, Yıl ve Satış. Kategori tablosu Product tablosuyla, Product tablosu ise Sales tablosuyla ilgilidir. Year tablosu Sales tablosuyla da ilgilidir. Tüm ilişkiler bire-çoktur (ayrıntıları bu makalenin devamında açıklanmıştır).

Büyük olasılıkla Power BI kart görseli tarafından oluşturulan bir sorgu, tek bir kategori olan Cat-A ve tek bir yıl cy2018 için yapılan satış siparişlerinin toplam satış miktarını istemektedir. Bu nedenle , Kategori ve Yıl tablolarında uygulanan filtreleri görebilirsiniz. Kategori tablosundaki filtre, Cat-A kategorisine atanan iki ürünü yalıtmak için Product tablosuna yayılır. Ardından Product tablosu filtreleri Sales tablosuna yayarak bu ürünler için yalnızca iki satış satırını yalıtır. Bu iki satış satırı , Cat-A kategorisine atanan ürünlerin satışlarını temsil eden bir satırdır. Birleştirilmiş miktarları 14 birimdir. Aynı zamanda Year tablosu filtresi, Sales tablosunu daha ayrıntılı olarak filtreler ve sonuçta Cat-A kategorisine atanan ve CY2018 yılında sipariş edilen ürünlere ait yalnızca bir satış satırı elde edilir. Sorgu tarafından döndürülen miktar değeri 11 birimdir. Bir tabloya birden çok filtre uygulandığında (bu örnekteki Sales tablosu gibi), bunun her zaman bir AND işlemi olduğunu ve tüm koşulların doğru olması gerektiğini unutmayın.

Yıldız şeması tasarım ilkelerini uygulama

Boyut ve olgu tablolarını içeren bir model oluşturmak için yıldız şeması tasarım ilkelerini uygulamanızı öneririz. Power BI'ın boyut tablolarını filtreleyen kuralları zorunlu kılması ve model ilişkilerinin bu filtreleri olgu tablolarına verimli bir şekilde yaymasına olanak tanıyacak şekilde ayarlanması yaygın bir durumdur.

Aşağıdaki görüntü Adventure Works satış analizi veri modelinin model diyagramıdır. Sales adlı tek bir olgu tablosunu içeren bir yıldız şeması tasarımı gösterir. Diğer dört tablo ise tarihe, eyalete, bölgeye ve ürüne göre satış ölçülerinin analizini destekleyen boyut tablolarıdır. Tüm tabloları bağlayan model ilişkilerine dikkat edin. Bu ilişkiler filtreleri (doğrudan veya dolaylı olarak) Sales tablosuna yayılır.

Bağlantısı kesilmiş tablolar

Başka bir model tablosuyla ilişkili olmaması alışılmadık bir durumdur. Geçerli bir model tasarımındaki böyle bir tablo , bağlantısı kesilmiş bir tablo olarak tanımlanır. Bağlantısı kesilmiş bir tablo, filtreleri diğer model tablolarına yaymak için tasarlanmamıştır. Bunun yerine, "kullanıcı girişi" (dilimleyici görseliyle olabilir) kabul ederek model hesaplamalarının giriş değerini anlamlı bir şekilde kullanmasına olanak tanır. Örneğin, çeşitli döviz kuru değerleriyle yüklü bağlantısız bir tablo düşünün. Tek bir fiyat değerine göre filtrelemek için bir filtre uygulandığı sürece, ölçü ifadesi satış değerlerini dönüştürmek için bu değeri kullanabilir.

Power BI Desktop varsayım parametresi, bağlantısı kesilmiş bir tablo oluşturan bir özelliktir. Daha fazla bilgi için bkz Power BI Desktop'ta değişkenleri görselleştirmek için Ne Olursa Parametresi oluşturma ve kullanma.

İlişki özellikleri

Model ilişkisi, tablodaki bir sütunu farklı bir tablodaki bir sütunla ilişkilendirmektedir. (Bu gereksinimin doğru olmadığı özel bir durum vardır ve yalnızca DirectQuery modellerindeki çok sütunlu ilişkiler için geçerlidir. Daha fazla bilgi için COMBINEVALUES DAX işlevi makalesine bakın.)

Uyarı

Bir sütunu aynı tablodaki farklı bir sütunla ilişkilendirmek mümkün değildir. Bu kavram bazen tablonun kendi kendine başvurduğu ilişkisel veritabanı yabancı anahtar kısıtlaması tanımlama yeteneğiyle karıştırılır. Ebeveyn-çocuk ilişkilerini depolamak için bu ilişkisel veritabanı kavramını kullanabilirsiniz (örneğin, her çalışan kaydı bir 'üstüne rapor' veren çalışanla ilişkilidir). Ancak, bu tür bir ilişkiyi temel alan bir model hiyerarşisi oluşturmak için model ilişkilerini kullanamazsınız. Üst-alt hiyerarşi oluşturmak için Ebeveyn ve Çocuk işlevler'e bakın.

Veri türleri sütunlar

İlişkinin hem "kimden" hem de "kime" sütununun veri türü aynı olmalıdır. DateTime sütunlarında tanımlanan ilişkilerle çalışmak beklendiği gibi davranmayabilir. Power BI verilerini depolayan, yalnızca DateTime veri türlerini kullanan altyapı; Tarih, Saat ve Tarih/Saat/Saat Dilimi veri türleri, üstte uygulanan Power BI biçimlendirme yapılarıdır. Modele bağımlı nesneler altyapıda DateTime (ilişkiler, gruplar vb.) olarak görünmeye devam eder. Bu nedenle, bir kullanıcı bu tür sütunlar için Modellemesekmesinden Tarih'i seçerse, verilerin saat kısmı altyapı tarafından hala dikkate alındığından aynı tarih olarak kaydedilmez. Tarih/saat türlerinin nasıl işlenme şekli hakkında daha fazla bilgi edinin. Davranışı düzeltmek için, Power Query Düzenleyicisi'nde sütun veri türlerinin, içeri aktarılan verilerden Time kısmını kaldıracak şekilde güncellenmesi gerekir, böylece işlem motoru verileri işlerken değerlerin aynı görünmesi sağlanır.

Önem düzeyi

Her model ilişkisi bir kardinalite türüyle tanımlanır. "from" ve "to" ilgili sütunlarının veri özelliklerini temsil eden dört kardinalite türü seçeneği vardır. "Bir" tarafı sütunun benzersiz değerler içerdiği anlamına gelir; "çok" tarafı sütunun yinelenen değerler içerebileceği anlamına gelir.

Uyarı

Bir veri yenileme işlemi yinelenen değerleri "bir" yan sütuna yüklemeyi denerse, veri yenileme işleminin tamamı başarısız olur.

Dört seçenek, kısaltma notasyonlarıyla birlikte aşağıdaki madde işaretli listede açıklanmıştır.

• Bire-çok (1:*)
• Çoka bir (*:1)
• Bire bir (1:1)
• Çoka çok (*:*)

Power BI Desktop'ta bir ilişki oluşturduğunuzda tasarımcı kardinalite türünü otomatik olarak algılar ve ayarlar. Power BI Desktop, hangi sütunların benzersiz değerler içerdiğini öğrenmek için modeli sorgular. İçeri aktarma modelleri için iç depolama istatistiklerini kullanır; DirectQuery modelleri için veri kaynağına profil oluşturma sorguları gönderir. Ancak bazen Power BI Desktop bunu yanlış anlayabilir. Tablolar henüz veri yüklenemediğinde veya yinelenen değerler içermesini beklediğiniz sütunlar şu anda benzersiz değerler içerdiği için bu durum yanlış olabilir. Her iki durumda da, herhangi bir "bir" yan sütun benzersiz değerler içerdiği sürece kardinalite türünü güncelleştirebilirsiniz (veya tablo henüz veri satırlarıyla yüklenmedi).

Bire çok (ve çoka bir) kardinalitesi

Bire çok ve çoka bir kardinalite seçenekleri temelde aynıdır ve aynı zamanda en yaygın kardinalite türleridir.

Birden çoğa veya çoktan bire ilişki yapılandırırken, sütunları ilişkilendirdiğiniz sıraya uygun olan ilişkiyi seçersiniz. Her tabloda bulunan ProductID sütununu kullanarak Product tablosundan Sales tablosuna ilişkin ilişkiyi nasıl yapılandırabileceğinizi düşünün. Product tablosundaki ProductID sütunu benzersiz değerler içerdiğinden, kardinalite türü bire çok olacaktır. Tabloları ters yönde, Satış'tan Ürün'e doğru ilişkilendirdiyseniz, kardinalite çoka-bir olur.

Bire bir kardinalite

Bire-bir ilişki, her iki sütunun da benzersiz değerler içerdiği anlamına gelir. Bu kardinalite türü yaygın değildir ve büyük olasılıkla yedekli verilerin depolanması nedeniyle bir altoptimal model tasarımını temsil eder.

Bu kardinalite türünü kullanma hakkında daha fazla bilgi için bkz . Bire bir ilişki kılavuzu.

Çoka çok kardinalitesi

Çoktan çoğa ilişki, her iki sütunda da yinelenen değerler bulunabileceği anlamına gelir. Bu kardinalite türü seyrek kullanılır. Genellikle karmaşık model gereksinimleri tasarlarken kullanışlıdır. Bunu, çoka çok olguları ilişkilendirmek veya daha ince taneli olguları ilişkilendirmek için kullanabilirsiniz. Örneğin, satış hedefi bilgileri ürün kategorisi düzeyinde ve ürün boyutu tablosu ürün düzeyinde depolandığında.

Bu kardinalite türünü kullanım kılavuzu için bkz Çoktan çoka ilişki yönergeleri.

Uyarı

Çoka çok kardinalite türü, Ocak 2024 ve daha sonraki dönemler için Power BI Rapor Sunucusu için geliştirilen modellerde desteklenir.

Tavsiye

Power BI Desktop model görünümünde, ilişki çizgisinin iki tarafındaki göstergelere (1 veya *) bakarak ilişkinin kardinalite türünü yorumlayabilirsiniz. Hangi sütunların ilişkili olduğunu belirlemek için, sütunları vurgulamak için ilişki çizgisini seçmeniz veya imlecin üzerine gelmeniz gerekir.

Çapraz filtre yönü

Her model ilişkisi çapraz filtre yönüyle tanımlanır. Ayarınız, filtrelerin yayılacağı yönü belirler. Olası çapraz filtre seçenekleri kardinalite türüne bağlıdır.

Kardinalite türü	Çapraz filtre seçenekleri
Bire Çok (veya Çok'a Bir)	Tek Her ikisi
Bire bir	Her ikisi
Çok-çok	Tek (Tablo1-Tablo2) Tek (Tablo2-Tablo1) Her ikisi

Tek çapraz filtre yönü "tek yön" ve Her ikisi de "her iki yön" anlamına gelir. Her iki yönde de filtreleyen bir ilişki genellikle çift yönlü olarak tanımlanır.

Bire çok ilişkiler için çapraz filtre yönü her zaman "bir" tarafından ve isteğe bağlı olarak "çok" tarafından (çift yönlü) olur. Bire bir ilişkiler için çapraz filtreleme yönü her zaman her iki tablodandır. Son olarak, çoka çok ilişkiler için çapraz filtre yönü tablolardan birinden veya her iki tablodan da olabilir. Kardinalite türü "bir" tarafı içerdiğinde, bu filtrelerin her zaman bu taraftan yayılacağına dikkat edin.

Çapraz filtre yönü Her İkisi olarak ayarlandığında, başka bir özellik kullanılabilir duruma gelir. Power BI satır düzeyi güvenlik (RLS) kurallarını zorunlu kıldığında çift yönlü filtreleme uygulayabilir. RLS hakkında daha fazla bilgi için bkz. Power BI Desktop ile satır düzeyi güvenlik (RLS).

Model hesaplaması kullanarak filtre yayma özelliğini devre dışı bırakma dahil olmak üzere ilişki çapraz filtre yönünü değiştirebilirsiniz. CROSSFILTER DAX işlevi kullanılarak elde edilir.

çift yönlü ilişkilerin performansı olumsuz etkileyeebileceğini unutmayın. Ayrıca, çift yönlü ilişki yapılandırma girişimi belirsiz filtre yayma yollarına neden olabilir. Bu durumda, Power BI Desktop ilişki değişikliğini işleyemeyebilir ve sizi bir hata iletisiyle uyarır. Ancak bazen Power BI Desktop, tablolar arasında belirsiz ilişki yolları tanımlamanıza olanak tanıyabilir. İlişki yolu belirsizliğini çözümleme, bu makalenin devamında açıklanmıştır.

Yalnızca gerektiğinde çift yönlü filtreleme kullanmanızı öneririz. Daha fazla bilgi için bkz . çift yönlü ilişki kılavuzu.

Tavsiye

Power BI Desktop model görünümünde, ilişki çizgisi boyunca ok uçlarını fark ederek bir ilişkinin çapraz filtre yönünü yorumlayabilirsiniz. Tek bir ok ucu, ok ucu yönünde tek yönlü bir filtreyi temsil eder; çift ok ucu çift yönlü ilişkiyi temsil eder.

Bu ilişkiyi etkinleştir

İki model tablosu arasında yalnızca bir etkin filtre yayma yolu olabilir. Ancak, bu ilişkileri etkin olmayan olarak ayarlamanız gerekse de, ek ilişki yolları eklemek mümkündür. Etkin olmayan ilişkiler yalnızca model hesaplaması değerlendirmesi sırasında etkin hale getirilebilir. USERELATIONSHIP DAX işlevi kullanılarak elde edilir.

Genellikle mümkün olduğunda etkin ilişkileri tanımlamanızı öneririz. Rapor yazarlarının modelinizi nasıl kullanabileceğinin kapsamını ve potansiyelini genişletiyorlar. Yalnızca etkin ilişkilerin kullanılması, rol oynayan boyut tablolarının modelinizde çoğaltılması gerektiği anlamına gelir.

Ancak belirli durumlarda, rol oynayan bir boyut tablosu için bir veya daha fazla pasif ilişki tanımlayabilirsiniz. Aşağıdaki durumlarda bu tasarımı göz önünde bulundurabilirsiniz:

• Rapor görsellerinin aynı anda farklı rollere göre filtrelemesi gerekmez.
• Belirli bir ilişkiyi etkinleştirmek için USERELATIONSHIP DAX işlevini, ilgili model hesaplamalarında kullanırsınız.

Daha fazla bilgi için bkz . Etkin ve etkin olmayan ilişki kılavuzu.

Tavsiye

Power BI Desktop model görünümünde, bir ilişkinin etkin ve etkin olmayan durumunu yorumlayabilirsiniz. Etkin bir ilişki düz çizgiyle gösterilir; etkin olmayan bir ilişki kesikli çizgi olarak gösterilir.

Bağıntısal bütünlüğü varsay

Bağlamsal bütünlük varsay özelliği, yalnızca aynı kaynak grubuna ait iki DirectQuery depolama modundaki tablo arasındaki bire çok ve bire bir ilişkiler için kullanılabilir. Bu özelliği, "birçok" yanındaki sütun NULL içermediğinde etkinleştirebilirsiniz.

Etkinleştirildiğinde, veri kaynağına gönderilen yerel sorgular, bir OUTER JOIN yerine INNER JOIN kullanarak iki tabloyu birleştirir. Genellikle, bu özelliğin etkinleştirilmesi sorgu performansını artırır, ancak veri kaynağının özelliklerine bağlıdır.

İki tablo arasında bir veritabanı yabancı anahtar kısıtlaması olduğunda bu özelliği her zaman etkinleştirin. Yabancı anahtar kısıtlaması olmasa bile, belirli bir veri bütünlüğü mevcut olduğu sürece özelliği etkinleştirmeyi göz önünde bulundurun.

Önemli

Veri bütünlüğü tehlikeye girerse, iç birleşim tablolar arasındaki eşleşmeyen satırları ortadan kaldırır. Örneğin, ilgili Product tablosunda mevcut olmayan bir ProductID sütun değerine sahip bir model Sales tablosu düşünün. Product tablosundan Sales tablosuna filtre yayma, bilinmeyen ürünlerin satış satırlarını ortadan kaldırır. Bu, satış sonuçlarının yetersiz ifade edilmesine neden olur.

Daha fazla bilgi için bkz . Power BI Desktop'ta bilgi tutarlılığı ayarlarını varsay.

İlgili DAX işlevleri

Model ilişkileriyle ilgili birkaç DAX işlevi vardır. Her işlev aşağıdaki madde işaretli listede kısaca açıklanmıştır:

• RELATED: Bir ilişkinin "bir tarafındaki" değeri alır. Satır bağlamında değerlendirilen farklı tablolardan hesaplamalar yaparken kullanışlıdır.
• RELATEDTABLE: İlişkinin "çok" tarafından bir satır tablosu alın.
• USERELATIONSHIP: Bir hesaplamanın etkin olmayan bir ilişkiyi kullanmasına izin verir. (Teknik olarak bu işlev, kullanımını etkilemeye yardımcı olan belirli bir etkin olmayan model ilişkisinin ağırlığını değiştirir.) Modeliniz rol yapma boyut tablosu içerdiğinde ve bu tablodan etkin olmayan ilişkiler oluşturmayı seçtiğinizde kullanışlıdır. Filtre yollarındaki belirsizliği çözmek için de bu işlevi kullanabilirsiniz.
• CROSSFILTER: İlişki çapraz filtre yönünü değiştirir (bir veya her ikisine) veya filtre yayma özelliğini devre dışı bırakır (yok). Belirli bir hesaplamanın değerlendirilmesi sırasında model ilişkilerini değiştirmeniz veya yoksaymanız gerektiğinde kullanışlıdır.
• COMBINEVALUES: İki veya daha fazla metin dizesini tek bir metin dizesinde birleştirir. Bu işlevin amacı, tablolar aynı kaynak gruba ait olduğunda DirectQuery modellerinde çok sütunlu ilişkileri desteklemektir.
• TREATAS: İlişkili olmayan bir tablodaki sütunlara filtre olarak tablo ifadesinin sonucunu uygular. Belirli bir hesaplamanın değerlendirilmesi sırasında sanal ilişki oluşturmak istediğinizde, gelişmiş senaryolarda yararlıdır.
• Ebeveyn ve Çocuk işlevleri: Ebeveyn-çocuk hiyerarşisini daha anlaşılır hâle getirmek için kullanabileceğiniz hesaplanmış sütunlar oluşturan ilgili işlev ailesi. Daha sonra bu sütunları kullanarak sabit düzeyli bir hiyerarşi oluşturabilirsiniz.

İlişki değerlendirmesi

Model ilişkileri, değerlendirme açısından normal veya sınırlı olarak sınıflandırılır. Yapılandırılabilir bir ilişki özelliği değildir. Aslında kardinalite tipinden ve ilişkili iki tablonun veri kaynağından elde edilir. Performans etkileri olabileceğinden veya veri bütünlüğünün tehlikeye atılması gerektiğinde sonuçları olabileceğinden değerlendirme türünü anlamak önemlidir. Bu etkiler ve bütünlük sonuçları bu konu başlığında açıklanmıştır.

İlk olarak, ilişki değerlendirmelerini tam olarak anlamak için bazı modelleme teorileri gereklidir.

İçeri aktarma veya DirectQuery modeli tüm verilerini Vertipaq önbelleğinden veya kaynak veritabanından kaynaklar. Her iki durumda da Power BI bir ilişkinin "bir" tarafının mevcut olduğunu saptayabiliyor.

Ancak bileşik model, farklı depolama modları (içeri aktarma, DirectQuery veya ikili) veya birden çok DirectQuery kaynağı kullanan tabloları içerebilir. İçeri aktarılan verilerin Vertipaq önbelleği de dahil olmak üzere her kaynak bir kaynak grubu olarak kabul edilir. Model ilişkileri daha sonra kaynak grubu içi veya çapraz kaynak grubu olarak sınıflandırılabilir. Kaynak grubu içi ilişki bir kaynak grubu içindeki iki tabloyu ilişkilendirirken, kaynaklar arası/çapraz grup ilişkisi tabloları iki kaynak grubu arasında ilişkilendirmektedir. İçeri aktarma veya DirectQuery modellerindeki ilişkilerin her zaman kaynak grubu içinde olduğunu unutmayın.

Bileşik model örneği aşağıda verilmiştır.

Bu örnekte bileşik model iki kaynak grubundan oluşur: Vertipaq kaynak grubu ve DirectQuery kaynak grubu. Vertipaq kaynak grubu üç tablo, DirectQuery kaynak grubu ise iki tablo içerir. Vertipaq kaynak grubundaki bir tabloyu DirectQuery kaynak grubundaki bir tabloyla ilişkilendirmek için bir çapraz kaynak grubu ilişkisi vardır.

Normal ilişkiler

Sorgu altyapısı ilişkinin "bir" tarafını saptayabildiğinde model ilişkisi normaldir . "'One' adlı yan sütunun benzersiz değerler içerdiği doğrulandı." Bire çok kaynak grubu içi ilişkilerin tümü normal ilişkilerdir.

Aşağıdaki örnekte, her ikisi de R olarak işaretlenmiş iki normal ilişki vardır. İlişkiler Vertipaq kaynak grubunda yer alan bire çok ilişkisini ve DirectQuery kaynağında yer alan bire çok ilişkisini içerir.

Tüm verilerin Vertipaq önbelleğinde depolandığı içeri aktarma modelleri için Power BI, veri yenileme zamanında her normal ilişki için bir veri yapısı oluşturur. Veri yapıları, tüm sütundan sütuna değerlerin dizine alınan eşlemelerinden oluşur ve bunların amacı sorgu zamanında tabloları birleştirmeyi hızlandırmaktır.

Sorgu zamanında, normal ilişkiler tablo genişletmenin gerçekleşmesine izin verir. Tablo genişletme, temel tablonun yerel sütunlarını ekleyip ilgili tablolara genişleterek bir sanal tablo oluşturulmasına neden olur. İçeri aktarma tabloları için sorgu altyapısında tablo genişletme yapılır; DirectQuery tabloları için, kaynak veritabanına gönderilen yerel sorguda yapılır ( Bilgi tutarlılığı varsay özelliği etkinleştirilmediği sürece). Sorgu altyapısı daha sonra genişletilmiş tablo üzerinde işlem yaparak genişletilmiş tablo sütunlarındaki değerlere göre filtreler ve gruplandırma uygular.

Uyarı

Etkin olmayan ilişkiler, ilişki bir hesaplama tarafından kullanılmasa bile genişletilir. çift yönlü ilişkilerin tablo genişletmeyi hiçbir etksi yoktur.

Bire çok ilişkilerde, tablo genişletmesi LEFT OUTER JOIN semantiği kullanılarak "çok" tarafından "bir" tarafına doğru gerçekleşir. "Çok" ile "bir" tarafından eşleşen bir değer olmadığında, "bir" yan tabloya boş bir sanal satır eklenir. Bu davranış yalnızca normal ilişkiler için geçerlidir, sınırlı ilişkiler için geçerli değildir.

Tablo genişletmesi, kaynak grubu içi bire bir ilişkilerde de gerçekleşir, ancak bu, FULL OUTER JOIN semantiği kullanılarak yapılır. Bu birleştirme türü, gerektiğinde her iki tarafa da boş sanal satırların eklenmesini sağlar.

Boş sanal satırlar, etkili bir şekilde bilinmeyen üyelerdir. Bilinmeyen üyeler, "çok" yan değerinin, karşılık gelen "bir" yan değeri olmaması durumunda meydana gelen başvuru bütünlüğü ihlallerini temsil eder. İdeal olan bu boşlukların mevcut olmamasıdır. Bunlar, kaynak verileri temizleyerek veya onararak ortadan kaldırılabilir.

Tablo genişletme, animasyonlu bir örnekle şu şekilde çalışır.

Bu örnekte model üç tablodan oluşur: Kategori, Ürün ve Satış. Kategori tablosu, Bire çok ilişkisi olan Product tablosuyla, Product tablosu ise Bire çok ilişkisi olan Sales tablosuyla ilişkilidir. Kategori tablosu iki satır, Product tablosu üç satır ve Sales tabloları beş satır içerir. Tüm ilişkilerin her iki tarafında da eşleşen değerler vardır, yani bilgi tutarlılığı ihlalleri yoktur. Sorgu zamanı genişletilmiş bir tablo gösterilir. Tablo, üç tablonun da sütunlarından oluşur. Bu, üç tabloda yer alan verilerin normal olmayan bir bakış açısıdır. Sales tablosuna yeni bir satır eklenir ve Ürün tablosunda eşleşen değeri olmayan bir üretim tanımlayıcısı değeri (9) vardır. Referans bütünlüğü ihlali. Genişletilmiş tabloda, yeni satırda Kategori ve Ürün tablosu sütunları için (Boş) değerler bulunur.

Sınırlı ilişkiler

"Bir" tarafı garantili olmadığında model ilişkisi sınırlıdır . Sınırlı bir ilişki iki nedenden dolayı gerçekleşebilir:

• İlişkide çoka çok kardinalite türü kullanılır (bir veya her iki sütun da benzersiz değerler içerse bile).
• İlişki çapraz kaynak grubudur (bileşik modeller için yalnızca böyle olabilir).

Aşağıdaki örnekte, her ikisi de L olarak işaretlenmiş iki sınırlı ilişki vardır. İki ilişki Vertipaq kaynak grubunda yer alan çoka çok ilişkisini ve bire çok kaynak grubu ilişkisini içerir.

İçeri aktarma modellerinde veri yapıları hiçbir zaman sınırlı ilişkiler için oluşturulmaz. Bu durumda Power BI, sorgu zamanında tablo birleştirmelerini çözümler.

Tablo genişletme, sınırlı ilişkiler için hiçbir zaman gerçekleşmez. Tablo birleşimleri semantik kullanılarak INNER JOIN elde edilir ve bu nedenle bilgi tutarlılığı ihlallerini telafi etmek için boş sanal satırlar eklenmez.

Sınırlı ilişkilerle ilgili başka kısıtlamalar da vardır:

• RELATED DAX işlevi "bir" yan sütun değerlerini almak için kullanılamaz.
• RLS'yi zorunlu tutmanın topoloji kısıtlamaları vardır.

Tavsiye

Power BI Desktop model görünümünde, bir ilişkiyi sınırlı olarak yorumlayabilirsiniz. Sınırlı bir ilişki, kardinalite göstergelerinin ardından parantez benzeri işaretler ( ) ile gösterilir.

İlişki yolu belirsizliğini çözme

çift yönlü ilişkiler, model tabloları arasında birden çok ve bu nedenle belirsiz filtre yayma yolları oluşturabilir. Belirsizliği değerlendirirken Power BI, filtre yayma yolunu önceliğine ve ağırlığına göre seçer.

Öncelik

Öncelik katmanları, Power BI'ın ilişki yolu belirsizliğini çözmek için kullandığı bir kural dizisi tanımlar. İlk kural eşleşmesi, Power BI'ın izleyeceği yolu belirler. Aşağıdaki her kural, filtrelerin kaynak tablodan hedef tabloya nasıl aktığını açıklar.

1. Çoktan çoğa ilişkilerden oluşan bir yol.
2. Bire-çok veya çoğa-çok ilişkilerinden oluşan bir yol.
3. Çoktan bire ilişkilerden oluşan bir yol.
4. Kaynak tablodan ara tabloya bire-çok ilişkilerden oluşan bir yol ve ardından ara tablodan hedef tabloya çoka-bir ilişkiler.
5. Kaynak tablodan ara tabloya bire çok ya da çoka çok ilişkiler içeren ve ara tablodan hedef tabloya çoka bir ya da çoka çok ilişkilerle devam eden bir yol.
6. Başka bir yol.

Bir ilişki tüm kullanılabilir yollara dahil edildiğinde, tüm yollardan düşünülmeden kaldırılır.

Ağırlık

Bir yoldaki her ilişkinin bir ağırlığı vardır. Varsayılan olarak, USERELATIONSHIP işlevi kullanılmadığı sürece her ilişki ağırlığı eşittir. Yol ağırlığı, yol boyunca yer alan tüm ilişki ağırlıklarının üst sınırıdır. Power BI, aynı öncelik katmanındaki birden çok yol arasındaki belirsizliği çözmek için yol ağırlıklarını kullanır. Daha düşük önceliğe sahip bir yol seçmez, ancak daha yüksek ağırlığa sahip yolu seçer. Yoldaki ilişkilerin sayısı ağırlığı etkilemez.

USERELATIONSHIP işlevini kullanarak bir ilişkinin ağırlığını etkileyebilirsiniz. Ağırlık, en içteki çağrının en yüksek ağırlığı aldığı bu işlev çağrısının hiyerarşisine göre belirlenir.

Aşağıdaki örneği göz önünde bulundurun. Product Sales ölçüsü Sales[ProductID] ile Product[ProductID] arasındaki ilişkiye daha yüksek bir ağırlık atar ve ardından Inventory[ProductID] ile Product[ProductID] arasındaki ilişkiyi izler.

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Uyarı

Power BI aynı önceliğe ve aynı ağırlığa sahip birden çok yol algılarsa, belirsiz bir yol hatası döndürür. Bu durumda, USERELATIONSHIP işlevini kullanarak veya model ilişkilerini kaldırarak veya değiştirerek ilişki ağırlıklarını etkileyerek belirsizliği çözmeniz gerekir.

Performans tercihi

En hızlıdan en yavaş performansa kadar aşağıdaki liste filtreleme yayılımı performansını sıralar:

1. Kaynak grubu içindeki bire birden çoğa ilişkiler
2. Aracı bir tabloyla elde edilen ve en az bir çift yönlü ilişki içeren çoka çok model ilişkileri
3. Çoka çok kardinalite ilişkileri
4. Kaynaklar arası grup ilişkileri

İlgili içerik

Bu makale hakkında daha fazla bilgi için aşağıdaki kaynaklara göz atın:

• Yıldız şemasını ve Power BI önemini anlama
• Bire bir ilişki kılavuzu
• Çoka çok ilişki kılavuzu
• Etkin ve etkin olmayan ilişki kılavuzu
• çift yönlü ilişki kılavuzu
• İlişki sorunlarını giderme kılavuzu
• Video: Power BI İlişkilerinde Yapılması ve Yapılmaması Gerekenler
• Sorularınız var mı? Power BI Topluluğu'na sormayı deneyin
• Öneri? Power BI'ı geliştirmek için fikirlere katkıda bulunma