Ralph Kimball'ın 1996'daki "The Data Warehouse Toolkit" kitabı yayımlandığından bu yana star schema, analitik veri modelinin altın standardı oldu. Ancak modern bulut platformlarının gelişiyle snowflake schema ve hatta daha uç modeller yeniden tartışma konusu. Karar ne üzerinde?
Star Schema
Merkezde fact tablosu (sales_fact), çevresinde denormalize dimension tabloları (dim_customer, dim_product, dim_date). Her boyut tek bir tabloda toplanır; JOIN sayısı minimum. Avantaj: basitlik, performans, BI aracının doğal sevdiği şekil.
sales_fact ←→ dim_customer ←→ dim_product ←→ dim_date ←→ dim_store
Snowflake Schema
Dimension'lar normalize edilir — dim_product → dim_category → dim_department gibi alt ilişkiler oluşur. Avantaj: daha az depolama, bakım kolaylığı. Dezavantaj: JOIN sayısı artar, sorgu karmaşıklaşır, BI aracı modelleme daha ağırdır.
Modern Bulut Perspektifi
Columnar storage (Snowflake, BigQuery, Synapse) çağında denormalize tablo boyutu eskisi kadar önemli değil. 1 TB'lık bir dim_customer tablosu columnar compression ile 50 GB'a inebiliyor. Dolayısıyla "snowflake schema ile alan kazanıyoruz" argümanı zayıfladı.
Diğer yandan GCP BigQuery ve AWS Athena gibi platformlarda JOIN maliyeti hâlâ önemli; bu platformlarda star schema daha ekonomik çalışıyor.
Pratik Rehber
- BI odaklı DWH (Power BI, Tableau, Qlik): Star schema — doğal entegrasyon, tutarlı performans.
- Data science + analitik hibrit: Star, ama dimension'larda hiyerarşiler için bağlantılı mini-tablolar (hafif snowflake).
- Çok dinamik ürün kataloğu (perakende, e-ticaret): Denormalize dim_product günlük güncellemelerde performans cezası yaratır; ya incremental rebuild ya da snowflake.
- Regülasyon raporları: Snapshot fact + tarihli SCD Type 2 dimension (her iki modelin üstü).
Denormalize Edilmesi Gereken Alanlar
- Tarih hiyerarşileri (yıl/çeyrek/ay/gün): her zaman dim_date'te denormalize.
- Müşteri demografi: çoğu zaman dim_customer'a taşı.
- Ürün kategori yolu: eğer 4+ seviye varsa, snowflake avantajlı olabilir.
One Big Table (OBT) Yaklaşımı
Modern ML pipeline'ları ve bazı self-service BI senaryoları, dimensional model yerine tek bir geniş tablo tercih ediyor. JOIN yok, tüm context'i tek satırda. Dezavantaj: bakım maliyeti çok yüksek; değişiklikler tüm tabloya yayılıyor. Önerimiz: OBT sadece ML feature store için; genel BI için dimensional model hâlâ kazanan.
