Merhaba Arkadaşlar,
DWH işinde, özellikle modelleme yaparken, kaynak sistemdeki arkadaşlara bir mimari kurduğumuzu anlatmak sıkıntılı bir iş. Kendileri webservise iki parametre geçtiği için, dwh etkisini de bu şekilde düşünüyorlar. :)
Girizgahı savunma-vari şekilde yaptıktan sonra, konumuza gelelim: Surrogate Keys(vekil anahtar imiş Türkçesi).
Malumunuz, OLTP sistemlerde genelde normalize tutulan verileri incelediğimizde, genelde bir primary key olduğunu görebilirsiniz. Bu kimi zaman bir sequence, kimi zaman bir timestamp, kimi zaman bir kombinasyon(işlemtarihi-000-kurum kodu-işlem tipi-seq vb) olabiliyor. Tıpkı OLTP sistemlerde olduğu gibi, Veri Ambarı dünyasında da bir surrogate key kullanımı mevcut. Surrogate Key'ler genelde herhangi bir anlam içermeyen, sequental yapıdaki numeric alanlardır.
Peki kaynak sistemlerde bir business key varken(ki ona natural key de diyoruz), neden bir daha SK üretiyoruz?
İlk belirtmemiz gereken neden, kaynak sistemlerdeki bu business key'ler(natural key), o sistem içinde bir anlamı olabilir. Örneğin bir şahıs şirketidir. Key olarak TCKN tutuyordur. Ancak sonrasında mevzuat değişmiştir, artık VKN(vergi no) almıştır kendisine. Dolayısıyla datanın şekli şemali tipi vs değişebilir. Bu kaynak ile ilgili bir durum. Absürt örnek vereyim, TCKN yerine de 'bjk1903' gibi bir değer de tutabilirler. Bunu izlemek, değişimleri yönetmek sıkıntı. Üstüne üstlük, bu keyin geçtiği, join kurduğu tüm alanları bulup dwh'te düzeltmek zorunda kalabilirdik. Bu nedenle business key'leri genelde string bir data tipinde tutup, karşılığında SK değer üretmek mantıklıdır.
Bunun dışında bir diğer neden de, az önce de yazdığım üzere, bus,ness key olarak, upuzun bir kombinasyon tutulabilir. Tabi bu şekilde çok fazla yer kapalayacaktır. Dolaylı olarak performans etkisi yaratacaktır. SK ile hem yerden tasarruf edecek hem de performans sorunu yaşamayacaksınız.
Belki de kritik bir sıkıntı daha da şu: kaynakta, örneğin transactionı fazla olan yapılarda, belli bir süre sonra, truncate edilip, bu natural key'ler en baştan başlatılabilir. Bu çok riskli bir durumdur. DWH data dilmeyip, history'i saklama konusunda hassastır, malumunuz. Bu şekilde büyük işlem karmaşaları ortaya çıkabilir.
Bunun gibi nedenlerden ötürü, kaynak(operasyonel) sistemlerden çekilen tablolar için, veri ambarında genelde bir SK değeri üretilir.
Sonra görüşürüz.
Hiç yorum yok:
Yorum Gönder