Sipariş ve Teslim Tarihi Aynı Takvimde: USERELATIONSHIP ile Pasif İlişki Kullanımı

Tek takvim, çok tarih: sorun nerede başlıyor

Bir sipariş tablosunda genellikle birden çok tarih sütunu vardır: sipariş tarihi, sevk tarihi, teslim tarihi, fatura tarihi. Hepsini aynı takvim tablosuna bağlamak isteyebilirsiniz; çünkü takvimdeki yıl, ay ve hafta sütunlarının hepsine aynı dilimleyiciyle ulaşmak istersiniz.

Ancak Power BI'da raporda süzgeç taşıyan ilişki etkin ilişkidir. Takvim ile sipariş tablosu arasında sipariş tarihi etkin olarak bağlıysa, bir ay dilimleyicisi seçtiğinizde hesaplanan her toplam o ayda verilen siparişlerdir. "Bu ay teslim edilen siparişlerin tutarı" sorusu ise başka bir ilişkiye ihtiyaç duyar.

Çözüm yolları arasında ayrı bir takvim kopyası kurmak ya da USERELATIONSHIP ile aynı takvimi farklı bir tarihe geçici olarak bağlamak vardır. Bu sayfa USERELATIONSHIP yolunu anlatır: model sade kalır, tek takvim tablosu üzerinden çalışılır, hangi tarihe göre hesaplandığı ise ölçünün adında ve formülünde görünür.

USERELATIONSHIP ne yapar, nasıl yazılır

Fonksiyonun söz dizimi sütun adlarından oluşur: USERELATIONSHIP ( sütunA, sütunB ). Microsoft belgesine göre bu sütunlar, kullanılacak ilişkinin uçlarıdır. Genellikle sütunA ilişkinin çok tarafını (olgu tablosundaki tarih), sütunB ise bir tarafını (takvimdeki tarih) gösterir; ters sırada verilirseniz fonksiyon sırayı kendi düzeltir. Argümanlar bir ifade olamaz, tam nitelikli sütun adı olmalıdır.

Fonksiyon bir değer döndürmez. Yalnızca belirtilen ilişkiyi, içinde bulunduğu hesaplama süresince etkinleştirir. Belge, ilişkinin etkin olup olmamasının önemli olmadığını da vurgular: etkin olmayan bir ilişki bile kullanılır ve aynı tablolar arasında hesapta adı geçmeyen etkin ilişkinin yerine geçer.

Fonksiyon tek başına yazılmaz; bir süzgeç argümanı alan fonksiyonun içinde durur. En yaygın yeri CALCULATE'tir. Aşağıdaki şema, bir ölçünün farklı ilişkilerle nasıl çalıştığını özetler.

Adım adım: teslim tarihine göre ölçü yazmak

Kurgusal bir sipariş modeli düşünün: Sipariş tablosunda Sipariş Tarihi ve Teslim Tarihi sütunları, ayrı bir Takvim tablosu var. Takvim'in Tarih sütunu tüm tarih sütunlarıyla ilişkilenmiş; sipariş tarihi ilişkisi etkin, teslim tarihi ilişkisi etkin olmayan olarak tanımlı.

Uygulama sırası şöyle işler: • Temel ölçüyü yazın: Toplam Tutar = SUM ( Sipariş[Tutar] ). Bu ölçü, takvim dilimleyicisine sipariş tarihi üzerinden tepki verir. • Teslim tarihli ölçüyü ekleyin: Teslim Edilen Tutar = CALCULATE ( [Toplam Tutar], USERELATIONSHIP ( Sipariş[Teslim Tarihi], Takvim[Tarih] ) ). • Bir matrise Takvim'den ay sütununu, değerlere her ölçüyü yerleştirin. • Aynı satırda "ay içinde alınan" ve "ay içinde teslim edilen" tutarlar yan yana görünür; aradaki fark, teslimat gecikmesini ya da aylar arası taşmayı gösterir.

Bu örnek Microsoft belgesindeki mantığın aynısıdır: belgede etkin ilişki sipariş tarihi, devreye alınan etkin olmayan ilişki sevk tarihidir ve ölçü adı hangi tarihe göre hesaplandığını söyler. Ölçü adına "teslim tarihine göre" ya da benzeri bir ifade eklemek, rapor okuyucusunun ölçüleri karıştırmasını önler.

Birden çok ilişki, iç içe CALCULATE ve diğer filtre değiştiriciler

Bir hesapta takvim ile olgu tablosunu bağlayan birden çok ilişki gerekiyorsa, her biri ayrı bir USERELATIONSHIP çağrısıyla belirtilmelidir. Aynı iç içe CALCULATE yapısında birden çok USERELATIONSHIP çatışırsa, en içteki geçerli olur.

CALCULATE belgesi USERELATIONSHIP'i bir süzgeç değiştirici olarak listeler. Etkin olmayan ilişkiyi devreye aldığınızda, aynı sütunlar arasındaki etkin ilişki otomatik olarak etkin olmaz. Aynı listede ALL, REMOVEFILTERS, KEEPFILTERS ve CROSSFILTER gibi fonksiyonlar da vardır; bunlarla birleştirmek mümkündür. Örneğin USERELATIONSHIP ile teslim tarihine geçip aynı CALCULATE içinde başka bir boyuttaki süzgeci kaldırabilirsiniz.

Bir sınır daha: bire bir ilişkilerde fonksiyon ilişkiyi yalnız tek yönde etkinleştirir. Çift yönlü süzgeç gerekiyorsa, aynı hesapta ters yönlü USERELATIONSHIP çağrıları birlikte yazılır. Bu ayrıntı çoğu rapor için gerekmez, ancak ilişki kuralları karışık modellerde sürpriz hatanın kaynağı olabilir.

Kısıtlar ve tipik hata mesajları

Fonksiyonun bilinen kısıtları şunlardır: • Yalnız süzgeç alan fonksiyonlarda çalışır: CALCULATE, CALCULATETABLE ve dönem başı/sonu bakiye ile dönem başından bugüne toplam fonksiyonları gibi. • Ölçünün bulunduğu tabloda satır düzeyi güvenlik tanımlıysa kullanılamaz; belgede, güvenlik tanımlı tabloya ilişkili örnek formülün hata vereceği belirtilir. • Argümanlardan biri hiçbir ilişkinin parçası değilse ya da sütunlar farklı ilişkilere aitse hata döner. • İlişki modelde hiç yoksa fonksiyon bir ilişki yaratmaz; önce ilişkiyi modelde tanımlamanız gerekir.

Sorun giderirken önce sütunların gerçekten bir ilişkinin uçları olup olmadığına bakın, sonra o ilişkinin başka bir etkin ilişkiyle çakışıp çakışmadığını kontrol edin. Hata yoksa ama sayılar beklenenden farklıysa, ölçünün beklediğiniz ilişkiyi mi kullandığını anlamak için sipariş ve teslim tarihi örneğinde bilinen bir ay seçip elle toplamla karşılaştırın.

Satır düzeyi güvenlik kullanıyorsanız, bu kısıt modelleme kararını etkiler; güvenlik kurallarını ve ilişkileri birlikte tasarlamak gerekir.

USERELATIONSHIP mi, ayrı takvim kopyası mı

Her çoklu tarih sorusu USERELATIONSHIP gerektirmez. Sipariş ve teslim olaylarını aynı grafikte ayrı tarih alanları olarak göstermeniz gerekiyorsa tek takvim tablosu yetmeyebilir; çünkü eksen tek bir tarih alanına bağlıdır. Böyle bir görselde sipariş ve teslim için ayrı takvim kopyaları (ayrı tarih tabloları) düşünülebilir.

USERELATIONSHIP, aksine, aynı takvim ekseninde farklı ölçüler gösterecekseniz idealdir: eksen ay, değerler ise "alınan" ve "teslim edilen" tutarlardır. Model tek takvimle sade kalır ve zaman zekası fonksiyonları tek bir tarih tablosuna dayanır.

Karar verirken sorun şudur: farklı tarihleri ayrı eksenlerde mi karşılaştırıyorum, yoksa aynı eksende farklı ölçüler mi gösteriyorum? İlk durumda ayrı takvim, diğerinde USERELATIONSHIP daha rahat çalışır. Kalıbı seçtikten sonra ölçü adlandırmasını tüm raporda tutarlı tutmak, bakım maliyetini düşürür.

Bu beceriyi Mindset programlarında nerede çalışırsınız

Power BI İleri Düzey ve DAX programı, "CALCULATE ve Filtre Bağlamında Ustalaşmak" ve "Zaman Zekası ve Dönem Analizi" başlıklarıyla USERELATIONSHIP'in doğal bağlamını kapsar: ilişkiler, filtre bağlamı ve dönem karşılaştırması bir arada çalışılır. Sipariş, lojistik ve satış operasyonları ekiplerinde teslim tarihine göre raporlama sık görülen bir ihtiyaçtır.

Uygulamalı Power BI ile Veri Analitiği ve Görselleştirme Sertifika Programı'ndaki "Veri Modelleme ve Yönetimi" başlığı ise ilişki kurulumunu temelden ele alır.