Oracle Data Integrator kurulduktan sonra master ve work repositoryleri oluşturulması hakkında makalemizi paylaşıyor olacağım.Bu makaleyi link vermeden veya sitemizin ismi geçmeden paylaşabilirsiniz.Önemli olan bu yazıyı okurken bizim sizlere küçükte olsa bi katkı sağlayabilmemizdir.
Master Repository : Şirketin IT kaynaklarının yapısını , güvenlik bilgilerini , proje ve veri kaynaklarıyla ilgili bilgilerin tutulduğu repository’dir.Sadece bir tane master repository gereklidir.
Work Repository : Veri kaynakları , projeler ve kullanımlarıyla ilgili bilgilerin tutulduğu repository’dir.
Repository’leri yaratmak için adım adım şunlar yapılmalıdır :
Repository disk alanları yaratılır.
Master Repository yaratılır.
Master Repository’e bağlanılır.
Work Repository yaratılır.
Work Repository’e bağlanılır.
NOT : Repositoryler ANSI ISO 89 syntaxını destekleyen her hangi bir ilişkisel veri tabanında yaratılabilir.Her bir repository için 200 mblik yer gereklidir.
REPOSITORY DİSK ALANI YARATMA
Oracle : Master repository’e karşılık snpm , Work repository’e karşılık snpw şemaları yaratılır.
SQL> create user
SQL> grant connect, resource to
Örnek :
create user SNPM_MASTER_YUSUF identified by SNPM_MASTER_YUSUF default tablespace USERS temporary tablespace TEMP;
grant connect, resource to SNPM_MASTER_YUSUF;
create user SNPW_WORK_YUSUF identified by SNPW_WORK_YUSUF default tablespace USERS temporary tablespace TEMP;
grant connect, resource to SNPW_WORK_YUSUF;
Microsof SQL Server : Master repository’e karşılık db_snpm , Work repository’e karşılık db_snpw veri tabanları yaratılır.Bu veritabanlarına yetkili snpm ve snpw kullanıcıları yaratılır.
CREATE LOGIN
WITH PASSWORD = '
DEFAULT_DATABASE =
DEFAULT_LANGUAGE = us_english;
USE
MASTER REPOSITORY YARATMA
1-Start Menu, Programs > Oracle Data Integrator > Repository Management > Master Repository Creation seçilir.
2-Aşağıdaki sahalar doldurulur.
Driver : Repository’nin yaratılacağı veri tabanına erişmek için kullanılacak driverdır.
URL : Veri tabanına erişmek için kullanılacak url’dir.
User : “snpm” şemasına erişmek için yaratılan kullanıcı.
Password : Kullanıcının şifresi.
ID : 0’dan farklı spesifik bir id.Repositoryler arasındaki import – export işlemlerini etkiler.
Technologies : Repository’nin bulunacağı teknoloji seçilir.
Language : Master repository’nin dili seçilir.
3- ‘OK’ butonuna basılıp , master repository yaratılır.
Şekil 1 : Master Repository Yaratma Ekranı
MASTER REPOSITORY’E BAĞLANMA
Master repository’e bağlanmak için :
1) Start Menu, Programs > Oracle Data Integrator > Topology Manager seçilir.
2) “New” butonuna basılır.(“Login Name”in yanındaki ilk buton.)
3) Aşağıdaki alanlar doldurulur.
Oracle Data Integrator Connection :
Login Name : Genel bir ad.(Örnek : Repository)
User : SUPERVISOR (Büyük Harflerle)
Password : SUNOPSIS (Büyük Harflerle)
DBMS Connection (Master Repository) :
User : Master Repository’e erişmek için tanımladığınız kullanıcı.
Password : Kullanıcının şifresi.
Driver’s List : Master Repository’e bağlanmak için gerekli olan driver seçilir.
URL : Veri tabanına erişmek için kullanılacak url’dir.
4) “Test” butonuna basılarak , bağlantının çalışıp çalışmadığı kontrol edilir.
5) “OK” butonuna basılır ve “Topology Manager” açılır.
WORK REPOSITORY YARATMA
1) “Topology Manager” ile master repository’e bağlanılır.
2) Açılan ekranda Topology -> Repositories -> Work repositories’e sağ tıklanır ve “Insert Work Repository” seçilir.Açılan ekranda “work repository”e bağlanabilmek için , bağlantı parametreleri girilir.
3) Aşağıdaki alanlar doldurulur :
Name : Work Repository bağlantı adı girilir.
Technology : Work Repository’nin bulunacağı teknoloji seçilir.
User : Work Repository’e erişmek için tanımladığınız kullanıcı.
Password : Kullanıcının şifresi.
JDBC Tabında -> JDBC Driver : Work Repository’nin yaratılacağı veri tabanına erişmek için kullanılacak driverdır.
JDBC Tabında -> JDBC URL : Work Repository’nin bulunacağı veri tabanına erişmek için kullanılacak url’dir.
4) “Test” butonuna basılarak , bağlantının doğru çalışıp çalışmadığı test edilir.
5 ) “OK” butonuna basılarak , Work Repository bağlantı bilgileri ekranı kapatılır.Açılan ekranda Repository için uniq isim ve id girilmesi istenir.
6) “Work Repository” ekranında aşağıdaki parametreler girilir.
ID : Work Repository’e 1’den 998’e kadar uniq bir id verilir.
Name : Work Repository’e uniq bir isim verilir.(Örnek : WORKREP1)
Type : Listeden “development” seçilir.
7) “Ok” butonuna basılır ve “Work Repository” yaratna işlemi başlatılır.
8) “Work Repository” yaratıldığı zaman “Work Repository” ekranı kapanır. “Work Repository”e , “Designer” ve “Operator” modullerinden ulaşılabilir.
WORK REPOSITORY’E BAĞLANMA
Workr repository’e bağlanmak için :
1) Start Menu, Programs > Oracle Data Integrator > Designer seçilir.
2) “New” butonuna basılır.(“Login Name”in yanındaki ilk buton.)
3) Aşağıdaki alanlar doldurulur.
Oracle Data Integrator Connection :
Login Name : Genel bir ad.(Örnek : Repository)
User : SUPERVISOR (Büyük Harflerle)
Password : SUNOPSIS (Büyük Harflerle)
DBMS Connection (Master Repository) :
User : Master Repository’e erişmek için tanımladığınız kullanıcı.
Password : Kullanıcının şifresi.
Driver’s List : Master Repository’e bağlanmak için gerekli olan driver seçilir.
URL : Veri tabanına erişmek için kullanılacak url’dir.
Work Repository :
Work Repository Name : Work Repository yaratırken verdiğiniz isim.(Örnek : WORKREP1)
4) “Test” butonuna basılarak , bağlantının çalışıp çalışmadığı kontrol edilir.
5) “OK” butonuna basılır ve “Topology Manager” açılır.
DEMO PROJE
Start Menu > Programs > Oracle Data Integrator > Examples , Start Demo Environment seçilireke , demo için hazırlanmış olan , repositoryler başlatılır.
DESİGNER’I BAŞLATMA
1) Start Menu > Programs > Oracle Data Integrator > Designer
2) Login Name kısmından uygun olan kullanıcı adı seçilir.Demo için “Getting Started – ETL Project” seçilir ve şifre boş bırakılır.
3) “Ok” butonuna basılarak , repository’e bağlanılır.
4) “Designer” ekranı açılır.(Designer açılırken karşınıza çıkan ekrandan “Close” butonuna basıp , çıkınız.)
Datawarehouse sistemleriyle ilgili araştırmalarımda çok güzel bir yazıyla karşılaştım
http://www.iszekasi.com/joomla155/index.php/tr/blog/23-oracledb/202-oracle-data-integrator.html sitesinde de göreceğiniz gibi ODI kullanımı ve çözümlerine yönelik dökümanı inceleyelim


İş Zekası projelerinin %60-%80 eforu verinin kaynak sistemlerden çıkarılması, gerekli çevrimlerin yapılması ve hedef sistemlere yüklenmesi (ETL) aşamalarında harcanmaktadır. Bu amaç için çok çeşitli ürünler aynı yöntemlerle veri çevrimlerini yapmakta ve veri akışını oluşturmakta. İşte bu ESKİ ihtiyaca YENİ bir yaklaşım getirmektedir Oracle Data Integrator (ODI) .
Önceleri sadece veri ambarlarının oluşturulması için kullanılmakta olan bu tür ürünler artık bir kurumdaki tüm veri entegrasyon amaçları için de kullanılıyor ve veri entegrasyonu konusunda uzmanlaşmış olan veri ambarı uzmanları ise artık kurumların veri entegrasyon ortamlarının da oluşmasında önemli roller oynamakta.
Oracle Data Integrator heterojen ortamların batch, real time, event oriented, message oriented, service oriented veri entegrasyonu için tekleştirilmiş bir arayüz ile yeni bir yaklaşım getirmekte ve entegrasyon süreçlerinin geliştirilmesi için gereken eforu projenin %60-%80 lerinden %30-%40 larına düşürebilmektedir.
ODI’ın öne çıkan özelliklerini aşağıdaki başlıklarda inceleyelim:
- ETL değil ELT
- Knowledge moduller (şablonları)
- Her aşamada veri çevrimi (kaynak, hedef ve veri işleme alanlarında)
- Changed Data Capture (Değişen verinin bulunması)
- Master Data Management
- Servis Odaklı Mimari (SOA )
- Java mimarisi – Tüm platformlar için tek uygulama
- Erişebilirlik
- Öğrenme hızı
ETL Değil ELT
Bu tür ürünlerin tarihçesine baktığımızda 3 ana aşamayı görüyoruz.
1- Veri taşınması ve çevrimi için kod üreten ürünler. Bunlar platformalara göre Cobol, C kodları üreten uygulamalardı.
2- Kendi server’ında veri işlemeyi yapan ürünler.
3- Veri tabanlarını kullanıp veri işleyen ürünler.
ODI üçüncü nesil bir ürün, veri işleme işini bu konuda zaten büyük yatırımlar yapan veri tablarına bırakmakta ve kendisi veri tabanlarının en güçlü yanlarını kullanarak verinin çevrimini sağlamakta. Diğer birçok ürün piyasaya çıktığında veri tabanlarının SQL lerinde CASE komutu yoktu, böyle düşününce veriyi işleyecek ayrı bir server fikri anlamlıydı. Oysa günümüzde veri tabanlarına baktığımızda (ör: Oracle 10g, Teradata, DB2, SQL Server 2005, Sybase IQ ) veri işleme anlamında çok güçlüler. Kurumlar veri tabanlarına ciddi bir yatırımı halihazırda yapmış bulunuyorlar. Bu gücü iş zekası ortamlarının oluşturulması için gereken veri işleme aşamasında neden kullanmasınlar?
ODI kaynak sistemlerden veriyi toparlayıp tasarıma göre staging veya hedef veri kaynağında birleştirip konsolide ediyor ve gereken çevrimi veri tabanı içerisinde yapıp hedefe yüklüyor. Kaynak ve hedef veri kaynaklarının en güçlü yanlarını kullanarak çevrimi yapabiliyor. Yapılan çevrimlerin %90 ı SQL’ler ile yapılabiliyor.
ELT kelimesinden de anlaşılacağı üzere önce veri kaynaktan çıkarılıyor (Extract) sonra hedef veya staginge yükleniyor (Load) ve çevrim yapılıyor (Transform).
ELT yaklaşımında kaynak ile hedef arasında herhangi bir server olmadığından verinin network üzerinden yolculuğu da kısalmış oluyor. ETL ürünlerindeki gibi ayrı bir server’ın bakımı ve kurulumu gibi yüklerde ortadan kalkmış oluyor.
Veri tabanları üzerinde çevrim yapmaktan bahsediyorsak bunun SQL’ler ile yapıldığını tahmin etmişsinizdir. Yeni bir scripting öğrenmenize gerek kalmadan tüm veri çevrim işini SQL in gücünü kullanarak yapabiliyorsunuz.
ELT yaklaşımında veri genel olarak bulk olarak işleniyor. Veri tabanlarının bu konuda yapmış oldukları performans yatırımlarını düşündüğünüzde performans arttırma konusunda da elimizdeki veri tabanımızın bize sunduğu fırsatları kullanıyor oluyoruz.
Kısaca ODI ile veri tabanları üzerinde, ayrı bir scripting öğrenmeden, yüksek performans ile ve geliştirme süresini ciddi miktarda azaltarak veri entegrasyonu yapılabiliyor.
Knowledge Modul’ler (Şablonlar)
Lego parçacıkları gibi birçok veri işleme modülünüzün olduğunu düşünün, onlarca modül (sort, transform, join vs.) ve karşımızda bir veri entegrasyonu problemi var. Bu modulleri kullanarak bir süreç tasarlayacaksınız. Tasarladınız, ileriki aşamalarda optimizasyonunu yapacaksınız. Optimizasyonu yaptıktan sonra benzer durumdaki belkide yüzlerce akış için aynı işi tekrarlayacaksınız. ODI ın devrimsel farkı bu noktada ortaya çıkmakta, knowledge modul adı verdiğimiz şablonlarınız var ve yukarıda bahsedilen zorluklarla uğraşmanıza gerek kalmıyor. Verinin bir ortamdan başka bir ortama taşınması, değişik ortamlardaki verinin entegre edilmesi, değişen veri ile hedef sistemlerin beslenmesi vs. gibi aşamaların her birisi için çeşitli şablonlar bulunmakta.
Knowledge Modul (KM) ler binlerce kişi tarafından test edilmiş, optimum çözümleri size sunmuş oluyor. İş zekası projelerinde veri entegrasyonu için harcanan zamanın çoğu ETL için harcanıyor demiştik. ETL süreci içerisinde de en fazla efor ise karşımıza çıkan problemler için geliştirmek zorunda olduğumuz veri akışlarının tasarımı. ODI birçok değişik durum için bu tür problemlerin çözümünü de beraberinde sunmasıyla hayatımızı kolaylaştırmaktadır.
Her Aşamada Veri Çevrimi
Verinin çevrimi çoğunlukla SQL’ler ile yapılıyor demiştik; kaynak, hedef ve staging veri kaynaklarımızın olduğunu düşünürsek çevrimin nerede yapılacağı ihtiyacımıza ve zorunluluklarımıza göre ODI içerisinde tasarlanabiliyor. Basit bir örnekle verecek olursak: kaynak sistemde text bir bilgi var ve uzunluğu 100 karakter, hedef ise 80 karakter, uzunluğu 100 den 80’e indirirken SUBSTR komutunu 2 nokta çalıştırabiliriz.
- Kaynaktan veriyi çekerken
- Kaynak sistemdiki bilgiyi staging’e aynı uzunlukla taşıyıp konsolide ederken
- Hedef veri kaynağına yüklerken çalıştırabiliriz
Bu esnekliğin bize kazandırdıklarını da şöyle özetleyebiliriz:
- Veri işleme yükünün veri tabanları arasında istenen şekilde dağıtılması
- Network trafiğinin azaltılması
- Her veri tabanının güçlü yanını kullanabilme
Changed Data Capture (Değişen Verinin İşlenmesi)
Günlük olarak yükleme yapılan bir veri ambarı düşündüğümüzde kaynak sistemlerden değişen verinin alınması zorunluluğu ortaya çıkmktadır. ODI içerisinde değişen verinin veri tabanı loglarından okunarak veya triggerlar ile bulunabilmesi için çeşitli knowledge moduller de bulunmaktadır. Örneğin kaynak sistemi Oracle olan bir kurumda operasyonel sistem tablolarından değişen verinin sisteme en az yük getirecek şekilde bulunabilmesi basit bir şekilde mümkün olmaktadır.
Değişen verinin veya tüm verinin işlenmesi için iki farklı akışın oluşturulması da gerekmemektedir, sadece bir check box ın işaretlenmesi ile akışın değişen veriyle çalışmasının sağlanması mümkün olmaktadır.
Master Data Management
Bugüne kadar kurumda bulunan hiçbir operasyonel sistemin sorumluluğu müşteri, ürün vs. verisinin tekliğini, doğruluğunu ve bütünlüğünü gözetmek değildi. Master Data’yı ise bu sorumluluğu alan sistem olarak düşünebiliriz. ODI değişik ortamlarda bulunan master verinin Master Data üzerinde konsolide edilmesi ve diğer tüm sistemlerle paylaşılması konusunda organizasyonlara yardımcı olabilmektedir. Veri seviyesinde yapılan bu entegrasyon aynı zamanda Servis Odaklı Mimari geçişlerinde de servislerin tanımlama zorluklarını da basitleştirmiş olmaktadır.
Servis Odaklı Mimari
ODI ile oluşturulan veri çevrimin ve verinin kendisi web service’ler ile dış kullanımlara açılabilmektedir. Veri çevrimi için dış ortamlarda bulunan web service leri de ODI içerisinden kullanılabilmektedir. Bu olanaklar ile verinin ve veri çevrim süreçlerinin kurumların SOA altyapıları ile entegrasyonu mümkün olabilmektedir.
Java Mimarisi
ODI tamamı ile java ile geliştirilmiş ve dolayısıyla ortam bağımlılığı yoktur. Aynı kodun windows, linux ve unix ortamlarında çalışabiliyor olması uygulamanın geliştirme maliyetinide düşürdüğünden kurumlara maliyet olarak avantaj sağlayacağı da düşünülebilir.
Erişebilirlik
ODI tüm JDBC,ODBC desteği olan populer veri tabanlarını ayrı bir connectore ihtiyaç duymadan kaynak veya hedef olarak kullanabilmektedir.
İlişkisel veri tabanları yanında çok boyutlu veri tabanları (Essbase), text dosyalar, xml, JMS tabanlı veri kaynaklarını da kullanabilmektedir.
Öğrenme Hızı
Son olarak ODI ı öğrenmek için harcayacağımız efordan bahsedelim; SQL bilgisi olan bir uygulamacı 2 günlük bir eğitim sonunda ELT işleri tasarlayabiliyor duruma gelebiliyor.
Bazı durumlarda uygulamacıların uzun zamanlarını alan hata mesajlarının anlaşılması da önemli bir konu. Veri ile uğraşan her uygulamacının SQL bildiği varsayılabilir ve ODI ın hata mesajları SQL hataları şeklinde kullanıcılara sunuluyor. Bu fark Hataların anlaşılması aşamasında ciddi bir kolaylık sağlayabiliyor.
Knowledge Moduller sayesinde değişik uygulamacıların geliştirdikleri uygulamaların standartlaştırması kaygısı ortadan kaybolmaktadır. Her kullanıcının geliştirmesi gereken onlarca adım zaten ODI tarafından KM ile hazır sunulmaktadır. Uygulamacılar verinin akışı ile ilgili herhangi bir tasarım yapmamakta sadece veri eşleştirilmesi (mapping) yapmaktadırlar.
Sonuç
Yukarıda öne çıkan özellikleri anlatılan ODI ürünü içerisinde aynı zamanda metadata yönetimi, scheduling, process flow tasarımı, data quality firewall gibi birçok özellikleri de mevcuttur.
Özet olarak söyleyecek olursak; veri tabanlarını en iyi şekilde kullanıp, basit ve yüksek performansta veri entegrasyonu yapabileceğimiz bir ürün ODI.
Veri ambarı ve veri entegrasyonu projelerinde yeni bir yaklaşımla benzer geleneksel ürünlerin bir adım önüne çıkmaktadır.
Bu makalemde bazı temel dwh bilgilerini paylaşmak istiyorum.Umarım faydalı olabiliriz..
Veri Ambarı kavramını açıklamak için birçok tanımlama yapılabilir ama basitçe tanımlayacak olursak Veri Ambarları bir şirketin bütün verilerini depolamak için oluşturulan alanlardır. Veriler değer derecelerine ve iş ilişkilerine göre toplanır.
Veri Ambarı verimliliği, kar oranlarını ve rekabet avantajlarını korumak için şirketler açısından çok büyük bir öneme sahiptir. Şirketler verileri internet, çağrı merkezleri, satış merkezleri, döküm yönetimi gibi birçok kaynaktan alır. Veriler toplanırken Data Life Cycle Management(Veri Yaşam Döngüsü Yönetimi) denilen konveyör banttan geçirilir.
Şirketin veri yaşam döngüsü yönetimi politikaları veri ambarının tasarımını ve yöntemlerini şekillendirir.
Şekil 1. Veri Ambarı Yapısına genel bir bakış
PRE-Data Warehouse
Bu aşama, asıl data warehouse tarafına veri sağlayan aşamadır. Burada dwh tasarımcıları hangi verinin hangi iş birimine gireceğine açıklık getirirler.
OLTP veritabanları operasyonel verilerin saklandığı veritabanı sistemidir. OLTP veritabanları, Kurumsal Kaynak yönetimi, Tedarik Zinciri, Satış YÖnetimi, Müşteri Hizmet Yazılımları gibi projelerde bulunabilir.Bu tarz database'ler işlem hızı ve doğruluğu için dizayn edilirler.
Metadata, verinin yaşam döngüsüne girilmesindeki doğruluğu sağlar ve veri ilişkilerinin, formatının doğruluğunu sağlar.
Data Cleansing
Veriler veri ambarına girmeden önce ETL sürecinde data quality eşiğini geçer. Burada verilerin ne şekilde kullanılacağı netleştirilir istenilen formata sokulur. Mesela marangozun masa yapmaya başlamadan önce ağacı yontup masanın ayaklarını gövdesini oluşturması gibi düşünülebilir.
Ayrıca ETL, verinin scheduled olarak da OLTP veritabanından extract edilmesinden sorumludur.
Data Repositories
Data Repository ler(veri depoları) iş kapsamının aktif verisini saklarlar. The Data Warehouse modeling design(Veri ambarı model tasarımı), veri analistleri için optimize edilmiştir.
DWH' ın data warehouse, data mart ve ODs gibi varyantları vardır. Data Mart kavramı fiziksel olarak data warehouse'dan farklı bir kavram değildir.Şöyle açıklanabilir ki data mart' lar dwh' ın iş birimlerince kategorize edilmiş halidir. Mesela A şirketi için bir data warehouse kavramı varsa, Bu kapsamda IK için, Pazarlama için, IT için ayrı ayrı data warehouse gibi data martlar vardır.
Data Warehouses(Veri Ambarları), veriyi toplar ve geçmiş veriler için bir depo teşkil eder. Bu yüzden sürekli güncel analiz için verimli değildir.İşte tam burada ODS(Operasyonel data store) devreye girer. ODS, verilerin datawarehouse'a girmeden önceki son halini saklar.
ODS, OLTP den derin geçmişi olan verileri saklamak için kullanılır.OLTP sistemlerde Büyük miktarda veri saklamak kaynak kısıtına ve işlem yavaşlığına yol açar.
Front-End Analysis
DWH ın en kritik ve son aşaması Front-End Analysis kavramıdır. Burada kullanıcılar repository'lerde depolanmış veriyle etkileşim halinde çalışırlar.
Veri madenceiliği, verinin en faydalı kullanım yolunu keşfetmektir.Veri madenciliği tahmin analizleri ve sınıflandırması için kullanılır. Mesela bir müşterinin rakip firmaya kayma sebeplerinin analizi gibi.
OLAP(Online Analytical Processing), geçmiş verilerin ve gerekli iş bilgilerinin parça parça, istenilen bazda analizini sağlar. Bu modül en çok pazarlama yöneticilerince kullanılır. Veriyi en işe yarar şekilde kullanmak için OLAP çok önemli bir faktördür. OLAP ve OLTP raporlarına şöyle bir örnek verirsek sanırım ayrım daha net anlaşılır :
OLTP : Şirketin kaçtane müşterisi var?
OLTP : Şirketin, yıl bazında belli yaş grupları arasındaki 2000 liranın üzerinde alışveriş yapan müşterilerinin bölgesel dağılımı. gibi..
Raporlama araçları(reporting tools) veriler hakkındaki raporları sağlamak için kullanılır, veriler iş ve performans göstergelerinin takibi arasındaki ilişkiyi göstermek için görüntülenir.
Veri görselleştirme araçları(Data Visualization tools) ise veri deposundan veri görüntülemek için kullanılır. Genelde veri madenciliği ve OLAP tool ları ile birleştirilir. Veri görselleştirmesi kullanıcıya verilerin birbirleriyle ilişkisini, mimarisini göstermek için işlemesine olanak sağlar.
Data Cleansing, data martlarımızı oluşturmadan önce mutlaka ayarlanması gereken ve ilerde ETL süreçlerimizde bizi sıkıntıya sokacak türden verilen kullanımını engeller ve aynı formata girmesini sağlar.Örneğin tarih alanlarımızda a,d,56,!..vb gibi karakterler görüyorsak bunları null,sysdate veya bizim belirlediğimiz herhangi bir alanda istediğimiz şekilde o veriyi tutmamız gerekecektir.
İşte bu yüzden işzekası nda bulunan bu güzel yazıyı paylaşıyorum
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.
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ığı