Modern Veri Ambarı Tasarımı: Star Schema, Snowflake ve En İyi Uygulamalar

Veri ambarı neden modelleme gerektirir?

İşletme veritabanları (OLTP sistemleri) günlük operasyonlar için optimize edilmiştir. Satış sisteminin amacı sipariş kaydetmektir, raporlama değil. Bu sistemlerde veriler normalized (3NF veya daha yüksek) tutulur — yani her bilgi mümkün olan en az yerde, tekrar edilmeden saklanır.

Veri ambarı ise tam tersi: Analitik sorgular için optimize edilmiştir. Analistler ve iş kullanıcıları hızlı yanıt bekliyor — karmaşık JOIN'ler yerine, tek bir tablodan okuma yapmak istiyorlar. İşte bu nedenle veri ambarında denormalize veya yarı-denormalize yapılar tercih edilir.

Ralph Kimball'un 90'lı yıllarda popülerleştirdiği dimensional modeling (boyutsal modelleme) yaklaşımı, bu ihtiyaca yanıt veriyor. Bu yaklaşımın temelinde iki tür tablo var: fact table (olgu tablosu) ve dimension table (boyut tablosu).

Fact table: Sayısal ve toplamsal

Fact table, veri ambarının merkezidir ve iş süreçlerine ait ölçümleri (metrics) saklar. Satış verisi mi tutuyorsunuz? Fact table'ınız satış adedi, satış tutarı, maliyet, kar gibi sayısal değerlerden oluşur. Her satır, belirli bir iş olayını temsil eder.

Fact table'ın temel özellikleri: Satır sayısı çok büyüktür (milyonlarca, milyarlarca satır olabilir). Sütunlar çoğunlukla sayısal ve toplamsaldır (summarizable). Diğer tablolara foreign key ile bağlanır. Tarih boyutu neredeyse her fact table'da bulunur.

Fact table'lar transaction grain'ine (işlem ölçekliliğine) göre sınıflandırılır: Transaction (her sipariş kalemi bir satır), Periodic snapshot (gunluk/aylık toplamlar) ve Accumulating snapshot (siparişin tüm süreç boyunca biriken metrikler). Hangi tip seçileceği, iş gereksinimlerine bağlıdır.

Dimension table: Açıklayıcı bağlam

Dimension table'lar, fact table'daki ölçümlerin "kim, ne, nerede, ne zaman, neden" sorularını yanıtlar. Müşteri adı, ürün kategorisi, satış bölgesi, sipariş tarihi gibi bilgiler dimension'larda saklanır. Genellikle az satır sayısına sahiptir ama sütun sayısı fazladır.

Dimension'ların en önemli özelliklerinden biri, surrogate key kullanımıdır. Doğal anahtar (gerçek sistemdeki ID) yerine, veri ambarında sıralı numara atanan yapay anahtar (surrogate key) kullanılır. Bunun üç nedeni var: Doğal anahtar kaynak sistemde değişebilir, tarihsel izleme için gereklidir, ve performans açısından integer anahtarlar daha hızlı JOIN yapılabilir.

Star schema: Sadelik ve performans

Star schema, dimensional modeling'in en yaygın ve önerilen biçimidir. Merkezde fact table, çevresinde dimension table'lar — tablo isimlerinin yerleşimi bir yıldızı andırır. Her dimension, fact table'a doğrudan ve aracısız bağlanır. Ara katman yoktur.

Star schema'nın avantajları: Sorgu performansı yüksektir, çünkü JOIN işlemi minimal sayıda tablo üzerinden yapılır. BI araçları (Power BI, Tableau) star schema'yı doğal olarak destekler. Veri modelini anlamak ve dokumentasyonu yapmak kolaydır.

Ancak star schema'nın bir dezavantajı var: Dimension'larda veri tekrarı (redundancy) olabilir. Örneğin, ürün kategorisi boyutunda hem kategori adı hem de alt kategori adı tekrar edebilir. Bu, depolama alanını artırır ama sorgu hızını düşürmez — tam tersine, JOIN sayısını azaltarak hızı artırır.

Snowflake schema: Normalizasyon ve veri tekrarını azaltma

Snowflake schema, dimension table'ların da normalize edildiği yapıdır. Kategori ayrı bir tabloya, alt kategori ayrı bir tabloya, coğrafi bilgiler başka bir tabloya ayrılır. Bu yapı, veri tekrarını minimize eder ama sorgu performansını düşürür — çünkü artık daha fazla JOIN işlemi gerekir.

Snowflake'in savunucuları "veri tutarlılığı" der. Evet, tekrar azalır ama gerçek hayatta bu tutarlılık kaybı mı yoksa sorgu hızı mı daha kritik? Çoğu iş zekası senaryosunda cevap sorgu hızıdır. Snowflake, özellikle boyutlar çok büyükse (örneğin milyonlarca ürün içeren bir ürün kataloğu) ve normalize etmek depolama maliyetini ciddi oranda düşürecekse düşünülebilir.

Pratik yaklaşım: Star schema varsayılan olmalı. Yalnızca somut bir neden varsa (aşırı veri tekrarı, boyut tablosu çok büyük ve normalize etmek anlamlı tasarruf sağlayacaksa) snowflake düşünülmeli. Bu kararı da erken aşamada almak gerekir — sonradan star'dan snowflake'e geçiş, raporlama katmanında çok fazla değişiklik gerektirir.

Slowly Changing Dimensions (SCD): Tarihsel izleme

Müşterinizin adresi değiştiğinde, eski adresi ne olacak? Ürünün kategorisi güncellendiğinde, geçmiş satışlardaki kategori bilgisi de mi değişecek, yoksa tarihsel olarak eski kategori mi kalmalı? İşte Slowly Changing Dimensions (SCD) bu sorulara yanıt veriyor.

Type 1 — Overwrite (Üzerine yaz): Eski değer yeni değerle değiştirilir, tarihsel izleme yapılmaz. Uygulama: Referans tabloları veya tarihsel önemi olmayan alanlar. Dezavantajı: Geçmiş veri kaybolur.

Type 2 — Add new row (Yeni satır ekle): Her değişiklik için yeni satır eklenir ve eski satır tarihsel bilgiyle işaretlenir. Böylece herhangi bir tarihteki durumu sorgulamak mümkün olur. En yaygın kullanılan SCD tipidir.

Type 3 — Add new column (Yeni sütun ekle): Eski ve yeni değer aynı satırda farklı sütunlarda tutulur. Sınırlı tarihsel görünüm sağlar ama depolama açısından verimlidir.

Type 6 (Hybrid): Type 1, 2 ve 3'ün kombinasyonu. Pratikte karmaşıklığı nedeniyle az kullanılır.

Gerçek bir perakende senaryosu

Bir perakende zinciri için veri ambarı tasarladığınızı düşünün. Fact tables: Satış (satış adedi, tutarı, maliyeti), Stok (anlık stok miktarı), Sipariş (sipariş adedi). Dimension tables: Ürün (ad, marka, kategori, alt kategori, birim fiyat), Müşteri (ad, segment, bölge, kayıt tarihi), Mağaza (ad, bölge, tip, açılış tarihi), Tarih (yıl, ay, hafta, gün, tatil bayram).

SCD örneği: Müşterinin segmenti değişti (Küçük İşletme → Orta Ölçekli). Satış raporlarında geçmiş segment bazında analiz yapılacaksa SCD Type 2 kullanılır — her segment değişikliği için yeni satır açılır, eski satır ValidTo ile kapatılır. Eğer sadece güncel segment önemliyse ve geçmiş kaydı tutulmasına gerek yoksa Type 1 overwrite yeterlidir.