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

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 рассчитаны на быстрое обслуживание относительно простых запросов большого числа пользователей. Их харак-ет малое время ожидания выполнения запросов. Эти системы работают с небольшими трансакциями, но идущими большими потоками.

Осн. св-ва:1)Атомарность-выполнение операций полностью или невыполнение вообще.

2)Согласованность-гарантия взаимной целостности данных

3)Изолированность-выполнение операций изолированно в пользовательской сети

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

31. Технология olap (On-Line Analytical Processing оперативная аналитическая обработка).

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

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

2) ср-ва графического представления данных.

OLAP-технологии основывается при помощи многомерной БД, называемых OLAP-кубами.

32.Хранилище данных (ХД), понятие и концепции построения .

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

Св-ва (принципы)организации ХД:

1)предметно-ориентированное. Инф-ция в ХД организована в соот-ии с основ-ми аспектами деят-ти п/п, т.е бизнес-процессами. Данные объедин-ся в категории и хранятся в соот-ии и с областями, кот-е они описывают

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

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

4)поддержание хронологии (истории)- привязка ко времени,или завис-ть от времени, т.е данные в ХД напрямую связаны с опреде-ым периодом времени.

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

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

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

Datamining– это процесс выделения из БД неявной и не структурированной информации с представлением её в виде пригодной для использования.

Задачи DM:

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

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

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

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

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

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

Типовые конфигурации:

    Конфигурация «1С:Бухгалтерия 8»

Основные возможности: ведение учёта по нескольким организациям в одной базе; ведение как бухгалтерского, так и налогового учёта (на раздельных планах счетов); возможность ведения учёта по упрощённой системе налогообложения (для каждой организации система налогообложения может быть выбрана независимо); более гибкие возможности по учётной политике (задаётся раздельно для бухгалтерского и налогового учёта), закрытию счетов, расчёту амортизации, учёту НДС , в том числе включение/исключение из стоимости с учётом ЕНВД в розничной торговле.

    Конфигурация «1С:Управление Торговлей 8»

Предназначена для ведения торгово-складского учёта на предприятиях. Функциональность по сравнению с конфигурацией «1С: Торговля и склад 7.7» расширена: появились возможности управления отношениями с клиентами (CRM), а также возможность планирования продаж и закупок.

    Конфигурация «1С:Зарплата и управление персоналом 8»

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

    планирование потребностей в персонале;

    управление финансовой мотивацией персонала;

    эффективное планирование занятости персонала;

    учёт кадров и анализ кадрового состава;

    начисление и выплата заработной платы;

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

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

    Конфигурация «1С:Управление производственным предприятием 8»

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

    Имеются конфигурации: «Управление производственным предприятием» (для России), «Управление производственным предприятием для Украины» и «Управление производственным предприятием для Казахстана», и это именно разные конфигурации, а не разные варианты настроек.

    Существует возможность изменения учтённых (проведённых) документов.Уровень техподдержки зависит от фирмы-партнера (так называемых «франчайзи»). Для поиска партнера существует специальный ресурс: «Выбор аттестованных франчайзи» .

Архитектура 1С:Предприятие 8

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

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

2) Прикладные механизмы. Состав прикладных механизмов 1С:Предприятия ориентирован на решение задач автоматизации учета и управления предприятием. Использование проблеммно-ориентированных объектов позволяет разработчику решать самый широкий круг задач складского, бухгалтерского, управленческого учета, расчета зарплаты, анализа данных и управления на уровне бизнес-процессов. 3) Интерфейсные механизмы. В 1С:Предприятии 8 реализован современный дизайн интерфейса и повышена комфортность работы пользователей при работе с системой в течение длительного времени.

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

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

35. ИКИС «Галактика» входит в комплекс бизнес-решений Галактика Business Suite, главное назначение которой – выполнение в едином информационном пространстве типовых и специализированных задач управления предприятием, холдингом, группой компаний в условиях современной экономики.

Система Галактика ориентирована на автоматизацию решения задач, возникающих на всех стадиях управленческого цикла: прогнозирование и планирование, учет и контроль реализации планов, анализ результатов, коррекция прогнозов и планов. Основной структурной единицей системы является модуль, предназначенный для решения отдельных задач определенной предметной области (например, «Управление сбытом», «Планирование производства»). Модули, в свою очередь, объединены в функциональные контуры. Допустимо как изолированное использование отдельных модулей, так и их произвольные комбинации, в зависимости от производственно-экономической необходимости. Стоит отметить, что в системе Галактика ERP сделан первый шаг к реализации концепции компонентной модели: логически модули системы состоят из компонент, взаимодействующих друг с другом через специальные интерфейсы.

Контур планирования и управления финансами системы Галактика ERP – это надежный инструмент для управления финансовыми ресурсами компании. Он адресован руководителям и специалистам финансовых и планово-экономических служб. С его помощью можно выполнять планирование финансово-хозяйственной деятельности предприятия, осуществлять моделирование и согласование финансовых планов, проводить анализ их фактического исполнения, вести оперативный финансовый менеджмент. Контур планирования и управления финансами системы Галактика ERP состоит из трех модулей – «Управление бюджетом», «Платежный календарь» и «Финансовый анализ».

Бюджетирование – процесс управления финансовыми ресурсами, включающий в себя следующие этапы:

Планирование и моделирование различных вариантов бюджетов;

Согласование и утверждение бюджетов;

Формирование фактических показателей бюджета;

Проведение корректировок бюджета.

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

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

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

(СУБД. - 1998. - № 4-5)

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

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

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

1. Хранилища (склады) данных

В области информационных технологий всегда сосуществовали два класса систем [ , С. 49]:

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

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

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

  • "предметно-ориентированные,
  • интегрированные,
  • неизменчивые,
  • поддерживающие хронологию

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

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

  1. Время обработки запросов к распределенному хранилищу значительно превышает соответствующие показатели для централизованного хранилища. Кроме того, структуры баз данных СОД, рассчитанные на интенсивное обновление одиночных записей, в высокой степени нормализованы, поэтому в аналитическом запросе к ним требуется объединение большого числа таблиц, что также приводит к снижению быстродействия.
  2. Интегрированный взгляд на распределенное корпоративное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Таким образом, временная недоступность хотя бы одного из источников может либо сделать работу информационно-аналитической системы (ИАС) невозможной, либо привести к ошибочным результатам.
  3. Выполнение сложных аналитических запросов над таблицами СОД потребляет большой объем ресурсов сервера БД и приводит к снижению быстродействия СОД, что недопустимо, так как время выполнения операций в СОД часто весьма критично.
  4. Различные СОД могут поддерживать разные форматы и кодировки данных, данные в них могут быть несогласованы. Очень часто на один и тот же вопрос может быть получено несколько вариантов ответа, что может быть связано с несинхронностью моментов обновления данных, отличиями в трактовке отдельных событий, понятий и данных, изменением семантики данных в процессе развития предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. В таком случае цель - формирование единого непротиворечивого взгляда на объект управления - может не быть достигнута.
  5. Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД. Основное назначение СОД - оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе.

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

Облегченным вариантом корпоративного хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. Концепция витрин данных была предложена Forrester Research в 1991 году . При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания. В 1994 году M. Demarest предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру:

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

Рассмотренная концепция ориентирована исключительно на хранение, а не на обработку корпоративных данных. Она не предопределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным. Таким образом, она оставляет свободу выбора во всем, что касается:

  • способов представления данных в целевом хранилище (например, реляционный, многомерный);
  • режимов анализа данных хранилища.

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

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

По критерию режима анализа данных информационно-аналитические системы подразделяются на две категории [ , ]:

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

Очень часто ИАС, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические СППР [ , С. 55], или Информационные системы руководителя (ИСР) [ , С. 73] - (Executive Information Systems, EIS) [ , С. 4] - содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений (ПРИМЕЧАНИЕ. По определению В. Пржиялковского [ , С. 81], ИСР - это "компьютерная система, позволяющая... предоставлять информацию в распоряжение старшего управляющего персонала с ограниченным опытом обращения с ЭВМ".). Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов; однако, каждый новый, непредусмотренный при проектировании такой системы, запрос должен быть сначала формально описан, передан программисту, закодирован и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.

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

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

По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).


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

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

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

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

1. Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View) Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice" - перевод С. Д. Кузнецова, выступление на 3-й ежегодной конференции "Корпоративные базы данных "98"), вращения (rotate) и размещения (pivot) направлений консолидации.
2. Прозрачность (Transparency) Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
3. Доступность (Accessibility) Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением оставшихся от старого наследства СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
4. Устойчивая производительность (Consistent Reporting Performance) С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
5. Клиент - серверная архитектура (Client-Server Architecture) Большая часть данных, требующих оперативной аналитической обработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров. Поэтому одним из требований является способность продуктов OLAP работать в среде клиент-сервер. Главной идеей здесь является то, что серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности.
6. Равноправие измерений (Generic Dimensionality) Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.
7. Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling) Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.
8. Поддержка многопользовательского режима (Multi-User Support) Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.
9. Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations) Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.
10. Интуитивное манипулирование данными (Intuitive Data Manipulation) Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе.
11. Гибкий механизм генерации отчетов (Flexible Reporting) Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.
12. Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels) Настоятельно рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели. Более того, каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.

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

  • собственно требования к функциональности (1, 2, 3, 6, 9, 12);
  • неформализованные пожелания (4, 7, 10, 11);
  • требования к архитектуре информационной системы, имеющие к функциональности весьма приблизительное отношение (5, 8); например, согласно требованию 5, система, реализованная на основе UNIX-сервера с терминалами, не может быть продуктом OLAP, так как не работает в клиент-серверной архитектуре; так же, OLAP продукт не может являться настольной однопользовательской системой, так как в этом случае нарушается требование 8.

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

3.2. Классификация продуктов OLAP по способу представления данных

В настоящее время на рынке присутствует около 30 продуктов, которые в той или иной степени обеспечивают функциональность OLAP (по данным обзорного Web-сервера http://www.olapreport.com на февраль 1998 года). Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.

Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP и/или интегрированные с внешними средствами, выполняющими такие функции. Эти довольно развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Для работы с небольшими, просто организованными базами эти средства подходят наилучшим образом. Основными представителями этого класса являются BusinessObjects одноименной компании , BrioQuery компании Brio Technology [ , С. 34] и PowerPlay компании Cognos [ , С. 34-35].

3.2.1. Многомерный OLAP (MOLAP)

В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

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

С другой стороны, имеются существенные ограничения.

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

  1. Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.
  2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).
  3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.
  4. Требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций.
3.2.2. Реляционный OLAP (ROLAP)

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

  1. При оперативной аналитической обработке содержимого хранилищ данных инструменты ROLAP позволяют производить анализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД).
  2. В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД.
  3. Системы ROLAP могут функционировать на гораздо менее мощных клиентских станциях, чем системы MOLAP, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой.
  4. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и разграничения прав доступа.
  5. Реляционные СУБД имеют реальный опыт работы с очень большими базами данных и развитые средства администрирования.

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

Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы [ , , ]. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений. Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению (например, Магазин - Город/район - Регион).

В общем случае факты имеют разные множества измерений, и тогда их удобно хранить не в одной, а в нескольких таблицах; кроме того, в различных запросах пользователей может интересовать только часть возможных измерений. Но при таком подходе при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Для решения этой проблемы авторы работы предлагают специальное расширение для языка SQL (оператор "GROUP BY CUBE" и ключевое слово "ALL") (ПРИМЕЧАНИЕ. В настоящее время это расширение еще не принято, поэтому данное предложение представляет пока чисто академический интерес.), а авторы [ , ] рекомендуют создавать таблицы фактов не для всех возможных сочетаний измерений, а только для наиболее полных (тех, значения ячеек которых не могут быть получены с помощью последующей агрегации ячеек других таблиц фактов базы данных).

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

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

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

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

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

Интеллектуальный анализ данных определяется в большинстве публикаций афористически - "извлечение зерен знаний из гор данных" , "разработка данных - по аналогии с разработкой полезных ископаемых" . При этом в английском языке существует два термина, переводимые как ИАД, - Knowledge Discovery in Databases (KDD) и Data Mining (DM). В большинстве работ они используются как синонимы [см., например, , ], хотя некоторые авторы [ , ] рассматривают KDD как более широкое понятие - научное направление, образовавшееся "на пересечении искусственного интеллекта, статистики и теории баз данных" и обеспечивающее процесс извлечения информации из данных и ее использования , а DM - как совокупность индуктивных методов этого процесса, то есть то, что ниже будет определено как стадия свободного поиска ИАД.

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

4.2.2. Прогностическое моделирование (Predictive Modeling)

Здесь, на второй стадии ИАД, используются плоды работы первой, то есть найденные в БД закономерности применяются для предсказания неизвестных значений:

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

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

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

4.2.3. Анализ исключений (Forensic Analysis)

Предметом данного анализа являются аномалии в раскрытых закономерностях, то есть необъясненные исключения. Чтобы найти их, следует сначала определить норму (стадия свободного поиска), вслед за чем выделить ее нарушения. Так, определив, что 84% общеобразовательных школ отнесены к муниципальной форме собственности, можно задаться вопросом - что же входит в 16%, составляющих исключение из этого правила? Возможно, им найдется логическое объяснение, которое также может быть оформлено в виде закономерности. Но может также статься, что мы имеем дело с ошибками в исходных данных, и тогда анализ исключений может использоваться в качестве инструмента очистки сведений в хранилище данных .

4.3. Классификация технологических методов ИАД

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

  1. В первом случае исходные данные могут храниться в явном детализированном виде и непосредственно использоваться для прогностического моделирования и/или анализа исключений; это так называемые методы рассуждений на основе анализа прецедентов. Главной проблемой этой группы методов является затрудненность их использования на больших объемах данных, хотя именно при анализе больших хранилищ данных методы ИАД приносят наибольшую пользу.
  2. Во втором случае информация вначале извлекается из первичных данных и преобразуется в некоторые формальные конструкции (их вид зависит от конкретного метода). Согласно предыдущей классификации, этот этап выполняется на стадии свободного поиска, которая у методов первой группы в принципе отсутствует. Таким образом, для прогностического моделирования и анализа исключений используются результаты этой стадии, которые гораздо более компактны, чем сами массивы исходных данных. При этом полученные конструкции могут быть либо "прозрачными" (интерпретируемыми), либо "черными ящиками" (нетрактуемыми).

Две эти группы и входящие в них методы представлены на рис. 4.


Рис. 4. Классификация технологических методов ИАД.

4.3.1. Непосредственное использование обучающих данных

Обобщенный алгоритм Lazy-Learning, относящийся к рассматриваемой группе, выглядит так (описание алгоритма взято из ). На вход классификатора подается пример , на выходе ожидается предсказание включающего его класса. Каждый пример представляется точкой в многомерном пространстве свойств (атрибутов) , принадлежащей некоторому классу . Каждый атрибут принимает непрерывные значения либо дискретные значения из фиксированного набора. Для примера возвращается его наиболее вероятный класс.

Индивидуальной особенностью алгоритма k-ближайшего соседа является метод определения в нем апостериорной вероятности принадлежности примера классу:

где возвращает 1, когда аргументы равны, или 0 в противном случае, - функция близости, определяемая как

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

причем чаще всего принимается r=2 (эвклидово пространство), а функция в зависимости от типа атрибута определяется следующими способами:

w(f) является функцией веса атрибута f. В чистом алгоритме k-ближайшего соседа:

то есть эта функция считается константой.

Метод ближайшего соседа является частным случаем метода k-ближайшего соседа при k=1. Более сложные алгоритмы типа Lazy-Learning основываются на том же обобщенном алгоритме [ , , ], но или иначе определяют апостериорные вероятности принадлежности примеров классам, или (как, например, Nested Generalized Exemplars Algoritm ) усложняют расчет функции w(f).

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

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

4.3.2. Выявление и использование формализованных закономерностей

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

  • по типам извлекаемой информации (которые определяются решаемой задачей - см. классификацию задач ИАД выше);
  • по способу представления найденных закономерностей.

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

  • методы кросс-табуляции;
  • методы логической индукции;
  • методы вывода уравнений.

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

Методы кросс-табуляции

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

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

К методам ИАД группы кросс-табуляции относится также использование байесовских сетей (Bayesian Networks) , в основе которых лежит теорема Байеса теории вероятностей для определения апостериорных вероятностей составляющих полную группу попарно несовместных событий по их априорным вероятностям:

Байесовские сети активно использовались для формализации знаний экспертов в экспертных системах , но с недавних пор стали применяться в ИАД для извлечения знаний из данных.

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

Стратегия, применяемая в алгоритмах индукции деревьев решений, называется стратегией разделения и захвата (divide-and-conquer), в противовес стратегии отделения и захвата (separate-and-conquer), на которой построено большое количество алгоритмов индукции правил. Quinlan описал следующий алгоритм разделения и захвата.

Множество атрибутов ;
- множество возможных значений атрибута (таким образом, области определения непрерывных атрибутов для построения деревьев решений также должны быть разбиты на конечное множество интервалов).

Quinlan предложил вычислять E-оценку следующим образом. Пусть для текущего узла:

Число положительных примеров;
- число отрицательных примеров;
- число положительных примеров со значением для ;
- число отрицательных примеров со значением для .

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

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

Индукция правил

Популярность деревьев решений проистекает из быстроты их построения и легкости использования при классификации. Более того, деревья решений могут быть легко преобразованы в наборы символьных правил - генерацией одного правила из каждого пути от корня к терминальной вершине. Однако, правила в таком наборе будут неперекрывающимися, потому что в дереве решений каждый пример может быть отнесен к одному и только к одному терминальному узлу. Более общим (и более реальным) является случай существования теории, состоящей из набора неиерархических перекрывающихся символьных правил. Значительная часть алгоритмов, выполняющих индукцию таких наборов правил, объединяются стратегией отделения и захвата (separate-and-conquer), или покрывания (covering) , начало которой положили работы R. Michalski [ , ]. Термин "отделение и захват" сформулировали Pagallo и Haussler , охарактеризовав эту стратегию индукции следующим образом:

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

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


Рис. 5. Общий алгоритм отделения и захвата для индукции правил.

Алгоритм SEPARATEANDCONQUER начинается с пустой теории. Если в обучающем множестве есть положительные примеры, вызывается подпрограмма FINDBESTRULE для извлечения правила, покрывающего часть положительных примеров. Все покрытые примеры отделяются затем от обучающего множества, произведенное правило включается в теорию, и следующее правило ищется на оставшихся примерах. Правила извлекаются до тех пор, пока не останется положительных примеров или пока не сработает критерий остановки RULESTOPPINGCRITERION. Зачастую полученная теория подвергается постобработке POSTPROCESS.

Процедура FINDBESTRULE ищет в пространстве гипотез правило, которое оптимизирует выбранный критерий качества, описанный в EVALUATERULE. Значение этой эвристической функции, как правило, тем выше, чем больше положительных и меньше отрицательных примеров покрыто правилом-соискателем (candidate rule). FINDBESTRULE обрабатывает Rules, упорядоченный список правил-соискателей, порожденных процедурой INITIALIZERULE.

Новые правила всегда вставляются в нужные места (INSERTSORT), так что Rules постоянно остается списком, упорядоченным по убыванию эвристических оценок правил. В каждом цикле SELECTCANDIDATES отбирает подмножество правил-соискателей, которое затем очищается в REFINERULE. Каждый результат очистки оценивается и вставляется в отсортированный список Rules, если только STOPPINGCRITERION не предотвращает это. Если оценка NewRule лучше, чем у лучшего из ранее найденных правил, значение NewRule присваивается переменной BestRule. FILTERRULES отбирает подмножество упорядоченного списка правил, предназначенное для использования в дальнейших итерациях. Когда все правила-соискатели обработаны, наилучшее правило возвращается.

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

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

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

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


Рис. 6. Поступрощение в обучающих алгоритмах
(a) разделения и захвата и (b) отделения и захвата.

Рис. 6(a) иллюстрирует работу поступрощения в индукции деревьев решений. Правая половина переусложненного дерева покрывается множествами C и D обучающих примеров. Когда упрощающий алгоритм решает отсечь эти две терминальные вершины, порождающий их узел становится терминальным, который теперь покрывается примерами . Левая ветвь дерева решений не затронута данной операцией.

С другой стороны, отсечение условий от правила означает его обобщение, то есть в новом виде оно будет покрывать больше положительных и больше отрицательных примеров. Следовательно, эти дополнительные положительные и отрицательные примеры должны быть исключены из обучающего множества, дабы не воздействовать на индукцию последующих правил. В случае на рис. 6(b) первое из трех правил упрощается и начинает покрывать не только примеры, покрываемые оригинальной версией, но и все примеры, которые покрывает третье правило, а также часть примеров, которые покрывает второе правило. Если третье правило после этого может быть просто удалено алгоритмом поступрощения, то ситуация с оставшимся множеством примеров B2 не такая простая. Второе правило, естественно, покрывает все примеры множества B2, потому что оно было произведено для покрытия примеров включающего его множества B. Однако вполне может статься, что другое правило окажется более подходящим для отделения положительных примеров B2 от оставшихся отрицательных примеров. Корректная обработка таких ситуаций требует тесной интеграции процессов предупрощения и поступрощения, значительно усложняющей алгоритм индукции правил и ухудшающей его производительность .

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

Методы вывода уравнений

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

Статистика

Классические методы статистического анализа применяются в средствах ИАД чаще всего для решения задачи прогнозирования.

  1. Выявление тенденций динамических рядов. Тенденцию среднего уровня можно представить в виде графика или аналитической функции, вокруг значения которой варьируют фактические значения уровней исследуемого процесса. Часто тенденции среднего уровня называют детерминированной компонентой процесса, и соответствующий динамический pяд выражается уравнением , где - уровень pяда в момент времени t, - детеpминиpованная компонента pяда, - случайная компонента. Детерминированная компонента обычно представляется достаточно простой аналитической функцией - линейной, параболической, гиперболической, экспоненциальной, - параметры которой подбираются согласно историческим данным для лучшей аппроксимации исторических данных.
  2. Гармонический анализ. Во многих случаях сглаживание рядов динамики с помощью определения тренда не дает удовлетворительных результатов, так как в остатках наблюдается автокоppеляция. Причиной автокоppелиpованности остатков могут быть нередко встречающиеся в pядах динамики заметные периодические колебания относительно выделенной тенденции. В таких случаях следует прибегать к гармоническому анализу, то есть к выделению из динамического ряда периодической составляющей. По результатам выделения из динамического ряда тренда и периодической составляющей может выполняться статистический прогноз процесса по принципу экстраполяции, по предположению, что параметры тренда и колебаний сохранятся для прогнозируемого периода [ , С. 304].
  3. Корреляционно-регрессионный анализ. В отличие от функциональной (жестко детерминированной) связи, статистическая (стохастически детерминированная) связь между переменными имеет место тогда, когда с изменением значения одной из них вторая может в определенных пределах принимать любые значения с некоторыми вероятностями, но ее среднее значение или иные статистические характеристики изменяются по определенному закону [ , С. 191-192]. Частным случаем статистической связи, когда различным значениям одной переменной соответствуют различные средние значения другой, является корреляционная связь. В соответствии с сущностью корреляционной связи ее изучение имеет две цели:
    1) измерение параметров уравнения, выражающего связь средних значений зависимых переменных со значениями независимой переменной (зависимость средних значений результативного признака от значений факторных признаков);
    2) измерение тесноты связи признаков между собой [ , С. 195-196].
    Метод корреляционно-регрессионного анализа хорошо изучен [ , 19, 29] и широко применяется на практике. Однако, он имеет ряд ограничений:
    1) для обеспечения достаточной точности и надежности число наблюдений должно быть в десятки или сотни раз больше числа факторов, чтобы закон больших чисел, действуя в полную силу, обеспечил эффективное взаимопогашение случайных отклонений от закономерного характера связи признаков;
    2) для надежного выражения закономерности по средней величине требуется достаточно качественная однородность совокупности, чтобы параметры корреляции не были извращены; кроме того, иногда в качестве условия корреляционного анализа выдвигают необходимость подчинения распределения совокупности по результативному и факторным признакам нормальному закону распределения вероятностей (это условие связано с применением метода наименьших квадратов при расчете параметров корреляции - только при нормальном распределении он дает оценку параметров, отвечающую принципам максимального правдоподобия), хотя на практике даже при приближенном выполнении этой предпосылки метод наименьших квадратов дает неплохие результаты [ , С. 14];
    3) метод корреляционно-регрессионного анализа не может объяснить роли факторных признаков в создании результативного признака [ , С. 198];
    4) интерпретировать корреляционные показатели следует лишь в терминах вариаций результативного и факторного признаков; если же задача состоит в измерении связи между изменениями признаков объекта во времени, то метод корреляционно-регрессионного анализа требует значительных изменений (требуется исследование корреляции рядов динамики) [ ; , С. 307-313].
    Получаемые в результате применения анализа корреляционно-регрессионные модели (КРМ) обычно достаточно хорошо интерпретируемы и могут использоваться в прогностическом моделировании. Но, как отмечается в , невозможно применять этот вид анализа, не имея глубоких знаний в области статистики. Теоретическая подготовка аналитика играет здесь особенно важную роль, поэтому немногие существующие средства ИАД предлагают метод корреляционно-регрессионного анализа в качестве одного из инструментов обработки данных.
  4. Корреляция рядов динамики. Проблема изучения причинных связей во времени очень сложна, и полное решение всех задач такого изучения до сих пор не разработано [ , С. 307]. Основная сложность состоит в том, что при наличии тренда за достаточно длительный промежуток времени большая часть суммы квадратов отклонений связана с трендом; при этом, если два признака имеют тренды с одинаковым направлением изменения уровней, то это вовсе не будет означать причинной зависимости. Следовательно, чтобы получить реальные показатели корреляции, необходимо абстрагироваться от искажающего влияния трендов - вычислить отклонения от трендов и измерить корреляцию колебаний (подробному рассмотрению этого подхода посвящена полностью работа ). Однако, не всегда допустимо переносить выводы о тесноте связи между колебаниями на связь рядов динамики в целом (согласно приведенному в [ , С. 312] примеру, правомерно рассматривать связь между колебаниями урожайности и колебаниями суммы выпавших за лето осадков, но связь между урожайностью и дозой удобрений нельзя свести только к корреляции колебаний).

Нейронные сети

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

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

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


Рис. 7. Нейрон с активационной функцией F; .

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

Чаще всего средства ИАД используют специальный тип нейронных сетей, обучаемых "с учителем", - многослойные персептроны [ , С. 54-55]. На рис. 8 изображена такая нейронная сеть с двумя слоями нейронов, имеющая три входных и три выходных переменных (в общем случае количество входов, количество выходов, число слоев и число нейронов в каждом внутреннем слое могут быть какими угодно). Выход каждого нейрона предыдущего слоя соединен со входом каждого нейрона последующего слоя.


Рис. 8. Многослойный персептрон, обучаемый процедурой обратного распространения ошибки.

Настройка весов многослойного персептрона осуществляется алгоритмом обратного распространения ошибки [ , С. 56-69]. При обучении предполагается, что для каждого входного вектора (множества входов) существует парный ему целевой вектор (множество выходов), и вместе они образуют обучающую пару (пример). Перед началом обучения всем весам должны быть присвоены небольшие начальные значения, выбранные случайным образом, для преодтвращения патологических случаев невозможности обучения. Все множество обучающих пар составляет обучающее множество. Обучение сети требует выполнения следующих операций:

  1. выбрать обучающую пару из обучающего множества;
  2. подать входной вектор обучающей пары на вход сети;
  3. вычислить выход сети;
  4. вычислить разность между выходом сети и целевым вектором обучающей пары;
  5. скорректировать веса сети, чтобы минимизировать ошибку;
  6. повторять шаги 1-5 для каждой пары обучающего множества до тех пор, пока ошибка на всем множестве не достигнет допустимого уровня.

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

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

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

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

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

4.3.3. Выводы

Как видно из сделанного обзора, ни один из рассмотренных методов не способен покрыть все задачи, обеспечивающие поддержку принятия управленческих решений на основе интеллектуального анализа содержимого хранилищ данных. Но большинство существующих на рынке систем интеллектуального анализа реализуют один-три метода (например, Pilot Discovery Server фирмы Pilot Software Inc. и Information Harvester фирмы Information Harvester Corp. - только деревья решений, Idis фирмы Information Discovery Inc. - деревья решений и индукцию правил, Darwin фирмы Thinking Machines - нейронные сети, деревья решений и визуализацию данных , MineSet фирмы Silicon Graphics - деревья решений, индукцию ассоциативных правил и визуализацию данных ), поэтому в реальных приложениях для того, чтобы не потерять большое количество значимых закономерностей, приходится, как правило, пользоваться несколькими разнородными инструментами. Кроме того, многие инструменты не позволяют напрямую работать с хранилищами данных, требуя предварительной подготовки исходных данных для анализа в виде плоских файлов фиксированной структуры, что также затрудняет их практическое использование.

5. Взаимодополняемость OLAP и ИАД

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


Рис. 9. Архитектура системы многомерного интеллектуального анализа данных.

Идеальной целью построения корпоративной информационно-аналитической системы является создание СППР замкнутого цикла. Как заметил N. Raden, "многие компании создали... прекрасные хранилища данных, идеально разложив по полочкам горы неиспользуемой информации, которая сама по себе не обеспечивает ни быстрой, ни достаточно грамотной реакции на рыночные события" [ , С. 39]. В особенно динамичных сферах (например, в розничной торговле), где ситуация меняется ежедневно, своевременное принятие грамотных решений не обеспечивается даже при использовании обычных средств OLAP и ИАД. Они должны быть объединены друг с другом и иметь обратную связь к исходным системам обработки данных, с тем чтобы результаты работы СППР немедленно передавались в виде управляющих воздействий в оперативные системы. Так, крупнейшая американская компания в сфере розничной торговли Wal-Mart занимается разработкой СППР замкнутого цикла }

Статьи по теме: