Star Schema Modeli Kurarken Dikkat Edilmesi Gerekenler

Vispeahen'de bir Star Schema modeli kurarken aşağıdaki noktalara dikkat etmek, modelin doğru çalışmasını, performanslı olmasını ve zaman içinde sürdürülebilir kalmasını sağlar.

1. İsimlendirme Standardı

Fact ve Dimension tabloları birbirinden ayırt etmek için tutarlı bir önek kullanın: Fact tablolar için “fact_”, Dimension tablolar için “Dim” öneki (örn. DimTarih, DimUrunKategori, DimBolge, DimMusteri). Model büyüdükçe bu standart, hangi tablonun fact hangi tablonun dimension olduğunu hızlıca ayırt etmeyi sağlar ve ekip içinde ortak bir dil oluşturur.

2. Join Kolonlarının Veri Tipi ve Format Uyumu

Fact ve Dimension tablolardaki join kolonlarının veri tipleri (metin-metin, sayı-sayı) ve değer formatları (büyük/küçük harf, boşluk, kod biçimi) birbiriyle uyumlu olmalıdır. Örneğin “city_code” ile “plaka” kolonlarının aynı kod setini kullanması gerekir. Uyumsuzluk, join'in hiç eşleşmemesine veya raporlarda eksik veri görünmesine yol açar.

3. Join Tipi Seçimi: Inner ve Left

Inner join sadece her iki tarafta karşılığı olan kayıtları getirir. Dimension tabloda karşılığı olmayan Fact kayıtları varsa (örneğin henüz tanımlanmamış bir ürün kategorisi), bu kayıtlar Inner join ile dashboard'dan tamamen kaybolur. Fact tablosundaki tüm kayıtların korunması gerekiyorsa Left join tercih edilmeli; Dimension tarafında eşleşmeyen değerler için “Tanımsız” gibi bir varsayılan satır eklemek iyi bir pratiktir.

4. DimTarih (Date) Tablosunun Önemi

Zaman bazlı analizler (yıl, ay, çeyrek, hafta, haftanın günü) için ayrı bir DimTarih tablosu oluşturup tüm Fact tablolardaki tarih kolonlarını bu ortak tabloya bağlayın. Bu yaklaşım tutarlı bir tarih hiyerarşisi sağlar ve farklı Fact tablolar arasında tarih bazlı karşılaştırmalı analizleri mümkün kılar.

5. Çoka-Bir (Many-to-One) İlişkiyi Koruma

Fact-Dimension join'leri her zaman “many-to-one” (çoka-bir) olmalıdır: bir Fact satırı yalnızca bir Dimension satırına eşleşmelidir. Dimension tablosunda tekrar eden anahtar değerleri varsa join sonucunda satır çoğalması (row duplication) oluşur ve toplamlar (SUM, COUNT) yanlış hesaplanır. Dimension tablosunun anahtar kolonunun benzersiz (unique) olduğundan emin olun.

6. Gereksiz Join'lerden Kaçınma ve Performans

Sadece dashboard ve raporlarda gerçekten kullanılacak Dimension tabloları join edin; kullanılmayan join'ler modeli karmaşıklaştırır ve sorgu performansını düşürür. Sık kullanılan join ve filtre kolonlarında, özellikle Fact tablosundaki foreign key kolonlarında indeks tanımlamak performansı önemli ölçüde artırır.

7. Kurulumdan Sonra Test ve Doğrulama

Model kurulduktan sonra basit bir dashboard veya rapor ile join sonuçlarını kontrol edin: toplam satır sayısı join öncesi ve sonrasında aynı mı? Beklenen toplamlar (SUM) değişmiyor mu? Bu kontroller, satır çoğalması (row duplication) veya veri kaybı gibi sorunları erken aşamada yakalamanızı sağlar.

Hızlı Kontrol Listesi:

• Tablo isimleri Fact_/Dim ön ekiyle tutarlı mı?

• Join kolonlarının veri tipi ve formatı eşleşiyor mu?

• Join tipi (Inner/Left) doğru seçildi mi?

• DimTarih tüm Fact tablolara bağlı mı?

• Dimension anahtar kolonu benzersiz mi?

• Gereksiz join yok mu ve foreign key'lerde indeks var mı?