İş Zekam NET

Bu site Makine Öğrenmesi, Veri Madenciliği, İş Zekası, Biyoenformatik konuları hakkında,teknoloji bağımsız olarak başlangıçtan ileri düzeye kadar türkçe bilgi sunmayı amaçlamaktadır.

İş Zekası Hakkında Herşey - 14

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.

İş Zekası Hakkında Herşey - 13

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.

İş Zekası Hakkında Herşey - 12

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.

İş Zekası Hakkında Herşey - 11

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.