Источник: bardthabrahabr
Жизнь требует от нас знания худшего, чтобы делать из него лучшее.
Оллпорт Г.
Это моя первая статья на хабре. В ней хотелось бы поделиться своим скромным опытом наступания на грабли в Oracle Business Intelligence EE, дабы, возможно, предостеречь тех, кому еще предстоит этот нелегкий путь. Русских статей и тем более книг по этому продукту я не нашел, поэтому надеюсь, что эта статья станет полезным материалом для всех новичков.
Введение
Oracle Business Intelligence EE (далее Продукт) - это инструмент бизнес-аналитики, который служит для облегчения восприятия больших объемов данных для конечных пользователей. Но прежде, чем эти самые пользователи увидят изящную диаграмму и аккуратную таблицу, нам, то есть разработчикам и администраторам, необходимо покопаться под капотом и как следует вымазаться во всех данных, представлениях и формулах агрегации. В данной статье я буду часто ссылаться на пошаговую инструкцию с официального сайта, потому что основные шаги там уже описаны и мне бы не хотелось повторяться, остановившись подробнее на трудностях, которые я испытал во время работы.
Сразу должен сказать, что столкнулся я с Продуктом почти случайно и опыта в сфере бизнес-аналитики я не имею, поэтому наверняка много из этой статьи покажется читателям очевидным. Во время разработки требований к одному из проектов заказчик пожелал, чтобы отчеты готовились именно в Продукте, потому что он уже куплен и теперь необходимо его покупку оправдать. Ответственным за эту часть проекта был назначен ваш покорный слуга.
Грабли №1. Что от нас ждут
Основным элементом администрирования бизнес-модели в Продукте является Administration Tool. Открыв его впервые, довольно сложно представить (по крайней мере мне), с какой же стороны начать разработку модели. Ответ: с правой.
Перед нами 3 уровня представления. Самый нижний, фундаментальный - справа. Это физический уровень. В нем ожидается увидеть структуру таблиц базы данных как она есть, возможно лишь за исключением не ключевых полей, содержащих лишнюю для пользователя и остальных уровней представления информацию.
Во втором уровне, логическом (или уровне бизнес-модели), от нас ожидают увидеть структуру типа "звезда". Центр звезды - это таблица фактов; лучи звезды - это измерения (dimensions). Тут начинается путаница, так как этот термин используется и для самих таблиц, и для особого типа дополнительной иерархии. Мы можем взять таблицу, которая уже в терминологии называется измерением, и сделать ее настоящим измерением; это означает, что мы сопоставляем определенную иерархию ее полей, по которым будет идти уточнение.
Классический пример: таблица, хранящая информацию о временных периодах. Тут иерархия будет включать в себя год, полугодие, квартал, месяц и т.д.
В самих же логических таблицах будут представлены поля, взятые из физического уровня, вычисляемые и агрегированные поля.
Третий, самый левый уровень, ближе всех к пользователю - презентационный. Здесь мы должны создать структуру, которую уже будет использовать конечный пользователь для составления отчетов. Собственно, это набор полей, которые он сможет включать в отчетные таблицы. А это означает, что то, что мы увидим в левой части экрана - увидит и пользователь. Здесь мы переименовываем поля с внутрибазового на русский язык и меняем их иерархию на понятную пользователю.
Грабли здесь заключаются в том, чтобы понять, для чего служит каждый из уровней, и строго следовать его предназначению. Ниже я расскажу, к чему может привести отсутствие четкого понимания разделения ролей между уровнями.
Подробнее о сборке всех уровней представления - в инструкции.
Грабли №2. Где база? Почему я ее не вижу?
Очень коротко. В пошаговой инструкции приведен способ по настройке ODBC драйвера Oracle. Что же делать, если по тем или иным причинам этот драйвер не доступен или не работает? Все очень просто. Физический уровень поддерживает не только импорт из "видимого" для Administration Tool источника, но и использование обычных Sql запросов. Для этого достаточно создать новую таблицу в физическом уровне, в ее свойствах указав тип Select и ввести необходимый Sql запрос.
Грабли №3. Ходьба по кругу
В нашей разработке база данных была спроектирована таким образом, что возникали несколько путей между двумя таблицами: в моем случае иерархия категорий финансов (таблица В) и структурная иерархия (таблица Г) сходились где-то на верхнем уровне (таблица A), и в то же время существовала таблица фактов, одновременно использующая обе иерархии в качестве измерений (таблица Б). Получается, что от таблицы Б до А можно было добраться двумя путями. Таких приколов Продукт ой как не любит, потому что гарантировать, что в результате мы не придем к противоречивым сведениям, он не может. А мы - можем. Как быть? Опять же, все просто, если знаешь что делать. Таких выкрутасов нельзя допускать в логическом уровне представления, потому что именно по нему осуществляется срез данных, но в физическом все иначе. Все реально существующие взаимосвязи мы формируем на физическом уровне, а на логическом - пытаемся обмануть систему. Я, например, добавил в таблицу Б поле, напрямую ссылающееся на запись в таблице А, в обход обоих иерархий, и одну их иерархий "отрезал" от таблицы А. Кольцо в логическом уровне разомкнулось, а целостность связей осталась нетронутой благодаря физической модели. Возможно есть и другие, более изящные и правильные способы, но предложенный мной - работает, а других я не встретил. И, опять же, таких петель нужно стараться избегать уже при проектировании баз данных, но в моем случае базу дали - надо делать.
Грабли №4. Самые короткие
Не забывайте, что Oracle любит только ПРОПИСНЫЕ буквы. Дабы избежать трудностей в дальнейшем, везде, где это возможно, избегайте строчных букв в названиях таблиц и элементов представления.
На этом будем считать, что с репозиторием мы закончили. Если эта статья понравится читателям, или они по крайней мере выскажут свое мнение в пользу продолжения - я напишу про еще пачку особенностей, на котоыре стоит обратить внимание, связанных не только с репозиторием, но и с администрированием пользовательского пространства Продукта.