joomla templates Data Warehouse Türkiye

Thu09082011

Last update07:32:32 PM GMT

Back Kategoriler Data warehouse Data Modellemede hapınızı seçin! (Inmonism vs Kimballism)
Pazartesi, 10 Ocak 2011 10:48

Data Modellemede hapınızı seçin! (Inmonism vs Kimballism)

Yazan&Gönderen  Yusuf Arslan
Bu Öğeyi Derecelendir
(1 Oy)

Inmonism vs Kimballism

Inmon_vs_Kimball

Veri ambari olayının iki büyük üstadı: Bill Inmon, Ralph Kimball. Yıllardır sorulmaya devam eden soru: Hangisinin yaklaşımı daha doğru?

 

Inmon’in işaret ettiği yöntem, tarihsel derinliği olan, kalıcı, konu odaklı ve entegre bir yapı kurup tüm kurumsal veriyi burada depolamak. Bunu yaparken verinin normalize bir formda tutulmasını önemsiyor Inmon. Çünkü her bir verinin tek bir erişim noktasının olmasını sağlamak istiyor.(Single version of truth). Böyle bir yapıyla veri entegrasyonu sağlanmış oluyor.(Veri entegrasyonundan anlaşılan su olmalı: Birincisi, her türlü kaynaktan alınan veri tek bir ortamda ayni veri deseni altında toplanmıştır(Veri konsolidasyonu).İkincisi de, ulaşılmak istenen bilginin tek bir adresinin olması sağlanmıştır).

Bahsettiğimiz yapıdaki bir veri ambarından -normalize ve en atomik yapıda olmasından dolayı- veri çekmek zordur. Bu yüzden genel yaklaşım yalnızca bu veri ambarını kaynak olarak kullanan departmantal datamartlar gelistirmektir. Kullanıcı da bu datamartlar üstünden sorgularını çeker, analizini yapar. Bu şekilde merkezi bir veri ambarı ve bu veri ambarına bağlı datamartlardan oluşan mimariye hub-and-spoke mimarisi deniyor.

Kimball’in yaklaşımı ise merkezi bir ortamda ve ortak bir desende veriyi toplamadan, direk departmantal veya konu odaklı datamartlar geliştirmek ve bu datamartlari kullanıcının kullanımıma açmak seklindedir.
Bu yaklaşımda, veri ambarı dediğimizde oluşturulmuş datamartların tümünü anlamalıyız. Kimball’in yaklaşımında en önemli kavramlardan biri conformed dimension’lardır. Veri konsolidasyonunu sağlamak amacıyla ortak dimension ve measure’lardan oluşan bir katman(conformed dimensions) vardır ve bu katman tüm datamartlarda kullanılarak herhangi iki datamartın bu katman üzerinden konsolide edilmesi sağlanır.

Süreç açısından iki yaklaşımı karşılaştırdığımızda Inmon yaklaşımında ODS ve/veya staging alan üzerinden tüm kaynak sistem verilerini tek bir sistemde veriyi tekilleştirip ve konsolide edip toplamak sonrasında bu entegre sistem üzerinden ilgili datamartları geliştirmek varken; Kimball yaklaşımında yine ODS, staging alan üzerinden birbirinden bağımsız ama conformed dimensionlarla birbirine bağlanabilecek datamartlar geliştirmek vardır. Birincisinde, kaynaktaki veriler nasıl bir araya getirilir diyerek işe başlanırken, diğerinde iş ihtiyaçları nedir diyerek projeye başlanır.

Piyasada kullanırlıklarına baktığımızda çoklukla Inmon yaklaşımının uygulanıp hub-and-spoke mimari tasarlandığını görüyoruz. Bu yaklaşımı uygularken genelde vendorların, bu yaklaşıma uygun olarak tasarladıkları mantıksal veri modelleri kullanılıyor.

Peki hangi yaklaşım daha doğrudur?  Ben de “duruma göre değişir” genel kanaatine katılıyorum.  İki yaklaşımı kıyasladığımızda, birinde daha sağlam ama geç bir teslimat diğerinde ise hızlı ve isteklere cevap veren bir teslimat ama ileriye dönük olarak oluşabilecek entegrasyon sorunları muhtemeldir. Her ikisini de belli noktalarda diğerine yaklaştırıp riski azaltmak elbette mümkün. Inmon yaklaşımında, entegre yapının tamamen bitmesini beklemeden bittikçe teslimatlar sağlamak, Kimball yaklaşımında conformed katman üstünde yoğunlaşıp burada entegrasyon sorunlarını çözmek gibi. Ama şu kesin ki Inmon yaklaşımında biraz daha fazla sabır, biraz daha fazla üst yönetim desteği gerekli.

Bu soruya cevap verirken düşünmemiz gereken en önemli konu da aslında kaynak sistemlerimizdir. Eğer çok az sayıda kaynak sistemimiz varsa entegrasyon için teslimatları ertelemek mantıklı olmayabilir. Çünkü belirttiğim gibi entegrasyonun iki aşaması vardır. Veri konsolidasyonu: Zaten az sayıda kaynak sistem olduğundan küçük bir sorun. Veri Tekilleştirme/Normalizasyonu: yine zaten operasyonel sistemlerin doğası gereği normalize yapıları vardır ve kaynak sistem az olduğundan farklı yerlerde de veri çoğullanmamıştır. Dolayısıyla tek ya da az sayıda ve düzenli kaynak sistemi olan bir organizasyonda tekrardan bir katman oluşturmak yerine direk olarak datamartlar geliştirmek daha akılcı bir çözüm olabilir. Ancak çok sayıda kaynak sistemi olan bir organizasyonda da Kimball yaklaşımı bir süre sonra entegrasyon sorunlarını ciddi seviyelere çıkaracaktır.

Mantıksal Veri Modelleri:
Inmon yaklaşımını benimseyen organizasyonlar, genellikle IBM, Teradata, Oracle gibi vendorların sağladıkları mantıksal veri modelleriyle işe başlıyorlar. Bu veri modelleriyle kaynak sistemlerdeki hangi tip verilerin bir araya getirilip hangilerinin arasında ilişki tanımlanmalı gibi sorular cevaplanıyor. Kullanılıp kullanılmaması konusunda benim kanaatim, tüm modeller için olan kanaatimle paralel. Modellerin çoğunun çok faydalı olduğunu düşünüyorum ama hiç birinin herhangi bir organizasyonun ihtiyacını direk karşılayacağını düşünmüyorum. Modelleri bir analiz dökümanı gibi değerlendirip okumanın ve çıkarımlar yapmanın çok faydalı olacağı, çok önemli bir rehber olacağı kesin ama bir modeli ulaşılmak istenen son nokta gibi konumlandırmak çok yanlış. Bir organizasyon eğer tüm mantıksal tabloları birebir fizikselleştiriyorsa bu yanlışa düşmüş demektir. Adı üstünde mantıksal veri modeli. Mantıksal kalmalı, birebir fizikselleşmemeli.

kurumsalzeka.com

Son Düzenleme Pazartesi, 14 Şubat 2011 14:55
Yusuf Arslan

Yusuf Arslan

Oracle Open Source

Tokat/Reşadiye doğumluyum.İlk-orta-lise hayatını Amasya/Suluova ilçesinde geçirdim.Sakarya Üniversitesi Bilgisayar Mühendisliği bölümünü bitirdikten sonra kariyerime Turkcell  İş Zekası Test Uzmanı olarak devam etmekteyim. 

Website: arslanyusuf.blogspot.com/ E-posta: Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir

Login to post comments