Slowly Changing Dimension Nedir?

Dimension (boyut) kavramı veri ambarlarında kullanılan bir terimdir. Özetle; analiz edeceğimiz verilerin nasıl, bir başka deyişle neye göre görüneceğini belirttiğimiz niceliklerdir. Mesela şirketinizin gelir – gider durumunu incelemek istiyorsunuz diyelim. Bu rakamları yıllara, iş yaptığınız bölgelere, ürünlerinize yada bunların hepsine göre analiz etmek istiyorsunuz. Buradaki -e göreler, sizin verilerinizi nasıl analiz edecek olduğunuzdur ve bunların her birine dimension denir.

Ralph Kimball ilk olarak Slowly Changing Dimension (yavaş büyüyen boyutlar) kavramını ortaya attığında yıl 1996′ ydı. SCD kısaca sahip olduğunuz dimensionların bir bölümünün yada belki tamamının tam olarak yavaşça değişmesidir ve bu değişimin ne zaman olacağını bilememeniz durumudur. Herhangi bir zamanda gerçekleşebilir. Şirketinizdeki satış temsilcilerini ele alalım. Bir satış temsilciniz 2012 yılında İstanbul bölge müdürlüğünüzde işe başlamış olsun. 2013 yılı sonunda Ankara şubenizde çalışmak üzere lokasyon değiştiriyor. Şirket satışlarınızı bölgelere ve yıllara göre analiz ediyorsunuz diyelim ki; böyle bir durumda bu satış temsilcisinin bölgesi neresi olmalı? Aslında cevap çok basit; her ikiside! Sadece Ankara olarak bakarsanız 2013 yılında İstanbul’ da yapılan satışları Ankara’ da yapılmış gibi görürsünüz ki tam burası yanlış yaptığınız yer olur. Aynı şekilde sadece İstanbul’ da diyemezsiniz. İlk akla gelen çözüm bu satış temsilcisi için veri ambarına 2 farklı satış temsilcisiymiş gibi kayıt girmek olur. Bu noktada da eğer kaynak sistemden bağımsız integer surrogate key’ ler kullanılmamışsa baya büyük bir krize bile yol açabilir.

Veri ambarı tasarımı yaparken işleri kolaylaştırması, hatalara düşülmemesi için farklı tiplerde SCD metodolojileri geliştirilmiş durumda. Bunlar Type 0‘ dan başlayarak Type 7‘ a kadar çeşitlendirilmiş. Geriye sizin için uygun olan çözümü bulup uygulamanız kalıyor.

Type 0: Orijinal değeri hiç bir şekilde değiştirmiyoruz. Bu kolona gelecek değişikleri kabul etmediğimiz durumlarda Type 0 diyoruz.

Type 1: Var olanın üzerine yazıyoruz. Mesela müşterilerinizin telefon numaralarını tutuyorsunuz. Bir müşterinin telefon numarası değişti diyelim ki, böyle bir kaydı tarihsel olarak tutmaya gerek olmadığına karar verildi (bu kararlar daha çok business tarafından verilir.) sizde var olan telefon numarasının üstüne yeni geleni update edersiniz.

Image

Type 2: Bu tipte olan dimensionlarda tarihsel verileri tutabilirsiniz. 2 şekilde bunu yapabilirsiniz. Satış temsilcisi örneğini düşünelim. Satış temsilcisinin bölgesi değişirse farklı bir surrogate key kullanarak tabloya ikinci bir kayıt girmelisiniz. Ayrıca CurrentRecord gibi bir kolon oluşturarak şu andaki geçerli olan kayıtları saklarken aynı zamanda bunların geçmişini de saklamış oluyorsunuz.

Image

Bir başka yaklaşımda tabloda EffectiveDate ve ExpirationDate gibi kolonlar bulundurmak. Son gelen kayıt için EndDate set edilmeyebilir yada ileri bir tarih set edilebilinir (9999-12-31). Böylelikle şu andaki geçerli kayıt ve onun geçmişini de tutmuş oluyoruz. NULL olan değerler indexlere dahil edilmezler. Bu nedenle EndDate alanını NULL bırakmamak indexlemede performansımızı artıracaktır.

Type2_2

Type 3: Type 2 için tabloya satır eklemiştik. Burada da kolon ekliyoruz. CurrentRecord gibi bir kolon ekleyerek hem Orijinal değeri hemde şu andaki değeri saklamış oluyoruz. Type 3‘ de sınırlı sayıda tarihsel veri saklayabiliyoruz.Image

Type 4: Bir dimension içerisinde sıkça değişen attribute’ lardan Mini-Dimension tablosu oluşturularak elde edilir. History tabloları olarak da bilinirler. Detay seviyedeki tabloda genel seviyedeki tablonun değişen alanları tutulur.

Image

Type 5: Type (4 + 1) olarak da bilinir. Type 4 ile Type 1‘ ın birleştirilmiş halidir diyebiliriz. Type 4‘ a ek olarak detay seviyedeki en son gelen kaydı bir başka tabloda saklar. Detay seviyedeki tabloya gelen her kayıt için şu andaki kaydı tuttuğumuz bu tabloyu güncelleriz.

Image

Type 6: Bir diğer hibrit metodolojidir. Type (1 + 2 + 3) olarak bilinir. Type 1, 2 ve 3‘ deki yaklaşımları birleştirir. Type 2‘ da olduğu gibi CurrentRecord (Current Row Indicator) ve EffectiveDate gibi kolonlarımız var. Type 3‘ de kullandığımız gibi şu andaki değeri tuttuğumuz kolonu (Historic Department Name) oluşturuyoruz. Son olarak Type 1‘ de yaptığımız gibi yeni gelen her değerle birlikte ilgili kolonu (Current Department Name) güncelliyoruz.

Image

Type 7: Type 2 olarak sakladığınız bir dimension tablonuz var. Bu tablo direkt olarak ilgili Fact tablosuna foreign key üzerinden bağlı olmalı. Type 6‘ de olduğu gibi şu andaki (Current) değerleri bir başka tabloda tutuyoruz. Bu tablo ile ilgili dimension tablosuda yine birbirleriyle ilişkilendirilmiş durumda olmalı. Şu andaki kayıtları tuttuğumuz tabloyu bu sefer ilgili Fact tablosuna bağlıyoruz. Current değerleri tuttuğumuz tablo hem dimension hemde Fact tablosuna bağlı olduğu için bu metodoloji Dual Type olarak da bilinir.

Image

Uygulanabilecek çok fazla metodoloji var gibi görünse de temelde tip 1, 2 ve 3′ ü bilmek yeterli olacaktır. Diğer hibrit tipler karışıklığı önlemek ve kolaylığı artırmak için birbirinden türetilmiş tiplerdir.

Reklamlar
Bu yazı Data Warehouse içinde yayınlandı ve , , , olarak etiketlendi. Kalıcı bağlantıyı yer imlerinize ekleyin.

One Response to Slowly Changing Dimension Nedir?

  1. Geri bildirim: Slowly Changing Dimension bildiğiniz gibi değil | Veri Yönetimi Departmanından Haberler

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s