Business Objects Universe Nedir

Merhaba arkadaslar geçen hafta bugün yazdigim makalede Business Objects’e bir giris yapmaya çalismistim. Bu makalede de Business objects’in Designer isimli modülünü anlatacagim. Bu Designer nedir? Ne ise yarar?

Öncelikle sunu söyleyeyim Universe dedigimiz katman Business Objects’in rakiplerine göre ileride oldugu güçlü yanidir. Özet olarak Veritabaninin o karmasikligini en aza indirdigimiz rapor çekenlerin isini hizlandiracagimiz mantiksal katmanimizdir Universe.

Geçen makalemizde raporlamanin vardigi ve gittigi noktayi anlatmistim. Neydi bu nokta, hiç bir teknik bilgisi olmayan is birimindeki bir kullanicinin istedigi an istedigi bilgiye ulasmasiydi. Dolayisi ile bunu saglayabilmek için kullanicinin önüne öyle bir platform sunmaliyiz ki sürükle birak ile raporunu rahatlikla yapsin. Sürükle birak ile kullanacagi bu objeleri ve daha fazlasini içeren yapiya Universe diyoruz ve Designer modülü ile üretiyoruz.

Kurdugumuz Business Objects sisteminde bir universe olabilecegi gibi birden fazla universe’ler de olabilir. Her bir universe tekbir veri kaynagina baglanir ve bu baglandigi kaynakta ki veritabani tablolarini kullanarak universe tasarlariz.

Universe’e her ekledigimiz tablo için gerekli join islemlerini yapariz, cardinality’sini belirleriz. Daha sonra bu tablolardan Universe Obje’lerini olusturacagiz. Bu objeleri tipki rapor yaparken kullanacagimiz sürükle-birak yöntemi ile yapabilriz. Ya bir tabloyu tutup komple solda duran bos alana atabiliriz. Yada o tablodaki kolonlardan istedigimiz alanlari sürükle birak ile objeleri olusturabiliriz.

Obje olusturma isleminde önemli bir nokta var ki unutulmamalidir. Universe islemini sadece teknik insanlar yani IT’de bu konuda sorumlu insanlar tek baslarina kesinlikle yapmamalidirlar. Bu islem sirasinda is biriminden kisilerde IT personelinin yaninda durmalidir. Yoksa yaptigimiz Universe mantiksal bir katman degil, veritabaninin kullanicilara açilmis hali olur. Bu durum ise rapor anlaminda IT’deki is yükünü almak yerine daha artirir. Çünkü artik birde yönetmeleri gereken ekstra bir sistemleri bulunmaktadir. Universe tasarlarken; best practise olarak Universe tasarlamayi bilen, universe’ü yapilacak veritabanini iyi bilen ve rapor talep eden(is birimi) kisiler bir araya gelerek yapmalidirlar. Rapor talipkari isteklerini belirtir, bu isteklerin veritabaninda neye denk geldigini, nasil kullanacagini o veritabaninin uzmani söyler, Universe yapacak kisi de bunlarin hepsinin birlestirerek Universe’ni olusturur. Tablolar Universede birbirlerine baglandiktan sonra “Class”lar yaratilmali bu Classlar veritabani kolonlarinin mantiksal oalrak birlestirildikleri yerdir. Mesela; Bölgeler isminde bir Class yaratip için Bölge ADlarini, BÖLGE IDlerini vb. alanlari koyabiliriz. Zaman isminde bir Class yapip içine ÇEYREK,YIL,AY gibi alanlar koyabiliriz. Daha sonra uç kullanici rapor yapmak istediginde kolay bir sekilde Bölge adini bulabilir, istedigi zamana göre sorgulayabilir. Bu objelerin ve Classlarin isimleri veritabaniyla ayni olmasi sart degildir. Aslinda çogunlukla farkli olur. Çünkü o alanlari is birminin anlayabilecegi bir isme çevirmek gerekir. Iste Universe yaparken is biriminin yaninzda olmasinin en büyük nedenlerinde biride budur. Örnek vermek gerekirse, siz database’nizde XID diye bir alan tutuyorsunuzdur, ama is birimlerindeki adi Ürün Kodu olabilir. Dolayisi ile bu isim degistirmeyi Univese’de Obje’nin ismini degistrerek yapabilirsiniz. Obje ismini degistirdikten sonra , bu objeye sag tik yapip Object Properties derseniz Select kisminda hala tablo adi ve kolan isminin ayni olarak kaldigini görürsünüz.

Diger bir nokta ise veritabaninda bazi alanlar look-uplari veya kolon commentleri ile anlamli olabilir. Mesela X kolon’nun içinde 0,1,2 degerleri olabilir, ama 1 silinmis, 2 var, 0 negatif ‘i temsil edebilir. Dolayisi ile bu durumu Universe tasarlarken düzeltmeniz gerekir. Attiginiz bu objeyi deceode veya case when gibi fonksiyonlarla(Dbnize göre degisir.) açiklayici hale getirmelisiniz. Ayrica yine universe’de aggregate objelerinide olusturmalisiniz. Mesela Abone Sayisi alani bunu Universe tanimlamalisiniz. Aggeragate islemler BO’da rapor çekerken yapilamaz. Ancak rapor çekildikten sonra yapialabilir eger Universede tanimlanmamissa. Bu durumda Dbnize daha fazla yük getirmenize sebep olabilir. DB’e yük demisken Universe’nizde ki joinleme islemini çok düzgün yapmalisiniz ve tutarli bir sekilde test etmelisiniz. Bu joinlere göre ; otomatik SQL sorgulari yapilacagini unutmayin. Eger bu islemde bir hataniz varsa, ollusturulan raporlar çalismayabilir, diger raporlarinda çalismasini engelleyebilir. Hatta sisteminizin durmasini sebep olabilir.

Bu islemi dogru yaptiniz kulllanicilariniz da hatasiz çalisabiliyor ise asagidaki Universe avantajlarini kullanicilariniz aktif olarak kullanabiliyor demektir.

1. SQL yazma derdi olmadan teknik gereksinime ihtiyaç duymadan, arkadaki tablo mantigini bilmek gerekmeden rapor yapilabilir.
2. Yetkilendirmesini saglam yaptiginiz takdirde her kullaniciniz sadece ona verdginiz kadar bilgiyi kullanabilir
3. Kullanicilariniz datadan ayni anlami çikaracaktir. Yani is terminolojisi her yerde ayni olacaktir.
4. Kullancilar kolay bir sekilde analiz yapabilecekler.

Universe hakkinda anlatilabilecek çok fazla sey var. Mesela bana çokça sorulan bir soru var. Universe yaptik ve çalisiyor ancak; otomatik olarak bir rapor için birkaç SQL olusturuyor. Simdi bunun basit bir sebebi var. Universe’de çikan bir hatadan kaynaklaniyordur. Büyük ihtimalle bir loop vardir. Ancak; bu tip detaylari ufak makaleler ile vermeyi düsünüyorum. Kisilere veya gruplara göre Universe seviyesinde restrinctionlar koymaktan, Derived table’lar yapmaya, Hierarchies kullanmaya kadar bir çok konu var, bu konulara yeri geldiginde deginecegim.

Tekrar görüsmek üzere