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.