Veri Ambarı Tasarımında Kaçınılması Gereken 10 Temel Hata
(4 votes, average: 4,00 out of 5)
Loading...Merhaba arkadaşlar. Kimball ve veri ambarı modelini daha önceden tanımıştık. Kimball ve arkadaşları, veri ambarı tasarımını optimize etmek için hem temel hem de gelişmiş teknikleri kapsayan kitabında veri ambarı tasarımında kaçınılması gereken 10 temel hata sıralaması yapmış. Ben bu yazımda bu hatalardan kaçın diyerek sadece veri ambarı tasarımı yapacak olanları hedeflemiyorum, tasarım yapmıyor olsak bile kaçınmamız gereken hatalar bizlere farklı fikirler verebilir veya zihnimizde bazı konuların önemini artırabilir.
Veri ambarı tasarımında kaçınılması gereken 10 temel hata listesi ters önem sırasına göre listelenmiş, fakat daha az önemli hataların bile daha karmaşık ETL sürecine yol açabileceği unutulmamalı.
En Yaygın 10 Temel Hata
Hata 10: Filtreleme ve gruplama için kullanılan metinsel özellikleri olgu (fact) tablosuna koymak.
Fact (olgu) ve dimension (hareket) tablolarını tanımlarken zaten bu özelliklerinden yararlanılır. İş sürecimizdeki sayısal ölçümler fact (olgu) tablosuna aittir, ölçümler bağlamında açıklayıcı metinsel ifadeler dimension (hareket) tablolarına aittir. Kesinlikle metinsel alanlar fact (olgu) tablosunda bulunmamalıdır.
Hata 9: Boyutlardaki geniş tarifli özellikleri yer kazanmak amacıyla kısıtlamak.
Boyutların ayrıntısını kontrol altına alarak muhafazakar bir tasarımcı olmak isteyebilirsiniz fakat her bir kolonu sadace bir kez değişecekmiş gibi ayrıntılı bir şekilde incelemekte fayda var. Boyut (dimension) tablolarındaki metinsel özelliklerin, BI uygulamalarında tarama, gruplama veya filtreleme gibi özellikler getirdiğini unutmayın.
Hata 8: Hiyerarşileri ve hiyerarşi seviyelerini doğru belirlememek.
Veri modelindeki hatalı boyutsal hiyerarşiler; analiz için gereken bilgileri almak, nitelik ilişkisi tutarsızlıkları oluşturmak ve hatta bazı analizlerin yapılması için aşırı karmaşık sorgular gerektirecektir.
Örneğimize bakalım. İki boyutlu tablolarımız var: yılın aylarını tutan dim_ay ve bir yıl içindeki haftaları tutan dim_hafta. (Şekil-1) İlişki çoktan çoğadır, çünkü her ay birkaç haftadan oluşur ve bir hafta iki ay içinde olabilir.
Şekil-1′ de görüldüğü gibi haftalardaki satış verilerinin toplamı, aylardaki satışların toplamından farklıdır, çünkü bazı haftalarda çakışma olabilir. Bu, bir hafta iki aya düştüğünde veya belirli aylar veri dönemimizde olmadığında gerçekleşebilir. Görüntülenen veriler doğru, ancak toplanamaz.
Bu hatanın oluşmaması için boyutları farklı hiyerarşilere bölmek gerekiyor. Şekil-3′ deki gibi bir çözüm modelinde birbirinden bağımsız iki hiyerarşi görüyoruz.
Hata 7: Boyutlarda yer alan özelliklerin (attribute) zamanla değişimlerini takip etme ihtiyacını göz ardı etmek.
İşletme kullanıcıları genellikle değişiklikleri boyut tablolarının özelliklerinin en azından bir alt kümesi üzerindeki etkisini anlamak ister. Üç temel slowly change dimension (yavaş büyüyen boyut) tekniği vardır. Benzer şekilde, bir grup öznitelik hızla değişiyorsa, daha alt seviyede detaylı nitelikleri yakalamak için bir boyutu bölebilirsiniz.
Hata 6: Sorgu performans sorunlarını doğrudan ve sadece daha fazla donanım ekleyerek çözmeye çalışmak.
Pahalı donanım eklemek, sorgu verimli DBMS (Database Management System) yazılımı seçme, bellek boyutunu artırma, CPU (Central Processing Unit) hızını artırma ve donanım düzeyinde paralellik ekleme gibi dengeli bir programın parçası olarak yapılmalıdır. Yani çözüm sadece burada aranmamalı ortak bir denge kurulmalıdır. Mesela çoğu BI aracı, aggregate functions (toplama fonksiyonları) kullanımı için açık bir desteğe sahiptir. Özetle aggregate functions (toplama fonksiyonları) veya türetilmiş özet tablolar sorgu performansını artırmanın uygun maliyetli bir yoludur.
Hata 5: Boyut (dimension) tablolarını fact (olgu) tablolarına bağlamak için natural key (doğal anahtar) veya operation key (operasyon anahtarı) kullanmak.
Natural key (doğal anahtar) tablo ile mantıksal olarak ilişkili olan veridir (TC kimlik numarası, IBAN numarası gibi). Dolayısıyla index boyutunu büyütmemek için tabloların bağlanmasında kullanılmaz. Surrogate key (yedek anahtar) ise veritabanı yönetim sistemleri tarafından üretilirler. (Oracle; sequence, Sql server; identity column gibi). 1′ den N’ ye kadar surrogate key (yedek anahtar) kullanılması önerilir ki buradaki N satır sayısıdır.
Hata 4: Fact (olgu) tablosunun ayrıntı düzeyini (grain) deklare etmeyi ihmal etmek ve ardından fact (olgu) tablosunun sahip olması gereken ayrıntı düzeyine (grain) her zaman sadık kalmamak.
Örneğin aşağıdaki gibi iki tane dimension (boyut) tablosu düşünelim.
Fact (olgu) tablosu, satış ölçümleriyle birlikte dim_urun boyutuna bağlı olsun. Soldan sağa doğru hareket ederek detaydan üst ayrıntıya gidelim. Yani detaydan çıkma (roll-up) yapıyoruz.
Şekil-5′ deki gibi farklı ayrıntı düzeyi (grain) tanımlandığında toplam değeri bizi yanlış sonuca götürdü. Forma ürününün kategorisinin belirtilmemiş olması bu hataya sebep oldu. Aynı şekilde detaya girme (drill-down) sorgularında yani üst kategoriden alt detaylara inerken de benzer hatayı alabilirdik. Her ikisinin çözümü için de alt detay veya üst detay girilmeli, eğer yoksa varsayılan bir değer eklenmelidir.
Hata 3: Belirli bir raporu esas alarak boyutlu modeli onun için tasarlamak.
Rapor merkezli bir şema tasarlamak yerine, ölçüm süreçlerine odaklanılması gerekiyor. Aksi takdirde yüzlerce fact (olgu) tablosu hazırlamamız gerekebilir.
Hata 2: Kullanıcıları en detay seviyedeki veriye erişim için normalize sistemlere yönelmek zorunda bırakmak.
En düşük seviyedeki veriler genelde çok boyutludur ve mutlaka boyutsal tasarımın temeli olmalıdır. Veri transferinden önce veri temizleme, veri kalitesini artırma, normalizasyon- denormalizasyon kurallarının oluşturulmuş olması gerekir. Çünkü verilerimiz ne kadar düzgün ve temiz olursa raporlarımız ve dolayısıyla kararlarımız da o derece doğru olacaktır.
Hata 1: Farklı fact (olgu) tabloları arasında boyutların (dimension) ve fact (olgu) kolonlarının ortak kullanımı ilkesine uygun davranmamak.
Farklı sistemlerden elde edilen iki veya daha fazla veritabanında gelir gibi sayısal değeri olan bir ölçüme sahipseniz, bu ölçümlerin teknik tanımlarının tam olarak eşleştiğinden emin olmak için özel dikkat göstermeniz gerekir. Tanımlar tam olarak eşleşmezse, ikisinin de gelir olarak adlandırılmaması gerekir.
Arkadaşlar bu yazımla modelleme serisini bitirmiş olduk. Tabi ki bunların dışında da çeşitli hatalar yapılabilir, fakat bu yaygın hatalar önceden hafifletilebilirse tasarımın başarılı olma şansı artar. Bir sonraki yazımda görüşmek üzere, hoşçakalın!
Kaynakça
http://aatinegar.com/wp-content/uploads/2016/05/Kimball_The-Data-Warehouse-Toolkit-3rd-Edition.pdf
![](https://www.veribilimiokulu.com/wp-content/uploads/2020/05/logo-e1590873495165.png"){kind=logo}