|
2 Sergey P
С OLAP каталогом существует большая путаница и еще одна путаница с тем, что в Oracle OLAP сейчас по сути два OLAP - реляционный или многомерный.
Смотрим вот эту презентацию -
http://www.events.lanit.ru/seminar121003/presentation/LANIT_Oracle_OLAP_Option.pdf
Там есть диаграмма с OLAP каталогом и что он из себя представляет.
OLAP каталог - это хранилище метаданных - то есть описаний того, что у нас есть в OLAP.
Идея на самом деле очень хорошая - у вас есть реляционные таблицы и вы с ними работаете, но потом вы эти же таблицы можете использовать как OLAP кубы - для этого нужно _зарегистрировать_ их в OLAP каталоге. Там регистрируется: что у вас является кубом, что измерениями, какие метки, какие иерархии у вас есть и проч. И после этого вы можете смотреть на эти ваши таблицы через BI Beans, которые содержат массу полезных для пользователя фич и избавляют программиста от лишней работы.
Кстати вы можете попробовать загреистрировать свои кубики в каталоге и получить именно ROLAP разработку.
Второй вариант - это Analytic Workspaces, бывший Express - вы можете делать кубы и все остальное сразу в многомерном виде, в случаях, если многомерная модель лучше подходит для вашей задачи. Потом вы точно также _регистрируете_ ваши объекты в OLAP каталоге и пользователь может с ними работать.
То есть получается, что в одной разработке может быть сразу кубики и в реляционном виде и в многомерном, при этом пользователь работает с ними в едином интерфейсе и не подозревает о том в каком виде лежит конкретный кубик.
Теперь следующий вопрос - на чем делать. У меня есть опыт работы и с Oracle OLAP и с MS AS и с другими средствами, что интересно, я был вероятно на самом первом курсе или на одном из самых первых курсов Microsoft по MS AS, который читался в России в 1999 году. Читал его г-н Александр Денисенко, которого я очень уважаю и который, по-моему, имеет отношение к этому сайту, по крайней мере как автор статей.
К чему я это? В то время MS AS был очень сырой, о чем говорят хотя бы ошибки при обсчете суммы по иерархии. То есть есть у тебя иерархия из трех слоев - считаем сумму наверх и получаем число с ошибкой в третьем знаке после запятой. Бред. Но после этого Microsoft очень хорошо вылизали свой движок и практически через год уже им можно было пользоваться.
На мой взгляд, у MS AS есть несколько больших преимуществ, в том числе очень быстрый и мощный движок, который в большинстве случаев не требует тюнинга со стороны администратора и второе - традиционно микрософтовское преимущество - дружественность интерфейса - на нем действительно можно очень быстро построить рабочий кубик.
Но что до сих пор в MS AS нет - это возможности построения нормального пользовательского интерфейса.
Есть два типа пользователей аналитических систем (на самом деле их больше, но для просто ты возьмем два)
1. Пользователь-аналитик, со знанием SQL
2. Конечный пользователь, который работает только с готовыми отчетами и понятия не имеет об SQL.
Для первого типа пользователей, к которым я и себя могу отнести, интерфейс не имеет решающего значения - он всегда может получить ответ на вопрос написав SQL запрос или используя любое общеупотребимое средство типа Oracle Discoverer, BO или Proclarity. В некоторых случаях можно работать и с Excel, если база не очень большая.
Для второго типа пользователей конечный интерфейс важен часто даже больше, чем данные которые они с помощью него извлекают - и вот для таких пользователей и нужно мощное гибкое средство построения интерфейсов. Причем второй тип пользователей чаще всего начальство или другие ЛПР.
А для каждой системы требования могут быть свои. Где то нужно скрестить базу с географическими картами, где то нужна система триггерной подсветки событий, где то нужен необычный навигатор, например если в измерении 300 тысяч листьев и нужно производить поиск по ним, где то нужны модели и функции, где то нужно чтобы на графике данные по конкретному товару раскрашивались строго в определенный цвет. Во многих подобных случаях Excel мало подходит да и в самом MS AS кроме числодробилки мало что есть. Например нет ни моделей ни функций.
Если ваш проект в том, чтобы выгрузить данные из 1с маленькой фирмы - то вас вполне устроит MS AS + Excel, а вот если у вас проект большой, даже выгрузить данные по большой торговой сети, то экселя начинает стремительно не хватать. Если проект специфический, то точно нужно средство разработки, а не просто клиент общего плана.
Вывод такой - если вы делаете систему для себя самого, то вам возможно либо OLAP вообще не нужен, либо сойдет реляционный, либо Cognos , либо MS AS.
Если у вас система большая, нестандартная и для крупного предприятия, то MS AS и прочего может не хватить. Вернее их можно использовать в части отчетов, но далеко не во всем. Ирония в том, что движок MS AS позволяет вытянуть практичкски неограниченные по объему и сложности кубы, а вот с интерфейсом почему то до сих пор плохо (или может я чего то не знаю).
Посмотрим что может Reporting Services, но пока на революцию не похоже.
У Oracle в этом плане ситуация такая, что прототип сделать сложнее с точки зрения простоты интерфейса, зато возможностей в принципе больше.
Что же касается того что Express теперь AW - задача видимо очень сложная и на первом этапе нужно было сделать, чтобы AW в принциипе заработал, даже в том же функционале что был у Express, а в 10g уже начнутся доработки по фенькам и по производительности.
Чего то я расписался в последний день года :) Все мысли, как обычно, мои собственные, возможно я в чем то не прав.
|
