Vissza

Oracle BI (OBIEE) Administration tool

  György Retek

  2017.10.30. 10:57

Az OBIEE nagy teljesítményű riportoló eszköz nagyvállalati környezetbe szánva, képes a legkülönfélébb rendszerekből adatokhoz jutni, ezeket összevonni, feldolgozni, az eredményt böngészőn keresztül a hozzáférésre jogosult felhasználók számára elérhetővé tenni.

Az adatforrások, illetve a hozzáférések menedzselése egy Admin tool segítségével 3 rétegen keresztül történik.

Első a fizikai réteg, ami az adatforrások leképezését jelenti. Az Aministration Tool  kapcsolódik az adatforráshoz, felolvassa az adatmodellt és a kiválasztott elemeket megjeleníti a modellben. Join-t a fizikai modellben kell először készíteni, össze lehet akár joinolni olyan táblákat is amelyek más-más adatbázisban vannak (akár a technológia is eltérhet, pl. Oracle-MSSQL), az oszloptípusnak viszont egyeznie kell, vagyis ha egyik oldalon stringként tárolok számot a másik oldalon számként, az gond.

Felolvassa az adatforrásból a foreign key-eket illetve a primary key-eket az eszköz automatikusan, ezek lesznek az előre beállított joinok és a kulcsok. Ha két foreign key van két tábla között akkor felolvassa, beállítja, de hibás lesz a fizikai modell, hiszen nem lehet egynél több kapcsolat két tábla között, egyiket le kell utólag törölni. A grafikus felület ráadásul csak az egyiket mutatja, a másik láthatatlan, a join listában viszont benne van.

Ezt lehet majd továbbvinni a logikai modellbe, vagyis itt is létrehozható a join, de kell neki legyen fizikai párja, itt konkrét kapcsolatot nem is lehet megadni, csak magát a fizikai modellben szereplő join-t. Meg lehet itt még adni hogy használjon  „driving table”-t, a driving table az egyes értékekre külön lekérdezéseket küld a másik táblába és hatékonyabb így, viszont ha sok az egyedi érték benne akkor nem, sőt a gyári határ 200 egyedi érték a joinra ami módosítható, efelett hiba jön:

State: HY000. Code: 59034. [nQSError: 59034] A Drive Table join exceeded the limit of 200 backend database queries. (HY000)

A riport hibával megáll, MAX_PARAMETERS_PER_DRIVE_JOIN illetve MAX_QUERIES_PER_DRIVE_JOIN paraméterekkel szabályozható a határérték.

 

A fizikai rétegben már lehetséges illetve érdemes a BI megoldásra jellemző neveket adni az objektumoknak; alias táblát csinálva megduplázhatom a fizikai táblát, más kulcsot, joint stb. definiálhatok minden egyes példánynak, más néven szerepelhet minden aminek név adható, itt használhatok ékezeteket, szóközt, stb. Fontos, hogy 2 tábla között csak 1 join lehet, ami a fizikai rétegben a tábla duplázásával kerülhető meg. Másik problémaforrás lehet hogy felhasználhat a riport adott modellnél olyan join-t amit nem kellene, azaz pl. egy többször használt dátumtáblán keresztül összeköthet két táblát aminek semmi köze egymáshoz, ami további ok a forrástáblák többszörözésére. Ezekre már itt gondolni kell.

Opaque view segítségével lehetséges view definiálása a fizikai rétegben, táblaként viselkedik a továbbiakban, deploy-olva felkerül a view magába a fizikai adatbázisba és az Obiee itt hivatkozza. Administration toolból történik a deployolás, az admin tool felteszi a view-et és megmondja a BI szervernek is hogy hol keresse. Undeploy-olással ez visszavonható. Deployolni nem is szükséges, ez esetben mint select küldi el a szervernek a kérést a BI tool. Érdemes megemlíteni hogy a fizikai rétegben ha ékezetes nevet adtam az opaque view adatforrásnak hibaüzenet érkezik mert nem tudja a nevet feloldani. „New physical table”, és a table type állítható át select-é.

Hogy MSSQL adatforrást fogadhasson az OBIEE, Odbc2-t kell választani idézőjel használat tiltásával, vagy a with-et letiltani, mivel hibás with-es lekérdezéseket ír. Az idézőjel átírása és a with tiltása miatt warning jön (mert nem gyári beállításokat használ), nem kell törődni vele. Az idézőjel hiba azért van mert az azonosítókat idézőjelbe teszi (pl select * from „tábla”), de előzőleg letiltja az idézőjel használatát, kiadja hogy „SET QUOTED_IDENTIFIER OFF” így a parancs hibás lesz. MSSQL esetlén szintaktikailag hibás with-es lekérdezéseket ír, ha tiltom ez megoldódik.

Második az üzleti réteg, itt megismétlődik a fizikai réteg releváns része. Kis # jelzi melyik a tény vagyis measurement tábla, ezt magától találja ki a joinok alapján; joinoláskor nem mindegy honnan hova húzom a nyilacskát – még a fizikai rétegben - a dimenzó felé megy a nyíl. Vagyis a „sok”-ból az egy felé, a gyerek felől a szülő felé. Tény táblánál be lehet állítani az oszlopra aggregációt, ilyenkor az adatok nem hoznak létre több sort, hanem egy sorban összegződnek/átlagolódnak/stb. Létrehozhatóak hierarchiák, különféle számítások.

Harmadik a prezentációs réteg, itt a üzleti rétegben található objektumok szervezhetőek folderekbe, például típus, adattartalom alapján, itt állíthatóak be jogosultságok a felhasználók számára, ki mit érhet el. Az itt lévő folderek jelennek meg magában a riportoló eszközben, ezeket lehet majd felhasználni a riportokban.


   

Megjegyzések
Még nincsenek hozzászólások. Légy első!

Blog kategória

Címkefelhő

Legutóbbi bloggerek

Bálint Mészáros
Bejegyzések: 1
Csillagok: 0
Dátum: 2019.06.11.
Adrienn Keszőcze
Bejegyzések: 1
Csillagok: 0
Dátum: 2019.05.28.
György Retek
Bejegyzések: 11
Csillagok: 19
Dátum: 2019.05.14.
Kálmán Bohus
Bejegyzések: 3
Csillagok: 0
Dátum: 2019.04.29.
Tamás Molnár
Bejegyzések: 7
Csillagok: 11
Dátum: 2019.03.18.

Kapcsolat