Çok Boyutlu Veri Modellemede Uyulması Gereken 10 Temel Kural

Kimball metodolojisi içersinde benim de projelerimde çok kullandığım 10 temel adım vardır. Çok boyutlu bir veri modelleme (Multi Dimensional Data Modelling) yaparken bu temel adımları takip ederseniz, büyük ihtimalle yanılgıya düşebileceğiniz çoğu konuda size yardımcı olacaktır. Kendimden örnek vermem gerekirse ilk projelerimde karşılaştığım bütün ikilemlerin cevabını bu kurallar içersinde bulmak bana biraz komik geldi. Keşke bu kuralları o zaman fark etseymişim de, o projelerde o kadar zorluktan geçmeseymişim. Ama kim bilir belki o zorluklardan geçmeden de bu kuralların önemini hiç bir zaman anlamayacaktım.

TEMEL KURALLAR:

1. Çok Boyutlu Modellerinize olabildiğince detaylı veri yüklemeye çalışın:

Bu kural bana göre 1 numara olmayı fazlasıyla hak ediyor. Veri Ambarı ve İş Zekası Teorisi adındaki yazımda da Aynak Katmanında bahsettiğim gibi. Çok Boyutlu veri modelinize kaynak sistemlerden veri çekerken, olabildiğince detay çekmeye çalışın. İlk düşündüğünüzde bu kadar detaylı veriyi modelimiz içersine almak size biraz gereksiz ve performans açısından kötü bir seçim gibi gelebilir fakat ilerde müşterinin ne isteyeceğini veya gereksinimlerin değişmeyeceğini bilemezsiniz. Detayını düşürdüğünüz her model gelecektede o detay seviyesinde kalmaya mahkum olacaktır. Detayınızı olabildiğince yüksek tutup, gerektiğinde raporlama düzeyinde gruplama yapmak genel metodoloji olarak çok daha etkin ve sürekliliği olan bir çözüm olacaktır.

2. Veri Yapılarınızı mutlaka İş Süreçleri bazında kurun:

İş süreçleri firmalardaki aktivitelerdir. Örnek olarak bir kurum içersinde sipariş etmek, faturalamak gibi iş süreçleri olabilir. Her iş sürecinin ölçülebilir en az bir tane değeri vardır. Mesela sipariş de sipariş edilen ürün miktarı ve siparişin değeri olabilir. Bu sebeple doğal olarak her iş süreci bir Fact tablosu haline gelir ve veriler bu yapılar üzerinde tutulur.

Bazen bu iş süreçlerinden bazıları birleştirilerek tek bir Fact tablosu halinde getirilmesi gerekebilir, fakat burada dikkatli olunmalı ve  bu yapıyı detaylı Fact tablosu ile desteklenmeli. Gruplanmış Fact tabloları temel versiyonlarının ancak yardımcı bacağı olabilir, onların yerine geçmemelidir.

3. Her bir Fact tablosunun mutlaka bir Zaman boyutu ile ilişkilendirin:

Mutlaka hazırladığınız her Fact tablosunda Zaman boyutunu bir şekilde bağlayın. Fact tablosu gerek aylık toplam veriyi tutsun, gerek saniye detayında veri tutsun, mutlaka Zaman boyutu ile bağlanmış olması gerekir. Buna bağlı olarak Zaman boyutunuzu bütün şirketin anlayabileceği formatlarda hazırlayın, örnek olarak gün, ay, yıl yanında haftanın ortası gibi veya mali çeyrek gibi her departmanın anlamadığı zaman peryiodları koymaktan kaçının. Her zaman formatı onaylanmış belli bir standartda olan kavramları kullanın.

4. Her bir Fact tablosunun kendi içersinde aynı detay seviyesinde olduğundan emin olun:

Detay seviyelerinde üç temel kavram vardır, İşlem Bazında, Periyodik Durum ve Artan Durum. İşlem Bazında detay, örnek olarak her bir satış işlemidir. Her seferinde bir satış yapıldığı zaman o satış kayıtlara o şekilde geçer. Periyodik durumda ise işlemler günlük,aylık veya yıllık bazda hesaplanarak toplamlar olarak Fact tablosuna yazılır.  Periyodik durumun özelliği toplanabilir olmasıdır, bir sene içersindeki her aylık ödemeleri topladığınızda senelik ödeme toplamını bulabilirsiniz. Son olara da Artan Durum’da üst üste binen bir toplamı düşünebiliriz. Örnek olarak hesap bakiyesi düşünebiliriz. Bakiye verisini aylık olarak hazırlayabiliriz fakat üst üste toplayamayız. Herhangi bir Fact tablosu yaratırken tablo içersindeki verilerin bu üç detaydan sadece birine uygun olduğuna emin olmamız gerekir.

5. Many-to-Many ilişkilerden Fact tablolarında kurtulmalıyız:

Bildiğiniz gibi çok boyutlu star schema veri yapılarında many-to-many ilişkilerin olmaması gerekiyor. Many-to-Many ilişkiye bir örnek vermek gerekirse, bankacılık sektöründe bir müşterinin birden çok hesabı olabildiği gibi bir hesap birden çok müşteriye bağlı olabilir. Bu yapı RDMS sistemlerde sorun olmamakla birlikte Star Schema’yı benimsemiş Cok Boyutlu veri yapılarına geçtiğimiz zaman bize tasarımsal zorluklar yaratacaktır. Bu tarz durumlardan olabildiğince kaçınmalıyız ve eğer karşılaşırsak bunları Köprü Fact tablosu tabir ettiğimiz aslında hiç Measure’ları olmayan sadece iki adet fact tablosunu birbirine bağlamayan tablolar ile çözmeliyiz.

6. Many-to-Many ilişkilerden Boyut (Dimension) tablolarında kurtulmalıyız:

Boyut tablolarında many-to-many ilişkiler genellikle hiyerarşik yapıları tasarlarken karşımıza çıkar. Bu tarz durumlarda RDMS’lerde yapmaya alışkın olduğumuz Normalizasyona karşı olarak Denormalizasyon yapmalıyız. Cok boyutlu sistemlerde Boyut (Dimension) tablolarında Denormalizasyon kullanmalıyız çünkü Fact tablosu ile Boyut tablosunu bağlarken bize sadece bir seviye verilir. Bir boyut tablosundan başka bir boyut tablosuna ilişki kurdurmamalıyız.

7. Hertürlü isimlendirme ve kodlamayı Fact tablosundan çıkartarak Boyut tablolarına taşımalıyız:

Çok boyutlu sistemlerde Fact tabolarında karakter verisi olmaması önerilir. Sadece Satır Anahtarlarından (Row Key) oluşan kolonlar ve Zaman boyutunun anahtarları olmalıdır. Diğer bütün yazısal veriler Boyut tablolarına itilmeli, bunların içersinde hiyerarşi oluşturabilecek veriler varsa denormalizasyon yapılarak yapılar düzenlenmeli. Boyut tabloları anlaşılır yazısal verilerden oluşmalıdır ki bu sayede kullanıcılar rahatlıkla bunları filitre olarak kullanabilsinler.

8. Bütün Boyut (Dimension) tablolarının Vekil Anahtar kullanmasını sağlamalıyız:

Vekil Anahtar gerçekte Tekil Anahtarı (Unique Key / Primary Key) olan verilere tekrar bir Vekil Anahtar atanmasıdır. Bu sayede özellikle Slowly Changing Dimension kavramı rahatlıkla uygulanabilinir. Genel kanı eğer bir Boyut tablosu SCD değilse Vekil Anahtar (Surrogate Key) konulmaz. Fakat ilk başta ihtiyacınız olmasa bile tasarımınızı yaparken her Boyut tablosu için baştan bir Vekil Anahtarı atarsak ilerde çıkabilecek ihtiyaçlara veya ihtiyaç değişikliklerine hazırlıklı olmuş oluruz.

9. Boyutları olabildiğince ortak hale getirerek kurum içersinde genel bir Boyut havuzu yaratın:

İleriye dönük bir sistem yaptığımız için elimizden geliğince bütün yarattığımız Boyut tablolarını müşteri tarafından ortaklaşa kararlaştırarak şekillendirmeliyiz. Bu sayede hem müşteri tarafında kabul edilmiş bir Boyut yapısı olduğu gibi veri mimarisi olarak da Fact tabloları için ortak bir Boyut havuzu oluşturmuş olursunuz. Kurumun ortak iş süreçlerinin ortak Boyutlarını ortaya çıkararak, Kimball’ın ortaya koyduğu Kurumsal Veri Ambarı Veriyolu Matrisi‘ndeki genel amacıda gerçekleştirmiş olursunuz.

10. Sürekli olarak müşterinin gereksinimlerini dengede tutarak, müşteri tarafından da kabul edilmiş bir Veri Ambarı yapısı oluşturun:

Veri Ambarı tasarımcıları genellikle müşterilerin hiç bitmeyen istekleri ve teknik imkanlar arasında sıkışırlar. Burada önemli olan müşteriye anlamlı ihtiyaçların önemini anlatırken kompleks ve gerçekci olmayan ihtiyaçlar arasında bir daha düşünmeleri gerektiğini ve asıl ihtiyaçlarını detaylı bir şekilde anlatılmasıdır. Dikkat çekilmesi gereken konu günümüzde ki ihtiyaçlara cevap verebilen fakat ilerde önümüze çıkabilecek ihtiyaçlarada uyum sağlayabilecek bir yapı oluşturmaktır. Gelecekte önümüze çıkacak ve şu anda verisi olmayan yapılar için bugünden tasarımının yapılması doğru olmaz. Herzaman projelerinizi olabildiğince basit ve fazlara ayırarak yapmaya çalışmalısınız.

Reklamlar

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 )

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 )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s