POWER BI VERİ MODELİ YILDIZ ŞEMASI

Power BI'a yeni başlayan analistlerin çoğu Excel alışkanlığını taşır: tek bir geniş tabloda her şey. Müşteri adı satış kaydının yanında, ürün kategorisi de orada, hatta tarih bilgileri bile tek tabloda. Bu yaklaşım Excel'de işler ama Power BI'da yapısal sorun: yavaş model, kırılgan ölçüler, sürdürülemez bakım.

Veri ambarı dünyasının onlarca yıllık birikiminin bir başlığı var: yıldız şema (star schema). Power BI'ın altındaki motor (Vertipaq) bu yapı için tasarlandı. Doğru şema kurulduğunda model hızlı, ölçüler kısa, bakım kolay; yanlış kurulduğunda terabaytlık RAM ve saatlerce yenileme süresi sorunları başlıyor.

Fact ile Dimension Ayrımı

Yıldız şemanın özü iki tablo tipini ayırmak:

• Fact (Olay) Tablosu: Sayısal ölçümleri içerir. Satış işlemleri, ödemeler, stok hareketleri. Her satır bir olay. Sayısal kolonlar (Miktar, Tutar, Adet) ile boyut tablolarına bağlanan ID kolonları.
• Dimension (Boyut) Tablosu: Açıklayıcı bilgileri içerir. Müşteri, ürün, tarih, lokasyon. Her satır bir varlık. Metin ve kategorik kolonlar.

Fact tablo "ne oldu" sorusuna cevap verir; dimension tablolar "kim, ne, nerede, ne zaman" bilgisini taşır. Pivot tablodaki satır/sütun seçimleri dimension'dan; değerler fact tablodaki sayılardan gelir.

Doğru Granülerlik

Fact tabloda her satır en küçük detay seviyesinde tutulur. Satış için ürün-müşteri-tarih kombinasyonu; her bir satış işlemi ayrı satır. Toplam veya özet seviyede tutmaya çalışmak şu anki ihtiyaç için işe yarar ama yarın "aylık değil, haftalık görmek istiyorum" sorusu geldiğinde model yeniden kurulmak zorunda kalıyor.

Pratik kural: olabildiğince ince granülerlik. Power BI'ın ölçü motoru (DAX) her seviyeye toplama yapabilir; ama önceden topladığınız veriden detaya inemezsiniz. Bir kez kaybedilen detay geri gelmez.

İlişki Yönü

Dimension tablolar fact'e bağlanır, tek yönlü ilişki: dimension → fact. Power BI bu ilişki üzerinden filtreleme yapar. Bir dimension'da seçim yapıldığında fact tablo filtrelenir.

İlişkide üç önemli özellik var:

• Cardinality: Çoğu zaman "one-to-many" (1:N). Bir müşteri çok sipariş.
• Cross filter direction: Tek yönlü (single) önerilir. Çift yönlü (both) performans ve mantık karmaşası yaratır.
• Active relationship: İki tablo arası birden fazla ilişki varsa biri aktif olur. Diğeri DAX ile çağrılır.

İlişkilerin tek yönlü kalması, modelin tahmin edilebilir davranmasını sağlıyor. Çift yönlü ilişki bazı senaryolarda gerekli (köprü tablo) ama gereksiz kullanıldığında sonsuz döngü riskleri ve garip filtreleme sonuçları üretiyor.

Tarih Boyutu (Dim_Tarih)

Her Power BI modelinde merkezi rol oynayan tablo. Excel'de tarih kolonu olay tablosunda durur; Power BI'da ayrı bir tarih tablosu olması şart — özellikle time intelligence fonksiyonları için.

İyi bir tarih boyutu kolonları:

• Date (her gün için bir satır, kesintisiz dizi)
• Year, Month, Quarter, Week
• MonthName, DayName
• IsWorkday, IsHoliday
• FiscalYear, FiscalQuarter (mali yıl takvim farklıysa)
• WeekOfYear, DayOfYear

Power Query'de bu tablo birkaç adımda otomatik üretilir. Bir kez kurulduğunda yıllarca kullanılır; her yıl yeni tarihler otomatik eklenir.

Rol Oynayan Boyut (Role-Playing Dimension)

Bir dimension tablosu farklı rollerde kullanılmak isteniyor olabilir. Bu konunun güncel ayrıntıları Power BI resmi belgelerinde yer alır. Tipik örnek: tarih boyutu hem "Sipariş Tarihi" hem "Teslim Tarihi" hem "Fatura Tarihi" olarak kullanılmak isteniyor.

Power BI'da bu üç yöntemle çözülür:

• Tarih boyutunu üç kez kopyalamak ve her birini ayrı ilişkilendirmek (en yaygın yöntem)
• Tek tarih boyutu, USERELATIONSHIP fonksiyonu ile DAX'tan rol değiştirmek
• Mevcut fact tablosunu unpivot edip rol kolonunu eklemek

İlk yöntem hızlı ve okunabilir; ikinci yöntem temizdir ama DAX karmaşıklığı artar. Modelin amacına göre tercih yapılır.

Slowly Changing Dimension

Bir müşterinin segmenti zamanla değişir; Mart'ta "Standart", Eylül'de "Premium". Bu değişimi nasıl yönetirsiniz?

İki yaklaşım var:

• SCD Type 1: Mevcut değeri günceller, geçmiş kaydedilmez. Sade ama tarih bazlı raporlama zayıf.
• SCD Type 2: Her değişikliği yeni satır olarak tutar. Müşteri-segment kombinasyonu için tarih aralıkları (BaslangicTarihi, BitisTarihi). Geçmişi koruyor.

Çoğu basit kurumsal senaryoda Type 1 yeterli; mali raporlama, denetim gereksinimi olan yapılarda Type 2 zorunlu.

Snowflake Şema: Genelde Kaçınılması Gereken

Dimension tabloların kendi içlerinde alt dimension'lara bağlanması "snowflake" şema. Ürün → Kategori → Üst Kategori gibi hiyerarşi yapısı. Veri normalizasyonu açısından temiz görünür ama Power BI için anti-pattern.

Snowflake'ın iki problemi var: filtreleme yolu uzuyor (performans düşer) ve model karmaşıklaşıyor. Power BI'ın motoru "denormalize" yapı için optimize. Tüm dimension bilgisi tek tabloda toplandığında hem hız hem bakım kolaylığı kazanılıyor.

Pratik karar: hiyerarşik bilgi varsa Power Query'de düzleştir, hepsi tek dimension tablosunda kalsın.

Star Schema'nın Pratik Faydaları

Doğru kurulmuş yıldız şemanın getirdiği avantajlar:

• DAX ölçüleri kısa ve okunabilir kalır
• Performans öngörülebilir; yenileme süreleri stabil
• Yeni rapor eklemek kolay (mevcut model kullanılır)
• Bakım maliyeti düşük; tek tablo değişikliği tüm raporlara yansır
• RAM kullanımı verimli (Vertipaq motoru yıldız şema için optimize)

Excel alışkanlığından gelip "tek tablo" mantığıyla başlayan analistler için yıldız şema disipline geçiş 2-3 hafta zaman alır. Bu süre sonunda raporlama hızı dramatik artıyor; model değişikliği başkasının raporunu kırma korkusu yok oluyor. Yıldız şema disiplini ve DAX pratiğini birlikte oturtmak isteyen analistler için Power BI eğitim içeriği uygulamalı senaryolarla bu yapıyı baştan kurar.