Інтерфейс Siebel => Oracle Server => Express Server, Інші СУБД, Бази даних, статті

Довгий час Oracle Express, Сімейство OLAP-продуктів від Oracle, Було лідером в області багатовимірних баз даних. Крім стандартних засобів OLAP-сервера (Express Server) воно має ряд важливих і характерних особливостей, таких як моделі, формули і, найголовніше, власною мовою програмування – Express Language, а також рядом інструментів для їх використання. В цілому, для свого часу прикладні аналітичні системи на Oracle Express працювали досить швидко і ефективно. Одним з самих успішних з них став продукт Oracle Financial Analyzer (OFA), призначений для формування фінансової звітності, проведення детального фінансового аналізу, ведення бюджету, фінансового планування та прогнозування. Цей продукт отримав широке застосування, зокрема OFA був включений до складу фінансових модулів сімейства Oracle E-Business Suite, і легко інтегрувався з ними. У 2000 році корпорацією Oracle було прийнято рішення про “перенесення” Express Server до складу реляційної СУБД Oracle 9 i, і таким чином в ній з’явилася OLAP Option. Замість OFA, для роботи в середовищі цієї опції було запропоновано нове фінансове додаток – Oracle Enterprise Budgeting & Planning (EPB). Але і до цього дня OFA (та інші аналітичні програми для середовища Oracle Express) продовжують використовуватися в багатьох компаніях.

Багато компаній на сьогоднішній день використовують BI-додатки для збору та аналізу корпоративної інформації, що зберігається в різних джерелах. Для отримання єдиного погляду на всю інформацію підприємства необхідне створення єдиної моделі її подання. Безсумнівно, Express Server і OFA є важливим компонентом у загальній моделі даних.

Один з клієнтів компанії “Борлас” вирішив впровадити у себе систему корпоративної звітності на основі Oracle Business Intelligence Enterprise Edition. Серед безлічі всіх джерел, які використовувалися для побудови єдиної моделі даних у компанії була система бюджетування OFA. Таким чином, перед нами постало завдання інтеграції OFA і Oracle BI Suite EE. Оскільки OFA є, по суті, надбудовою над Express Server, ми стали вирішувати загальну задачу інтеграції Express Server і Oracle BI Suite EE.

Реалізація інтерфейсу Oracle Server => Express Server

На сьогоднішній день Oracle пропонує дві аналітичні платформи: Standard Edition , Колишній Oracle Business Intelligence 10 g, і Enterprise Edition , Інтегрована платформа для реалізації різних методів аналізу даних, заснована на платформі Siebel Analytics . Крім того, існує редакція Oracle Business Intelligence Standard Edition One є скороченою версією Enterprise Edition для середнього та малого бізнесу.

Oracle BI Suite Standard Edition складається з двох основних компонентів:


Oracle Discoverer дозволяє будувати довільні звіти і формувати нерегламентовані запити. Він легко інтегрується з СУБД Oracle, у тому числі з опцією OLAP. Однак він не має ніяких адаптерів до Express Server і тому не може працювати з ним. З іншого боку Oracle Reports, компонент для створення і публікації стандартних регламентованих звітів, надає доступ до різних джерел даних (SQL, PL / SQL, JDBC, XML-файли та інші), включаючи готовий адаптер до Express Server.

Oracle BI Suite Enterprise Edition складається з набору різних компонентів. В основі лежить Oracle BI Server – сервер, що забезпечує доступ до джерел даних і представляє їх у вигляді єдиної моделі даних. Він має відкритий і розширюваний набір адаптерів, відповідальних за зв’язок з джерелами даних. Були створені індивідуальні адаптери до різних систем, включаючи реляційні СУБД (Oracle, DB2, SQL Server, Teradata, Informix та ін), корпоративні програми (OEBS, Peoplesoft, JD Edwards, SAP R / 3, mySAP), OLAP-джерела (Oracle OLAP, Microsoft Analysis, SAP BW, Hyperion), XML-джерела. Однак адаптерів до Oracle Express не було створено.

Сімейство програмних продуктів Oracle Express складається з сервера багатовимірних баз даних (Express Server, Personal Express), інструментів для адміністрування (Express Administrator), інструментальні засоби для розробки складних інтегрованих клієнтських додатків (Express Analyzer, Express Objects), засоби для публікації даних в Інтернеті (Web Publisher) і багато іншого. На малюнку 1 приведена архітектура сімейства Oracle Express.


Рис. 1 Архітектура сімейства Oracle Express.

До складу сімейства продуктів Oracle Express включені наступні інтерфейси:


Слід зазначити, що клієнтські програми Express Analyzer, Express Objects, Web Publisher використовують у своїй роботі XCA та / або SNAPI. XCA є закритим протоколом для внутрішньої роботи самого сервера бази даних і для наших цілей не підходить. EWA – це доповнення до Express Server, основною функцією якого є побудова даних в Web форматі. На малюнку 2 показана схема роботи EWA.


Рис. 2. Cхема роботи Express Web Agent

Таким чином, на роль інтерфейсу доступу до Express із зовнішніх систем і, зокрема, Oracle Server підходить тільки SNAPI.

Оскільки Oracle BI Suite EE може працювати з будь-яким ODBC-джерелом, найпростішим рішенням поставленого завдання було б створення власного ODBC-драйвера. Для цього можна скористатися готовими комерційними бібліотеками (Software Developer Kit) для написання ODBC-драйверів. Ми зробили простий ODBC-драйвер на базі SimbaEngine SDK від компанії Simba Technologies. При реалізації базових методів ми зіткнулися з наступними труднощами:


Оскільки завдання вимагала досить швидкого і надійного рішення і, крім того, написання власного драйвера було пов’язане з багатьма ризиками, ми вирішили опрацювати інші варіанти рішення.

Oracle BI Suite EE надає інтеграцію з безліччю продуктів від Oracle, включаючи всебічну підтримку СУБД Oracle Database 10 g. Таким чином, якщо ми б могли представити дані з Express як таблиці Oracle, то завдання було б вирішена. Для цього нам потрібно опублікувати Express-куби у вигляді уявлень (view) на основі табличних функцій (table function), які отримували дані з Express Server. Оскільки до складу Oracle Reports входить адаптер до Express Server, ми вирішили скористатися ним. Адаптер реалізований на Java c використанням технології Oracle Reports Pluggable Data Source (PDS), дозволяє підключати до Oracle Reports довільні джерела даних. PDS – набір інтерфейсів на Java (API). Він описаний в Oracle Reports Java API Reference. До складу Oracle Reports входять готові PDS-адаптери до XML файлів, JDBC джерел і найголовніше до Express Server.

Схема роботи PDS-адаптерів до Express Server наведені на малюнку 3.


Рис. 3. Схема роботи PDS-адаптерів до Express Server

SNAPI драйвер до Express Server являє собою бібліотеку на мові “C”. Для того, щоб можна було скористатися методами цього драйвера в Java, Oracle запропонував спеціальну бібліотеку Express Java (XRJ – eXpRess Java), яка є своєрідним містком між “натуральним” (компілювати в бінарний код) SNAPI-драйвером і сучасним Java-драйвером. Бібліотека XRJ підключається в Java-пакеті Express PDS і здійснює всі взаємодію з SNAPI-драйвером. Далі будемо позначати як SNAPI / XRJ-драйвер зв’язку з SNAPI-драйвера і XRJ-бібліотеки. Аналогічна зв’язка працює і ще в одному продукті Express Spreadsheet Add-In.

Публікація даних з Express Server як уявлень в базі даних дозволяла вирішити не тільки конкретну задачу реалізації інтерфейсу Oracle BI Suite EE і Express Server, але дозволяла включити Express Server в загальну інформаційну середу через СУБД Oracle. Крім того, такий підхід виявився простим, ефективним і технологічним, оскільки всієї обробкою займалася СУБД Oracle. Завдяки серйозній підтримці Java і широким можливостям самої СУБД Oracle, яка дозволяють створювати конвеєрні табличні функції на Java, рішення задачі побудови інтерфейсу Express Server – Oracle Server виявилося дуже витонченим.

Розглянемо більш докладно пропоноване рішення, побудоване на наступних базових продуктах: Oracle Express Server 6.4, Oracle Database 10 g, Oracle Express PDS 10 g.


Рис. 4.

Як і в Oracle Reports, в основі рішення лежить: SNAPI-драйвер, що надає доступ до баз даних Express Server і спеціальна XRJ-Бібліотека впровадження до нього Java-інтерфейс. XRJ-бібліотека має свій власний синтаксис запитів, (схожий на синтаксис конфігураційних файлів), в якому вказується база даних Express Server, показники, вимірювання, ієрархії, обмеження на вимірювання і багато інше. Для побудови таких запитів нами було зроблено спеціальний додаток Express SNAPI Query Builder, що використовує схожі з Express майстра побудови запитів і селектор. За допомогою цього додатка можна легко отримувати запити до Express в форматі XRJ-бібліотеки.

Починаючи з версії 8 i в СУБД Oracle включена повноцінна Java-машина, Oracle JVM. На сьогоднішній день СУБД Oracle дозволяє створювати, зберігати і виконувати Java-додатки всередині себе. Крім того, важливим є те, що PL / SQL і Java код можуть спокійно співіснувати разом в одній програмі. Однак СУБД Oracle забороняє використання JNI (стандартний інтерфейс програмування для написання “натуральних”, тобто компілюються в бінарний код цільової операційної системи, методів) Незважаючи на те, що використання JNI в більшості випадків веде до втрати багатоплатформності Java-коду, дана можливість розширює сферу застосування самої мови Java на додатки, для яких ця умова не є необхідною. У таких системах використання JNI дозволяє поєднувати сучасний об’єктно-орієнтований підхід Java з існуючим (LEGACY) системно-залежним кодом на С / С + +, яким і є драйвер SNAPI / XRJ. JNI-інтерфейс використовувалася в Oracle Reports, щоб підключити XRJ-бібліотеку в Java PDS-драйвер. Нам ж довелося реалізувати клієнт-серверний підхід, коли сервер, що стоїть окремо від бази даних, може підключати будь-які бібліотеки, а клієнт ще взаємодіє з сервером.

Таким чином, нами був зроблений проміжний буферний сервер, який за JNI підключав SNAPI-драйвер. У його завдання входило отримання запитів від клієнтів і переправлення їх далі SNAPI / XRJ-драйверу, який розбирав цей запит і видавав назад результати. Далі буферний сервер віддавав результати клієнту.

В якості реалізації клієнт-серверної технології була обрана RMI-архітектура. Система Remote Method Invocation (RMI) дає можливість об’єктах, що виконується на одній Java-машині, викликати методи об’єкта, виконується на інший. RMI забезпечує функціонал для віддалених комунікацій між програмами, написаними на мові Java.

Для подання кубів у вигляді таблиць були використані табличні функції, особливий тип функцій PL / SQL, які повертають не скалярний значення, а масив елементів довільної структури. Причому, є два види табличних функцій: повертають результат у вигляді масиву та контролюючі обробку повертається вибірки за допомогою реалізації інтерфейсу ODCITable. У нашому рішенні ми використовували саме ODCITable-інтерфейс, оскільки це дозволяло реалізувати конвеєрні табличні функції і отримати високу продуктивність. Для подання кубів у вигляді таблиць необхідно було створити спеціальні структури в СУБД Oracle, які представляли результати вибірки даних з Express кубів. Тут можливі два варіанти: або створюється один великий тип, складається їх максимального числа стовпців всіх типів, або для кожного куба створюється свій власний тип. Далі створюються подання або матеріалізовані уявлення в СУБД Oracle, які, використовуючи конвеєрні табличні функції, повертають вибірки з кубів.

Після того, як Express-куби, в тому числі з OFA, опубліковані як уявлення (матеріалізовані подання) в СУБД Oracle, на їх основі можна будувати звіти засобами Oracle BI Suite EE.

Приклад використання

Розглянемо приклад побудови звіту в Oracle BI Suite EE на основі тестової бази даних, яка поставляється з Oracle Express – demo.db. Візьмемо куб – SALES, побудований за трьома вимірами: MONTH, PRODUCT, DISTRICT. У представлених нижче лістингах відсутній Java-код для шлюзового RMI-сервера, RMI-клієнта, оскільки вони досить великі і складні.

Створимо для нього відповідні структури в СУБД Oracle:

———————————————– – Специфікація об’єктного типу для осередку куба
———————————————–
create or replace type t_sales_row as object (
sales number,
month date,
product varchar2(30),
district varchar2(30)
);
———————————————– – Специфікація табличного типу
———————————————–
create or replace type t_sales_table as table of t_sales_row;

Для побудови конвеєрної табличній функції необхідно створити відповідний тип, який реалізовував би інтерфейс ODCITable

———————————————– – ODCITable тип
———————————————–
create or replace type t_sales_rowset as object (
key integer,
– Статична функція, необхідна для створення контексту – Query – еапрос в Express
static function ODCITableStart(sctx out t_sales_rowset, query varchar2)
return number
as language java name ‘SalesRowset.ODCITableStart( oracle.sql.STRUCT[],
java.lang.String)
return java.math.BigDecimal’,
– Метод примірника, необхідний для отримання чергової порції вибірки
member function ODCITableFetch(self in out t_sales_rowset, nrows in number,
outset out t_sales_table)
return number
as language java name ‘SalesRowset.ODCITableFetch( java.math.BigDecimal,
oracle.sql.ARRAY[])
return java.math.BigDecimal’,
– Метод екхемпляра, необхідний для закриття контексту
member function ODCITableClose(self in t_sales_rowset)
return number
as language java name ‘SalesRowset.ODCITableClose() return java.math.BigDecimal’
);

Тепер нам треба створити Java пакет SalesRowset опишемо тільки основні методи, які необхідні для роботи ODCITable типу.

Перша функція ODCITableStart, необхідна для створення контексту і відкриття курсора. Для неї входять параметром буде Express запит.

static public BigDecimal ODCITableStart(STRUCT[] sctx, String query) throws SQLException { / / З’єднання поточної сесії
Connection conn = new OracleDriver().defaultConnection(); / / Створюємо контекст запиту, StoredCtx – довільний клас, його визначаємо ми самі
StoredCtx ctx = new StoredCtx(query);
int key;
try { / / Створюємо ключ для нашого контексту
key = ContextManager.setContext(ctx);
} catch (CountException ce) {
return ERROR;
}
Object[] impAttr = new Object[1];
impAttr[0] = new BigDecimal(key); / / Створюємо дескриптор для нашого ODCITable типу в базі
StructDescriptor rowset = StructDescriptor.createDescriptor(“T_SALES_ROWSET”, conn); / / Заповнюємо тип
sctx[0] = new STRUCT(rowset, conn, impAttr);
… / / Далі ми звертаємося до RMI серверу і відправляємо запит Express

return SUCCESS;
}

Друга функція ODCITableFetch необхідна для отримання нової порції даних з вибірки. Для неї входять параметром буде Express запит.

public BigDecimal ODCITableFetch(BigDecimal nrows, ARRAY[] outSet) throws SQLException {
StoredCtx ctx;
try { / / Отримуємо контекст по ключу
ctx = (StoredCtx) ContextManager.getContext(key.intValue());
} catch (InvalidKeyException ik) {
return ERROR;
}
Connection conn = new OracleDriver().defaultConnection();
try {

ArrayList list = _srv.fetchQuery(ctx.nQueryId, nrowsval);
StructDescriptor cube_row = StructDescriptor.
createDescriptor(“T_SALES_ROW”, conn);
ArrayDescriptor cube_table = ArrayDescriptor.
createDescriptor(“T_SALES_TABLE”,conn);
ArrayList list = null;
… / / Отримуємо в list через звернення до RMI серверу чергову порцію вибірки / / Нехай вона повертається у вигляді / / {SALES, MONTH, PRODUCT, DISTRICT}, відповідним типом t_sales_row


Object[] table = new Object[list.size()];
int i = 0; / / Проходимо по всьому масиву і заповнюємо структуру
for (Iterator it = list.iterator(); it.hasNext();) {
table[i++] = new STRUCT(_cube_row, _conn, (Object[]) it.next());
} / / Створюємо масив з структуру
outSet[0] = new ARRAY(cube_table, conn, table);
table = null;
list.clear();
list = null;
return SUCCESS;
} catch (Exception e) {
e.printStackTrace();
System.out.println(e.toString());
}
}


Остання функція ODCITableClose необхідна для закриття курсора і контексту.

public BigDecimal ODCITableClose() throws SQLException {
StoredCtx ctx;
try {
ctx = (StoredCtx) ContextManager.clearContext(key.intValue());
} catch (InvalidKeyException ik) {
return ERROR;
}
… / / Звертаємося до RMI серверу і закриваємо курсор до Express

ctx = null;
return SUCCESS;
}

Тепер можна створити конвеєрну табличну функцію, для якої тип T_SALES_ROWSET буде реалізують її.

———————————————- – Конвеєрна функція на основі t_sales_rowset
———————————————–
create or replace function getExpressSales(query varchar2)
return t_sales_table
pipelined using t_sales_rowset;

Тепер для того, щоб створити уявлення в СУБД на основі цієї функції, нам треба сформувати запит до Express Server. Для створення SNAPI запитів ми створили спеціальний додаток Express SNAPI Query Builder, за допомогою якого ми єднаємося з Express і будуємо за допомогою стандартного Express майстра запит.


У підсумку отримуємо запит до Express Server в наступному вигляді:

DB0=DEMO.DB
DBCount=1
MeasureCount=1
Measure0=SALES
E0Count=2
E1Count=1
E2Count=1
E0Dim0Name=XP_MEASUREDIM
E0Dim0Script=CALL XP_SLLIMIT(“XP_MEASUREDIM”, “CUBE”,”SALES”)
E0Dim1Name=MONTH
E0Dim1Script=call XP_SELEVALUATE( “MONTH”, NA )
E0Dim1DimLName=MONTH
E0Dim1Hier=E1Dim0Name=PRODUCT
E1Dim0Script=call XP_SELEVALUATE( “PRODUCT”, NA )
E1Dim0DimLName=PRODUCT
E1Dim0Hier=E2Dim0Name=DISTRICT
E2Dim0Script=call XP_SELEVALUATE( “DISTRICT”, NA )
E2Dim0DimLName=DISTRICT
E2Dim0Hier=QL=1

Створюємо на його основі подання

———————————————- – Вистава для SALES
———————————————–
create or replace view v_express_sales as select * from table(getExpressSales(‘DB0=DEMO.DBDBCount=1
MeasureCount=1
Measure0=SALES
E0Count=2
E1Count=1
E2Count=1
E0Dim0Name=XP_MEASUREDIM
E0Dim0Script=CALL XP_SLLIMIT(“”XP_MEASUREDIM””, “”CUBE””,””SALES””)
E0Dim1Name=MONTHE0Dim1Script=call XP_SELEVALUATE( “”MONTH””, NA )
E0Dim1DimLName=MONTH
E0Dim1Hier=
E1Dim0Name=PRODUCT
E1Dim0Script=call XP_SELEVALUATE( “”PRODUCT””, NA )
E1Dim0DimLName=PRODUCTE1Dim0Hier=E2Dim0Name=DISTRICT
E2Dim0Script=call XP_SELEVALUATE( “”DISTRICT””, NA )
E2Dim0DimLName=DISTRICTE2Dim0Hier=QL=1″));

Результат запиту

select * from v_express_sales;
SALES MONTH PRODUCT DISTRICT
———- ———– ————————- ————————-
32153,52 31.01.1995 TENTS BOSTON
32536,3 28.02.1995 TENTS BOSTON
43062,75 31.03.1995 TENTS BOSTON
57608,39 30.04.1995 TENTS BOSTON
81149,36 31.05.1995 TENTS BOSTON
88996,35 30.06.1995 TENTS BOSTON
87273,84 31.07.1995 TENTS BOSTON
89379,13 31.08.1995 TENTS BOSTON
71388,47 30.09.1995 TENTS BOSTON
66412,33 31.10.1995 TENTS BOSTON
66013,92 31.01.1995 CANOES BOSTON
76083,84 28.02.1995 CANOES BOSTON
91748,16 31.03.1995 CANOES BOSTON
125594,28 30.04.1995 CANOES BOSTON
126713,16 31.05.1995 CANOES BOSTON
147412,44 30.06.1995 CANOES BOSTON
152727,12 31.07.1995 CANOES BOSTON
126433,44 31.08.1995 CANOES BOSTON
122797,08 30.09.1995 CANOES BOSTON

87272,64 31.10.1995 CANOES BOSTON


Створимо звіт в Oracle BI EE Answers за допомогою Direct Request.


Уявімо результати запиту у вигляді крос-таблиці


Висновок

Побудоване нами рішення дозволяє здійснювати прямий доступ до Express Server з СУБД Oracle. Звичайно, у такого рішення є свої обмеження. По-перше, це обмеження, пов’язані з роботою зв’язки SNAPI / XRJ і SNAPI інтерфейсу Express сервера, а по-друге, необхідна наявність СУБД Oracle 10 g і Oracle Reports 10 g. В цілому ж воно дозволяє будувати системи, в яких Express Server і OFA, зокрема, будуть вже не окремо стоять додатками, а інтегрованими в загальну інформаційну середу. Причому рішення локального завдання реалізації інтерфейсу OFA -> Oracle BI Suite EE, дозволило нам створити спільний підхід для підключення Express Server до будь-яких додатків через СУБД Oracle.Такім додатком може бути, наприклад Oracle Discoverer, що входить до складу Oracle BI Suite Standard Edition. Важливим є і те, що тепер Express Server можна включати в будь ETL-процеси, тобто тепер Express стає повноцінним джерелом для побудови сховища даних.

Окремий самостійний ODBC-драйвер або будь-який інший драйвер стандарту доступу до даних JDBC, ODBO або XMLA, звичайно більш універсальний, оскільки може працювати безпосередньо і мати свій власний движок і проміжний шар. Ще одним важливим плюсом окремого драйвера відсутність вимоги в СУБД Oracle 10 g і Oracle Reports 10 g.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*