DAX, T-SQL, Excel, Veri Ambarı

Yakın zamanda başlayacak olan görsel ve videolu eğitim yazılarına geçmeden önce bir iki yazı daha mevcut tecrübelerim üzerinden tespitler yapmama müsade edin.

Projelerde teknik anlamda iki farklı profille karşılaşıyorum: Excel power user’lar, yani Excel’i iyi kullananlar ve SQL’ciler.

Excel kullanıcıları genelde, mali işler, finans, planlama, satınalma kademelerinde çalışan arkadaşlar.

SQL’ciler ise büyük oranda IT kökenli kişiler.

Excel kullanıcılarının DAX’a adaptasyonu, alışması daha hızlı ve kolay oluyor. “Niye DAX kullanıyoruz” gibi bir soru gelmiyor. Aksine, Excel’de kullanılan bir çok fonksiyonun benzer yapıda olması, pivot tablo mantığının neredeyse aynı olması, “relationship”‘ler sayesinde vlookup’lardan kurtulmaları çok ilgilerini çekiyor. Hesaplanmış sütun mantığını hemen anlıyorlar.

Excel ve DAX’taki benzer fonksiyonlar

Excel power user’lar, PBI ile ilgili genelde iki noktada -biraz- duraksıyorlar. Birincisi Excel’deki “hücre” referansına alışmış olmalarından kaynaklanıyor, PBI’da hücreye referans yok, tablo ve sütunlar üzerinden her şey.

İkincisi, tek bir tabloda her şeyi kullanmaya alışmış olmaları. Ürün satışlarını inceliyorlarsa, satışların olduğu tabloda ürüne ait tüm sütunlar var.

PBI’da bu tür tanım çoklamalarına gerek yoktur, transaction tabloları ayrıdır, dimension (boyut) tabloları ayrıdır. Tablolar arası “relation”‘lar kurmak yeterlidir.

DAX ile SQL’in de ortak noktaları çok: bir çok komut, hatta çalışma şekli SQL’den alınma.

DAX ve SQL’deki benzer fonksiyonlar

SQL’e ve T-SQL ile sorgu yazmaya hakim kişiler genelde şöyle bir soru soruyorlar: DAX ile yapılan hesaplamaları T-SQL ile yapmak mümkün, veri ambarına rakamları “sum” ederek getirmek mümkün, “group by” yapmak mümkün. Bu durumda niye DAX kullanıyoruz? Kullanmasak da olur mu?

Kısmen haklılar.

T-SQL

Satışlar - Yüksek Gelirli Müşteriler:=
   SELECT SUM(Fiyat * Miktar)
   FROM Satışlar
   WHERE MüşteriID IN (
      SELECT DISTINCT ID 
      FROM Müşteriler
      WHERE Gelir > 10000
   )

DAX

Satışlar - Yüksek Gelirli Müşteriler :=
CALCULATE (
    SUMX ( 'Satışlar'; 'Satışlar'[Fiyat] * 'Satışlar'[Miktar] );
    'Müşteriler'[Gelir] > 10000
)

Aynı hesaplamayı hem DAX ile hem SQL ile yapabilirsiniz. Doğru!

SQL kullanıcıları ile ilgili ikinci konu, veri ambarı oluşturma tarafında çıkıyor. Detay satırların daha PBI’a verileri çekmeden önce gruplanabilir olması, “sum” larının alınabilmesi, “niye hesaplamaları DAX’ta yapıyoruz, SQL tarafında da çözebiliriz” sorusunu getiriyor. Bu da doğru!

Farklara gelince:

• DAX in-memory çalışır. SQL öyle değildir (column store index’le kısmen yaklaşabilir.) Yukarıdaki sorgu Müşteriler tablosu 10 milyon satırsa belki 30 saniyede gelir. DAX’ta 3 sn sürmez.
• SQL kodları “portable” değildir. DAX “portable” dır.  Geliri 10000’den yüksek olanlar + Üniversite mezunlarını bulmak isterseniz SQL’de kodu sıfırdan tekrar yazmanız gerekir. DAX’ta önceki yazdığınız metriği kullanmaya devam edersiniz ( Calculate ([Satışlar – Yüksek Gelirli Müşteriler];’Müşteriler'[Eğitim]=”Üniversite”) gibi ) Hatta buna bile gerek kalmaz, “Eğitim” tipini rapora düşürdüğünüz anda her bir eğitim tipi için hesaplamayı direkt yapar.
• SQL’de kod yazarken releationship’leri her defasında tekrar tanımlamak gerekir, PBI’da relationship’leri bir kez tanımlarsınız, modelin bir parçası olur, tekrar tekrar tanımlamaya gerek yoktur.
• SQL’de 3-4 tabloyu birleştirerek bir sorgu attığınızda canlı sistemi yavaşlatabilirsiniz, PBI kendi verisini üzerinde çalışır, canlı sistemi etkilemez,  tablolar arasında “relationship”‘ler üzerinden “hızlı” hesaplama yapmak üzere tasarlandığından her durumda SQL’den daha hızlı çalışır.
• Veri ambarına rakamları gruplayarak getirmek, “sum” etmek, “aggregate” etmek, “detay” görmek istediğinizde tekrar kodunuzu değiştirmenizi gerektirir, canlı sisteme de yük bindirir. PBI ile en alt seviye detay veriyi çektiğinizde otomatik “aggregate”‘ler kendiliğinden hazırdır.
• SQL ile “bir veya bir kaç soruya” cevap veren kodlar yazabilirsiniz. Cevap vermeniz gereken soru sayısı arttıkça, size lazım olan tablo sayısı arttıkça yazmanız gereken kodun  “bakımını” yapamaz hale gelirsiniz, canlı sistemi de muhtemelen çökertirsiniz. PBI ile doğru bir veri modeli kurduğunuzda, finanstan, satışlara, stoklardan siparişlerinize kadar her şeyi bir kez yaparsınız.
• OLTP veritabanı başka, OLAP başkadır. Tamamen farklı terminolojiler. Amerika kıtasına yüzerek de gidebilirsiniz, uçakla da.
• T-SQL bir sorgulama dilidir. DAX bir veri modelleme dilidir.

Bu veri modelini SQL kodu yazarak kuramazsınız!

Ayrı bir veri ambarı kuracaksanız önerilerim şunlar: size en alt seviyede hangi detaylar lazımsa onları çekin. SQL tarafında herhangi bir gruplama, aggregasyon yapmayın, join vs yapmayın.  Veri ambarı tasarımına başka araçlar kullanarak “haftalar” ayırmayın. Küçük bile olsa “sonuç” döndürün. Size lazım olan tüm yetenekler PBI tarafında mevcut.