Veri Ambarı

Operasyonel veritabanları, firmaların operasyonel sistemlerinin taleplerine en iyi şekilde cevap vermek üzere tasarlanmışlardır. Operasyonel veritabanları ne kadar iyi tasarlanmış olsalar da, geriye dönük veri saklama kapasitelerinin sınırlı olması ve komplike analizler için optimize edilmemiş olmaları sebebiyle stratejik karar verme aşamasında kullanılmaya pek uygun değillerdir.

Karar Destek Sistemleri uzun yıllardır gündemde olmasına rağmen 1990‟lı yılların başında farklı veri kaynaklarındaki ve farklı uygulamalardaki önemli verilerin tek bir platformda toplanması fikri, “veri ambarı” konseptinin ortaya çıkmasına sebep olmuştur. Veri ambarı (data warehouse) için, operasyonel verilerin sorgulama ve analiz için tasarlanmış bir kopyası da denilebilir. [1]

Veri ambarı için bir çok tanım bulunmakla beraber hemen hepsinde ortak olarak bulunan öğeler, bu konseptin yaratıcılarından olan W.Inmon‟un tanımında bulunmaktadır: “Veri ambarı, karara verme sürecine destek olmak için tasarlanmış, içinde bulunan tüm verilerde zaman bilgisi bulunan bütünleşik, tutarlı ve konu odaklı bir veritabanıdır.“ [5]

Veri ambarı tabiri, kimileri için sadece bir veri kümesini ifade ederken, kimileri için ise verilerin son kullanıcıya sunulmasına yardımcı olan bir platform ve etrafındaki uygulamaları kapsamaktadır. [23] Aslında veri ambarı konsepti, operasyonel ve stratejik karar süreçlerini etkileyen gelişmiş bir bilgi işlem mimarisini tanımlar. Veri ambarı şirket için hazır alınabilecek bir ürün veya çözüm değildir, tersine organizasyondaki süreçlerin, yazılımların, donanımların ve verinin bir bileşiminden oluşur. [3]

Veri ambarından bahsederken Veri Adacığı (Data Mart) kavramına da değinmek gerekir. Veri ambarı tüm şirket genelindeki veriyi saklayan ve modelleyen bir yapıyken, veri adacığı sadece belli bir iş kolunun veya departmanın ihtiyaçlarını karşılamak üzere tasarlanmış bir yapıdır. Küçük bir veri ambarı olarak da tanımlanabilecek olan veri adacığı, düşük maliyetli olması ve kısa sürede işlevsel hale getirilebilmesi sebebiyle tercih edilebilmektedir. Veri adacığı, şirket içinde veri ambarına örnek teşkil edecek bir başlangıç adımı olabileceği gibi, kurumsal bir veri ambarının oluşturulmasının ardından belli bir grubun spesifik ihtiyaçlarını karşılamak amacıyla da tasarlanmış olabilir. [2]

23

Veri ambarı yapısı, Karar Destek Sistemleri‟nde olması beklenen tüm unsurların yerine getirilmesini sağlayacak bir platform sağlar. Verilerin ve süreçlerin konsolidasyonu ihtiyacını, tüm departmanlarda bulunan süreçlere ait verilerin tek bir noktada toplanmasını sağlayarak karşılar. Veri ambarında konularına göre mantıksal olarak modellenen bu veriler, şirketin bütünü hakkında fikir verecek konsolide enformasyonun tek bir noktadan üretilmesine yardımcı olur. [18]

Verilerin kalitesi, veri ambarına transfer sırasında veriler manipüle edilerek veya transfer sonrasında veriler üzerinde çeşitli uygulamalar çalıştırılarak arttırılır. Veri ambarının detay seviyesi, şirketin operasyonel ve stratejik ihtiyaçlarına cevap verecek şekilde tasarlanarak, Karar Destek Sistemleri‟nin entegre bir çözüm sunmasına olanak sağlar. Yüksek performanslı bir ortam sağlanması işlevini ise operasyonel sistemlerden periyodik olarak çekilen büyük miktarda verinin, analize uygun şekilde modellenmesi sayesinde yerine getirir. [18]

4.3.1. Veri Ambarı Karakteristikleri

W.Inmon‟a ait veri ambarı tanımında bulunan konu odaklılık, bütünleşiklik, sabitlik ve tarihsellik unsurları veri ambarının temel karakteristikleri olarak sıralanabilir. Bu karakteristiklerin anlaşılması veri ambarı konseptinin algılanması için önem teşkil etmektedir.

Konu odaklılık ile, operasyonel sistemlerdeki süreç odaklı tasarımın aksine, veri ambarında bir fonksiyonel iş kolu için anlam ifade eden verilerin bir arada tutulması üzerine kurulu bir tasarım kastedilmektedir. [11] Bir bankanın operasyonel sisteminde bireysel kredi süreci, kredi talebinden kredinin sonlanmasına kadar bir süreç olarak işlem görebilir ve raporlanabilir. Ancak veri ambarında bu veri, müşterinin ürünleri altında veya bankanın riskleri kategorisinde kategorize edilebilir.

Bütünleşiklik ile veri ambarında tanımlanan, değişkenler bazında gruplanan verilerin özetlenerek saklanması, bu verilerin gerekirse kontrolden geçirilip temizlenmesi ve manipüle edilmesi olarak yorumlanabilir. [11] Bir bankanın operasyonel sisteminde, başvuru ve kabul süreci farklı olan konut kredisi ile taşıt kredisi farklı ekranlar aracılığıyla ele alınır ve banka mizanında farklı hesaplarda gösterilebilir ancak veri ambarının konu odaklılık karakteristiğine de uygun olarak banka bazında ele alındığında her iki kredi de banka için bir risktir. Bu sebeple mizanda farklı hesaplar olarak ele alınan bu iki farklı krediye, veri ambarına taşıma yapılırken tek bir değişken atanabilir. Bu durumda veri ambarı kullanılarak yapılacak analizlerde bu veriler konsolide bir halde son kullanıcıya sunulmuş olur.

Sabitlik ile veri ambarındaki verinin değişmemesi kastedilmektedir. Operasyonel sistemlerde veriler yazma, silme ve güncelleme işlemleri ile kayıtlarda anlık değişiklikler yaşanır. Ancak analizlere baz teşkil eden veri ambarındaki verinin değişmemesi, alınacak kararların sağlıklı olabilmesi için gereklidir. [11] Bu durumun sağlanabilmesi için ise veri ambarına, taşınan veriler üzerinde güncelleme yapılmaz. Veri ambarına taşıma sıklığı aylık, haftalık veya günlük olarak tanımlanabilir. Gerekli görüldüğünde son ana en yakın durumun analizini yapabilmek için gün içinde belli saatlerde veya bir tetiklemeye istinaden de taşıma yapılabilmesi mümkündür.

Tarihsellik ile, veri ambarına atılan tüm kayıtlara ait bir tarih bilgisinin bulunması kastedilmektedir. [12] Bu tarih bilgisi gün bilgisi olabileceği gibi, ihtiyaca göre hafta, ay hatta yıl bilgisi bile olabilir. Bu sayede kullanıcıların belli bir periyoda ait analiz yapma

25

şansları olacaktır. Yılın ilk çeyreği ile ikinci çeyreğindeki kredi kullandırımları arasında kıyaslama yapabilmek için veri ambarına taşınan kredilere ait kayıtlarda tarih bilgisinin bulunması gereklidir.

4.3.2. Veri Ambarının İşleyişi

Operasyonel sistemler ile analitik sistemler fiziksel olarak ayrı olsalar da, bu iki ortamı birbirlerinden ayrı düşünmemek gerekir. Operasyonel sistemde üretilen veriler analitik sisteme transfer esnasında belli bir ayıklama ve temizleme işleminden geçirilmezse, enformasyon üretme süreci son kullanıcılar için kolay olmaktan çıkacaktır. [18]

Veri ambarının modellemesinin ardından göz ardı edilmemesi gereken unsur, bu sistemi besleyecek yapının oluşturulmasıdır. Veri ambarında, iş kolunun ihtiyaçlarını karşılayacak verinin gereksiz detaylarından arındırılarak ve konsolidasyon için gerekliyse bir miktar manipüle edilerek yani daha homojen hale getirilerek saklanması gerekecektir. Veri ambarı için en kritik süreç olan, veri transferi ve homojenleştirme işlemlerini otomize etmeye yarayan uygulamalar bulunmaktadır. Bu uygulamalar, veriyi kaynağından çıkartma, değiştirme ve veri ambarına yükleme işlemlerini yaptıkları için, ilgili kelimelerin İngilizce karşılıklarının ilk harflerine tekabül eden ETL (Extract-Transform-Load) kısaltması ile bilinmektedirler.

Şekil 4.2: Veri ambarının işleyişi [18]

An

a

li

tik

O

rtam

Ope

ra

s

y

onel

Orta

m

27

ETL uygulamaları, farklı veritabanı ve platformlara hızlı ve etkin bir şekilde erişerek, veri ambarının önemli özelliklerinden biri olan konsolide veriyi derleme işlevinin yerine getirilmesini sağlarlar. Şekli 4.2‟de gösterilen sürecin üst tarafı operasyonel sistem, alt tarafı ise analitik sistemi temsil etmektedir. Veri ambarının, operasyonel veri tabanlarından homojen veri ile beslenmesini sağlayan ETL süreci şeklin sağ tarafındaki oklar ile gösterilmektedir. Veri ambarından yapılan analizler yardımıyla üretilen bilgi ve bu bilgiye istinaden alınan stratejik iş kararları, iş süreçleri üzerinde etkiler yapmaktadır. İş süreçleri üzerinde yapılan değişiklerin operasyonel sisteme, dolayısıyla ilgili veri tabanına etkisi bulunmaktadır.

Şekil 4.2‟de gözüktüğü üzere, ETL sürecini de içine alan veri ambarının işleyişinde, sürecin teknik boyutunun sonuçları sürecin iş boyutunu etkilemektedir. İş kolu tarafında yapılan değişiklikler yine teknik tarafa değişiklik olarak yansımaktadır. Bu dinamik yapının yönetilebilmesi için uygulamaların optimizasyonu kadar, insan faktörünün de ön plana çıkması gerektiğini vurgulamakta yarar vardır.