Veri Ambarı Modelleme: Şema Seçimi Neden Önemli?
Veri ambarı projelerinde en kritik kararlardan biri veri modellemesi seçimidir. Verilerinizi nasıl yapılandırdığınız, sorgu performansını, bakım kolaylığını ve raporlama esnekliğini doğrudan etkiler. İki temel yaklaşım öne çıkar: Star Schema (Yıldız Şeması) ve Snowflake Schema (Kar Tanesi Şeması).
Bu rehberde her iki yaklaşımı derinlemesine inceleyecek, avantaj ve dezavantajlarını karşılaştıracak ve hangi durumda hangisini tercih etmeniz gerektiğini açıklayacağız.
Star Schema (Yıldız Şeması)
Star Schema, Ralph Kimball'ın boyutsal modelleme yaklaşımının temelini oluşturur. Merkezdeki Fact tablosu (ölçü değerleri) etrafında denormalize Dimension tabloları yer alır. Diyagramda yıldız şekline benzediği için bu ismi almıştır.
Yapısı
SQL Örneği
-- Star Schema: Basit ve hızlı sorgulama
SELECT
d.Yil,
d.CeyrekAdi,
m.Bolge,
u.Kategori,
SUM(f.Tutar) AS ToplamSatis,
AVG(f.Tutar) AS OrtalamaSiparis
FROM FactSatis f
JOIN DimZaman d ON f.ZamanKey = d.ZamanKey
JOIN DimMusteri m ON f.MusteriKey = m.MusteriKey
JOIN DimUrun u ON f.UrunKey = u.UrunKey
GROUP BY d.Yil, d.CeyrekAdi, m.Bolge, u.Kategori;
-- Sadece 3 JOIN gerekli!Star Schema Avantajları
- Yüksek sorgu performansı: Daha az JOIN, daha hızlı sonuç
- Basit anlaşılırlık: İş kullanıcıları modeli kolayca anlayabilir
- Power BI uyumu: Microsoft, Star Schema'yı açıkça önerir
- Kolay bakım: Dimension değişikliklerinde tek tablo güncellenir
Snowflake Schema (Kar Tanesi Şeması)
Snowflake Schema'da Dimension tabloları normalize edilmiştir — yani alt tablolara bölünmüştür. Örneğin DimUrun tablosu DimKategori ve DimMarka gibi ayrı tablolara ayrılır.
Yapısı
SQL Örneği
-- Snowflake Schema: Daha fazla JOIN gerekli
SELECT
d.Yil,
b.BolgeAdi,
dep.DepartmanAdi,
k.KategoriAdi,
SUM(f.Tutar) AS ToplamSatis
FROM FactSatis f
JOIN DimZaman d ON f.ZamanKey = d.ZamanKey
JOIN DimMusteri m ON f.MusteriKey = m.MusteriKey
JOIN DimSehir s ON m.SehirKey = s.SehirKey
JOIN DimBolge b ON s.BolgeKey = b.BolgeKey
JOIN DimUrun u ON f.UrunKey = u.UrunKey
JOIN DimKategori k ON u.KategoriKey = k.KategoriKey
JOIN DimDepartman dep ON k.DepartmanKey = dep.DepartmanKey
GROUP BY d.Yil, b.BolgeAdi, dep.DepartmanAdi, k.KategoriAdi;
-- 7 JOIN gerekli!Snowflake Schema Avantajları
- Düşük depolama alanı: Normalize yapı tekrarı azaltır
- Veri bütünlüğü: Referans tabloları tek noktadan güncellenir
- Standart uyumluluk: 3NF kurallarına daha yakın
Karşılaştırma Tablosu
| Kriter | Star Schema | Snowflake Schema |
|---|---|---|
| Sorgu Performansı | ⭐⭐⭐⭐⭐ Çok hızlı | ⭐⭐⭐ Orta |
| Depolama Alanı | ⭐⭐⭐ Daha fazla | ⭐⭐⭐⭐⭐ Tasarruflu |
| Anlaşılırlık | ⭐⭐⭐⭐⭐ Kolay | ⭐⭐⭐ Karmaşık |
| JOIN Sayısı | Az (3-5) | Çok (7-12) |
| Bakım | ⭐⭐⭐⭐ Kolay | ⭐⭐⭐ Zor |
| Power BI Uyumu | ⭐⭐⭐⭐⭐ Mükemmel | ⭐⭐⭐ Orta |
| ETL Karmaşıklığı | ⭐⭐⭐⭐ Basit | ⭐⭐⭐ Karmaşık |
Hangisini Tercih Etmelisiniz?
Star Schema'yı Seçin Eğer:
- Power BI, Tableau veya SAP BO gibi BI araçları kullanıyorsanız
- Sorgu performansı öncelikliyse
- İş kullanıcılarının modeli anlamasını istiyorsanız
- Hızlı geliştirme ve bakım önemliyse
Snowflake Schema'yı Seçin Eğer:
- Çok büyük Dimension tabloları varsa (milyonlarca satır)
- Depolama maliyeti kritik bir faktörse
- Veri bütünlüğü en üst düzeyde gerekiyorsa
- ETL süreçleri zaten karmaşıksa
Sonuç
Star Schema ve Snowflake Schema, her ikisi de veri ambarı modellemesinde geçerli yaklaşımlardır. Ancak modern BI ekosisteminde — özellikle Power BI ve SAP BW/4HANA kullanıyorsanız — Star Schema açık ara favoridir. Daha hızlı sorgular, daha kolay bakım ve daha iyi araç uyumu sunar. Snowflake Schema ise depolama optimizasyonu gereken özel senaryolarda değerini korur.
