Power BI Desktop’ta model ilişkileri

Bu makale, Power BI Desktop'ta içeri aktarılan veri modelleyicilerine yöneliktir. Kullanımı kolay, doğru ve en uygun modeller sunmak için temel bilgiler veren, önemli bir model tasarımı konu başlığıdır.

Tablo rolleri ve ilişkileri dahil olmak üzere en uygun model tasarımı hakkında ayrıntılı bilgi için Yıldız şemasını ve Power BI açısından önemini anlama makalesini inceleyin.

İlişkinin amacı

Basitçe ifade etmek gerekirse Power BI ilişkileri, model tablolarının sütunlarına uygulanmış olan filtrelerin diğer model tablolarına da yayılmasını sağlar. Filtreler, izlenecek bir ilişki yolu olduğu sürece yayılmaya devam eder ve bu sayede birden fazla tabloya yayılabilir.

İlişki yolları belirlenimcidir ve bu nedenle filtreler her zaman aynı şekilde yayılır, rastgele değişime uğramaz. Ancak ilişkiler devre dışı bırakılabilir veya belirli DAX işlevlerini kullanan model hesaplamaları tarafından değiştirilen filtre bağlamına sahip olabilir. Daha fazla bilgi için bu makalenin ilerleyen bölümlerinde yer alan İlgili DAX işlevleri konu başlığına bakın.

Şimdi ilişkilerin filtreleri nasıl yaydığını animasyonlu bir örnekte görelim.

Bu örnekte model dört tablodan oluşmaktadır: Kategori, Ürün, Yıl ve Satış. Kategori tablosu Ürün tablosuyla, Ürün tablosu da Satış tablosuyla ilişkilendirilmiştir. Yıl tablosu da Satış tablosuyla ilişkilendirilmiştir. Tüm ilişkiler bir-çok türündedir (bu türle ilgili ayrıntılar bu makalenin ilerleyen bölümlerinde açıklanmaktadır).

Büyük olasılıkla Power BI kart görseli gibi bir kaynak tarafından oluşturulan bir sorgu, tek bir kategoriye (Kat-A) ve tek bir yıla CY2018 ait olan toplam satış miktarıyla ilgili bilgileri istemektedir. Bu nedenle Kategori ve Yıl tablolarına filtre uygulanmıştır. Kategori tablosundaki filtre Ürün tablosuna yayılarak Kat-A kategorisine atanmış olan iki ürünü yalıtmaktadır. Ardından Ürün tablosu filtreleri Satış tablosuna yayılarak bu ürünler için yalnızca iki satış satırını yalıtmaktadır. Bu iki satış satırı, Kat-A kategorisine atanmış olan ürünlerin satışlarını temsil etmektedir. Toplam miktar 14 birimdir. Ayrıca Yıl tablosunun filtresi, Satış tablosunu da filtreleyerek Kat-A kategorisine atanmış ve CY2018 yılında sipariş edilmiş olan ürünlere ait tek bir satış satırı sunmaktadır. Sorgu tarafından döndürülen miktar değeri 11 birimdir. Bir tabloya birden fazla filtre uygulandığında (bu örnekteki Satış tablosu gibi) her zaman AND işlemi gerçekleştirilir ve tüm koşulların doğru olması gerekir.

Bağlantısı olmayan tablolar

Bir model tablosunun başka bir model tablosuna bağlı olmaması sık görülen bir durum değildir. Geçerli bir model tasarımında bu tür tablolar, bağlantısı olmayan tablo olarak açıklanabilir. Bağlantısı olmayan tablo, diğer model tablolarına filtre yayma amacıyla kullanılmaz. Bunun yerine "kullanıcı girişini" kabul etmek (muhtemelen bir dilimleyici görseliyle) ve model hesaplamalarının giriş değerini anlamlı bir şekilde kullanmasını sağlamak için kullanılır. Örneğin döviz kuru değerlerinden oluşan bir aralığa sahip olan, bağlantısı olmayan bir tablo düşünün. Tek kur değerine göre filtrelemek için bir filtre uygulandığı sürece ilgili değer bir ölçüm ifadesi tarafından satış değerine dönüştürme amacıyla kullanılabilir.

Power BI Desktop durum parametresi, bağlantısı olmayan tablo oluşturan bir özelliktir. Daha fazla bilgi için Power BI Desktop'ta değişkenleri görselleştirmek için durum parametresi oluşturma ve kullanma makalesine bakın.

İlişki özellikleri

Model ilişkisi, bir tablo içindeki sütunlardan biriyle farklı bir tablonun sütunlarından biri arasında ilişki oluşturur. (Bu gereksinimin geçerli olmadığı özel bir durum vardır ve bu yalnızca DirectQuery modellerindeki çoklu sütun ilişkileri için geçerlidir. Daha fazla bilgi için COMBINEVALUES DAX işlevi makalesine bakın.)

Kardinalite

Her model ilişkisiyle birlikte bir kardinalite türü tanımlanması gerekir. "Kaynak" ve "hedef" ilişkili sütunların veri özelliklerini temsil eden dört farklı 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.

Dört seçenek ve kısaltılmış ifadeleri aşağıdaki madde işaretli listede açıklanmıştır:

• Bir-çok (1:*)
• Çok-bir (*:1)
• Bir-bir (1:1)
• Çok-çok (*:*)

Power BI Desktop'ta ilişki oluşturduğunuzda tasarımcı kardinalite türünü otomatik olarak algılayacak ve ayarlayacaktır. Tasarımcı modeli sorgulayarak benzersiz değerlerin bulunduğu sütunları öğrenir. İçeri Aktarma modelleri için iç depolama istatistiklerini kullanır, DirectQuery modelleri için de veri kaynağına profil oluşturma sorgusu gönderir. Ancak yanıldığı durumlar da olabilir. Bunun nedeni tablolara henüz veri yüklenmemiş olması veya yinelenen değer içermesini beklediğiniz sütunların o an için benzersiz değerler içeriyor olmasıdır. Her iki durumda da "bir" tarafındaki sütunlarda benzersiz değerler bulunduğu (veya tabloya henüz veri satırları yüklenmediği) sürece kardinalite türünü güncelleştirebilirsiniz.

Bir-çok ve Çok-çok kardinalite seçenekleri temelde aynıdır ve aynı zamanda en yaygın kullanılan kardinalite türleridir.

Bir-çok veya Çok-çok ilişki yapılandırırken sütunlara arasında ilişki kurduğunuz sıralamayla eşleşeni seçmeniz gerekir. Ürün tablosu ile Satış tablosu arasında ilişki kurmak için her birinde bulunan Ürün Kimliği sütununu nasıl yapılandıracağınızı düşünün. Ürün tablosundaki Ürün Kimliği sütunu benzersiz değerler içerdiğinden Bir-çok kardinalite türü kullanılır. Tablolar arasındaki ilişkiyi ters yönde kuracak olursanız (Satış tablosundan Ürün tablosuna), kardinalite türü Çok-bir olur.

Bir-bir ilişkisi her zaman iki sütunda da benzersiz değerler olduğu anlamına gelir. Bu kardinalite türü yaygın kullanılmaz ve genellikle gereksiz verilerin depolanması nedeniyle uygun olmayan bir tasarım ortaya çıkarır. Bu kardinalite türünü kullanma hakkında daha fazla bilgi için bkz. Birebir ilişki kılavuzu.

Çok-çok ilişkisi, iki sütunda da yinelenen değer olabileceği anlamına gelir. Bu kardinalite türü oldukça seyrek kullanılır. Bu tür özellikle karmaşık model gereksinimlerini tasarlarken yararlı olur. Bu kardinalite türünü kullanma yönergeleri için bkz. Çoka çok ilişkiler kılavuzu.

Çapraz filtre yönü

Her model ilişkisiyle birlikte bir çapraz filtre yönü tanımlanması gerekir. Yapacağınız seçim, filtrelerin yayılma yönünü belirler. Çapraz filtre seçenekleri, kardinalite türüne göre değişir.

Tek çapraz filtre yönü "tek yön", Her İkisi ise "iki yön birden" anlamına gelir. İki yönde filtre uygulanan bir ilişki genellikle iki yönlü olarak tanımlanır.

Bir-çok ilişkilerde çapraz filtre yönü her zaman "bir" tarafındandır ve isteğe bağlı olarak "çok" tarafına da eklenebilir (iki yönlü). Bir-bir ilişkilerde çapraz filtre yönü her zaman iki tablodan birden olur. Son olarak Çok-çok ilişkilerde çapraz filtre yönü tabloların birinden veya ikisinden birden olabilir. Kardinalite türü "bir" tarafı içerdiğinde filtreler her zaman o taraftan yayılacaktır.

Çapraz filtre yönü Her İkisi olarak ayarlandığı sürece ek özellik kullanılabilir. Satır düzeyi güvenlik (RLS) kuralları zorunlu tutulduğunda çift yönlü filtreleme uygulayabilir. RLS hakkında daha fazla bilgi için Power BI Desktop ile satır düzeyi güvenlik (RLS) makalesine bakın.

Çapraz filtrenin yönünün değiştirilmesi (filtrenin yayılmasını devre dışı bırakma dahil) işlemi bir model hesaplamasıyla da yapılabilir. Bunun için CROSSFILTER DAX işlevi kullanılır.

İki yönlü ilişkiler, performansı olumsuz etkileyebilir. Ayrıca iki yönlü ilişki yapılandırma girişimi sonucunda belirsiz filtre yayma yolları elde edilebilir. Bu durumda Power BI Desktop, ilişki değişikliğini gerçekleştiremeyebilir ve sizi bir hata iletisiyle uyarır. Ancak Power BI Desktop bazen tablolar arasında belirsiz ilişki yolları tanımlamanıza izin verebilir. Belirsizlik algılama ve yol çözümlemesini etkileyen öncelik kuralları, bu makalenin ilerleyen bölümlerindeki Öncelik kuralları konu başlığında açıklanmaktadır.

İki yönlü filtrelemeyi yalnızca ihtiyaç duyulması halinde kullanmanız önerilir. Daha fazla bilgi için bkz. Çift yönlü ilişki kılavuzu.

Bu ilişkiyi etkinleştir

İki model tablosu arasında yalnızca bir etkin filtre yayma yolu olabilir. Ek ilişki yolu ekleyebilirsiniz ancak bu ilişkilerin devre dışı olarak yapılandırılması gerekir. Etkin olmayan ilişkiler yalnızca model hesaplama sırasında etkin hale getirilebilir. Bunun için USERELATIONSHIP DAX işlevi kullanılır.

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

Bilgi tutarlılığı varsay

Bilgi tutarlılığı varsay özelliği yalnızca aynı veri kaynağını temel alan iki DirectQuery depolama modu tablosu arasındaki Bir-çok ve Bir-bir ilişkileri için kullanılabilir. Bu özellik etkinleştirildiğinde, veri kaynağına gönderilen yerel sorgular iki tabloyu OUTER JOIN yerine INNER JOIN kullanarak birleştirir. Bu özelliğin etkinleştirilmesi genellikle sorgu performansını iyileştirse de bu durum veri kaynağına göre değişir.

İki tablo arasında veritabanı yabancı anahtar kısıtlaması mevcut olduğunda bu özelliği mutlaka etkinleştirin. Yabancı anahtar kısıtlaması olmasa da veri bütünlüğünün mevcut olduğundan emin olduğunuz sürece bu özelliği etkinleştirebilirsiniz.

İlgili DAX işlevleri

Model ilişkileriyle ilgili olan birçok DAX işlevi vardır. Bu işlevler aşağıdaki madde işaretli listede kısaca açıklanmıştır:

• RELATED: "Bir" tarafındaki değeri alır.
• RELATEDTABLE: "Çok" tarafından bir satır tablosu alır.
• USERELATIONSHIP: Belirli bir devre dışı model ilişkisinin kullanılmasını zorunlu kılar.
• CROSSFILTER: İlişkinin çapraz filtre yönünü (bir veya iki yönlü) değiştirir veya filtrenin yayılmasını devre dışı bırakır (yok).
• COMBINEVALUES: İki veya daha fazla metin dizesini tek bir metin dizesinde birleştirir. Bu işlevin amacı, DirectQuery modellerindeki çok sütunlu ilişkileri desteklemektir.
• TREATAS: Bir tablo ifadesinin sonucunu, ilişkili olmayan bir tablodaki sütunlara filtre olarak uygular.
• Üst ve Alt işlevler: Bir üst-alt hiyerarşisini doğal hale getirme amacıyla hesaplanmış sütunlar oluşturmak için kullanılabilecek ilgili işlevlerden oluşan kümedir. Daha sonra bu sütunlar, sabit düzey hiyerarşi oluşturmak için kullanılabilir.

İ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 ilişki özelliği değildir. Aslında aralarında ilişki bulunan iki tablonun kardinalite türünden ve veri kaynağından oluşur. Veri bütünlüğünün tehlikeye girmesi durumunda performans açısından belirli etkileri veya sonuçları olabileceğinden değerlendirme türünü anlamak önemlidir. Bu konu başlığında bu etkiler ve bütünlük açısından sonuçlar açıklanmaktadır.

Öncelikle ilişki değerlendirmelerini anlamak için modelleme konusunda bazı teorik bilgilerin dikkate alınması gerekir.

İçeri aktarma veya DirectQuery model kaynakları, tüm verilerini Vertipaq önbelleğinden veya kaynak veritabanından alır. Her iki örnekte de Power BI, ilişkinin "bir" tarafının mevcut olduğunu tespit edebilir.

Ancak bir Bileşik model, farklı depolama modları (İçeri aktarma, DirectQuery veya İkili) veya DirectQuery kaynakları kullanan tablolardan oluşabilir. İçe aktarma verileri Vertipaq önbelleği de dahil olmak üzere her kaynağın bir kaynak grubu olduğu kabul edilir. Model ilişkileri daha sonra kaynak grubu içi ya da kaynak grupları arası olarak sınıflandırılabilir. Kaynak grubu içinde bir ilişki, bir kaynak grubundaki iki tabloyu; buna karşın kaynak grupları arasında bir ilişki, farklı kaynak gruplarından tabloları ilişkilendirir. İçeri aktarma veya DirectQuery modellerindeki ilişkilerin her zaman kaynak grubu içinde olduğunu unutmayın.

Şimdi bir Bileşik model örneğine göz atalım.

Bu örnekte, Bileşik model iki kaynak grubundan oluşmaktadır: Vertipaq kaynak grubu ve DirectQuery kaynak grubu. Vertipaq kaynak grubunda üç tablo, DirectQuery kaynak grubunda ise iki tablo bulunmaktadır. Vertipaq kaynak grubundaki bir tabloyu DirectQuery kaynak grubundaki bir tabloyla ilişkilendiren bir kaynak grupları arası ilişki mevcuttur.

Normal ilişkiler

Sorgu altyapısının ilişkinin "bir" tarafını belirleyebildiği model ilişkileri, normal ilişki olarak kabul edilir. Bu durum, "bir" taraftaki sütunun benzersiz değerler içerdiğini onaylar. Tüm kaynak grubu içi bire çoklu ilişkiler normal ilişkilerdir.

Aşağıdaki örnekte iki normal ilişki vardır ve ikisi de R harfiyle gösterilmiştir. İlişkiler, Vertipaq kaynak grubu içinde yer alan bire-çok ilişkisini ve DirectQuery kaynak grubunda yer alan bire-çok ilişkisini kapsamaktadır.

Tüm verilerin Vertipaq önbelleğinde depolandığı İçeri aktarma modellerinde, veriler yenilendiğinde her bir normal ilişki için bir veri yapısı oluşturulur. Veri yapıları, tüm sütunlar arası değerlerin dizinlenmiş eşleşmelerini içerir ve sorgu zamanında tabloların daha hızlı birleştirilmesini sağlamak için kullanılır.

Normal ilişkiler, sorgu zamanında tablonun genişletilmesini sağlar. Tablo genişletme işleminin sonucunda temel tablonun yerel sütunları alınıp ilişkili tablolarla genişletilerek bir sanal tablo oluşturulur. İçeri aktarma tablolarında bu işlem sorgu altyapısında, DirectQuery tablolarında ise kaynak veritabanına gönderilen yerel sorguda gerçekleştirilir (Bilgi tutarlılığı varsay özelliğinin etkinleştirilmemiş olması koşuluyla). Ardından sorgu altyapısı genişletilen tabloya göre işlem yapar ve bu tablonun sütunlarında filtre uygulama ve gruplama işlemlerini gerçekleştirir.

Bire çok ilişkilerde tablo genişletme işlemi, LEFT OUTER JOIN semantiği kullanılarak "çok" tarafından "bir" tarafına doğru gerçekleştirilir. "Çok" tarafından "bir" tarafına eşleşen bir değer yoksa "bir" tarafındaki tabloya boş bir sanal satır eklenir.

Tablo genişletmesi ayrıca bire-bir grup içi ilişkilerde de oluşur, ancak bu yalnızca FULL OUTER JOIN semantiği kullanıldığında söz konusudur. Bu işlem, gerekli olduğunda bir tarafa boş sanal satırların eklenmesini sağlar.

Boş sanal satırlar, Bilinmeyen Üyeler olarak adlandırılır. Bilinmeyen üyeler, "çok" tarafındaki değere "bir" tarafında karşılık gelen bir değerin bulunmadığı bilgi tutarlılığı ihlallerini temsil eder. İdeal bir ortamda boş satır bulunmaması gerekir ve bu satırlar kaynak verilerin temizlenmesi veya onarılmasıyla ortadan kaldırılabilir.

Tablo genişletme işleminin nasıl çalıştığını animasyonlu bir örnekle inceleyelim.

Bu örnekte model üç tablodan oluşmaktadır: Kategori, Ürün ve Satış. Kategori tablosu ile Ürün tablosu arasında Bir-çok ilişkisi, Ürün tablosu ile de Satış tablosu arasında Bir-çok ilişkisi vardır. Kategori tablosunda iki satır, Ürün tablosunda üç satır, Satış tablosunda ise beş satır vardır. Tüm ilişkilerin iki tarafında da eşleşen değerler vardır ve bu nedenle bilgi tutarlılığı ihlali mevcut değildir. Sorgu zamanında oluşturulan bir genişletilmiş tablo gösterilmektedir. Bu tablo, üç ayrı tablodan alınan tüm sütunları içermektedir. Bu tablo, üç tabloda yer alan verilerin normalleştirilmişlikten çıkarılmış bir perspektifini sunmaktadır. Satış tablosuna yeni bir satır eklenmiştir ve bu satırda Ürün tablosunda karşılığı bulunmayan üretim tanımlayıcısı değeri (9) mevcuttur. Bu bir bilgi tutarlılığı ihlalidir. Genişletilmiş tablodaki yeni satır (Boş), Kategori ve Ürün tablosundaki sütunların değerlerini içermektedir.

Sınırlı ilişkiler

"Bir" taraf garantisi bulunmayan model ilişkileri, sınırlı ilişki olarak kabul edilir. Bu durumun iki farklı nedeni olabilir:

• İlişki Çok-çok kardinalite türünü kullanmaktadır (sütunların biri veya her ikisi benzersiz değer içeriyor olsa da)
• İlişki kaynak grupları arasındadır (bu durumda yalnızca Bileşik modellerde görülebilir)

Aşağıdaki örnekte iki sınırlı ilişki vardır ve ikisi de L harfiyle gösterilmiştir. İki ilişki, Vertipaq kaynak grubunda yer alan çoktan-çoğa ilişkisi ile kaynak grupları arasındaki birden-çoğa ilişkiyi kapsamaktadır.

İçeri aktarma modellerinde sınırlı ilişkiler için veri yapısı oluşturulmaz. Bu da tablo birleşimlerinin sorgu zamanında çözümlenmesi gerektiği anlamına gelir.

Sınırlı ilişkiler için tablo genişletme işlemi gerçekleştirilmez. Tablo birleşimleri, INNER JOIN semantiği kullanılarak elde edilir ve bu nedenle bilgi tutarlılığı ihlallerini telafi etmek için boş sanal satırlar eklenmez.

Sınırlı ilişkilerle ilgili ek kısıtlamalar da mevcuttur:

• RELATED DAX işlevi, "bir" taraftaki sütun değerlerini alma amacıyla kullanılamaz
• RLS'nin zorunlu kılınması, bazı topoloji kısıtlamalarını da beraberinde getirir

Öncellik kuralları

İki yönlü ilişkiler, model tabloları arasında birden fazla (ve belirsiz) filtre yayma yolu oluşturabilir. Aşağıdaki listede Power BI'ın belirsizlik algılama ve yol çözümleme amacıyla kullandığı öncelik kuralları verilmiştir:

1. Sınırlı ilişkiler dahil olmak üzere Çok-bir ve Bir-bir ilişkileri
2. Çok-çok ilişkileri
3. Ters yöndeki iki yönlü ilişkiler ("Çok" tarafından)

Performans tercihi

Aşağıdaki listede en hızlıdan en yavaşa doğru olmak üzere filtre yayma performansları listelenmiştir:

1. Birden-çoğa kaynak grubu içi ilişkiler
2. Ara tablo ile elde edilen ve en az bir iki yönlü ilişki içeren çok-çok model ilişkileri
3. Çok-çok kardinalite ilişkileri
4. Kaynak grupları arası ilişkiler

Sonraki adımlar

Bu makale hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın:

• Yıldız şemasını ve Power BI açısından önemini anlama
• Birebir ilişki kılavuzu
• Çoka çok ilişkiler kılavuzu
• Etkin ve etkin olmayan ilişki karşılaştırması 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 mı var? Power BI Topluluğu'na sorun
• Önerileriniz mi var? Power BI'ı geliştirmek için fikirlerinizi paylaşın