Dimensional Modelling Tipleri

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