Сущность оперативной аналитической обработки данных (OLAP)

Содержание:

Введение

OLAP (online analytical processing) - представляет собой инструмент для анализа больших объёмов данных. В базе OLAP-технологий находятся понимание данные в виде OLAP-кубов. OLAP-кубы включают в себя бизнес - показатели, применяемые с целью рассмотрения и принятия управленческих решений, например: собственные средства, совокупные средства (активы), заёмные средства, рентабельность продукции, прибыль и т.д.

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

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

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

Целью курсовой работы – является рассмотрение особенности технологии OLAP.

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

Объектом курсовой работы является технология OLAP.

Глава 1. Теоретические основы использования OLAP технологии

1.1. Понятие технологии OLAP

OLAP (оперативный анализ данных) — представляет собой инструмент для анализа больших объёмов данных. Взаимодействуя с OLAP-системой, пользователь сможет осуществлять гибкий просмотр информации, получать произвольные срезы данных и выполнять аналитические операции детализации, свёртки, сквозного распределения, сравнения во времени. Вся работа с OLAP-системой происходит в терминах предметной области^[1].

OLAP-системы являются часть более общего определения Business Intelligence, что включает в себя кроме классического OLAP-сервиса средства компании общего применения документов, возникающих в процессе деятельности пользователей хранилища. Методика Business Intelligence гарантирует электронный обмен отчётными документами, разделение прав пользователей, доступ к аналитической информации из Internet/Intranet.

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

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

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

В 1993 г. Е.Ф. Коддом — создателем концепции реляционных СУБД и, по совместительству, OLAP — были сформулированы критерии OLAP. Они заключаются в недочетах реляционной модели и, в главную очередь, свидетельствуют на невозможность «объединять, смотреть и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных специалистов способом». Единые условия к системам OLAP, расширяют работоспособность реляционных СУБД и содержат трехмерный анализ как одну из собственных характеристик.

Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP:

Многомерное концептуальное представление данных. Концептуальное представление модели данных в OLAP должно быть многомерным согласно своей природе, то есть позволять специалистам реализовывать подсознательные процедуры «анализа вдоль и поперёк», вращения и размещения направлений консолидации.

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

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

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

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

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

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

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

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

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

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

Комплект этих требований, послуживших фактическим определением OLAP, следует рассматривать равно как рекомендательный, а конкретные продукты оценивать по степени приближения к идеально полному соответствию абсолютно всем требованиям. Позднее все эти требования были переработаны в так называемый тест FASMI, который также определяет требования к продуктам OLAP. FASMI — это аббревиатура от названия каждого пункта теста^[2]:

Fast (Быстрый). Система OLAP должна обеспечивать минимальное время доступа к аналитическим данным — в среднем порядка 5 секунд;

Analysis (Анализ). Система OLAP должна давать пользователю возможность осуществлять числовой и статистический анализ;

Shared (Разделяемый доступ). Система OLAP должна предоставлять возможность работы с информацией многим пользователям одновременно;

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

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

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

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

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

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

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

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

Одним из популярных средств исследования OLAP-систем считается семейство программных продуктов Oracle Express OLAP фирмы Oracle. Программное предоставление Oracle Express предоставляет обширные способности для формирования аналитических концепций на основе сервера многомерных баз данных — Oracle Express Server. В состав инструментальных средств Oracle Express входят ресурсы администрирования и формирования многомерных баз данных — Express Administrator, способ визуального формирования облегченных клиентских демонстраций и дополнений — Express Analyzer, профессиональная инструментальная среда объектно-ориентированной разработки OLAP-приложений — Express Objects, позволяющая формировать непростые встроенные клиентские дополнения, и прочие средства, сопряженные с публикацией данных в Сети интернет.

Концептуальное многомерное представление двенадцать правил Кодда^[3]:

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

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

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

4. Постоянная производительность при разработке отчетов — производительность OLAP-систем не должна значительно уменьшаться при увеличении количества измерений, по которым выполняется анализ.

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

6. Равноправие измерений — OLAP-система должна поддерживать многомерную модель, в которой все измерения равноправны. При необходимо­сти дополнительные характеристики могут быть предоставлены отдель­ным измерениям, но такая возможность должна быть предоставлена лю­бому измерению.

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

8. Поддержка многопользовательского режима — OLAP-система должна предоставлять возможность работать нескольким пользователям совместно с одной аналитической моделью или создавать для них различные модели из единых данных. Из-за возможности чтения и записи данных, система должна обеспечивать целостность и без­опасность информации.

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

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

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

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

Набор этих требований, послуживших де-фактором определением OLAP, довольно часто вызывает разнообразные нарекания, к примеру, принципы 1, 2, 3, 6 считаются требованиями, а принципы 10, 11 — неформализованными пожеланиями. Таким образом, приведенные 12 требований Кодда никак не дают возможность точно установить OLAP. В 1995 г. Кодд добавил ещё 6 правил:

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

2. Поддержка всех моделей OLAP-анализа — OLAP-система обязана сохранять все без исключения 4 модели анализа данных, определенные Коддом: стереотипную, толковательную, умозрительную и категориальную.

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

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

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

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

Кроме того, Кодд разбил все восемнадцать правил на четыре группы, и назвал их особенностями. Группы получили названия: В, S, R и D.

Основные особенности (В) включают следующие правила:

• многомерное концептуальное представление данных (правило 1);
• интуитивное манипулирование данными (правило 10);
• доступность (правило 3);
• пакетное извлечение против интерпретации (правило 13);
• поддержка всех моделей OLAP-анализа (правило 14);
• архитектура "клиент-сервер" (правило 5);
• прозрачность (правило 2);
• многопользовательская поддержка (правило 8).
• Специальные особенности (S):
• обработка ненормализованных данных (правило 15);
• сохранение результатов OLAP: хранение их отдельно от исходных данных (правило 16);
• исключение отсутствующих значений (правило 17);
• обработка отсутствующих значений (правило 18).
• Особенности представления отчетов (R):
• гибкость формирования отчетов (правило 11);
• стандартная производительность отчетов (правило 4);
• автоматическая настройка физического уровня (измененное оригинальное правило 7).
• Управление измерениями (D):
• универсальность измерений (правило 6);
• неограниченное число измерений и уровней агрегации (правило 12);
• неограниченные операции между размерностями (правило 9).

1.2. История создания технологии

Концепция обработки данных на многомерных массивах не считается новой. По сути она восходит к 1962 г., когда Ken Iverson издал собственную книгу “Язык программирования” (“A Programming Language”, APL). Первая фактическая реализация APL произошла в запоздалых 60-х фирмой IBM. APL – это весьма изящный, математически установленный стиль с многомерными неустойчивыми и обрабатываемыми операциями. Он подразумевался как оригинальное мощное средство по работе с многомерными переустройствами согласно сравнению с иными практическими стилями программирования.

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

Однако недовольство от этих начальных ошибок не убила идею. Она применялась во многих деловых приложениях 70-х, 80-х годов. Многие из этих приложений обладали особенностями нынешних систем аналитической обрабатывания. Таким образом, IBM создала операционную систему для APL, названную VSPC, и определенные люди полагали её идеальной средой для индивидуального применения, сейчас электронные таблицы не стали повсеместно распространены.

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

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

В 1972 г. несколько прикладных многомерных программных продуктов, прежде использовавшихся в учебных целях, отыскали коммерческое использование: Express. Он в полностью переписанном виде остаётся и в настоящее время, но уникальные концепции 70-х годов прекратили являться актуальными. На сегодняшний день, в 90-х, Express считается одной из более известных OLAP-технологий, и Oracle будет продвигать его и дополнять новейшими способностями.

Больше многомерных продуктов возникло в 80-х годах. В начале десятилетия – продукция с названием Stratagem (позже именуемый Acumate). Который ещё продвигался вплоть до начала 90-х. На сегодняшний день, в отличие от Express, почти не применяется.

Comshare System W был многомерным продуктом другого стиля. Предложенный в 1981 г., он был первоначальным, где планировалась значительная ориентированность на конечного пользователя и на разработку финансовых дополнений. Он привнёс немало концепций, которые, разумеется, никак не были хорошо адаптированы, такие, как полностью непроцедурные принципы, полноэкранный просмотр и исправление многомерных данных, автоматическое перевычисление и пакетная интеграция с реляционными данными. Но Comshare System W был довольно тяжел для аппаратного обеспечения того времени согласно сравнению с иными продуктами и меньше применялся в перспективе, реализовываться всё меньше, и в продукте не совершалось практически никаких усовершенствований. Хотя он и на сегодняшний день доступен в UNIX, он не считается клиент-серверным, что не содействует увеличению его предписания в рынке аналитических товаров. В запоздалых 80-х Comshare выпустил продукт для DOS, а позже для Windows. Данные продукты именовались Commander Prism и использовали те же концепции, что и System W.

Другой творческий продукт поздних 80-х именовался Metaphor. Он предназначался для профессиональных маркетологов. Он также предложил немало новейших концепций, которые только на сегодняшний день начинают широко применяться: клиент-серверные расчеты, применение многомерной модели в реляционных данных, объектно-ориентированная разработка приложений. Но обычное аппаратное предоставление индивидуальных машин тех дней не было способно работать с Metaphor и поставщики должны были создавать личные стандарты на персональные машины и сети. Постепенно Metaphor начал работать успешно и на серийных индивидуальных машинах, но продукт был сделан только для OS/2 и имел свой личный графический интерфейс пользователя.

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

В середине 80-х родился термин EIS (информационная система руководителя). Первым продуктом, ясно продемонстрировавшим это направление, был Pilot’s Command Center. Это был продукт, который позволял выполнять совместные вычисления, то, что мы называем сегодня клиент-серверными вычислениями. Поскольку мощность персональных компьютеров 80-х годов была ограничена, продукт был очень “серверо-центричен”, однако этот принцип и сегодня очень популярен. Pilot недолго продавал Command Center, но предложил много концепций, которые можно узнать в сегодняшних OLAP-продуктах, включая автоматическую поддержку временных промежутков, многомерные клиент-серверные вычисления и упрощённое управление процессом анализа (мышь, чувствительные экраны и т.п.). Некоторые из этих концепций были повторно применены позднее в Pilot Analysis Server.

В конце 80-х электронные таблицы были доминирующими на рынке инструментов, предоставляющих анализ конечным пользователям. Первая многомерная электронная таблица была представлена продуктом Compete. Он продвигался на рынок как очень дорогой продукт для специалистов, но поставщики не обеспечили возможность захвата рынка этим продуктом, и компания Computer Associates приобрела права на него вместе с другими продуктами, включая Supercalc и 20/20. Основным эффектом от приобретения CA Compete было резкое снижение цены на него и снятие защиты от копирования, что, естественно, способствовало его распространению. Однако он не был удачным. Compete положен в основу Supercalc 5, но многомерный аспект его не продвигается. Старый Compete всё ещё иногда используют в связи с тем, что в свое время в него были вложены немалые средства.

Фирма Lotus была следующей, кто попытался вступить на рынок мно-гомерных электронных таблиц с продуктом Improv, который запускается в NeXT машине. Это давало гарантию, как минимум, что продажи 1-2-3 не понизятся, но когда этот со временем был выпущен под Windows, Excel ранее имел значительную часть рынка, что не разрешило Lotus внести какие-либо перемены в разделение рынка. Lotus, подобно CA с Compete, переместила Improv в нижнюю часть рынка, но и это не стало условием успешного продвижения в рынке, и новейшие исследования в данной сфере не приобрели продолжения. Обнаружилось, что пользователи индивидуальных ПК выбрали электронные таблицы 1-2-3 и не интересуются новыми многомерными способностями, в случае если они не полностью совместимы с их прежними таблицами. Так же концепции небольших, настольных электронных таблиц, предлагаемых как индивидуальные приложения, в реальности не стали комфортными и не прижились в реальном деловом обществе. Microsoft вышла по данному пути, добавив PivotTables (в русской редакции это называется “сводные таблицы”) к Excel. Хотя немногие пользователи Excel приобрели выгоду от использования данной способности, это, вероятно, исключительный факт широкого применения в обществе возможностей многомерного анализа просто потому, что в мире весьма немало пользователей Excel.

Глава 2. OLAP-клиент - OLAP-сервер, реализации OLAP

2.1 OLAP – клиент – OLAP- сервер

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

Объем обрабатываемых данных

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

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

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

Помимо этого, на число измерений накладывают ограничения возможности человеческого восприятия. Установлено, что средний человек способен одновременно оперировать 3-4, максимум 8 измерениями. При огромном числе измерений в динамической таблице восприятие данных значительно усложняется. Этот фактор необходимо принимать во внимание при предварительном расчете своевременной памяти, которая может понадобиться OLAP-клиенту.

Длина измерений также оказывает большое влияние на объем адресного пространства OLAP-средства, занимающегося при вычислении OLAP-куба. Чем длиннее измерения, тем больше ресурсов необходимо для выполнения предварительной сортировки многомерного массива, и наоборот. Только лишь короткие измерения в начальных данных – ещё один довод в пользу OLAP-клиента.

Производительность системы

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

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

Однако до определенного объема данных производительность серверных и клиентских средств является сопоставимой. Для OLAP-клиентов, поддерживающих распределенные вычисления, область сопоставимости производительности может распространяться на объемы данных, покрывающие потребности в OLAP-анализе огромного количества пользователей. Это подтверждают результаты внутреннего тестирования MS OLAP Server и OLAP-клиента "Контур Стандарт". Тест выполнен на ПК IBM PC Pentium Celeron 400 МГц, 256 Mb для выборки в 1 миллион уникальных (т.е. агрегированных) записей с 7 измерениями, содержащими от 10 до 70 членов. Время загрузки куба в обоих случаях не превышает 1 секунды, а выполнение различных OLAP-операций выполняется за сотые доли секунды.

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

Следует помнить, что точка "перелома" определяет границу резкого удорожания OLAP-решения. Для задач каждого конкретного пользователя эта точка легко определяется по тестам производительности OLAP-клиента. Такие тесты можно получить у компании-разработчика.

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

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

Организация архитектур с прямым доступом к первичным данным

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

Аналогичным образом, целый ряд OLAP-клиентов дает возможность реализо-вать ROLAP- и Desktop-архитектуру с прямым доступом к БД. Это гарантирует анализ начальных данных в режиме online.

Мощность ПК пользователей

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

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

Сетевой трафик

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

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

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

Поэтому в подавляющем большинстве случаев анализ БД "средних" объемов с поддержкой OLAP-клиента не будет тормозить работу пользователя.

Затраты на внедрение и сопровождение

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

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

Принципы работы OLAP-клиентов

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

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

Рассмотрим процесс создания OLAP-приложения с помощью клиентского инструментального средства. (Приложение Б)

Принцип работы ROLAP-клиентов - предварительное описание семантического слоя, за которым скрывается физическая структура исходных данных. При этом источниками данных могут быть: локальные таблицы, РСУБД. Список поддерживаемых источников данных определяется конкретным программным продуктом. После этого пользователь может самостоятельно манипулировать понятными ему объектами в терминах предметной области для создания кубов и аналитических интерфейсов.

Принцип работы клиента OLAP-сервера иной. В OLAP-сервере при создании кубов пользователь манипулирует физическими описаниями БД.

При этом в самом кубе создаются пользовательские описания. Клиент OLAP-сервера настраивается только на куб.

Поясним принцип работы ROLAP-клиента на примере создания динамического отчета о продажах (Приложение Б). Пусть исходные данные для анализа хранятся в двух таблицах: Sales и Deal.

При создании семантического слоя источники данных - таблицы Sales и Deal - описываются понятными конечному пользователю терминами и превращаются в "Продукты" и "Сделки". Поле "ID" из таблицы "Продукты" переименовывается в "Код", а "Name" - в "Товар" и т.д.

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

Далее на базе бизнес-объекта создается OLAP-отчет. Пользователь выбирает бизнес-объект и перетаскивает его атрибуты в области колонок или строк таблицы отчета.

В нашем примере на базе бизнес-объекта "Продажи" создан отчет по продажам товаров по месяцам.

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

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

2.2 Реализации OLAP

Известные OLAP-продукты^[4]

Первым продуктом, выполняющим OLAP-запросы, был Express (компания IRI). Однако, сам термин OLAP был предложен Эдгаром Коддом, «отцом реляционных БД». А работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт — Essbase (позже купленный Hyperion, которая в 2007 г. была поглощена компанией Oracle) — годом ранее. Другие хорошо известные OLAP-продукты включают Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), Oracle OLAP Option, DB2 OLAP Server от IBM (фактически, EssBase с дополнениями от IBM), SAP BW, продукты Brio, BusinessObjects, Cognos, MicroStrategy и других производителей.

C технической точки зрения, представленные на рынке продукты делятся на "физический OLAP" и "виртуальный". В первом случае наличествует программа, выполняющая предварительный расчет агрегатов, которые затем сохраняются в специальную многомерную БД, обеспечивающую быстрое извлечение. Примеры таких продуктов - Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay. Во втором случае данные хранятся в реляционных СУБД, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов - SAP BW, BusinessObjects, Microstrategy. Системы, имеющие в своей основе "физический OLAP" обеспечивают стабильно лучшее время отклика на запросы, чем системы "виртуальный OLAP". Поставщики систем "виртуальный OLAP" заявляют о большей масштабируемости их продуктов в плане поддержки очень больших объемов данных.

Deductor

В настоящей работе мне хотелось бы подробнее рассмотреть продукт компании BaseGroup Labs – Deductor.

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

Состав системы:

1. Studio

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

2. Viewer

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

3 Warehouse

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

4. Client-Server

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

Принципы работы^[5]:

1. Импорт данных

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

2. Экспорт данных

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

3. Обработка данных

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

4. Визуализация

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

5. Механизмы интеграции

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

6.Тиражирование знаний

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

Заключение

Таким образом, в процессе рассматриваемой темы я выяснил, что концепциями поддержки принятия решений может быть создана в подсистеме оперативного анализа. С целью которой и используется методика оперативной аналитической обработки данных OLAP (Online analytical processing), использующая теорию многомерного представления данных.

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

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

Список использованных источников

1. Альперович М. Введение в OLAP и многомерные базы данных. – М.: Вильямс. 2012.
2. Архипенков С. Я., Голубев Д. В., Максименко О. Б. Хранилища данных. - Издательство: Диалог-МИФИ, 2012.
3. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Методы и модели анализа данных OLAP - Издательство: БХВ-Петербург, 2013.
4. Бергер А. OLAP и многомерный анализ данных / — СПб: БХВ-Петербург, 2013.
5. Дегтярев Ю.И. Системный анализ и исследования операций. -- М.: Высш. ш., .2012.
6. Елманова Н.В., Федоров А.А. Введение в OLAP-технологии Microsoft. – М.: Диалог-МИФИ, 2014.
7. Заботнев М.С.Методы представления информации в разреженных гиперкубах данных [Электронный ресурс]. — Режим доступа: http://www.olap.ru/basic/theory.asp
8. Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных. // СУБД. – 2012.
9. Кречетов Н., Иванов П. Продукты для интеллектуального анализа данных. // ComputerWeek-Москва. – 2013.
10. Федоров А., Елманова Н. Основы OLAP // КомпьютерПресс. – 2014.

Приложение А

Зависимость производительности клиентских и серверных OLAP-средств от увеличения объема данных

Приложение Б

Создание OLAP-приложения с помощью клиентского ROLAP-средства

1. Альперович М. Введение в OLAP и многомерные базы данных. – М.: Вильямс. 2012.

   ↑

2. Федоров А., Елманова Н. Основы OLAP // КомпьютерПресс. – 2014. ↑

3. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Методы и модели анализа данных: OLAP - Издательство: БХВ-Петербург, 2013. ↑

4. Альперович М. Введение в OLAP и многомерные базы данных. – М.: Вильямс. 2012. ↑

5. Коровкин С. Д., Левенец И. А., Ратманова И. Д., Старых В. А., Щавелёв Л. В. Решение проблемы комплексного оперативного анализа информации хранилищ данных. // СУБД. – 2012. ↑