Home / MAKALELER / Veri Ambarı / Dimensional Modelling Tipleri

Dimensional Modelling Tipleri

Dimensional Modelling hakkında notlar – The Data Warehouse Toolkit

1) SCD oluşturulurken Surrogate Key gerekliliği  (Surrogate key; certain need for SCD Type 2)

SCD Type 2 hazırlarken natural key ile birlikte değişen alanları da alan surrogate key oluşturmak en iyi yöntemdir.
Production Employee Table
           
Emp_no Emp_name Start_date End_date Department Manager
1 Smith 01/01/10 IT 0
2 Tiger 01/01/10 Sales 0
*Updated as 1
DWH Employee Dimension
             
Surrogate_key Emp_no Emp_name Start_date End_date Department Manager
1 1 Smith 01/01/10 IT 0
2 2 Tiger 01/01/10 01/01/13 Sales 0
3 2 Tiger 01/01/13 Sales 1

Yukarıdaki örnekte emp_no=2 için manager=1 olarak update edilmiş, dwh sisteminde bu değişikliği tutmak istiyoruz, dwh da natural key i dimension için PK olarak kullandığımızı düşünürsek, unique liği sağlamak için manager ve/ya başlangıç, bitiş tarihlerini fact tabloya eklememiz gerekecekti. Fact tabloda sadece natural key kullanılırsa bu çalışanın değişikliğini takip edemeyiz, çalışan departman değiştirmiş olabilirdi, departman değişikliğinde örneğin bütçe hesaplamasında bu çalışanın maliyet merkezi değişmiş olacak ve biz takip edemeyecektik.. Surrogate key kullanımıyla fact tabloda tarih veya ikincil alanlar kullanılmasına gerek kalmaz. OLTP sistemden gelen başlangıç/bitiş tarihlerine dayanılarak oluşturulması yine yanlış sonuçlara neden olabilir. Çalışanın işten ayrılma tarihi değişikliği karşılamadığı için boştu. Bu dimension için departman ve yönetici flaginden surrogate key oluşturulması en doğru sonucu verir.

2)Alternate Reality

SCD Type 3, aynı satırda geçmişi ve kaydın son halinin görüntülenmesini sağlar, buna alternatif gerçeklik (alternate reality) denir. Örnekte çalışanların işe girişte başladıkları departman ve şu an çalıştıkları departman aynı kayıtta görüntülenebilir. Geniş aralıkta değişen bir segment tanımlandığında müşterinin segment değişimini  ilk ve son segmentine göre tek satırda sorgulayabilmek etkin olacaktır.

Production Employee Table
           
Emp_no Emp_name Start_date End_date Dept Manager
1 Smith 01/01/10 IT 0 *Upd as SAP
2 Tiger 01/01/10 Sales 1
DWH Employee Dimension
             
Surrogate_key Emp_no Emp_name Start_date End_date First_Dept Current_Dept Manager
1 1 Smith 01/01/10 01/02/13 IT IT 0
2 2 Tiger 01/01/10 01/01/13 Sales Sales 0
3 2 Tiger 01/01/10 Sales Sales 1
4 1 Smith 01/01/10 IT SAP 0
3)Role Playing with Dimensions
Bir dimensionın bir facte aynı anda farklı rollerle birden fazla bağlanmasına dimension role playing denir.Aşağıdaki factte ürünlerin sipariş ve satış tarihleri tutuluyor. Dim_time tablosu view ile çoğaltılarak facte order_date ve sales_date alanlarından farklı dimensionlar olarak bağlanıyor.



4) Junk Dimensions

Bir datawarehouse için optimum dimension sayısının 5-15 arasında olması tavsiye ediliyor. Flagler için birer dimension oluşturulması dimension sayısını çok arttırabilir, fakat gereklidir. Flag dimensionları tek veya ilgili bir kaç dimension da birleştirmek fact alan sayısı ve dimension sayısı olarak, ayrıca bakım için kolaylık sağlayan bir çözüm olabilir.

customer_flag_id country sex sales_first
1 domestic female new
2 domestic female old
3 domestic male new
4 domestic male old
5 domestic female new
6 domestic female old
7 domestic male new
8 domestic male old
9 abroad female new
10 abroad female old
11 abroad male new
12 abroad male old
5)Large Changing Dimensions(Demographics)

Customer gibi sıklıkla değişen özelliklere sahip büyük tabloları SCD Type 2-3 ile değişiklikleri takip etmek ve bakımını yapmak zorlaşır. Bu tip tablolara Rapidly Changing Monster Dimension 🙂 denmiş. Sıklıkla değişen özellikleri alıp ayrı bir dimension oluşturmak bir çözüm olabilir.Yaş, gelir, şehir gibi değişebilen alanlar ,customer dimension ında tutulması yerine, aralıklar tanımlayarak aşağıdaki gibi bir dimension oluşturulur.

Demographic Key Age Country Income(TL)
1 20-25 TR 1000-3000
2 25-30 TR 3000-5000
3 25-30 Other

Yaş, ülke ve gelir bilgileri için alt ve üst sınırlar ayrı alanlarda verilerek daha fazla detay alınabilir. Fact tabloda customer_key ve demographic_key tutularak factten customer key üzerinde değişen demographic_key lerin takibi yapılabilir.

6)Aggregate Tables

Sorgulama performansını arttırmak için aggregate tabloların kullanılması en basit ve en ucuz yöntemlerden biri olabilir. Kullanıcılar, genellikle geliştirme sırasında doğru dizayn ve başlangıçta yaptıkları testlerle veri ambarının doğru sonuçları getirdiklerine ikna olmuşlarsa sonrasında detayları sorgulamazlar. Production sistemden alınan günlük transaction ların veri ambarında datamartta aylık olarak sunulabilir. Kullanıcılara açılan ve genelde sorgulanan tabloların gözlenmesi ile detay ve aggregate tablolara giden sorgu sayıları elde edilebilir.

7) Factless Fact Tables

Ölçülebilir değerlerin tutulmadığı, dimension key lerin arasındaki ilişkilerin tutulduğu fact tablolarıdır. Bu tablolardan belli bir zaman aralığında değişen dimension keylerin sayıları gibi ölçümler elde edilebilir. Bu ölçümler çok karmaşık olmadıkça raporlama tarafında  elde edilebileceği için tekrarlayan değerlerin fact tabloda tutulmasına gerek yoktur.Aşağıdaki gibi bir fact tabloda aktiviteye kayıt olan ve katılan sayılarını count / count distinct ile elde edebiliriz.

Fact_activity
time_key
attendant_key
place_key
activity_status_key
attendant_status_key

 

 

Select time_key, activity_key, count(attendant_key)#Registrations, count(case when attendant_status_key=’A’ then attendant_key end) #Attendances From Fact_activityGroup by time_key, activity_key

 

About Jale Ozgur

PL/SQL , ETL, BI Developer

İlginizi Çekebilir

Udemy Online Veri Ambarı Eğitimi

Yoğun emekler sonucunda “Türkçe” Veri Ambarı Eğitimi Udemy’de yayın hayatına başladı.Ömür boyu erişim,soru cevap bölümleri …

Bir Cevap Yazın