Учебное пособие: Методические указания для студентов Москва 2005 удк 681. 3

Финансовая академия при Правительстве РФ

Н.В.Катаргин

ОПЕРАТИВНАЯ АНАЛИТИЧЕСКАЯ

ОБРАБОТКА ДАННЫХ

OLAP .

ИНТЕЛЛЕКТУАЛЬНЫЕ

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Методические указания для студентов

Москва 2005

УДК 681.3

Рецензенты:

Доктор экономических наук, профессор, зав.кафедрой ИТУ и ВТ Академии труда и социальных отношений В.Н.Квасницкий

Доцент кафедры ВТ и ПМ Московского государственного агроинженерного университета им.В.П.Горячкина Т.И.Воловник

Катаргин Н.В.

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

Интеллектуальные информационные системы.

Методическое пособие для студентов – 26 с.

Описан новый подход к оперативной аналитической обработке данных - On-Line Analytical Processing (OLAP), основанный на предварительном отборе информации из баз данных, проведении обработки и структуризации данных и расчетных величин в виде многомерных кубов. Рассмотрены различные технологии создания многомерных хранилищ данных и программные средства для создания и использования кубов в СУБД SQL Server и Excel. Рассмотрены интеллектуальные информационные системы, в том числе экспертные системы и интеллектуальный анализ данных совместно с OLAP.

Введение

В 1970 году Е.Ф.Кодд (E.F.Codd) опубликовал ряд статей, в которых заложил основы алгебры отношений, или реляционной алгебры, послужившей основой для создания реляционных баз данных, как настольных (dBase, FoxPro, Paradox, Access), так и серверных: Oracle, SQL Server, MySQL, SyBase, Informix и др., в которых данные размещаются в двумерных таблицах. Поиск и обработка данных по нескольким таблицам обеспечиваются путем связывания полей таблиц, содержащих одинаковые атрибуты отображаемых в базе данных объектов. Обычно в одной из таблиц связываемое поле является ключевым, что обеспечивает непротиворечивость данных в различных таблицах. В реляционных базах данных накопилось огромное количество информации, алгоритмы ее обработки и требования к скорости и удобству аналитической обработки данных выросли, что потребовало нового подхода и программного обеспечения. В 1993 году Кодд предложилновый подход к аналитической обработке данных - On-Line Analytical Processing (OLAP), основанный на предварительном отборе информации из баз данных, проведении математической обработки и структуризации данных и расчетных величин в виде многомерных кубов, в которых значение каждого элемента данных зависит не от двух индексов, как в двумерной таблице (номер строки и номер столбца), а от нескольких. Трехмерный куб можно себе представить как набор двумерных таблиц, индексы каждого элемента данных при этом - номер строки, номер столбца и номер таблицы. Четырехмерный куб представить себе уже невозможно, но математические методы и программные средства позволяют эффективно с ними работать. Заметим, что в OLAP-кубах не соблюдаются требования нормализации таблиц реляционных баз данных: в них можно размещать расчетные значения (агрегаты). Отбор данных из OLAP-куба геометрически можно представить как его сечение плоскостью или более сложной поверхностью.

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

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

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

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

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

В настоящее время программные средства для использования OLAP-технологии имеются в пакетах серверных реляционных СУБД Oracle, SQL Server и др., а также в Excel и в клиентских приложениях, создаваемых с помощью Delphi, C++Builder, Visual Basic. Суммарный объем рынка OLAP, включая расходы на разработку программных продуктов, в конце 90-х г.г. составлял несколько миллиардов долларов, а темпы роста составляли 40% в год.

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

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

Обычно обработку данных проводят по схеме “Клиент-Сервер”, представленной на Рис.1. При этом данные хранятся в мощном компьютере - сервере, а компьютер пользователя (клиент) может иметь минимальные ресурсы, вплоть до мобильного телефона с выходом в Internet по протоколу GPRS. В компьютере пользователя должна быть программа-клиент, обеспечивающая передачу запросов от программы пользователя через линию связи машине-серверу, прием ответов и их передачу программе пользователя для визуализации. В машине-сервере должна быть программа-сервер, обеспечивающая прием запросов от клиентов и их передачу системе управления базой данных (СУБД) для выполнения, а также передачу ответов клиентам.

Данные Программа

СУБД Сервер пользователя Клиент

Сервер Клиент

Линия связи

Рис.1. Обработка данных по схеме Клиент-Сервер

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

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

· возможность исторического анализа показателей за любой временной период;

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Полная структура корпоративной информационно-

аналитической системы (ИАС )

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

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

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

В 1993 году в работе [1] Е.Ф.Кодд рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил 12 общих требований к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик. Позже его определение было переработано в так называемый тест FASMI , требующий, чтобы OLAP-приложение предоставляло возможности быстрого анализа разделяемой многомерной информации: I

Fast (Быстрый) –анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика - 5 с или менее.

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

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

Multidimensional (Многомерной) – это основная, наиболее существенная характеристика OLAP.

Information (Информации) – приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

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

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

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

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

Первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software, Oracle Express Server компании Oracle) относились к классу MOLAP , то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.

Системы оперативной аналитической обработки реляционных данных (ROLAP ) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных (описаний данных). К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Программный комплекс ИнфоВизор, разработанный в России, в Ивановском государственном энергетическом университете, также является системой этого класса. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.

Гибридные системы (Hybrid OLAP, HOLAP ) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.

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

Далее эти системы рассмотрены более подробно.

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

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

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

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

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

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

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

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

· Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда в 2.5-100 раз меньшему объему исходных детализированных данных.

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

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

· Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.

· Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

· Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

·

Реляционный OLAP (ROLAP ).

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

· В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.

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

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

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

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

Рис. 4. Пример схемы "звезды"

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

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

4. Основные понятия многомерной модели данных

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

Основными понятиями многомерной модели данных являются:

Показатель (факт, m easure) – это величина (обычно числового типа), которая собственно и является предметом анализа. Это, например, объём продаж некоторого товара, или выручка от продаж товара. Один OLAP-куб может обладать одним или несколькими показателями.

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

Объекты, совокупность которых и образует измерение, называются членами измерений (members). Члены измерений визуализируют как точки или участи, откладываемые на осях гиперкуба. Например, временное измерение: Дни, Месяцы, Кварталы, Годы – наиболее часто используемые в анализе, могут содержать следующие члены: 8 мая 2002 года, май 2002 года,

2-ой квартал 2002 года и 2002 год.

Объекты в измерениях могут быть различного типа, например “производители” – “марки автомобиля” или “годы” – “кварталы”. Эти объекты должны быть организованы в иерархическую структуру так, чтобы объекты одного типа принадлежали только одному уровню иерархии.

Ячейка (cell) – атомарная структура куба, соответствующая конкретному значению некоторого показателя. Ячейки при визуализации располагаются внутри куба и здесь же принято отображать соответствующее значение показателя.

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

Рис. 5 Куб c тремя измерениями

Заметим, что, в отличие от измерений, не все значения показателей должны иметь и имеют реальные значения. Например, Менеджер Петров в 1994 г. мог еще не работать в фирме, и в этом случае все значения Показателя Объем продаж за этот год будут иметь неопределенные, “пустые” значения.

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

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

Значения, "откладываемые" вдоль измерений, называются членами или метками (members). Метки используются как для "разрезания" куба, так и для ограничения (фильтрации) выбираемых данных – когда в измерении, остающемся "неразрезанным", нас интересуют не все значения, а их подмножество, например три города из нескольких десятков. Значения меток отображаются в двумерном представлении куба как заголовки строк и столбцов. Метки могут объединяться в иерархии , состоящие из одного или нескольких уровней (levels) . Например, метки измерения "Магазин" (Store) естественно объединяются в иерархию с уровнями:

All (Мир)

Country (Страна)

State (Штат)

City (Город)

Store (Магазин).

В соответствии с уровнями иерархии вычисляются агрегатные значения , например объем продаж для USA (уровень "Country") или для штата California (уровень "State"). В одном измерении можно реализовать более одной иерархии - скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.

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

Существуют следующие типы иерархий:

Сбалансированные (balanced ) иерархии, в которых число уровней определено её структурой и неизменно, и каждая ветвь иерархического дерева содержит объекты каждого из уровней. Каждому производителю автомобилей может соответствовать несколько марок автомобилей, а каждой марке – несколько моделей автомобилей, поэтому можно говорить о трёхуровневой иерархии этих объектов. В этом случае на первом уровне иерархии располагаются производители, на втором – марки, а на третьем – модели.
Как нетрудно понять, что для формирования сбалансированной иерархии необходимо наличие связи “один-ко-многим” между объектами менее детального уровня по отношению к объектам более детального уровня. В принципе каждый уровень сбалансированной иерархии можно представить как отдельное простое измерение, но тогда эти измерения окажутся зависимыми, в значит неизбежно повышение разреженности куба.

Несбалансированные (unbalanced) – иерархии, в которых число уровней может быть изменено, и каждая ветвь иерархического дерева может содержать объекты, принадлежащие не всем уровням, только нескольким первым. Необходимо заметить, что все объекты несбалансированной иерархии принадлежат одному типу. Типичный пример несбалансированной иерархии – иерархия типа "начальник – подчиненный", где все объекты имеют один и тот же тип – “Сотрудник”.

Неровные (ragged) – иерархии, в которых число уровней определено её структурой и постоянно, однако в отличие от сбалансированной иерархии некоторые ветви иерархического дерева могут не содержать объекты какого-либо уровня. Иерархии такого вида содержат такие члены, логические "родители" которых не находятся на непосредственно вышестоящем уровне. Типичным примером является географическая иерархия, в которой есть уровни “Страны”, “Штаты ” и “Города”, но при этом в наборе данных имеются страны, не имеющие штатов или регионов между уровнями “Страны” и “Города”.

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

В одном из опубликованных стандартных тестов полный подсчет агрегатов для 10 Мб исходных данных потребовал 2,4 Гб, т. е. данные выросли в 240 раз.

Архитектура OLAP-приложений

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

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

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

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

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

Конкретные OLAP-продукты, как правило, представляют собой либо средство многомерного представления данных, OLAP-клиент (например, Pivot Tables в Excel 2000 фирмы Microsoft или ProClarity фирмы Knosys), либо многомерную серверную СУБД, OLAP-сервер (например, Oracle Express Server или Microsoft OLAP Services).

Слой многомерной обработки обычно бывает встроен в OLAP-клиент и/или в OLAP-сервер, но может быть выделен в чистом виде, как, например, компонент Pivot Table Service фирмы Microsoft.

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

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

5. OLAP и многомерные базы данных

Термин "OLAP" неразрывно связан с термином "хранилище данных" (Data Warehouse). Приведем определение, сформулированное "отцом-основателем" хранилищ данных Биллом Инмоном: "Хранилище данных – это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управленческих решений".

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

Создание многомерных баз данных и Аналитические службы SQL Server

OLAP-кубы можно создавать на машине-клиенте, и средства для этого есть, но мы будем рассматривать их создание и обработку на машине-сервере с использованием мощной СУБД Microsoft SQL Server 2000 Enterprise Edition с использованием входящих в ее состав Аналитических Служб (Analytical Services). Серверные OLAP -средства являются промежуточным звеном между хранилищем данных в виде реляционной СУБД и клиентским приложением. Основным компонентом аналитических служб является программа Analysis Server - сервис операционной системы Windows NT/2000/XP. Этот сервер предназначен для создания OLAP-кубов на основе реляционных хранилищ данных, а также для предоставления доступа к ним из клиентских приложений. Для работы с ним необходимо установить аналитические службы Microsoft SQL Server (они входят в комплект поставки Microsoft SQL Server Enterprise Edition, Standard Edition, Developer Edition и Personal Edition) и запустить утилиту Analysis Manager, с помощью которой обычно и создаются многомерные базы данных. Прежде всего следует зарегистрировать в Analysis Manager программу OLAP-сервер (он может находиться как на локальном компьютере, так и на другом компьютере в рамках локальной сети), выбрав пункт Register Server из контекстного меню элемента Analysis Servers в левой части главного окна Analysis Manager. Затем нужно соединиться с OLAP-сервером, выбрав пункт Connect контекстного меню соответствующего элемента.

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

Прежде чем создавать OLAP-кубы, необходимо описать источники исходных данных для них. Для описания источника данных выберем из контекстного меню элемента Data Sources пункт New Data Source… и заполним поля стандартной диалоговой панели Data Link Properties. В качестве провайдера данных (программа, обеспечивающая преобразование формата данных) укажем OLE DB Provider for SQL Server и выберем базу данных.

В Microsoft SQL Server Analysis Services измерения делятся на коллективные (shared dimensions) и частные (private dimensions).

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

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

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

Иерархия данных в измерениях, основанных на данных типа «дата/время», подчиняется определенным стандартным правилам – ведь время измеряется в годах, месяцах, днях, часах, минутах независимо от того, какую предметную область мы анализируем. Поэтому измерения в OLAP-средствах обычно делятся на стандартные (не имеющие отношения ко времени) и временные. Поскольку наше измерение относится к последним, в диалоговой панели Select the dimension type выберем опцию Time Dimension и в качестве колонки, в которой содержатся данные типа «дата/время», укажем выбранное поле.

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

Создание измерения заканчивается запуском редактора измерений – Dimension Editor. В нем при необходимости можно внести изменения в структуру измерения, например добавив дополнительные уровни или свойства членов измерения. Так, если мы планируем анализировать зависимость продаж от дня недели или сравнивать продажи в выходные, праздничные и будние дни, можно перенести в раздел Member Properties уровня Day поля Day of Week, Holiday и Weekend исходной таблицы

Заполнение хранилища данных OLAP с помощью DTS

Data Transformation Services ( DTS ) – это набор служб SQL Server, предназначенных для организации импорта, экспорта, преобразования данных и переноса их между любыми источниками, доступными через интерфейсы OLE DB. С их помощью можно копировать структуры данных и сами данные из одной базы данных в другую, создавать средства для переноса данных, встроенные в приложения, а также дополнять хранилища данных из разнообразных источников различных типов (не обязательно SQL Server). Для описания источников данных и заполнения хранилища данных обычно требуется создать и выполнить так называемый пакет DTS (DTS package), содержащий описание последовательности всех действий, которые следует выполнить при переносе данных (включая преобразование типов данных, выполнение запросов и т.д.). Создать пакет DTS можно с помощью редактора DTS package editor.Для его запуска следует в SQL Server Enterprise Manager соединиться с сервером, содержащим хранилище данных, найти в разделе Data Transformation Services элемент Meta Data Services Packages и выбрать опцию New Packages из его контекстного меню. Затем требуется описать базу данных, в которой находится хранилище. Для этого требуется перенести на рабочее пространство редактора пакетов DTS пиктограмму Microsoft OLE DB Provider for SQL Server с палитры Data Tool в левой части окна редактора. После этого появится диалоговая панель Connection Properties (Свойства соединения), в которой нужно выбрать базу данных и указать параметры доступа к ней (пароль и др.).

Создание OLAP-кубов

Как и измерение, куб можно создать с помощью соответствующего мастера или непосредственно в редакторе кубов. Запустить мастер создания кубов можно командой New Cube | Wizard из контекстного меню элемента Cubes.

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

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

Рис. 6. Выбор мер куба в Мастере создания кубов

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

К созданному кубу можно добавить вычисляемые значения, то есть значения, которые не хранятся в самом кубе, а вычисляются “на лету”. Типичным примером такого значения может быть дополнительная мера, вычисленная на основе уже имеющихся. При вычислениях можно использовать как функции из библиотеки, входящей в состав Analysis Services, так и выражения Visual Basic for Applications (VBA), а также собственные библиотеки функций. Для создания вычисляемых выражений следует выбрать раздел Calculated Members и из контекстного меню выбрать опцию New Сalculated Member. После этого будет запущен построитель выражений (Calculated Member Builder), в котором можно создавать и редактировать выражения, перетаскивая мышью имена измерений и их уровней, мер, имена функций.

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

Для определения количества агрегатов и их вычисления следует запустить Storage Design Wizard – мастер создания многомерного хранилища. Для этого в редакторе кубов следует выбрать пункт меню Tools | Design Storage. В первой диалоговой панели следует указать способ хранения данных – MOLAP, ROLAP или HOLAP, затем выбрать, какова должна быть производительность при выполнении запросов (либо будущий максимальный объем хранилища). После этого можно нажать на кнопку Start и получить зависимость производительности от объема хранилища.

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

6. Microsoft Excel как OLAP-клиент

Первым из компонентов Microsoft Office, предназначенных для создания OLAP-клиентов, является набор библиотек PivotTable Service . С одной стороны, он является составной частью Analysis Services и выполняет роль связующего звена между Analysis Services и их клиентами (не обязательно имеющими отношение к Microsoft Office). PivotTable Service может быть установлен отдельно на компьютер, на котором эксплуатируются какие-либо клиенты Analysis Services; для его установки в состав Analysis Services входит отдельный дистрибутив. С другой стороны, PivotTable Service входит и в состав Microsoft Office 2000/XP и при этом может быть использован не только для работы с данными Analysis Services, но и для создания и чтения локальных OLAP-кубов, не имеющих отношения к Analysis Services, как с помощью Microsoft Excel, так и без него.

PivotTable Service можно использовать в различных средствах разработки клиентских приложений: Visual Basic, Delphi, C++Builder, Visual C++. PivotTable Service поддерживает язык Multidimensional Expressions(MDX) и подмножество языка SQL, а также позволяет вводить в тексты программ на Visual Basic, Delphi, C++ дополнительные расширения подмножеств языка SQL – DDL (Data Definition Language – язык определения данных) и DML (Data Manipulation Language – язык манипулирования данными), необходимые для описания структуры локальных OLAP-кубов. Особый интерес представляют использование предложения CreateCube (расширение языка DDL)для описания структуры OLAP-куба и предложения InsertInto (расширение языка DML) для заполнения локального OLAP-куба данными.

Вторым компонентом, который может быть использован для просмотра OLAP-кубов, является служба, называемая PivotTable Reports – средство создания сводных таблиц Microsoft Excel. Это средство позволяет получать, сохранять в оперативной памяти и отображать на листах рабочих книг двухмерные и трехмерные наборы агрегатных данных на основе данных из реляционных СУБД и рабочих книг Excel. PivotTable Reports входит в Excel начиная с версии 5.0, но возможность считывать с помощью него данные из OLAP-кубов Analysis Services, равно как и создавать локальные OLAP-кубы, впервые появилась в Excel 2000. Отметим, что средство создания сводных таблиц Excel использует библиотеки PivotTable Services.

И наконец, третьим компонентом, применяемым при создании OLAP-клиентов, является PivotTable List – элемент управления ActiveX, входящий в состав Microsoft Office Web Components и предназначенный для просмотра сечений OLAP-кубов. Применяется он главным образом на Web-страницах, а иногда и в обычных Windows-приложениях, например в последних версиях С++Builder и Delphi.

Средства создания сводных таблиц Microsoft Excel хранят в памяти агрегатные данные, вычисленные на основе данных из реляционных СУБД или полученные от OLAP-серверов. Манипулируя сводной таблицей, пользователь может управлять отображением этих данных.

Посредством Microsoft Excel 2000 можно корректно отображать данные из OLAP-кубов, созданных с помощью Microsoft SQL Server 7.0 OLAP Services. Что касается OLAP-кубов, созданных с помощью Microsoft SQL Server 2000 Analysis Services, по большей части посредством Microsoft Excel 2000, то они также отображаются корректно, однако имеются и некоторые ограничения.

Создание сводной таблицы с данными OLAP-кубов

Запустим Microsoft Excel и из меню Data выберем PivotTable and PivotChart Report. После этого управление будет передано мастеру PivotTable and PivotChart Wizard. В первой диалоговой панели этого мастера укажем, что для построения сводной таблицы выбирается внешний источник данных, для чего выберем опцию External data source. Затем укажем, что это за источник, нажав кнопку Get Data в следующей диалоговой панели, что приведет к запуску приложения Microsoft Query. Далее выберем закладку OLAP Cubes и, если в операционной системе еще нет описания соответствующего источника данных, создадим его (рис. 7).

Рис. 7. Описание источника данных

В процессе создания источника данных укажем его имя, выберем OLE DB-провайдер (в нашем случае – Microsoft OLE DB Provider for OLAP Services 8.0, поскольку мы используем Microsoft SQL Server 2000 Analysis Services) и нажмем на кнопку Connect (рис. 8).

Рис. 8. Выбор типа данных (provider) и выбора источника данных

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

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

Для дальнейших манипуляций нам потребуется панель инструментов PivotTable, в которой необходимо определить, какие из мер мы хотим отобразить в сводной таблице. Для этого достаточно перенести мышью кнопку (в случае Excel 2002 – соответствующий элемент из списка) с наименованием нужной меры в область данных (Data Area). Затем требуется определить, какие из полей будут участвовать в формировании строк, столбцов и страниц (иногда последние называются фильтрами). В общем случае сводная таблица является трехмерной, и можно считать, что третье измерение расположено перпендикулярно экрану, а мы наблюдаем сечения, параллельные плоскости экрана и определяемые тем, какая “страница” выбрана для отображения. Осуществить фильтрацию можно путем перетаскивания мышью соответствующих кнопок с панели инструментов PivotTable (в случае Excel 2002 – соответствующих элементов с панели PivotTable Field List) на области строк, столбцов и страниц сводной таблицы – Row Area, Column Area и Page Area. В сводной таблице Excel отобразится содержимое OLAP-куба. Теперь этим отображением можно манипулировать.

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

С помощью одного из доступных в Excel шаблонов оформления можно изменить оформление сводной таблицы. Кроме того, можно выбрать на панели инструментов PivotTables пункты меню PivotTable | Table Options или PivotTable | Field Settings и изменить другие параметры отображения данных в сводной таблице.

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

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

Microsoft Excel позволяет создавать локальные OLAP-кубы, представляющие собой подмножества данных серверных OLAP-кубов. Локальные кубы хранятся в файлах с расширением *.cub. Для корректного создания локального куба на основе серверного куба, содержащего несбалансированные измерения, рекомендуется применять Microsoft Excel 2002. Чтобы создать локальный OLAP-куб на основе серверного куба, следует на панели инструментов PivotTables выбрать пункт меню PivotTable | Offline OLAP в Excel 2002 (в Excel 2000 ему соответствовал пункт меню PivotTable | Client-Server Settings) и нажать кнопку Create offline data file (в Excel 2000 — Create Local Cube). Далее следует выбрать измерения и их уровни, а также меры, которые будут присутствовать в локальном кубе. Помимо выбора измерений, их уровней и мер можно внести и другие ограничения в набор данных, который будет содержаться в локальном кубе, выбрав набор членов изменений, участвующих в его формировании.

Теперь осталось только сохранить локальный куб в файле с расширением *.cub. Отметим, что этот файл является отчуждаемым: его можно просматривать на любом компьютере, оснащенном как Microsoft Excel 2002, так и Microsoft Excel 2000, независимо от наличия на нем Microsoft SQL Server Analysis Services или их клиентской части.

7. Основы построения и использования интеллектуальных информационных систем

Многие поколения людей мечтали о создании “думающей машины”. Особые надежды возлагались на ЭВМ, проходили бурные дискуссии на тему “Может ли машина мыслить?”. Решались и практические задачи: в 50-е г.г. ХХ века были начаты работы по машинному переводу с одного языка на другой, было создано устройство для распознавания образов – персепетрон, позднее были разработаны программы для игры в шахматы. Теоретический задел, созданный на первом этапе, привел в 80-е гг. к важным практическим результатам – создание экспертных и интеллектуальных расчетно-логических и информационно-поисковых систем, общение с компьютером на естественном языке, решение не вполне структурированных задач. В настоящее время под искусственным интеллектом понимают область исследований, в которой изучаются системы, строящие результирующий вывод для задач с неизвестным алгоритмом решения на основе неформализованной исходной информации.

Классификация интеллектуальных информационных систем

Интеллектуальные информационные системы можно разделить на две группы:

· Системы общего назначения: экспертные, нейросистемы, интеллектуальные пакеты прикладных программ (ИППП);

· Системы эвристического поиска, обычно специализированные: роботехнические, распознавания образов, игровые, общения: обработки текстов, речевого общения, машинного перевода.

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

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

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

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

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

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

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

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

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

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

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

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

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

· Исходные данные могут храниться в явном детализированном виде и непосредственно использоваться для прогностического моделирования и/или анализа исключений; это так называемые методы рассуждений на основе анализа прецедентов. Главной проблемой этой группы методов является затрудненность их использования на больших объемах данных, хотя именно при анализе больших хранилищ данных методы ИАД приносят наибольшую пользу.

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

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

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

Интеграция OLAP и ИАД

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

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

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

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

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

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

Знания и их свойства

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

1) Внутренняя интерпретация, т.е. хранение в памяти не только данных, но и их описаний – метаданных, например, заголовков таблиц.

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

3) Внешняя структура связей – связи объектов между собой.

4) Шкалирование – упорядочение информационных единиц путем измерения интенсивности отношений и свойств.

5) Семантическая метрика позволяет соотносить понятия, к которым неприменимы количественные шкалы.

6) Активность – получение новых знаний на основе существующих.

Знания можно классифицировать по различным основаниям:

· По способу существования различают факты (хорошо известные обстоятельства) и эвристики (знания из опыта экспертов.

· По способу использования: факты, правила принятия решений, описание знаний – метазнания.

· По формам представления: декларативные (факты в виде наборов структурированных данных) и процедурные (алгоритмы в виде процедур обработки фактов).

· По способу приобретения: научные и житейские, бытовые.

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

Экспертные системы

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

Огромный интерес к ЭС обусловлен тремя основными обстоятельствами:

· ЭС ориентированы на решение широкого круга задач в ранее неформализуемых областях, которые считались малодоступными для использования ЭВМ;

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

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

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

Структура типовой ЭС представлена на рис.12.