Pull to refresh

IBM Cognos BI и QlikView, с чего начать любопытному?

Reading time 4 min
Views 20K
image

Некоторое время назад я написал статью, в которой относительно кратко описал механику работы с BI системами на примере IBM Cognos BI. Я решил немного развить тему, и сделать своеобразное «сравнение» аналитических продуктов IBM Cognos и QlikView.
Сам материал публикации нельзя назвать сравнением, это больше инструкция «с чего начать?». Я продемонстрирую как сделать относительно несложный отчет 2-мя инструментами — IBM Cognos BI и QlikView, а вы уже сами решите, какой из них больше вам подходит (или не подходит).
Материал статьи будет изложен в виде комбинации немного текста и много видео (любители почитать могут сходить в статью про IBM Cognos BI). Я надеюсь, что такой способ донесения информации будет удобен и сократит время создания материала

Примечания


  1. Все материалы статьи готовились с помощью trial версий программного обеспечения (IBM Cognos Express и QlikView Personal Edition). Это значит, что каждый из вас может зайти на официальный сайт, скачать триал версию и повторить все продемонстрированное;
  2. У меня есть богатый опыт работы с продуктами IBM Cognos (имеется ряд успешных проектов, сертификаты и т. д.), в то же время, опыта работы с продуктами Qlik значительно меньше;
  3. Зачастую, одна и та же задача может иметь несколько вариантов решения, и если я выбрал и продемонстрировал конкретное решение, это не значит, что именно это решение является лучшим или наиболее оптимальным, просто в настоящий момент я решил выполнить конкретную реализацию именно так.

Постановка задачи


Я много думал какой должна быть тестовая задача. С одной стороны, мне хотелось показать побольше функционала, с другой, чем больше функций я рассмотрю, тем объемней становится материал. В итоге я решил, что рассмотренного материала должно быть достаточно, чтобы непосвященный человек мог начать работу с рассматриваемыми инструментами.
Итак, предположим, что некоторый заказчик предоставил нам образец отчета, сделанного в Excel (см. скриншот) и хочет, чтобы мы сделали такой же, выбранным BI инструментом, на базе их витрины данных.

image

Конечно же, в реальной жизни, реальный заказчик, вряд ли предоставит вам такой структурированный и формализованный образец отчета. Реальные образцы зачастую имеют весьма произвольную форму. Но фактически всегда, все отчеты произвольного вида формализуются и структурируются, а потом реализуются в BI системах.
Также как и с отчетом, клиент вероятнее всего вам не предоставит готовую витрину данных и вам придется ее построить самостоятельно, на базе уже существующего хранилища данных (чаще всего сложного и неоднородного). Но в нашем случае мы уже будем располагать готовой витриной данных.



Метаданные


Если говорить простым языком, то метаданные в BI системах, это механизм, с помощью которого пользователь показывает BI системе каким образом организована система хранения данных и как с этими данными работать. Каждая известная мне BI система имеет механизм метаданных. Метаданные — это не всегда просто информация об источнике данных, в ряде случаев, метаданными выступают внутренние механизмы хранения BI системы (например, OLAP кубы). К примеру, метаданными в Cognos BI является формализованное описание структуры системы хранения данных, а в QlikView — таблицы с данными, загруженные в проприетарное хранилище и механизмы их формирования.
Я могу выделить 2 диаметрально противоположных подхода к разработке метаданных:
  1. Минималистичный — метаданные включают в себя тот минимум, который необходим для решения конкретной задачи. Чаще всего такой подход применяют тогда, когда необходимо максимально быстро решить конкретную задачу (построить конкретный отчет). Плюсом такого подхода является очень высокая скорость разработки, недостатком — неуниверсальность, отсутствие потенциала к расширению, ограниченные возможности для построения аналитиком произвольных отчетов. Также, при разработке метаданных в быстром темпе, разработчики часто пренебрегают правилами лучших практик;
  2. Универсальный — метаданные включают в себя максимальное описание источника данных. Такой подход применяют тогда, когда нам необходимо сделать универсальный инструмент для аналитика. Плюсами такого подхода являются высокий потенциал к расширению (обычно в такие метаданные легко добавить новый атрибут, измерение или показатель), универсальность для аналитика (аналитик может быстро и относительно просто строить отчеты фактически любого уровня детализации). Среди недостатков можно отметить длительное время разработки и пониженную скорость работы отчетов на больших объемах данных.

В нашем случае, я постараюсь остановится на золотой середине. Т. е. в метаданные я не буду включать те таблицы, которые не нужны для построения нашего отчета. Но при этом я постараюсь сохранить потенциал к расширению и учесть правила лучших практик.

Метаданные для IBM Cognos BI




Метаданные для QlikView




Отчеты


Когда метаданные готовы, мы можем приступать к разработке отчетов. В процессе разработки отчетов я также буду стараться найти некий компромисс между скоростью разработки отчета и его универсальностью. В принципе все серьезные BI инструменты поддерживают весьма широкий перечень функций (возможность создания параметризованных отчетов, Drill-Down и Drill-Trouth связи, циклическое отображение элементов и т. д.), в данной статье я постараюсь использовать исключительно базовый функционал.

Разработка отчета в IBM Cognos BI




Разработка отчета в QlikView

С моей точки зрения, разрабатывая статический регламентный отчет в QlikView, я поступаю не очень справедливо, т. к. QlikView больше ориентирован на интерактивный анализ данных в режиме реального времени. С другой стороны, моя задача показать базовую механику работы с инструментом, а для этой цели подойдет решение любой тематической задачи.

Tags:
Hubs:
+8
Comments 7
Comments Comments 7

Articles