POWER BI DAX NEDİR? MEASURE MANTIĞI, CONTEXT VE YAYGIN HATALAR

Power BI raporları bazen “doğru görünüyor” ama iş sorusunu yanlış yanıtlar: toplamlar tutar, kırılımlar sapar, yüzdeler uçuşur. Bu tür sürprizlerin büyük kısmı tek bir yerde toplanır: DAX ve onun “context” mantığı.

DAX (Data Analysis Expressions), Power BI’ın hesaplama dilidir; ama klasik bir programlama dili gibi düşünmek çoğu zaman yanıltır. DAX, modelinizdeki ilişkiler, filtreler ve görseldeki seçime göre hesaplamayı her an yeniden kurar. Bu yüzden “aynı formül” farklı görsellerde farklı sonuç verebilir.

Bu yazıda “Power BI DAX nedir?” sorusunu pratik bir yerden ele alacağız: measure mantığı, row/filter context, context transition, en sık yapılan hatalar ve bunları önlemek için sağlam bir kontrol listesi.

DAX’in rolü: model üzerinde hesaplama dilinin amacı

DAX’i “Excel formüllerinin gelişmişi” diye tanımlamak kolaydır; fakat Power BI tarafında DAX, model tabanlı çalışır. Yani hesaplamayı sadece hücredeki değere göre değil, model ilişkilerine ve görselin uyguladığı filtrelere göre üretir.

Bir KPI kartı, bir tablo görseli ve bir çubuk grafik aynı measure’ı çağırdığında, her biri farklı bir filtre setiyle çalışır. DAX’in gücü de burada başlar: tek bir measure, farklı bağlamlarda “kendini” doğru konumlandırabilir.

Bu yüzden rapor tasarımında ilk hedef, ölçülerin (measure) tekrar kullanılabilir ve tutarlı olmasıdır. Hesaplamayı tabloya yazmak yerine measure olarak tanımlamak çoğu senaryoda daha doğru sonuç ve daha iyi yönetilebilirlik sağlar.

DAX nerede çalışır, ne zaman çalışır?

DAX; veri yenileme (refresh) sırasında değil, çoğunlukla rapor etkileşimi sırasında çalışır. Slicer seçimi, sayfa filtresi, görsel filtresi, drill-down gibi her aksiyon, measure’ların yeniden hesaplanmasına neden olabilir. Bu davranış, performans ve doğruluk açısından kritik bir tasarım kararına dönüşür.

Measure mantığı: neden “hesaplanan kolon” ile aynı şey değil?

Yeni başlayanların en sık yaptığı hata, her ihtiyacı calculated column ile çözmeye çalışmaktır. Oysa calculated column, veri yenilemede hesaplanır ve satır düzeyinde saklanır; measure ise sorgu anında hesaplanır ve filtre bağlamına göre değişir.

Measure neyi çözer?

• Toplam, ortalama, oran, pay, payda gibi agregasyon ve KPI metrikleri
• Seçime göre değişen “Dinamik” hesaplar (slicer, drill-down, sayfa filtresi)
• Birden çok tablo ve ilişkiyi bir araya getirip bağlama göre sonuç üretme
• Zaman zekâsı (YTD, MTD, geçen yıl, hareketli ortalama) gibi dönemsel hesaplar

Calculated column ne zaman gerekli?

Calculated column, genellikle sınıflandırma, segment, etiket, anahtar üretimi veya ilişki kurmaya yardımcı alanlar için tercih edilir. Örneğin “Müşteri Tipi”, “Kanal Grubu”, “Ürün Segmenti” gibi raporda filtrelenecek bir alan gerekiyorsa calculated column mantıklıdır. Ama “Satış Toplamı” gibi metrikler için measure daha doğru seçim olur.

Context kavramı: DAX’in gerçek sırrı

DAX’te sonuçların “oynamasının” nedeni, formülün kendisi değil; formülün çalıştığı bağlamdır. Bu bağlam iki ana parçaya ayrılır: Row context ve Filter context.

Row context (satır bağlamı) nedir?

Row context, bir tablodaki “mevcut satır” üzerinden hesap yapma durumudur. Calculated column’lar doğal olarak row context ile çalışır. Ayrıca iterator fonksiyonları (SUMX, AVERAGEX vb.) da satır satır ilerleyerek row context üretir.

Filter context (filtre bağlamı) nedir?

Filter context, rapor sayfası, slicer, görsel eksenleri, görsel filtresi, RLS ve ilişkiler üzerinden gelen tüm filtrelerin birleşimidir. Measure’lar ağırlıklı olarak filter context ile hesap yapar. Örneğin “Kategori = Elektronik” seçildiyse measure, sadece o kategoriye ait kayıtları görür.

Context transition: CALCULATE neden “sihirli”?

CALCULATE, DAX’in en kritik fonksiyonlarından biridir çünkü bağlamı değiştirebilir. Özellikle row context içinden filter context’e geçiş (context transition) yaratması, pek çok ileri senaryonun temelini oluşturur. Bu “geçiş” doğru anlaşılmadığında, hesaplar beklenmedik şekilde şişer veya sıfırlanır.

Temel DAX örnekleri: doğru measure nasıl yazılır?

Önce basit ama sağlam bir temel kural: Bir metrik için measure yazıyorsanız, anlamlı bir isim, net bir agregasyon ve mümkünse tek sorumluluk prensibi kullanın. “Her şeyi yapan” dev measure’lar hem zor debug edilir hem de performans maliyeti yaratır.

Örnek 1: satış toplamı ve kâr marjı

Aşağıdaki örnekler, tipik bir satış modelinde en sık ihtiyaç duyulan ölçüleri gösterir. Burada divide kullanımı, sıfıra bölme riskini güvenli şekilde yönetir.

// Toplam Satış
[Toplam Satış] =
SUM ( 'Sales'[SalesAmount] )

// Toplam Maliyet
[Toplam Maliyet] =
SUM ( 'Sales'[CostAmount] )

// Kâr
[Kâr] =
[Toplam Satış] - [Toplam Maliyet]

// Kâr Marjı
[Kâr Marjı] =
DIVIDE ( [Kâr], [Toplam Satış], 0 )

Bu yapı, hem okunabilir hem de tekrar kullanılabilirdir. “Kâr Marjı” gibi oran metrikleri, farklı kırılımlarda (ülke, kategori, müşteri) doğru sonuç vermelidir; bunun yolu, pay ve paydanın measure olarak tanımlanmasıdır.

Örnek 2: seçili bağlama göre dinamik Top-N

Top-N analizlerinde en sık hata, filtrelerin yanlış kaldırılması veya yanlış uygulanmasıdır. Aşağıdaki örnek, seçili bağlamı koruyarak ürünleri satışa göre sıralamak için tipik bir kurgudur.

// Ürün Sıra (seçili bağlamda)
[Ürün Satış Sırası] =
RANKX (
    ALLSELECTED ( 'Product'[ProductName] ),
    [Toplam Satış],
    ,
    DESC,
    Dense
)

Burada ALLSELECTED kullanımı önemlidir: Kullanıcı sayfa/slicer seçimlerini korur, sadece görsel içindeki kategorik alanın sıralama setini yönetir. ALL kullanılsaydı, sayfa seçimleri de yok sayılabilir ve kullanıcı “ben filtreledim ama neden sıralama değişmedi?” diyebilirdi.

Yaygın hatalar: sonuçlar neden yanlış çıkar?

DAX’te hatalar çoğu zaman “syntax” hatası değildir; mantık hatasıdır. Rapor doğru hesaplamıyor gibi görünür, ama aslında formülünüz farklı bir bağlamda çalışıyordur. Aşağıdaki başlıklar, sahada en sık karşılaşılan problemleri toparlar.

1) TOPLAM satırı ile satırların toplamı aynı değil

Özellikle oran ve ortalama gibi metriklerde, toplam satırı “satırların toplamı” değildir; çoğu zaman “toplam bağlamın” yeniden hesaplanmasıdır. Örneğin her ürünün marjını hesaplayıp toplam satırında bunları toplamak genellikle anlamsızdır. Çözüm, toplamda doğru matematiği kurmaktır: ağırlıklı ortalama, pay/payda yaklaşımı veya ayrı bir total mantığı.

2) Relationship yönü ve aktif/pasif ilişki

Modelde ilişki yönleri (single/both) ve pasif ilişkiler, filter context’in akışını belirler. Bir boyut tablosundan fakt tabloya filtre gitmiyorsa, measure doğru “evreni” göremez. USERELATIONSHIP gibi fonksiyonlar, pasif ilişkileri measure içinde kontrollü şekilde devreye almak için kullanılır.

3) ALL ile her şeyi “temizlemek”

ALL, bağlamı kaldırır; ama yanlış yerde kullanılırsa rapordaki tüm seçimleri boşa çıkarır. Kullanıcı filtrelediği halde sonuç değişmiyorsa, çoğu zaman ALL gereğinden geniş kullanılmıştır. Daha dar kapsamlı seçenekler (ALLSELECTED, ALLEXCEPT, REMOVEFILTERS) çoğu zaman daha güvenli ve niyet odaklıdır.

4) EARLIER ve satır bağlamına aşırı yaslanma

EARLIER, calculated column dünyasında yer bulur; ancak karmaşık kullanım, okunabilirliği düşürür ve bakım maliyetini yükseltir. Birçok senaryoda doğru modelleme ve measure yaklaşımı ile EARLIER ihtiyacı ortadan kalkar. Alternatif olarak değişkenler (VAR) ile daha okunabilir yapı kurulabilir.

5) BLANK davranışını yanlış yorumlama

BLANK, DAX’te “0” değildir. Bazı görseller BLANK’ı göstermeyebilir, bazı hesaplar BLANK ile farklı davranabilir. Özellikle DIVIDE ve IF gibi yapılarda BLANK/0 ayrımını bilinçli yönetmek gerekir. Doğru varsayılan değer (alternate result) belirlemek, rapor deneyimini iyileştirir.

Performans ve okunabilirlik: hızlı çalışan DAX için pratikler

Bir measure doğru olsa bile yavaş çalışıyorsa rapor kullanımını baltalar. DAX performansı; veri modeli, kardinalite, ilişkiler ve formülün çalışma şekline bağlıdır. Burada amaç “en kısa yazmak” değil, motorun iyi optimize edebileceği bir ifade üretmektir.

VAR kullan: tekrar hesaplamayı azalt

Değişkenler hem okunabilirliği artırır hem de aynı ifadeyi defalarca hesaplamayı engelleyebilir. Özellikle CALCULATE içinde birden çok kez kullanılan ara sonuçları VAR ile yakalamak iyi bir pratiktir.

İpucu: Karmaşık measure’ları “parçalara böl” yaklaşımı, hem test etmeyi hem de yeniden kullanımı kolaylaştırır.

Iterator’ları gerektiğinde kullan

SUMX gibi iterator fonksiyonları güçlüdür, ama her durumda şart değildir. Basit bir SUM varken SUMX kullanmak gereksiz maliyet yaratabilir. Iterator kullanmanız gerekiyorsa, iterasyon tablosunu mümkün olduğunca küçük tutmak önemlidir.

Filtre kaldırmayı hedefe göre daralt

ALL yerine ALLEXCEPT veya REMOVEFILTERS ile yalnızca gerekli alanların filtresini kaldırmak, hem doğruluğu korur hem de kullanıcı beklentisiyle uyumludur. Böylece rapor etkileşimi “tutarlı” hissedilir.

Debug ve doğrulama: measure’ı nasıl test edersin?

DAX’te güven, “göz kararı” ile değil, sistematik test ile kurulur. Measure’ı doğrulamak için küçük bir kontrol rutini oluşturmak, hataları erken yakalamanın en hızlı yoludur.

Adım adım kontrol yaklaşımı

1. Önce en basit haliyle pay ve paydayı ayrı measure yap.
2. Filtreleri tek tek ekleyerek hangi aşamada sapma başladığını bul.
3. Toplam satır davranışını ayrı değerlendir; gerekirse total için özel mantık kur.
4. Model ilişkilerini ve filtre yönünü kontrol et; “beklediğin filtre akışı” var mı bak.

DAX Studio ve Performance Analyzer ile ölç

Performans sorunlarında sezgi yerine ölçüm gerekir. Power BI’daki Performance Analyzer görsel bazında süreleri gösterir. Daha ileri analizde DAX Studio ile sorgu planına, storage engine/formula engine dağılımına bakarak darboğazı netleştirebilirsiniz. Böylece “neden yavaş” sorusu somut hale gelir.

En iyi uygulamalar: sürdürülebilir bir ölçü katmanı kur

Gerçek hayatta raporlar büyür, yeni sayfalar gelir, ekip değişir. Bu yüzden DAX’iniz yalnızca bugün doğru çalışmamalı; yarın da anlaşılmalı. Aşağıdaki pratikler, ölçü katmanını uzun ömürlü yapar.

İsimlendirme ve klasörleme

Measure isimlerini iş diline yakın tutun: “Toplam Satış”, “Kâr Marjı”, “Sipariş Adedi” gibi. Benzer ölçüleri display folder yapısıyla gruplayın. Bu, hem raporu geliştiren kişinin hızını artırır hem de yanlış measure seçimini azaltır.

Model odaklı düşün: önce şema, sonra DAX

Birçok problem DAX ile değil, modelleme ile çözülür. Yıldız şema, boyut tabloları, doğru ilişki yönü ve tarih tablosu gibi temeller yerinde değilse, DAX “yamaya” dönüşür. Sağlam model, daha kısa ve güvenilir DAX demektir.

Eğitimle hızlan: doğru mental modeli kur

DAX’i ezberlemek yerine, “context” mantığını ve measure düşünme biçimini oturtmak gerekir. Bu yaklaşımı pratik örneklerle pekiştirmek isterseniz Power BI eğitimi sayfasına göz atabilirsiniz.

Özet: DAX’i doğru anlamak neden fark yaratır?

Power BI DAX nedir sorusunun cevabı, sadece “formül dili” değildir; etkileşimli rapor dünyasında doğru hesap üretmenin temelidir. Measure mantığı, row/filter context ve CALCULATE ile bağlam yönetimi oturduğunda, raporlar hem daha doğru hem de daha sürdürülebilir hale gelir.

En iyi sonuç için şu üç noktayı unutmayın: (1) metrikleri measure olarak kurgulayın, (2) bağlamı bilinçli yönetin, (3) toplam satır davranışını özellikle test edin. Bu üçlü, yaygın hataların büyük kısmını otomatik olarak engeller.

Bir sonraki adım olarak, mevcut raporunuzdaki en kritik 5 measure’ı seçip “pay-payda” yaklaşımıyla sadeleştirmeyi deneyin. Hız, doğruluk ve okunabilirlikteki farkı kısa sürede hissedersiniz.