Veri Ambarı ve İş Zekası Yapısal Teorisi

SQLBI Methodology: (Özellikle Microsoft İş Zekası teknolojileri alanında isim yapmış iki danışman olan Alberto Ferrari ve Marco Russo’nun kurduğu şirkette bedava olarak yayınlanan elektronik bir kitap. Bu kitap genel teoriyi anlamamda ve bir metodoloji kurmamda bana en çok fayda sağlayan kaynaktır.)

1. The Data Warehouse Lifecycle Toolkit, 2nd Edition:� İş zekası ve veri ambarı ile ilgilenen herkesin mutlaka okuması gereken temel bir kitap. Kitabın yazarıRalph Kimball 1980’lerde veri ambarı yapısını ilk geliştiren isimlerden biridir. O günden bu güne yazıları ve kitapları veri ambarı dünyasına yön vermiştir.

Yukarıda görmüş olduğunuz yapıyı 6 katmana ayırabiliriz. Bu katmanlar veri’den bilgiye (analize) doğru bir geçis olarak görebiliriz. Bu geçiş sırasında veri yapımız farklı gereksinimlerden kaynaklanarak değişiklik gösteriyor. Teknik olarak her katmanı� ETL katmanı ile ayırıyoruz.

Çok karıştırmadan katmanları açıklamak istiyorum;

1. Source Systems (Kaynak Sistemler)
2. Mirror Layer (Ayna Katmanı)
3. Staging Layer (Kademe Katmanı)
4. Data Warehouse Layer (Veri Ambarı Katmanı)
5. OLAP (Online Analytical Processing) (Bunu türkçeye çevirmesi zor açıkcası ben kısacası Küp Katmanı demek istiyorum)
6. Data Access Tools (Bu katman aslında sadece verinin görüntülenmesini sağlayan programlardan oluşuyor.)

1. Source Systems (Kaynak Sistemler):

Kaynak sistemler, kurumdaki hali hazırda çalışan bilgisayar sistemleridir. Bunlar muhasebe programından, döküman yönetimine, ERP veya özelleştirilmiş uygulamalar olabilir. Bu sistemler genellikle birbirlerinden bağımsız çalışan sistemlerdir. Kısacası muhasebe sisteminin verisini özelleştirilmiş bir uygulamanın kullanması pek kolay değildir ve çoğu kez kullanmaz da.

Kurumlarda gördüğünüz yapılar genellikle birbirinden ayrı çalışan sistemler içinde bir sürü veritabanı şeklindedir. Fakat çoğu kez kurumlarda uu sistemlerin içlerinde ne tuttuklarını tam olarak bilen bir çalışan bulmak zordur. O yüzden üst düzey yöneticilerden bir rapor için veri istenildiğinde BT departmanı bunu genellikle günü kurtaracak çözümlerle bir Excel dökümanı halinde vermeği seçer. Excel dökümanının artısı, çoğu yönetici Excel kullanmayı iyi bilir hatta bazıları BT derpartmanındakilerden de iyi bilir. Ama excel dökümanı veriyi içersinde sakladığı için bir veriyi siz excel dökümanına yüklediğiniz anda o veri eskimeye başlar. Bunun nedeni operasyonel sistemlerin sürekli durmadan veri üretmesidir.

Gün sonunda gelinen durumu şu şekilde özetleyebilirim; şirketlerde büyük kaynaklar harcanarak alınmış olan uygulamalar vardır fakat bu uygulamaların çoğu birbirleriyle bilgi alış verişi yapamaz ve küçük bir rapor ihtiyacı için dönüp dolaşıp yine Excel’in ellerine düşülür. Burada Excel’in kötü veya kullanışsız bir uygulama olduğunu düşündüğüm fikri çıkarılmasın, sadece bu senaryo içersinde Excel’in bu şekilde kullanılması bana çok taş devri geliyor. Ek olarakda sizce de bu kadar para harcanarak oluşturulan uygulamaların sonuçlarını almak bu kadar zor olmalı mı ? Sonuçta ne diye bu uygulamalara dünyanın parasını veriliyor, bunlardan daha hızlı ve doğru sonuçlar alınması için.

İşte Kaynak Sistemlerden bahsettiğim bunlar, kendi başlarına çalışan veritabanları veya özelleştirilmiş uygulamalar.

2. Mirror Layer (Ayna Katmanı):

Ayna Katmanı adından da anlaşılacağı gibi kaynak sistemlerinin aynası görevini yapar. Bir başka değişle kaynak sistemlerinin veri tabanlarının kopyasını olduğu gibi veri ambarının Ayna katmanına alırız. Bağlı olan bütün kaynak sistemleri veritabanları için bunu yaptığımız zaman Ayna Katmanında elimizde bütün sistemlerin bir kopyası olmuş olur.

Bu konu içersinde çalışan arkadaşlardan bazıları şöyle düşünebilir, böyle birşeye ne gerek var sadece SQL sorgumuzu verelim ve bize sorgumuz karşılığında gelen veriyi tutalım. Bu da bir yaklaşım tabi, fakat bu yaklaşımda ki en büyük sorunlardan biri eğer birçok SQL sorgunuz varsa ve aslında bu sorgular içersinde kullandığınız SQL tablolarınız ortak ise o zaman her sorgu için karşıdaki kaynak sisteminizi birden çok çalıştırıyorsunuz demektir.

Deneyimlerimden gördüğüm, kaynak sistemler genellikle operasyonel sistemlerdir ve zaten belli bir yoğunluk düzeyleri vardır. Siz buna ek olarak her sorgu için sürekli olarak bu sistemlerden veri çekmeye çalıştığınızda hem kaynak sistemleri yorarsınız hemde alacağınız veriyi daha uzun sürede alırsınız.

Bütün tabloları kopyalamamızın diğer bir sebebi de, ileride karşılaşabileceğimiz ihtiyaç değişiklikleridir. Önceden hazırlanmış SQL sorguları ile sadece ihtiyaç duyduğunuz veriyi aldığınız zaman, elinizde sadece o anda ki ihtiyaç duyduğunuz veri olur ama ihtiyaçlarda en küçük bir değişiklik olduğu zaman (emin olun olucaktır) ilgili bütün sorguları baştan değiştirmeniz gerekir.

Genel olarak Ayna Katmanının sahip olması gereken özelliler ve yapısı bu şekildedir;

• Kaynak Sisteminin kopyasıdır.
• Kaynak Sistemdeki veritabanı yapısını korur. (Star Schema ise Star Schema,� Snowflake schema ise Snowflake)
• Her ETL döngüsünde sıfırlanır.
• ETL döngüsü içersinde veri büyüklüğüne göre Incremental (Artan) yükleme yapılır.

Özet olarak Ayna katmanını ne kadar Kaynak Sistemlerinin kopyası olarak tutabilirseniz, ileride çıkabilecek değişikliklere karşı o kadar esnek olursunuz.

3. Staging Layer (Kademe Katmanı):

Kademe katmanı, en komplike olan katman dersek yalan olmaz. Veri üzerinde yapılması gereken bütün operasyonları bu katmanda gerçekleştiririz. Veri Kalitesi, Veri Yapısının Değiştirilmesi, Veri Teklilleştirilmesi gibi birçok operasyonu bu katman içersine koyabiliriz.

Temel olarak Ayna katmanında olan birbirinden bağımsız birçok veritabanını SQL sorguları ile istediğimiz yapılar içersine sokuyoruz. Tabi bu SQL sorguları çapraz veritabanları arasında çalışan sorgularda olabilir. Aslında burada Ayna katmanında olan operasyonel veritabanlarımızı ihtiyacımız olan İş Süreç odaklı veri yapılarına çeviriyoruz. Şimdi diyeceksiniz İş Süreçli veri yapısı nasıl oluyor ?

Şu şekilde anlatabilirim sanırım, operasyonel veri yapılarında veri kavramlara göre tutuluyor. Örnek olarak, bir çalışanın bilgileri Personnel tablosunda tutulurken o çalışanın hangi saatler arasında çalıştığı TimeSheet tablosunda tutulabilinir. Ama bu bilgiler Muhasebe departmanını ilgilendirdiği kadar İnsan Kaynakları departmanınıda ilgilendirebilir. Fakat İnsan Kaynaklarını ilgilendiren Performans verileri Muhasebe Departmanını ilgilendirmez. Burada bahsettiğim Muhasebe ve İnsan Kaynakları’nın her biri aslında bir iş sürecidir. Biz veri yapılarımızı vari ambarında şekillendirirken İş Süreçleri bazında şekillendirirsek, her odak grubunun kullanacağı yapıyıda oluşturmuş oluruz. Böylece ortada karışık bir sistemden çok odaklanmış küçük veri yapıları oluşur, bu sayede asıl amacımız olan hızlı raporlama hedefine çok daha rahat bir şekilde ulaşmış oluruz.

Veri Kalitesinin düzenlenmesi sürecini biraz açmak gerekirse, örnek olarak Ayna katmanından  aldığımız adres bilgisinde bazı girdilerdeki Şehir boş bırakılmış veya bir girdide “istanbul” yazılmışken diğerinde “İSTANBUL” yazılmış. Burada yapmamız gereken Şehir içersinde olabildiğince boş bıraklılmış alanın olmaması ve İstanbul’un sadece tek bir şekilde yazılmış olmasıdır.

Veri Tekilleştirilmesi aslında hakkında birçok özelleştirilmiş sistem bulunan diğer bir kavramdır. Fakat genellikle Kademe Katmanında elimizden geldiğince veri tekilleştirilmesi yapmaya çalışıyoruz. Kısaca veri tekilleştirilmesini anlatmam gerekirse; bir çalışan birbirinden bağımsız çalışan birçok sistemde olabilir. Örnek olarak benim ismin Muhasebe sisteminde Can Atuf Kansu iken İnsan Kaynakları sisteminde Can Kansu olarak gözükebilir. Burda ki soru bu verileri toparlarken kaç tane Can var ? Acaba Can ve Can Atuf isminde iki ayrı kişi mi var yoksa aslında ikiside aynı kişi sadece İnsan Kaynakları sisteminde göbek adı yazılmamış mı ? Bu gibi durumşların tesbitinde ve çözülmesinde birçok yöntem vardır ama Kademe Katmanında elimizden geldiğince bu tür ikilemleri çözmeye çalışmalıyız. Hala çözemediğimiz ve bizi rahatsız eden veriler varsa Microsoft’un Master Data Services gibi ürünler ile bu soruna daha kökten bir çözüm arayabiliriz.

Kademe katmanındaki yapmamız gereken operasyonlarımız bittiğinde verimiz bir sonra ki katman olan Veri Ambarı katmanının yapı ve kalite olarak aynısı olmak zorundadır. Veriyi Veri Ambarı katmanına attıktan sonra üzerinde hiç bir şekilde değişiklik yapamayız. Bu sebeple Kademe Katmanında yapacağımız bütün değişiklikleri yaparız ve veriyi bir sonra ki katman için hazır hale getiririz.

Kademe Katmanının amaçlarını özetlemek gerekirse;

• Verileri İş Süreçleri üzerinde odaklamak. (Bu kavrama biz� Data Mart yani Veri Marketi diyoruz.)
• Gerektiğinde Veri Kalitesi sorunlarını çözmek.
• Gerektiğinde Veri Tekilliği sorunlarını çözmek.
• Verinin veri ambarındaki en son katman olan Veri Ambarı katmanının yapısının aynısı haline getirmek.
• Verinin büyüklüğüne göre Incremental yani Artan yükleme yapılır ama her ETL dögüsünde bu katmanı sıfırlamak gerekir.

4. Veri Ambarı Katmanı:

Veri ambarı katmanı Veri Ambarı yapımızın en son katmanıdır. Bu katmana geçiş, Kademe Katmanını ne kadar doğru şekilde yapabilirsek o kadar kolay olacaktır. Kademe katmanında bahsettiğimiz bütün hazırlıklardan sonra bu katmana geçiş yapılır. Geçiş genellikle Incremental (Artan) şekilde yapılır. Bir başka değişle bugün aldığımız verileri dünkü verileri silmeden dünkü verilerin sonuna ekleriz böylece elimizde hem dünün hemde bugünün verisi olmuş olur. Bu sayede Veri Ambarı katmanı sürekli olarak büyür. Bu büyümede veri ambarına tarihsel analiz yapabilme özelliği sağlar.

Bu katman her ETL süreci bittiğinde kullanıma hazır olur, böylece kurumun bütün sistemlerinden gelen verileri temizlenmiş ve düzenlenmiş bir format içersinde bütün kurumun kullanımına açılmış olur.

Veri Ambarı Katmanının genel özellikleri şu şekildedir;

• Tablo ve kolon isimlendirmeleri son kullanıcının anlayacağı biçime getirilmiştir.
• Artan bir şekilde yükleme yapıldığı için tarihsel veri barındırır.
• Star Schema yanı Yıldız şema yapısı kullanır.
• İş süreçlerine odaklanarak verileri gruplar.

Veri ambarının en temel özelliği, kurum içersinde bütün sistemler ve raporlar için tek doğru bilgi kaynağı yaratmış olmasıdır. Eskiden bir rapor alırken birden çok farklı sisteme bağlanıp her sistemdeki verinin doğruluğunu onaylamadan raporlar içersinde kullanmaya çalışırken. Veri ambarı sayesinde kalitesi ve doğruluğu onaylanmış veri üzerinden rapor hazırlanabilinir. Bu sayede hem BT departmanı, kullanıcılara doğru ve kaliteli bilgi verdiğinden emin olabilir hem de farklı kullanıcılar farklı zamanlarda çekilen raporlarda veri farklılıkları yaşamazlar bu sayede BT departmanına olan güven artmış ve rapor hazırlama süreside azalmış olur.

5.OLAP (Online Analytical Processing) (KÜP Katmanı):

OLAP teknolojisi veri ambarından aslında tamamen farklı bir konudur. Fakat genellikle OLAP sistemleri bir veri ambarının üzerine kurulur. Bu sebeple bende şirketlerde kullanılan süreç bazında gittim ve OLAP’ı veri ambarının üzerinde ek bir katman olarak ele almaya karar verdim. Burada önemli olan OLAP’ın bir zorunluluk olmamasıdır. Bu konuyu biraz daha detaylandıracağım zaman anlayacaksınız fakat OLAP olmadan da Veri Ambarı kullanılarak iş zekası yapılabilinir.

OLAP teknolojisini açıklamak gerekirse;� RDMS sistemlerini bilenler bunu daha iyi anlayacaktır. RDMS’de yeni bildiğimiz SQL veritabanlarında, hesaplama gereken bir bilgi biz sorguyu çalıştırdığımız zaman hesaplanır. Örnek olarak, eğer biz şirketimizde çalışan personelin sayısını öğrenmek istiyorsak buna uygun bir SQL sorgusu hazırlarız ve çalıştırırız. SQL biz bu sorguyu çalıştırdığımız anda ilgili tabloya gider ve personelleri baştan sona kadar sayar ve bize sonucu geri getirir. Bu küçük sistemlerde çok hızlı gerçekleşsede büyük veri tabanlarında uzun süre alabilir. Bu gibi durumlar ile başa çıkabilmek için OLAP teknolojisi geliştirilmiştir.

OLAP teknolojisinde önceden belirtiğimiz sayaçlara göre bütün gelebilecek sorulara karşı cevaplar hazırlanır. Örnek vermek gerekirse, eğer biz personel sayısını merak ediyorsak OLAP’a daha tasarım aşamasında böyle bir ihtiyacımız olduğunu ve zamanı geldiğinde bu soruyu soracağımız belirtiriz. OLAP’da bunu üzerine personel sayısını gelebilecek her türlü soru tipine göre önceden hesaplar ve hafızasına kayıt eder. Soru tipinden bahsettiğim örnek olarak, 2012 yılındaki personel sayısıdır. Siz eğer OLAP’a “ben senden sene bazında personel sayısını isteyebilirim” derseniz oda elinde olan veriler doğrultusunda hazırlayabildiği her senenin personel sayısını hesaplar ve kayıt eder. Siz herhangi bir zaman 2012 yılındaki personel sayısını istediğiniz zaman, OLAP sadece rafdan hazır olan bir yemeği alıyor misali, daha önceden hesaplanmış bu bilgiyi size sunar. Bu sayede sizin bekleme süreniz büyük bir şekilde düşmüş olur.

Bu konuyla ilgili iler ki zamanlarda daha detaylı bir yazı hazırlamayı düşünüyorum. Ama genel olarak yukarıda bu teknolojiyi anlatabildiğime inanıyorum.

6. Data Access Tools:

Bu katman teknik olarak uygulamalardan oluşmaktadır. Bu uygulamalar gerek veri ambarı olsun gerek OLAP olsun bu katmanlardaki veriyi sorgulayarak anlaşılır raporlara dönüştürür. Veri ambarı sorgulamalarında genellikle detaylı tablo raporları kullanılırken, OLAP sorgularından zaman bazlı grafiksel analizler çıkartılır.

Bu katmanda önemli olan iş ihtiyacınıza göre gereken doğru ürünü seçmektir. Birkaç örnekle sanırım bunu daha iyi anlatabilirim;

• Eğer ihtiyacınız : “Ben X ve Y tarihleri arasında yapılan satışların detaylı dökümünü istiyorum.” ise size veri ambarını sorgulayabilen ve detaylı tablosal rapor hazırlayabilen bir uygulama gerekir. Örnek olarak: Microsoft Reporting Services.
• Eğer ihtiyacınız: “Ben bu seneki Nisan ayı ile geçen senelerdeki Nisan ayı içersinde yapılan satışların satış temsilcisi ve sene bazında dağılımlarını görmek istiyorum” ise  size OLAP teknolojisini kullanabilen grafik hazırlama özellikleri gelişmiş bir uygulama gerekir. Örnek olarak: Microsoft Power View veya Panorama Necto

Bu uygulamardan pazarda birçok çeşit vardır. Bütçenize ve ihtiyaçlarınıza en uygun olan uygulamayı bulmak detaylı bir araştırma ve satın alma süreci gerektirir. Benim kendi deneyimlerimden öğrendiğim bir kaç ders var, şu şekilde;

• Alacağınız uygulamanın ne yapabildiğinden öte ne yapamadığıda önemli
• Alacağınız uygulamanın desteğini kim verecek, Türkiye’de yaygın bir çözüm ortağı yapısı var mı yoksa daha çok yurt dışına bağlı bir destek mü alacaksınız.
• Alacağınız ürünün güncellemeri için tekrar yatırım yapmak zorundamısınız
• Alacağınız ürünün benzer özelliklerde olan ürünü sizin hali hazırda yapmış olduğunuz lisans anlaşmaları içersinde yer alıyor mu ? Alıyorsa belki boşu boşuna para harcayacaksınız. Asıl soru benim elimde ne var ?
• Alacağınız ürünü çalışırhale getirmek için başka yatırımlar yapmanıza gerek var mı ?
• Alacağınız ürünü şirketinize kurduğunuz zaman kendi BT departmanınızdan teknik hizmet alabilecek misin ? Alamayacaksanız BT elemanlarına öğretebileceğiniz bir eğitim programı var mı ? Varsa bu eğitim programı sonunda elemanınızdan ne kadar bir hizmet bekleyebilirsiniz ?
• Alacağınız ürünün lisanslaması nasıl gerçekleşiyor ? Kullanıcı başına mı yoksa Server başına mı ?
• Tam olarak size ne kadara mal olacağını bilmeniz gerekiyor bu da elinizdeki bütce ile ilgili tabiki.

Bu listeye daha birçok kalem eklenebilinir ama benim için iş zekası ve raporlama uygulamalrına spesifik olarak üstünde durulması gereken sorular bu şekilde.

Evet, kısaca elimden geldiğince veri ambarı yapısının nasıl olması gerektiğini ve buna uygun OLAP ve Raporlama Uygulamalarının ne şekilde kullanılması gerektiğini anlatmaya çalıştım. Bu yazı üzerinde ilerki günlerde güncellemeler yapabilirim çünkü mutlaka atladığım veya daha iyi anlatabileceğim bir çok konu olduğunu şimdiden hissediyorum.

Sizinde eğer bu konu hakkında kendi düşünceleriniz ve deneyimleriniz varsa paylaşırsanız memnun olurum.