Veri ambarında yıldız şema nasıl tasarlanır?

Yıldız şema neyi çözer?

Yıldız şema, analiz sorgularını hızlı ve anlaşılır kılmak için veriyi tek bir merkezde toplanan ölçümler ve bu ölçümleri çevreleyen açıklayıcı tablolar olarak düzenleyen modeldir. Ortada olgu tablosu (fact table) durur, çevresinde boyut tabloları (dimension tables) yer alır. Şemanın çizimi yıldıza benzediği için bu adı alır.

İşlemsel sistemlerdeki normalize edilmiş yapı, kayıt girişi için iyidir ama bir yönetici raporu için çok sayıda tabloyu birbirine bağlamayı gerektirir. Yıldız şema bu bağlantıları baştan düşünür: analist satışı ürüne, tarihe, mağazaya ve müşteriye göre kırmak istediğinde her kırılım tek bir birleştirme uzaklığındadır. Kimball Group'un boyutsal modelleme teknikleri bu yaklaşımın standart kaynağıdır.

Tasarıma hangi sırayla başlanır?

Boyutsal modelleme birkaç ardışık karar üzerine kurulur ve sıra önemlidir. Önce iş süreci seçilir: sipariş alma, fatura kesme, stok hareketi, çağrı kaydı gibi ölçüm üreten bir süreç. Sonra tane (grain) belirlenir: olgu tablosunun bir satırı tam olarak neyi temsil eder? Ardından o taneye uyan boyutlar, en son da ölçümler yani olgular belirlenir.

En sık yapılan hata, tabloları çizmeye taneyi yazmadan başlamaktır. Tane cümle olarak yazılmalıdır, örneğin: Bir satış faturasının her kalemi için bir satır. Bu cümle yazılınca hangi boyutların bağlanabileceği ve hangi ölçümlerin toplanabileceği kendiliğinden netleşir. Tane belirsiz kalırsa aynı tabloda hem sipariş hem kalem düzeyinde değer birikir ve toplamlar sessizce yanlış çıkar.

Olgu tablosu nasıl kurulur?

Olgu tablosu sayısal ölçümleri ve boyut tablolarına giden anahtarları taşır. Kimball sınıflandırmasında başlıca türler işlem (transaction), periyodik özet (periodic snapshot) ve birikimli özet (accumulating snapshot) olgu tablolarıdır; ölçümü olmayan, yalnızca olayın gerçekleştiğini kaydeden olgusuz (factless) tablolar da vardır.

Ölçümleri toplanabilirliğe göre ayır: • Toplanabilir: satış tutarı, adet, maliyet. Her boyutta toplanabilir. • Yarı toplanabilir: stok bakiyesi gibi değerler. Zaman boyunca toplanmaz, ortalaması alınır. • Toplanamaz: oran ve yüzdeler. Bunları tabloya koymak yerine pay ve paydayı ayrı sakla, oranı raporda hesapla.

Fatura numarası gibi tek başına tablo gerektirmeyen tanımlayıcılar olgu tablosunda kalabilir; buna dejenere boyut (degenerate dimension) denir. Olgu tablosuna açıklayıcı metin koyma, onun yeri boyut tablosudur.

Boyut tablosu nasıl tasarlanır?

Boyut tabloları raporun etiketlerini, filtrelerini ve gruplama alanlarını taşır. Geniş olması sorun değildir; ürün boyutunda kategori, marka, renk, paket tipi gibi onlarca öznitelik bulunabilir. Normalize edip kar tanesi şemaya (snowflake) dönmek yerine tek tabloda düz tutmak, sorguyu basit ve hızlı bırakır.

Her boyut satırına iş sisteminden bağımsız bir yedek anahtar (surrogate key) ver. İş anahtarı (ürün kodu, müşteri numarası) ayrı bir sütun olarak kalır. Yedek anahtar sayesinde kaynak sistem kodu yeniden kullansa bile tarihsel kayıtlar karışmaz ve boyutun geçmişini tutmak mümkün olur. Tarih boyutu neredeyse her şemada bulunur; takvim tarihine ek olarak hafta, ay, çeyrek, resmî tatil ve mali dönem gibi alanları önceden hesaplayıp saklar. Aynı tarih, ürün ve müşteri boyutlarını birden çok olgu tablosunda ortak kullanmak, uyumlu boyut (conformed dimension) ilkesidir ve farklı süreçlerin raporlarını yan yana okunur kılar.

Örnek: perakende satış şeması

Örneğin bir perakende firmasının satış faturalarını modelleyelim. Tane: fatura kalemi başına bir satır. Boyutlar: tarih, ürün, mağaza, müşteri. Olgular: adet, brüt tutar, indirim tutarı, net tutar. Olgu tablosunda bu boyutların yedek anahtarları, fatura numarası (dejenere boyut) ve ölçümler bulunur.

Bu yapıda aylık ve kategori bazlı net satış sorgusu şuna benzer:

SELECT d.month_name, p.category, SUM(f.net_amount) AS net_sales FROM fact_sales f JOIN dim_date d ON f.date_key = d.date_key JOIN dim_product p ON f.product_key = p.product_key GROUP BY d.month_name, p.category;

Sorgu yalnızca birleştirme ve gruplamadan ibarettir. Mağaza ya da müşteri kırılımı eklemek yalnızca bir birleştirme daha demektir. Şema doğru kurulduğunda yeni rapor taleplerinin çoğu yeni tablo gerektirmez.

Yaygın hatalar ve kontrol listesi

Yıldız şema projelerinde tekrar eden hatalar şunlardır: • Tane yazılmadan tablo çizmek ve olgu tablosunda karışık düzeyde veri biriktirmek. • Boş (NULL) boyut anahtarlarını olduğu gibi bırakmak; bunun yerine bilinmiyor satırı olan bir boyut kaydı kullanmak, birleştirmelerde satır kaybını önler. • Oranları ve ortalamaları olgu tablosunda saklayıp sonra toplamaya çalışmak. • Boyutu aşırı normalize edip her sorguda uzun birleştirme zincirleri yaratmak. • Tarihsel değişimi düşünmeden boyutu üzerine yazmak. Bu konu için yavaş değişen boyut stratejileri ayrıca ele alınmalıdır.

Tasarımı bitirmeden önce kontrol et: tane tek cümleyle yazılı mı, her olgu bu taneye uyuyor mu, her boyutun yedek anahtarı ve iş anahtarı var mı, ortak boyutlar süreçler arasında aynı mı, iş birimi örnek soruları şema üzerinden yanıtlayabiliyor mu?

Mindset programlarında nerede çalışılır?

Bu beceri, veri ambarı geliştiren mühendisler ve raporlama modelini sahiplenen analitik ekipleri için doğrudan işe yarar. Boyutsal Modelleme ve Kimball Metodolojisi eğitiminin modülleri olgu tablolarının ve boyut tablolarının tasarımını ayrı ayrı ele alır ve fiziksel tasarımla bitirme projesine bağlanır.

Veri Mühendisliği Programı ise modellemeyi veri ambarı, veri gölü ve lakehouse mimarileri ile ELT tasarımının içinde, uçtan uca bir veri hattının parçası olarak işler. Şirket içinde raporlama dağınıklığı yaşayan ekipler için modelleme, tek doğru kaynağı kurmanın ilk adımıdır.