Power BI Veri Modeli: Yıldız Şema ile Doğru Kurulumun Anatomisi

Power BI projelerinin başarısız olma sebeplerinin çoğu, DAX formüllerinin karmaşıklığında değil, alttaki veri modelinin yanlış kurulmasında yatar. Yıldız şema (star schema) — Ralph Kimball tarafından popülerleştirilen boyutsal modelleme yaklaşımı — Power BI'ın matematiksel motoruyla en verimli çalışan yapıdır. Bu yazıda yıldız şemayı, fact ve dimension tablolarını, ilişki yönü kararlarını ve sık yapılan hataları kurumsal bir bakışla ele alacağız.

01. Neden Yıldız Şema? VertiPaq Motorunun Perspektifinden

Power BI'ın kalbi VertiPaq adı verilen sütun bazlı (columnar) sıkıştırma motorudur. Bu motor, veri her sütuna göre ayrı ayrı sıkıştırıp saklar ve sorguları paralel işler.

VertiPaq, tekrar eden değerleri çok verimli sıkıştırır: 10 milyon satırlı bir tabloda "Ürün Kategorisi" sütunu sadece 8 farklı değer içeriyorsa, sıkıştırma oranı %99'a çıkar. Ama aynı sütun, ürün adı ve tedarikçi bilgisiyle birleştirilmiş "flat" tabloda tutulursa, tekrar örüntüsü bozulur ve sıkıştırma dramatik biçimde düşer.

Yıldız şema, tam olarak bu sıkıştırmayı maksimize eder: tekrarlı özellikleri boyut tablolarına ayırır, ölçülebilir olayları fact tablosunda tutar. Sonuç: 5-10 kat daha küçük model, 3-5 kat daha hızlı sorgu.

02. Fact ve Dimension Tabloları: Anatomik Bakış

Fact tablosu, ölçülebilir iş olaylarını tutar: satış, sipariş, tahsilat, üretim çıktısı. Her satır bir "olay" temsil eder ve içeriği:

• Sayısal ölçüler (miktar, tutar, maliyet, adet)
• Boyut tablolarına referans veren yabancı anahtarlar (foreign key)

Dimension tablosu, olayın "kim, ne, nerede, ne zaman" boyutlarını tutar:

• Müşteri (isim, sektör, şehir)
• Ürün (kod, kategori, marka)
• Tarih (yıl, çeyrek, ay, gün, tatil bayrağı)
• Mağaza / Depo (lokasyon, bölge, tip)

İdeal bir yıldız şemada fact tablosu ince ve uzun (milyonlarca satır ama sadece 8-15 sütun), boyut tabloları geniş ama kısa olur (binlerce satır, 20-40 sütun).

03. Tarih Boyutu: Vazgeçilmez Standart

Her ciddi Power BI modelinde ayrı bir Tarih (Date) dimension tablosu olmalıdır. Bu, "gün" gibi görünen küçük bir karar değil, DAX time-intelligence fonksiyonlarının (YTD, SAMEPERIODLASTYEAR, DATESYTD, PARALLELPERIOD) çalışabilmesi için zorunlu bir yapı taşıdır.

Doğru bir Tarih tablosu:

• Analiz dönemini kapsayan kesintisiz tarih aralığı içerir (her gün için tek satır)
• Model içinde "Date table" olarak işaretlenir
• Yıl, çeyrek, ay adı, ay numarası, hafta, gün, iş günü bayrağı sütunları içerir
• Fact tablolarındaki tarih alanlarıyla one-to-many ilişki kurar

Tarih tablosu olmayan modelde time-intelligence DAX'ı yazamazsınız; yazsanız bile beklenmedik sonuçlar üretir.

04. İlişki Yönü ve Kardinalite Kararları

İki tablo arasında ilişki kurarken üç karar vermek gerekir:

• Kardinalite (one-to-many, one-to-one, many-to-many)
• Cross-filter direction (single veya both)
• Aktif / pasif ilişki

Standart yıldız şemada tüm ilişkiler one-to-many (dimension'dan fact'e) olmalı ve tek yönlü (single-direction) çalışmalıdır. Bidirectional ilişki, cazip görünür ama modelin karmaşıklaşmasına, sorguların yavaşlamasına ve beklenmedik toplam davranışlarına yol açar.

Many-to-many ilişkileri özellikle kaçınılmalıdır; gerçekten gerekiyorsa köprü (bridge) tablo ile tek yönlü ilişkilere dönüştürülmelidir. Aktif ilişki her tablo çifti arasında yalnızca bir tane olabilir; ikinci ilişki için USERELATIONSHIP fonksiyonu gerekir.

05. Snowflake Şeması: Ne Zaman Kabul Edilebilir?

Snowflake şeması, dimension tablolarının kendi içinde alt dimension'lara bölündüğü yapıdır (Ürün → Kategori → Ana Kategori). Klasik teoride "normalize" olduğu için tercih edilirdi.

Power BI'da snowflake, VertiPaq motorunun sıkıştırma avantajını azaltır ve DAX yazımını zorlaştırır. Genel kural: dimension tablolarını mümkün olduğunca denormalize edin (tek geniş tablo tercih edin).

Snowflake'in kabul edilebilir olduğu durum: aynı sub-dimension farklı ana dimension'lar tarafından paylaşılıyorsa (örneğin "Bölge" hem "Müşteri" hem "Mağaza" için geçerliyse). O zaman ayrı Bölge tablosu, denormalize etmekten daha temiz kalır.

06. Sık Yapılan 5 Modelleme Hatası

Sahada gördüğümüz en yaygın hatalar:

• Fact ve dimension'ı tek tabloda birleştirmek (flat model): performans çöker, sıkıştırma azalır
• Tarih boyutu olarak fact tablosundaki tarih sütununu kullanmak: time-intelligence bozulur
• Sayısal alanları dimension'a koymak: özellikle tutar, fiyat gibi ölçüler mutlaka fact'te olmalı
• İlişkileri bidirectional yapmak: karmaşıklık ve yavaşlık
• Composite key kullanmak: iki alanın birleşiminden anahtar yaratmak yerine, kaynakta tek bir sürrogat anahtar üretmek gerekir

Bu beş hata düzeltilirse, modelin hem boyutu hem hızı iki-üç kat iyileşir.

07. Modeli Doğrulama: Vertipaq Analyzer ve Best Practices

Modeli kurup geçmeyin; performans karakterini ölçün. Vertipaq Analyzer (DAX Studio içinde ücretsiz araç), tablonuzun her sütununun ne kadar yer kapladığını gösterir. En çok yer kaplayan sütunlar genellikle:

• Yüksek kardinaliteli metin (müşteri adı, ürün açıklaması)
• Tarih-saat sütunları (sadece tarih yeterliyken zaman da tutulmuş)
• ID sütunları (tekilse sıkıştırılamaz)

Best Practices Analyzer (BPA), tabular editor içinde yıldız şema en iyi pratiklerini otomatik denetler; ihlaller listelenir. Her prod öncesi çalıştırılmalıdır.