slowly changing dimension etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
slowly changing dimension etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

21 Ağustos 2011 Pazar

Surrogate Keys ve Slowly Changing Dimension - 1

Bilindiği gibi veri ambarları fact ve dimension tablolaran oluşur.Veri ambarına aktarılan bilgilerin mümkün olduğunca ilgili,minimum verilerden oluşması gerekmektedir.Veri tipi optimizasyonuda veri ambarı oluşturulması sırasında önemli bir konudur.Şöyleki transactional veritabanından alınan ana veriler ve idler olduğu gibi veri ambarına aktarılırsa veri tipi optimizasyonu es geçilmiş olur.














Örneğin,ürün idsi (item_code) olarak transactional veri tabanı (OLTP) üzerinde char (10) kadar yer kaplasın ve bunun gibi maksimum 1000 adet ürün olduğunu düşünelim.Ürün dimension tablosunda char yada int olarak
durmasının fazla bir esprisi olmayacaktır.Bize alandan yer tasarrufu yapacak kısım fact tablosudur.Bir fact tablosuna bu ürüne ait hareket kayıtlarını tutarken char(10) kadar bir alan kaplayan alan kullanırsak 1 milyon kayıtta 10 bayt*1 milyon byte sadece 9,5 mb gibi yer kaplayacaktır.Eğer bunun yerine dimension tablomuzda int bir identity alan tanmılayıp referans olarak bu idyi fact tablosuna atsaydık 4 byte * 1 milyon = ~3.8 mb yer kaplayacaktır.

Şöyle dediğinizi duyar gibiyim.Depolama sistemleri çok gelişti ve mb hesabı yapmayın diyebilirsiniz.Bu kayıtları milyarlarca olabilieceğini,indexlemenin eklenmesiyle ek maliyetlerin gelebileceğini,fact tablosunda başka dimension referans id lerinin geleceğini göz ardı etmemek gerekir.

Başlangıçta bu tür optimizasyonlar  düşünülmez fakat daha sonrasında veriambarına ait veritabanımızın boyutu terabaytlara ulaşınca başta yapmamız gereken optimizasyonları sonradan yapmak zorudan kalabiliriz.

Sonuç olarak surrogate keys veriambarlarında kullanılması gereken bir concepttir.Kodlama yaparken de yük getireceğini düşünmüyorum.

Yöntem:

Ürnü bilgilerinin aşağıdaki gibi saklandığı dim_item tablosu olduğunu düşünelim.Auto increnmental (otomatik olarak artan) olarak tanımlandığını varsayıyorum ki kesin olarak her tabloda tekilliği (unique) sağlayan alan olmalı.Item_code ise oltp'den gelen id olsun.


DIM_ITEM
IDITEM_CODE
1D90*500478
2D90*500479
3D90*500480
.


Satışların tutulduğu fact_sales tablosunun içinde ürün referans olarak aşağıdaki gibi D90*500478 alınması yanlıştır.


FACT_SALES
ITEM_IDTRANS_DATEQTY
D90*50047821.08.20116
D90*50047921.08.20115
D90*50048021.08.201112



Bunun yerine dim_item tablosundaki id kolonu fact tablosuna kaydedilmelidir.Gerek duyulduğundan dimesion tablosu ile join edilerek D90*500478  bilgisine ulaşılabilir.


FACT_SALES
ITEM_IDTRANS_DATEQTY
121.08.20116
221.08.20115
321.08.201112

Bu tip bir veri aktarımını query yardımı ile yada etl tool olarak kullandığınız platformdaki dönüştürücülerle yapabilirsiniz.

Query ile :

insert into fact_sales (item_id,
                                trans_date,
                                qty)
select                    dim_item.id,
                             tmp_sales.trans_date,
                             tmp_sales.qty
   from tmp_sales
inner join dim_item on dim_item.item_code = tmp_sales.item_code
 
Microsoft  ETL çözümü integration services ( ssis ) için slowly changing dimesion ile bu dönüşümü kolayca yapabilirsiniz.Sonraki yazıda slowly changing dimesion kullanımını anlatacağım.