Dimension yani boyut kavramı veri ambarlarında kullanılan bir ifadedir. Yani; analiz edeceğimiz verilerin nasıl, bir başka deyişle neye göre görüneceğini belirttiğimiz niceliklerdir. Örneğin; şirketinizin gelir – gider durumunu incelemek istiyorsanız rakamları yıllara, iş yaptığınız bölgelere, ürünlerinize yada bunların hepsine göre analiz etmek istiyebilirsiniz. Buradaki -e göreler, sizin verilerinizi nasıl analiz edecek olduğunuzdur ve bunların her birine dimension (boyut) 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.
Resim-1
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.
Resim-2
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.
Resim-3
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. 
Resim-4
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.
Resim-5
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.
Resim-6
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.
Resim-7
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.
Resim-8
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.
Referanslar
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
