Merhaba bu yazımda elimden geldiğince ODI’da Topology
kısmını anlatmaya çalışacağım. ODI en çok kullanılan aktarım araçlarından biri
ve buna rağmen piyasada az geliştiricisi olan bir tool. ODI’in tüm kısımlarını
parça parça yazacağım fakat ilk Topology kısmından başlamak istedim sebebi
aslında ilk noktamız olması ve aynı zamanda,görece en karmaşık bölümü olması.
Özellikle Context, Physical ve Logical arasındaki ilişki kolay sindirilen bir
kısım değil. Ama umuyorum ki bu yazıdan sonra bu sorun ortadan kalkacaktır.
Topology
·
Physical Architecture:Bu
kısım sizin bağlanacağınız veri kaynağını tanımladığınız kısmı içeriyor.Bu bir
DB veya File olabilir. Hangi server üzerindeki hangi DB’ye ve bu DB’nin hangi
şemalarına bağlanacağımızı tanımlıyoruz.
Aynı zamanda Agent da bu kısımda bulunmakta.Agent
ise bir makinede(Genelde DWH’ın olduğu yerde) kurulu olan bir program aslında.Görevi
ise yarattığımız senaryoları çalıştırmak aslında.
·
Contexts: Contextleri
tanımladığımız kısım.İlerde detaylı anlatacağım fakat Physical ile Logical
şemalar arasındaki bir köprü gibi düşünebilirsiniz
·
Logical Architecture:Logical
şemaları oluşturduğumuz kısım.Burda fiziksel hiçbir şey yok aslında yaratıp
geçtiğimiz bir kısım ama önemi Model ve Prosedürlerde inanılmaz ortaya çıkıyor.
·
Languages:Bu kısımda
kullanacağımız dilin fonksiyonlarının nasıl tanımlandığını kontrol edip
değiştirebiliriz.Default yüklenirken geliyor bir şey yapmanıza gerek yok fakat
en önemli nokta SQL’de Aggregate fonksiyonlarının Group Function işaretli
olduğundan emin olun yoksa otomatik aggrege etmez.
·
Repositories:Burada
ODI’ın bilgilerinin tutulacağı yeri oluşturuyoruz.Her açtığınızda yaptıklarımızın
kaybolmaması bir yerde kayıtlı olduğu anlamına geliyor ki bu genelde DWH’da
DEV_ODI_REPO isimli şema oluyor ama o bambaşka bir konu😊
Master Repository Topology,Version,Users
gibi konuları saklar iken Work Repository Mapping, Variable, Packages,Scenario
gibi geliştirmelerimiz ile ilgili bilgileri saklar. İki tip Work Repository
vardır. Development olanda geliştirmeleri yaparız diğeri ise Prod’dur.
Developmentda yaptığımız geliştirmelerin senaryolarını buraya aktarır sadece
çalıştırma işlemini Prod’da yaparız.Prodda Designer kısmı gelmez zaten.
·
Generic Action:Açıkçası
benim hiç işim düşmedi,kişisel deneyimim yok.
**Physical Architecture’ı
açtığınızda bir çok kullanılmayan teknoloji çıkar aşağıdaki tiki kullanarak
sadece kullandığınız teknolojileri filtreleyebilirsiniz.
Şimdi gelelim yazının asıl
konusuna Context’e ne gerek vardı ya da logical şemalara?
Şimdi hayal edin elinizde bir
mapping var ve bunu istediğiniz ortamlar için çalıştırmak
istiyorsunuz(Dev,Test,Prod vb.). Bu durumda iki seçeneğiniz var ya mappingi
çoklayacaksınız var olan ortamınız kadar, source ve target connectionlarını
değiştireceksiniz her ortam için,ki bunun
en önemli dezavantajı her değişiklik için ne kadar çokladıysanız o kadar
aynı işi yapmanız gerekir. Ya da öyle bir şey olacak ki connection bilgileri
parametrik olacak ve siz ne seçerseniz onun için çalışacak. İşte burada context
işin içine giriyor ve siz hangi ortamı seçerseniz onun için çalışıyor.
Bunu nasıl yapıyor peki derseniz,hangi
logical şemanın hangi physical şemaya gitmesi gerektiğini bildiği için
yapabiliyor.Çünkü context tanımlarken bunları seçiyoruz. Her context için
aynı logical şema farklı physical şemalara gidiyor.Yani logical bir DM
şemamız var diyelim Context_Prod için Logical_DM şeması Physical_DM_Prod
DB’sine eşleşecek.Context_Test için Logical_DM şeması Physical_DM_Test DB’si
ile eşleşecek.Yani logical şema aynı kalmasına rağmen physical şema her context
için değişecek.
****Bu eşleştirmeyi yaparken çok
önemli bir konu bağlanmaya çalıştığınız DB’lerin metadataları aynı
olmalı.Örneğin Prodda var olup Test olmayan bir tablonuz var ise hata alırsınız
ya da tablo var ama veri tipleri farklı ise de.
Aşağıdaki gibi ilgili context
için logical ve şemaları eşleştirebiliriz.
Bu eşleştirmenin sonucunda logical
DM şemamızın hangi context için hangi physical’a gittiğini görebiliriz.
Bu haliyle hala yetersiz bir
cevap çünkü logicalın ne iş yaptığını henüz çözemedik.Logical şema Model’de
işin içine giriyor.Çünkü modelleri logical şemalar üzerine kuruyoruz.Peki model
ne işe yarıyordu.Model tablo,view veya synonimlerin metadatalarını tutuyor.
Şimdi bu kısmı biraz detaylı anlatacağım çünkü modeli
anlamak çok önemli.Dikkat ederseniz DM isimli bir model kurmuşum ve teknolojiden
Oracle bir DB’ye bağlanacak demişim Logical şemasınıda DM seçmişim.Bu haliyle
model kurulu ama içeri tablo almadık henüz. Şimdi aşağıdaki ekran
görüntüsündeki gibi Prod isimli context ile içeri bir tablo aldığımızı
düşünelim. Şu anda burada olan işlem şu şekilde : siz Prod contextini
seçtiğinizde DM logical şemasını hangi physical şema ile eşleştirdiyseniz Prod
contextinde, oraya gitti o DB’deki ilgili tablonun metadatasını(sütun
isimleri,veri tipleri,uzunluk vb.) aldı getirdi.
***Burada bir Context seçmek zorunlu çünkü metadataları bir
physical DB’den almamız gerekiyor eğer burada context seçili olmazsa
metadataları getiremeyiz.Çünkü bir DB’ye bağlanamayız.
Sonrasında bu tabloyu Mappingimizde kullandığımızda DM
modeli üzerinden tabloyu Mappingimize getiriyoruz.Fakat bu yaptığımız şu an
Prod içindi,peki bunu Test için nasıl çalıştıracağız?
Mappingi veya scenariosunu çalıştırmak istediğimizde bize
Contexti sorar.
Bu mappingi çalıştırdığımızda mappingde kullandığınız
tablolar (source,target) için Model’e gider ilgili modeller hangi logical
şemalar üzerine kurulu olduğunu bulur.Sonra çalıştırdığımız context için bu
logical şemalar hangi physical şemalara gidiyor ise o DB’lere giderek ilgili
verileri okur veya yazar.
Şimdi tüm süreci özetlemeye çalışalım. Bizim Mappinglerde kullandığımız tablo için
bir Model lazım. Bu Model her zaman bir Logical şema üzerine kuruludur.Bu
Logical şemalar Contextler yardımı ile hangi Physical şemaya gideceğini
bilirler. Ve bu sayede ODI’da herhangi bir şey çalıştırdığımızda bize zorunlu
olarak sorduğu Context yardımıyla ilgili DB için çalışırlar.Aşağıdaki resimde
çalışma mantıklarını görebilirsiniz.
Bu süreç Dev,Test,Uat gibi ortamlar haricinde de
kullanılabilir.Örneğin elimizde 10 farklı source DB var diyelim.Hepsinin
metadataları 1-1 aynı fakat farklı fiziksel makineler üzerindeler. Aynı mantık
ile 10 adet context yardımıyla bu süreci rahatlıkla yönetip verilerimizi içeri
alabiliriz.
