ODI ile Slowly Changing Dimension Uygulaması

OLTP sistemlerde update gören bir satırın önceki haline ulaşmanın çok zor olduğu açık. Peki bir önceki hali de değil istediğim bir anda o satırın durumu neydi desem, iş iyice içinden çıkılmaz bir hal alıyor gibi. Pek tabii OLTP’de de bunu sağlayacak bir altyapıyı kurmak mümkün ama bu OLTP için hem ekstra yük(her açıdan) hem zahmetli hem de biraz gereksiz bir iş. Onun için tam da bu noktada devreye veri ambarı ve kaçınılmaz olarak da Slowly Changing Dimension metodu giriyor.

Bir tabloyu SCD olarak saklamak için birden fazla yol, bu yolları kullanmak için de PL/SQL, T-SQL dahil kullanabileceğiniz birden fazla araç var. Biz burada tahmin edebileceğiniz gibi bu işi ODI üzerinde nasıl yapabileceğimize yoğunlaşıp bir örnekle de daha anlaşılır olmasını sağlamaya çalışacağız.

ODI, SCD uygulamaları için güçlü bir platform sunar. ODI'nin sunduğu bu özellikleri kullanarak, veri ambarı projelerinizde SCD uygulamalarını kolaylıkla gerçekleştirebilirsiniz.

Elimizde personel bilgilerinin saklandığı bir tablo olduğunu düşünelim;

CREATE TABLE OLTP.PERSONEL ( PERSONEL_ID NUMBER NOT NULL PRIMARY KEY, AD VARCHAR2(50 BYTE), SOYAD VARCHAR2(50 BYTE), BIRIM_ID NUMBER );

personel bilgileri özellikle birim, ünvan gibi bilgileri sık sık değişebilecek verilerdir ve bir personelin şu andan 4 ay önce veya 2 yıl önce hangi birimde olduğu bilgisi önemli bir bilgidir. Bu bilgiye ulaşmak için hedef tablomuzda ekstra bir kaç kolona daha ihtiyaç duyuyoruz.

CREATE TABLE KDS.PERSONEL_SCD ( PERSONEL_SK NUMBER, PERSONEL_ID NUMBER, AD VARCHAR2(50 BYTE), SOYAD VARCHAR2(50 BYTE), BIRIM_ID NUMBER, BAS_TAR DATE, BIT_TAR DATE );

Hedef tabloya eklediğimiz BAS_TAR ve BIT_TAR kolonlarımızın eklenme sebebine değinelim;

Örneğin A personeli 2005 yılından 2009 yılına kadar Yazılım birimindeydi, 2009’dan beri ise AR-GE biriminde.

OLTP tarafında 01.01.2009 yılına kadar;

şeklinde görürsünüz. Dolayısıyla DW tarafındaki tabloya tarih parametresiyle gittiğiniz takdirde personelin hangi tarihte nerede olduğu bilgisine ulaşmanız artık çok kolay. Ve bu kolaylğı bize sağlayan BAS_TAR ve BIT_TAR kolonları. (kolon isimleri opsiyonel :))

Yukarıdaki örnekte sizin de şimdiye kadar farketmiş olacağınız gibi artık PERSONEL_ID kolonunun uniqueliğinden bahsedemeyiz, dolayısıyla yeni bir unique kolona ihtiyacımız var(Surrogate Key) ve bu da PERSONEL_SK.

Hem kaynak hem de hedef tablonun oluşturulup ODI modeline alındığını varsayarak SCD interface’ini hazırlamaya başlayabiliriz.

İlk olarak hedef tablo PERSONEL_SCD’yi modelden açıp kolon editörüne geçip Description kısmından Slowly Changing Dimension Behavior değerlerini set etmemiz gerekiyor.

Bizim Örneğimizde; PERSONEL_SK = Surrogate Key, PERSONEL_ID = Natural Key, AD, SOYAD, BIRIM_ID = Add Row On Change, BAS_TAR = Starting Timestamp, BIT_TAR = Ending Timestamp değerlerini almalıdır.

Yeni interface ekranı açıp tanımlama kısmını tamaladıktan sonra Mapping sekmesine geçip tablolarımızı ilgili yerlere sürükleyebiliriz. eğer kolon isimlerini değiştirmediysek yeni eklediğimiz kolonlar hariç diğerlerini ODI otomatik olarak eşleştirecektir.

Surrogate Key alanı değerini bir sequence’ten almalıdır. Kullanacağımız sequence’i ODI üzerinde tanımladıktan sonra Surrogate Key alanının mappingine SEQUENCE_ADI_NEXTVAL yazabilirsiniz. Yine mapping kısmına BAS_TAR için SYSDATE, BIT_TAR için çok ileri bir tarih verelim. Mappingimizin son hali aşağıdakine benzer olmalıdır.

Mapping aşamasını tamamladıktan sonra Flow sekmesine geçip kullanacağımız SCD Knowledge Module’ü seçebiliriz. Veritabanımızın oracle olduğunu varsayarak IKM Oracle Slowly Changing Dimension‘u seçtim. (Yoksa import edebilirsiniz)

Modülü seçip (basit kullanım için) Flow Control seçeneğini false değerine set ettikten sonra interfac’i kaydedebiliriz.

Interface’i ilk çalıştırdığınızda tüm kayıtların o anki değerini o ank tarihle SCD tablosuna atar. Test etmek için kendi örneğimizde kaynak tabloya iki kayıt ekleyip interface’i çalıştırdıktan sonra hedef tabloyu kontrol edelim.

INSERT INTO OLTP.PERSONEL (PERSONEL_ID, AD, SOYAD, BIRIM_ID) VALUES (157, ‘SUNA’, ‘SEYHAN’, 1);

INSERT INTO OLTP.PERSONEL (PERSONEL_ID, AD, SOYAD, BIRIM_ID) VALUES (441, ‘BÜLENT’, ‘ŞEN’, 1);

Interface ilk kez çalıştıktan sonra hedef tablo (KDS.PERSONEL_SCD);

kaynak tablodaki kayıtlardan birinin üzerinde bir güncelleme yapıp interfacei tekrar çalıştırdığımız zaman neler olduğunu görelim.

UPDATE OLTP.PERSONEL SET BIRIM_ID = 45 WHERE PERSONEL_ID = 147;

Update işlemi ve devamında interface’i tekrar çalıştırma sonucu oluşan hedef tablo;

Görülebileceği gibi update gören satırı çokladı ve kaydın hem eski hali hem de yeni hali saklanıyor. Örneğin ID değeri 157 olan personelin hangi tarihte hangi birimde olduğu bilgisine tarih parametresiyle ulaşabiliriz. İyi çalışmalar.