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 identified by   default tablespace temporary tablespace   ;

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ığı