SQL DSO
Decision Support Objects (DSO)— это набор библиотек, содержащих COM-объекты, позволяющие создавать и модифицировать многомерные базы данных и содержащиеся в них объекты (кубы, коллективные измерения и т.д.). Отметим, что Analysis Manager — приложение, использующее SQL DSO, — входит в состав аналитических служб.
Эти библиотеки можно использовать для разработки собственных приложений, в которых осуществляется создание или модификация многомерных баз данных, в том числе и для реализации действий, не предусмотренных в клиентских утилитах, входящих в состав аналитических служб (рис. 1).
Рис. 1. Приложение, использующее SQL DSO
Отметим, что SQL DSO можно использовать только для доступа к аналитическим службам Microsoft. Ни к каким другим OLAP-серверам с помощью этих библиотек обратиться нельзя.
Более подробно о применении SQL DSO мы расскажем в отдельной статье.
Средства добычи знаний в бизнесе и финансах
1. Классы систем интеллектуального анализа данных, применяемые в бизнесе и финансах
1.1. Предметно-ориентированные аналитические системы
1.2. Статистические пакеты
1.3. Нейронные сети
1.4. Системы рассуждений на основе аналогичных случаев
1.5. Деревья решений (decision trees)
1.6. Генетические алгоритмы
1.7. Нелинейные регрессионные методы
1.8. Эволюционное программирование
2. Тестовая задача
Вместо заключения, или "если очень хочется, то это только кажется"
Компьютерные технологии автоматического интеллектуального анализа данных переживают бурный расцвет. Это связано главным образом с потоком новых идей, исходящих из области компьютерных наук, образовавшейся на пересечении искусственного интеллекта, статистики и теории баз данных и обозначаемой как KDD (knowledge discovery in databases - обнаружение знаний в базах данных). Сейчас происходит лавинообразный рост числа программных продуктов, использующих технологии KDD, а также типов задач, где их применение дает значительный экономический эффект. Элементы автоматической обработки и анализа данных становятся неотъемлемой частью концепции электронных хранилищ данных и часто именуются в этом контексте data mining (добыча знаний из данных). На российском рынке эта технология делает лишь первые шаги. Отчасти это можно объяснить высокой стоимостью систем data mining, но, как показывает история развития других сегментов компьютерного рынка России, сам по себе этот фактор вряд ли является определяющим. Скорее здесь проявляется действие некоторых специфичных для России негативных факторов, резко уменьшающих эффективность применения технологии data mining. Постараемся определить эти факторы, проанализировать степень подверженности им различных классов систем интеллектуального анализа данных, а также выделить свойства таких систем, облегчающие российским покупателям их применение.
Начнем с характеристики российской специфики. Компьютерные системы поддержки принятия решений, в принципе, могут основываться на двух подходах.
Другой отличительной чертой российской экономики, как на макро-уровне, так и на уровне отдельных предприятий, является ее нестабильность; кроме того, она подвержена и действию многочисленных, неожиданно возникающих факторов. В то время как на Западе предприятия в основном работают в рамках уже устоявшейся законодательной базы, в сложившихся структурах товарных, финансовых и информационных потоков, российские предприятия вынуждены подстраиваться под постоянно меняющиеся правила игры. Это же касается российских финансовых рынков (например, ГКО), где примерно раз в полгода происходит существенная корректировка правил работы. Итак, человек должен обязательно контролировать и анализировать результаты, получаемые системами data mining. Это нужно, чтобы гарантировать учет всех влияющих на решение факторов. Как следствие, построенные модели должны быть прозрачны и допускать интерпретацию.
Наконец, еще одно обстоятельство влияет на применение систем добычи знаний в российских условиях. Оно связано с тем, что люди, ответственные за принятие решений в бизнесе и финансах, обычно не являются специалистами по статистике и искусственному интеллекту и поэтому не могут непосредственно использовать системы интеллектуального анализа данных, требующие сложной настройки или специальной подготовки данных. Если такая система поставляется как составная часть общей технологии электронных хранилищ данных, реализованной на предприятии (что становится самой распространенной практикой в развитых странах), то это не составляет проблемы - все настройки и препроцессорная обработка осуществляются автоматически. Однако российские предприятия, использующие хранилища данных с элементами data mining, сегодня крайне немногочисленны. Поэтому важными факторами, определяющими коммерческий успех систем интеллектуального анализа данных в России, являются простота в использовании и высокая степень автоматизма.
Названные факторы в большой степени определяют динамику продвижения data mining в России и будут определять ее еще 1,5-2 года.Рассмотрим теперь существующие классы систем добычи знаний и проанализируем их с точки зрения этих факторов, а затем проиллюстрируем данный анализ на примере одной из типичнейших задач из области финансовых рынков.
Статистические пакеты
Хотя последние версии почти всех известных статистических пакетов включают наряду с традиционными статистическими методами также элементы data mining, основное внимание в них уделяется все же классическим методикам - корреляционному, регрессионному, факторному анализу и другим. Главный недостаток систем этого класса - их невозможно эффективно применять для анализа данных, не имея глубоких знаний в области статистики. Неподготовленный пользователь должен пройти специальный курс обучения. Обычно в процессе исследования данных с помощью статистических пакетов приходится многократно применять набор из одних и тех же элементарных операций, однако в этих системах средства автоматизации процесса исследования либо отсутствуют, либо требуют программирования на некотором внутреннем языке, что также редко по силам пользователю, если он не статистик и не программист. Все эти факторы делают мощные современные статистические пакеты слишком тяжеловесными для массового применения в финансах и бизнесе. К тому же часто эти системы весьма дороги - от 1000 до 8000 долл. В качестве примеров, доступных в России, можно назвать SAS (компания SAS Institute), SPSS (SPSS) и Statgraphics (Statistical Graphics).
Таблица фактов
Таблица фактов является основной таблицей хранилища данных. Как правило, она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться. Обычно говорят о четырех наиболее часто встречающихся типах фактов. К ним относятся:
факты, связанные с транзакциями (Transaction facts). Они основаны на отдельных событиях (типичными примерами которых являются телефонный звонок или снятие денег со счета с помощью банкомата); факты, связанные с «моментальными снимками» (Snapshot facts). Основаны на состоянии объекта (например, банковского счета) в определенные моменты времени, например на конец дня или месяца. Типичными примерами таких фактов являются объем продаж за день или дневная выручка; факты, связанные с элементами документа (Line-item facts). Основаны на том или ином документе (например, счете за товар или услуги) и содержат подробную информацию об элементах этого документа (например, количестве, цене, проценте скидки); факты, связанные с событиями или состоянием объекта (Event or state facts). Представляют возникновение события без подробностей о нем (например, просто факт продажи или факт отсутствия таковой без иных подробностей).Для примера рассмотрим факты, связанные с элементами документа (в данном случае счета, выставленного за товар).
Таблица фактов, как правило, содержит уникальный составной ключ, объединяющий первичные ключи таблиц измерений. Чаще всего это целочисленные значения либо значения типа «дата/время»— ведь таблица фактов может содержать сотни тысяч или даже миллионы записей, и хранить в ней повторяющиеся текстовые описания, как правило, невыгодно — лучше поместить их в меньшие по объему таблицы измерений. При этом как ключевые, так и некоторые неключевые поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем будут получены агрегатные данные.
Пример таблицы фактов, которая может быть построена на основе базы данных Northwind, приведен на рис. 2.
Рис. 2. Пример таблицы фактов
В данном примере измерениям будущего куба соответствуют первые шесть полей, а агрегатным данным — последние четыре.
Отметим, что для многомерного анализа пригодны таблицы фактов, содержащие как можно более подробные данные (то есть соответствующие членам нижних уровней иерархии соответствующих измерений). В данном случае предпочтительнее взять за основу факты продажи товаров отдельным заказчикам, а не суммы продаж для разных стран — последние все равно будут вычислены OLAP-средством. Исключение можно сделать, пожалуй, только для клиентских OLAP-средств (о них мы поговорим чуть позже), поскольку в силу ряда ограничений они не могут манипулировать большими объемами данных.
Отметим, что в таблице фактов нет никаких сведений о том, как группировать записи при вычислении агрегатных данных. Например, в ней есть идентификаторы продуктов или клиентов, но отсутствует информация о том, к какой категории относится данный продукт или в каком городе находится данный клиент. Эти сведения, в дальнейшем используемые для построения иерархий в измерениях куба, содержатся в таблицах измерений.
Таблицы измерений
Таблицы измерений содержат неизменяемые либо редко изменяемые данные. В подавляющем большинстве случаев эти данные представляют собой по одной записи для каждого члена нижнего уровня иерархии в измерении. Таблицы измерений также содержат как минимум одно описательное поле (обычно с именем члена измерения) и, как правило, целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной идентификации члена измерения. Если будущее измерение, основанное на данной таблице измерений, содержит иерархию, то таблица измерений также может содержать поля, указывающие на «родителя» данного члена в этой иерархии. Нередко (но не всегда) таблица измерений может содержать и поля, указывающие на «прародителей», и иных «предков» в данной иерархии (это обычно характерно для сбалансированных иерархий), а также дополнительные атрибуты членов измерений, содержавшиеся в исходной оперативной базе данных (например, адреса и телефоны клиентов).
Каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов.
Отметим, что скорость роста таблиц измерений должна быть незначительной по сравнению со скоростью роста таблицы фактов; например, добавление новой записи в таблицу измерений, характеризующую товары, производится только при появлении нового товара, не продававшегося ранее.
Пример таблицы измерений приведен на рис. 3.
Рис. 3. Пример таблицы измерений
Одно измерение куба может содержаться как в одной таблице (в том числе и при наличии нескольких уровней иерархии), так и в нескольких связанных таблицах, соответствующих различным уровням иерархии в измерении. Если каждое измерение содержится в одной таблице, такая схема хранилища данных носит название «звезда» (star schema). Пример такой схемы приведен на рис. 4.
Рис. 4. Пример схемы «звезда»
Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка» (snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно соответствующие верхним уровням иерархии измерения и находящиеся в соотношении «один ко многим» в главной таблице измерений, соответствующей нижнему уровню иерархии, иногда называют консольными таблицами (outrigger table).
Пример схемы «снежинка» приведен на рис. 5.
Рис. 5. Пример схемы «снежинка»
Отметим, что даже при наличии иерархических измерений с целью повышения скорости выполнения запросов к хранилищу данных нередко предпочтение отдается схеме «звезда».
Однако не все хранилища данных проектируются по двум приведенным выше схемам. Так, довольно часто вместо ключевого поля для измерения, содержащего данные типа «дата», и соответствующей таблицы измерений сама таблица фактов может содержать ключевое поле типа «дата». В этом случае соответствующая таблица измерений просто отсутствует.
В случае несбалансированной иерархии (например, такой, которая может быть основана на таблице Employees базы данных Northwind, имеющей поле EmployeeID, которое одновременно является и первичным, и внешним ключом и отражает подчиненность одних сотрудников другим (см. рис. 1) в схему «снежинка» также следует вносить коррективы. В этом случае обычно в таблице измерений присутствует связь, аналогичная соответствующей связи в оперативной базе данных.
Еще один пример отступления от правил — наличие нескольких разных иерархий для одного и того же измерения. Типичные примеры таких иерархий — иерархии для календарного и финансового года (при условии, что финансовый год начинается не с 1 января), или с различными способами группировки членов измерения (например, группировать товары можно по категориям, а можно и по компаниям-поставщикам). В этом случае таблица измерений содержит поля для всех возможных иерархий с одними и теми же членами нижнего уровня, но с разными членами верхних уровней (пример такой таблицы приведен на рис. 3).
Как мы уже отмечали выше, таблица измерений может содержать поля, не имеющие отношения к иерархиям и представляющие собой просто дополнительные атрибуты членов измерений (member properties). Иногда такие атрибуты могут быть использованы при анализе данных.
Более подробно о проектировании хранилищ данных и одном из CASE-инструментов, способных упростить процесс их создания, — CA ERwin, рассказано в статье Сергея Маклакова «Хранилища данных и их проектирование с помощью CA ERwin», КомпьютерПресс, CD-ROM № 1’2001).
Следует сказать, что для создания реляционных хранилищ данных нередко применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Примером такого продукта является Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах (не по строкам, а по столбцам). Однако создавать хранилища можно и в обычных реляционных СУБД.
Итак, обсудив типичную структуру хранилища данных, на основе которых обычно строятся OLAP-кубы, вернемся к созданию OLAP-кубов и поговорим о том, какими бывают OLAP-инструменты.
Технические аспекты многомерного хранения данных
В многомерных хранилищах данных содержатся агрегатные данные различной степени подробности, например, объемы продаж по дням, месяцам, годам, по категориям товаров и т.п. Цель хранения агрегатных данных — сократить время выполнения запросов, поскольку в большинстве случаев для анализа и прогнозов интересны не детальные, а суммарные данные. Поэтому при создании многомерной базы данных всегда вычисляются и сохраняются некоторые агрегатные данные.
Отметим, что сохранение всех агрегатных данных не всегда оправданно. Дело в том, что при добавлении новых измерений объем данных, составляющих куб, растет экспоненциально (иногда говорят о «взрывном росте» объема данных). Если говорить более точно, степень роста объема агрегатных данных зависит от количества измерений куба и членов измерений на различных уровнях иерархий этих измерений. Для решения проблемы «взрывного роста» применяются разнообразные схемы, позволяющие при вычислении далеко не всех возможных агрегатных данных достичь приемлемой скорости выполнения запросов.
Как исходные, так и агрегатные данные могут храниться либо в реляционных, либо в многомерных структурах. Поэтому в настоящее время применяются три способа хранения данных:
MOLAP (Multidimensional OLAP) –— исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные. ROLAP (Relational OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально и находились. Агрегатные же данные помещают в специально созданные для их хранения служебные таблицы в той же базе данных. HOLAP (Hybrid OLAP) — исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных.Некоторые OLAP-средства поддерживают хранение данных только в реляционных структурах, некоторые — только в многомерных. Однако большинство современных серверных OLAP-средств поддерживают все три способа хранения данных. Выбор способа хранения зависит от объема и структуры исходных данных, требований к скорости выполнения запросов и частоты обновления OLAP-кубов.
Отметим также, что подавляющее большинство современных OLAP-средств не хранит «пустых» значений (примером «пустого» значения может быть отсутствие продаж сезонного товара вне сезона).
Технологии доступа к аналитическим службам из клиентских приложений
Пользователей аналитических служб можно условно разделить на две группы: администраторов, создающих или модифицирующих OLAP-кубы, и обычных пользователей-аналитиков, читающих данные из OLAP-кубов с целью создания аналитических отчетов. Эти группы используют разные технологии доступа к OLAP-данным. Ниже мы выясним, какие технологии предназначены для этих двух категорий пользователей.
Технологии интеллектуального анализа данных (ИАД)
Под ИАД следует понимать сложный анализ "очищенных" данных с использованием математических методов машинного обучения, таких как: статистические методы, нейронные сети, искусственный интеллект, генетические алгоритмы, деревья решений и т. д., а также, результаты их применения - методов представления данных. Смысл использования сложного анализа данных сведен к формулировке "получения новой информации из данных".
К информационным технологиям ИАД сегодня относятся:
I. Оперативный анализ данных
В основе концепции OLAP-систем лежит принцип многомерного представления данных: каждое числовое значение, содержащееся в ИХ, может иметь до нескольких десятков (сотен) атрибутов. Одним из существенных недостатков реляционной модели БД является невозможность объединять, просматривать и анализировать данные с точки зрения многомерности измерений, то есть наиболее понятным для аналитиков способом. С целью расширения функциональных возможностей традиционных реляционных СУБД следует включить многомерный анализ как одну из характеристик, так как: "реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в создании новой технологии разработки баз данных, а в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы автоматизировать интеллектуальную деятельность руководителя".
Многомерное представление данных представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению.
По типу используемой базы данных все OLAP-системы делятся на три класса:
1. Системы оперативной аналитической обработки многомерных баз данных (или MOLAP-системы), в которых данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:
1. гиперкубов - все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений;
2. поликубов - каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы.
2. Системы оперативной аналитической обработки реляционных баз данных (или ROLAP-системы) позволяют представлять данные в многомерной форме, обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных.
3. Гибридные системы оперативной аналитической обработки данных (Hybrid OLAP, HOLAP-системы) разработаны с целью совмещения достоинств и минимизации недостатков предыдущих систем. Они объединяют аналитическую гибкость и скорость ответа MOLAP-систем с постоянным доступом к реальным данным, свойственным ROLAP-системам.
II. Исследование данных (Data Mining)
Основная цель технологии – поиск и выявление в данных скрытые связи и взаимозависимости с целью наглядного предоставления их руководителю в процессе принятия решения. Технология включает в себя методы поиска новой информации в данных, подразумевающие использование математических алгоритмов (статистика, оптимизация, корреляция и др.), позволяющих находить эти зависимости и синтезировать дедуктивную информацию.
III. Извлечение знаний из баз данных (Knowledge Discovery in Databases)
Технология представляет новое направление в области ИАД, где процесс поиска закономерностей в данных рассматривается как процесс машинного обучения. Технология объединяет в себе вопросы моделирования закономерностей и зависимостей в базах данных и определяет математические методы построения систем "открытия" (извлечения, добычи) новых данных на основе методов классификации, кластеризации, построения деревьев решений и др.
Таким образом, основу СИППР составляет интегрированное сочетание технологии накопления и хранения данных на основе информационных хранилищ с технологией интеллектуального анализа данных. Концептуальная модель системы интеллектуальной поддержки принятия решений представлена на рисунке.
Основными компонентами концептуальной модели СИППР являются:
Информационное хранилище данных. Организуется на платформе мощной СУБД. Поскольку размеры хранилища могут достигать сотен гигабайт и больше, используемая СУБД должна поддерживать, технологию "больших баз данных" (VLDB, Very Large Database). Для организации БД хранилищ целесообразно использовать программные продукты таких производителей как: Microsoft, IBM, Oracle, Informics, Terradata и аналогичных.
Средства погружения данных. Сюда входят средства очищения, преобразования, синхронизации и агрегирования данных, предназначенные для объединения и трансформации данных, поступающих от внешних и внутренних источников, в целостную и взаимосвязанную информацию.
Одним из основных требований, предъявляемых к этим средствам, является обеспечение возможности доступа к различным источникам данных, что обеспечивается за счет использования универсального интерфейса доступа к данным (например, типа ODBC, OLE DB и т.д.).
Витрины данных. Витрины данных - это небольшие хранилища с упрощенной архитектурой, предназначенные для хранения небольшого подмножества данных и снятия нагрузки с основного ИХ предприятия.
Генераторы запросов, информационно-поисковые системы в области детализированных данных, нацеленных на поиск информации в реляционных СУБД. Общепризнанным стандартом языка манипулирования реляционными данными признан SQL. Информационно-поисковые системы, обеспечивающие интерфейс конечного пользователя в задачах поиска детализированной информации, могут использоваться в качестве надстроек, как над отдельными БД, так и над ИХ.
Рисунок 1. Концептуальная модель системы интеллектуальной поддержки принятия решений
Системы аналитической обработки агрегированных показателей. Предназначены для многомерного представления и последующего анализа данных. Системы ИАД и системы извлечения знаний из ИХ. Главными задачами являются поиск функциональных и логических закономерностей в накопленной информации, а также построение аналитических моделей и решающих правил, которые объясняют выявленные взаимосвязи и способны прогнозировать развитие бизнес-процессов. В связи с тем, что рассмотренные технологии определены сравнительно недавно и имеют тенденцию постоянного развития, строгого разграничения предметной области их применения не существует.
Следует отметить, что зарубежные страны занимают лидирующее положение в области разработок и внедрения во все жизненные сферы СППР, ориентированных на интеллектуальную обработку данных. Одними из немногих примеров информационных систем, реализующие методы ИАД, их предназначение и возможности являются:
Система "Darwin", разработанная компанией Thinking Machines (Бедфорд, шт. Массачусетс) позволяет строить модели на основе нейросетей и деревьев решений, а также использовать методы визуализации и классификации данных. Пакет "PowerPlay 5.0" фирмы Cognos - выполняет многомерный анализ данных, включающих до двух и более миллионов записей, в масштабе корпоративного предприятия (свыше 2000 пользователей). Система позволяет: построение трехмерных графиков и диаграмм, ранжирование данных, немедленный возврат к верхнему уровню иерархии данных и систем меню, полностью определяемых ЛПР. ROLAP-cистема "DSS Agent" компании MicroStrategy (Виенна, шт. Виргиния) представляет для построения ИХ интегрированный набор инструментов и методов объединения данных из разнородных источников. Проект "Pablo for Windows" фирмы Andyne Computing (Кингстон, Канада) представляет СППР, позволяющую просматривать обобщенные выборки на основе данных из реляционных баз данных и манипулировать ими. Программный пакет "Integrity Data Re-engineering Tool" производства компании Vality Technology. Представляет среду программирования, используемую для исследования, стандартизации и интегрирования данных из различных источников. "Integrity" выявляет новую информацию и наборы правил из оперативных данных, что позволяет разработчикам ИХ планировать и определять модели данных, которые бы правильно отображали сложности реального мира. Продукты хранения данных фирмы Red Brick Systems, позволяющие: быстро разрабатывать и устанавливать приложения для управления; строить запросы к БД любого размера с информацией, собранной от разнородных источников; обеспечивать наилучший доступ к обобщающей и детальной информации в единой базе данных. В качестве российских разработок следует отметить:
1. Нейронно-сетевой пакет "STATISTICA Neural Networks" компании StatSoft-Россия, предоставляющий возможность автоматически получать эффективные решения слабоструктурированных задач, в которых использование традиционных статистических методов является нерациональным.
В системе реализован полный набор архитектур сетей, алгоритмов обучения (методы обратного распространения, квази-ньютоновский, Левенберга-Маркара, Кохонена, квантования обучающего вектора и др.), мощные средства визуализации данных, помогающие оценивать качество работы сети и строить прогнозы. Кроме того, в систему заложены, генетические алгоритмы отбора входных данных, а также полный интерфейс прикладного программирования (API), позволяющий включать нейронные сети в другие приложения. На основе методов искусственного интеллекта реализован "Мастер решения задач", позволяющий автоматизировать выбор наилучшей архитектуры и построение сети.
2. Система "PolyAnalyst", представленная российской компанией Megaputer Intelligence в качестве инструментария для автоматического извлечения из данных решающих правил, зависимостей и других знаний, на основе которых могут приниматься управляющие решения.
В основе "PolyAnalyst" лежит набор методик и алгоритмов анализа данных - как традиционных, так и современных - метод автоматического обнаружения размытых нелинейных зависимостей и инструментарий построения произвольных нелинейных регрессионных моделей методами эволюционного программирования.
3. OLAP-средства, в качестве приложений, внедряют в свои системы такие лидеры российского информационного рынка как "1 C", "Парус" и другие.
Нельзя не отметить и нашедшие широкое распространение CASE-средства, предназначенные для разработки подобных систем. Большую популярность завоевал такой продукт как ERwin® 4.0 (http://www.interface.ru/fset.asp?Url=/ca/news/pr010124798.htm) – представляющий промышленный инструментарий для моделирования данных, разработанный для поддержки структурного подхода к управлению информацией.
Таким образом, в основе всех современных систем лежат различные математические методы теории машинного обучения или совокупность нескольких. На текущий момент проведение исследований в области машинного обучения с целью разработки новых и модернизации старых методов является наиболее альтернативным подходом для создания АСУ нового поколения – систем интеллектуальной поддержки принятия решений.
Технологии построения информационных хранилищ данных
Согласно классическому определению, информационное хранилище данных - это совокупность программно-аппаратных средств, позволяющих предоставлять данные в целостном виде для последующего анализа и принятия управляющих решений.
Идея, положенная в основу технологии ИХ, состоит в том, что проводить оперативный анализ непосредственно на базе оперативных информационных систем неэффективно. Вместо этого, все необходимые для анализа данные извлекаются из нескольких традиционных баз данных (в основном, реляционных), преобразуются и затем помещаются (или погружаются) в один источник данных - ИХ.
В процессе погружения данные:
очищаются - устранение ненужной информации; агрегируются - вычисление сумм, средних; трансформируются - преобразование типов данных, реорганизация структур хранения; объединяются из внешних и внутренних источников – приведение к единым форматам; синхронизируются - соответствие одному моменту времени.Сегодня, технологии построения ИХ являются основой для построения полноценных OLAP-систем и, соответственно, СППР, ориентированных на решение слабоструктурированных задач принятия решения, поскольку ИХ содержит данные, обладающие следующими свойствами:
Целостность и внутренняя взаимосвязь.Хотя данные погружаются из различных источников, но они объединены едиными законами именования, способами измерения атрибутов и т.д. Это имеет большое значение для корпоративных организаций, в которых одновременно могут эксплуатироваться различные по своей архитектуре вычислительные системы, представляющие одинаковые данные по-разному. Например, могут использоваться несколько различных форматов представления дат, или один и тот же показатель может называться различным образом, например, "вероятность доведения информации" и "вероятность получения информации". В процессе погружения подобные несоответствия устраняются автоматически.
Предметная ориентированность.Локальные базы данных содержат мегабайты информации, абсолютно не нужной для анализа (адреса, почтовые индексы, идентификаторы записей и т.п.).
Подобная информация не заносится в хранилище, что ограничивает спектр, рассматриваемых при принятии решения, данных до минимума.
Отсутствие временной привязки.
Оперативные системы охватывают небольшой интервал времени, что достигается за счет периодического архивирования данных. ИХ, напротив, содержит исторические данные, накопленные за большой интервал времени (года, десятилетия).
Доступность исключительно для чтения.
Модификация данных не производится, поскольку она может привести к нарушению целостности ИХ. Так как не требуется минимизировать время погружения, то структура хранилища может быть оптимизирована для обработки определенных запросов, что достигается за счет денормализации реляционной схемы, предварительного агрегирования и построения наиболее уместных индексов.
Таким образом, данные, погруженные в ИХ, организуясь в интегрированную целостную структуру, обладающую естественными внутренними связями, приобретают новые свойства, что придаст им статус информации.
Использование технологий ИХ стало возможно благодаря следующим факторам:
постепенное осознание руководящим звеном того, что в данных содержится не просто информация, а скрытые закономерности (знания), характеризующие процесс управления в целом, и способные повысить его эффективность;
снижение стоимости средств хранения информации дает возможность хранить данные, накопленные за длительные интервалы времени, с высокой степенью детализации;
снижение стоимости ЭВТ сложных архитектур;
переход от массового обслуживания к индивидуальному. Преобразования в области информационных и компьютерных технологий открыли возможности использования индивидуального подхода в проектировании и разработки систем в зависимости от их предназначения и решаемых задач, т.е. конкретных требований заказчика.
Однако, информационные хранилища данных представляют только перспективную архитектуру построения СИППР масштаба корпоративного предприятия и является центральной ее частью. Для построения полнофункциональной СИППР необходимы специальные программные средства, ориентированные на аналитические технологии обработки данных - технологии интеллектуального анализа данных (ИАД).
Тестовая задача
Чтобы проиллюстрировать относительные преимущества и недостатки описанных методов и систем, а также чтобы как-то оценить реальный экономический эффект от их применения, используем их для решения одной и той же задачи - управления портфелем из двух наиболее ликвидных акций российских предприятий - Мосэнерго (MSNG) и "Норильский никель" (NKEL). Рассмотрим такую упрощенную стратегию, при которой на каждую из этих акций отводится половина портфеля, и мы можем либо полностью продать все акции MSNG или NKEL, либо купить их на сумму, составляющую ровно половину от стоимости портфеля. Для выработки правил, определяющих условия, при которых акции нужно покупать или продавать с помощью рассмотренных методов, мы использовали историю рынка за период 1 сентября 1995 - 5 января 1997 гг. Для проверки полученной информации был взят период с 6 января 1997 по 28 февраля 1997 гг. Мы решали эту задачу при помощи следующих систем и методов:
· технический анализ - устранение тренда с оптимальной шириной окна; дерево решений (SIPINA);
· генетический алгоритм (GeneHunter);
· нейронная сеть - перцептрон с тремя скрытыми слоями и обратным распространением ошибки (NeuroShell);
· метод группового учета атрибутов (NeuroShell);
· метод "ближайшего соседа" (Unica); PolyAnalyst.
Применяя каждую систему, мы использовали установленные по умолчанию настроечные параметры, как это сделал бы пользователь-неспециалист. Разумеется, трудно делать какие-то надежные выводы по результатам решения одной задачи, однако эти результаты все же весьма показательны.
Чтобы оценить эффективность каждого из тестируемых методов, мы сравнивали доходность (измеряемую в процентах годовых) управления нашим портфелем с помощью полученных ими правил и доходность, которую мы получили бы, если бы просто держали эти акции в течение всего периода. Разница этих показателей для каждой методики в обучающем и тестовом периодах показана на рис. 1.
Рисунок 1.
Сравнительная доходность при использовании каждой методики.
График (рис. 1) очень ярко подтверждает мысль о том, что наличие контроля значимости получаемых правил - это одно из главных требований к системам анализа данных, применяемых к российским задачам. Например, видно, что нейронная сеть оказывается эффективной в период обучения, но показывает очень низкие результаты применительно к новым данным. При этом вполне возможно, что, варьируя многочисленные настроечные параметры нейросетевого алгоритма, можно получить значительно лучший результат, однако чрезвычайно сомнительно, чтобы это самостоятельно смог сделать человек, не являющийся специалистом по нейросетям. Это обстоятельство служит подтверждением второго тезиса о том, что реально применяемые для анализа российских финансовых и корпоративных данных системы должны быть высокоавтоматичны и не требовать сложной специальной настройки.
Для того чтобы оценить экономический эффект и окупаемость описываемых систем, приведем еще один график (рис. 2), который показывает разницу в долларах между управлением портфелем акций с начальной стоимостью 100 тыс. долл. в течение тестового периода с помощью построенной стратегии и удержанием акций без совершения каких-либо операций.
Рисунок 2.
Разница в управлении портфелем акций.
Видно, что для тех систем, которые показывают положительные результаты при решении этой задачи, характерное время окупаемости составляет от трех недель до месяца.
Результаты, полученные на тестовом примере, в целом подтверждают корректность сделанного выделения основных требований, определяющих успешность применения систем добычи данных к российским задачам. Как видно из рисунков, в этом примере положительные результаты были продемонстрированы тремя системами из семи (PolyAnalyst, Pattern Recognition Workbench, а также одним из стандартных методов технического анализа).
Типичная структура хранилищ данных
Как мы уже знаем, конечной целью использования OLAP является анализ данных и представление результатов этого анализа в виде, удобном для восприятия и принятия решений. Основная идея OLAP заключается в построении многомерных кубов, которые будут доступны для пользовательских запросов. Однако исходные данные для построения OLAP-кубов обычно хранятся в реляционных базах данных. Нередко это специализированные реляционные базы данных, называемые также хранилищами данных (Data Warehouse). В отличие от так называемых оперативных баз данных, с которыми работают приложения, модифицирующие данные, хранилища данных предназначены исключительно для обработки и анализа информации, поэтому проектируются они таким образом, чтобы время выполнения запросов к ним было минимальным. Обычно данные копируются в хранилище из оперативных баз данных согласно определенному расписанию.
Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это позволяет повысить скорость выполнения запросов), поэтому может допускать избыточность данных.
Для дальнейших примеров мы снова воспользуемся базой данных Northwind, входящей в комплекты поставки Microsoft SQL Server и Microsoft Access. Ее структура данных приведена на рис. 1.
Рис. 1. Структура базы данных Northwind
Основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables).
Вместо заключения, или "если очень хочется, то это только кажется"
Рассмотренные объективные факторы, имеющие экономические корни, конечно, существенно влияют на процесс внедрения систем KDD как нового продукта на рынке программного обеспечения. Но если даже указанные проблемы частично будут решены, останется еще ряд "подводных течений", часто субъективного плана, играющих не меньшую роль.
Действительно, основным сдерживающим фактором развития сферы аналитических услуг являлся низкий спрос. Платежеспособные потребители были слабо заинтересованы в получении эффективных решений - экономическая конъюнктура позволяла получать прибыль другими способами. Сейчас, казалось бы, изменился инвестиционный климат, появился спрос на аналитический консалтинг, более того, производителям и продавцам программного обеспечения есть что предложить - рынок, вроде бы, созрел и снизу, и сверху. Проблема, однако, не в том, чтобы предложить нужный инструмент - оказалось, что потенциальные пользователи не могут его взять.
Причина банальна. KDD не просто рыночный продукт - это идеология, способ мышления. Эффективное использование KDD невозможно без конкретного человека. Ситуацию с приобретением программного продукта, реализующего KDD, зачастую можно сравнить с покупкой правил игры в шахматы в комплекте с доской. А кто будет играть? И как долго учиться?
Сегодня ощущается явный технологический и системный разрыв между разработчиками и пользователями. Разрыв на уровне языка общения, общих понятий, подхода к проблеме. Например, системщик, формулируя на своем языке указанные в начале статьи экономические факторы, характеризующие специфику российского рынка, при построении и исследовании математической модели обязательно отметит:
· наличие на рынке нескольких взаимосвязанных систем, интересы которых могут не совпадать;
· наличие возмущений, помех, ошибок измерений и другого рода неопределенностей, о которых в ряде случаев известны лишь границы изменений, а какие-либо вероятностные характеристики отсутствуют;
· сами системы меняются со временем;
· возможность влияния на системы по принципу обратной связи;
· наличие запаздывания при передаче информации внутри системы и при воздействии на нее (кстати, при построении моделей и стратегий игры на фондовом рынке на основе KDD часто забывают о таких "пустяках", как комиссионные; учет времени регистрации ценных бумаг, которое может достигать нескольких недель, и т. д.).
Вся эта информация на первый взгляд может показаться лишней. Однако системы KDD часто как раз и оказываются эффективны в решении задач из плохо формализуемых предметных областей, где знания неточны, неполны, противоречивы и изменчивы, а значит, требуется и разработка специальных средств представления таких знаний, а также эффективных методов работы с ними. В реальной практике пользователь знает лишь, что хочет получить прибыль (KDD должны окупаться), но не может на системном уровне поставить задачу.
Что отсюда следует? Продвинутые предприниматели осознали, что KDD - реальный способ повышения эффективности работы. Вопрос не в том, нужны ли новые технологии, а в том, как их применить в каждом конкретном случае. Затраты на постановку задачи и сопровождение KDD могут на порядок превышать стоимость отдельного пакета программ: очевидно, что стоит потратить часть денег на обучение специалистов - в итоге выйдет дешевле и эффективнее. Возрастает роль специализированных консалтинговых фирм, осуществляющих комплексное сопровождение проектов, включая диагностику задачи, анализ методов решения, выработку рекомендаций, реализацию выбранного подхода, сопровождение, оптимизацию.
Внешние воздействия
Системы бизнес-интеллекта больше не ограничены выполнением внутренних функций. Они взаимодействуют со многими внешними для предприятия областями.
Наши респонденты подтверждали традиционные цели и функции для систем бизнес-интеллекта, например такие, как периодический репортинг для управленческого звена. В частности, согласно ответам 75% респондентов, "гибкий анализ по мере возникновения бизнес-проблем" является целью наивысшего приоритета для систем бизнес-аналитики.
Однако, весьма неожиданным фактом стала внешняя ориентация аналитических систем. Существенное количество компаний "поставляет информацию своим заказчикам в качестве обратной связи" (53%) и составляет отчеты для "поставщиков и бизнес-партнеров" (19%). Пользователи аналитических систем идут за пределы внутреннего управления, обеспечивая поддержку для заказчиков (43%), бизнес-партнеров (35%), поставщиков (21%) и дистрибуторов (17%). Доступ к среде хранилищ данных расширяется до "основанного на Web распространения информации для всех групп пользователей" (36%) и "персонализации информации для всех пользователей" (34%). Маркетинг (79%) и анализ отношений с заказчиками (70%) занимает почти такое же место, как и традиционные приложения бизнес-интеллекта, такие как финансовый анализ (82%) и анализ прибыльности (70%).
Введение в OLAP: часть Архитектура Microsoft Analysis Services
Что представляют собой аналитические службы
Что хранится в многомерной базе данных
Технологии доступа к аналитическим службам из клиентских приложений
SQL DSO
PivotTable Service, OLE DB for OLAP и ADO MD
Клиенты аналитических служб
Analysis Manager
Приложения Microsoft Office
Заключение
Службы преобразования данных
Репозитарий аналитических служб
В предыдущих статьях данного цикла (КомпьютерПресс № 4, 5’2001) мы рассказали об основах OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных, а также рассмотрели типичную структуру хранилищ данных и некоторые технические аспекты многомерного хранения данных. Настоящая статья посвящена типичной архитектуре OLAP-служб, рассматриваемой на примере Microsoft Analysis Services — OLAP-сервера фирмы Microsoft, входящего в комплект поставки Microsoft SQL Server 2000 Enterprise Edition и на сегодняшний день признанного аналитиками Gartner Group одним из наиболее популярных продуктов этого класса.
Введение в OLAP: часть Хранилища данных
Типичная структура хранилищ данных
Таблица фактов
Таблицы измерений
OLAP на клиенте и на сервере
Технические аспекты многомерного хранения данных
Заключение
Первая статья данного цикла (см. Введение в OLAP: часть 1. Основы OLAP) была посвящена основам OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных. В ней мы обсудили концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, относящиеся к многомерному анализу.
В настоящей статье мы рассмотрим типичную структуру хранилищ данных, поговорим о том, что представляет собой OLAP на клиенте и на сервере, а также обсудим некоторые технические аспекты многомерного хранения данных.
Введение в OLAP: часть Основы OLAP
Что такое хранилище данных
Что такое OLAP
Многомерные кубы
Некоторые термины и понятия
Заключение
В цикле статей "Введение в базы данных", публиковавшемся в последнее время (см. КомпьютерПресс #3/2000 — #3/2001), мы обсуждали различные технологии и программные средства, применяемые при создании информационных систем — настольные и серверные СУБД, средства проектирования данных, средства разработки приложений, а также Business Intelligence — средства анализа и обработки данных масштаба предприятия, которые в настоящее время становятся все более популярными в мире, в том числе и в нашей стране. Отметим, однако, что вопросы применения средств Business Intelligence и технологии, используемые при создании приложений такого класса, в отечественной литературе пока еще освещены недостаточно. В новом цикле статей мы попробуем восполнить этот пробел и рассказать о том, что представляют собой технологии, лежащие в основе подобных приложений. В качестве примеров реализации мы будем использовать в основном OLAP-технологии фирмы Microsoft (главным образом Analysis Services в Microsoft SQL Server 2000), но надеемся, что основная часть материала будет полезна и пользователям других средств.
Первая статья в данном цикле посвящена основам OLAP (On-Line Analytical Processing) — технологии многомерного анализа данных. В ней мы рассмотрим концепции хранилищ данных и OLAP, требования к хранилищам данных и OLAP-средствам, логическую организацию OLAP-данных, а также основные термины и понятия, применяемые при обсуждении многомерного анализа.
В данной статье мы ознакомились
В данной статье мы ознакомились с основами OLAP. Мы узнали следующее:
Назначение хранилищ данных— предоставление пользователям информации для статистического анализа и принятия управленческих решений. Хранилища данных должны обеспечивать высокую скорость получения данных, возможность получения и сравнения так называемых срезов данных, а также непротиворечивость, полноту и достоверность данных. OLAP (On-Line Analytical Processing) является ключевым компонентом построения и применения хранилищ данных. Эта технология основана на построении многомерных наборов данных — OLAP-кубов, оси которого содержат параметры, а ячейки — зависящие от них агрегатные данные. Приложения с OLAP-функциональностью должны предоставлять пользователю результаты анализа за приемлемое время, осуществлять логический и статистический анализ, поддерживать многопользовательский доступ к данным, осуществлять многомерное концептуальное представление данных и иметь возможность обращаться к любой нужной информации. Кроме того, мы рассмотрели основные принципы логической организации OLAP-кубов, а также узнали основные термины и понятия, применяемые при многомерном анализе. И наконец, мы выяснили, что представляют собой различные типы иерархий в измерениях OLAP-кубов.
В следующей статье данного цикла мы рассмотрим типичную структуру хранилищ данных, поговорим о том, что представляет собой клиентский и серверный OLAP, а также остановимся на некоторых технических аспектах многомерного хранения данных.
В данной статье мы рассмотрели типичную структуру реляционных хранилищ данных. Итак, теперь мы знаем, что:
типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД— как правило, она денормализована; основными составляющими структуры хранилищ данных являются таблица фактов (fact table) и таблицы измерений (dimension tables); таблица фактов является основной таблицей хранилища данных. Обычно она содержит сведения об объектах или событиях, совокупность которых будет в дальнейшем анализироваться; таблица фактов, как правило, содержит уникальный составной ключ, состоящий из первичных ключей таблиц измерений. При этом как ключевые, так и некоторые неключевые ее поля должны соответствовать будущим измерениям OLAP-куба. Помимо этого таблица фактов содержит одно или несколько числовых полей, на основании которых в дальнейшем вычисляются агрегатные данные; таблицы измерений содержат неизменяемые либо редко изменяемые данные — как правило, по одной записи для каждого члена нижнего уровня иерархии в измерении; таблицы измерений содержат как минимум одно описательное поле и, как правило, целочисленное ключевое поле для однозначной идентификации члена измерения; каждая таблица измерений должна находиться в отношении «один ко многим» с таблицей фактов; если каждое измерение содержится в одной таблице измерений, такая схема хранилища данных носит название «звезда». Если же хотя бы одно измерение содержится в нескольких связанных таблицах, такая схема хранилища данных носит название «снежинка». Далее мы обсудили особенности клиентских и серверных OLAP-средств. Мы узнали, что:
клиентские OLAP-средства представляют собой приложения, осуществляющие вычисление агрегатных данных (сумм, средних величин, максимальных или минимальных значений) и их отображение, при этом сами агрегатные данные содержатся в кэше внутри адресного пространства такого OLAP-средства; в серверных OLAP-средствах сохранение и изменение агрегатных данных, а также поддержка содержащего их хранилища осуществляются отдельным приложением или процессом, называемым OLAP-сервером; в случае применения серверных средств вычисление и хранение агрегатных данных происходят на сервере, что позволяет в общем случае снизить требования к ресурсам, потребляемым клиентским приложением, а также сетевой трафик и время выполнения запросов. наконец, мы рассмотрели различные технические аспекты многомерного хранения данных. Мы узнали, что в настоящее время применяются три способа хранения данных: MOLAP (Multidimensional OLAP) — и детальные, и агрегатные данные хранятся в многомерной базе данных. В этом случае многомерные данные полностью содержат исходные детальные данные; ROLAP (Relational OLAP) — детальные данные остаются в той же реляционной базе данных, где они находились изначально. Агрегатные же данные помещаются в специально созданные для их хранения служебные таблицы в той же самой базе данных; HOLAP (Hybrid OLAP) — детальные данные остаются в той же реляционной базе данных, где они и находились изначально, а агрегатные данные хранятся в многомерной базе данных.
В данной статье мы рассмотрели архитектуру аналитических служб Microsoft. Мы узнали, что:
основным компонентом аналитических служб является Analysis Server, представляющий собой сервис операционной системы Windows NT/2000 и предназначенный для создания OLAP-кубов и предоставления доступа к ним из клиентских приложений; аналитические службы Microsoft поддерживают все известные технологии многомерного хранения данных— Multidimensional OLAP, Relational OLAP и Hybrid OLAP; аналитические службы поддерживают получение вычисляемых агрегатных данных, создание коллективных измерений и виртуальных кубов. Далее, рассмотрев различные технологии доступа к OLAP-данным, мы узнали следующее:
для создания административных приложений следует применять Decision Support Objects (SQL DSO) — набор библиотек, в которых содержатся COM-объекты, позволяющие создавать и модифицировать многомерные базы данных и содержащиеся в них объекты, такие как кубы, коллективные измерения и т.д. SQL DSO можно использовать только для доступа к аналитическим службам Microsoft; приложения, предназначенные только для чтения OLAP-данных, для взаимодействия с аналитическими службами обязательно используют PivotTable Service — библиотеки, загружаемые в адресное пространство клиентского приложения и предназначенные для просмотра серверных OLAP-кубов, а также для создания, модификации и чтения локальных OLAP-кубов, созданных в клиентском приложении; для взаимодействия с PivotTable Service клиентское приложение может использовать OLE DB for OLAP — расширение универсального механизма доступа к данным OLE DB, позволяющее обращаться к многомерным данным, а также ADO MD — COM-серверы для доступа к многомерным данным, представляющие собой надстройку над OLE DB for OLAP и удобные для использования в клиентских приложениях. Спецификация OLE DB for OLAP является открытой. И наконец, мы кратко рассмотрели, какие клиентские утилиты можно использовать для доступа к аналитическим службам, а именно:
Analysis Manager, входящий в состав аналитических служб, предназначен для создания и модификации объектов многомерной базы данных и использует для этой цели библиотеки SQL DSO. С его помощью можно осуществлять и просмотр многомерных данных, для чего используется OLE DB for OLAP; нередко для просмотра OLAP-кубов применяются приложения Microsoft Office, в частности Microsoft Excel, а также ActiveX-компонент PivotTable List, входящий в состав Microsoft Office Web Components.
Защита доступа
Защита доступа к данным предприятия всегда была головной болью, но адекватная защита все же должна быть реализована. Двадцать четыре % компаний указали, что они имеют "чрезвычайно высокий" уровень защиты в своих системах бизнес-интеллекта; однако остальные 45 % указали, что они настоятельно желали бы достигнуть такого уровня. Другими словами, есть существенный разрыв между фактическими и желаемыми уровнями защиты доступа для бизнес-аналитических систем.
