Требования, предъявляемые к OLAP-системам

С 1993 года стал проявляться интерес к многомерному представлению данных — в этом году появилась программная статья Эдварда Кодда. В ней он сформулировал двенадцать основных требований к средствам реализации OLAP, дал критическую оценку реляционного подхода в связи с его малой пригодностью к реализации в задачах многомерного анализа данных с повышенными требованиями к времени отклика на аналитические запросы. Они состоят в следующем:

1. Многомерное представление данных.

Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.

2. Прозрачность.

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

3. Доступность.

Средства должны сами выбирать источник данных и связываться с ним для формирования ответа на данный запрос.

4. Согласованная производительность.

Производительность не должна зависеть от количества измерений в запросе.

5. Поддержка архитектуры «клиент-сервер»

Средства должны работать в архитектуре «клиент-сервер».

6. Равноправность всех измерений.

Ни одно из измерений не должно быть базовым, все они должны быть равноправными.

7. Динамическая обработка разреженных матриц.

Неопределенные значения должны храниться и обрабатываться наиболее эффективными способами.

8. Поддержка многопользовательского режима работы с данными.

Все многомерные операции должны поддерживаться многими пользователями.

9. Поддержка операций на основе различных измерений.

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

10. Простота манипулирования данными.

Средства должны иметь максимально удобный и естественный пользовательский интерфейс.

11. Развитые средства представления данных.

Средства должны поддерживать различные способы представления данных.

12. Неограниченное число измерений и уровней агрегации данных.

Не должно быть ограничений на число поддерживаемых измерений.

К 12 правилам впоследствии были присоединены еще шесть.

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

В конце 90-х годов получил распространение свод требований к информационно-аналитическим системам в виде «теста FASMI» — аббревиатуры английских слов, определяющих требования к OLAP-системам: Fast Analysis Shared Multidimensional Information — русский перевод Быстрый Анализ Разделяемой Многомерной Информации.

Раскроем содержание перечисленных свойств, которыми должна обладать OLAP-система.

Fast Быстрый — это свойство выражается во временных требованиях к ответам системы на запросы пользователей. Ответ должен быть получен обычно за время в пределах секунды. Более сложные запросы можно обрабатывать в течение 5-ти секунд и лишь отдельные запросы допускаются с 20-секундной реакцией. Такие требования связаны с психофизиологичекими показателями аналитиков и ЛПР, обусловлены достижением наиболее значимых результатов анализа при выполнении этих требований. Специальные исследования показали, что при времени ответа более 30-ти секунд наступает раздражение и возможна реакция в виде перезапуска системы.

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

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

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

Information Информация — должна обеспечиваться возможность получения ее из любых необходимых источников. Инструментальные средства оперируют с необходимыми объемами и структурами данных.

Более подробно рассмотрим свойство многомерности, так как оно является наиболее характерным отличительным от других систем свойством, в частности OLTP (On line Transaction Processing), которые поддерживают текущую функциональность предприятия.

Как показано в предыдущих параграфах информационное пространство, отображающее функционирование объекта, многомерно. Естественно стремление аналитика и ЛПР к тому, чтобы иметь дело с моделью данных в наиболее естественном виде. Это обстоятельство привело к тому, что с помощью современных программно-технических средств, имеющих широкие возможности интерпретации данных, были созданы соответствующие многомерные модели. Теоретические основы были заложены в трудах крупных российских ученых Ясина, Королева и др. еще в 70-х годах XX века. В трудах Кодда, Инмона легко узнаются основополагающие идеи этих и других ученых, которые были реализованы в большом числе проектов в разных предметных областях.

Задачи и содержание оперативного (OLAP) анализа

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

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

Извлечение необходимой информации для построения отчетов производится путем использования ряда процедур.

К ним относятся:

− сечение или срез (slice and dice) — извлечение данных из факт-таблицы по каким-либо определенным значениям одного или нескольких измерений, например из гипер-куба (факт-таблицы), содержащей сведения об издержках; в отчет (раздел отчета) помещают данные только по какому-либо одному виду или группе издержек;

− поворот, под которым понимают изменение координат, их порядка или добавление измерений; эта процедура обеспечивает замену в готовом отчете «Издержки», к примеру, аргумента — время на регионы или центры затрат; если рассматривалась взаимозависимость «возраст — семейное положение» то можно в качестве аргумента брать любое из этих измерений и менять их местами;

− свертка (drill up) — агрегируются данные по заданным признакам и алгоритмам; можно группировать необходимые данные, содержащиеся в ИХ в детальном виде; так при занесении сведений в операционную БД ежесуточно в ИХ их можно передавать в агрегированном виде — еженедельно или ежемесячно, соответственно агрегированные данные можно помещать в отчеты;

− развертка или раскрытие (roll up) — процедура, обратная свертке, данные детализируются, например группы товаров представляются по конкретным товарам, более крупные временные периоды разбиваются на мелкие и т.д.

− создание кросс-таблиц — то есть совмещение данных из разных таблиц по заданным признакам; например создается отчет, в котором сводятся данные об издержках и выручке по одним и тем же изделиям и временным периодам;

− проекция — конструирование отчетов, являющихся подмножествами из множества единичных реквизитов или атрибутов, содержащихся в операционных базах или в ИХ;

− построение трендов — зависимость числовых или качественных значений показателя от тех или иных параметров, например времени, технологии и т.д.

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

Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse).

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

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

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

Хотя OLAP и не представляет собой необходимый атрибут хранилища данных, он все чаще и чаще применяется для анализа накопленных в этом хранилище сведений.

Место OLAP в информационной структуре предприятия (рис. 1).

Рисунок 1. Место OLAP в информационной структуре предприятия

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

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

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

Типы многомерных OLAP-cистем

Общие положения

В рамках OLAP-технологий на основе того, что многомерное представление данных может быть организовано как средствами реляционных СУБД, так и многомерных специализированных средств, различают три типа многомерных OLAP-систем:

− многомерный (Multidimensional) OLAP — MOLAP

− реляционный (Relation) OLAP — ROLAP

− смешанный или гибридный (Hibrid) OLAP — HOLAP

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

Рассмотрим подробнее сущность, достоинства и недостатки приведенных разновидностей OLAP-систем.

Многомерные OLAP-системы

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

Достоинствами MOLAP являются:

− более быстрое, чем при ROLAP получение ответов на запросы — затрачиваемое время на один-два порядка меньше;

− из-за ограничений SQL затрудняется реализация многих встроенных функций.

К ограничениям MOLAP относятся:

− сравнительно небольшие размеры баз данных — предел десятки Гигабайт,

− за счет денормализации и предварительной агрегации многомерные массивы используют в 2,5-100 раз больше памяти, чем исходные данные (расход памяти при увеличении числа измерений растет по экспоненциальному закону);

− отсутствуют стандарты на интерфейс и средства манипулирования данными;

− имеются ограничения при загрузке данных.

Реляционные OLAP-системы

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

Достоинствами ROLAP-систем являются:

− возможность оперативного анализа непосредственно содержащихся в хранилище данных, так как большинство исходных баз данных — реляционного типа;

− при переменной размерности задачи выигрывают ROLAP, так как не требуется физическая реорганизация базы данных;

− ROLAP-системы могут использовать менее мощные клиентские станции и серверы, в виду того, что на серверы ложится основная нагрузка по обработке сложных SQL-запросов;

− уровень защиты информации и разграничения прав доступа в реляционных СУБД несравненно выше, чем в многомерных.

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

Выполнение же этих условий позволяет при использовании ROLAP-систем добиться схожих с MOLAP-системами показателей в отношении времени доступа, а также превзойти в экономии памяти.

Гибридные OLAP-системы

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

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

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

Тем не менее встречаются обстоятельства, когда применение ROLAP— и HOLAP-cистем становится невозможным из-за чрезвычайно жестких требований со стороны объектов управления или соответственно контролируемых процессов. Такие ситуации характерны для крупных промышленных, транспортных, энергетических комплексов, на финансовых рынках, при управлении объектами в критических ситуациях или их моделировании.

Для такого класса применения ИАС становится безальтернативным применение многомерных или объектно-ориентированных инструментальных средств и методов.

Выбор архитектуры OLAP-приложения

При реализации информационно-аналитической системы важно не ошибиться в выборе архитектуры OLAP-приложения. Дословный перевод термина On-Line Analytical Process — «оперативная аналитическая обработка» — часто воспринимается буквально в том смысле, что поступающие в систему данные оперативно анализируются. Это заблуждение — оперативность анализа никак не связана с реальным временем обновления данных в системе. Эта характеристика относится к времени реакции OLAP-системы на запросы пользователя. При этом зачастую анализируемые данные представляют собой снимок информации «на вчерашний день», если, например, данные в хранилищах обновляются раз в сутки.

В этом контексте более точен перевод OLAP как «интерактивная аналитическая обработка». Именно возможность анализа данных в интерактивном режиме отличает OLAP-системы от систем подготовки регламентированных отчетов.

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

Рисунок 1. OLAP – куб (гиперкуб, метакуб)

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

Очевидно, что время формирования многомерной базы данных существенно зависит от объема загружаемых в нее данных, поэтому разумно ограничить этот объем. Но при этом необходимо не сузить возможности анализа и не лишить пользователя доступа ко всей интересующей информации. Существует два альтернативных пути: Analyze then query («Сначала проанализируй — затем запроси дополнительную информацию») и Query then analyze («Сначала запроси данные — затем анализируй»).

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

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

К достоинствам второго подхода следует отнести «свежесть» информации, которую пользователь получает в виде многомерного отчета — «микрокуба». Микрокуб формируется на основе только что запрошенной информации из актуальной реляционной базы данных. Работа с микрокубом осуществляется в интерактивном режиме — получение срезов информации и ее детализация в рамках микрокуба осуществляется моментально. Другим положительным моментом является то, что проектирование структуры и наполнение микрокуба осуществляется пользователем «на лету», без участия администратора баз данных. Однако подход страдает и серьезными недостатками. Пользователь, не видит общей картины и должен заранее определяться с направлением своего исследования. В противном случае запрошенный микрокуб может оказаться слишком мал и не содержать всех интересующих данных, а пользователю придется запрашивать новый микрокуб, затем новый, затем еще и еще. Подход Query then analyze реализует инструментальное средство BusinessObjects одноименной компании и инструментальные средства платформы Контур компании Intersoft Lab.

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

На работе единой многомерной базы данных практически не сказывается количество обращающихся к ней пользователей. Они лишь читают имеющиеся там данные в отличие от подхода Query then analyze, при котором количество микрокубов в предельном случае может расти с той же скоростью, что и количество пользователей.

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

Наиболее яркими представителями подхода «Analyze then query» являются инструментальные средства PowerPlay и Impromptu компании Cognos.

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

Сферы применения OLAP-технологий

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

Рассмотрим некоторые сферы применения OLAP-технологий, взятые из реальной жизни.

1. Продажи

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

2. Закупки

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

3. Цены

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

4. Маркетинг

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

5. Склад

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

6. Движение денежных средств

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

7. Бюджет

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

8. Бухгалтерские счета

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

9. Финансовая отчетность

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

10. Посещаемость сайта

Лог-файл Интернет-сервера многомерен по природе, а значит подходит для OLAP-анализа. Фактами являются: количество посещений, количество хитов, время проведенное на странице и другая информация, имеющаяся в логе.

11. Объемы производства

Это еще один пример статистического анализа. Таким образом, можно анализировать объемы выращенного картофеля, выплавленной стали, произведенного товара.

12. Потребление расходных материалов

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

13. Использование помещений

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

14. Текучесть кадров на предприятии

Анализ текучести кадров на предприятии в разрезе филиалов, отделов, профессий, уровня образования, пола, возраста, времени.

15. Пассажирские перевозки

Анализ количества проданных билетов и сумм в разрезе сезонов, направлений, видов вагонов (классов), типов поездов (самолетов).

Этим списком не ограничиваются сферы применения OLAP - технологий. Для примера рассмотрим технологию OLAP-анализа в сфере продаж.

Пример использования OLAP-технологий для анализа в сфере продаж

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

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

Измерение «группы товаров» разрабатывается так, чтобы в максимальной степени отразить структуру продаваемой продукции. При этом важно соблюсти определенный баланс, чтобы, с одной стороны, избежать излишней детализации (количество групп должно быть обозримым), а с другой — не упустить существенный сегмент рынка.

Измерение «Клиенты» отражает структуру продаж по территориально-географическому признаку. В каждом измерении могут существовать свои иерархии, например, в данном измерении это может быть структура: Страны – Регионы – Города – Клиенты.

Для анализа эффективности деятельности подразделений следует создать свое измерение. Например, можно выделить два уровня иерархии: департаменты и входящие в них отделы, что и должно найти отражение в измерении «Подразделения».

По сути, измерения «Время», «Товары», «Заказчики» достаточно полно определяют пространство предметной области.

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

Рисунок 2. OLAP – куб для анализа объема продаж

Вот именно такой трехмерный массив в терминах OLAP и называется кубом. На самом деле, с точки зрения строгой математики кубом такой массив будет далеко не всегда: у настоящего куба количество элементов во всех измерениях должно быть одинаковым, а у кубов OLAP такого ограничения нет. Куб OLAP совсем не обязательно должен быть трехмерным. Он может быть и двух-, и многомерным - в зависимости от решаемой задачи. Серьезные OLAP-продукты рассчитаны на количество измерений порядка 20. Более простые настольные приложения поддерживают где-то 6 измерений.

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

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

Рисунок 3. Структура аналитического отчета

Разрежем наш OLAP – куб и получим отчет о продажах за третий квартал, он будет иметь следующий вид (рис.4).

Рисунок 4. Отчет о продажах за третий квартал

Можно разрезать куб вдоль другой оси и получить отчет о продажах группы товаров 2 в течение года (рис. 5).

Рисунок 5. Поквартальный отчет о продажах товара 2.

Аналогично можно проанализировать отношения с клиентом 4, разрезав куб по метке Клиенты (рис. 6)

Рисунок 6. Отчет о поставках товаров клиенту 4.

Можно детализировать отчет по месяцам или говорить о поставках товаров в определенный филиал клиента.

Дата добавления: 2014-02-26; просмотров: 1433; Нарушение авторских прав

Мы поможем в написании ваших работ!