"Ralph Kimball - The Date Warehouse Toolkit" dan notlar - 1

Kimball'ın modeli, son kullanıcının çok zorlanmadan kullanabileceği ama en önemlisi rahat ve kolay geliştirilebilecek bir tasarım yapmak üzerine kurulu. İşte "The Data Warehouse Toolkit" kitabından birkaç not.

• "Presentation area", ilişkisel veri tabanına bağlı ise bu boyutlu(dimensional) modellenmiş tablolara "star schema" denir. "Presentation area", multidimensional bir veritabanı veya OLAP'a bağlı ise, data küplerde saklanıyordur.
• İşin gereksinimlerine odaklan ve modelini ona göre kur, veri yapına göre değil.
• Kolay development'a odaklan.
  
• En iyi özellikler (attribute) metin olanlarıdır.
• Dimension tabloları, denormalize edilmiş tablolardır.
  
• Hiyerarşik veri tutan tabloları denormalize etmek ve bu tür tablolarda "snowflake schema" dan kaçınmak gerekli.
• Kullanıcıya atomik data vermek gerekmese bile, datayı atomik seviyede tutmakta fayda var.
• Dimension veya fact tablolarına yeni bir attribute eklemek gerekirse, eski tarihli datalar için bu attributelere verinin olmadığına dair anlamlı bir bilgi yaz.
• Fact tablolarında en detayda oranlar değil, toplamlar olsun. Daha sonra toplamların oranını al, oranların toplamını değil.
  
• DATE dimension tablosu tanımla. Bu tablo veri tarihçesinin tutulmasını ve raporların kolay alınmasını sağlayacak. Date tablosundaki anahtar alan tarih tipinde değil, bir integer. Bunun integer olmasının ararlarını daha sonra göreceğiz. Date dimension içerisinde, raporlarda kullanılabilecek ve zaman ile ifade edilen her türlü şey olabilir. Günün adı (pazartesi, salı vb) , Satış sezonu (İlkbahar - yaz, sonbahar - kış), ayın kaçıncı günü, yılın kaçıncı günü, tatil gibi. Date Dimension Tablosunun Alanları : "Date Key, Date, Day of week, Month, Year, Quarter, Full Date Description, Day number in calendar month, Day number in calendar year, Sales Season" gibi olabilir.

Kaçınılması gereken sık rastlanan tuzaklar :

• İş 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 presentation 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ı içeren 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, analitiğinin ve 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.