OLAP: оперативная аналитическая обработка данных. Способы аналитической обработки данных для поддержки принятия решений Методы и средства аналитической обработки информации

Анна Иванова

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

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

Хранилища данных

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

Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как "место, где люди могут получить доступ к своим данным" (см., например, Ralph Kimball, The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses , John Wiley & Sons, 1996 и The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse , John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных:

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

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

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

Реляционные хранилища данных

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

Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это повышает скорость выполнения запросов) и может допускать избыточность данных. Типичная структура хранилища данных приведена на рис. 1. Основные составляющие этой структуры - таблица фактов (fact table) и таблицы измерений (dimension tables).

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

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

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

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

В состав современных средств проектирования данных, таких, как CA AllFusion Modelling Suite, обычно входят шаблоны для проектирования хранилищ данных. Следует сказать, что для создания реляционных хранилищ данных иногда применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Пример такого продукта - Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах. Однако создавать хранилища можно и в обычных реляционных СУБД.

OLAP и многомерные хранилища данных

Многомерные хранилища данных составляют основу OLAP-средств (On-Line Analytical Processing), предназначенных для комплексного многомерного анализа данных. Концепция OLAP была описана в 1993 г. Э. Ф. Коддом, автором реляционной модели данных, и в настоящее время поддержка OLAP реализована во многих СУБД и средствах анализа данных.

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

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

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

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

• MOLAP (Multidimensional OLAP) - исходные и агрегатные данные хранятся в многомерной базе данных;
• ROLAP (Relational OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально находились, агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных;
• HOLAP (Hybrid OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные хранятся в многомерной базе данных.

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

Выпущенные в течение последних лет СУБД ведущих производителей - IBM, Microsoft, Oracle, содержат средства для создания многомерных хранилищ данных (эта традиция была начата несколько лет назад корпорацией Microsoft, включившей OLAP-сервер в состав SQL Server 7.0). Существуют и отдельные продукты для создания OLAP-хранилищ - их выпускают компании Hyperion, Sybase, Business Objects и некоторые другие.

Data Mining

Термином Data Mining (mining в переводе с английского означает "добыча полезных ископаемых") обозначают процесс поиска корреляций, тенденций, взаимосвязей и закономерностей между данными посредством различных математических и статистических алгоритмов: кластеризации, создания субвыборок, регрессионного и корреляционного анализа. Примерами искомой информации могут служить сведения о том, какие категории покупателей чаще всего приобретают тот или иной товар, какая часть покупателей одного конкретного товара приобретает другой конкретный товар, какая категория клиентов чаще всего вовремя не выплачивает предоставленный кредит. Подобного рода информация обычно используется при прогнозировании, стратегическом планировании, анализе рисков, и ценность ее для предприятия очень высока.

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

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

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

Обычно выделяют пять стандартных типов закономерностей, выявляемых методами Data Mining:

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

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

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

Методы анализа в конкретной предметной области , базирующиеся на эмпирических моделях. Часто применяются, например, в недорогих средствах финансового анализа.

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

Метод "ближайшего соседа" - выбор близкого аналога исходных данных из уже имеющихся накопленных данных.

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

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

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

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

Средства визуализации OLAP-данных и результатов Data Mining

Универсальные средства визуализации OLAP-данных выпускают многие компании, такие, как Business Objects, Cognos, Panorama, ProClarity. Как правило, эти инструменты рассчитаны на пользователей, обладающих определенными познаниями в области баз данных и статистических методов анализа. Обычно подобные инструменты позволяют обращаться к хранилищам данных и OLAP-источникам различных производителей (например, к многомерным хранилищам на основе СУБД Oracle, Microsoft и IBM), получать срезы многомерных данных и строить на их основе диаграммы. Зачастую производители этих инструментов поставляют также middleware-серверы, предназначенные для выполнения анализа данных и предоставления результатов для отображения в клиентских приложениях, а также средства создания решений на основе клиентских инструментов и middleware-серверов (например, библиотеки классов или элементы управления ActiveX). Учитывая, что ситуация со стандартами в области бизнес-аналитики все еще далека от идеальной (в отличие от реляционных СУБД, для многомерных СУБД пока нет ни общепринятого стандарта языка запросов, аналогичного языку SQL, ни универсальных механизмов доступа к данным, аналогичных ODBC или OLEDB), применение подобных средств может в той или иной степени решить проблему создания аналитических приложений в компаниях, использующих СУБД и OLAP-средства от нескольких различных производителей.

Производители OLAP-средств, в частности, Oracle и IBM, нередко сами выпускают рассчитанные на пользователей клиентские приложения для доступа к OLAP-хранилищам, созданным на основе их же серверных средств. Так, у корпорации Oracle имеется даже несколько таких продуктов, объединенных в пакет Oracle Business Intelligence. Кроме того, в последнее время получили широкое распространение дополнительные модули для электронных таблиц, предназначенные для визуализации OLAP-данных. Так, средства отображения данных аналитических служб Microsoft SQL Server доступны пользователям Microsoft Excel 2000 и более поздних версий, а компании Oracle и Hyperion выпускают встраиваемые в тот же Excel дополнительные модули доступа к собственным OLAP-хранилищам.

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

Средства генерации отчетов

Отчет представляет собой документ, содержимое которого динамически формируется на основе информации, содержащейся в базе данных. На рынке ПО сейчас представлено немало средств создания отчетов: как отдельных продуктов, так и входящих в состав средств разработки приложений или СУБД, и реализованных в виде либо серверных служб, либо клиентских приложений. Как правило, средства создания отчетов поддерживают широкий спектр универсальных механизмов доступа к данным (ODBC, OLE DB, ADO.NET), нередко - средства прямого доступа к наиболее популярным СУБД с помощью их клиентских API, содержат средства деловой графики, интегрируются с офисными приложениями, позволяют публиковать отчеты в Интернете, включают классы или компоненты, предназначенные для создания приложений, реализующих (наряду с другими возможностями) генерацию отчетов.

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

Заключение

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

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

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

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

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

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

Рис. 3.4.

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

Если трехмерный куб можно представить графически, то куб с количеством измерений более трех визуализировать уже невозможно. Поэтому в реальности для анализа используют срезы куба. - это результат выборки данных куба по выбранным пользователем значениям измерений, которые называются метками (members). Например, аналитик хочет сравнить продажи трех групп товаров в Москве и Санкт-Петербурге за январь и февраль. В этом случае он должен расположить значения измерения «Товар» по строкам, значения измерений «Город» и «Время» - по столбцам и выбрать в измерениях интересующие его позиции. Срез куба будет иметь вид, представленный на рис. 3.5.

Рис. 3.5.

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

Рис. 3.6.

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

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

• поворот - транспонирование, в результате которого меняются местами строки и столбцы таблицы;
• проекция - агрегирование значений в ячейках, лежащих на оси проекции, по определенному закону (суммирование, нахождение среднего, определение количества непустых ячеек и др.);
• раскрытие, или детализация (drill-down), - замена одного из значений измерения совокупностью значений из следующего уровня иерархии измерения;
• свертка, или консолидация (roll-up/drill-up), - операция, обратная раскрытию;
• сечение (slice-and-dice) - получение «среза» данных путем задания параметров их выборки из куба.

В общем случае алгоритм работы OLAP включает в себя выполнение следующих действий:

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

Впервые определение OLAP-технологии было дано Е. Коддом в 1993 г . Коддом были описаны возможности многомерного анализа и сформулированы 12 правил OLAP, к которым чуть позже (в 1995 г.) были добавлены еще несколько. Рассмотрим их подробнее.

• 1. Многомерное концептуальное представление данных (Multi- Dimensional Conceptual View). В продукте OLAP используется многомерная модель представления данных, при которой категориальные атрибуты данных рассматриваются как измерения, а количественные - как факты.
• 2. Прозрачность (Transparency). От пользователя должно быть скрыто, как реализована многомерная модель, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
• 3. Доступность (Accessibility). Инструментарий OLAP должен обеспечивать пользователю доступ к данным независимо от их места и способа хранения. При этом должна поддерживаться единая, согласованная и целостная модель данных.
• 4. Устойчивая производительность (Consistent Reporting Performance). Должна быть обеспечена высокая производительность OLAP независимо от количества измерений многомерной модели и размеров базы данных.
• 5. Клиент-серверная архитектура (Client-Server Architecture). Для обеспечения оперативной аналитической обработки распределенных данных OLAP-продукт должен работать на основе клиент-серверной архитектуры. Для обобщения и консолидации данных из различных физически разделенных корпоративных баз данных инструмент должен поддерживать построение общей концептуальной схемы данных.
• 6. Равноправие измерений (Generic Dimensionality). Для всех измерений в многомерном кубе должен быть доступен одинаковый набор функций. При необходимости любому измерению могут быть добавлены дополнительные характеристики. Базовая структура данных, формулы расчета и форматы отчетов не должны быть привязаны к какому-то одному измерению.
• 7. Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling). Поскольку кросс-таблицы, формируемые инструментом OLAP, часто бывают разреженными, должна обеспечиваться их оптимальная обработка. Инструмент должен обеспечивать высокую скорость обработки вне зависимости от расположения ячеек данных, от количества измерений в кубе и разреженности данных.
• 8. Поддержка многопользовательского режима (Multi-User Support). Инструмент OLAP должен позволять работать с одними и теми же данными одновременно нескольким пользователям и обеспечивать при этом целостность и защиту данных.
• 9. Неограниченная поддержка кроссмерных операций (Unrestricted Crossdimensional Operations). При выполнении манипуляций данными (операций среза, поворота, консолидации, детализации) должно обеспечиваться сохранение функциональных отношений между ячейками многомерного куба, описанных с помощью формул. Преобразования установленных отношений должны выполняться системой самостоятельно, без необходимости их переопределения пользователем.
• 10. Интуитивное манипулирование данными (Intuitive Data Manipulation). Пользовательский интерфейс для выполнения манипуляций данными должен быть максимально удобным, естественным и комфортным.

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

12. Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels). OLAP-инструмент должен поддерживать аналитическую модель данных, в которой может содержаться до 20 измерений. При этом инструмент должен позволять пользователю определять для каждого измерения неограниченное количество уровней агрегации по любому направлению консолидации.

Для определения OLAP как аналитического инструмента в качестве универсального критерия используется тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации). Рассмотрим детально каждую из составляющих этой аббревиатуры.

Fast (быстрый). Запросы пользователей должны обрабатываться OLAP- системой с высокой скоростью, при этом среднее время обработки запроса не должно превышать 5 с, большинство запросов должно обрабатываться в пределах 1 с, самые сложные запросы, требующие больших вычислений, должны обрабатываться не более 20 с.

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

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

Multidimensional (многомерный). OLAP-приложение должно обеспечивать многомерное представление данных с поддержкой иерархических измерений.

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

В зависимости от ответа на вопрос, существует ли многомерный куб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В MOLAP реализуется многомерное представление данных на физическом уровне в виде многомерных кубов. Системы ROLAP используют классическую реляционную модель, характерную для OLTP-систем. При этом данные хранятся в реляционных таблицах, но специальные структуры эмулируют их многомерное представление. Также выделяют гибридные OLAP (HOLAP - Hybrid OLAP), в которых детализированные данные хранятся в реляционных таблицах, а агрегированные данные - в многомерных кубах. Такая комбинация реляционной и многомерной моделей позволяет сочетать высокую производительность, характерную для многомерной модели, и возможность хранить сколь угодно большие массивы данных, присущую реляционной модели.

• Codd Е. Providing OLAP to User-Analysts: An IT Mandate // Computerworld. 1993. T. 27.№30.

3.4 Способы аналитической обработки данных

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

Очень часто информационно-аналитические системы, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются Информационными системами руководителя (ИСР), или Executive Information Systems (EIS). Они содержат в себе множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы которые могут возникнуть при принятии решений. Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения, которых у аналитика появляется новая серия вопросов. Однако каждый новый запрос, непредусмотренный при проектировании такой системы, должен быть сначала формально описан, закодирован программистом и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо.

Оперативная аналитическая обработка . Или On-Line Analytical Processing, OLAP – это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 г. Эдгаром Коддом и имеет следующие требования к приложениям для многомерного анализа:

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

– предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;

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

– многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;

– возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

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

Рассмотрим составные части OLAP-системы.

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

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

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

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

Сервер. Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продуктов является использование МБД либо РБД для хранения данных.

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

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

Клиентские OLAP-средства (например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys) представляют собой приложения, осуществляющие вычисление агрегатных данных и их отображение. При этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства.

Если исходные данные содержатся в настольной СУБД, вычисление агрегатных данных производится самим OLAP-средством. Если же источник исходных данных – серверная СУБД, многие из клиентских OLAP-средств посылают на сервер SQL-запросы и в результате получают агрегатные данные, вычисленные на сервере.

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

Многие средства разработки содержат библиотеки классов или компонентов, позволяющие создавать приложения, реализующие простейшую OLAP-функциональность (такие, например, как компоненты Decision Cube в Borland Delphi и Borland C++ Builder). Помимо этого многие компании предлагают элементы управления ActiveX и другие библиотеки, реализующие подобную функциональность.

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

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

Идея сохранения кэша с агрегатными данными в файле получила свое дальнейшее развитие в серверных OLAP-средствах (например, Oracle Express Server или Microsoft OLAP Services), в которых сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером. Клиентские приложения могут запрашивать подобное многомерное хранилище и в ответ получать те или иные данные. Некоторые клиентские приложения могут также создавать такие хранилища или обновлять их в соответствии с изменившимися исходными данными.

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

3.5 Технические аспекты многомерного хранения данных

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

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

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

Многомерное хранение – средства физической организации данных, обеспечивающие эффективное выполнение многомерных запросов.

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

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

Тем не менее, использование агрегированных данных чревато недостатками. Основными недостатками являются увеличение объема хранимой информации (при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально) и времени на их загрузку. Причем объем информации может увеличиваться в десятки и даже в сотни раз. Например, в одном из опубликованных стандартных тестов полный подсчет агрегатов для 10 Мб исходных данных потребовал 2,4 Гб, т. е. данные выросли в 240 раз!

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

Как исходные, так и агрегатные данные могут храниться либо в

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

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

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

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

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

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

3.6 Интеллектуальный анализ данных (Data Mining )

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

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

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

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

В общем случае процесс интеллектуального анализа данных (Data Mining) состоит из трёх стадий

выявление закономерностей (свободный поиск);

использование выявленных закономерностей для предсказания неизвестных значений (прогностическое моделирование);

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

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

Выделяют пять стандартных типов закономерностей, выявляемых методами Data Mining:

1.Ассоциация позволяет выделить устойчивые группы объектов, между которыми существуют неявно заданные связи. Частота появления отдельного предмета или группы предметов, выраженная в процентах, называется распространенностью. Низкий уровень распространенности (менее одной тысячной процента) говорит о том, что такая ассоциация не существенна. Ассоциации записываются в виде правил: A => B , где А - посылка, В - следствие. Для определения важности каждого полученного ассоциативного правила необходимо вычислить величину, которую называют доверительность А к В (или взаимосвязь А и В). Доверительность показывает, как часто при появлении А появляется В. Например, если д(A/B) =20%, то это значит, что при покупке товара А в каждом пятом случае приобретается и товар В.

Типичным примером применения ассоциации является анализ структуры покупок. Например, при проведении исследования в супермаркете можно установить, что 65 % купивших картофельные чипсы берут также и «кока-колу», а при наличии скидки за такой комплект «колу» приобретают в 85 % случаев. Подобные результаты представляют ценность при формировании маркетинговых стратегий.

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

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

4.Кластеризация – это распределение информации (записей) из БД по группам (кластерам) или сегментам с одновременным определением этих групп. В отличие от классификации здесь для проведения анализа не требуется предварительного задания классов.

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

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

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

регрессионный, дисперсионный и корреляционный анализ (реализован в большинстве современных статистических пакетов, в частности, в продуктах компаний SAS Institute, StatSoft и др.);

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

нейросетевые алгоритмы – метод имитации процессов и явлений, позволяющий воспроизводить сложные зависимости. Метод основан на использовании упрощенной модели биологического мозга и заключается в том, что исходные параметры рассматриваются как сигналы, преобразующиеся в соответствии с имеющимися связями между «нейронами», а в качестве ответа, являющегося результатом анализа, рассматривается отклик всей сети на исходные данные. Связи в этом случае создаются с помощью так называемого обучения сети посредством выборки большого объема, содержащей как исходные данные, так и правильные ответы. Нейронные сети широко применяются для решения задач классификации;

нечеткая логика применяется для обработки данных с размытыми значениями истинности, которые могут быть представлены разнообразными лингвистическими переменными. Нечеткое представление знаний широко применяется для решения задач классификации и прогнозирования, например, в системе XpertRule Miner (Attar Software Ltd., Великобритания), а также в AIS, NeuFuz и др;

индуктивные выводы позволяют получить обобщения фактов, хранящихся в БД. В процессе индуктивного обучения может участвовать специалист, поставляющий гипотезы. Такой способ называют обучением с учителем. Поиск правил обобщения может осуществляться без учителя путем автоматической генерации гипотез. В современных программных средствах, как правило, сочетаются оба способа, а для проверки гипотез используются статистические методы. Примером системы с применением индуктивных выводов является XpertRule Miner, разработанная фирмой Attar Software Ltd. (Великобритания);

рассуждения на основе аналогичных случаев (метод «ближайшего соседа») (Case-based reasoning – CBR) основаны на поиске в БД ситуаций, описания которых сходны по ряду признаков с заданной ситуацией. Принцип аналогии позволяет предполагать, что результаты похожих ситуаций также будут близки между собой. Недостаток этого подхода заключается в том, что здесь не создается каких-либо моделей или правил, обобщающих предыдущий опыт. Кроме того, надежность выводимых результатов зависит от полноты описания ситуаций, как и в процессах индуктивного вывода. Примерами систем, использующих CBR, являются: KATE Tools (Acknosoft, Франция), Pattern Recognition Workbench (Unica, США);

деревья решений – метод структурирования задачи в виде древовидного графа, вершины которого соответствуют продукционным правилам, позволяющим классифицировать данные или осуществлять анализ последствий решений. Этот метод дает наглядное представление о системе классифицирующих правил, если их не очень много. Простые задачи решаются с помощью этого метода гораздо быстрее, чем с использованием нейронных сетей. Для сложных проблем и для некоторых типов данных деревья решений могут оказаться неприемлемыми. Кроме того, для этого метода характерна проблема значимости. Одним из последствий иерархической кластеризации данных является отсутствие большого числа обучающих примеров для многих частных случаев, в связи с чем классификацию нельзя считать надежной. Методы деревьев решений реализованы во многих программных средствах, а именно: С5.0 (RuleQuest, Австралия), Clementine (Integral Solutions, Великобритания), SIPINA (University of Lyon, Франция), IDIS (Information Discovery, США);

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

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

3.7 Интеграция OLAP и Data Mining

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

В настоящее время появляется составной термин «OLAP Data Mining» (многомерный интеллектуальный анализ) для обозначения такого объединения.

Существует три основных способа формирования «OLAP Data Mining»:

«Cubing then mining». Возможность выполнения интеллектуального анализа должна обеспечиваться над любым результатом запроса к многомерному концептуальному представлению, то есть над любым фрагментом любой проекции гиперкуба показателей.

«Mining then cubing». Подобно данным, извлечённым из хранилища, результаты интеллектуального анализа должны представляться в гиперкубической форме для последующего многомерного анализа.

«Cubing while mining». Этот гибкий способ интеграции позволяет автоматически активизировать однотипные механизмы интеллектуальной обработки над результатом каждого шага многомерного анализа (перехода) между уровнями обобщения, извлечения нового фрагмента гиперкуба и т. д.).

11 класса [Текст... им как часть всей системы ... доцент ... Чебоксары , 2009. № 10. С. 44 -49 ... . Авторы-составители : Н. ... конспекты лекций , ...

• Учебно-методическое пособие

  ... лекций . Подготовка лекции по математике. Написание конспекта лекции лекции . Использование информационных технологий ...

• И к кондаурова с в лебедева научно-исследовательская деятельность будущего учителя математики творческие задания по элементарной математике и методике её преподавания

  Учебно-методическое пособие

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

• М ОНИТОРИНГ СМИ Модернизация профессионального образования Март - август 2011г

  Краткое содержание

  ... 11 .08.2011 "Мертвые души-2" В РНИМУ им ... 3,11 -3,44 . ... публичные лекции руководителей... Чебоксарах ... и строчащая конспекты аудитория - ... информационные системы и технологии . ... системой образования, - говорит доцент ... составителей ... части повышения реального содержания ...

Аналитические технологии бизнес- процессов

Системы бизнес интеллекта - Business Intelligence (BI) объединяют в себе различные средства и технологии анализа и обработки данных масштаба предприятия. На основе этих средств создаются BI-системы, цель которых - повысить качество информации для принятия управленческих решений.

К BI относятся программные продукты следующих классов:

· системы оперативной аналитической обработки (OLAP);

· средства интеллектуального анализа данных (DM);

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

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

В 1993 году основоположник реляционного подхода к построению баз данных Эдгар Кодд с партнерами (Edgar Codd, математик и стипендиат IBM), опубликовали статью, инициированную компанией и озаглавленную "Обеспечение OLAP (оперативной аналитической обработки) для пользователей-аналитиков", в которой были сформулированы 12 критериев технологии OLAP, впоследствии ставшие основным содержанием новой и очень перспективной технологии.

Позднее они были переработаны в тест FASMI, который определяет требования к продуктам OLAP:

· FAST (быстрый). Приложение OLAP должно обеспечивать минимальное время доступа к аналитическим данным - в среднем порядка 5 секунд;

· ANALYSIS (анализ). Приложение OLAP должно давать пользователю возможность осуществлять числовой и статистический анализ;

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

· MULTIDIMENSIONAL (многомерность);

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

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

Основная идея OLAP заключается в построении многомерных кубов, которые будут доступны для пользовательских запросов. Многомерные кубы (рис.5.3) строятся на основе исходных и агрегированных данных, которые могут храниться как в реляционных, так и в многомерных базах данных. Поэтому в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) и HOLAP (Hybrid OLAP).

Соответственно, OLAP-продукты по способу хранения данных делятся на три аналогичные категории:

1. В случае MOLAP, исходные и многомерные данные хранятся в многомерной БД или в многомерном локальном кубе. Такой способ хранения обеспечивает высокую скорость выполнения OLAP-операций. Но многомерная база в этом случае чаще всего будет избыточной. Куб, построенный на ее основе, будет сильно зависеть от числа измерений. При увеличении количества измерений объем куба будет экспоненциально расти. Иногда это может привести к "взрывному росту" объема данных.

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

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

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

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

В основе оперативной аналитической обработки данных лежит принцип организации информации в гиперкубическую модель. Простейший трехмерный куб данных по поставкам деталей для ранее рассмотренной тестовой базы данных приведен на рис. 3.11. Каждая его ячейка соответствует «факту» – например, объему поставки детали. Вдоль одной грани куба (одного измерения) располагаются месяцы, в течение которых выполнялись отражаемые кубом поставки. Второе измерение составляют виды деталей, а третье – соответствует поставщикам. В каждой ячейке содержится объем поставки для соответствующей комбинации значений по всем трем измерениям. Следует отметить, что при заполнении куба выполнена агрегация значений по поставкам каждого месяца из тестовой базы данных.

3.11. Вариант упрощенного гиперкуба для анализа поставок деталей

Системы класса OLAP различаются по способу представления данных.

Многомерный OLAP (MOLAP ) – в основу этих систем положена многомерная, основанная на динамических массивах структура данных с соответствующими методами доступа. MOLAP реализуется на патентованных технологиях организации многомерных СУБД. Преимуществом этого подхода является удобство выполнения вычислений над ячейками гиперкуба, т.к. под все сочетания измерений заведены соответствующие ячейки (как в электронной таблице). К классическим представителям таких систем можно отнести Oracle Express, SAS Institute MDDB.

Реляционный OLAP (ROLAP) – поддерживает многомерные аналитические модели над реляционными БД. К данному классу систем можно отнести Meta Cube Informix, Microsoft OLAP Services,Hyperion Solutions, SAS Institute Relational OLAP.

Настольный OLAP (Desktop OLAP) – средства генерации многомерных запросов и отчетов для локальных информационных систем (электронные таблицы, плоские файлы). Можно выделить следующие системы – Business Objects, Cognos Power Play.

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

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

Рис. 3.12. Схема типа «звезда» аналитической витрины по поставкам деталей

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

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

SELECT SUM(VALUE), SUPPLIER.SUPPLIER_NAME, FACT.MONTH_ID

FROM FACT, SUPPLIER

WHERE FACT.YEAR_ID=2004

AND FACT.SUPPLIER_CODE=SUPPLIER.SUPPLIER_CODE

GROUP_BY SUPPLIER_CODE, MONTH_ID

ORDER_BY SUPPLIER_CODE, MONTH_ID.

На рис. 3.13 приведен фрагмент отчета, сформированного в результате заданного запроса.

Термин оперативная аналитическая обработка (On-Line Analytical Processing- OLAP) впервые был упомянут в докладе, подготовленном для корпорации Arbor Software Corp. в 1993 году, хотя определение этого термина, как и в случае с хранилищами данных, было сформулировано намного позже. Понятие, обозначенное этим термином, может быть определено как "интерактивный процесс создания, сопровождения, анализа данных и выдачи отчетов". Кроме того, обычно добавляют, что рассматриваемые данные должны восприниматься и обрабатываться таким образом, как если бы они хранились в многомерном массиве. Но прежде чем приступить к обсуждению собственно многомерного представления, рассмотрим соответствующие идеи в терминах традиционных таблиц SQL.

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

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

9 Приведем совет из книги по хранилищам данных: "[Откажитесь] от нормализации… По пытки нормализовать любую из таблиц в многомерной базе данных исключительно ради экономии дис кового пространства [именно так!] - напрасная трата времени… Таблицы размерности не должны быть нормализованы… Нормализованные таблицы размерности исключают возможность просмотра".

10 Если только эта таблица результатов не включает какие-либо неопределенные значения, или NULL-значения (см. главу 19, раздел 19.3, подраздел "Дополнительные сведения о предикатах"). На самом деле конструкции SQL: 1999, которые должны быть описаны в данном разделе, можно охаракте ризовать как "основанные на использовании" этого весьма не рекомендуемого средства SQL (?); в дей ствительности, они подчеркивают тот факт, что в своих различных проявлениях неопределенные значе ния могут иметь разный смысл, и поэтому позволяют представить в одной таблице много разных преди катов (как будет показано ниже).

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

1. Определить общее количество поставок.

2. Определить общее количество поставок по поставщикам.

3. Определить общее количество поставок по деталям.

4. Определить общее количество поставок по поставщикам и деталям.

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

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

Многомерные базы данных

До сих пор предполагалось, что данные OLAP хранятся в обычной базе данных, использующей язык SQL (не считая того, что иногда мы все же касались терминологии и концепции многомерных баз данных). Фактически мы, не указывая явно, описывали так называемую систему ROLAP (Relational OLAP- реляционная OLAP). Однако многие считают, что использование системы MOLAP (Multi-dimensional OLAP - многомерная OLAP) - более перспективный путь. В этом подразделе принципы построения систем MOLAP будут рассмотрены подробнее.

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

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

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

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

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

Примечание. Различие между значениями независимых, или размерных, переменных,

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

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

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

Между прочим, из предыдущего описания должно быть ясно, что ячейки массива часто оказываются пустыми (и чем больше размерностей, тем чаще наблюдается такое явление). Иными словами, массивы обычно бывают разреженными. Предположим, например, что товар р не продавался заказчику с в течение всего периода времени t. Тогда ячейка [с,р, t] будет пустой (или в лучшем случае содержать нуль). Многомерные СУБД поддерживают различные методы хранения разреженных массивов в более эффективном, сжатом представлении12. К этому следует добавить, что пустые ячейки соответствуют отсутствующей информации и, следовательно, системам необходимо предоставлять некоторую вычислительную поддержку для пустых ячеек. Такая поддержка действительно обычно имеется, но стиль ее, к сожалению, похож на стиль, принятый в языке SQL. Обратите внимание на тот факт, что если данная ячейка пуста, то информация или не известна, или не была введена, или не применима, или отсутствует в силу других причин

(см. главу 19).

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

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

композиции, связывающая детали с комплектом деталей, комплекты деталей с узлом, узлы с модулем, модули с изделием. Часто одни и те же данные могут агрегироваться многими разными способами, т.е. одна и та же независимая переменная может принадлежать ко многим различным иерархиям. Система предоставляет операторы для прохождения вверх (drill up) и прохождения вниз (drill down) по такой иерархии. Прохождение вверх означает переход от нижнего уровня агрегирования к верхнему, а прохождение вниз -

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

Примечание. Между операциями прохождения вверх (drill up) и накопления итогов (roll

up) есть одно тонкое различие: операция накопления итогов - это операция реализации

12 Обратите внимание на отличие от реляционных систем. В настоящем реляционном аналоге этого примера в строке Ic, p, t) не было бы пустой "ячейки" количества, в связи с тем, что строка (с,р, t) просто бы отсутствовала. Поэтому при использовании реляционной модели, в отличие от многомерных массивов, нет необходимости поддерживать "разреженные массивы", или скорее "разреженные таблицы", а значит, не требуются искусные методы сжатия для работы с такими таблицами.

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

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

Завершая этот раздел, отметим, что в некоторых продуктах сочетаются оба подхода - ROLAP и MOLAP. Такую гибридную систему OLAP называют HOLAP. Проводятся широкие дискуссии с целью выяснить, какой из этих трех подходов лучше, поэтому стоит и нам попытаться сказать по данному вопросу несколько слов13. В общем случае системы MOLAP обеспечивают более быстрое проведение расчетов, но поддерживают меньшие объемы данных по сравнению с системами ROLAP, т.е. становятся менее эффективными по мере возрастания объемов данных. А системы ROLAP предоставляют более развитые возможности масштабируемости, параллельности и управления по сравнению с аналогичными возможностями систем MOLAP. Кроме того, недавно был дополнен стандарт SQL и в него включены многие статистические и аналитические функции (см. раздел 22.8). Из этого следует, что в настоящее время продукты ROLAP способны к тому же предоставлять расширенные функциональные возможности.

OLAP (Online Analytical Processing – оперативная аналитическая обработка) – это информационный процесс, который дает возможность пользователю запрашивать систему, проводить анализ и т.д. в оперативном режиме (онлайн). Результаты генерируются в течении секунд.

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

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

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

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

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

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

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

4. Устойчивая производительность.

5. Клиент – серверная архитектура.

6. Равноправие измерений.

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

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

9. Неограниченная поддержка кроссмерных операций.

10. Интуитивное манипулирование данными.

11. Гибкий механизм генерации отчетов.

12. Неограниченное количество измерений и уровней агрегации.

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

Интеллектуальный анализ данных (Data Mining) и знаний (Knowledge Мining). Управление и анализ больших объемов данных (Big data). Системы бизнес-аналитики (Business Intelligence, BI).

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

В общем случае процесс ИАД состоит из трех стадий:

1) выявление закономерностей (свободный поиск);

2) использование выявленных закономерностей для предсказания неизвестных значений (прогнозирование);

3) анализ исключений для выявления и толкования аномалий в найденных закономерностях.

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

Все методы ИАД по принципу работы с исходными данными подразделяются на две группы:

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

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

Data Mining (DM)– это технология обнаружения в «сырых» данных ранее неизвестных нетривиальных, практически полезных и доступных интерпретации знаний, необходимых для принятия решений в различных сферах человеческой деятельности. Алгоритмы, используемые в Data Mining, требуют большого количества вычислений, что ранее являлось сдерживающим фактором широкого практического применения этих методов, однако рост производительности современных процессоров снял остроту этой проблемы.

Рынок Business Intelligence состоит из 5 секторов:

1. OLAP-продукты;

2. Инструменты добычи данных;

3. Средства построения Хранилищ и Витрин данных (Data Warehousing);

4. Управленческие информационные системы и приложения;

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

В настоящее время среди лидеров корпоративных BI-платформ можно выделить MicroStrategy, Business Objects, Cognos, Hyperion Solutions, Microsoft, Oracle, SAP, SAS Institute и другие (в приложении Б приведен сравнительный анализ некоторых функциональных возможностей BI-систем).

Аналитическая обработка информации является непосредственно аналитической процедурой, в связи с чем выдвигаются серьезные требования к ее организации, а именно, соответствующее методическое обеспечение, определенный уровень подготовки аналитиков, их обеспеченность техническими средствами проведения анализа.
Качество и обоснованность принимаемых управленческих решений в значительной степени определяются не только достоверно-стью, полнотой, доступностью, оперативностью получения информации, но также и эффективностью используемых при ее обработке методов. Совершенствование технологии аналитической обработки экономической информации - один из ключевых элементов совершенствования технологии управления.
Качественное информационное обеспечение процесса управления хозяйственной деятельностью возможно только при использовании на практике новейших информационных технологий: средств вычислительной техники, телекоммуникаций и программного обеспечения, а также автоматизированных систем управления.
Условия хозяйственной деятельности, предполагающие широкие права предприятий по формированию учетной политики, воз-можности ее изменения, смене форм собственности; процессы ре- структуризации, объединение компаний и т. п., диктуют необходи-мость обработки большого объема аналитической информации. Усложнились и сами расчеты, применяемые при отражении тех или иных финансово-хозяйственных операций. Широкие права предприятий по выбору способов начисления амортизации по объектам основных средств делают практически невыполнимой задачу расчета сумм амортизационных отчислений при условии ручной обработки информации.
Возрастают требования к степени оперативности, достоверности информации, необходимой для принятия управленческих решений. Именно организация экономического анализа в компьютерной среде позволила значительно повысить оперативность сбора и регистрации учетной информации, существенно снизить вероятность арифметических ошибок и, как следствие, уменьшить трудоемкость работы аналитических служб на предприятиях.
Сложность информационных потоков, несовершенство каналов получения информации, методов и техники сбора, хранения и обработки информации нередко приводят к ее существенному запаздыванию, а следовательно, и к потере ее"качества. Основой своевременного получения информации служит интеграция ее сбора и обработки, что обеспечивает взаимодействие хозяйственной деятельности и экономического анализа, приводит к постепенному слиянию автоматизации расчетов с информационной системой предприятия.
Автоматизированная система сбора, обработки и хранения, представляющая собой разветвленную сеть регистрирующих устройств, линий связи и ЭВМ, сокращает время между возникновением информации и ее использованием в аналитической работе. Технические средства обеспечивают своевременное доведение информации о процессах, происходящих на предприятии, до руководителей и других работников управления. Применение современных информационных технологий дает возможность выполнить быстрый поиск и трудоемкие расчеты, а также отображать результаты в приемлемой форме.
Ведущее место в процедурах преобразования экономической информации занимает ее систематизация и обработка. При использовании вычислительной техники обработка информации стала органичной частью единого информационного технологического процесса. Современные компьютеры не только изменили связи этого процесса с другими, создав возможности технологического единства информационных процессов, но и оказали влияние на содержание понятия «обработка данных». Если при ручном или механизи- рованном выполнении аналитических работ под обработкой понимались преимущественно арифметические действия, то сегодня для обработки применяются сложнейшие логические и статистические операции.
Большая часть экономической информации, полученной в результате обработки, направляется руководителям, специалистам, менеджерам в конкретные сроки, предусмотренные календарным графиком сбора и обработки данных. При формировании регламентированной экономической информации установление сроков ее подготовки не представляет особой сложности, так как они обычно обусловлены условиями производства. Трудность представляет проектирование сбора и обработки нерегламентированной информации для принятия управленческих решений в произвольные моменты времени. Для получения такой информации система должна формировать данные, характеризующие результаты работ, ход выполнения планов, динамику экономического и социального развития, с задаваемым периодом.
Такая система требует иного подхода к проектированию тех- , нологического процесса сбора и обработки данных, предусматривающего различные режимы получения информации. Наиболее перспективен интерактивный режим, обеспечивающий непосредственное взаимодействие пользователей с ЭВМ. Для принятия оперативных управленческих решений менеджеры на основе опреде- т ленных диалоговых процедур выбирают необходимую информацию, отражающую обеспеченность и использование материальных, трудовых и финансовых ресурсов, ход производственных и других хозяйственных процессов.
В обработанном, взаимосвязанном и скоординированном виде информация передается отделам и службам экономического управления, ответственным за анализ хозяйственной деятельности и принятие решений. Для управления экономикой им необходима особая информация прогнозного характера, позволяющая не только фиксировать положение дел на предприятии, но и анализировать тенденции развития того или"иного процесса, явления и принимать на основе этого оптимальные и своевременные решения. Такой тип управления предполагает наличие не только данных об управляемом объекте и его окружении, но и проанализированной информации, пригодной для прогнозирования. Информация о прошлом поведении системы и окружающей ее среды применяется для выработки управленческих решений на основе предвидимого решения с помо-щью средств экономического моделирования, экспертных и прогнозных программных систем.

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

Более поздним достижением в этой области явилось добавление архитектуры клиент – сервер. Было издано много инструментов для развития OLTP приложений.

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

OLAP (Online Analytical Processing – оперативная аналитическая обработка) – это информационный процесс, который дает возможность пользователю запрашивать систему, проводить анализ и т.д. в оперативном режиме (онлайн). Результаты генерируются в течении секунд.

С другой стороны, в OLTP системе огромные объемы данных обрабатываются так скоро, как они поступают на вход.

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

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

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

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

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

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

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

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

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

4. Устойчивая производительность.

5. Клиент – серверная архитектура.

6. Равноправие измерений.

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

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

9. Неограниченная поддержка кроссмерных операций.

10. Интуитивное манипулирование данными.

11. Гибкий механизм генерации отчетов.

12. Неограниченное количество измерений и уровней агрегации.

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

Интеллектуальный анализ данных.

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

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

Многие важные решения в почти любой области бизнеса и социально сферы основываются на анализе больших и сложных БД. ИАД может быть очень полезным в этих случаях.

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

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

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

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

Но динамические ИС поддержки решений могут действовать не только в области оперативной аналитической обработки (OLAP). Поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах.

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

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

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

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