Uzmanına Sor

Unified Dimensional Model

SQL Server 2005 ile birlikte Microsoft Unified Dimensional Model (UDM) adı
verilen yeni bir teknoloji sundu. UDM yapısı OLAP sisteminin sunduğu
multidimensional storage ve preprocessed aggregate’lar gibi avantajların
tümünden faydalanırken, klasik OLAP sistemlerinin dezavantajlarından korunmak
amacıyla tasarlandı.

Yapı

UDM bir data mart’ın üzerinde konumlandırılan ve son kullanıcı açısından OLAP
sisteminden hiç bir farkı olmayan bir yapıdır. Bu yapısına karşın UDM’in en
önemli avantajlarından biri aslında bir data mart’a gereksinim duymamasıdır.
UDM’i bir ya da daha fazla OLTP sistemini destekleyecek şekilde
tasarlayabiliriz. Aynı zamanda data mart ve OLTP sistemlerin bir arada bulunduğu
karma bir yapı da oluşturmanız mümkündür. UDM farklı veritabanı
sağlayıcılarından hatta XML formatındaki verilerden de faydalanabilmektedir.

UDM measure, dimension, hiyerarchy, hem star hem snowflake yapısındaki
küpleri hatta doğrudan OLTP sisteminden gelen tabloları barındırabilir. Bu esnek
yapı bir data mart tasarımı yapmadan business intelligence çözümleri
üretebilmemizi sağlasa da, bir data mart tasarımı yapmanın faydalı olduğu
durumlar elbette bulunmaktadır ki bu durumları ilerleyen bölümlerde detaylı
olarak ele alıyor olacağız.

Veri Kaynakları

UDM bir ya da daha fazla veri kaynağı tanımlaması ile başlar. Veri kaynakları,
UDM’e veri sağlayacak bir ya da daha fazla veritabanı bağlantısına ilişkin
bilgileri barındırır. Veri kaynağı sunucu adını, veritabanı adını ve kullanıcı
bilgilerini bir kaç ek bilgi ile birlikte kapsar. Oracle, MySQL gibi pek çok
farklı veritabanı sağlayıcısına bağlantı kurabilmemizi sağlayan farklı OLE DB
providerları bulunmaktadır. Bu sayede BI platformumuz SQL Server dışındaki
veritabanı sağlayıcılarından da faydalanabilmektedir.

Data View’lar

Veri kaynakları tanımlandıktan sonra kullanılacak tablo ve alanların
tanımlandığı data view oluşturulur. Data View’lar farklı veri kaynaklarından
gelen tablo ve fieldları bir araya getirebilir. Örneğin sipariş yönetim
sisteminden gelen tablolar, satış yönetim sisteminden gelenlerle
birleştirilebilir. Data View’ların sunduğu bu çoklu veri kaynağı desteği, UDM’in
ismindeki “Unified” ifadesinin temelidir.

Tablo ve fieldlar data view’a eklendikten sonra data view, veritabanında yer
alan ve gereksinim duymadığımız maddelerin filtrelenmesinde kullanılabilir. Data
View’a sadece BI çözümünde gereksinim duyulacak tablo ve fieldlar eklenir. Veri
kaynaklarındaki tablo yapısı değişmez. Data view, sonraki adımlarda nelerin
oluşturulabileceğini doğrudan yönetir.

Bu özellikle veri kaynaklarının çok büyük ve yüksek derecede normalizasyonun
söz konusu olduğuy OLTP sistemlerinde oldukça faydalıdır. Data View sadece
measure, dimension ve hiyerarchy’ler için gereksinim duyulan tabloları
kullanılabilir halde tutarak ihtiyaç duyulmayan verilerin oluşturacağı gereksiz
kalabalığın önüne geçer. Aynı şekilde tabloların içinde yer alan gereksinim
duyulmayan fieldlar görüntülenmez.

Data View’ı daha kolay anlaşılabilir hale getirmek için tablo ve fieldlarda
kullanıcı dostu isimler ve açıklamalar kullanılabilir. Bu metadata UDM’in
tümünde kullanılır. Bu fieldların kullanımı ile oluşturulan tüm measure,
dimension ve hierarchy’ler, bu kullanıcı dostu isim ve açıklamaları kullanırlar.

Ek olarak, data view’ı veri modeline sanal eklemeler yapmak için de
kullanabiliriz. Bu eklemeler, veritabanının kendisinde değil, sadece UDM içinde
yer alan sanal modelde oluşturulur. Bu sayede gerekli durumlarda bu eklemeleri
OLTP sistemine hiç bir müdahalede bulunmadan oluşturabilir, değiştirebilir ve
silebiliriz.

Sanal eklentilere örnek vermek gerekirse, veritabanında iki tablo arasında
tanımlanmamış bir ilişkinin tanımlanmasından bahsedebiliriz. Başka örnek ise
tabloya eklenecek hesaplanmış bir alan olabilir. Farklı veritabanlarından gelen
fieldlar ile yapılacak hesaplamalar ya da farklı fieldlardaki metinsel ifadeleri
kullanarak oluşturulan metinsel ifadeler, hesaplanmış alanları sıklıkla
kullandığımız noktalardan biridir.

Data View tamamlandıktan sonra, içeriği measure, dimension, hierarchy ve küp
oluşturma işleminde kullanıma hazırdır.

Şu ana kadar UDM ile BI modellemesinde 2 aşamadan bahsettik. Önce veri
kaynaklarını, sonrasında ise data view tasarımını gerçekleştirdik.

Proaktif Önbellekleme (Proactive Caching)

UDM, Geleneksel OLAP sistemlerinin sunduğu performans avantajını sağlamak için
preprocessed aggregate’ları kullanır. Yüksek erişebilirlik için bu preprocessed
aggregate’lar bir proactive cache’de tutulur.

Bu yapı sadece gerektiğinde oluşturulduğundan ve sadece kaynak veri modelinde
değişiklik olduğunda değiştirildiği için tercih edilmiştir. Kullanılan bu yapı,
IIS’in web sayfalarını önbelleklemek için kullandığı altyapıya oldukça
benzemektedir.

UDM caching mekanizmasının diğer caching mekanizmalarından ve IIS’te yer alan
caching mekanizmasından farkı, proaktif olmasıdır. IIS’te sayfa sadece ilk
erişimde cache’e aktarılır. İlk kullanıcı bu aktarım nedeniyle makul bir süre
beklemektedir.UDM’de ise, bir talep olması beklenmeksizin caching
gerçekleştirilir. UDM veri kaynağında ileride oluşacak değişiklikleri monitör
eder. Caching seçeneklerinde belirtilen zamanda UDM cache’i siler ve güncel
verilerle yeniden oluşturur.

Proactive caching MOLAP, ROLAP ve HOLAP yapılarında kullanılabilir. UDM bu
mimarilerden hangisini kullanmanız gerektiği konusunda size yardımcı olarak
doğru kararı vermenizi kolaylaştırır. Karar sürecinde dikkat etmemiz gereken en
temel noktalar “responsiveness” ve “latency”dir.

Xml Tanımlamaları

UDM’de yapılan tüm tanımlamalar XML dosyalarında saklanır. Her veri kaynağı,
data view, dimension ve küp tanımlaması kendi xml dosyasında tutulur. Bu XML
dosyalar doğrudan veri içermezler. XML dosyaları sadece tanımlamaları içerir.
Kısaca bu XML dosyaları, UDM’in kaynak kodudur.

Avantajlar

UDM geleneksel OLAP mimarileri ile karşılaştırıldığında pek çok avantaj
sunmaktadır. En temel avantajları vurgulamak gerekirse;

Transactional Veriye Dayanan OLAP Mimarisi

UDM OLAP küplerinin doğrudan transactional veri ile oluşturulmasına izin verir.
UDM kesin bir star ya da snowflake data mart’a gereksinim duymaz. Bunun yerine
iyi yapılandırılmış, ilişkisel bir veritabanı yeterli olur.

Bu OLTP sistemlerdeki verilerin Data Mart’a aktarımına duyulan gereksinimi ve
ETL yazma sırasında oluşan zaman kaybını ortadan kaldırır ki bu zamanla birlikte
uygulama sürecinin basitleştirilmesi ve daha düşük proje bütçeleri anlamına da
gelmektedir.

Son Derece Düşük Gecikme (Latency)

OLAP sistemini doğrudan OLTP sistemlerine dayandırarak data warehouse
sistemlerde ortaya çıkan gecikme en aza indirgenmiş olur. Gerçekte gerçek
zamanlı ya da neredeyse gerçek zamanlı performans elde edebiliriz. Ancak elbette
gerçek zamanlı iş zekası çözümlerini, OLTP sistemlerde oluşturacağı iş yükünü
göz önünde bulundurarak planlamamız gerekir.

Oluşturma ve Bakım Kolaylığı

UDM mimarisi OLAP projelerinin oluşturulmasındaki karmaşıklığı ortadan kaldırır.
UDM data mart gereksinimini ortadan kaldırarak veri oluşturma, transformation ve
load işlemlerini oluşturmak için harcanan zaman ve iş gücünü asıl işimiz olan iş
zekası’na yönlendirmemizi sağlar. Sadece bu bile, UDM’i diğer OLAP sistemlerine
tercih etmemiz için yeterli bir gerekçedir.

Source Control ile Tasarım Versiyonlaması

UDM içindeki her nesnenin kendi xml dosyasında tutulması sayesinde, UDM içindeki
her nesnenin versiyonlaması, source safe benzeri bir source control mekanizması
ile yürütülebilir. Source control mekanizması nesnelerdeki değişiklikleri takip
eder ve gerekli durumlarda karşılaştırma ve roll back imkanı sunar. Bu bir BI
projesinde özellikle geliştirme aşamasında oldukça faydalı bir özelliktir.

Sırada

Yazı dizisinin sonraki bölümünde teoriye biraz ara vereceğiz ve geliştirme
ortamını tanıyarak, BI çözümlerine doğru ilk adımımızı atacağız.

Paylaş

Hide Sites

Mimari

OLAP sisteminin en temel parçası küp ve içerdiği önceden hesaplanmış değerlerdir (preprocessed aggregates). OLAP sistemleri küp verilerini barındırmak için 3 temel mimariden birini kullanır. Her mimarinin farklı avantaj ve dezavantajları vardır. Aşağıdaki şekilde bu sistemlerin avantaj ve dezavantajlarını görebilirsiniz.

Relational Olap (ROLAP)
Relational OLAP küp verilerini çok boyutlu bir veritabanında saklar. Leaf-level measure’lar ilişkisel küp için veri kaynağı görevini üstlenmiş olan data mart’ta barındırılır. Preprocessed aggregate’lar da bir ilişkisel veritabanı tablosunda barındırılırlar.

Bir karar verici, belirli bir kaç değeri öğrenmek istediğinde, ROLAP sistemi önce dimension üyesinin bir hesaplama mı değer mi içerdiğine bakar. Hesaplama içeriyorsa değer ilişkisel tablodan, değer içeriyor ise data mart’tan alınır.

ROLAP mimarisi, ilişkisel veritabanlarına dayanan yapısı nedeniyle diğer OLAP mimarilerine kıyasla çok daha büyük boyutlarda veri barındırabilir. ROLAP mimarisi leaf-level değerleri doğrudan data mart’tan aldığından dolayı, ROLAP sisteminden dönen leaf-level değerler her zaman data mart’ın kendisi kadar güncel olacaktır. Bir başka söylemle, ROLAP sistemi leaf-level veriler söz konusu olduğunda herhangi bir gecikme ile karşılaşmamıza neden olmamaktadır. ROLAP sisteminin dezavantajı ise aggregate ve leaf-level değerlerin okunmasının diğer OLAP mimarilerine kıyasla daha yavaş olmasıdır.

Multidimensional OLAP (MOLAP)
Multidimensional OLAP (MOLAP) hem küp verisini ROLAP mimarisindeki gibi bir multidimensional veritabanında barındırır. Bununla birlikte hem preprocessed aggregate değerler hem de leaf-level değerlerin bir kopyası multidimensional veritabanında barındırılır. Bu nedenle, tüm talepler multidimensional veritabanından cevaplanır ki bu da MOLAP sistemlerin son derece yüksek tepki süresine sahip olmasının en temel nedenidir.

MOLAP sistemine veri yükleme işlemi gerçekleştirilirken leaf-level veriler de multimensional veritabanına kopyalandığından bekleme süresi daha uzun olmaktadır. Bu yapı nedeniyle, MOLAP sisteminden dönen leaf-level değerler, data mart ile farklılık gösterebilmektedir. MOLAP sistemi leaf-level değerleri multidimensional veritabanında barındırdığından daha fazla disk alanına gereksinim duymaktadır.

Hybrid OLAP (HOLAP)
Hybrid OLAP (HOLAP) mimarisi ROLAP ve MOLAP mimarilerinin bir karışımıdır. HOLAP her iki mimarinin avantajlarından faydalanmak ve zayıf yönlerinden kaçınmak amacıyla tasarlanmıştır.

HOLAP mimarisi küp ve preprocessed aggregate değerlerini multidimensional veritabanında barındırır. Bu, aggregate değerlerin okunma hızını son derece yüksek tutar. Bununla birlikte HOLAP yapısı leaf-level değerleri küp için veri kaynağı rolünü üstlenen ilişkisel data mart’ta barındırır. Bu leaf-level değerlerin okunması için ek zaman gereksinimini ve datamart ile küp arasındaki değer farklılıklarının önüne geçmemizi sağlar.

Dezavantajlar
OLAP sistemlerinin iş zekası çözümleri açısından sundukları pek çok avantaj olsa da, bazı dezavantajları da bulunmaktadır.Bu bölümde bu dezavantajların üzerinde duracağım;

Maliyet (ya da Yönetim, Bakım, Geliştirme Zorlukları)
OLAP sistemleri son kullanıcı açısından oldukça kolay ve kullanışlı bir ortam sunmakta. Bu kolaylığı sağlamak için işin zor kısmı yönetim ve geliştirme bölümlerine aktarılmış durumdadır. Bu karmaşıklık, iş zekası sistemlerinin geliştirilmesi için daha yüksek seviyede teknik bilgi gereksinimini doğurmaktadır.

Tüm dimension, hiyerarchy ve measure’ların tanımlanması ve oluşturulması gerekir. Sonraki adımda bu nesnelerin küpler içinde tanımlanması gerekir. Bu, organizasyon, hedefleri ve işleyişi hakkında oldukça detaylı bilgi gereksinimi anlamına gelmektedir. Bununla birlikte geliştirme ve bakım ekiplerinin data mart ve seçilen OLAP araçları hakkında bilgi sahibi olması zorunludur.

Elbette geliştirme ve bakım ekibi için gereken bilgi ve deneyim oranı arttıkça maliyet de artar. İş zekası projeleri son derece yüksek malieytli uzmanlık gereksinimi yüzünden oldukça yüksek maliyetli olabilmektedir. Bu faktör, tek başına pek çok organizasyonun iş zekası çözümlerinden uzak durmasına yol açmaktadır.

Data Mart Gereksinimi
Pek çok durumda, OLAP sistemleri star ya da snowflake mimarisindeki bir data mart’a gereksinim duyarlar. Veriler OLTP sisteminden, data mart’a aktarılır ki bu iş genellikle schedule edilmiş görevler aracılığıyla gerçekleştirilir ve veri aktarımı sırasında veri temizleme ve düzenleme işlemleri (veri yükleme / data loading) de gerçekleştirilir. OLTP sistemlerindeki değişiklikler elbette ilgili data loading rutinlerinde değişiklik anlamına gelecektir.

Gecikme
OLAP sisteminin kullandığı data mart yapısı nedeniyle data loading işlemi gerçekleşene kadar OLTP sistemlerdeki veriler, OLAP sistemleri tarafından görülemeyecektir. Data loading işlemi çoğu senaryoda gecelik olarak gerçekleştirildiği için OLAP sistemi OLTP sistemini 1 gün sonradan takip edecektir.

Salt Okunur
Bazı durumlarda bir OLAP analizi sırasında bazı verilerin güncellenmesi istenebilmektedir. Bu verilerdeki hatalardan kaynaklanabileceği gibi karar vericinin farklı what-if senaryolarını gözlemlemek istemesinden de kaynaklanabilir, örneğin: “Komisyonlar yüzde 1 oranında arttırılmasının kar tutarına etkisi ne olacaktır?”.

Çoğu durumda OLAP verileri read-only durumdadır. OLAP sistemimizin writeback desteği olsa dahi, veri güncellemesini data mart üzerinde yapıyor olacaktık ve değişikliklerimiz transactional sisteme yansımayacaktı.

Bu bölümde temel OLAP mimarilerini ele aldık. Sonraki bölümün konusu ise temel OLAP mimarilerilerinin dezavantajlarından korunmak için geliştirilmiş olan Unified Dimensional Model yapısı olacak.

Paylaş

Hide Sites

OLAP Sisteminin Özellikleri
OLAP sistemleri verinin analizi ve analiz sonuçlarının sunumuna odaklanmış bir altyapı sunar. Bu altyapı OLAP sistemlerini efektif karar verme gereksinimi duyan kullanıcılar için doğal bir seçim haline getirir.

Multidimensional Database
OLAP sistemleri measure, dimension, hierarchy ve cube’ler şeklinde organize edilmiş verilere dayanır. Transactional veritabanlarının tablo, satır, sütun ve ilişkiler içerdiğini hatırlayalım. Bu multidimensional yaklaşım kullanıcıların verileri gereksinim duydukları şekilde bölümlendirme ve filtrelemelerine olanak tanır. Kullanıcılar dimensionlar aracılığıyla verileri farklı açılardan görebilir, hierachyler sayesinde drill yaparak gördükleri bir veriye ait detaylara ulaşabilirler.

Multidimensional bir veritabanı iş zekasına yönelik verilerin saklanması için en sık kullanılan alternatiftir. Multidimensional veritabanlarının analize yönelik verilerin saklanması için en uygun alternatif olmasının yanı sıra, sundukları bir diğer önemli avantajda preprocessed değerlerin saklanmasına uygun bir altyapı sunuyor olmalarıdır.

Preprocessed Aggregates
Bir karar verici, belirli bir ölçütün, belirli boyutlara bağlı değerini görmek istediğinde, göreceği değerler o anda on-the-fly olarak hesaplanır. Karar vericinin bu hesaplama işlemi sırasında beklemesi gerekecektir. Bu özellikle veriye erişim hızının önemli olduğu ve büyük boyutlu veritabanlarında istenmeyen bir durum olarak karşımıza çıkacaktır.

OLAP sistemlerinin amacı, karar vericilerin veri ile etkileşim içinde olmasını sağlamak olduğuna göre, hesaplamaların hızlı bir şekilde geri dönmesi gerekir. Bu nedenle OLAP sistemleri bazı değerleri önceden hesaplar. Bu ön-hesaplama, data load ve update işlemlerinin bir parçası olarak, arkaplanda gerçekleştirilen bir işlemdir. Ön-hesaplama bir arkaplan işlemi olarak gerçekleştirildiğinden dolayı, kullanıcılara doğrudan bir etkisi yoktur. Hesaplanan bu değerler küpün içinde saklanmaktadır.

Bir karar verici belirli bir ölçütün, belirli boyutlara göre değerini görmek istediğinde, veriler on-the-fly hesaplanmak yerine veritabanından okunarak kullanıcıya iletilebilecektir. Bu sistemin tepki süresini çok büyük oranda hızlandıracaktır.

Kolayca Anlaşılabilir Bir Yapı
OLTP sistemlerde veri normalize olarak saklanır ve tablolar arasındaki bağlar karmaşık foreign key ilişkileri ile sağlanır. Burada amaç tekrarlayan veri miktarını minimuma indirgemektir. Karar vericilerin bu veriler arasından gereksinim duyduğu veriyi elde edebilmesi için inner ve outer join ifadelerini kullanarak gerekli sorguları hazırlaması gerekecektir. Bir ölçütün hesaplanma yöntemini belirleyen iş kuralları kod tarafında yer alacak ve karar vericinin bir ölçütü kullanmak istemesi durumunda bu hesaplamalar raporun her açılışında yeniden gerçekleştirilecektir.

Çoğu zaman OLTP sistemlerdeki field ve tablolar yazılım geliştiriciler için bir anlam ifade etse de, son kullanıcı açısından bir anlam ifade etmez. Veritabanı sistemi kullanılacak isimlerin biçim ve uzunlukları konusunda kısıtlamalar getiriyor olabilir. Saydıklarım ve benzeri durumlarda ortaya çıkacak tablo ve field isimleri son kullanıcı açısından şifrelenmiş veri izlenimi yaratabilir. Karar vericinin bir alanın aslında hangi veriyi sakladığını anlamakla zaman harcamak ve doğru verinin sorgulandığından emin olmak yerine, veriye odaklanması gerekir.

OLAP sistemlerde ise durum tam tersidir.  Verinin yapısı dimension ve hierarchyler ile temsil edilir. OLAP sistemi doğru tasarlanırsa, bu dimension ve hierarchyler organizasyonun yapısı ile örtüşecektir. Bu nedenle veri yapısı karar vericiler açısından son derece tanıdık olacaktır.

OLAP sistemlerinde bir ölçütün hesaplanmasında kullanılan iş kuralları, ilgili ölçütün hesaplamalar alanı içinde barındırılır. Kullanıcının hesaplamaları ölçütün her kullanılışında yeniden oluşturmasına ihtiyaç yoktur. Örnek vermek gerekirse; işletmemizin net kar değerini şu formülle hesapladığını varsayalım:

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Personel Maliyeti + Satış Komisyonları)

İlişkisel ortamda net kar verisi aşağıdaki gibi hatalı bir biçimde raporlanabilir:

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Personel Maliyeti )

ya da

Net Kar = Satış Fiyatı – (Hammadde Maliyeti + Satış Komisyonları)

Bu tutarsızlık karışıklığa ve daha kötüsü yanlış kararların alınmasına neden olabilir. OLAP yapısında ise net kar ölçütü için kullanılacak formül bir noktada tanımlıdır ve karar verici bu ölçüte baktığında her zaman gerekli verileri kullanarak doğru sonucu ürün, ay ya da satış bölgesi gibi bir boyut bazında verir.

Son olarak OLAP sistemleri iş zekasına yönelik yapılar olduğundan, ölçüt, boyut, hiyerarşi ve benzeri tüm OLAP unsurlarıu, karar verici tarafından kolayca anlaşılabilir şekilde isimlendirilebilir, daha iyisi istenilen diğer dillere tercüme edilerek farklı dilleri anlayan kullanıcılar için ayrı sistemler tasarlamak yerine tek sistemin, tüm kullanıcılar tarafından kullanılabilmesi sağlanabilir.

Bir sonraki bölümde, OLAP sistemlerinin mimarisini ele alıyor olacağız.

Paylaş

Hide Sites

Unified Dimensional Model
İlk bölümlerde İş Zekası’nın sağlıklı karar verme sürecini desteklemek için nasıl kullanılabileceğine değindik. Sonrasında iş zekası’na kaynak olacak veriyi tanımladık ve çoğu durumda ihtiyaç duyduğumuz verilerin OLTP sistemlerde yer aldığını gördük.

OLTP sistemleri incelediğimizde, bu sistemlerin iş zekası için çok sağlıklı bir veri kaynağı olmadığını farkettik. OLTP sistemler gerçekleşen her işleme dair oluşan verileri saklamak için tasarlanmışlardır. Hesaplamalar yaparak özet veriler sunmak için optimize edilmiş bir yapıya sahip değillerdir.

OLTP sistemlerin iş zekası alanındaki yetersizlikleri bizi data mart yapısına yöneltti. Data mart yapısı, büyük miktarda tarihsel verilerin barındırılması için tasarlanmış bir ilişkisel veritabanı sistemidir. Data mart yapısını incelerken kullanıcıların büyük miktardaki tarihsel veri üzerinde çeşitli hesaplamalar yapmak isteyeceklerini ve bu hesaplamaların büyük miktardaki veriler ile yapılması durumunda ciddi bir performans sıkıntısının ortaya çıkacağını belirtmiştik ve cevabın Online Analytical Processing (OLAP) olduğunu  belirtmiştik.

Online Analytical Processing
İlişkisel veritabanı ve OLTP teorisinin yaratıcılarından E.F: Codd, 1993 yılında veri analistlerinin gereksinimlerine göre optimiz edilmiş yeni bir sistem fikrini sundu. Bu sistemi “Online Analytical Processing” kısaca OLAP olarak isimlendirdi. Codd tarafından ortaya çıkarılan fikir genel anlamda pek fazla kabul görmesede, OLAP ismi İş Zekası için tasarlanan sistemlerin genel adı olarak kullanılmaya devam etmektedir.

OLAP yapısı, kullanıcıların analiz esnasında veri ile etkileşim içinde olmasına izin verecek şekilde tasarlanmıştır. Kullanıcılar verileri bölümlendirebilir, gruplandırabilir, farklı görünümlerle analiz edebilir, dwill-down yaparak belirli bir veriyi oluşturan detay verilere ulaşabilir. Bu esnek ve gelişmiş yapı, OLAP yapısını sıklıkla kullanılan statik raporlardan ayırmaktadır.

OLAP yapısı kullanıcıların verilere hızlı ve kolay bir şekilde erişmesini sağlamak amacıyla tasarlanmıştır. Veriler genellikle bir data mart’ta saklanır. OLAP sistemi data mart içindeki verinin hızlı bir şekilde görüntülenmesi ve analizi için gerekli yapıyı sunar. OLAP sisteminde veriler measure, dimension, hierarchy ve cube unsurlarından oluşmaktadır.

Gerçekte OLAP sistemi daha önceki bölümlerde kısaca değindiğim küplere odaklanmıştır. OLAP yapısı ile ilgili teknik detaylara girmeden önce, küplere biraz daha değinmekte fayda görüyorum. Bu sefer ay, ürün ve satış sorumlusu bilgilerini dimension olarak kullanıyoruz. Ortaya çıkan küp aşağıdaki gibi görünecektir.

Gördüğünüz gibi grafikteki küp, üç boyutun kesişim noktasındaki veriyi yani Zeynepcan tarafından Temmuz ayında İstanbul 2010 Kültür Başkenti serisi ürününden yapılan satış miktarını göstermektedir.

Zeynepcan, satış sorumlusu, İstanbul 2010 Kültür Başkenti, ürün, Temmuz ise Ay boyutunun bir üyesidir. Bu üç boyutun kesişim noktasındaki satış verisi ise 16.702 TL’dir.

Kesişim noktasında okuduğumuz değer “detail” ya da “leaf-level” value olarak adlandırılır. Grafikte yer alan 16.702 TL verisi, üç boyutun kesişim noktasındaki değer olduğu için leaf-level value’dur. Zeynepcan’ın Temmuz ayındaki toplam satış verisine ulaşmak için Zeynepcan’ın Temmuz ayında sattığı tüm ürünleri bir araya getirmemiz gerekir. Bunu aşağıdaki grafikte görebiliriz:

Aynı aydaki tüm satış sorumlularının yaptığı tüm satışların toplamını elde etmek için başka bir hesaplama daha yapmamız gerekir. Bu sefer tüm satış sorumlularının yaptığı Temmuz ayı içinde tüm satışları bir araya getirmemiz gerekir.

Bu hesaplamaları aynı zamanda boyutların içinde hareket ederken de kullanırız. Satış sorumlularının gruplanabildiğini, bölgelere ayrılabildiğini, ürünlerin ürün gruplarında ve ürün türlerinde gruplanabildiğini, ayların ise çeyrek ve yıl içinde gruplanabildiğini hatırlayın. Bir hiyerarşinin seviyeleri içinde yukarı doğru yapılan her harekette, alt seviyeye ait verilerin bir araya getirilmesi ve gruplanması için hesaplamalar yapılır. Örneğin Zeynepcan’ın İstanbul 2010 Kültür Başkenti ürününde 1. Çeyrekte yaptığı satış verisi, Zeynepcan’ın bu üründe Ocak, Şubat ve Mart aylarında yaptığı satışların toplamıdır.

Küpler pek çok boyut ve pek çok hesaplama gerektiren hiyerşi içerebilir. Hiyerarşilerin sayısının ve seviyesinin artması, işlem hızımızı azaltacaktır. Bunun üstesinden gelebilmek için eldeki verilerin tümü (ya da bir kısmı) önceden hesaplanır. Saklanan bu verilere “preprocessed aggregates” ismi verilir.

Bir sonraki bölümde OLAP sisteminin özelliklerini, avantajlarını ve dezavantajlarını ele alıyor olacağız.

Paylaş

Hide Sites

Yazı dizimizin son bölümünde star şemaları incelemiş ve örnek firmamızın veritabanı modeli üzerinde çalışmıştık. Bu bölümde ise star şemalara alternatif olarak kullanılan snowflake şemalarını inceliyor olacağız.

Snowflake şemaları ilişkisel veritabanlarından aşina olduğumuz ilişkisel bir yapı sunar. Snowflake yapısında hiyerarşinin her bir katmanı, ayrı bir tabloda saklanır. Aşağıdaki grafikte bunu görebilirsiniz. Star yapısı gibi snowflake yapısıda ismini tasarım sonrasında ortaya çıkan görünümden almaktadır.

Start yapısında olduğu gibi, bu yapıdada ilişkiler foreign keyler aracılığıyla yönetilir. Bu nedenle fact table, tüm üyelerin en alt seviyesinin kombinasyonları için ayrı ve eşsiz bir kayıt içerir. Bu hiyerarşi seviyeleri için ölçütler star şemadaki gibi hesaplama yöntemi ile elde edilirler.

Snowflake Yapısı, Star Yapısı ve Analysis Services
Snowflake ilişkisel tasarımın tüm avantajlarına sahiptir. Duplicate veri oluşumu söz konusu değildir ve bu nedenle yönetimi daha kolaydır. Ek olarak ilişkisel veritabanları üzerinde deneyim sahibi kişiler için anlaşılması ve kullanımı daha kolaydır.

Snowflake yapısının dezavantajı ise ölçütlerin hesaplanması sırasında pek çok join gerektiriyor olmasıdır. Büyük ölçekli data martlarda bu son derece ciddi performans sıkıntılarına yol açabilmektedir.

Hem snowflake, hem de star yapısında hesaplamalarımızı on the fly gerçekleştiririz. Çok sayıda dimension içeren ya da çok fazla üyeye sahip dimensionlarda bu ciddi zaman gerektirebilmektedir. Bu measureları önceden hesaplayarak data martta, disk üzerinde saklayabiliriz ancak bu data mart’ın yapısını oldukça karmaşık hala getirerek yönetimini zorlaştırabilir.m Peki data mart’ın sorumlularının akli dengesini bozmadan yüksek performanslı bir yapıyı nasıl oluşturabiliriz? Bu noktada OLAP altyapıları devreye girmektedir.

Altyapı konusunda bir sonraki adımda bahsedeceğimiz Analysis Services ya da en az Microsoft’un Analysis Services ürünü kadar yaygın olan Oracle BI ürünleri bu noktada devreye girer ve bu işin sağlıklı, yüksek performanslı ve kolay yönetilebilir bir hal almasını sağlarlar. Ben yazı dizisinin ilerleyen bölümlerinde Analysis Services ürününü kullanıyor olacağım. Bir sonraki bölümde Microsoft SQL Server Analysis Services ürününü tanıyor olacağız.

Paylaş

Hide Sites

Star Schema
Measure ve Dimension’lar data mart’ta iki şekilde saklanırlar. İlk olarak star schema’yı ele alacağız. Bu şemanın ismi, bu türdeki data mart için oluşan ilişkisel database diagramın görünümünden gelir. Star schema 2 tür tablo kullanır: fact table ve dimension table.

Bir start schema’nın merkezinde fact table yer alır. Fact table measure için bir sütun içerir ve her dimension’ın üyeleri için bir foreign key alan içerir. Bu tablonun primary key alanı, tüm foreign ket alanların birbirine bağlanması ile ortaya çıkar. Bu yapıya aynı zamanda composite key ismi verilir. Fact table’lar içerdikleri measure’ın isminin sonuna Fact ekinin eklenmesiyle isimlendirilirler. Örneğimizdeki fact table bu şekilde isimlendirilerek SalesFact ismini almıştır.

Dimensionlar dimension tablolarında barındırılırlar. Dimension table’lar dimension’ın üyelerini tanımlamakta kullanılan eşsiz genellikle integer olarak tanımlanan bir anahtar alanına ve bu üyeyi açıklayan bir açıklama alanına sahiptir. Dimension tablosunda saklanan her dimension için ayrı bir satır oluşturulur. Dimension tabloları içerdikleri dimension’a göre başına Dim ön eki getirilerek isimlendirilir. DimProductType dimension tablosunun satırları şu şekilde olacaktır.

Dimension tablolarını şemaya eklediğimizde, aşağıdaki grafiktekine benzer bir görünüm elde ederiz.

Büyük ihtimalle, fact tablosu dimension üyelerinin ortaya çıkaracağı eşsiz kombinasyonları içerecektir. Büyük ihtimalle dememin nedeni, dimension üyelerinin bazı kombinasyonlarının değer içermemesidir.

Örneğimize göre, “Milliyet Gazetesi Reklam Kampanyası” “marketing campaign” dimension’ının bir üyesi olursa, Sales Fact tablosunun içeriği şöyle olacaktır.

Örneğimizde “marketing campaign” dimension’ının 8 üyesi olacağını, yıl dimension’ının 6 üyesi olacağını, product type dimension’ının 4 üyesi olacağını, sales region dimension’ının 7 üyesi olacağını ve buyer’s age dimension’ının 6 üyesi olacağını düşünecek olursak Fact tablosunda 8 x 6 x 4 x 7 x 6 adet veya 8.064 adet satırımız olacaktır. Bu yapıda çok büyük bir değer gibi görünmese de, on ya da yüzlerce üyeniz olduğunda, fact tablonuzun boyutu ciddi oranda büyüyecektir.

Gerçekte, fact table dimension üyeleri için açıklama değil identifier bilgilerini içerir. Bu kullanılan disk alanında ciddi tasarruf sağlar. Satır sayınız milyonlara ya da 100 GB ve üzerinde bir veritabanı ile çalışmaya başladığınızda burada bahsettiğim şeyin önemini çok daha iyi anlayabilirsiniz.

Ek olarak, tek bir fact table, birden çok measure içerebilir. Bu iki ya da daha fazla measure’ın, aynı dimension’ı kullandığı durumlarda karşılaşılan bir durumdur. Birden çok measure’ı, aunı dimension’larla aynı fact table’a koymak, data mart tarafından kullanılan disk alanında ciddi tasarruf sağlayacaktır.

Attribute’lar
Bazı durumlarda dimension üyeleriyle ilgili bazı ek bilgileri saklama ihtiyacı duyarız. Bu dimension’ın üyelerini daha iyi tanımlamamıza yardımcı olur. Bu ek bilgiler dimension’ın attribute’ı olarak adlandırılır.

Attribute’lar dimension üyelerini daha iyi tanımlamak için kullanılırlar. Kullanıcılarının çıktı olarak isteyebilecekleri bazı bilgileri içerebilecekleri gibi, data mart’tan analiz esnasında çekilecek verilerin kısıtlanması ya da filtrelenmesi amacıyla kullanılmak üzere bazı bilgileri barındırabilirler. Attribute’lar dimension tablolarında aşağıdaki grafikte görüldüğü gibi ek alanlar şeklinde saklanırlar.

Hiyerarşiler
Çoğu durumda dimensionlar daha büyük bir yapının üyesi durumundadırlar. Bu yapıya hiyerarşi adı verilir. Örneğimizde yıl, product type ve sales region dimension’ları kendi hiyerarşilerinin parçalarını oluştururlar.

Hiyerarşiler iki ya da daha fazla ilişkili dimension’dan meydana gelen yapılardır. Üst seviyede bulunan bir dimenison, bir sonraki seviyeye ait bir daha daha fazla dimension’ı içerir.

Örneğin; Yıl dimension’ı çeyrek, çeyrek dimension’ı ay dimension’ını içerir. Product Type dimension’ı alt ürün gruplarını, alt ürün grupları da ürünleri içerir.

Hiyerarşiler kullanıcıların data mart içinde yer alan measure’lar içinde hareket ederek eldeki veriyi farklı açılardan görmelerini sağlar. Örnek vermek gerekirse, bir kullanıcı “İstanbul Serisi” ürün ailesinin alt ürün türlerine bakabilir. Sonrasında Karadeniz bölgesi için satış detaylarını inceleyebilir. Sonrasında bu satışların sadece 2007 yılının ilk çeyreğine ait olanlarını görüntüleyebilir. Sonuçta tüm bu verilerin toplamına yani toplam satış tutarına göz atabilir. Kullanıcı verinin içinde hareket ederek karar vermek için gerekli bilgilere kolayca ulaşabilir.

Start şemasında, hiyerarşilerle ilgili bilgiler, dimension tablolarında tutulur. Her dimension tablosunun primary key alanı, hiyerarşinin en alt noktasını oluşturur. Bu nedenle fact tablosu, içerdiği foreign keylerin bu alanları göstereceği şekilde güncellenmelidir. Bu, fact tablosu, hiyerarşinin en alt seviyesinin kombinasyonu için bir kayıt içerecektir.

Hiyerarşilerin en alt seviyelerinin dışındaki katmanlar data mart’ta saklanmaz, bunun yerine çalışma zamanında saklanan verilere dayanan hesaplamalarla elde edilirler. Örneğin bir kullanıcı Karadeniz bölgesi için toplam satış bilgisini talep ederse, bu veri, Karadeniz bölgesindeki tüm alt bölgelere ait satışlar toplanarak elde edilir.

Bir sonraki bölümde SnowFlake şemasını ele alıyor olacağız.

Paylaş

Hide Sites

Data Mart
Önceki bölümde bahsettiğim gibi işletmenin OLTP sistemlerini İş Zekası platformuna veri kaynağı olarak tanımlamamız durumunda ciddi sorunlarla karşılaşabiliriz. Bu sorunların önüne geçebilmek için OLTP sisteminde yer alan verileri OLTP sistemi dışında, ayrı bir alana aktarırız ve yapacağımız hesaplamalara kaynak olarak bu veri kaynağını kullanırız. Bu ayrı alana Data Mart adını veriyoruz.

Data Mart’ların Özellikleri
Data Mart’lar İş Zekası çözümüne kaynak olarak tasarlandıkları için, işleri işletmenin günlük işlemlerini yürütmek olan OLTP sistemlerden farklı bir yapıya sahiptirler. Normalizasyon kurallarına bağlı olarak tasarlanmalarına karşın, data mart’lar hızlı erişime göre optimize edilmişlerdir. Data Mart bir ilişkisel beritabanı olmakla birlikte, daha az join gerektirecek şekilde tasarlanırlar. Data Mart’larda hız kazanmak amacıyla denormalize (tekrarlayan) veri kabul edilebilir.

Bir Data Mart tasarımı yaparken, normalizasyon kuralları “fact”ler etrafında kümelenen farklı bir yapı ile değiştirilirler. Yeni tasarım yapısı “stars” ve “snowflakes” olarak adlandırılırlar. Bu iki kavramı bu ve sonraki bölümlerde inceliyor olacağız.

Gerçek Zamanlı Olmayan Veri
OLTP sistemler business transactionlara dair verileri bu transactionlar gerçekleştiği anda kaydeder. Data Mart’lar ise belirli aralıklarla güncellenirler. Veri OLTP sistemlerden belirli aralıklarla Data Mart’a aktarılır. Bu işleme “data load” olarak adlandırılır.

Data Mart’lar OLTP sistemlerden tamamen ayrı oldukları için, İş Zekası uygulamalarının Data Mart’lara erişimleri, OLTP sistemler üzerinde herhangi bir yük oluşturmaz. Bu durumun tek istisnası, data load işlemidir. Data Load sırasında OLTP sistemler kopyalanacak verilerin hazırlanması için ciddi yük altına girebilirler. Burada avantajımız, data load işleminin scheduled olarak off-peak zamanlarda çalıştırılabilecek bir işlem olmasıdır.

Önceki bölümlerde değindiğimiz gibi, data mart’ta bulunan veriler gerçek zamanlı değildir. Çoğu durumda işlem gerçekleşmesi ile gerçekleşen işleme dair verilerin data mart’a aktarılması arasında zaman olur. Eğer data load işlemi her ay, ay sonu işlemlerinden sonra gerçekleşecek şekilde schedule edilirse, data mart 1 aylık gecikmeye sahip olacaktır. Data load gecelik olarak çalışırsa, data mart 1 günlük gecikmeye sahip olacaktır.

İş Zekası gereksinimlerinin tam ve doğru olarak karşılanabilmesi için kabul edilebilir ve uygulanabilir gecikme doğru olarak belirlenmeli ve altyapı bu gecikme süresine göre tasarlanmalıdır. Data mart tarafından sunulacak veriler, sağlıklı karar verme sürecini destekleyecek yeterlilikte olmalıdır. Bununla birlikte data load işlemi, OLTP sistemin üzerinde gereksiz bir yük oluşturacak sıklıkta olmamalıdır.

Konsolidasyon ve Cleansing
Farklı OLTP sistemlerden gelen veriler tek bir data mart içinde birleştirilebilirler. Bu bazı complex hesaplamaları yapmamızı sağlar. Ancak daha önce bahsettiğim gibi bu gereksinimin önünde bazı engeller vardır. Birden çok OLTP sistem, veriyi saklamak için farklı formatlar kullanıyor olabilir. Aynı türden veri için tutarsız veri türleri ile karşılaşabiliriz. Aynı entity için eşleşmeyen identifier alanlar söz konusu olabilir ve farklı zamansal periyod ve tarih formatları kullanılıyor olabilir. Tüm bu farklılıklar, farklı sistemlerde yer alan verilerin birleştirilmesini zorlaştıracaktır.

Bu tür sorunlar veriler data mart’ta saklanmadan önce çözümlenmelidir. Bunun için cleansing adını verdiğimiz işlemi gerçekleştiririz.

Data Cleansing verileri data mart ortamında sorunsuz bir şekilde kullanabileceğimiz hale getirir. Tutarsız veri türlerini tek bir türe dönüştürür. Eşleşmeyen identifier alanları standart bir yapıya çevirir. Yapacağımız hesaplamalar için uygun olmayan verileri düzenler veya siler.

Data cleansing genelde daha büyük bir işlemin bir parçası olarak gerçekleştirilir. Bu büyük işlem verileri OLTP sistemden alır ve data mart’a aktarır. Bu nedenle bu sürecin tümüne verilen isim “extract, transform and load” kelimelerinin kısaltması olan ETL’dir. ETL süreci verileri OLTP sistemden alır, gerekli cleansing işlemlerini gerçekleştirir ve veriyi data mart’a aktarır.

Bir Data Martın Yapısı
İş zekası için kullandığımız veriyi 4 ana başlık altında inceleyebiliriz: measure, dimension, attribute ve hierarchy. Bu 4 veri türü bize bir data mart’ın yapısını tanımlamada yardımcı olur. Şimdi sırayla bu veri türlerini inceleyelim.

Measure
Measure olarak adlandırdığımız yapı İş Zekası başlığı altında yapacağımız her işin temelidir. Measure’lar olmadan iş zekası olamaz tespiti hiç de yanlış olmaz. Makalenin ilk bölümlerinde değindiğim gibi measure’lar, sağlıklı karar verme sürecinin en temel parçalarıdır.

Bir measure, işletmenin performansının ölçümünde kullanılmak üzere hesaplanan belirli bir konunun toplam değeridir. Measure, aynı zamanda fact olarak da adlandırılır. Measure bilgilerini içeren tablolara fact table ismi verilse de, fact table’lar fact’lerden daha fazlasını barındırırlar.

Dimension
Toplam satış miktarı karar verme sürecinde kullanılabilecek bir measure’dır. Ancak karar vericiler şirketin o güne kadar yaptığı toplam satışı görmek istemezler. Çünkü tüm satış personelinin, tüm ürünlerde, şirket kurulduğu günden o güne kadar yaptıkları toplam satış, tek bir rakamsal değer olarak çok anlamlı değildir. Bunun yerine karar vericiler bu değeri daha ufak parçalar halinde görmek isterler. Dimension’lar bu bölümlendirmede kullanılırlar.

Dimension’lar belirli bir measure ile ilgili kategorizasyon yapmamızı sağlar. Örnek vermek gerekirse toplam satış tutarını tek bir bilgi olarak kabul edelim. Geometride bir noktanın boyutu yoktur.

Bir kategorizasyon yaparak (ya da dimension) bu tek bir noktayı temsil eden veriyi bölümlendirebiliriz. Örneğimize eldeki satış verilerini yıllık kategorilendirmeye tabi tutalım.

Artık elimizde yıl isimli dimension’da her bir yıl için bir nokta içeren bir çizgi mevcut. Geometride çizgi tek boyutlu bir nesnedir. Bu nedenle elimizdeki measure’a bir dimension ekledik ve 2002, 2003, 2004, 2005, 2006, 2007 değerlerinin her biri Yıl isimli dimension’ın üyeleri (member) oldu.

Bu noktada toplam satış bilgisinin ürün bazında kırılımını elde edebiliriz.

Toplam satışa ait measure’lar artık bir kare içinde hizalanmış durumdadır. Kare iki boyutlu bir nesne olduğu için oluşturduğumuz measure’a bir dimension daha ekledik. Ürün isimli bu dimension’ın “Ankara Serisi”, “İstanbul Serisi”, “İstanbul 2010 Kültür Başkenti” ve “Diyarbakır Serisi” isimli üyeleri vardır.

Şimdi toplam satış verisini bir defa daha, bölge bilgisiyle bölümlendirelim. Toplam satış measure’ı artık üç boyutlu bir nesne olan küp halini alacaktır. Görebileceğiniz üzere eklediğimiz her yeni kriter, elimizdeki measure’ın dimensionality oranını arttırmaktadır, bu nedenle ismi dimension’dır.

Elimizdeki Measure’ı ek dimensionlar oluşturarak daha detaylı kırılımlar elde edebiliriz. Örneğin pazarlama kampanyası ve müşteri yaş grubu dimensionlarını ekleyerek önce 4 sonrasında ise 5 boyutlu bir nesne elde edebiliriz. Bu durumda nesnemiz bir grafikle görüntülemek için oldukça karmaşık bir hal alır. Bu 4 ve daha çok boyutlu nesneleri küp olarak tanımlarız. İlerleyen bölümlerde küpleri ilgili son derece detaylı olarak ele alıyor olacağız.

Bir sonraki bölümde start schema yapısını ele alıyor olacağız.

Paylaş

Hide Sites

Önceki bölümlerde İş Zekası ile ilgili pek çok temel konuyu, örneklerle ele aldık ve iş zekasının karar verme sürecindeki önemini vurguladık. Bununla birlikte İş Zekasının işletmedeki pek çok farklı seviye için önemini ve kullanım alanlarını açıkladık. Son olaraksa örnek işletmemiz olan “TinyToys Ltd” firmasını yakından tanıdık.

Sıradaki adımımız, “TinyToys Ltd” firmasının ihtiyaç duyduğu iş zekası çözümünü geliştirirken kullanacağımız örnek veritabanı yapılarını oluşturmak olacak. Bazı durumlarda İş Zekası için kaynak durumunda olan veriler doğrudan bazı veritabanı veya dosyalardan temin edilebilir durumda olurken, bazı durumlarda ise bu verilerin İş Zekası amacıyla kullanılabilir hale getirilmesi için gereken ön işlemleri yapabileceğimiz ayrı bir alana taşınması gerekir. Bu ayrı alana İş Zekası terminolojisinde “data mart” adı verilmektedir.

Kaynağın Aranması
İş Zekasının işletmelerin sağlıklı karar verebilmesi açısından önemini gördük. Bu bizi şu soruya yönlendiriyor: “İş Zekası’nın kaynağı nedir?”.  İş Zekası çözümlerinde kaynak olarak kullanılan bilgi işletmenin zaten günlük işleyişiyle ortaya çıkarttığı transactional verilerdir.

Transactional Veri
Pek çok işletme gerçekleştirdiği işlemlerin takibini yapmaktadır. Alınan siparişler, üretilen ürünler, verilen servisler, müşterilerden alınan ödemeler ve tedarikçilere yapılan ödemeler gibi. Tüm bu işlemlere genel olarak “Business Transaction” ismini veriyoruz. Bu işlemler sonucunda oluşan verileri ise “transactional data” olarak adlandırıyoruz.

Bir işletmenin sağlıklı yürüyebilmesi için gerçekleşen “Business Transaction”ların takip edilmesi, ürün ve servisler için ödemelerin alınması, alınan ürün ve hizmetler için ise ödemelerin yapılması, sipariş ve servis taleplerinin karşılanması gerekmektedir. İşletmeler genellikle nelerin yapıldığı ve nelerin yapılması gerektiği ile ilgili kayıt tutmak zorundadırlar. Bu bilgilerin bilgisayar tarafından yönetilmesi ve bilgisayarda saklanması durumunu “Online Transaction Processing” ya da kısaca “OLTP” olarak adlandırıyoruz.

OLTP sisteminde saklanan verilerin toplamı, işletmenin geçmişini oluşturmaktadır. OLTP sistemleri, önceki bölümlerde değindiğim ölçütleri hesaplamak için gerekli ham verileri içermektedir. Bu nedenle İş Zekası çözümümüzü geliştirebilmek için bu verilere gereksinim duyarız.

Transactional Verilerin İş Zekası Çözümünde Kullanımının Zorlukları
OLTP sistemleri ölçütleri hesaplamak ve İş Zekası çözümümüzü geliştirebilmemiz için gereksinim duyduğumuz ham verileri barındırır demiştik. Ancak bu verilere erişimde bazı sıkıntılarla karşılaşabiliriz. Bu problemleri kısaca özetleyelim:

Tasarım Kısıtları: İyi tasarlanmış OLTP sistemleri transactionların sağlıklı bir şekilde işlenmesi ve saklanmasını sağlamak için optimize edilmiştir. Bu verilerin normalizasyon kuralları doğrultusunda daha ufak parçalara bölünmesi anlamına gelir. Bu OLTP sistemlerin çok sayıda transaction’ı eşzamanlı olarak yürütebilmesini sağlar. Bu tür verilerin saklanması için en sağlıklı platform ilişkisel veritabanı yönetim sistemleridir.

Diğer yandan İş Zekası için kullanacağımız ölçütler bir transaction’a ait olayları yansıtmak için değil, bir grup transaction’ın istenen zaman dilimi içindeki net sonucunu yansıtmak için tasarlanmıştır. İş zekası ölçütleri çoğunlukla yüzlerce, binlerce hatta milyonlarca ayrı transaction’ın hesaplanması ile elde edilirler. Bu sonuçları hesaplayabilmesi için sistemin bir grup farklı optimizasyondan geçirilmesi gerekecektir.

OLTP sistemler, tasarım amaçları ve yöntemlerinden dolayı bu tarz hesaplamalar konusunda çok başarılı değillerdir. Bu, zaten OLTP sistemlerin geliştirilme amacının dışındadır. Bu hesaplamaların sağlıklı çalışması için farklı bir veri saklama optimizasyonu ile çalışmamız gerekir.

Günlük İşlemler: OLTP sistemler işletmemizin günlük işlerini destekler. Çoğu durumda işletmenin reaksiyon hızı bu sistemlerin performansı ile orantılıdır.  Eğer sipariş sistemi veya müşteri yönetim sistemi cevap vermez hale gelirse, işletmemizin işleri ciddi oranda aksayabilir. OLTP sistemler üzerinde az önce bahsettiğim hesaplamaları yapmak, bu sistemlerin işlem gücünü ve kaynaklarını ciddi oranda kullanacak ve hesaplamanın tamamlanması oldukça uzun zaman alacaktır. Hesaplama sırasında pek çok kaydın bloke olması da güçlü bir ihtimaldir ki bu, bu kayıtlara dayanan günlük işlemlerin o kayıtlardaki lock kalkana kadar durması anlamına gelecektir. Sanırım bu hesaplamaların OLTP sistemler üzerinde yapılmasının sakıncalarını saymaya devam etmeme gerek yoktur. Sadece bir rapor oluşturmak için muhasebe sisteminin durduğunu ya da e-ticaret platformunuzun cevap veremez hale geldiğini düşünün.

Arşivleme: OLTP sistemler günlük işlemlere odaklanmış olduğundan, uzak geçmişe yönelik verilerle ilgilenmez.Bu sistemler kısa bir döneme ait veriyi kaydeder ve/veya veri sadece o anki durumu gösterir. Bir ürünün o anki stok durumu gibi. Veriler bir yıl için kaydedilip sonrasında bir yıllık işlem tarafından silinebilir. Farklı bir formatta arşivlenebilir veya basitçe, silinebilir. Hangi durum olursa olsun, arşivlenen bu verilere erişim kolay olmayacaktır.

OLTP sistemler bu tarz arşivleme yöntemlerini sistemin sağlıklı çalışmasını garanti etmek için desteklerler. Bir transaction tablosu çok fazla kayıt içerirse, OLTP sistemi yavaş çalışmaya başlayabilir. Arşivleme, bu sistemlerin sağlıklı ve beklenen performansla çalışmasını sağlamak amacıyla da kullanılabilir. Ancak arşivleme İş Zekası açısından ciddi bir problem olabilir. Ölçütlerimizdeki trendlere bakarken geçen yılın değerlerini bu yıl ile hatta pek çok yılı birbiri ile kıyaslamak isteriz. Geçmiş yıllara ait veriler arşivlendiğinde ya da silindiğinde bu işlemin yapılması oldukça zorlaşacaktır.

Farklı Noktalardaki Veriler: İşletmelerin operasyonlarını yürüttüğü pek çok farklı OLTP sistemi olabilir. Örnek firmamızda olduğu gibi veriler farklı iş operasyonlar için farklı sistemlerde, farklı formatlarda saklanabilir. Hatta işletmenin tüm verilerinin tek bir sistemde saklandığı bir yapıyla büyük ihtimalle hiç bir zaman karşılaşamayacaksınız diyebilirim.

Diğer yandan İş Zekası çözümümüzde yer alacak ölçütler bu tür bir ayrımı desteklememektedir. Bunun yerine tüm işletmeyi bir bütün olarak görürler. Örneğin sıklıkla ihtiyaç duyulan ölçütlerden biri belirli bir ürüne dair kar payıdır. Bu ölçütü hesaplayabilmek için üretim sisteminden bu ürünün üretiminde kullanılan hammaddelerle ilgili bilgilere, muhasebe sisteminden bu hammaddelerin maliyetlerine, puantaj sisteminden bu ürünün üretimi için harcanan işgücü bilgisine, sipariş sisteminden ürün için ödenen rakama ihtiyaç duyarız. Bu, bu tür bir ölçütün hesaplanabilmesi için tüm bu farklı sistemlere ait verilerin bir araya getirilmesi gerektiği anlamına geliyor.

Sistemler arasındaki iletişime gelmeden önce, önümüzde farklı bir sorun var. Tüm bu sistemler, büyük ihtimalle farklı ürün tanımlama şemaları, kodlar ve takvimler kullanmaktadır. Aynı ürün üretim sisteminde “17187” ürün kodu ile tanımlıyken, e-ticaret sisteminde “EB-17RXQ” kodu ile tanımlı olabilir. Bordro programı 2 haftalık ödeme sistemi ile çalışırken, muhasebe sistemi mali aylarla çalışabilir. Farklı sistemlerdeki veriler bir araya getirildiğinde yapmamız gereken ilk iş, verilerin eşleştirilmesi olacaktır ki inanın bu çoğu durumda bir kaç sunucunun birbirleri ile iletişimini sağlamaktan çok daha basit bir işlemdir.

Yazı dizimizin bir sonraki bölümünde “Data Mart” konusunu ele alıyor olacağız.

Paylaş

Hide Sites

Önceki bölümlerde İş Zekası kavramını, işletmeler açısından önemini ve uygulama alanlarını detaylıca ele aldık. İş Zekası konusunda teknik konulara geçmeden önce sizleri örneklerimizde rol alacak aktörle tanıştırmak istiyorum: “TinyToys Ltd”.

“TinyToys Ltd” dekoratif biblolar ve cam ürünleri üreten ve satan bir firmadır. “TinyToys Ltd” pek çok farklı ürün serisine sahiptir. Örneğin 2010 yılına özel “İstanbul, 2010 Kültür Başkenti” serisi, bunun dışında Türkiye’nin farklı illerinin kültürek simgelerini konu alan seriler mevcuttur. Bu ürünlerin üretiminde cam, kil, kalay ve alüminyum kullanılmaktadır.

“TinyToys Ltd” ürünlerini üç farklı kanal aracılığıyla pazarlamaktadır. Bunlar;

• Kendisine ait olan ve sadece kendi ürünlerinin satıldığı 5 adet “TinyToys Ltd” mağazası.
• Kendisine ait olan ve ürünlerinin internet üzerinden satışının yapıldığı “TinyToys Ltd” web sitesi.
• Diğer perakendecilere yapılan toplu satışlar

“TinyToys Ltd” Firmasının Gereksinimleri
“TinyToys Ltd” son üç yılda oldukça ciddi büyüme kaydetmiş, sipariş miktarında %300 oranında bir artış gerçekleşmiştir. Bu büyüme “TinyToys Ltd” firmasının mevcut iş zekası çözümü olan “statik rapor”ların önünde ciddi engeller olduğunu farketmesini sağladı. Bir kaç yıl öncesine kadar statik raporlar karar destek sürecini başarıyla destekliyordu ancak artık bu yöntem, raporların oluşması ve anlaşılması için bir saatten fazla zaman gerekmesi nedeniyle ihtiyaca cevap vermemeye başlamıştır. Bu raporlar çok kısmi bir özetleme ile çalışmaktadır.

“TinyToys Ltd” firması pek çok farklı ürün ailesine sahiptir ve bu alanlardaki rekabette başarılı olabilmek için sağlıklı bir karar verme mekanizmasına ihtiyaç duyulmaktadır. “TinyToys Ltd” firmasının mevcut iş zekası altyapısı malesef bu konuda gereksinim duyulan desteği sağlamamaktadır.

Bu nedenlerden dolayı, “TinyToys Ltd” firması karar verme sürecine daha sağlıklı destek verecek bir "İş Zekası” platformu oluşturulması için yeni bir proje başlattı. Bu proje datawarehouse tasarımını, datawarehouse’ın mevcut sistemlerdeki verilerle oluşturulması ve işletmenin tüm kademelerindeki karar vericilere yönelik analiz uygulamalarının geliştirilmesini kapsamaktadır. Yeni iş zekası platformu SQL Server 2008 platformu üzerinde kurgulanmaktadır.

Makale dizisinin bundan sonraki bölümlerinde “TinyToys Ltd” firmasının yeni iş zekası projesinin tüm aşamalarına tanık olacağız. Ancak başlamadan önce “TinyToys Ltd” firmasının mevcut sistemini inceleyelim.

Mevcut Sistem
Geliştirilecek olan İş Zekası platformunda veri kaynağı olarak rol alacak 5 farklı sistem mevcuttur. Bu sistemlerin genel görünümü için aşağıdaki grafiği inceleyebilirsiniz.

Üretim Otomasyonu
Üretim otomasyon sistemi bir ürünün üretilmesi için kullanılan tüm materyallerin takibini yapar. Bu sistem aynı zamanda hangi üretim hattında hangi ürünlerin üretildiğini takip eder. Son olarak bu sistem her mesai döneminde kaç ürün üretildiğini takip eder.

Bu sistem özel bir veri saklama formatı kullanır. Veriler bu sistemden comma-delimited metin dosyaları halinde export edilebilir. Bu dosya üretim sisteminin verilerinin İş Zekası sistemine aktarımında kullanılacaktır.

Sipariş Sistemi
Sipariş sistemi tüm ürünler için stok bilgisini barındırır. Bununla birlikte “TinyToys Ltd” firmasının tedarikçilerinin verdiği toplu sipariş bilgisini içerir. Sipariş Sistemi bu bilgilerle birlikte “TinyToys Ltd” mağazaları ve “xyz.com” web sitesinden gelen sipariş verilerini de içerir.

Sipariş sistemi, teslimat dahil olmak üzere sipariş durum bilgisini yönetir, faturaları oluşturur ve ödemelerini yönetir. Ek olarak bayilerden geri gönderilen ürünlerle ilgili kayıtları tutar.

Bu sistem verileri Microsoft SQL Server veritabanında barındırmaktadır.

POS Sistemi
POS sistemi firmaya ait 5 mağazada yapılan ödemeleri yönetir. Bu sistem aynı zamanda bu mağazalardaki stok yönetimini UPC (Universal Product Code) sistemini kullanarark gerçekleştirir. Bu sistem hem nakit hem kredi kartı ile yapılan ödemeleri yönetir. Aynı zamanda müşteriden geri dönen ürünlerle ilgili takip yine bu sistem üzerinden yapılmaktadır.

Tüm POS sistemlerinde oluşan veriler bir XML dosyasına aktarılarak gecelik olarak ftp ile merkezi bir alana aktarılmaktadır. Bu xml dosyaları POS verilerinin İş Zekası platformuna aktarımında kullanılmaktadır.

xyz.com Web Sitesi
xyz.com online mağazası ASP.NET ile geliştirilmiş ve veritabanı olarak SQL Server kullanmaktadır. Tüm satışlar kredi kartı ile gerçekleştirilmektedir. Müşterilerin her satın alma için ad, adres, telefon numarası ve email bilgilerini vermeleri gerekmektedir.

Online mağaza tüm siparişlerin, müşterilerden geri dönen ürünlerin ve promosyon ve indirimlerin kaydını tutmaktadır.

Muhasebe Sistemi
Muhasebe sistemi “TinyToys Ltd” firmasının tüm finansal işlemlerinin kaydını tutmaktadır. Bu kayıtlaraa hammadde alımı da dahildir. Muhasebe sistemi SQL Server veritabanı kullanmaktadır.

İş Zekası Sisteminin Geliştirilmesi
Yazı dizisinin sonraki bölümlerinde mevcut sistem ve gereksinimleri dikkate alarak ihtiyaç duyulan İş Zekası platformunu geliştirmek için ilk adımları atıyor olacağız.

Paylaş

Hide Sites

Farklı Seviyelerde “İş Zekası”
Önceki bölümlerde İş Zekası’na işletmelerin her seviyesinde gereksinim duyulduğuna değinmiştim. Gerçekten İş Zekası ile işletmenin tüm seviyelerine yönelik “cevap”lar oluşturulabilir. Ancak İş Zekası ile oluşturulan her “cevap”, işletmenin tüm seviyelerinde gereklidir sonucuna varmak hata olacaktır. İşletmelerde yer alan farklı seviyeler, farklı türde bilgilere gereksinim duyarlar. Bu bölümde işletmelerde hangi seviyede ne tür bilgilere gereksinim duyulduğunu, bir piramit üzerinden anlatıyor olacağım.

Piramidin Zirvesi
İşletmelerin üst düzey karar vericileri büyük fotoğrafa bakmak zorundadırlar. İşletme için uzun vadeli hedefler belirlemekle sorumludurlar ve ufak detaylara takılıp zaman kaybetmemek için sorumluluk alanları ile ilgili çok detaylı bilgi yerine bu bilginin doğru şekilde özetlenmiş ve biçimlendirilmiş haline sahip olmalıdırlar.

 
Şekil 1.1: İşletmenin Farklı seviyelerindeki hedefler

Özetlenmiş Ölçütler
İş Zekası bu seviyelerin gereksinimlerini karşılayacak şekilde tasarlanmıştır. Ölçütler karar vericilere özetlenmiş olarak iletilmelidir. Çoğu durumda ölçütler sayılarla değil, çeşitli grafiksel öğelerle ifade edilirler. Bu grafiksel öğeler ölçütün kabul edilebilir değerler içinde olup olmadığını, gecikmeyi veya kabul edilmesi mümkün olmayan değerleri ifade eder. Bu grafiksel öğelere İş Zekası konusunda “Key Performance Indicator” kısaca KPI adı verilir.

Şekil 1.2: Somut Ölçütler

KPI’lar üst düzey karar vericilere işletmenin belirli bir alandaki anlık durumu ile ilgili görsel, kolay algılanabilen ve kolay yorumlanabilen bilgi sağlar. KPI’lar sıklıkla trafik lamlabaları veya gauge grafikleri gibi anlık durumu ifade eden grafiksel öğeler olarak sunulur. KPI’ları ilerleyen bölümlerde detaylıca ele alıyor olacağız.

Yüksek Gecikme
Üst düzey karar vericiler genellikle uzun vadeli hedefler üzerinde çalıştığından, anlık verilere gereksinim duymazlar. Bu, bu seviyedeki iş zekası uygulamalarının dayandığı verilerin, çoğunlukla anlık güncelleniyor olması zorunluluğunun olmadığı anlamına gelir. Bu seviyedeki karar vericilerin belirli bir konuya dair belirli bir dönemdeki trendi görmeleri gerekir.

Şekil 1.3: Karar verici seviyelerine göre gereksinim duyulan veri güncelleme sıklığı

Orta Seviye
Orta düzey karar vericiler departman ve diğer birimlerin yönetimini gerçekleştirirler. Kısa vadeli hedefler belirlerler ve sorumlulukları kapsamındaki birimler için planlama yaparlar. Orta düzey karar vericiler günlük süreçlere dair detaylı verilere gereksinim duymazlar.

Özetlenmiş Ölçütler ve Drilldown
Bu seviyedeki karar vericilerde özetlenmiş verilere gereksinim duyarlar ancak sıklıkla belirli bilgilerin detayını görmek isterler (drilldown). Bu nedenle bu seviyedeki karar vericiler raporları, veri odaklı analize izin veren interaktif sistemlerle birlikte kullanırlar. Bu tür karar vericiler veri madenciliği teknikleri ile oluşturulmuş verileri de kullanabilirler.

Kabul Edilebilir Gecikme
Bu karar vericiler işletmenin günlük işlevlerine daha yakın olduklarından, bazı durumlarda daha düşük gecikmeye gereksinim duyarlar. Ölçütlerin günlük olarak güncellenmesine gereksinim duyma olasılıkları olmakla birlikte, genellikle haftalık ya da aylık periyodlara ilişkin verilere gereksinim duyarlar.

Piramidin Temeli
Piramidin temelini oluşturan insanlar, yani çalışanlarımız, yöneticilerimiz ve grup liderlerimiz günlük işlemleri gerçekleştirir. Bu insanlar günlük operasyonel hedefleri belriler ve bir sonraki haftaya, güne veya mesai dönemine ilişkin kaynak planlamasıyla ilgili kararları alırlar. Bir sonraki satış kampanyasını ya da satış aramasını planlarlar. Bu karar vericiler genellikle yüksek erişilebilirliğe ve yüksek tepki süresine sahip İş Zekası sistemlerine gereksinim duyarlar.

Detay Seviyesinde Ölçütler
Bu karar vericiler işletmenin tüm operasyonlarıyla ilgili detaylarla ilgilenirler ve detaylı veriye gereksinim duyarlar. Bu karar vericiler bazı durumlarda ölçütlerin özetlenmesi ancak drilldown ile detaylara inilebilmesine gereksinim duyarlar. Bununla birlikte veri madenciliğinden faydalanarak belirli trend ve korelasyonları günlük bazda izleme gereksinimi duyabilirler.

Düşük Gecikme
Bu seviyedeki karar vericiler günlük operasyonlarla ilgilendiğinden, bilgideki değişikliklerden en hızlı şekilde haberdar olmalıdırlar. Bu nedenle bu seviyede çok düşük bir gecikmeye tolerans gösterilebilir. Bazı kritik durumlarda günlük, saatlik hatta daha küçük bir periyodu içeren verilere gereksinim duyarlar.

Paylaş

Hide Sites