Bir modelde çoklu tarih sütunu olması ne demek önce bunun tarifiyle başlayalım!
Fact tablolarının en belirgin özelliklerinden biri en az 1 tane tarih sütunu içermeleridir. Bu tarih sütunu bazen date-time şeklinde de olabilir. Önceki yazıdan hatırlatmak gerekirse, özellikle ilişki kurmak için kullandığınız bu tür date-time sütunlarını date ve time olarak iki sütuna ayırmak bir best-practice’tir. Hayatınız kolaylaşır. Fact tabloları çoğunlukla çoklu tarih sütunu içerir. Farklı rollere karşılık gelen birden fazla tarih sütunu barındırır.
Örneğin satış belgelerinin olduğu bir fact tablosuyla uğraşıyorsanız, siparişin açılış tarihi, teslim tarihi, termin tarihi gibi birden fazla tarih bilgisiyle karşılaşırız. Benzer şekilde finansal hesap hareketlerinde de transaction tarihi (yani kaydın oluştuğu tarih) ve vade tarihi gibi sütunlar bulunur.
Power BI ‘da, modelinizde kaç tane fact tablonuz olursa olsun, tek bir tarih tablosuyla çalışmak genellikle önerilen ve yönetimi daha kolay bir yöntemdir. Ama tek yöntem değildir!
Örnek Contoso modelimizde satışlar tablosunda 3 farklı tarih sütunu var: transaction tarihi, termin ve teslim tarihleri.
Fact tablosundaki tüm tarih sütunlarını, Tarih tablosundaki Tarih sütunuyla eşleştirebiliriz.
Power BI ‘daki ilişki kurallarına göre iki tablo arasında birden fazla ilişki kurulabilir, ama ilişkilerden aynı anda sadece bir tanesi aktiftir, diğerleri inaktiftir. Aksi taktirde modelde belirsizlik durumu (İngilizce jargona göre “ambiguity” ) oluşurdu.
İlk kurduğumuz ilişki aktif ilişki olur, kesintisiz düz çizgiyle gösterilir, diğer ilişkiler inaktiftir ve kesikli çizgiyle gösterilir. Metriklerimizi yazarken, CALCULATE ve USERELATIONSHIP fonksiyonları yardımıyla formüle müdahele etmediysek, bütün hesap kitap aktif ilişki üzerinden gerçekleşir.
İlk vermemiz gereken kararlardan biri, fact tablosundaki hangi tarih sütununu aktif, diğerlerini inaktif yapmakla ilgili olabilir ki bu sorunun cevabı modeli kullanacak kişilerin profiline bağlı. Eğer satış ekibindenseniz sizin için temel (aktif) tarih sütunu muhtemelen transaction tarihi olur. Siparişi almışsınızdır, sizin için de önemli olan siparişin açıldığı -yani kaydın oluştuğu- tarihtir. Eğer planlamacıysanız, muhtemelen sizin için daha önemli olan tarih termin tarihidir. Siparişin ne zaman açıldığının fazlaca bir önemi yoktur sizin için, ne zaman teslimat istendiğine göre planlarsınız her şeyi.
Hangi ilişkinin aktif hangilerinin inaktif olacağını, ilişkileri çift tıkladığınızda açılan “Edit Relationships” menüsünden ayarlayabilirsiniz.
** Ara not, başarılı analitik projeler için iş süreç bilgisi, hangi konunun ne şekilde ölçülmesi gerektiği kritik bir konudur. Siparişin açıldığı tarihten teslimine kadar kaç gün geçtiği, siparişin ne kadarının hatasız teslim edildiği önemli KPI’lardan biridir birçok sektörde. OTIF ( On Time In Full ), DIFOT ( Delivery In Full On Time) gibi farklı isimleri olur bazen, ama hedef bellidir, açılan tüm siparişleri belli bir alt-üst limiti olan zaman aralığında teslim etmeniz beklenir. Bu aralığa düşen teslimatlar/siparişler 100 puan alır, dışına düşenler ne kadar dışına düştüğüne göre daha yüksek/düşük puanlanır. Sektörünüzün/şirketinizin ne olduğuna göre bu KPI’ı düzgün yönetmek için bazen “stok yönetimi” sistemi kurmanız gerekir, bazen de “termin yönetimi”.
Basit satışlar metriğimizi ekleyelim.
Satışlar = SUMX( 'Satışlar' ,'Satışlar'[Fiyat] * 'Satışlar'[Miktar] )
Yazdığımız tüm metrikler, eğer USERELATIONSHIP ile modifiye etmezsek aktif ilişkideki Tarih sütunu üzerinden çalışacak. Eğer satışları termin veya teslim tarihlerine göre hesaplamak istiyorsak aşağıdaki şekilde modifiye etmemiz gerekir.
Satışlar Termine Göre =
CALCULATE(
[Satışlar] ,
USERELATIONSHIP( 'Tarih'[Tarih] , 'Satışlar'[Termin Tarihi] )
)
Satışlar Teslime Göre =
CALCULATE(
[Satışlar] ,
USERELATIONSHIP( 'Tarih'[Tarih] , 'Satışlar'[Teslim Tarihi] )
)
Hangi sütunu ilk sırada yazdığımızın bir önemi yok, yeter ki iki ilişki sütunu da formülde geçsin.
** DAX ‘a yeni başlayanlar için not: Yukarıdaki teslim/termine göre metriklerinde, [Satışlar] metriğini çağırmak yerine bu metriğin açık formülünü de yazabilirdik. Eğer CALCULATE bir row context altında çalışmıyorsa, yani context transition‘a sebep olacak bir durum yoksa metriği çağırmakla metriğin açık formülünü yazmak arasında bir fark yok. Ve her seferinde formülleri sıfırdan tekrar yazmak yerine temel metriği çağırıp CALCULATE ile varyasyonlarını yazmak iyi-pratik örneği.
Bu yöntemin, yani tek bir tarih tablosu kullanmanın avantajları ne? Model daha yönetilebilir, daha az karmaşık! Artı, en önemli avantajı özellikle eksenli görsellerde (line chart gibi) tek bir ortak zaman ekseni üzerinde tüm metrikleri görebiliriz!
Dezavantajı ise -tabii dezavantaj diyeceksek buna- her bir tarih “rolü” için bir metrik yazmak gerekiyor. Her bir tarih için 3 farklı satış metriği yazdık, bunların bir de time intelligence gibi başka varyasyonlarını düşünecek olursak yazmamız gereken metrik sayısı biraz daha fazla olacaktır. Time Intelligence grubu için calculation groups kullanmakta fayda var bu tür durumlarda.
…
Peki ya aşağıdaki gibi bir matris yaratmak istiyorsak?
Eğer planlamacıysanız ya da lojistik departmanındaysanız yukarıdaki matrisin verdiği bilgi kıymetli : Ocak’ta açılan siparişlerin 618K’lık kısmı Ocak’ta teslim edilecek, 217K’lık kısmı ise Şubat’ta teslim edilecek! Ve bu matrisi oluşturmak için sadece ve sadece ilk yazdığımız basit satışlar metriğini kullanabiliriz!
Eğer modelimizin kurgusunu aşağıdaki gibi değiştirirsek!
Tek bir tarih tablosu kullanıyor olsaydık yukarıdaki matrisi elde etmek çok kolay olmazdı, ya tek tek tüm termin ayları için metrik yazardık, ya da disconnected table ile gene DAX tarafında takla atmamız gerekirdi. Ama her bir tarih rolü için ayrı bir tarih tablosu yaratıp satışlar tablosuyla ilişkilendirdiğimizde bu matrisi yaratmak son derece basit!
Bu modellemenin dezavantajı ise tek bir ortak zaman ekseninde tüm bilgileri görmek daha zor! Eksenli görsellerde 2 eksen var, bazılarında secondary X axis’i de sayarsak 3, ama tek tarih tablosu kullandığımız model üzerinden elde ettiğimiz grafik kadar anlaşılır olmazdı hiç biri.
Fakat, her bir rol için ayrı ayrı metrikler yazmaktan da kurtulduk bir taraftan! Bir tane satış metriğini dileğimiz tarih tipine göre gösterebiliyoruz.
Her bir tarih rolü için yarattığımız tablolardaki isimlendirmeye de dikkat etmekte fayda var, aksi taktirde raporları oluşturmak/okumak kafa karıştırıcı olabilir. Ocak ayı tüm tarih tablolarında Ocak diye geçerse, veya yıl, hangisinin hangi tarih tablosundan geldiğini nasıl anlayacağız? Bu yüzden Ocak, Ocak Termin, Ocak Teslim gibi isimlendirme farklılığı yaratmanızı şiddetle tavsiye ederim.
Tabii her iki yöntemi hibrid olarak aynı modelde kullanmayı da secebilirsiniz!
Eğer farklı rollere ait tarihleri bu şekilde ayrı ayrı tablolar olarak modele almayı tercih ettiyseniz, hepsini tek tek “Mark as Date Table” diyerek modele tanıtmanızı öneririm.
Jargondaki “role playing dimensions”, tek bir boyutun (dimension) farklı rollere sahip olmasından kaynaklanıyor. “Tarih” tek bir boyut, niteliği aynı, değişmiyor, fakat ifade ettiği, gösterdiği rol farklı. Birinde transaction tarihi, diğerinde teslimat, termin, vade tarihi vs.
İki modelleme yaklaşımı arasındaki en belirleyici avantaj-dezavantaj, örneğini verdiğim tek bir tarih ekseni üzerinde her şeyi görmek ve farklı rollere ait tarihlerin çakıştığı görselleri/matrisleri oluşturmak. Hangisi modeliniz için daha kritikse o yaklaşımı kullanmakta fayda var.
Yazıdaki modeli -bloga üyeyseniz- indirebilirsiniz.
Sadece üyeler görebilir. Hızlı üyelik için sosyal medya hesabınızla giriş yapabilirsiniz!