Причины внедрения информационных систем на основе хранилищ данных

Среди причин, побуждающих компании к реализации прокетов по внедрению информационных систем на основе хранилищ данных:

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

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

Аналитические информационные системы на основе хранилищ данных, позволяют существенно сократить время, требуемое для получения необходимой информации/знаний. Происходит сжатие времени, открывающее возможности для:

	Создания новых бизнес-процессов;
	Ускорения существующих бизнес-процессов. Здесь подразумевается сокращение интервалов времени, после которых принимаются управляющие воздействия.

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

	Центры обработки вызовов. Доступ к информации об абоненте позволяет операторам проводить различные сценарии в общении с абонентами, в зависимости от его принадлежности к той или иной группе. Как результат √ сокращение издержек на содержание службы, увеличение оборота от продажи дополнительных услуг.
	Выявление брака на ранних стадиях за счет более частого анализа претензий покупателей продукции. В результате сокращение расходов по гарантийным обязательствам.
	Коррекция закупок на основе достоверной и своевременной информации об объемах продаж.
	Оптимизация логистики за счет быстрого доступа к информации, предоставляемой распределенной сетью сбыта.
	Сокращение интервалов пересмотра страховых премий поможет страховым компаниям повысить привлекательность услуг и избежать чрезмерных расходов по выплатам;
	и пр.

Таким образом, хранилища данных и аналитические системы, реализуя потенциал уже совершенных инвестиций (существующие информационные системы), открывают для компаний ПРОГНОЗИРУЕМЫЕ возможности по совершенствованию бизнеса.

На самом деле, основными причинами, побуждающими организации внедрять хранилища данных, являются:

	Необходимость выполнения аналитических запросов и генерации отчетов на не задействованных основными информационными системами вычислительных ресурсах.
	Необходимость использования моделей данных и технологий, ускоряющих процесс выполнения запросов и подготовки отчетности, но не предназначенных для обработки транзакций.
	Создание среды, в которой даже относительно небольших знаний основ СУБД достаточно для создания запросов и подготовки отчетов. Это означает сокращение времени, требуемого от персонала ИТ-департамента для сопровождения системы.
	Создание источника с предварительно очищенной информацией.
	Упрощение процесса подготовки отчетов на основе информации из нескольких транзакционных систем и/или внешних источников данных и/или данных, используемых исключительно для генерации отчетов.
	Создание выделенного источника в тех случаях, когда возможности транзакционной системы не соответствует требуемому бизнесом сроку хранения данных и/или необходимо иметь возможность подготовки отчетов на определенные моменты времени в прошлом ("as was" reporting).
	Защита конечных пользователей от необходимости в какой бы то ни было степени вникать в структуру и логику работы БД регистрирующей системы

Применение OLAP технологий при извлечении данных

OLAP (Online Analyzing Processing) - это один из способов добычи и анализа данных. Суть заключается в том, что информация представляется в виде многомерного куба с возможностью произвольного манипулирования ею. По сухому описанию довольно трудно понять, зачем OLAP нужен и как он работает.

Общий принцип работы любой OLAP системы прост. Давайте вначале представим себе отчет в виде куба.

Город	Товар	Январь	Февраль	Март	Итого
Москва	Утюг
	Пылесос
	Чайник
Итого
Рязань	Холодильник
	Чайник
	Телефон
Итого
Владивосток	Утюг
	Телефон
	Пылесос
Итого

На рисунке изображен 3-х мерный куб, хотя количество измерений особого значения не имеет. Просто 3 измерения легче представить. Теперь, если мы сложим значения во всех ячейка по вертикали, то получим следующий отчет.

Город	Январь	Февраль	Март	Итого
Москва
Рязань
Владивосток
Итого

Вся работа с кубом, собственно, и сводится к различным его поворотам, группировкам. Можно менять количество измерений, способы группировки, но это не важно. Принципы совершенно одинаковы. И эти самые принципы порождают определенные проблемы. Дело в том, что при таком представлении данных работать с информацией легко и удобно, но куб очень быстро увеличивается в размерах. И для того, чтобы получить хороший результат, необходимо, чтобы на экран выводился не весь куб, а только нужная его часть. Для этого необходимо: во-первых, иметь возможность выбирать только те измерения, которые нас интересуют. Если вам все равно, в какой город продавался товар, то нужно с самого начала убрать измерение ╚город╩. Во-вторых, иметь возможность выбрать/отсечь ненужные значения. Например, если из всей номенклатуры интересуют только утюги и холодильники, нужно строить куб только для них.

Положительные и отрицательные стороны OLAP-технологии.

У любой технологии есть свои минусы и плюсы, и OLAP тоже не без греха. Во-первых, OLAP рассчитан в первую очередь на анализ процессов. Отгрузка, поступления, оплата √ это эму дается легко. Если вы хотите анализировать объекты, то лучше использовать другой инструментарий. Во-вторых, при работе с OLAP исходят из предположения, что вы четко знаете, какую информацию вы хотите получить из базы данных. OLAP - это прежде всего инструмент добычи информации. Если вам нужно получить ответы на нечетко поставленные вопросы, например, - отобрать 10 лучших клиентов, тут будут проблемы. Вам нужно использовать другие методы анализа, т.к. нет простого определения понятия хороших клиентов, а следовательно невозможно сформировать SQL запрос к базе данных, а SQL - это фундамент на котором все это работает. В-третьих, к OLAP нужно относиться осторожно. Вещь очень мощная, но может мгновенно загрузить все ресурсы сервера. Так что отсекайте как можно больше информации, а лучше строить отдельные хранилища данных. Это оптимальный вариант. Соберите информацию из разных источников, систематизируйте, влейте в хранилище и анализируйте. Вот тут OLAP-у будет где разгуляться. Создание хранилища данных - очень серьезная работа, но чудесного способа решения всех проблем с информацией не существует. Если ваши данные разбросаны где попало и не систематизированы, вам ничто не поможет. В целом, OLAP очень красивая, полезная и интересная технология. Если грамотно подходить к ее применению, то она принесет огромную пользу в вашей ежедневной работе.

Ядро OLAP системы. Часть 1 -- принципы построения

Механизм OLAP является на сегодня одним из популярных методов анализа данных. Есть два основных подхода к решению этой задачи. Первый из них называется Multidimensional OLAP (MOLAP) - реализация механизма при помощи многомерной базы данных на стороне сервера, а второй Relational OLAP (ROLAP) - построение кубов 'на лету' на основе SQL запросов к реляционной СУБД. Каждый из этих подходов имеет свои плюсы и минусы. Их сравнительный анализ выходит за рамки этой статьи. Мы же опишем нашу реализацию ядра настольного ROLAP модуля.

Такая задача возникла после применения ROLAP системы, построенной на основе компонентов Decision Cube, входящих в состав Borland Delphi. К сожалению, использование этого набора компонент показало низкую производительность на больших объемах данных. Остроту этой проблемы можно снизить, стараясь отсечь как можно больше данных перед подачей их для построения кубов. Но этого не всегда бывает достаточно.

В Интернете и прессе можно найти много информации об OLAP системах, но практически нигде не сказано о том, как это устроено внутри. Поэтому решение большинства проблем нам давалось методом проб и ошибок.

Схема работы

Общую схему работы настольной OLAP системы можно представить следующим образом:

Алгоритм работы следующий:

Получение данных в виде плоской таблицы или результата выполнения SQL запроса.

Кэширование данных и преобразование их к многомерному кубу.

Отображение построенного куба при помощи кросс-таблицы или диаграммы и т.п. В общем случае, к одному кубу может быть подключено произвольное количество отображений.

Теперь можно рассмотреть как подобная система может быть устроена внутри. Начнем это с той стороны, которую можно посмотреть и пощупать, то есть с отображений.

Отображения, используемые в OLAP системах, чаще всего бывают двух видов- кросс-таблицы и диаграммы. Рассмотрим кросс-таблицу, которая является основным и наиболее распространенным способом отображения куба.

Кросс-таблица

На приведенном ниже рисунке, желтым цветом отображены строки и столбцы, содержащие агрегированные результаты, светло-серым цветом отмечены ячейки, в которые попадают факты и темно-серым ячейки, содержащие данные размерностей.

Таким образом, таблицу можно разделить на следующие элементы, с которыми мы и будем работать в дальнейшем:

Заполняя матрицу с фактами, мы должны действовать следующим образом:

- На основании данных об измерениях определить координаты добавляемого элемента в матрице.

- Определить координаты столбцов и строк итогов, на которые влияет добавляемый элемент.

- Добавить элемент в матрицу и соответствующие столбцы и строки итогов.

При этом нужно отметить то, что полученная матрица будет сильно разреженной, почему ее организация в виде двумерного массива (вариант, лежащий на поверхности) не только нерациональна, но, скорее всего, и невозможна в связи с большой размерностью этой матрицы, для хранения которой не хватит никакого объема оперативной памяти. Например, если наш куб содержит информацию о продажах за один год, и если в нем будет всего 3 измерения √ Клиенты (250), Продукты (500) и Дата (365), то мы получим матрицу фактов следующих размеров:

Кол-во элементов = 250 х 500 х 365 = 45 625 000

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

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

Рассмотрим, как можно определить координаты факта, зная соответствующие ему измерения. Для этого рассмотрим подробнее структуру заголовка:

При этом можно легко найти способ определения номеров соответствующей ячейки и итогов, в которые она попадает. Здесь можно предложить несколько подходов. Один из них - это использование дерева для поиска соответствующих ячеек. Это дерево может быть построено при проходе по выборке. Кроме того, можно легко определить аналитическую рекуррентную формулу для вычисления требуемой координаты.

Подготовка данных

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

При использовании такой структуры мы значительно снижаем потребность в памяти. Что довольно актуально, т.к. для увеличения скорости работы желательно хранить данные в оперативной памяти. Кроме того, хранить можно только массив элементов, а их значения выгружать на диск, так как они будут нам требоваться только при выводе кросс-таблицы.

Библиотека компонентов CubeBase

Описанные выше идеи были положены в основу при создании библиотеки компонентов CubeBase.

TСubeSource осуществляет кэширование и преобразование данных во внутренний формат, а также предварительное агрегирование данных. Компонент TСubeEngine осуществляет вычисление гиперкуба и операции с ним. Фактически, он является OLAP-машиной, осуществляющей преобразование плоской таблицы в многомерный набор данных. Компонент TCubeGrid выполняет вывод на экран кросс-таблицы и управление отображением гиперкуба. TСubeChart позволяет увидеть гиперкуб в виде графиков, а компонент TСubePivote управляет работой ядра куба.

Сравнение производительности

Данный набор компонент показал намного более высокое быстродействие, чем Decision Cube. Так на наборе из 45 тыс. записей компоненты Decision Cube потребовали 8 мин. на построение сводной таблицы. CubeBase осуществил загрузку данных за 7сек. и построение сводной таблицы за 4 сек. При тестировании на 700 тыс. записей Decision Cube мы не дождались отклика в течение 30 минут, после чего сняли задачу. CubeBase осуществил загрузку данных за 45 сек. и построение куба за 15 сек.

На объемах данных в тысячи записей CubeBase отрабатывал в десятки раз быстрее Decision Cube. На таблицах в сотни тысяч записей √ в сотни раз быстрее. А высокая производительность √ один из самых важных показателей OLAP систем.

Ядро OLAP системы. Часть 2 -- внутри гиперкуба

В предыдущей статье была рассмотрена архитектура и взаимодействие компонентов, которые могут быть использованы для построения OLAP машины. Теперь рассмотрим подробнее внутреннее устройство компонентов.

Загрузка данных в гиперкуб

Первым этапом работы системы будет загрузка данных и преобразование их во внутренний формат. Закономерным будет вопрос - а зачем это надо, ведь можно просто использовать данные из плоской таблицы, просматривая ее при построении среза куба. Для того чтобы ответить на этот вопрос, рассмотрим структуру таблицы с точки зрения OLAP машины.

Для OLAP системы колонки таблицы могут быть либо фактами, либо измерениями. При этом логика работы с этими колонками будет разная. В гиперкубе измерения фактически являются осями, а значения измерений √ координатами на этих осях. При этом куб будет заполнен сильно неравномерно √ будут сочетания координат, которым не будут соответствовать никакие записи и будут сочетания, которым соответствует несколько записей в исходной таблице, причем первая ситуация встречается чаще, то есть куб будет похож на вселенную - пустое пространство, в отдельных местах которого встречаются скопления точек (фактов). Таким образом, если мы при начальной загрузке данных произведем преагрегирование данных, то есть объединим записи, которые имеют одинаковые значения измерений, рассчитав при этом предварительные агрегированные значения фактов, то в дальнейшем нам придется работать с меньшим количеством записей, что повысит скорость работы и уменьшит требования к объему оперативной памяти.

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

Для хранения гиперкуба проще всего использовать базу данных своего внутреннего формата. Схематически преобразования можно представить следующим образом:

То есть вместо одной таблицы мы получили нормализованную базу данных. Вообще-то нормализация снижает скорость работы системы, - могут сказать специалисты по базам данных, и в этом они будут безусловно правы, в случае когда нам надо получить значения для элементов словарей (в нашем случае значения измерений). Но все дело в том, что нам эти значения на этапе построения среза вообще не нужны. Как уже было сказано выше, нас интересуют только координаты в нашем гиперкубе, поэтому определим координаты для значений измерений. Самым простым будет перенумеровать значения элементов. Для того, чтобы в пределах одного измерения нумерация была однозначной, предварительно отсортируем списки значений измерений (словари, выражаясь терминами БД) в алфавитном порядке. Кроме того, перенумеруем и факты, причем факты преагрегированные. Получим следующую схему:

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

Такое будет у нас внутреннее представление гиперкуба. Так как мы делаем его не для реляционной базы данных, то в качестве полей связи значений измерений используются просто поля переменной длины (в РБД такое сделать мы бы не смогли, так как там количество колонок таблицы определено заранее).

Реализация гиперкуба

Можно было бы попытаться использовать для реализации гиперкуба набор временных таблиц, но этот метод обеспечит слишком низкое быстродействие (пример √ набор компонент Decision Cube), поэтому будем использовать свои структуры хранения данных.

Для реализации гиперкуба нам необходимо использовать структуры данных, которые обеспечат максимальное быстродействие и минимальные расходы оперативной памяти. Очевидно, что основными у нас будут структуры для хранения словарей и таблицы фактов. Рассмотрим задачи, которые должен выполнять словарь с максимальной скоростью:

проверка наличия элемента в словаре;

добавление элемента в словарь;

поиск номеров записей, имеющих конкретное значение координаты;

поиск координаты по значению измерения;

поиск значения измерения по его координате.

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

Для оптимизации работы гиперкуба необходимо определить то, какие задачи необходимо решать в первоочередном порядке, и по каким критериям нам надо добиваться повышения качества работы. Главным для нас является повышение скорости работы программы, при этом желательно, чтобы требовался не очень большой объем оперативной памяти. Повышение быстродействия возможно за счет введения дополнительных механизмов доступа к данным, например, введение индексирования. К сожалению, это повышает накладные расходы оперативной памяти. Поэтому определим, какие операции нам необходимо выполнять с наибольшей скоростью. Для этого рассмотрим отдельные компоненты, реализующие гиперкуб. Эти компоненты имеют два основных типа- измерение и таблица фактов. Для измерения типовой задачей будет:

- добавление нового значения;

- определение координаты по значению измерения;

- определение значения по координате.

При добавлении нового значения элемента нам необходимо проверить, есть ли у нас уже такое значение, и если есть, то не добавлять новое, а использовать имеющуюся координату, в противном случае необходимо добавить новый элемент и определить его координату. Для этого необходим способ быстрого поиска наличия нужного элемента (кроме того, такая задача возникает и при определении координаты по значению элемента). Для этого оптимальным будет использование хеширование. При этом оптимальной структурой будет использование хеш-деревьев, в которых будем хранить ссылки на элементы. При этом элементами будут строки словаря измерения. Тогда структуру значения измерения можно представить следующим образом:

PFactLink=^TFactLink;

TFactLink=record

FactNo:integer;//индекс факта в таблице

Next:PFactLink;// ссылка на следующий элемент

End;

TDimensionRecord=record

Value:string;//значение измерения

Index:integer;//значение координаты

FactLink:PFactLink;//указатель на начало списка элементов таблицы фактов

End;

И в хеш-дереве будем хранить ссылки на уникальные элементы. Кроме того, нам необходимо решить задачу обратного преобразования √ по координате определить значение измерения. Для обеспечения максимальной производительности надо использовать прямую адресацию. Поэтому можно использовать еще один массив, индекс в котором является координатой измерения, а значение - ссылка на соответствующую запись в словаре. Однако можно поступить проще (и сэкономить при этом на памяти), если соответствующим образом упорядочить массив элементов так, чтобы индекс элемента и был его координатой.

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

Ядро OLAP системы. Часть 3 -- построение срезов куба

Итак, в предыдущей статье был описан способ хранения данных в виде гиперкуба. Он позволяет сформировать набор точек в многомерном пространстве на основе информации, находящейся в хранилище данных. Для того, чтобы человек мог иметь возможность работы с этими данными, их необходимо представить в виде, удобном для обработки. При этом в качестве основных видов представления данных используются сводная таблица и графики. Причем оба этих способа фактически представляют собой проекции гиперкуба. Для того, чтобы обеспечить максимальную эффективность при построения представлений, будем отталкиваться от того, что представляют собой эти проекции. Начнем рассмотрение со сводной таблицы, как с наиболее важной для анализа данных. Структура сводной таблицы достаточно подробно была рассмотрена в первой статье, посвященной разработке OLAP системы.

Необходимо найти способы реализации такой структуры. Можно выделить три части, из которых состоит сводная таблица: это заголовки строк, заголовки столбцов и собственно таблица агрегированных значений фактов. Самым простым способом представления таблицы фактов будет использование двумерного массива, размерность которого можно определить, построив заголовки. К сожалению, самый простой способ будет самым неэффективным, потому что таблица будет сильно разреженной, и память будет расходоваться крайне неэффективно, в результате чего можно будет строить только очень малые кубы, так как иначе памяти может не хватить. Таким образом, необходимо подобрать для хранения информации такую структуру данных, которая обеспечит максимальную скорость поиска/добавления нового элемента и в то же время минимальный расход оперативной памяти. Этой структурой будут являться так называемые разреженные матрицы, про которые более подробно можно прочесть у Кнута. Возможны различные способы организации матрицы. Для того, чтобы выбрать подходящий нам вариант, рассмотрим изначально структуру заголовков таблицы.

Заголовки имеют четкую иерархическую структуру, поэтому естественно будет предположить для их хранения использовать дерево. При этом схематически структуру узла дерева можно изобразить следующим образом:

Родительский узел	Значение измерения	N (Количество дочерних узлов)	Столбец (строка) со значением
Дочерний узел 1	Дочерний узел 2	┘	Дочерний узел N

При этом в качестве значения измерения логично хранить ссылку на соответствующий элемент таблицы измерений многомерного куба (см. предыдущую статью). Это позволит сократить затраты памяти для хранения среза и ускорить работу. В качестве родительских и дочерних узлов также используются ссылки. Тогда описанную структуру можно реализовать следующим пседокодом:

PHeaderTreeNode=^THeaderTreeNode;
THeaderTreeNode=record
Parent:PHeaderTreeNode;//родительский узел

Value:PDimensionRecord;//значение измерения

ChildCount:integer;//кол-во детей узла

Childs:array of PHeaderTreeNode;//массив детей узла┘

End;

В этом коде пока не указан один элемент - столбец (строка) со значением. О том, чем является это поле, мы поговорим попозже. А теперь перейдем к добавлению элементов в дерево заголовков. Каждый уровень дерева будет соответствовать одному измерению в том порядке, в котором они используются для построения среза. При этом самый верхний узел дерева будет соответствовать полному итогу в сводной таблице.

Для добавления элемента в дерево необходимо иметь информацию о его местоположении в гиперкубе. В качестве такой информации надо использовать его координату, которая хранится в словаре значений измерения (см. предыдущую статью). Рассмотрим схему добавления элемента в дерево заголовков сводной таблицы. При этом в качестве исходной информации используем значения координат измерений. Порядок, в котором эти измерения перечислены, определяется требуемым способом агрегирования и совпадает с уровнями иерархии дерева заголовков. В результате работы необходимо получить список столбцов или строк сводной таблицы, в которые необходимо осуществить добавление элемента.

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

Procedure GetMatrixCol(InpCoord: array of integer; var OutCols: array of PMatrixCol);

//InpCoord √ набор значений координат измерений

// OutCols √ набор столбцов, в формировании значений которых используется данный//факт

Var
xNode:PheaderTreeNode;//текущий узел дерева

I:integer;//Номер текущего уровня дерева

Begin
xNode := RootNode; // присваиваем значение текущего узла в корневой узел

for I:=0 to DimensionsCols.Count √1 do

begin
OutCols[I]:=xNode.MatrixCol;//это ссылка на столбец матрицы

// проверяем, есть ли у нас соответствующий дочерний узел

if xNode.Childs[InpCoord[I]]= nil then

begin
inc(xNode).ChildCount;//увеличиваем счетчик потомков узла // теперь создаем новый узел √ потомок

xNode.Childs[InpCoord[I]]:=new(TColHeaderTreeNode);
SetLength(xNode.Childs[InpCoord[I]].Childs,DimensionsCols[I].Count);
xNode.Childs[InpCoord[I]].ChildCount:=0;
xNode.Childs[InpCoord[I]].Parent:=xNode;
xNode.Childs[InpCoord [I]].Value:=DimensionCols[I].Value[InpCoord [I]];

end;
// переходим к следующему узлу

xNode:=xNode.Childs[InpCoord[I]];
end;

End;

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

Теперь рассмотрим, в каком виде необходимо представить значения внутри столбцов - то есть как определить требуемую строку. Для этого можно использовать несколько подходов. Самым простым было бы представить каждый столбец в виде вектора, но так как он будет сильно разреженным, то память будет расходоваться крайне неэффективно. Чтобы избежать этого, применим структуры данных, которые обеспечат большую эффективность представления разреженных одномерных массивов (векторов). Самой простой из них будет обычный список, одно- или двусвязный, однако он неэкономичен с точки зрения доступа к элементам. Поэтому будем использовать дерево, которое обеспечит более быстрый доступ к элементам. Например, можно использовать точно такое же дерево, как и для столбцов, но тогда пришлось бы для каждого столбца заводить свое собственное дерево, что приведет к значительным накладным расходам памяти и времени обработки. Поступим чуть хитрее √ заведем одно дерево для хранения всех используемых в строках комбинаций измерений, которое будет идентично вышеописанному, но его элементами будут не указатели на строки (которых нет как таковых), а их индексы, причем сами значения индексов нас не интересуют и используются только как уникальные ключи. Затем эти ключи будем использовать для поиска нужного элемента внутри столбца. Сами же столбцы проще всего представить в виде обычного двоичного дерева. Графически полученную структуру можно представить следующим образом:

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

В обобщенном виде последовательность действий для добавления элемента в матрицу можно описать следующим образом:

- Определить номера строк, в которые добавляются элементы

- Определить набор столбцов, в которые добавляются элементы

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

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

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

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

Заключение

Опыт использования технологии OLAP (концерн "Пульсар")

Как эффективно использовать накопившуюся информацию в базах данных? Как заставить числа "заговорить"? Базы данных - это кладезь информации, но нужен гибкий инструмент для выборки и агрегирования данных. Нам хотелось бы поделиться опытом использования одной из аналитических технологий, а именно OLAP.

Справка: Концерн "Пульсар" объединяет 6 совместных узбекско-чешских производственных предприятий и 9 дилерских фирм и в настоящее время является одной из быстроразвивающихся и динамичных компаний на рынке Узбекистана. Компания каждый год осваивает 1-2 новых производства.

Аналитический отдел концерна "Пульсар" занимается исследованием и анализом деятельности предприятий, входящих в состав концерна, а также разработкой перспективных направлений бизнеса.

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

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

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

До объединения предприятий в концерн не существовало единой политики в области информационных технологий. Одни предприятия были автоматизированы комплексно, другие частично, на предприятиях использовались программы разных разработчиков, существовала проблема "островковой автоматизации", то есть не могло быть и речи о единых стандартах в структуре файлов баз данных. И, на первый взгляд, стояла непростая задача извлечения нужной информации из базы данных? Модернизировать программное обеспечение для каждого из предприятий было нецелесообразно и довольно накладно, приводить все данные к единому формату заняло бы достаточно много времени и не было уверенности в том, что это верное решение.

Был проведен анализ рынка аналитического программного обеспечения и, в результате мы остановили свой выбор на программе Cube российского разработчика ПО Basegroup.

Basegroup любезно предоставила нам версию try and buy. Несколько дней работы с пакетом показали, что именно такое ПО подходит для решения наших задач. Первое, что хочется выделить, так это возможность генерации практически любых агрегированных данных за считанные минуты. Полученный результат легко экспортируется MS Excel. Использование программы избавило нас от дополнительного документооборота, если раньше формы сводок составлялись в аналитическом отделе и после согласования с руководством рассылались по всем предприятиям, заполнив которые, нужно было отослать обратно, в настоящее время, пользуясь Cube, мы отказались от подобной практики.

Аналитический отдел имеет доступ к базам данных предприятий, и в нужное время выбирает необходимые данные прямо из них. Несомненным достоинством программы является и то, что ей может пользоваться рядовой пользователь компьютера, не обладающий специальными знаниями в области баз данных. Программа обладает понятным и дружественным интерфейсом и легка в освоении.

Приведем два частных случая использования программы.

Производственные предприятия концерна составляют планы на будущий год, для этого составляются бюджеты продаж, бюджеты расходов по реализации, бюджеты производства, бюджет финансовой деятельности и т.д. Рассмотрим бюджет продаж. Для составления этого бюджета мы использовали статистические данные за предшествующие годы. Для того, чтобы получить предполагаемые продажи за планируемый период, мы должны были учесть сезонность продукта, уровень продаж прошлых периодов, влияние отпускных цен на продажи и другие параметры. Очевидно, что получить эту информацию, используя бухгалтерскую отчетность не так уж просто. И здесь нам на помощь пришла программа Cube, мы не только существенно сэкономили время, отведенное на подготовку плановых данных, но подготовили более качественные данные. Сверка плановых показателей с фактическими выявила небольшие отклонения, что в очередной раз подтвердило оправданность использования Cube.

Вся продукция, производимая предприятиями, реализуется через дилерскую сеть.

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

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

В настоящее время организовано 4 рабочих места, использующие ПО Cube.

Приведем основные достоинства программы:

- Генерация практически любого отчета.

- Экспорт данных в MS Excel.

Нет рутинной работы по составлению отчетов.

Нет необходимости в привлечении квалифицированных программистов.

Нет необходимости изменять существующую информационную систему только для того, чтобы получить новые виды отчетов.

Цена программного продукта и профессионализм службы поддержки.

Теперь мы уверены в том, что все данные обрабатываются и отражаются в отчетах.

Я. Янски - генеральный директор Концерна "Пульсар", кандидат технических наук (jajan@pulsar.uz)

C.14.4.

Литература

1. WWW.BASEGROUP.RU/OLAP/PUISAR.HTM

OLAP в России

В последние годы аналитическая обработка данных постепенно выходит на передний план. Например, аналитические модули появились в составе пакетов финансово-производственных приложений SAP R/3, Oracle Applications и др.; почти одновременно с лидерами мирового рынка включили аналитические модули в свои системы российские фирмы (Парус, АйТи (система (Босс-Корпорация))) и др. В условиях рыночной экономики качество информационной поддержки деятельности руководителей и аналитиков становится одним из факторов достижения предприятиями конкурентных преимуществ. Осуществить такую поддержку непосредственно на основе данных OLTP-систем, автоматизирующих сбор и первичную обработку данных о деятельности предприятия, невозможно. Именно это и обусловило интерес к системам поддержки принятия решений (СППР или DSS по анг.), которые являются основной сферой применения OLAP (On-Line Analytical Processing, оперативная аналитическая обработка, оперативный анализ данных), превращающей руду■ OLTP-систем в готовое изделие, которое руководители и аналитики могут непосредственно использовать.

Сначала кратко об основных классах OLAP-продуктов.

Многомерная модель в OLAP является логической, она может быть реализована как базовая в СУБД (в этом случае говорят о многомерных базах данных (МБД или MDB по анг.) и соответственно о MOLAP) или смоделирована на реляционной базе данных (в этом случае говорят о ROLAP) благодаря применению схемы типа звезда■. В центре звезды находится главная таблица - таблица фактов, запись которой содержит показатель и составной ключ, состоящий из первичных ключей таблиц измерений (лучей, справочных таблиц).

Первоначально мировой рынок OLAP-продуктов развивался как рынок систем, реализующих MOLAP, но с середины 90-х годов основные поставщики реляционных СУБД архитектуры клиент-сервер начинают предлагать ROLAP.

OLAP-продукты, реализующие MOLAP, весьма разнообразны. Хотя статья Кодда привлекла широкое внимание к OLAP в начале 90-х годов, необходимо отметить, что первые MOLAP-системы появились еще в конце 60-х годов. Ряд MOLAP-систем разрабатывался именно как OLAP-продукты, например, семейство Oracle Express, в состав которого входят сервер МБД Express Server, система анализа МБД Express Analyzer, средства разработки OLAP-приложений Express Objects и несколько утилит и готовых приложений. Эти продукты позволяют создавать сложные OLAP-приложения. В других продуктах OLAP реализован как опция, например, как OLAP-модуль в пакете Seagate Info, созданном на основе генератора отчетов Crystal Reports компании Seagate Software.
Естественно, возникает вопрос о том, что предпочтительнее - MOLAP или ROLAP. В самом общем виде ответ звучит так - для больших (десятки гигабайт) баз данных OLAP предпочтительнее ROLAP, для баз данных меньшего размера - MOLAP. Но острота этого вопроса в последнее время снимается благодаря развитию гибридного OLAP - HOLAP: это относится прежде всего к MOLAP-продуктам, которые получают возможность подключения к реляционным базам данных и другим источникам данных и подкачки информации из них (а это особенно важно в российских условиях, но об этом ниже).

Корпорация Oracle помимо развития ROLAP в СУБД ORACLE в 1995 году приобрела семейство MOLAP-продуктов Express.

Корпорации IBM и Microsoft только в прошлом году начали предлагать OLAP в рамках своих серверов баз данных. Подход Microsoft, пожалуй, наиболее оптимален из подходов всех поставщиков OLAP-продуктов с точки зрения реализации HOLAP. Кроме того, предложенный ею протокол доступа к данных OLE DB for OLAP становится таким же стандартом в мире OLAP, каким в мире реляционных СУБД архитектуры клиент-сервер является ODBC. От выхода Microsoft на рынок OLAP ждут многого, но пока еше рано делать выводы о его успешности.

Исходя же из рыночных способов распространения OLAP, можно выделить три класса:

1. готовые тиражируемые OLAP-приложения, распространяемые либо автономно, либо в составе прикладных пакетов;

2. OLAP-приложения, создаваемые в рамках заказных проектов;

3. OLAP-продукты (сервер, средства разработки приложений) для создания OLAP-приложений организацией-покупателем.

Историю OLAP в России следует, наверное, отсчитывать с 1996 года, когда несколько компаний начали заметно продвигать OLAP-продукты. К этому времени относится и разработка первых известных российских OLAP-приложений. Если судить по сайтам компьютерных компаний с описаниями OLAP-продуктов, то в настоящее время OLAP в России и странах СНГ продвигают несколько десятков компаний. Если же принять во внимание другие проявления активности по продвижению OLAP, то придется говорить о гораздо более узком круге компаний.

Компания ⌠Терн■ (www.tern.ru) не только продает комплект BusinessObjects компании Business Objects, она успешно использует его при выполнении заказных проектов. OLAP-продукты компаний Cognos и CA/Platinum продвигает фирма Argussoft (www.argussoft.ru). OLAP-продукты от Oracle, Microsoft и Seagate Software распространяет компания Interface (www.interface.ru), которая регулярно проводит семинары по тематике OLAP и СППР. Финансовые приложения и OLAP-сервер корпорации Hyperion, а также приложения собственной разработки предлагает компания Ланит (www.lanit.ru). Поставщики основных реляционных СУБД архитектуры клиент-сервер и их партнеры также действуют с разной степенью активности на российском рынке OLAP. Крупным организациям предлагает свои сложные и дорогие продукты, в т. ч. и OLAP-продукты, компания SAS Institute.

Что сдерживает развитие российского рынка OLAP? Можно указать ряд причин, обусловленных как действиями поставщиков и распространителей, так и отношением потенциальных пользователей.

С одной стороны, что касается поставщиков и распространители OLAP-продуктов, многие из них ведут работу с выделенными по каким-то критериям (или сложившимися стихийно) узкими кругами организаций. Например, Oracle СНГ и ее партнеры, похоже, наиболее активно продвигает OLAP в России, но это продвижение происходит в рамках продвижения всех продуктов Oracle и покупают Oracle Express в основном пользователи СУБД ORACLE. А ведь OLTP-подсистемы информационных систем множества российских предприятий, в т.ч. и весьма крупных, основаны на файл-серверной технологии (или простейшем варианте технологии клиент-сервер на основе Btrieve) и нет оснований ожидать от них в обозримом будущем массового перехода на технологию клиент-сервер (корпорация ⌠Галактика■ опубликовала результаты продаж своей одноименной системы, позиционируемой как система автоматизации средних и крупных предприятий, в 1999 году. Продажи по платформам СУБД распределились так: Oracle - 16%, Microsoft - 7%, Btrieve - 77%(!!).). Эти организации могли бы использовать MOLAP-продукты, такие как Oracle Express, или OLAP-приложения на основе MOLAP-продуктов.

В целом же создается впечатление о пассивности большинства поставщиков и распространителей OLAP в России, что проявляется в проблемах с русификацией продуктов и документации, технической поддержкой, отсутствием активного маркетинга.

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

В потоке переводных западных публикаций OLAP рассматривается почти всегда в контексте тематики хранилищ данных, больших и сверхбольших баз данных OLTP (десятки и сотни гигабайт данных), информация которых, перекачанная в хранилище/витрины данных, и должна анализироваться средствами OLAP. Базы данных OLTP, с которыми имеют дело российские специалисты, как правило, намного меньше - большими у нас называют базы данных, содержащие несколько гигабайт данных, а то и несколько сот мегабайт.

А это приводит к тому, что специалисты российских предприятий часто воспринимают OLAP как нечто, не имеющее к ним в настоящее время отношения. И не только они. Сотрудники московского офиса одной крупной западной компании, выпускающей ряд программных продуктов, на мой вопрос, почему они не уделяют внимания продвижению своего OLAP-продукта, отвечали:■Но ведь OLAP нужен для баз данных размером под 80 и более гигабайт. А таких баз в России единицы.■(Справедливости ради должен отметить, что этот разговор состоялся два года назад. Но активность этой компании в продвижении своего OLAP-продукта за это время не изменилась.).

Так вот, OLAP успешно применяется для анализа баз данных размером в десятки мегабайт (нужно уточнить, это размер баз данных OLAP, т.е. размер исходных баз данных OLTP в 2-10 больше √ не все данные OLTP нужны для анализа; здесь имеется в виду размер содержательных данных). В 1997 году Международная группа пользователей Oracle провела опрос пользователей Oracle Express, результаты которого были опубликованы на www.ioug.org. Согласно этому опросу, размеры используемых баз данных варьируют в диапазоне от 10 мегабайт до 4 гигабайт, среднее значение от 100 до 350 мегабайт. Эти данные позволяют сделать вывод, что круг российских организаций √ потенциальных пользователей OLAP - очень широк (а ведь многие организации, отработав с данными OLTP, архивируют их, не имея ясных планов по их использованию).

Еще один и, пожалуй, более важный момент заключается в убеждении, также вынесенном из западных публикаций, что аналитика начинается тогда, когда автоматизированы основные бизнес-процессы и информационная система организации построена как совокупность интегрированных подсистем, включая хранилище/витрины данных. На многих же российских предприятиях царит ⌠островковая■ автоматизация, т.е. информационная система √ это ⌠зоопарк■ из слабосвязанных и/или изолированных разнородных (по используемым средствам) подсистем, задач, баз данных. Но российские разработчики успешно использовали OLAP и в таких условиях (в этом случае особенно необходимы OLAP-продукты, реализующие HOLAP), идя от конкретных задач. На Украине фирма UBS (www.ubs-solutions.com) внедряет в одной организации почти полный набор модулей Oracle Applications, причем в первую очередь модули аналитики, используя накопленные данные и не ожидая полного перестроения информационной системы заказчика в результате внедрения других модулей.

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

К настоящему времени в России и странах СНГ уже реализовано не менее 100 проектов с применением OLAP (эта минимальная оценка, скорее разработано 200-300 проектов). Отсутствие активного маркетинга OLAP проявляется, в частности, и в том, что информация об этих проектах редко публикуется. Но даже немногие известные описания проектов, общение с разработчиками OLAP-приложений позволяет сделать некоторые выводы. OLAP-продукты как инструмент разработчика значительно проще, чем СУБД архитектуры клиент-сервер. При реализации OLAP решающее значение имеет качество данных, т.е. их верность, полнота, согласованность. Эта проблема подчеркивается западными пользователями OLAP-продуктов, но, похоже, в России решать ее особенно трудно (как обеспечить сопоставимость ценовых данных за 90-е годы, если учет не велся в у.е.?). OLAP, как отмечалось выше, используется прежде всего в СППР руководителей и в случае успешной реализации OLAP отношение руководителей к ИТ значительно улучшается.

Большинство OLAP-продуктов, которые более-менее активно продвигаются в России, относятся к категории ⌠тяжелых■, в том числе и по цене. И до последнего времени OLAP-продукты преимущественно использовали крупные предприятия, банки и государственные структуры. Но выход бесплатного OLAP-сервера Microsoft, который оказывает ценовое давления на других поставщиков, активизация некоторых распространителей других OLAP-продуктов в России создает условия для применения OLAP-технологии средними и малыми организациями.

Если Вы хотите оспорить/уточнить какие-то положения этой статьи, пишите по адресу arezn99@mail.ru.

ВРЕЗКА1

Аналитическая обработка данных, результаты которой используются конечными пользователями, в СССР ранее реализовывалась на машинах ЕС и СМ ЭВМ. Какие-либо специализированные программные средства для этого не использовались. Как правило, для реализации аналитической обработки применялись те же средства, что и для реализации оперативной обработки транзакций (OLTP) - СУБД и средства разработки приложений, а также генераторы отчетов. Разработчики информационных систем, реализуя как OLTP, так и аналитическую обработку данных, часто сталкивались со следующей проблемой: для оптимальной (в смысле минимизации используемых машинных ресурсов, трудоемкости разработки и т.д. ) реализации OLTP необходима база данных одной структуры, а для оптимальной реализации аналитической обработки необходима база данных другой структуры.

Наиболее важная задача, решаемая с применением OLTP, - это ввод (с контролем) информации в базу данных (технологически, как правило, это множество коротких транзакций к базе данных), который должен быть выполнен в заданный срок. Важность решения этой задачи в рамках любой информационной системы очевидна и если разработчики принимали решение работать с единой базой данных, то выбор этот чаще всего делался в пользу той ее структуры, при которой оптимизировался ввод данных (либо выбиралась структура базы данных не оптимальная ни для ввода данных, ни для аналитической обработки, но позволяющая решать обе задачи удовлетворительно). Но нередко разработчики выбирали работу с двумя базами: ввод данных происходил в одну базу данных, затем после завершения этого процесса прошедшие все необходимые виды контроля данные переносились во вторую базу данных (в первом приближении такую базу можно назвать, используя современную терминологию, хранилищем данных), структура которой выбиралась для оптимизации последующей обработки, в т.ч. и аналитической. Причем необходимость во второй базе данных была тем выше, чем сложнее были запросы к данным при аналитической обработке. Эта схема √ с двумя базами данных, для работы с которыми используется одна СУБД, применяется и в настоящее время. Естественным шагом в развитии схемы с двумя базами данных является использование для работы со второй базой специализированной технологии (и продуктов, которые ее реализуют). Наибольшее признание к настоящему времени в качестве такой технологии получила OLAP-технология.

Определение OLAP как аналитической обработки данных на основе применения многомерной модели данных было предложено в начале 90-х годов Э. Коддом в виде знаменитых 12 правил. По основам OLAP в российских компьютерных изданиях и Интернете опубликовано уже немало статей (см., например, www.olap.ru).

КОНЕЦ ВРЕЗКИ1

ВРЕЗКА2

Сайт www.olapreport.com фирмы Business Intelligence является, возможно, самым полным источником информации по OLAP. Здесь подробно изложена история OLAP и многомерных баз данных, рассмотрены их основные понятия, публикуются подробные обзоры продуктов, анализируется динамика рынка и т.д. Ряд статей c этого сайта переведен на русский язык, см. www.socio.newmail.ru. Пожалуй, единственным спорным разделом этого сайта является изложение анализа характеристик мирового рынка OLAP, методика которого (она изложена на сайте) вызывает сомнения (например, при определении доли Oracle в нее не включены результаты продаж Oracle Discoverer, реализующего ROLAP; кроме того, в анализе учитываются качественно разные продукты √ приложения (Pillar), серверы баз данных OLAP, средства разработки OLAP-приложений, продукты, которые помимо функций OLAP, реализуют и другие функции (BusinessObjects); строго говоря, для корректного анализа надо сегментировать рынок OLAP ┘).

Мировой рынок OLAP-продуктов является одним из наиболее динамичных секторов мирового рынка ПО (это вывод всех исследовательских компаний). Его динамика проявляется как в быстром росте продаж ($1 миллиард в 1996, $1.4 миллиард 1997, более $2 миллиардов в 1998 и $2.5 миллиардов 1999), так и в появлении новых фирм-разработчиков и слияниях (приведены цифры Business Intelligence, которые, как и доли отдельных фирм, весьма отличаются от данных других исследовательских компаний).

Таблица 1. Результаты 10 лидеров мирового рынка OLAP в 1999 и 1998 гг. (взято с www.olapreport.com)

1999 1998

(предварительно)

Поставщик Место Доля (%) Место Доля (%)

["Hyperion Solutions 1 28.4% 1 34.0%

total market]

Hyperion Solutions (Essbase,

Enterprise/Pillar, Wired) 1 23.0% 1 28.7%

Oracle 2 11.4% 2 17.0%

Cognos 3 11.1% 3 9.6%

MicroStrategy 4 7.9% 4 6.5%

Microsoft 5 7.6% - -

Business Objects 6 5.3% 6 4.4%

Comshare 7 3.2% 5 4.8%

Applix 8 3.1% 10 2.5%

IBM 9 3.0% 13 1.9%

(включая продажи DB2 OLAP Server и перепродажи Essbase)

Sterling Software 10 2.8% 9 2.9%

Учитывая эти моменты, а также динамичность мирового рынка OLAP, не стоит придавать данным таблицы 1 чрезмерного значения. К тому же эти данные (финансовые результаты) не отражают распространенности (числа используемых копий) OLAP-продуктов.

КОНЕЦ ВРЕЗКИ2

ВРЕЗКА 3

Автор обратился к компаниям, действующим на российском рынке OLAP, с просьбой вкратце его охарактеризовать. Были получены следующие ответы.

Дмитрий Загороднийчук, менеджер по маркетингу компании Avicomp Services AG:

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

На многих предприятиях внедрение OLAP-систем не является первоочередной задачей. Не все руководители предприятий понимают выгоду от использования средств анализа. А многие из тех руководителей, которые видят, как использовать OLAP-системы в управлении предприятием, не имеют возможности выделить ресурсы для их внедрения.

Специальной оценки конкурентов на рынке OLAP мы не проводили, это относится и к выходу Microsoft на этот рынок.

Александр Пелагейкин, менеджер по маркетингу компании РДТЕХ:

Компания РДТЕХ с 1998 года начала разработку отчетно-аналитических систем и продажу продуктов Oracle Express. Российский рынок OLAP пока не развит, но тем не менее, видится нам перспективным. Мешает его развитию отсутствие усилий по его формированию. В случае ИТ не спрос рождает предложение, а предложение формирует рынок и спрос.

В данный момент многие компании в России занимаются тематикой OLAP, поэтому кого-то выделять я не буду.

Если говорить о выходе Microsoft на рынок OLAP, то еще рано говорить о каких-либо оценках, так как не слышно что-то о реализации проектов на российском рынке с использованием продуктов Microsoft. В компьютерной прессе (включая Интернет) неоднократно появлялись обзоры продуктов OLAP, в которых обсуждались и продукты Microsoft. Если судить по этим публикациям, то продукт Microsoft пока "сыроват" и тягаться с лидерами ему тяжело.

Сергей Шургин, менеджер по маркетингу компании Терн:

Компания Терн действует на рынке OLAP с 1996 года. С 1997 г. мы являемся региональным партнером компании Business Objects в России и странах СНГ. Рынок OLAP в России до конца не сформирован, но в ближайшем будущем преобразуется в важный отдельный сегмент рынка ИТ. Мешает слабая развитость информационных систем на российских предприятиях и недостаточноеосмысление необходимости их использования. Под слабым развитием в первую очередь понимается невостребованность информ. систем руководством и персоналом компаний, плохая постановка учета и управления. Не хотелось бы выделять какие-либо компании среди конкурентов, т.к. на самом деле их очень много. Выход Microsoft на рынок OLAP мы оцениваем положительно, так как эта компания будет популяризовывать OLAP вообще, но пока не в состоянии

⇐ Предыдущая 1 2 3 4 567 8 9 Следующая ⇒