|
Страница 1 из 3 
Успешная компания сегодня должна принимать множество различных решений. И чем более обоснованные решения будут приняты, тем большего успеха и прибыли достигнет предприятие. Для многих лиц, играющих ключевую роль в принятии решений, способность быстрее и эффективнее конкурента анализировать бизнес-процессы означает принятие более правильных решений, достижение большей прибыльности и большего успеха. Оптимизация реляционной базы данных предоставила компаниям возможность продуктивно собирать данные о транзакциях, поставляя информации лицам, принимающим решения. Тем не менее, имеется верхний предел объема данных, который может содержаться в реляционной базе данных, при котором еще сохраняется возможность достаточно эффективно осуществлять анализ. {mos_fb_discuss:14}
OLAP позволяет выполнять быстрый и эффективный анализ над большими объемами данных. Данные хранятся в многомерном виде, что наиболее близко отражает естественное состояние реальных бизнес-данных. Кроме того, OLAP предоставляет пользователям возможность быстрее и проще получать сводные данные. С его помощью они могут при необходимости углубляться (drill down) в содержимое этих данных для получения более детализированной информации. В данной статье рассмотрены системы хранения данных, архитектуры OLAP и определены типы бизнес-структур, которые существенно выигрывают от применения возможностей OLAP. При этом в статье проанализированы лидеры рынка OLAP и дан обзор соответствующих продуктов и/или линеек продуктов. Эти темы дополнены рассмотрением технологий Data Mining и Хранилищ данных. Компоненты OLAP-систем OLAP-система состоит из множества компонент. На самом высоком уровне представления система включает в себя источник данных, OLAP-сервер и клиента. Источник данных представляет собой источник, из которого берутся данные для анализа. Данные из источника переносятся или копируются на OLAP-сервер, где они систематизируются и подготавливаются для более быстрого впоследствии формирования ответов на запросы. Клиент - это пользовательский интерфейс к OLAP-серверу. В этом разделе статьи описываются функции каждой компоненты и значение всей системы в целом. Источники Источником в OLAP-системах является сервер, поставляющий данные для анализа. В зависимости от области использования OLAP-продукта источником может служить Хранилище данных, наследуемая база данных, содержащая общие данные, набор таблиц, объединяющих финансовые данные или любая комбинация перечисленного. Способность OLAP-продукта работать с данными из различных источников очень важна. Требование единого формата или единой базы, в которых бы хранились все исходные данные, не подходит администраторам баз данных. Кроме того, такой подход уменьшает гибкость и мощность OLAP-продукта. Администраторы и пользователи полагают, что OLAP-продукты, обеспечивающие извлечение данных не только из различных, но и из множества источников, оказываются более гибкими и полезными, чем те, что имеют более жесткие требования. Сервер Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продукта является использование для хранения данных многомерной (ММБД, MDDB) либо реляционной (РДБ, RDB) базы данных. Этот раздел описывает "за" и "против" каждого из этих подходов. MOLAP MOLAP - это Multidimensional On-Line Analytical Processing, то есть Многомерный OLAP. Это означает, что сервер для хранения данных использует ММБД. Поскольку большинство OLAP-продуктов основаны на МДБД, под OLAP часто понимают также и MOLAP. Смысл использования ММБД очевиден. Она может эффективно хранить многомерные по своей природе данные, обеспечивая средства быстрого обслуживания запросов к базе данных. Данные передаются от источника данных (как это описано выше) в многомерную базу данных, а затем база данных подвергается агрегации. Предварительный расчет - это то, что ускоряет OLAP-запросы, поскольку расчет сводных данных уже произведен. Время запроса становится функцией исключительно времени, необходимого для доступа к отдельному фрагменту данных и выполнения расчета. Этот метод поддерживает концепцию, согласно которой работа производится единожды, а результаты затем используются снова и снова. Многомерные базы данных являются относительно новой технологией. Использование ММБД имеет те же недостатки, что и большинство новых технологий. А именно - они не так устойчивы, как РБД, и в той же мере не оптимизированы. Другое слабое место ММБД заключается в невозможности использовать большинство многомерных баз в процессе агрегации данных, поэтому требуется время для того, чтобы новая информация стала доступна для анализа. "Взрыв" базы данных "Взрыв" базы данных представляет собой феномен многомерных баз. Несмотря на то, что эта проблема исследовалась специалистами, тем не менее, трудно объяснить, почему и как это происходит. Представляется, что это связано с разреженностью базы данных и предварительной агрегацией данных. Если многомерная база данных содержит небольшое число элементов данных, сравнимое с количеством обеспечиваемых ею уровней агрегации, каждый фрагмент данных будет вносить больший вклад во все получаемые из него данные. Когда база данных "взрывается", размер ее становится существенно больше, чем он должен быть. Сложно определить условия "взрыва" базы данных или предсказать, "взорвется" ли некая конкретная структура. Одним из подходов, который, похоже, может помочь решить проблему "взрыва", является динамическое управление разреженными данными. Эта методика позволяет анализировать свои собственные модели хранения и оптимизировать их с целью предотвращения "взрыва" базы данных. Таблица 1. Многомерные базы данных | За | Против | | Точно моделируют бизнес-данные | Как правило, не могут грамотно управлять очень большими базами данных | | Обеспечивают быстрый доступ без SQL | Представляют собой новую, и, поэтому, еще не оптимизированную технологию | | Содержат заранее рассчитанные сводные данные | Имеют риск "взрыва" | ROLAP ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов. Существует ряд причин для выбора именно реляционной, а не многомерной базы данных. РБД - это хорошо отработанная технология, имеющая множество возможностей для оптимизации. Использование в реальных условиях дало в результате более проработанный продукт. К тому же, РБД поддерживают более крупные объемы данных, чем ММБД. Они как раз и спроектированы для таких объемов. Основным аргументом против РБД является сложность запросов, необходимых для получения информации из большой базы данных с помощью SQL. Неопытный SQL-программист мог бы с легкостью обременить ценные системные ресурсы попытками выполнить какой-нибудь подобный запрос, который в ММБД выполняется гораздо проще. Таблица 2. Реляционные базы данных | За | Против | | Идеальны для больших объемов данных | Для сложных запросов SQL не является оптимальным | | Отработанная, оптимизированная технология | Определение оптимальной схемы хранения данных представляется более трудным и важным делом | Агрегированные/Предварительно агрегированные данные Быстрая реализация запросов является императивом для OLAP. Это один из базовых принципов OLAP - способность интуитивно манипулировать данными требует быстрого извлечения информации. В целом, чем больше вычислений необходимо произвести, чтобы получить фрагмент информации, тем медленнее происходит отклик. Поэтому, чтобы сохранить маленькое время реализации запросов, фрагменты информации, обращение к которым обычно происходит наиболее часто, но которые при этом требуют вычисления, подвергаются предварительной агрегации. То есть они подсчитываются и затем хранятся в базе данных в качестве новых данных. В качестве примера типа данных, который допустимо рассчитать заранее, можно привести сводные данные - например, показатели продаж по месяцам, кварталам или годам, для которых действительно введенными данными являются ежедневные показатели. Различные поставщики придерживаются различных методов отбора параметров, требующих предварительной агрегации и числа предварительно вычисляемых величин. Подход к агрегации влияет одновременно и на базу данных и на время реализации запросов. Если вычисляется больше величин, вероятность того, что пользователь запросит уже вычисленную величину, возрастает, и поэтому время отклика сократиться, так как не придется запрашивать изначальную величину для вычисления. Однако, если вычислить все возможные величины - это не лучшее решение - в таком случае существенно возрастает размер базы данных, что сделает ее неуправляемой, да и время агрегации будет слишком большим. К тому же, когда в базу данных добавляются числовые значения, или если они изменяются, информация эта должна отражаться на предварительно вычисленных величинах, зависящих от новых данных. Таким образом, и обновление базы может также занять много времени в случае большого числа предварительно вычисляемых величин. Поскольку обычно во время агрегации база данных работает автономно, желательно, чтобы время агрегации было не слишком длительным. Клиент Клиент - это как раз то, что используется для представления и манипуляций с данными в базе данных. Клиент может быть и достаточно несложным - в виде таблицы, включающей в себя такие возможности OLAP, как, например, вращение данных (пивотинг) и углубление в данные (дриллинг), и представлять собой специализированное, но такое же простое средство просмотра отчетов или быть таким же мощным инструментом, как созданное на заказ приложение, спроектированное для сложных манипуляций с данными. Интернет является новой формой клиента. Кроме того, он несет на себе печать новых технологий; множество интернет-решений существенно отличаются по своим возможностям в целом и в качестве OLAP-решения - в частности. В данном разделе обсуждаются различные функциональные свойства каждого типа клиентов. Несмотря на то, что сервер - это как бы "хребет" OLAP-решения, клиент не менее важен. Сервер может обеспечить прочный фундамент для облегчения манипуляций с данными, но если клиент сложен или малофункционален, пользователь не сможет воспользоваться всеми преимуществами мощного сервера. Клиент настолько важен, что множество поставщиков сосредотачивают свои усилия исключительно на разработке клиента. Все, что включается в состав этих приложений, представляет собой стандартный взгляд на интерфейс, заранее определенные функции и структуру, а также быстрые решения для более или менее стандартных ситуаций. Например, популярны финансовые пакеты. Заранее созданные финансовые приложения позволят специалистам использовать привычные финансовые инструменты без необходимости проектировать структуру базы данных или общепринятые формы и отчеты. Инструмент запросов/Генератор отчетов Инструмент запросов или генератор отчетов предлагает простой доступ к OLAP-данным. Они имеют простой в использовании графический интерфейс и позволяют пользователям создавать отчеты перемещением объектов в отчет методом "drag and drop". Тогда как традиционный генератор отчетов предоставляет пользователю возможность быстро выпускать форматированные отчеты, генераторы отчетов, поддерживающие OLAP, формируют актуальные отчеты. Конечный продукт представляет собой отчет, имеющий возможности углубления в данные до уровня подробностей, вращения (пивотинг) отчетов, поддержки иерархий и др.. Add-Ins (дополнения) электронных таблиц. Сегодня во многих направлениях бизнеса с помощью электронных таблиц производятся различные формы анализа корпоративных данных. В каком-то смысле это идеальное средство создания отчетов и просмотра данных. Аналитик может создавать макросы, работающие с данными в выбранном направлении, а шаблон может быть спроектирован таким образом, что, когда происходит ввод данных, формулы рассчитывают правильные величины, исключая необходимость неоднократного ввода простых расчетов. Тем не менее, все это дает в результате "плоский" отчет, что означает, что как только он создан, трудно рассматривать его в различных аспектах. Например, диаграмма отображает информацию за некоторый временной период, - скажем, за месяц. И если некто желает увидеть показатели за день (в противоположность данным за месяц), необходимо будет создать абсолютно новую диаграмму. Предстоит определить новые наборы данных, добавить в диаграмму новые метки и внести множество других простых, но трудоемких изменений. Кроме того, существует ряд областей, в которых могут быть допущены ошибки, что в целом уменьшает надежность. Когда к таблице добавляется OLAP, появляется возможность создавать единственную диаграмму, а затем подвергать ее различным манипуляциям с целью предоставления пользователю необходимой информации, не обременяя себя созданием всех возможных представлений. Интернет в роли клиента Новым членом семейства OLAP-клиентов является Интернет. Существует масса преимуществ в формировании OLAP-отчетов через Интернет. Наиболее существенным представляется отсутствие необходимости в специализированном программном обеспечении для доступа к информации. Это экономит предприятию кучу времени и денег. Каждый Интернет-продукт специфичен. Некоторые упрощают создание Web-страниц, но имеют меньшую гибкость. Другие позволяют создавать представления данных, а затем сохранять их как статические HTML-файлы. Все это дает возможность просматривать данные через Интернет, но не более того. Активно манипулировать данными с их помощью невозможно. Существует и другой тип продуктов - интерактивный и динамический, превращающий такие продукты в полнофункциональные инструменты. Пользователи могут осуществлять углубление в данные, пивотинг, ограничение измерений, и др. Прежде, чем выбрать средство реализации Интернет, важно понять, какие функциональные возможности требуются от Web-решения, а затем определить, какой продукт наилучшим образом воплотит эту функциональность. Приложения Приложения - это тип клиента, использующий базы данных OLAP. Они идентичны инструментам запросов и генераторам отчетов, описанным выше, но, кроме того, они вносят в продукт более широкие функциональные возможности. Приложение, как правило, обладает большей мощностью, чем инструмент запроса. Разработка Обычно поставщики OLAP обеспечивают среду разработки для создания пользователями собственных настроенных приложений. Среда разработки в целом представляет собой графический интерфейс, поддерживающий объектно-ориентированную разработку приложений. К тому же, большинство поставщиков обеспечивают API, который может использоваться для интеграции баз данных OLAP с другими приложениями. Архитектуры OLAP MOLAP Сегмент рынка, принадлежащий многомерным базам данных, связан с компаниями, основным продуктом которых являются машины баз данных. Они не обязательно озабочены тем, какие инструменты будет применять пользователь для того, чтобы манипулировать информацией, содержащейся в базе данных (т.е. клиентом), они просто обеспечивают мощный сервер для того, чтобы пользователь мог самостоятельно построить собственные настроенные приложения или приобрести готовые приложения у другого поставщика. Тем не менее, деятельность ряда производителей охватывает одновременно и клиентскую и серверную области MDDB/Application OLAP. ROLAP Реляционному OLAP отводится наименьший сегмент рынка. Поставщики, работающие в данной области, создают OLAP-продукты, использующие реляционную базу данных для хранения многомерных кубов. Прикладной OLAP Безусловно, это самая большая область, и это, в общем-то, то, с чем обычно связывают и что обычно понимают под термином "OLAP". Прикладной OLAP, как правило, состоит из многомерных баз данных, доступ к которым происходит через конкретное приложение, или, возможно, через множество приложений. Поставщики в данной области рынка в основном предлагают клиенты для базы данных. Клиент может быть как простым средством просмотра, так и более мощным приложением. Настольный OLAP Представителями настольного OLAP являются продукты, необязательно соединяющиеся с сервером. Они могут запускаться в основном на клиентской части, хотя данные в форме куба данных могут загружать и с сервера. Тот факт, что куб данных строится и хранится на машине пользователя, позволяет рекомендовать их тем, кто часто использует портативные компьютеры или кто нечасто запускает настолько сложные отчеты, что для их формирования необходима более высокая скорость клиента, а, следовательно, и более мощный сервер для ее обеспечения.
|