Технологии аналитической обработки информации. Обзор и анализ программных технологий разработки WEB-приложений для аналитической обработки данных

Тема 6

КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ ОБРАБОТКИ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ

Понятие корпоративной информационной технологии

Сущность и значение корпоративных информационных технологий

Среди многообразия программ для бизнеса под термином "информационные технологии в корпоративном управлении" традиционно понимают "комплексные системы автоматизации управления". Известны и другие их названия – системы масштаба предприятия, корпоративные информационные системы (КИС), корпоративные (или комплексные) системы управления (КСУ), автоматизированные системы управления (АСУ).

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

Например, решение системы SAP R/3 для авиационной промышленности поддерживает учет и контроль серийных заводских номеров всех деталей самолета, сроков их эксплуатации, плановой замены или ремонта, что обеспечивает не только надежность производства, но и безопасность пассажиров.

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

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

Концепция построения

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

Не случайно такое различное по функциональному наполнению, системным решениям, назначению и использованию "управленческое" программное обеспечение, как "Галактика", "БЭСТ" и "1С: Предприятие", аналогично по принципам организации информации, технологии ее формирования и обработки, а также по методам взаимодействия с системами.

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

Аналитическая обработка информации

Планирование деятельности предприятия, получение оперативной информации и принятие на основе ее анализа правильного решения связано с обработкой больших объемов данных. Отчеты, формируемые в учетных корпоративных системах управления, обычно лишены гибкости. Их нельзя “покрутить”, “развернуть” или “свернуть”, чтобы получить желаемое представление данных, в том числе и графическое. Чем больше “срезов” и “разрезов ” можно сделать, тем реальнее можно представить картину деятельности предприятия и принять оптимальное решение по управлению бизнес-процессами. Для такого рода задач необходимо математическое и экономическое моделирование, а также высокое быстродействие. Аналитический модуль имеется в системе “РепКо”, более известна система “Триумф-Аналитика” (Корпорация “ПАРУС” – “Тора центр”). Казалось бы, учетные системы строят справки в различных “разрезах” по информации, хранящейся в базе данных, просто представляют то, что есть. А аналитические системы строят новую информацию по заданным параметрам или критериям, оптимизируя ее для конкретных целей. Поэтому чаще необходим специальный инструмент для просмотра и визуализации информации, которым является “оперативный анализ данных” (OLAP - online analytical processing). Он предоставляет собой совокупность удобных и быстродействующих средств доступа, просмотра и многомерного анализа информации, накопленной в хранилище.

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

Обычно из корпоративных систем управления информация передается в специализированные программы аналитической обработки данных. Многие отечественные разработчики пытаются решать эти задачи самостоятельно, например, компании “Никос-Софт” (система NS-2000), “Цефей” (корпоративная система управления “Эталон”), "КОМСОФТ" (программно-методологический и инструментальный комплекс "КОМСОФТ-СТАНДАРТ" 2.0) и др.

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

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

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

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

Интеграция требуется и продуктам различных производителей – во имя объединения комплексных решений со специализированными:

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

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

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

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

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

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

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

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

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

В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:

1) Хранилища данных, или Склады данных (Data Warehouse)


2) Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP)

3) Интеллектуальный анализ данных - ИАД (Data Mining)

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

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

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

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

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

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

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

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

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

2) кэширование данных и преобразование их к многомерному кубу;

3) отображение построенного куба при помощи кросс-таблицы или диаграммы и т.п.

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

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

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

схема созвездия

УДК 621. 37/39. 061. 2/4

МЕТОДЫ АНАЛИТИЧЕСКОЙ ОБРАБОТКИ ИНФОРМАЦИИ

ГВОЗДИНСКИЙА.Н., КЛИМКО Е.Г., СОРОКОВОЙ А.И.

Проводится аналитический обзор методов интеллектуального анализа данных (также называют: ИАД, data mining, обнаружение знаний в базах данных) с учетом использования определенного метода для условий Украины. Обзор методов аналитической обработки информации в сложных информационных системах рассматривается с точки зрения скорости извлечения данных, сбора обобщенной информации и повышения достоверности процесса.

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

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

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

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

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

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

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

Сбор данных: оценка их, объединение и очистка, отбор и преобразование;

Построение модели: оценка и интерпретация, внешняя проверка;

Использование модели;

Наблюдение за моделью.

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

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

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

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

Рис.1. Нейронная сеть

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

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

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

Недостаток-необходимость иметь большой объем обучающей выборки. Окончательное решение зависит от начальных установок сети. Данные должны быть обязательно преобразованы к числовому виду. Полученная модель не объясняет обнаруженные знания (так называемый “черный ящик”).

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

РИ, 2000, № 4

указывается, к какому классу надо отнести рассматриваемый объект.

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

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

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

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

Можно выделить следующие механизмы:

Отбор сильнейших наборов хромосом, которым соответствуют наиболее оптимальные решения;

Скрещивание - получение новых индивидов при помощи смешивания хромосомных наборов отобранных индивидов;

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

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

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

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

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

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

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

Литература: 1. Щавелев Л.В. Интеллектуальный анализ данных. http://www.citforum.ru/seminars/cis99/ sch_04.shtml, 2. Буров К. Обнаружение знаний в хранилищах данных / / Открытые системы. 1999. №5-6., http: / /www.osp.ru/os/l999/05-06/14.htm. 3. КиселевМ, Соломатин Е. Средства добычи знаний в бизнесе и финансах // Открытые системы. 1997. №4. С. 41-44. 4. Кречетов Н, Иванов П. Продукты для интеллектуального анализа данных // Computer Week - Москва. 1997. №14-15. С. 32-39. 5. Edelstein H. Интеллектуальные средства анализа и представления данных в информационных хранилищах // Computer Week - Москва. 1996. №16. С. 32-35.

Поступила в редколлегию 22.06.2000

Рецензент: д-р техн. наук, проф. Путятин В.П.

Гвоздинский Анатолий Николаевич, канд. техн. наук, профессор кафедры искусственного интеллекта ХТУРЭ. Научные интересы: оценка эффективности сложных информационных систем управления. Увлечения и хобби: классическая музыка, туризм. Адрес: Украина, 61166, Харьков, ул. акад. Ляпунова, 7, кв. 9, тел. 32-69-08.

Климко Елена Генриховна, ассистент кафедры компьютерных технологий и информационных систем Полтавского государственного технического университета имени Юрия Кондратюка. Аспирантка (без отрыва от производства) кафедры искусственного интеллекта ХТУРЭ. Научные интересы: аналитический анализ данных. Увлечения и хобби: чтение, вязание на спицах. Адрес: Украина, 36021, Полтава, ул. Алмазная, 1-А, кв. 34, тел. (053-22) 3-43-12.

Сороковой Александр Иванович, канд. техн. наук, доцент кафедры компьютерных технологий и информационных систем Полтавского государственного технического университета имени Юрия Кондратюка. Научные интересы: KDD (обнаружение знаний). Увлечения и хобби: собаки. Адрес: Украина, 36022, Полтава, пер. Ломаный, 37А, тел.(053-2) 18-60-87, e-mail: [email protected]

4. Классификация OLAP-продуктов.

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

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

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

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

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

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

Задача хранилища - предоставить "сырье" для анализа в одном месте и в простой, понятной структуре.

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

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

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

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

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

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

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

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

2. Оперативная аналитическая обработка данных.

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

По Кодду, многомерное концептуальное представление данных (multi-dimensional conceptual view ) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных.

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

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

Операция спуска (drilling down ) соответствует движению от высших ступеней консолидации к низшим ; напротив, операция подъема (rolling up ) означает движение от низших уровней к высшим (рис. 2).

Рисунок 2. Измерения и направления консолидации данных

3. Требования к средствам оперативной аналитической обработки.

Многомерный подход возник практически одновременно и параллельно с реляционным . Однако, только начиная с середины девяностых годов, а точнее с
1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда , в которой он сформулировал 12 основных требований к средствам реализации OLAP (табл. 1).

Таблица 1.

Правила оценки программных продуктов класса OLAP

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

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

Помнить 12 правил Кодда слишком обременительно для большинства людей. Оказались, что можно резюмировать OLAP-определение только пятью ключевыми словами: Быстрый Анализ Разделяемой Многомерной Информации - или, кратко - FASMI (в переводе с английского: F ast A nalysis of S hared M ultidimensional I nformation ).

Это определение впервые было сформулировано в начале 1995 года и с тех пор не нуждалось в пересмотре.

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

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

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

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

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

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

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

Тест FASMI - разумное и понятное определение целей, на достижение которых ориентированы OLAP.

4. Классификация OLAP -продуктов.

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

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

Классификация по способу хранения данных

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

1. В случае MOLAP , исходные и агрегатные данные хранятся в многомерной БД или в многомерном локальном кубе.

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

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

Классификация по месту размещения OLAP -машины.

По этому признаку OLAP -продукты делятся на OLAP -серверы и OLAP -клиенты:

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

MOLAP.

MOLAP - это Multidimensional On-Line Analytical Processing, то есть Многомерный OLAP. Это означает, что сервер для хранения данных использует многомерную базу данных (МБД). Смысл использования МБД очевиден. Она может эффективно хранить многомерные по своей природе данные, обеспечивая средства быстрого обслуживания запросов к базе данных. Данные передаются от источника данных в многомерную базу данных, а затем база данных подвергается агрегации. Предварительный расчет - это то, что ускоряет OLAP-запросы, поскольку расчет сводных данных уже произведен. Время запроса становится функцией исключительно времени, необходимого для доступа к отдельному фрагменту данных и выполнения расчета. Этот метод поддерживает концепцию, согласно которой работа производится единожды, а результаты затем используются снова и снова. Многомерные базы данных являются относительно новой технологией. Использование МБД имеет те же недостатки, что и большинство новых технологий. А именно - они не так устойчивы, как реляционные базы данных (РБД), и в той же мере не оптимизированы. Другое слабое место МБД заключается в невозможности использовать большинство многомерных баз в процессе агрегации данных, поэтому требуется время для того, чтобы новая информация стала доступна для анализа.

ROLAP.

ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов.

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

Агрегированные/Предварительно агрегированные данные.

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

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

· OLAP -клиент устроен по-другому. Построение многомерного куба и OLAP -вычисления выполняются в памяти клиентского компьютера. OLAP -клиенты также делятся на ROLAP и MOLAP . А некоторые могут поддерживать оба варианта доступа к данным.

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

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

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

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

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

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

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

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

· Затраты на внедрение и сопровождение OLAP -клиента существенно ниже, чем затраты на OLAP -сервер.

· При использовании OLAP -клиента со встроенной машиной передача данных по сети производится один раз. При выполнении OLAP -операций новых потоков данных не порождается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Продажи.

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

2. Закупки.

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

3. Цены.

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

4. Маркетинг.

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

5. Склад.

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

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

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

7. Бюджет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OLAP – куб для анализа будет иметь вид (рис. 2):

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

Обзор и анализ программных технологий разработки WEB-приложений для аналитической обработки данных

Технологии оперативной аналитической обработки данных

программный модель приложение данные

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

Такие системы строятся на основе современных СУБД, в которых развит механизм управления транзакциями, что сделало их основным средством создания систем оперативной обработки транзакций (OLTP-систем, On-Line Transactions Processing).

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

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

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

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

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

Информационно-поисковый анализ - анализ данных, проводимый по заранее определенным, т.е. заранее заданным видам запросов (регламентированным запросам).

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

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

§ функциональные и логические закономерности в накопленных данных;

§ модели и правила, объясняющие найденные закономерности;

§ прогнозы развития процессов.

Сравнение характеристик различных видов анализа данных иллюстрирует таблица 1.1.

Таблица 1.1 - Сравнение видов анализа данных

В соответствии с рассмотренными выше видами анализа данных аналитические системы можно разделить на следующие группы:

1. Системы корпоративной отчетности:

§ используются для контроля оперативной ситуации и анализа отклонений (отвечают на вопрос «что происходит»);

§ предоставляют оперативные данные о результатах деятельности в виде заранее заданных форм отчетности;

§ базируются на информационно-поисковом анализе данных;

§ могут не использовать хранилище данных, а брать данные непосредственно из OLTP-систем;

§ предназначены для широкого круга конечных пользователей (клиенты, партнеры, фискальные учреждения).

2. Системы аналитической обработки данных и аналитической отчетности (OLAP-системы - системы оперативной аналитической обработки, On-Line Analytical Processing):

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

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

§ базируются на оперативно-аналитическом анализе данных;

§ чаще всего используют хранилище данных, оптимизированное под задачи многомерного анализа данных;

§ ориентированы на пользователей, которым требуется постоянное интерактивное взаимодействие с информацией (менеджеры, аналитики).

3. Системы глубокого анализа данных:

§ обладают развитыми инструментами для проведения глубокого анализа;

§ позволяют получить нетривиальные, скрытые знания;

§ используют хранилище данных в качестве источника информации;

§ базируются на интеллектуальном анализе данных;

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

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

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

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

Рисунок 1.1.1 - Виды аналитических систем

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

Известен тест, созданный в 1995 году, определяющий критерии, по которым систему можно отнести к классу OLAP-систем.

Этот тест получил название FASMI (Fast Analysis of Shared Multidimensional Information) (быстрый анализ совместно используемой многомерной информации) и в настоящее время широко используется.

В соответствии с тестом FASMI OLAP определяется пятью ключевыми словами:

§ Fast (Быстрый);

§ Analysis (Анализ);

§ Shared (Разделяемой);

§ Multidimensional (Многомерной);

§ Information (Информации).

Схематичное представление теста изображено на рисунке 1.1.2.

Рисунок 1.1.2 - Тест FASMI.

1. Fast (Быстрый)

OLAP-система должна обеспечить выдачу ответов на большинство запросов в пределах приблизительно 5 секунд. Для простых запросов этот показатель может быть 1 секунда, а для редкостных по сложности запросов он может достигать 20 секунд.

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

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

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

Для достижения данной цели разработчики OLAP-систем используют разные методы:

Динамическая предобработка данных;

Создание специальных программно-аппаратных решений;

Применение аппаратных платформ с большей производительностью.

Критерий скорости является наиболее критическим в определении принадлежности системы к классу OLAP.

2. Analysis (Анализ).

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

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

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

3. Shared (Разделяемой).

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

4. Multidimensional (Многомерной).

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

5. Information (Информации).

OLAP-система должна обеспечивать получение необходимой информации в условиях реального приложения.

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

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