Microsoft, verinin olusumundan/depolanmasından baslayarak, son kullanıcının

mevcut veri uzerinden gecmisle ilgili analiz ve gelecekle ilgili kestirimlerde bulunmasını

sağlayacak bir dizi arac ve yontem sunmakta ve bunların butunune “İs Zekası”

uygulamaları demektedir.

Karar vericilerin en doğru kararları verebilmesi icin organizasyonun urettiği verilerin

veritabanı uzmanlarınca en doğru sekilde yapılandırılarak saklanması, gerektiğinde

farklı ortamlardan alınan verilerin uygun bir bicimde bir araya getirilmesi ve veri

analistlerince uygun yontemlerle is analistlerine sunulması ve is analistlerince

yorumlanarak karar vericilerin anlayabileceği bicime donusturulmesi gerekmektedir.

Microsoft bu sureclere destek vermek icin SQL Server urununu OLTP veritabanı

sunucusu olarak, SQL Server Integration Services urununu veri transferi ve temizleme

aracı olarak, SQL Server Analysis Server aracını veri madenciliği ve analiz aracı

olarak, son olarak da SQL Server Reporting Services aracını, sonucları son kullanıcılara

gostermek amacıyla raporlama aracı olarak sunmaktadır.

Ayrıcı Excel ve bazı diğer web bilesenleriyle, veri madenciliği ve analizi sonuclarını son

kullanıcıların daha rahat ve etkin kullanacağı araclar da sunmaktadır

. İş Zekâsı ve Microsoft

Günümüzde işletmeler için kullanılabilir bilgi çok önemli bir değerdir. 21. yüzyıl

ekonomisinin rekabetçi ortamında, firmaların sürdürülebilir rekabet avantajı

sağlayabilmeleri için bilginin gücünü daha etkin bir şekilde kullanabilmeleri gerekir.

Kurumların bilgiyi kullanma çabalarında ulaşılan son aşama, iş zekâsı uygulamalarıdır. İş

zekâsına küçük-büyük tüm işletmelerin ihtiyacı vardır ve iş zekâsı çözümleri karar alma

süreçlerinde önemli rol oynar.

Kurum ve kuruluşların karar vericileri, en doğru kararı verebilmek için en doğru bilgilere

gereksinim duymaktadırlar. Karar vericilere bilgiye dayalı ilerleme imkânı sunarak,

kurumun gelir ve performansını en üst düzeye ulaştırmayı hedefleyen iş zekâsı

uygulamaları, tüm kuruluşlara rekabet gücü sağlamaktadır.

Hedefi yüksek performansa ulaşmak olan kurum ve kuruluşlar için bilgiye ulaşmak, ulaşılan

bilgileri paylaşmak ve kullanabilmek hayati öneme sahiptir. Bunu gerçekleştirmenin en

kolay, pratik ve güvenilir yolu iş zekâsı çözümleridir. İş zekâsı çözümleri, kurum içi ve dışı

verileri bir platformda toplayıp analiz etme yeteneğinde olup işletmelerin bilgiyi

yönetebilmeleri ve bir değere dönüştürebilmelerine imkân tanır. Dolayısıyla

organizasyonların daha yüksek performans düzeyine ulaşmalarına yardımcı olur,

operasyonel verimlilik ve şeffaflık sağlar. Aynı zamanda CRM “Customer Relations

Management” , ERP “Enterprice Resource Planning” gibi kurumda şu ana kadar yapılmış

olan iş ve BT “Bilgi Teknolojileri” yatırımlarının da etkin geri dönüşüne imkân sağlar.

İş zekâsı uygulamaları sayesinde karar vericiler, stratejik ve operasyonel kararlarında daha

doğru ve hızlı adımlar atabilmektedirler. İş zekâsı çözümleri, etkin bilgi yönetimi sürecinin

vazgeçilmez bir parçası olarak karşımıza çıkmaktadır. İş zekâsı çözümleri, başlangıçta daha

çok kurum ve kuruluşlarda karar vericilere hitap eden bir çözümler bütünü olarak ortaya

çıkmıştır. Hâlbuki sadece karar vericilerde değil, kurumların her aşamasında iş zekâsı

uygulamalarına ihtiyaç vardır ve her aşamada kritik bir öneme sahiptir.

İş zekâsı uygulamalarıyla, verilerin bilgiye, bilginin yoruma, yorumun karara ve kararın

eyleme dönüştürülebilmesi mümkün hale gelmektedir. İş zekâsını bir süreç olarak

düşünürsek; veri bilgiye, bilgi yoruma, yorum karara ve karar eyleme dönüştüğünde gerçek

bir iş zekâsından bahsedilebilmektedir.

Neden Microsoft Araç Seti?

Microsoft teknolojilerini kullanarak bir DW/BI (Data Warehouse / Business Intelligence)

sistemini nasıl inşa edeceğimizi tarif etmeye devam etmeden önce, şu soruyu sormak

yerinde olur: Microsoft araç setini ilgi çekici kılan ne?

Bütünlük: İşletim sisteminden, veritabanı motorlarından ve geliştirme ortamlarından Office

ve Excel masaüstüne kadar sadece Microsoft yazılımı kullanarak bütün bir DW/BI sistemi

inşa edebilirsiniz. Tüm bileşenlerin etkin bir şekilde birlikte çalışacağına duyacağınız

güvende ekstra bir rahatlık alanına sahipsiniz.

Düşük Sahip Olma Maliyeti: SQL Server'ın lisanslama maliyetleri diğer yazılım

üreticilerinin karşılaştırılabilir ürün kümelerine göre daha düşük olagelmiştir; ancak toplam

sahip olma maliyeti, lisanslama maliyetlerinin yanı sıra, sürekli destek, eğitim ve operasyon

maliyetlerine de bir o kadar bağlıdır. Microsoft, SQL Server sistemlerinin rakip ürünlere göre

daha az yönetsel kaynak gerektirdiğini iddia etmektedir. Organizasyonunuzda .NET

programlama yetenekleri zaten var olabilir. Eğer öyleyse, DW/BI sisteminizi özelleştirmek ve

genişletmek gerçekten kolay olabilir.

Açıklık: Her ne kadar tüm bir DW/BI sistemini Microsoft yazılımıyla inşa etmeniz

mümkünse de -ki bu kitap bunun nasıl yapılacağını anlatıyor- böyle davranmak zorunda

değilsiniz. Microsoft DW/BI çatısının her hangi bir bileşeni üçüncü bir parti ürünü için

çıkarılabilir ve pek çok müşteri Microsoft DW/BI sistemlerini heterojen ortamlarda

oluşturmaktadırlar.

Yüksek Performans ve Ölçeklenebilirlik: Bu kitabın yazıldığı sıralarda, terabaytlık

hacimlere sahip DW/BI sistemleri hayli yaygın ve 10-20 TB çok da nadir değil. DW/BI

sistemleri klikleme akışı ve RFID veri akışları gibi alt seviye işlemlere dayanmaya

yöneldikçe, ortalama büyüklükte organizasyonlar bile kendilerini "terabayt kulübü"nde

bulabilirler. Microsoft bu eğilimi fark etmiş durumda ve ürünlerini özellikle de SQL Server

bileşenlerini yüksek veri hacimlerinde iyi performans göstermek üzere test etmiş bulunuyor.

İş Zekâsında Microsoft Yatırımı: SQL Server 2005 iş zekâsı çözümleri, bir arada dikişsiz

değilse bile çok profesyonel dikişlere sahip olarak çalışan gerçek araçlardan oluşmaktadır.

Araçlardan bazıları -özellikle Analysis Services- türünün en iyileri. Tüm ürünler rakipleri

olan tek başına çalışan ürünlerle, sadece kendi özellikleriyle de rekabet edebilir durumdalar.

Microsoft açık bir şekilde mükemmel iş zekâsı uygulamaları geliştirmeniz için gerekli

araçları inşa etmeye kendini adamış bulunuyor. Ve Microsoft'un uzun bir süre boyunca

etrafta olacağına mantıklı bir güven duyabilirsiniz.

Yaygın Olarak Kullanılan İş Zekâsı Terimlerine Genel Bir Bakış

İşletmeler genellikle iş sistemlerinden ikisini kullanırlar. Bu sistemler;

1. Çevrimiçi hareket işleme (OLTP) olarak ta bilinen Operasyonel işlemler,

2. Kullanıcılara işlerinde daha etkili kararlar alabilmesini sağlayan ve bu amacı

gerçekleştirebilmek için operasyonel verileri uygun bir şekilde seçerek alan Karar

Destek Sistemleri’dir.

Bazı şirketler bu iki işlemi tek bir sistemde gerçekleştirmelerine rağmen genellik bu durum

aşağıda açıklayacağım nedenlerden dolayı pek uygun olmamaktadır.

· Operasyonel sistemler içinde bulunan OLTP verileri tekrarlamayı önlemek üzere

normalleştirilirler ve bu verilerin analiz işlemlerinde kullanılması için daha karmaşık

sorgular yazılmasını gerektirir.

· OLTP sistemler Veri Ekleme, Düzenleme ve Silme işlemleri için uyarlanmışlardır ve

genellikle yüksek bir indekslemeye tabii tutulmamışlardır. İndekslerin az olması

nedeniylede analitik verileri almak için kullanılan sorgularda performans problemleri

olması yüksek bir olasılıktır.

BI çözümlerinin temel hedefi geniş ölçekli karar destek yeteneği ve kullanıcıların iyi organize

edilmiş ve çeşitli kullanıcı gruplarından gelmiş verileri kolay kullanabileceği araçlar

sunmaktır. BU nedenle veriler OLTP sistemlerinde olsalar bile bir BI sistemine aktarılıp bu

sistemde etkin karar destek sorgulamalarına gidilmelidir.

Aşağıda BI çözümleri için kullanılan temel BI terimleri ve açıklamaları anlatılmıştır.

ETL : Operasyonel sistemlerde tutulan veriler işletmede kullanılan uygulamalara özel bir

şekilde tutulduğu için kullandığımız BI sistemine direkt olarak atılmaya uygun olmayabilir.

Bu tür heterojen yapılardan gelen verilerin BI sistemine Aktarılması, Uygun Şekilde

Çevrilmesi (işimize yaramayan verilerin ayıklanması, veri tiplerinin uygun hale getirilmesi,

vb.) ve son olarak BI sistemine Yüklenmesi işlemine ETL adı verilmektedir. ETL konusu

daha detaylı bir şekilde 4. bölümde işlenecektir.

Data Warehouse : Veri ambarı olarak da adlandırabileceğimiz Data Warehouse, BI

sistemlerinde kullanılan tutarlı verilerin tutulduğu merkezileştirilmiş ambarlardır. Bu kısa

tanımla birlikte aslında veri ambarları, veri analizi, veri madenciliği ve raporlama

işlemlerinin her biri için verinin farklı kopyalarını da tutarlar. Ayrıca sorgu performansını

artırmak için bir çok durumda Denomalize işlemine tabi tutulmaları gerekmektedir.

Data Mart : Data Mart’ları Veri Ambarının bir parçası olarak tanımlayabiliriz. Örnek vermek

gerekirse, bir şirket içerisinde bulunan Pazarlama ve Satış departmanlarına ait analizleri Veri

Ambarının tamamından değilde sadece Pazarlama yada sadece Satış departmanlarına ait

bölümlerinde çekip işlemeye Data Mart adını verebiliriz.

OLAP : Çevrimiçi Analitik İşleme olarakta bilinen OLAP en çok kullanılan analizlerden

olan çok boyutlu analizdir. Bu sayede veriyi işletmenin kabul ettiği sınırlar dahilinde bir

7

OLAP küpü içine yerleştirebilir ve bu şekilde detaylı bir analiz gerçekleştirebiliriz. Örneğin;

kullanıcıların satış toplamlarını ürüne, sipariş tarihine, müşteriye ve satıldığı lokasyona göre

ayrı ayrı gösteren bir küp oluşturabilriz.

Data Mining : Veri Madenciliği, veriyi analiz etmek ve veri içerisinde bulunan örnek ve

istatistiklere bağlı olarak tahmin yürütebilmek için matematiksel algoritmalar kullanan bir

çözümdür. Veri Madenciliği çözümleri içerisinde eğilimleri, kümeleri yada istatistiksel

ilişkileri barındıran bir yada daha fazla veri madeni algortiması içerebilir. Örneğin; bir

müşterinin daha önceden almış olduğu malları kullanıp o müşterinin hangi tür ürünlere

eğilim gösterdiği tahmin edilebilir ve müşteriye eğilim gösterdiği ürün kategorisinde yeni

çıkmış bir ürüne ait bilgiler gönderilebilir yada ona benzer özellikler gösteren farklı

müşterilerin almış oldukları diğer ürünler öneri olarak sunulabilir.

Dashboard ve Scorecard : İşletmenin kısa ve uzun vadeli taktik anlayışlarını belirlediği

araçlara verilen isimlerdir. Scoreboard’lar haftalık ve aylık taktik belirlemeye dolayısı ile

uzun vadeli işlemler için kullanılırken Dashboard’lar ise daha kısa süreli örneğin bir iki saat

aralıklarla bile güncellenebilirler. Bu nedenle Dashboardlar içerisinde scoreboard’lar

barındırılabilir.

Raporlama : Standart sabit raporlardan verilen parametrelere bağlı olarak belli seviyelerde

içerisinde gezinebileceğimiz raporlarımız olabilir. Ek olarak raporlama sistemi kullanıcılara

yetkilerine bağlı olarak raporların en güncel durumlarını otomatik olarak sunabilmelidir.

3. İş Zekası Adımları ve Microsoft’un İlgili Araçları ve

Teknolojileri

İş Zekası Adımları

Bir iş zekası projesini kolay bir şekilde yönetebilmek için bir çok şey yapılabilir. Aşağıda

bahsedilen konu başlıkları bir İş Zekası projesini nasıl daha yapısal ve disiplinli bir hale

getirebileceğimiz anlatılmaktadır.

İş Zekası Projesindeki farklı İş Zekası Komponentlerini Alt Projelermiş gibi

Değerlendirmek

Bir İş Zekası projesi; Çekme, Dönüştüme, Yükleme(ETL), Veri Madenciliği(Data Mining),

Çevrimiçi Analitil İşleme(OLAP) ve Raporlama gibi birbirlerinden farklı bir çok alt

komponentten oluşur. Geliştirme aşamasında bu alt komponentlerin her birini Ana Proje

altında alt projeler olarak ayrı ayrı tanımlayarak bu alt projelere özel ihtiyaçları daha

kolaylıkla ortaya çıkarabiliriz. Örneğin; yukarıda da bahsettiğim gibi İş Zekası projesi

8

içerisinde ETL ve OLAP işlemleri o projenin bütününde yer almasına rağmen, ETL, veri akışı

ve bu verilerin işleme sıralamasıyla alakalı işleri yaparken, OLAP ise ETL’de işlenip Veri

Ambarına aktarılmış haline çok boyutlu analizler yapmak üzere tasarlanmıştır. Bu

farklılıklardan dolayı bu iki işlemi ayrı projeler olarak değerlendirmek hem bu işlemlere özel

ihtiyaçların hem de her iki işlem arasında yapılacak bağlantıların belirlenmesini

kolaylaştıracaktır.

Analiz Çözümleri Veri Modellemesi için İşletme Gereksinimlerini Kullanmak

Veri Ambarı ve OLAP küpleri için en önemli unsure işletme ihtiyaçlarını karşılayan Veri

Modelleri kullanmaktır. Bu nedenle veri modelleri oluşturulurken sadece işletmenin

kendisini değil işletmeyle birlikte iş yapan diğer kurumları da, işletmeyle ilişkilerine bağlı

olarak değerlendirip, bu değerlendirme sonuçlarına gore hazırlanmalıdır.

ETL Çözümünde Kullanılacak Veri Kaynakları ve Hedeflerini Belirlemek İçin

Analiz Sonuçları Kullanmak

Hangi Veri kaynağının kullanılacağı ve alınan verilerin nereye yükleneceğinin belirlenmesi

İş Zekası projelerinin en önemli adımını oluşturmaktadır. Bu nedenle projeye başlamadan

önce bu analizlerin düzgün bir şekilde yapılması gerekmektedir. Analiz esnasında aşağıda

yazılı unsurların kesinlikle belirlenmesi projenin başarıyla sonuçlanmasında önemli bir yer

teşkil etmektedir.

1. Kesin Kaynaklar ve bu kaynaklara ait karakteristikler(Veri Tipi vb.)

2. Veriyi çekmek için kullanılacak teknoloji. Örneğin OLEDB kullanarak mı yoksa

ODBC kullanarak mı veri kaynağına bağlanacağız?

3. Çekilecek verinin boyutu

4. Ne sıklıkta veri çekileceği

5. Çekilen veriyi doğrulama ve çevirme işlemine tabi tutulup tutulmayacağı

6. Çekilen verinin saklanması için araya başka veri kaynaklarının alınıp alınmayacağı

İhtiyaç analizi yukarı bahsedilen adımların detaylı bir şekilde tanımlanması işletme için en

uygun ETL çözümünü sunmamızı sağlayacaktır. Bu adımda önemle durulmalıdır çünkü

ETL çözümleri hatalı yada eksik analizler neticesinde çok büyük zaman ve para kaybına

neden olabilirler.

Raporlama Çözümleri İçin Analiz Sonuçları Kullanmak

Bir İş Zekası projesinde OLAP küpleri ve veri kaynakları raporlama amacıyla kullanılabilir.

Raporlama çözümlerinde sıklıkla kullanılan yöntem son kullanıcıların hali hazırda

kullandıkları raporları örnek alıp o raporlara uygun çözümler sunmak işimizi

kolaylaştırabilir. Aynı şekilde yeni projeyle yeni raporlama ihtiyaçlarıda ortaya çıkacağından

bu ihtiyaçların karşılanması için, yöneticiler, son kullanıcılar, kısacası tüm kademelerdeki

çalışanların görüşleri alınıp alınan bu görüşlerin dokümante edilmesi gerekir. Tüm

raporlama çözümleri aşağıda yazılı unsurları ne kadarını karşılayacağı önceden

belirlenmelidir.

1. Detay seviyesi

2. Rapor üretim sıklığı

ETL süreci, veri ambarı olayının en meşakkatli işi diyebiliriz. Veri ambarı kurulduktan sonra hergün devam eden aksadığında organizasyonda yüksek seslerin çıkmasına sebep olan, sürekli düzgün gitmesi de mümkün olmayan, organizasyondaki tüm teknik sistemlere dokunan bir iş. Her ne kadar ne yaparsan yap yine sıkıntı kaçınılmaz gibi bir resim çizmiş olsam da işin en başından bazı durumlar için kafa yorarsak bu problemleri minimize edebiliriz.

Veri ambarı projesinin ETL’e bakan kısımlarını yürütürken alacağımız kararlar, üstünde düşünmemiz gereken bazı konuları sıralayalım:

1. ETL işi için bir ürün satın almalı mıyız yoksa in-house çözümlerle bu işin üstesinden gelebilir miyiz? Veri ambarınin ilk çıktığı zamanlarda in-house çözümlerle bu işler götürülmüş ama günümüzde çok gelişmiş ürünler var dolayısıyla hazır bir ürün kullanmak işleri kolaylaştıracaktır. Her şeyden önce hiç kod yazmadan sürükle bırakla bir sistemden diğerine veri transferi yapmak mümkün. Bunun dışında, herhangi bir ürünle staging olayını ortadan kaldırıp direk final formda veri ambarında tabloları tutabiliriz. Çünkü etl ürünleri artık her türlü transformasyonu memory üstünde yapabiliyor. dolayısıyla önce aynen bir staging alana alayım sonra ordan sql ile transform edeyim derdi yok. Bir avantajı da ürünlerin tüm süreci yönetip, izlemeyi sağlayan önyüzler sağlaması. Etl ürünü almayı tercih etmezsek, her şeyden önce bir tasarruf yapmış oluruz. Ürün olduğu duruma göre çok yavaş da gitmez aslında işler ama bakım aşamasında işler biraz zorlaşacaktır. Lisanslama ücretleri fazla geliyorsa bir de yeni bir ürüne adaptasyon, eğitim ihtiyacı vs gibi sebepler ürün almayalım noktasına götürebilir şirketleri. Kaldı ki, gerçekten süreç iyi yönetilip standartlar oluşturulursa gayet de güzel gider işler ama her durumda bir scheduling ürününe ihtiyaç olacaktır.

2. Hangi tablolar hangi sıklıkta veri ambarına alınmalı? Bu konu aslında kullanıcı ihtiyaçlarına bağlı bir durum. Kullanıcılar kimi tabloların her gün, kimi tabloların haftada bir, kimisinin de belki de saatte bir güncellenmesini isteyebilir. ETL sürecinde günlük yüklemenin sistemi zorlayacağı durumlar olabilir. Bu durumlarda problem belirtilip kullanıcıyla mutabakata varmak gerekebilir veya analiz netleşmemişse hangi veri hangi sıklıkta gereklidir konusunda ihtiyaç analizi atlanmamalıdır.

3. Tabloları kaynak sistemden alırken her defasında tüm tabloyı yeniden mi almalıyız yoksa sadece değişen kısmı mı almalıyız? Bu konu da üzerinde fazlaca düşünülmesi gerekilen bir konu. Zaman kısıtı yoksa tüm tabloları yeniden almak çok kolay ve sağlam bir metot ama ne yazık ki zaman kısıtı hep var. Dolayısıyla kaynak sistemde, veri ambarına son yükleme tarihinden sonra hangi kayıtlar eklendi, hangi kayıtlar güncellendi ve hangi kayıtlar silindi sorusuna cevap bulabiliyor olmalıyız.(Bu olaya Change Data Capture(CDC) deniyor.). CDC yöntemlerinden ayrıca bir yazımızda bahsedeceğiz ama ETL sürecinde düşünülmesi gerekilen en önemli konulardan biri olduğunun altını çizmek lazım.

4. Staging yapmalı mıyız? Hangi tablolarda yapmalıyız? Bu konu da performansı direk etkileyen konulardan biri şöyle ki daha önce de belirttiğimiz gibi artık ETL ürünleriyle hiç staginge ihtiyaç duymadan her türlü transformasyonu yapıp direk final tabloya load edebiliyoruz. Bu durumda tekrar tekrar diske yazma işlemi yapmaktan kurtuluyoruz dolayısıyla ciddi bir hızlanma sağlanıyor. Ancak, bazı durumlar bu yaklaşımı değiştirmeye itiyor. Birincisi, CDC yaparken son load zamaninin verisine ihtiyaç duyulabilinir. İkincisi, büyük tablolarda tablonun alınıp havada transform edilip load edilmesi süresi uzun bir süre ve bir şekilde kesilmesi durumunda (OS veya DB vs kaynaklı olarak) zaman kaybı olacak. Genelde basamakları kısa tutmak gibi bir yaklaşım hep daha sağlamdır. Son bir sebep de transformasyon işleminde olabilecek problemleri kontrol etmek için kaynak sistemi sorgulamak zorunda olmak. Dolayısıyla staging yapmalı mıyız, hangi tabloları yapalım hangilerini yapmayalım konusu üstünde düşünülmesi gerekilen bir konu.

5. Veri kalitesi(Data Quality) ile ilgili yaklaşım ne olmalı? Veri kalitesi işi genelde Veri ambarı grubuna yıkılan bir iş oluyor dolayısıyla ETL sürecinde bunun için de bazı önlemler almak akıllıca olabilir. Kaldı ki kalitesiz veri zaten bazı varsayımlarımızı bozup ETL işlerinin patlamasına sebep de olabilir. Şöyle ki cinsiyet tutulması gereken kolonda ERKEK veya KADIN gibi değerler olacağını varsayarız buna göre transformasyon işlemleri yaparız fakat bu kolon da beklemediğimiz bir değer geldiğinde bu kaydı ne yapmalıyız? Kimball der ki, bu gibi durumlar için hem fact hem dimension tablolarında bir quality kolonu bulundurun ve böyle varsayım dışında kalan durumlarda o satırı işaretleyin ki veri kalite problemlerini görebilelim. Başka bir yaklaşım bu gibi durumlarda bu satırı komple başka bir hata tablosuna atıp esas tabloya atmamak olabilir ama hatalı kolondan bağımsız alınabilecek raporları kurtarmak adına bu yaklaşım çok sağlıklı değil.

6. ETL’in düzgün çalışıp çalışmadığını anlamak için nasıl bir mekanizma kurabiliriz? Problem olduğu düşünülen durumlar olduğunda kontrol amaçlı olarak transform edilmiş ve rapora açılan tablo ile kaynak tabloyu kıyaslamak durumunda kalıyoruz. Ancak normal süreçte tüm tablolar için bu kontrolü yapmak sürdürülebilir bir iş olmuyor. Bu amaçla şöyle bir yaklaşım geliştirebiliriz: Bazı istatistikî değerler için kabul aralıkları oluşturup ilgili günün o istatistik değerlerinin bu kabul aralığında olup olmadığını bir sql script yardımıyla yapıp sonuçları bir tabloya yazmak işleri çok kolaylaştırabilir. Başka bir yaklaşım olarak da önce kaynak sistem üstünde bazı istatistikler alıp sonra veri ambarında aynı istatistikleri alıp arada bariz fark olup olmadığını kontrol etmek olabilir. Bu istatistikî değerler; toplam satır sayısı, ortalama tutar gibi genel bazı değerler olsa da hata olup olmadığını çıkartmamızı sağlayacaktır.

7. Kaynak sistemlerde yapilan degisikliklerin veri ambarına etkisini nasil kontrol altinda tutabilirim? Bu konu ETL işlerinin patlamasina en fazla sebep olan konu diyebiliriz. Kaynak sistemdeki bir tabloda yapılan kolon ekleme, kolon çıkarma, kolon özelliğini değiştirme gibi durumlarda ETL işlerine müdahale edilmezse sonuç işlerin hata almasi şeklinde oluyor. Bu problemle baş etmenin ideal yolu kaynak sistemlerde yapılan değişikliklerin veri ambarına bildirilmesi için arada bir anlaşma yapmaktır ama ne kadar sadık kalınır tartışılır. Ama en azından geliştirme yaparken kaynak sistemde değişiklik yapılabileceği akılda bulundurularak yapılmalı. Mesela select * from.. şeklinde değil de select kolon1, kolon2 … gibi ifadeler kullanırsak bile kaynağa kolon eklenen durumlardan etkilenmemiş oluruz.

8. Değişen dimensionları(Slowly Changing Dimension(SCD)) nasil implement etmeliyiz? Sonrasinda ek iş çıkarmamasi açısından hangi SCD’lere hangi stratejiyi uygulayağımız belirlenmelidir. ETL sürecine gelene kadar bu alanda analiz yapılmamışsa, analiz yapılıp gereksinimlere göre strateji belirlenmelidir.

9. Yükleme performansını nasil kontrol altında tutabiliriz? Yükleme sürelerinin bazı sebeplerle(İşletim sistemi, network, kaynak sistemdeki değişiklik) hiçbir ek geliştirme olmasa da arttığını gözlemleriz. Bunun kaynağına inmeyi kolaylaştırmak için belli adımların çalışma sürelerini tutmak önemlidir dolayısıyla hangi adımın gereğiden fazla sürdüğü kolayca belirlenip ona göre aksiyon alınabilir.

ETL Programı almalı mı, almamalı mı?

Veritabanı seçimi yapılırken, analitik bir değerlendirme yapılmaya çalışılsa da, seçenekler, yöneticilerin başkalarından duyduğu teknolojilerle şekilleniyor. Bu kişisel bilgilerin de birçoğu veritabanları daha tam oturmamışken oluşan önyargılarla şekilleniyor. Sorumluluğu minimuma indirmek için, yapılan işin ne olduğundan çok satış elemanlarının ön plana çıkardığı noktalar göz önünde bulunduruluyor. Aslında bunu başlı başına başka bir yazıda ele almak gerekli. Bu yazıda ETL programı seçimi konusunda sorulması gereken sorulardan bahsedeceğim. Konu zaten sorular olduğu için, yazının sorular üzerinden ilerleyeceğini şimdiden belirtmek isterim. İ

lk olarak sormam gereken soru şudur, “bu tercih edilen veritabanıyla tam olarak entegre çalışabilecek bir program mevcut mu?” Bu programı kullanan bir ETL çalışanına sorulması gereken soru ise, program bize elle yazılan koda göre ne gibi bir avantaj sağlayacak? Eğer bu iki sorunun cevabı bizi tatmin ediyorsa programın işe yarayacağı net olarak ortadadır. Öbür taraftan cevabın net olmaması ise projeden beklentiyi belirler. “Ne kadar esnek olmayı planlıyorsunuz?” sorusu aslında “hangi sorumluluklardan kaçmayı, hangi sorunlara göğüs germeyi göze alıyorsunuz?” sorusunun cevabına paralel olacaktır. Eğer kaynak sistemlerden alınan veriyi test edip, kriterlerinize uymadığı noktada yöneticilerden yağacak email’lara karşı dimdik duracağınızdan eminseniz, bir ETL programı kullanılması kararını rahatlıkla verebilirsiniz.

Buna karşılık, eğer her gelen isteğe cevap vermek gibi bir yükümlülüğünüz varsa alınacak ETL programının esnek olmasına dikkat edilmesi gerek veya hiç almamak gerek. Yeterince esnek olmadığı için bir program almadığınızı düşünün. Bu durumda dikkat etmeniz gereken, program almayarak aslında gelecek her türlü teknik soruna çare bulabileceğinizi taahüt etmiş oluyorsunuz. Bu karar verilmeden önceki durumla, verildikten sonrası arasında çok büyük bir fark var. Program kullanma kararı verilince, işe alınacak personelin, programın sahip olduğu özellikleri ne kadar kullanabileceğine bakılmalı.

Misal, Oracle Data Integrator (ODI) kullanılmasına karar verilmişse işe alınacak kişilerin ODI kullanmayı bilmesi aslında tam olarak yeterli değil. ODI kendi içinde Jython kullanabilir, shell script’leri çalıştırılabilir, PL/SQL kodu kullanılabilir bir program. Programın avantajlarının tam olarak kullanılabilmesi için çalışanların bu teknolojileri bilmesi gerekli. Bir de bunların üzerine ODI’nin getirdiği ek paketler mevcut ki bu durumda mevcut çalışanların en az 6 aylık bir eğitim sürecine girmesi gerekmekte.

ODI sadece bir örnek. İster Pentaho olsun, ister Informatica ya da başka bir program, spesifik gereklilikler daima olacaktır. Buna karşılık program alınmadığı durumu düşünelim. Doğrudan kaynak veritabanlarına bağlanılmalı, işletim sistemi seviyesinde çıkacak sorunları çözmeli, gelecek geliştirme isteklerine cevap verebiliyor olmalılar. Sizin de farketmiş olacağınız gibi bilgi birikimi her iki seçenekte de oldukça gerekli. Bir program kullanılıyorsa, gerekli olan birikim tanımlanabiliyor (Jython, PL/SQL gibi). Ancak program kullanılmadığında engin bir bilgi birikimi ve bir o kadar da adapte olabilecek çalışanlar işe alınması gerekiyor. http://www.gna.com.tr/blog/ dan alıntı

Veriambarı bir organizasyonun elektronik olarak saklanan datasının deposudur.Veri

ambarları raporlama ve analizi kolaylaştırmak için dizayn edilmişlerdir. Veriambarları analiz ve ilişkili verilerin sorgulanabildiği sistemlerdir.Birden fazla kaynak sistemin işleme tabi tutulmasıyla oluşmuştur.Ayrıca bu şekilde anlık işlemlerin gerçekleştiği veritabanlarındaki tutarsızlıkların ve kirli verilerin filtrelenerek analiz ve raporların etkilenmemesi sağlanmıştır.

 

Veri ambarının yapısı genel itibariyle şu aşamalardan oluşur;

 

1.Kaynak sistem:Günlük işlemlerden gelen kayıtların(transactionların)kaydedildiği

veritabanlarıdır.Bu veritabanları genelde tek bir işlev için normalize edildikleri için bunların hem raporlamada hem de işlemler için kullanılmaları verimi düşürür.

 

2.ETL(Extract-Transform-Load):ETL sürecinin ilk parçası olan extract aşamasında veri kaynak sistemlerden

 

ortaya çıkmaktadır.Bu şekilde farklı kaynaklardan gelen datalar üzerinde daha etkin ve kolay şekilde sorgulama yapılabilmektedir.

 

 

Veriambarları iş    zekası çözümlerinde de kullanılmaktadır.İş zekası daha iyi iş kararları verebilmek amacıyla kullanılmaktadır[2].Veriambarları günümüzde birçok sektörde kullanılmakla birlikte özellikle rekabetin yoğun olduğu telekomünikasyon sektöründe kullanılmaktadır.Burada abonelere sunulan kampanyaların sonuçları,verilen bonusların kullanılma durumu gibi çeşitli işlevlerin yanında özellikle numara taşıma sonrası abonenin gidebileceğini tahmin eden algoritmalar da kullanılmaktadır.

 

 

Günümüzün bilgi çağı olmasından dolayı sürekli artan veri miktarının saklanması için veritabanları sürekli artmıştır.Ancak bu veritabanlarında bulunan veriler raporlama ve analiz için kullanılmaya uygun değildir.Bu verileri raporlama ve analizde kullanabilmek için buradaki ham bilginin kulanılır şekile dönüştürülmesi gerekmektedir.

 

 

Genel itibariyle veri tabanları hızlı ve etkin veri girişi,çıkışı ve güncellemesi için tasarlanmışlardır.Ancak bu yapılarda analiz ve raporlama için gereken algoritmaları çalıştırarak analiz ve raporlamaları gerçekleştirmek çok zordur.Bu nedenle yeni bir veritabanı oluşturularak bu yeni veritabanına sadece analiz ve raporlamada kullanılacak verilerin taşınması gerekliliği çekilir.Genellikle veriambarları birden fazla farklı kaynak sistemi kullanmaktadır.

 

 

Bu kısımın esasında çekilen verinin beklenen yapıya uygun olup olmadığının kontrol edilmesidir.Eğer değilse veri veriambarına alınmaz.

 

 

ETL sürecinin ikinci ayağı olan transform(dönüştürme)aşamasında ise birçok kural ve fonksiyonun extract edilen veriye uygulanmasıdır.Bu sayede iş ve teknik taleplei karşılayan hedeflenen veri kaynaktan türetilmiş olmaktadır.

 

 

ETL sürecinin son ayağı olan load(yükleme) aşamasında ise veri veriambarına yüklenir.Ancak bu işlem iş isteklerine göre değişebilmektedir.Mesele kimi işletmelerde mevcut veriye eklenerek giderken,bir kısmında haftalık olarak yenilenmekte ya da tarihsel olarak yeni data eklenmektedir.

 

 

1.Metadata: Veri hakkındaki bilgilere metadata denilmektedir.Veriambarında bulunan herbir veri elemanının anlamını,hangi elemanın hangi elemanlarla ilişkisi olduğunu,bu ilişkinin hangi şekilde gerçekleştiğini ve kaynakta bulunan veri ile hedefteki veri gibi bilgileri kendine tutmaktadır.

 

2.Front-end:Kullanıcı tarafında raporlama ve analizde kullanılmak üzere çeşitli araçlar kullanılarak veriambarına erişmesidir.

 

2.YAZILIM TEST

 

 

Bir program veya sistemin özelliğinin veya yeteneğinin değerlendirilmesi ve beklenen

sonuçlarım gözlemlenebilmesi için yapılan aktivitelere yazılım testi denilmektedir [3].

 

Yazılım testi genel itibariyle müşteri talepleri doğrultusunda geliştirilen bir yazılımın, kalite düzeyi müşteri tarafından belirlenen maliyet analizi göz önüne alınarak,müşterinin beklediği kalitede olup olmadığının belirlenmesi sürecidir.Yazılımlardaki hatalar geliştirici,analist gibi insan kaynaklı olmakla birlikte donanımsal kaynaklı da olabilmektedir.Bütün yazılım hatalarıkodlama hatası olmayabilir.Pahalı hataları meydana getiren ortak kaynak ihtiyaç analizleridir.Beklenilmeyen ihtiyaçlar yazılım dizaynırı tarafından ele alınmaz[4].

 

 

Yazılım geliştirme süreçlerine testin eklenmesinin nedeni yazılım geliştirme süreci sonucunda ortaya çıkan hataların müşteriye geri dönülmesi zor durumlara bırakmamasını sağlamaktır.Çünkü yazılımlarda bulunan bir hata canlıya alındığında yazılımın yaptığı işe göre bir şirkete itibar,para ve müşteri kaybına neden olabilmektedir.Tüm bunların önüne geçebilmek için test süreçlerini yazılım sürecinin içerisine yerleştirmek gerekiyor.

 

 

Yazılım doğrulama(verification) ve onaylama(validation)’nın birleşiminden oluşur.

Doğrulama:Yazılımı doğru yaptık mı?

Onaylama:Doğru yazılımı yaptık mı? 

 

 

Yazılım test süreçlerini aşağıdaki şekilde sınıflandırabiliriz;

Sistem bilgisine göre;

 

1.Black box test;

 

2.White box test;

 

3.Gray box test:

 

Yazılım yaşam döngüsünde çalıştırılma zamanına göre;

 

1.Unit test

 

2.Entegrasyon testi

 

3.Sistem testi

 

4.Kullanıcı onay testi

 

Testleri amaçlarına göre de sınıflandırabiliriz;

 

1.İşlevsel test:Yazılımın işlevsel yönünün irdelendiği testlerdir.Burada verilen bir girdinin

analize göre beklenilen çıktının verilip verilmediği test edilir.İşlevsel test yazılım yaşam

döngüsünün tüm anlarında yapılan testlerde kullanılabilir.

 

1.1.Yükleme testi(Installation test) : Kullanıcının ilk etkileşimi yazılımı yükleme sırasında oluşmaktadır.Farklı platformlarda yazılımın sorunsuz şekilde yüklenebildiği kontrol edilmelidir.Kullanıcı kurulumda sorun istemediği için çok önemli bir testtir.

 

1.2.Regresyon testi(Regression Test) : Regresyon testlerinin amacı yapılan bir hata düzeltmesinin veya bir değişikliğin halihazırda sorunsuz çalışan kısımları etkilemediğinin görülmesidir.

 

1.3.Yükseltme ve uyumluluk  testi(Upgrade and backward compatibility testing) : Her yazılımın sürekliliğini sağlamak için yükseltme sürümleri yapılır.Ancak bu sürümlerin önceki

sürümlerlerle uyumlu olması gerekmektedir.Bu nedenle bunun testinin yapılması gerekir.Bu teste uyumluluk testi adı verilir.

 

Yükseltme testinde ise kullanıcının efor sarfetmeden ve sistemini bozmadan bir yazılım yükseltmesi yapması beklenir.Bunun kontrolü için de yükseltme testi yapılır.

 

1.4.Erişilebilirlik testi: Kullanıcıların görsel,işitsel veya bedensel engelleri olabilir.Yazılımın bu kullanıcılar için çeşitli kolaylık sağlaması gerekmektedir.Bu nedenlede bu özelliklerin fonksiyonel testler sırasında kontrol edilmesi gerekmektedir.

 

1.5.Uluslararasılalıştırma ve yerelleştirme testi : Yapılan yazılımların diğer ülkelerde satışa sunulacak ise yazılımın bu ülkeler için uyumlu olması gerekmektedir.Bunun için yazılımın GUI’si,mesajlar,uyarı ekranları vb. Kısımlarının yerel dille yazılmış olmalıdır.Ayrıca bu değişiklikler yazılımın düzgün çalışmasını engellememelidir.

 

 

2.İşlevsel olmayan test: Test aktivitelerine odaklanılan,yazılımın işlevsel olamayan yönünü

irdeler,

 

2.1.Performans,yükleme ve stres testleri :  İşlevsel testlerden sonra yapılan bir testtir.Genel itibariyle bir kodlamanın hataları düzeltilmesinden sonra yapılır.Genel olarak web uygulamalarında kullanılır.Burada belli bir yük altında iken   sistemin cevap zamanı ve kullanımı testleri yapılır.

2.2.Kullanılabilirlik testleri :  Bir sistemin ne kadar kolay kullanılabilir ve öğrenilebilir olduğuyla ilgili testlerdir.Bu testler sayesinde müşteri memnuniyetiyle satışlar artar,destek için ayrılan kaynak azalır.

2.3.Güvenlik testleri : Güvenlik testindeki birincil amaç güvenlik açıklarını tespit etmek ve bunları tamir etmektir.Güvenlik testi genellikle kodlama  ve yükleme yapılıp operasyonel hale geldikten sonra yapılır. Bu test diğerlerinin aksine periyodik olarak ağ güvenliği için sistemin tüm güvenlik açıklarını tespit etmek için kullanılır.

 

 

 

3.VERİAMBARI PROJESİNDE TEST PROSEDÜRLERİ

 

 

Şirketimizin yapmış olduğu veriambarı projesinde kullanılan veri miktarı çok fazla olduğu için veriambarlarında kullanılan PL/SQL kodlarıyla verinin işlenmesi yetersiz kalmaktaydı.Bu nedenle ABINITIO adında ETL  (Extract,Transform,load) aracı kullanıldı.Bu aracın özelliği parametrik şekilde ayarlanarak paralel işlem yapabilmesidir.Bu nedenle çok büyük verileri kolaylıkla kısa zamanda işleyebilmektedir.

 

 

Bu araç tablo bazlı işlem yapmamaktadır.Yani bir veri işlenmeden önce tablodan dosyaya inilmeli sonrasında raporlamada kullanılmak üzere işlem sonrasında tekrar veriler dosyadan tablolara çıkılmaktadır.

 

Bu aracın bir diğer özelliği yarı görsel olmasıdır.Geliştirme hem görsel komponentler kullanılarak hem de kodlama yapılarak halledilmekteydi.

               

 

Bu projede yapılan geliştirmelerin testleri yukarıda bahsedilen testlerin  tamamı yapılamamıştır.Nedeni de sürenin kısıtlı olması ve bu nedenle bazı sorunlar geliştirme canlıya alındıktan sonra çıkmakta ve canlıda düzeltilmekteydi.

Yapılan testleri anlatacak olursam;

 

 

1.Yapılan geliştirme test grubuna ulaştığında öncelikle run olup olamadığı testi yapılmaktaydı.Yani giriş dosyaları veildiğinde dml hataları varmıydı,geliştirmenin çıkışında data oluşup oluşmadığıyla ilgili genel yapıyla alakalı testler yapılmaktaydı.Bu kısımda işlevsel testimizi halletmiş oluyorduk.

 

 

2.Canlıdan alınan güncel verilerle geliştirme run edilmekteydi.Bu şekilde oluşan çıkış verileri   ‘Veri Kalitesi’(Data Quality) testlerinde kullanılmak üzere tablolara yüklenmektaydi.Daha sonrasında bizler giriş veri tablolarını verilen analize göre SQL kodlamasıyla çıkış veri tablosunu oluşturmaktaydık.Son aşamada ABINITIO geliştirmesinin çıkış verisiyle,bizim yaptığımız SQL kodunun çıkış verisi  SQL’in ‘MINUS’ özelliği kullanılarak çıkış verisinin doğruluğu test edilmekteydi.

 

3.Incremental run   yapılarak geliştirmenin bir sonraki gün gelecek yeni insertleri,updateleri ve delete datalarını işleyip işleyemediğinin testini yapıyorduk.

 

 

4.Extraction ve load shell script kodlarının doğru şekilde tablolardan verileri çekip,tablolara düzgün şekilde yüklemesinin  testini yapıyorduk.

 

 

5.Canlıda olan bir geliştirmede hata bulunduysa düzeltmesi yapıldıktan sonra tüm geliştirme tekrardan bütünlüğünün bozulup bozulmadığıyla ilgili teste tabii tutulmaktaydı.

 

 

6.Performans testlerinde yapılan geliştirmelerde işlem tekrarlarının azaltılması yönünde yapılan geliştirmeler gözden geçirilmekte ve geliştiriciye bununla ilgili geri dönüş yapılmaktaydı.

Yukarıda bahsettiğim gibi yapılan testler daha fazla çeşitlendirilebilirdi.Ancak bir proje dahilinde kısıtlı zaman içerisinde yapıldığından dolayı test çeşidi olarak bu kadar yapılmıştır.

 

Okan Beşli

İ.Hakkı ÇAVDAR

 

 

 

 

Merhaba,

ETL süreçlerini ve faydalarını iyi analiz edebileceğimiz bir yazı paylaşıyoruz.Bunun için Avea BT Sistemleri Direktörü Cahit Beyle roportajdan bir bölüm yayınlayalım.

Avea BT Sistemleri Uygulama Geliştirme Direktörü Cahit Terzioğlu

"IBM Information Server DataStage ürününü işimizin kritik bir bileşeni olarak görüyoruz"

Operasyonal sistemlerinden analiz sistemlerine hızlı, düzenli ve uygun formatta veri akışını sağlamada bir ETL aracından faydalanmaya karar veren Avea BT ekibi, veri entegrasyonu ihtiyaçlarına yanıt verecek en uygun çözüm olarak IBM Information Server DataStage yazılımını seçti. Türkiye'nin önde gelen mobil iletişim operatörü olan Avea'nın BT Sistemleri Uygulama Geliştirme Direktörü Cahit Terzioğlu, son derece rekabetçi olan mobil iletişim pazarında iş başarısı için datawarehouse sistemlerinin sağlıklı sonuçlar üretmesi gerektiğini, bunun için de DataStage gibi bir veri entegrasyonu aracı kullanmanın zorunlu olduğunu belirtiyor.


"Avea'da, operasyonel anlamda diğer sektörlerle karşılaştırılamayacak büyüklükte ve sayıda veri oluşuyor ve sürekli bir değişim söz konusu. Verinin analiz yapılabilecek bir seviyeye getirilmesi oldukça zahmetli bir işlem. Bu nedenle seçeceğimiz veri entegrasyonu aracının hızlı bir şekilde geliştirmeye, konfigürasyona açık olması, büyük datayla çalışmayı becerebilecek bir altyapı sunması gerekiyordu. DataStage, bizim bu tür beklentilerimizi tamamen karşıladı."
Okan Karaduman
AVEA Teknoloji İş Zekası ve Kurumsal Sistemler Müdürü


Avea'nın şirket profili ve faaliyet alanı hakkında bilgi alabilir miyiz?

CAHİT TERZİOĞLU: Avea, 9 milyon abonesi ile Türkiye'nin en genç ve yenilikçi mobil iletişim operatörüdür. "Avea" markası ile gerek kurumsal gerekse bireysel hizmetlerimizle hızla büyümekte, gerek teknoloji ve altyapıya, gerekse yönetim ve çalışanlarımıza sürekli olarak yatırım yapmaktayız. 1.900 çalışanı, 165 ülkede 371 operatörle serbest dolaşım anlaşması bulunan bir şirket olarak, müşteri ihtiyaçlarını birincil önceliğe yerleştirip, onlara en kaliteli hizmeti sunan öncü şirket olma vizyonu ile müşterilerimize son teknolojinin yanı sıra yenilikçi ve kaliteli hizmetler sunmaktayız.

Veri entegrasyonu konusunda IBM Information Server DataStage uygulamasını kullanıyorsunuz. Sizden öncelikle proje öncesi durumunuz ve ihtiyaçlarınızı öğrenebilir miyiz?

CAHİT TERZİOĞLU: Proje öncesinde bir veriyi datawarehouse sistemimize aktarma konusunda klasik yöntemlerimiz vardı. Bu yöntem dolayısıyla, operasyonel anlamda yazılımın yürütülmesi, üretilmesi aşamasında oldukça zorlanıyorduk. Verilerimizi daha hızlı ve datawarehouse sistemine uygun formatta, zamanında ve düzgün bir sıralamayla aktarabilmek için araştırmaya başladık. Amacımız, operasyonel yükü mümkün olduğu kadar ortadan kaldırmaktı. Kullandığımız yöntem bizim için çok yetersiz hale gelmişti. Endüstri standartlarına uygun ETL araçlarından birini seçmemiz gerekiyordu.

Çözüme nasıl karar verdiniz?

CAHİT TERZİOĞLU: Pazardaki güçlü alternatifleri araştırdık. Bir değerlendirme sürecinden geçtik ve değerlendirmenin sonucunda da en iyi çözümün DataStage olacağına karar verdik. Oldukça da hızlı bir şekilde DataStage'i devreye sokarak, hem gerekli düzenlemeleri yaptık hem de zamanında ve düzgün bir veri akışını sağladık.

Geçiş süreciniz hakkında bilgi verebilir misiniz?

OKAN KARADUMAN: Öncelikle "Unrated CDR" yani "ücretlendirilmemiş veri kaydı" olarak adlandırdığımız, hacimsel anlamda yoğun olan bölümden başladık. Daha sonra datawarehouse sistemimizi besleyen diğer sistemlerimizi de bu çalışmaya dahil ettik. En zorlu sürecimiz veri kaydının içeriye yüklenmesiydi. İlk önce "ücretlendirilmemiş" ardından da "ücretlendirilmiş" veri kayıtlarını içerecek biçimde projemizi sürdürdük.

Verilerinizi doğuran operasyonel uygulamalarınızdan söz edebilir misiniz?

CAHİT TERZİOĞLU: Ücretlendirilmemiş veri kayıtlarımız ?mediation' ortamımızdan geliyor. Mediation, network tarafında her türlü ses, data, SMS gibi kayıtları ve bunlardan üretilen verileri faturalama ve diğer ilgili sistemlerimize aktarmak üzere merkezi olarak toplayan ve yönlendiren bir alan. Ücretlendirilmiş veri kaydı ise bir ?billing' uygulaması üzerinden akıyor. Çok büyük bir hacimden söz ediyoruz, çünkü toplam müşteri sayımızın yaptığı tüm konuşmaların sonucunda ortaya çıkan, günlük hatta saatlik veri kayıtları bunlar.

Bütün bu yapıyı düşünürsek, DataStage'den beklentileriniz nelerdi?

OKAN KARADUMAN: Sözünü ettiğimiz bu operasyonel sistemden, analitik sisteme, yani datawarehouse sisteme veri akışı için DataStage'i kullanıyoruz. Datastage, akan veriyi alıp, formatlayıp, datawarehouse sistemine yüklüyor. Operasyonel tarafta diğer sektörlerden çok daha fazla veri oluşuyor ve sürekli bir değişim söz konusu. Çünkü müşterilerimize devamlı yeni teknolojik hizmetler sunuyoruz ve bu hizmetler yeni kayıtlar anlamına geliyor. Bizim veri entegrasyonu anlamında bu değişime çok hızlı uyum sağlamamız gerekiyor.Verinin analiz yapılabilecek bir seviyeye getirilmesi oldukça zahmetli bir işlem. Bu nedenle seçeceğimiz ETL aracının hızlı bir şekilde geliştirmeye, konfigürasyona açık olması, büyük datayla çalışmayı becerebilecek bir altyapı sunması gerekiyordu.
Gün içinde hatta saatler içinde oluşan verilerimiz, bazı şirketlerin yıllık verilerine eşdeğer olabiliyor. Bizim bu datayı zamanında, analiz ortamına atıp, analizini yapıp, sonuçları pazarlama, finans, satış departmanlarımızla paylaşmamız söz konusu. Bu sonuçların hızla paylaşılabilmesi, içinde bulunduğumuz yoğun rekabetçi pazarda hayati önem taşıyor. Bu bilgiler ilgili departmanlarımıza zamanında ulaşmazsa hiçbir değer ifade etmiyorlar. Bu yüzden DataStage bizim için önemli.

DataStage'in özelliklerini değerlendirebilir misiniz? BT departmanları açısından düşünürsek, ne gibi avantajlar sağlıyor?

OKAN KARADUMAN: Birincisi standardizasyon getiriyor. DataStage'i ayrı bir makineden sistemimizi durdurmadan yönetebiliyoruz. Bu süreçte doğrudan datawarehouse sistemindeki veri tabanları üstünde güncelleme yapmıyor, bu tranformasyonu kendine ait olan sunucuda gerçekleştiriyor ve sadece yükleme aşamasında datawarehouse uygulamasına erişiyor. Bu da uygulamanın kesintisiz hizmet vermesini sağlıyor. IBM Information Server ürünlerinin bizim henüz kullanmadığımız ama faydalı olduğunu gördüğümüz özelliklerini de önümüzdeki yıl devreye almayı düşünüyoruz. Örneğin, veri kalitesinin sağlanması ve kirliliğin arındırılmasına ilişkin avantajlar sunduğunu biliyoruz. Sonuç olarak, DataStage'in bundan sonra yürüteceğimiz projelerimizde de, verilerimizi hızlı bir şekilde uygun formata ve uygun sıralamaya getirerek, veri kalitesini sağlayarak destek olmasını bekliyoruz.

IBM ve IBM Çözüm Ortağı OBase ile ilişkilerinizi ve müşteri memnuniyetinizi değerlendirebilir misiniz?

CAHİT TERZİOĞLU: OBase, uzun zamandır işbirliği içinde olduğumuz bir firma ve yetkinliklerine güveniyoruz. Bu projede de başından bu yana daima yanımızda oldular. DataStage ürününün IBM gibi, lider bir teknoloji firması tarafından sunuluyor olmasından da çok memnunuz. Tamamen bir tesadüf olarak datawarehouse donanım platformumuzun da IBM ürünlerinden oluşması dolayısıyla bu memnuniyetimiz daha da artıyor. IBM'le şirketimizin kurulumundan bu yana sıkı bir işbirliğimiz var. Bizim için ürünlerin sürdürülebilirliği son derece önemli ve IBM ile de bunu sağlayabileceğimizi biliyoruz.