Veri ambarı boyutlarında ‘business key’leri anahtar olarak neden kullanmamalıyım?


Veri ambarı tasarımlarında yapılan önemli hatalardan birisi, business key olarak adlandırılan OLTP kaynak sistemdeki primary key’leri boyutlarda aynen kullanmaktır.

Aslında bir yandan mantıklı geliyor. İlgili nesneyle ilgili bir anahtar sistemim zaten var, veri ambarında da aynısını neden kullanmayayım?

Neden kullanmamanız gerektiğiyle ilgili 3 sebep size:

– Boyut tablosu tek bir veri kaynağından beslenmiyor olabilir. Şu an tek bir kaynaktan besleniyor olsa bile ileride beslenmeyecek olabilir. Şöyle bir durum düşünün mesela: Satış verilerini bir uygulamadan alıyorsunuz ve iş zekası projesi geliştiriyorsunuz üzerine. Ürün boyutu yapacaksınız. Ürün boyutunda ID olarak satış kaynak sistemindeki ID’yi kullandınız. Bir sene kadar sonra bu iş zekası çözümüne üretim tarafını da eklemek gerekti. Üretim verileri ayrı bir kaynak OLTP sisteminde. Üretimin fact’lerini oluştururken, ürün boyutuna yine bağlamanız gerekecek. Üretim verileriyle satış verilerini karşılaştırabilmek için de aynı ürün boyutuna bağlamanız gerekecek. Bu durumda ürün boyutunu beslerken her iki kaynaktan beslemeniz gerekecek. Ya kaynak sistemlerde business id’leri çakışan iki ürün gelirse? Eğer DW keyleri kullanıyorsanız, sorununuz yok. Kullanmıyorsanız…

– İkinci sebep: OLTP kaynaklarından gelen business key’leri GUID gibi çok yer kaplayan veri tiplerinde olabilirler. Bu durumda onları almayacak mıyız peki? Alacağız, ama boyutun içine attribute olarak. Key olarak kendi oluşturduğumuz DW keyleri kullanacağız? Ne fark eder? Boyuttaki bir kaydı ifade etmek için bir kere kullanılsa da, ilgili kolon değeri fact tablosunda yüzbinlerce, milyonlarca hatta yerine göre çok daha fazla satırda tekrar ediyor olabilirler. Boyutta attribute olarak tanımlanan bir kolon bundan etkilenmeyecektir. Ama boyutta key olarak tanımlanan kolon, fact tablosunda da foreign key olarak geçeceğinden yüksek sayıda satırda bize fena etki edecektir. Böyle anahtar bir kolonun diyelim int seçilmesiyle smallint seçilmesi arasında sadece 2 byte fark vardır. Ama yaklaşık 1 milyon satırda bu 2 byte fact tablosunda 2 MB eder. 1 Milyar kadar satırda ise 2 GB eder.

– Üçüncü ve belki en önemli sebep: OLTP kaynak sistemleri genelde unutkandırlar. Verilerin eski halleri tutulmaz. Oysa veri ambarı sistemlerinin tarih içindeki değişimi de takip edebilmesi ve raporlayabilmesi beklenir. Bu da boyut satırlarının tarihçesi takip edilmek istenen kolonlar için farklı versiyonlarının oluşturulmasını gerektirir. DW keyleri kullanmadan bu senaryoyu yaşatamazsınız.

Bu yazı MS İş Zekası, Veri ambarı içinde yayınlandı ve , , olarak etiketlendi. Kalıcı bağlantıyı yer imlerinize ekleyin.

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 )

Google fotoğrafı

Google 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 )

Connecting to %s