1 Nisan 2010 Perşembe

Google DocVerse 'i satın aldı.

 Google, DocVerse'i satın aldı. Cloud Computing'in en yaygın örneklerinden biri olan Google Docs artık DocVerse'in sağladığı paylaşım özellikleri ile daha da güçleneceğe benziyor. 


Artık sadece online dosyalarımızı değil, bilgisayarımızdaki dosyalarımızı ve klasörlerimizi de  google docs'a yükleyip, cloud computing nimetlerinden faydalanabileceğiz. 



Google Docs'daki dökümanlarımızı desktop'da rahatça kullanabilmemiz için de memeo isimli bir uygulama yazmış google.
Google Docs'u aktif olarak kullanmaya başlayınca senkronizasyon ve yedekleme ihtiyaçlarımız da doğacak tabii ki. Bunun için de syncplicity uygulaması imdadımıza yetişiyor.

Google, gelecek Cloud'da diyor ve bununla ilgili yatırımlarına devam edecek gibi görünüyor. Bakalım, gelecekte neler olacak?




Google'ın DocVerse'i almasıyle ilgili haberi google'ın blog'ından okuyabilirsiniz : http://googleenterprise.blogspot.com/2010/03/google-docs-welcomes-docverse.html

29 Mart 2010 Pazartesi

Kimball'dan Veri Ambarı Geliştirme Önerileri

Ralph Kimball, The Data Warehouse Toolkit isimli kitabında, yeni bir veri ambarı geliştirirken dikkat edilmesi gereken tuzaklardan bahsetmiş.
İşte Kimball'ın önerileri :
  • İş gereksinimleri ve amaçlarına odaklanmak yerine teknoloji ve dataya takılmayın.
  • Veri ambarı işini destekleyenlerin makul bir yönetim vizyonuna sahip olmaması veya işi yeterince sahiplenmemesi sorun olabilir.
  • Kolay yönetilebilir, ilgi çekici devam edecek proje yerine, çok büyük, yıllar sürecek ve çaba gerektiren projeler ile mücadele etmeyin.
  • Dimensional modellere dayanan kullanışlı bir görsellik yaratmadan, normalize edilmiş veri yapılarına enerji harcamayın.
  • Arka plandaki operasyonel performans ve geliştirme kolaylığından fazla, ön yüzün kullanım kolaylığı ve performansına önem vermeyin.
  • Belki sorgulanabilir diye, görsel katmanı fazla karmaşık yapmayın. Veritabanı tasarımcıları, karmaşık sorgular yerine, kullanıcıların basit ihtiyaçlarını karşılarlar ise daha fazla takdir edilirler.
  • Ortak, birbirine bağlanabilen dimension tablolarından oluşan veri mimarisi yerine tek başına kullanılabilecek dimension tablolarından oluşan yapılar kurun.
  • Görsel alandaki dimension yapılarına sadece özet data yükleyin.
  • Bir işin gereksinimlerinin, altındaki verinin ve işin yapıldığı teknolojinin statik olduğunu varsayın.
  • Veri ambarının başarısının kullanıcının işi benimsemesiyle ilgili olduğunu unutmayın. Kullanıcı, veri ambarını karar vermenin temeli olarak kabul etmezse tüm çabalarınız boşa gider.

Inmon ve Kimball'ın Data Warehouse Modellemeleri

Mary Breslin, data warehouse modellemenin iki babası Kimball ve Inmon un modellerini karsilastırdığı bir makale yazmış. İşte makalenin kısa bir özeti

Inmon'un yaklaşımı, klasik ilişkisel veritabanı araçları ve yöntemleri kullanılarak yapılan "top-down development" üzerine kurulu.

Inmon, data warehouse'u daha büyük bir bilgi ortamının bir parçası olarak görüyor. Bu büyük bilgi ortamına da CIF (Corporate ınformation Factory) adını veriyor. Data warehouse'un daha büyük ortamlara iyi uyum sağlaması için, bir atomik bir de birimlere özel veri tabanı olması gerektiğini savunuyor.

Inmon'ın yöntemleri sadece IT uzmanları tarafından aktif olarak kullanılabilir durumda. Son kullanıcılar geliştirme aşamasında aktif rol oynamıyor. Kısacası Inmon'un yaklaşımı daha teknik bir yaklaşım.

Operasyonel (Transactional) sistemlerde işlenen veri, gerekli şekillerde düzenlenerek (Bu işleme ETL deniyor) atomik veritabanına taşınıyor. Her bir departman için, ihtiyaca göre ayrı bir veritabanı tasarlanıyor ve bu veritabanları temel verileri atomik veritabanından alıyor. Böylece departmanların aldıkları raporlar arasında veri uyumsuzluğu sorunu olmuyor.

Kimball'in yaklaşımı ise geleneksel veritabanı tasarım metodlarından farklı. "Bottom - up" yaklaşımı ile her iş süreci için ayrı bir data mart oluşturmayı tavsiye ediyor. Tüm bu data mart ların toplamı ise kuruluşun data warehouse U oluyor. Çeşitli data mart'lar arasında iletişim kurmak için de "data bus" dediği ve tüm data Mart'ların standarta uygun veri boyutları ile modellenmesini gerektiren bir mimari öneriyor.

Verinin son kullanici tarafindan daha rahat anlasilmasi ve performans nedeniyle Normalizasyon kurallarının gecerli olmadigi Dimensional veri modeli tasarimlarda çok merkezi rol oynuyor. Dimensional modelde iki çeşit tablo oluyor. Fact tablolar, çok fazla satırdan olusan ancak buna karşılık az kolon içeren foerign key ve metrik ölçüm dısında bir veri tutmayan tablolara deniyor. Dimension tablolar ise fact tablolardaki verinin detaylarını ve ozelliklerini tutan tablolar ve fact e göre daha az satır içermelerine rağmen yüzlerce kolondan oluşabiliyorlar.

Inmon ve Kimball' in modellerinin benzer noktaları da var.Her ikisi de farklı yöntemlerle de olsa zaman özelliği tutmak gerektiğini savunuyor. Her iki model de verilerin transactional sistemden aktarılırken standartlastirilmasi ve düzenlenmesini oneriyor (ETL)

Hangi modelin kullanılacağı tamamen ihtiyaclara ve isin yapısına göre verilecek bir karar.


Makeleyi okumak için : http://www.bi-bestpractices.com/view-articles/4768