Yavaş değişen boyutlar veri ambarında nasıl yönetilir?

Sorun: boyut değiştiğinde geçmiş ne olur?

Bir müşteri şehir değiştirir, bir ürün başka bir kategoriye taşınır, bir satış temsilcisi başka bölgeye atanır. Boyut tablosunda bu değişikliği yapmanın tek bir doğru yolu yoktur, çünkü rapor geçmişi farklı biçimlerde okuyabilir: ya her şeyi bugünkü değerle göstermek istersin ya da olay anındaki değerle.

Örneğin bir müşteri geçen yıl İzmir'de oturuyordu ve şimdi Ankara'da. Geçen yılın satışlarını bölge bazında raporlarken bu satışlar İzmir'e mi yazılmalı, Ankara'ya mı? Yavaş değişen boyut (slowly changing dimension, SCD) teknikleri bu soruya alan bazında cevap vermeni sağlar. Kimball Group, tekniklerini Tip 1 için üzerine yazma, Tip 2 için yeni satır ekleme, Tip 3 için yeni öznitelik ekleme diye adlandırır.

Hangi alana hangi tip uygulanır?

Karar alan düzeyinde ve iş birimiyle birlikte verilir. Pratik bir eleme şöyledir: • SCD Tip 1: Geçmişin bilinmesine gerek yok ya da eski değer hataydı. Yazım düzeltmesi, telefon formatı, yanlış girilmiş doğum tarihi gibi alanlar buna uyar. • SCD Tip 2: Raporlar olay anındaki durumu görmeli. Müşteri segmenti, bölge ataması, ürün kategorisi, fiyat listesi sınıfı gibi analiz için önemli alanlar buna uyar. • SCD Tip 3: Yalnızca bir önceki değere karşılaştırmalı bakmak yeterli. Örneğin yeniden yapılanma sırasında eski ve yeni bölge adının yan yana görülmesi.

Bir boyut tablosundaki her alan aynı tipte olmak zorunda değildir. Telefon numarası Tip 1, müşteri segmenti Tip 2 olabilir. Alan listesini çıkarıp her biri için geçmişi tutmanın iş değerini sor; değeri yoksa Tip 1 en ucuz çözümdür.

Tip 2 tablosu nasıl görünür?

Tip 2'de değişen her kayıt için yeni bir boyut satırı eklenir. Bu yüzden iş anahtarı artık satırı tek başına tanımlamaz; yedek anahtar (surrogate key) zorunlu hale gelir. Tabloya genellikle şu alanlar eklenir: geçerlilik başlangıcı, geçerlilik bitişi ve güncel satırı işaretleyen bir bayrak.

Örnek müşteri boyutunda aynı müşteri kodu birden çok satırda görünür:

customer_key | customer_code | city | valid_from | valid_to | is_current A-kayıt | M-örnek | İzmir | eski tarih | değişim tarihi | hayır B-kayıt | M-örnek | Ankara | değişim tarihi | açık (NULL) | evet

Olgu tablosuna satış yazılırken, satışın gerçekleştiği tarihte geçerli olan satırın yedek anahtarı kullanılır. Böylece eski satışlar İzmir satırına, yeni satışlar Ankara satırına bağlı kalır ve geçmiş raporlar sonradan değişmez.

Yükleme mantığı adım adım

Her dönemsel yüklemede kaynaktan gelen kayıtlar boyut tablosundaki güncel satırlarla karşılaştırılır. Mantık şöyle işler: • Kaynakta olup boyutta olmayan iş anahtarı: yeni satır eklenir, geçerlilik başlangıcı yükleme tarihi, bitiş açık bırakılır, güncel bayrağı evet olur. • İş anahtarı var ve yalnızca Tip 1 alanlarında fark var: mevcut satırlar (geçmiş satırlar dahil) üzerine yazılır. • İş anahtarı var ve Tip 2 alanlarında fark var: mevcut güncel satırın bitiş tarihi kapatılır, bayrağı hayır yapılır ve yeni değerlerle yeni satır eklenir. • Fark yok: hiçbir şey yapılmaz.

Farkı hızlı bulmak için Tip 2 alanlarının birleşiminden bir özet değeri (hash) üretip karşılaştırmak yaygın bir yöntemdir. SQL tarafında bu iş genellikle MERGE ifadesi ya da dönüşüm aracının hazır anlık görüntü (snapshot) özelliğiyle yapılır; hangisinin kullanılabildiği veri ambarı ürününün güncel belgesine bağlıdır.

Geçmişe doğru sorgu nasıl yazılır?

Tip 2 boyutlu şemada farklı okuma biçimleri vardır. Olgu tablosu yedek anahtar üzerinden bağlandığında sorgu olay anındaki durumu otomatik verir; ek bir tarih filtresine gerek kalmaz. Müşterilerin bugünkü şehre göre dağılımını görmek istiyorsan boyutu güncel bayrağıyla filtrelemek yerine iş anahtarı üzerinden güncel satırı bulup olguyu ona yeniden eşlemen gerekir; bunun için boyut tablosunun yanında güncel görünüm (view) hazırlamak iyi bir alışkanlıktır.

Tek başına bir boyut tablosunda belirli bir tarihteki durumu görmek için şu filtre kullanılır: sorgu tarihi, geçerlilik başlangıcına eşit ya da büyük ve bitişten küçük olmalıdır, açık bitiş değeri ise sonsuz kabul edilir. Bu koşulu her analistin elle yazması yerine tek bir görünüme koymak hata riskini azaltır.

Sık yapılan hatalar

En sık hata, tüm tabloya tek tip uygulamaktır: her şeye Tip 2 uygulamak boyutu şişirir ve gereksiz satırlar yaratır, her şeye Tip 1 uygulamak ise geçmiş raporları sessizce değiştirir.

Diğer tekrar eden sorunlar: • Tarih aralıklarının kesişmesi veya boşluk bırakması. Bir satırın bitişi ile sonrakinin başlangıcı aynı mantıkla tanımlanmalı. • Yükleme tarihi ile işlemin gerçek geçerlilik tarihini karıştırmak. Kaynak sistem değişikliğin ne zaman olduğunu veriyorsa onu kullan. • Çok hızlı değişen alanları Tip 2 yapmak. Sık değişen öznitelikler ayrı bir küçük boyuta taşınmalıdır. • Yedek anahtar yerine iş anahtarıyla birleştirme yapmak; bu, olgu satırını yanlış sürüme bağlar.

Yükleme sonrası otomatik testler ekle: her iş anahtarı için tek güncel satır olmalı, geçerlilik aralıkları örtüşmemeli.

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

Bu konu, veri ambarında tarihsel doğruluk sorumluluğu taşıyan veri mühendisleri ve raporlama modelcileri için günlük iştir. Boyutsal Modelleme ve Kimball Metodolojisi eğitimi, Tarihsel Takip ve Değişim Yönetimi modülünü ayrı bir konu olarak işler.

Veri Mühendisliği Programı ise aynı mantığı ELT tasarımı, veri kalitesi ve test modülleriyle birleştirir; yani yukarıdaki yükleme kurallarının otomatik testlerle güvence altına alınması yönüne taşır.