Лекционный материал по ИИС для самостоятельного изучения. 2 Модели представления знаний 2 Логическая модель представления знаний
 Скачать 2.32 Mb.
|
|
Деревья решений. Деревья решений (decision trees) предназначены для решения задач классификации. Они создают иерархическую структуру классифицирующих правил типа «ЕСЛИ…ТО…» (if-then), имеющую вид дерева. Дерево решений состоит из узлов (рис.4.2), где производится проверка условия, и листьев– конечных узлов дерева, указывающих на класс (узлов решения). 134 Образование Имеется дом Доход > 5000 Выдать кредит Отказать Выдать кредит Высшее Среднее Специальное Нет Да Нет Возраст > 40 Да Да Нет … … … Рис. 2.6. Пример дерева решений. Дерево решений строится по определенному алгоритму. Наибольшее распространение получили алгоритмы CART и C4.5(C5.0). Искусственные нейронные сети (ИНС). Искусственные нейронные сети, в частности, многослойный персептрон, решают задачи регрессии и классификации. Однако, в отличие от дерева решений, нейронные сети не способны объяснять выдаваемое решение, поэтому их работа напоминает «черный ящик» со входами и выходами. Нейронные сети моделируют простые биологические процессы, аналогичные процессам, происходящим в человеческом мозге. ИНС способны к адаптивному обучению путем реакции на положительные и отрицательные воздействия. В основе их построения лежит элементарный преобразователь, называемый искусственным нейроном или просто нейроном по аналогии с его биологическим прототипом. 135 Структуру нейросети – многослойного персептрона (рис.4.3) - можно описать следующим образом. Нейросеть состоит из нескольких слоев: входной, внутренний (скрытый) и выходной слои. Входной слой реализует связь с входными данными, выходной – с выходными. Внутренних слоев может быть от одного и больше. В каждом слое содержится несколько нейронов. Все нейроны соединяются между собой связями, называемые весами. Вход 1 Вход 2 Вход N ∑ ∑ ∑ ∑ ∑ ∑ ∑ ∑ ∑ ∑ ∑ Выход 1 Выход 2 Выход M Входной слой Внутренние (скрытые) слои Выходной слой Рис.4.3. Многослойный персептрон. Перед использованием нейронной сети производится ее обучение, что представляет собой итерационный процесс настройки весовых коэффициентов. Для обучения применяются специальные алгоритмы. Наибольшее распространение получили градиентные методы обучения – алгоритм обратного распространения ошибки (Back Propagation), сопряженных градиентов, RProp и другие. Для проверки адекватности построенной нейронной сети используется специальный прием - тестовое подтверждение. Основное достоинство нейронных сетей состоит в том, что они моделируют сложные нелинейные зависимости между входными и выходными переменными. 136 Линейная регрессия. Линейная регрессия, как это следует из названия, решает задачи регрессии. Но она предназначена для поиска линейных зависимостей в данных. Если же зависимости нелинейные, то модель с использованием линейной регрессии может быть не построена вообще. Для этого лучше воспользоваться более универсальным методом нахождения зависимостей, например, искусственной нейронной сетью. Кластерный анализ. Главное назначение кластерного анализа – разбиение множества исследуемых объектов и признаков на однородные кластеры (группы). Большое достоинство кластерного анализа в том, что он позволяет производить разбиение объектов не по одному параметру, а по целому набору признаков. Кроме того, кластерный анализ в отличие от большинства математико-статистических методов не накладывает никаких ограничений на вид рассматриваемых объектов, и позволяет рассматривать множество исходных данных практически произвольной природы. Самоорганизующиеся карты. Самоорганизующиеся карты (Self Organizing Maps – SOM), или карты Кохонена, так же как и методы кластерного анализа, используются для решения задач кластеризации и сегментирования. Самоорганизующаяся карта является разновидностью нейронной сети. Ассоциативные правила. Ассоциативные правила (association rules) позволяют находить закономерности между связанными событиями, т.е . выявление ассоциаций. Примером ассоциативного правила, служит утверждение, что покупатель, приобретающий хлеб, приобретет и молоко с вероятностью 75%. Впервые эта задача была предложена для 137 поиска ассоциативных правил для нахождения типичных шаблонов покупок, совершаемых в супермаркетах, поэтому иногда ее еще называют анализом рыночной корзины (market basket analysis). Ассоциативные правила эффективно используются в сегментации покупателей по поведению при покупках, анализе предпочтений клиентов, планировании расположения товаров в супермаркетах, адресной рассылке. Классическим алгоритмом нахождения ассоциативных правил считается алгоритм APriori. Последовательные шаблоны. Последовательные шаблоны (sequential patterns) представляют собой закономерности между связанными во времени событиями. Алгоритмы последовательных шаблонов похожи на алгоритмы ассоциативных правил. Распространение получили AprioriAll и AprioriSome. 4.2. Хранилища данных Понятие и концепция хранилищ данных. Предпосылки появления ХД. Со временем в различных информационных системах начали аккумулироваться большие объемы данных – документы, сведения о банковских операциях, информация о клиентах, заключенных сделках, оказанных услугах и т. д. Постепенно возникло понимание того, что сбор данных не самоцель. Собранная информация может оказаться весьма полезной в процессе управления организацией, поиска путей совершенствования деятельности и получения посредством этого конкурентных преимуществ. Но для этого нужны системы, которые позволяли бы выполнять не только 138 простейшие действия над данными: подсчитывать суммы, средние, максимальные и минимальные значения. Появилась потребность в информационных системах, которые позволяли бы проводить глубокую аналитическую обработку, для чего необходимо решать такие задачи, как поиск скрытых структур и закономерностей в массивах данных, вывод из них правил, которым подчиняется данная предметная область, стратегическое и оперативное планирование, формирование нерегламентированных запросов, принятие решений и прогнозирование их последствий. Понимание преимуществ, которые способен дать интеллектуальный анализ, привело к появлению нового класса информационных систем – систем поддержки принятия решений (СППР), ориентированных на аналитическую обработку данных с целью получения знаний, необходимых для разработки решений в области управления. Дополнительным стимулом совершенствования этих систем стали такие факторы, как снижение стоимости высокопроизводительных компьютеров и расходов на хранение больших объемов информации, появление возможности обработки больших массивов данных и развитие соответствующих математических методов. Обобщенная структурная схема системы СППР представлена на рис. 4.4. 139 Рис.4.4. Структура СППР. С СППР используются специализированные базы данных, которые называются хранилищами данных (ХД). Хранилища данных ориентированы на аналитическую обработку и удовлетворяют требованиям, предъявляемым к системам поддержки принятия решений. В настоящее время однозначного определения ХД не существует, из-за того что разработано большое количество различных архитектур и технологий ХД, а сами хранилища используются для решения самых разнообразных задач. Каждый автор вкладывает в это понятие свое видение вопроса. Обобщая требования, предъявляемые к СППР, можно дать следующее определение ХД, которое не претендует на полноту и однозначность, но позволяет понять основную идею. Хранилище данных - разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивость и хронологию данных, а также высокую скорость выполнения аналитических запросов. 140 Применительно к решению бизнес-задач, хранилище данных – это специальным образом систематизированная информация из разнородных источников (базы данных учетных систем компании, маркетинговые данные, мнения клиентов, исследования конкурентов и т.п.), необходимая для обработки с целью принятия стратегически важных решений в деятельности компании. Для того чтобы получить качественный прогноз, нужно собрать максимум информации об исследуемом процессе, описывающей его с разных сторон. Например, для прогнозирования объемов продаж может потребоваться различная и разнородная следующая информация (рис.2.2). Рис. 4.5. Хранилище данных Типичное ХД существенно отличается от обычных систем хранения данных (баз данных). Главным отличием являются цели их создания и использования. База данных играет роль помощника в оперативном управлении организации. Это каждодневные задачи получения актуальной информации: бухгалтерской отчетности, учета договоров и т.д. В свою очередь 141 хранилище данных консолидирует всю необходимую информацию для осуществления задач стратегического управления в среднесрочном и долгосрочном периоде. Например, продажа товара и выписка счета производятся с использованием базы данных, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, — с помощью хранилища данных. Другое важное отличие заключается в динамике изменения данных. Базы данных в OLTP-системах характеризуются очень высокой динамикой изменения записей из-за повседневной работы большого числа пользователей (откуда, кстати, велика вероятность появления противоречий, ошибок, нарушения целостности данных и т. д.). Что касается ХД, то данные из него не удаляются, а пополнение происходит в соответствии с определенным регламентом (раз в час, день, неделю, в определенное время). Важнейшим элементом ХД является семантический слой – механизм, позволяющий аналитику оперировать данными посредством бизнес-терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных. Основные положения концепции ХД. Принято считать, что у истоков концепции ХД стоял технический директор компании Prism Solutions Билл Инмон, который в начале 1990-х г. опубликовал ряд работ, ставших основополагающими для последующих исследований в области аналитических систем. Б. Инмон дал следующее определение ХД: предметно- ориентированный, интегрированный, неизменяемый и 142 поддерживающий хронологию набор данных, предназначенный для обеспечения принятия управленческих решений. В основе концепции хранилищ данных лежат следующие положения (принципы): Предметная ориентированность. В данном случае подразумевается, что ХД должно разрабатываться с учетом специфики конкретной предметной области, а не аналитических приложений, с которыми его предполагается использовать. Структура ХД должна отражать представления аналитика об информации, с которой ему приходится работать. Интегрированность означает, что должна быть обеспечена возможность загрузки в ХД информации из источников, поддерживающих различные форматы данных и созданных в различных приложениях – учетных системах, базах данных, электронных таблицах и других офисных приложениях, поддерживающих структурированность данных (например, текстовые файлы с разделителями). При этом данные, допускающие различный формат (например, числа, дата и время), в процессе загрузки должны быть преобразованы к единому представлению. Кроме того, очень важно проверить загружаемые данные на целостность и непротиворечивость, обеспечить необходимый уровень их обобщения (агрегирования). Объем данных в хранилище должен быть достаточным для эффективного решения аналитических задач, поэтому в ХД может накапливаться информация за несколько лет и даже десятилетий. Принцип неизменчивости предполагает, что, в отличие от обычных систем оперативной обработки данных, в ХД 143 данные после загрузки не должны подвергаться каким-либо изменениям, за исключением добавления новых данных. Поддержка хронологии означает соблюдение порядка следования записей, для чего в структуру ХД вводятся ключевые атрибуты Дата и Время. Кроме того, если физически упорядочить записи в хронологическом порядке, например в порядке возрастания атрибута Дата, можно уменьшить время выполнения аналитических запросов. Основные требования к ХД. Чтобы ХД выполняло функции, соответствующие его основной задаче – поддержке процесса анализа данных, – оно должно удовлетворять требованиям, сформулированным одним из авторов концепции ХД – Р. Кимбаллом: высокая скорость получения данных из хранилища; автоматическая поддержка внутренней непротиворечивости данных; возможность получения и сравнения срезов данных; наличие удобных средств для просмотра данных в хранилище; обеспечение целостности и достоверности хранящихся данных. Чтобы соблюсти все перечисленные требования, для построения и работы ХД, как правило, используется не одно приложение, а система, в которую входит несколько программных продуктов. Одни из них представляют собой собственно систему хранения данных, другие – средства их просмотра, извлечения, загрузки и т. д. 144 Архитектуры хранилищ данных. Разработка и построение корпоративного ХД – это дорогостоящая и трудоемкая задача. Успешность внедрения ХД во многом зависит от уровня информатизации бизнес- процессов в компании, установившихся информационных потоков, объема и структуры используемых данных, требований к скорости выполнения запросов и частоте обновления хранилища, характера решаемых аналитических задач и т. д. Чтобы приблизить ХД к условиям и специфике конкретной организации, в настоящее время разработано несколько архитектур хранилищ: многомерные, реляционные, гибридные виртуальные. Многомерные ХД реализуют многомерное представление данных на физическом уровне в виде многомерных кубов. Данная технология получила название MOLAP – Multidimensional OLAP. Реляционные ХД используют классическую реляционную модель, характерную для оперативных регистрирующих OLTP-систем. Данные хранятся в реляционных таблицах, но образуют специальные структуры эмулирующие многомерное представление данных. Такая технология обозначается аббревиатурой ROLAP – Relational OLAP. Гибридные ХД сочетают в себе свойства как реляционной, так и многомерной моделей данных. В гибридных ХД детализированные данные хранятся в реляционных таблицах, а агрегаты – в многомерных кубах. Такая технология построения ХД называется HOLAP – Hybrid OLAP. 145 Виртуальные ХД не являются хранилищами данных в привычном понимании. В таких системах работа ведется с отдельными источниками данных, но при этом эмулируется работа обычного ХД. Иначе говоря, данные не консолидируются физически, а собираются непосредственно в процессе выполнения запроса. Кроме того, все ХД можно разделить на одноплатформенные и кросс-платформенные. Одноплатформенные ХД строятся на базе только одной СУБД, а кросс-платформенные могут строиться на базе нескольких СУБД. Многомерные хранилища данных. Многомерная модель данных, лежащая в основе построения многомерных хранилищ данных (МХД), опирается на концепцию многомерных кубов, или гиперкубов. Они представляют собой упорядоченные многомерные массивы, которые также часто называют OLAP-кубами (аббревиатура OLAP расшифровывается как On-Line Analytical Processing - оперативная аналитическая обработка). Технология OLAP представляет собой методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов. Не следует пытаться провести геометрическую интерпретацию понятия «многомерный куб», поскольку это просто служебный термин, описывающий метод представления данных. В основе многомерного представления данных лежит их разделение на две группы – измерения и факты. Измерения – это категориальные атрибуты, наименования и свойства объектов, участвующих в 146 некотором бизнес-процессе. Измерениями являются наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т. д. Измерения могут быть и числовыми, если какой-либо категории (например, наименованию товара) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора. Измерения качественно описывают исследуемый бизнес- процесс. Факты – это данные, количественно описывающие бизнес-процесс, непрерывные по своему характеру, то есть они могут принимать бесконечное множество значений. Примеры фактов – цена товара или изделия, их количество, сумма продаж или закупок, зарплата сотрудников, сумма кредита, страховое вознаграждение и т. д. Структура многомерного куба. Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например, Дата, Товар, Город, а фактами - числовые значения, соответствующие этим измерениям. Принцип организации многомерного куба поясняется на рис.4.6. В такой системе каждому набору значений измерений (например, дата – товар – покупатель) будет соответствовать ячейка, в которой размещаются числовые показатели (то есть факты), связанные с данным набором. Таким образом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь. Например в одной ячейке будут располагаться факты, относящиеся к продаже Товара2 во Владивостоке в декабре месяце. 147 Рис. 4.6. Данные в трехмерном кубе. Кроме того, куб позволяет реализовать сечения данных. Сечение заключается в выделении подмножества ячеек гиперкуба при фиксировании значения одного или нескольких измерений. В результате сечения получается срез или несколько срезов, каждый из которых содержит информацию, связанную со значением измерения, по которому он был построен. Например, если выполнить сечение по значению «г. Москва» измерения Город, то полученный в результате срез будет содержать информацию об истории продаж всех товаров, которую можно будет свести в плоскую таблицу. При необходимости ограничить информацию только одним товаром (например, Товаром 2) потребуется выполнить еще одно сечение, но теперь уже по значению Товар 2 измерения Товар. Результатом построения двух срезов будет информация о продажах в одном городе одного товара. Манипулируя таким образом сечениями гиперкуба, пользователь всегда может получить информацию в нужном разрезе. Затем на основе построенных срезов может быть сформирована кросс-таблица (рис 4.7), и с ее помощью очень быстро получен необходимый отчет. Данная методика лежит в основе технологии OLAP-анализа. 148 Рис. 4.7. Пример многомерного отчета. Таким образом, информация в многомерном хранилище данных является логически целостной. Это уже целостные структуры типа «кому, что и в каком количестве было продано на данный момент времени». Преимущества многомерного подхода к организации данных очевидны. Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД. Возможность построения более широкого спектра аналитических запросов. В некоторых случаях использование многомерной модели позволяет значительно уменьшить продолжительность поиска в ХД, обеспечивая выполнение аналитических запросов практически в режиме реального времени. Это связано с тем, что агрегированные данные 149 вычисляются предварительно и хранятся в многомерных кубах вместе с детализированными, поэтому тратить время на вычисление агрегатов при выполнении запроса уже не нужно. Использование многомерной модели данных сопряжено с определенными трудностями. Так, для ее реализации требуется больший объем памяти. Это связано с тем, что при реализации физической многомерности используется большое количество технической информации, поэтому объем данных, который может поддерживаться МХД, обычно не превышает нескольких десятков гигабайт. Кроме того, многомерная структура труднее поддается модификации; при необходимости встроить еще одно измерение требуется выполнить физическую перестройку всего многомерного куба. На основании этого можно сделать вывод, что применение систем хранения, в основе которых лежит многомерное представление данных, целесообразно только в тех случаях, когда объем используемых данных сравнительно невелик, а сама многомерная модель имеет стабильный набор измерений. Реляционные хранилища данных. Применение реляционной модели при создании ХД в ряде случаев позволяет получить преимущества над многомерной технологией, особенно в части эффективности работы с большими массивами данных и использования памяти компьютера. На основе реляционных хранилищ данных (РХД) строятся ROLAP-системы (Relational OLAP). В основе технологии РХД лежит принцип, в соответствии с которым измерения хранятся в плоских таблицах так же, как и в обычных реляционных СУБД, а 150 факты (агрегируемые данные) – в отдельных специальных таблицах этой же базы данных. При этом таблица фактов является основой для связанных с ней таблиц измерений. Она содержит количественные характеристики объектов и событий, совокупность которых предполагается в дальнейшем анализировать. Схемы построения РХД.На логическом уровне различают две схемы построения РХД – «звезда» и «снежинка». При использовании схемы «звезда» центральной является таблица фактов, с которой связаны все таблицы измерений. Таким образом, информация о каждом измерении располагается в отдельной таблице, что упрощает их просмотр, а саму схему делает логически прозрачной и понятной пользователю (рис. 4.8). Рис.4.8. Схема построения РХД «звезда». 151 Однако размещение всей информации об измерении в одной таблице оказывается не всегда оправданным. Например, если продаваемые товары объединены в группы (имеет место иерархия), то придется тем или иным способом показать, к какой группе относится каждый товар, что приведет к многократному повторению названий групп. Это не только вызовет рост избыточности, но и повысит вероятность возникновения противоречий (если, например, один и тот же товар ошибочно отнесут к разным группам). К преимуществам схемы «звезда» можно отнести: простоту и логическую прозрачность модели; более простую процедуру пополнения измерений, поскольку приходится работать только с одной таблицей. Недостатками схемы «звезда» являются: медленная обработка измерений, поскольку одни и те же значения измерений могут встречаться несколько раз в одной и той же таблице; высокая вероятность возникновения несоответствий в данных (в частности, противоречий), например, из-за ошибок ввода. Для более эффективной работы с иерархическими измерениями была разработана модификация схемы «звезда», которая получила название «снежинка». Главным отличием схемы «снежинка» является то, что информация об одном измерении может храниться в нескольких связанных таблицах. То есть если хотя бы одна из таблиц измерений имеет одну или несколько связанных с ней других таблиц 152 измерений, в этом случае будет применяться схема «снежинка» (рис. 4.9). Рис.4.9. Схема построения РХД «снежинка». Основное функциональное отличие схемы «снежинка» от схемы «звезда» – это возможность работы с иерархическими уровнями, определяющими степень детализации данных. В приведенном примере схема «снежинка» позволяет работать с данными на уровне максимальной детализации, например, с каждым товаром отдельно, или использовать обобщенное представление по группам товаров с соответствующей агрегацией фактов. Выбор схемы для построения РХД зависит от используемых механизмов сбора и обработки данных. Каждая из схем имеет свои преимущества и недостатки, которые, однако, могут проявляться в большей или меньшей степени в зависимости от особенностей функционирования ХД в целом. 153 Преимуществами схемы «снежинка» являются: она ближе к представлению данных в многомерной модели; процедура загрузки из РХД в многомерные структуры более эффективна и проста, поскольку загрузка производится из отдельных таблиц; намного ниже вероятность появления ошибок, несоответствия данных; большая, по сравнению со схемой «звезда», компактность представления данных, поскольку все значения измерений упоминаются только один раз. Недостатки схемы «снежинка»: достаточно сложная для реализации и понимания структура данных; усложненная процедура добавления значений измерений. Кроме того, существует ряд технических особенностей, которые могут определить предпочтения разработчиков РХД при выборе схемы его построения. Основные преимущества РХД: практически неограниченный объем хранимых данных; поскольку реляционные СУБД лежат в основе построения многих систем оперативной обработки (OLTP), которые обычно являются главными источниками данных для ХД, использование реляционной модели позволяет упростить процедуру загрузки и интеграции данных в хранилище; при добавлении новых измерений данных нет необходимости выполнять сложную физическую 154 реорганизацию хранилища в отличие, например, от многомерных ХД; обеспечиваются высокий уровень защиты данных и широкие возможности разграничения прав доступа. Главный недостаток РХД заключается в том, что при использовании высокого уровня обобщения данных и иерархичности измерений в таких хранилищах начинают «размножаться» таблицы агрегатов. В результате скорость выполнения запросов реляционным хранилищем замедляется. В то же время в многомерных хранилищах, где данные хранятся в виде многомерных кубов, эта проблема практически не возникает, и в большинстве случае удается достичь более высокой скорости выполнения запросов. Таким образом, выбор реляционной модели при построении ХД целесообразен в следующих случаях. Значителен объем хранимых данных (многомерные ХД становятся неэффективными). Иерархия измерений несложная (то есть немного агрегированных данных). Требуется частое изменение размерности данных. При использовании реляционной модели можно ограничиться добавлением новых таблиц, а для многомерной модели придется выполнять сложную перестройку физической структуры хранилища. Гибридные хранилища данных. Многомерная и реляционная модели хранилищ данных имеют свои преимущества и недостатки. Например, многомерная модель позволяет быстрее получить ответ на запрос, но не дает возможности эффективно управлять такимиже большими объемами данных, как реляционная модель. Логично было бы 155 использовать такую модель ХД, которая представляла бы собой комбинацию реляционной и многомерной моделей и позволяла бы сочетать высокую производительность, характерную для многомерной модели, и возможность хранить сколь угодно большие массивы данных, присущую реляционной модели. Такая модель, сочетающая в себе принципы реляционной и многомерной моделей, получила название гибридной, или HOLAP (Hybrid OLAP). Хранилища данных, построенные на основе HOLAP, называются гибридными хранилищами данных (ГХД) (рис.4.10). Рис.4.10 Гибридное ХД. Главным принципом построения ГХД является то, что детализированные данные хранятся в реляционной структуре (ROLAP), которая позволяет хранить большие объемы 156 данных, а агрегированные данные – в многомерной (MOLAP), которая позволяет увеличить скорость выполнения запросов (поскольку при выполнении аналитических запросов уже не требуется вычислять агрегаты). Пример. В супермаркете, ежедневно обслуживающем десятки тысяч покупателей, установлена регистрирующая OLTP-система. При этом максимальному уровню детализации регистрируемых данных соответствует покупка по одному чеку, в котором указываются общая сумма покупки, наименования или коды приобретенных товаров и стоимость каждого товара. Оперативная информация, состоящая из детализированных данных, консолидируется в реляционной структуре ХД. С точки зрения анализа представляют интерес обобщенные данные, например, по группам товаров, отделам или некоторым интервалам дат. Поэтому исходные детализированные данные агрегируются, и вычисленные агрегаты сохраняются в многомерной структуре гибридного ХД. Если данные из OLTP-системы имеют большой объем (несколько десятков тысяч записей в день и более) и высокую степень детализации, а для анализа используются в основном обобщенные данные, гибридная архитектура хранилища оказывается наиболее подходящей. Преимущества гибридного хранилища данных. Хранение данных в реляционной структуре делает их в большей степени системно-независимыми, что особенно важно при использовании в управлении предприятием экономической информации (показателей). Реляционная структура формирует устойчивые и непротиворечивые опорные точки для многомерного хранилища. 157 Поскольку реляционное хранилище поддерживает актуальность и корректность данных, оно обеспечивает очень надежный транспортный уровень для доставки информации в многомерное хранилище. Недостатком гибридной модели является усложнение администрирования ХД из-за более сложного регламента его пополнения, поскольку при этом необходимо согласовывать изменения в реляционной и многомерной структурах. Виртуальные хранилища данных. Неизбежной проблемой при использовании хранилищ данных в корпоративных аналитических системах является избыточность. Она снижает эффективность использования дискового пространства и оперативной памяти компьютерной системы, а при очень больших объемах хранящейся и обрабатываемой информации может вызвать снижение производительности, возрастание времени ожидания отклика на запрос и даже привести к полной неработоспособности системы. Избыточность в той или иной степени характерна как для реляционных, так и для многомерных хранилищ. Ситуация усугубляется еще и тем, что ХД хранят историческую информацию и реализуют принцип неизменчивости данных. То есть в отличие от обычных систем оперативной обработки (OLTP-систем), где хранятся лишь актуальные данные, а данные, утратившие актуальность, уничтожаются, ХД могут только пополняться новыми данными, а удаление исторических данных не производится. Кроме того, часто требуется хранить большие объемы агрегированных данных. В совокупности эти факторы могут привести к «взрывному» росту объемов ХД. 158 Преодолеть проблему избыточности и даже свести ее к нулю можно путем использования виртуальных хранилищ данных (ВХД). В основе концепции виртуального ХД лежит принцип, в соответствии с которым данные из локальных источников, внешнего окружения, баз данных и учетных систем не консолидируются в единое ХД физически, а извлекаются, преобразуются и интегрируются непосредственно при выполнении запроса в оперативной памяти ПК. Фактически запросы адресуются непосредственно к источникам данных. Виртуальным хранилищем данных – это система, которая работает с разрозненными источниками данных и эмулирует работу обычного хранилища данных, извлекая, преобразуя и интегрируя данные непосредственно в процессе выполнения запроса. При работе с ВХД пользователь, можно сказать, имеет дело с «иллюзией» хранилища данных (рис.4.11). Виртуальность предполагает, что ВХД существует только до тех пор, пока работает соответствующее приложение. Как только оно завершает работу, виртуальное хранилище прекращает существование. 159 Рис.4.11 Виртуальное ХД. Преимущества виртуального хранилища данных. Минимизируется объем требуемой дисковой и оперативной памяти, поскольку отсутствует необходимость хранения исторических данных и многочисленных агрегированных данных для различных уровней обобщения информации. Наличие в ВХД развитого семантического слоя позволяет аналитику полностью абстрагироваться от проблем, связанных с процессом извлечения данных из разнообразных источников, и сосредоточиться на решении задач анализа данных. Появляется возможность анализа данных в OLTP- системе сразу после их поступления без ожидания загрузки в хранилище. 160 Однако концепция ВХД имеет ряд недостатков по сравнению с ХД, где информация консолидируется физически. Источники данных, информация из которых запрашивается в ВХД, могут оказаться недоступными, если доступ к ним осуществляется по сети или если изменилось место их локализации. Временная недоступность хотя бы одного из источников может привести к невозможности выполнения запроса или к искажению представленной по нему информации. Отсутствует автоматическая поддержка целостности и непротиворечивости данных, могут быть утеряны отдельные фрагменты документов и т. д. Данные в источниках хранятся в различных форматах и кодировках, что может привести к ошибкам при их обработке и к искажению информации, полученной в ответ на запрос. Например, если в текстовых файлах с разделителями используются неоднотипные разделители или в файле Excel данные в одном столбце не являются типизированными, это, скорее всего, приведет к неправильной работе аналитических алгоритмов. Из-за возможной несогласованности моментов пополнения источников данных и из-за отсутствия поддержки в них хронологии по одному и тому же запросу в различные моменты времени могут быть получены отличающиеся данные. Практически невозможна работа с историческими данными, поскольку в ВХД доступны только те данные, которые находятся в источниках в конкретный момент времени. 161 Поскольку некоторые типы источников данных не оптимизированы по скорости доступа к ним, извлечение данных из них занимает определенное время, что снижает скорость выполнения запросов виртуальными хранилищами. Пример. Устоявшейся практикой при использовании ХД является ночная загрузка собранных за день данных из OLTP- систем. Такой регламент позволяет уменьшить нагрузку на OLTP-систему в период ее активного использования. Однако подобная практика не обеспечивает возможности анализировать информацию в течение рабочего дня. Использование ВХД снимает эту проблему, поскольку такое хранилище не требует загрузки данных, а может предоставить актуальную информацию по первому требованию. Таким образом, применение ВХД оказывается полезным для предприятий, которые не имеют технических средств и квалифицированного персонала для поддержки физических ХД. Особенно велики преимущества ВХД при необходимости анализировать самую свежую информацию. В ВХД отсутствует этап загрузки данных, поэтому временной интервал между появлением информации в OLTP- системе и ее готовностью к анализу данных минимален. При этом следует учитывать, что, поскольку ВХД поддерживает историческую информацию только за период актуальности OLTP-систем, применение такого хранилища оправданно лишь тогда, когда исторические данные для анализа не требуются. 162 4.3. Средства реализации интеллектуального анализа данных Программное обеспечение в области интеллектуального анализа данных. Даже самые мощные технологии извлечения закономерностей и машинного обучения, такие как KDD и Data Mining, не представляют особой ценности без инструментальной поддержки в виде соответствующего программного обеспечения. Рынок программных средств продолжает формироваться по сей день, однако в этой области уже можно выделить некоторые стандарты де-факто. Рынок программного обеспечения KDD и Data Mining делится на несколько сегментов (рис.4.12). Рис.4.12 Классификация ПО в области Data Mining и KDD. Статистические пакеты с возможностями Data Mining и настольные Data Mining пакеты ориентированы в основном на профессиональных пользователей. Их отличительные особенности: 163 слабая интеграция с промышленными источниками данных; бедные средства очистки, предобработки и трансформации данных; отсутствие гибких возможностей консолидации информации, например, в специализированном хранилище данных; конвейерная (поточная) обработка новых данных затруднительна или реализуется встроенными языками программирования и требует высокой квалификации; из-за использования пакетов на локальных рабочих станциях обработка больших объемов данных затруднена. Настольные Data Mining пакеты могут быть ориентированы на решение всех классов задач Data Mining или какого-либо одного, например кластеризации или классификации. Вместе с тем эти пакеты предоставляют богатые возможности в плане алгоритмов, что достаточно для решения исследовательских задач. Недостатком пакетов является невозможность создания прикладных решений промышленного уровня. СУБД с элементами Data Mining. Практически все крупные производители систем управления базами данных (СУБД) включают в состав своих продуктов средства для анализа данных, OLAP, а также поддержку хранилищ данных. Эти инструменты как бы «встраиваются» в СУБД. Отличительные особенности СУБД с элементами Data Mining: высокая производительность; 164 алгоритмы анализа данных по максимуму используют преимущества СУБД; жесткая привязка всех технологий анализа к одной СУБД; сложность в создании прикладных решений, поскольку работа с СУБД ориентирована на программистов и администраторов баз данных. Аналитические платформы. В отличие от СУБД с набором алгоритмов Data Mining, аналитические платформы изначально ориентированы на анализ данных и предназначены для создания готовых решений промышленного уровня. Они позволяют наиболее полно реализовать все этапы KDD. Аналитическая платформа — специализированное программное решение (или набор решений), которое содержит в себе все инструменты для извлечения закономерностей из «сырых» данных: средства консолидации информации в едином источнике (хранилище данных), извлечения, преобразования, трансформации данных, алгоритмы Data Mining, средства визуализации и распространения результатов среди пользователей, а также возможности «конвейерной» обработки новых данных. Отличительные особенности аналитических платформ: в аналитической платформе, как правило, всегда присутствуют гибкие и развитые средства консолидации (создание ХД); наличие средств импорта данных из широкого спектра различных источников; наличие средств интеграции с промышленными источниками данных; 165 обязательное наличие инструментов очистки и преобразования структурированных данных; хранение данных в едином источнике — в хранилище данных; наличие репозитария моделей, описывающих выявленные закономерности, правила и прогнозы; широкий спектр алгоритмов Data Mining; развитый инструментарий визуализации данных и результатов анализа (моделирования). На рис. 2 изображена типовая схема системы ИАД на базе аналитической платформы. Вообще говоря, приведенную на рис.4.13 систему можно построить с использованием нескольких программных решений, например, разделить функции извлечения/загрузки, OLAP-отчетности, хранилища данных, Data Mining между различным программным обеспечением. Но чтобы эти отдельные компоненты превратились в полноценную аналитическую систему, необходимо произвести интеграцию между ними на уровне обмена данными, а еще лучше — метаданными. 166 Рис.4.13 Типовая схема системы ИАД на базе аналитической платформы. Аналитическая платформа Deductor. Аналитическая платформа Deductor является одним из программных продуктов, реализующих методы ИАД. Аналитическая платформа Deductor разработана отечественной фирмой BaseGroup Labs г. Рязань (www.basegpoup.ru). Первая версия Deductor увидела свет в 2000 г. и с тех пор идет непрерывное развитие платформы. В 2007 г. выпущена пятая по счету версия системы, в 2009 г. – версия 5.2. 167 Сегодня Deductor – это яркий представитель как настольной, так и корпоративной системы анализа данных последнего поколения. Аналитическая платформа Deductor состоит из пяти частей: Deductor Warehouse – многомерное хранилище данных, аккумулирующее всю необходимую для анализа предметной области информацию. Использование единого хранилища позволяет обеспечить непротиворечивость данных, их централизованное хранение и автоматически обеспечивает всю необходимую поддержку процесса анализа данных. Deductor Warehouse оптимизирован для решения именно аналитических задач, что положительно сказывается на скорости доступа к данным. Предназначен для аналитика. Deductor Studio – программа, реализующая функции импорта, обработки, визуализации и экспорта данных. Deductor Studio может функционировать и без хранилища данных, получая информацию из любых других источников, но наиболее оптимальным является их совместное использование. В Deductor Studio включен полный набор механизмов, позволяющий получить информацию из произвольного источника данных, провести весь цикл обработки (очистку, трансформацию данных, построение моделей), отобразить полученные результаты наиболее удобным образом (OLAP, диаграммы, деревья…) и экспортировать результаты на сторону. Это полностью соответствует концепции извлечения знаний из баз данных (KDD). Позволяет пройти все этапы построения прикладного решения. Предназначен для аналитика. 168 Deductor Viewer – рабочее место конечного пользователя. Позволяет отделить процесс построения моделей от использования уже готовых моделей. Все сложные операции по подготовке моделей выполняются аналитиками-экспертами при помощи Deductor Studio, а Deductor Viewer обеспечивает пользователям простой способ работы с готовыми результатами, скрывает от них все сложности построения моделей и не предъявляет высоких требований к квалификации сотрудников. Является средством тиражирования знаний, т.е. когда построенные аналитиком модели используют пользователи, не владеющие технологиями анализа данных. Deductor Server – служба, обеспечивающая удаленную аналитическую обработку данных через компьютерную сеть. Deductor Client – клиент доступа к Deductor Server. Обеспечивает доступ к серверу из сторонних приложений и управление его работой. Существует три типа варианта поставки платформы Deductor: Enterprise; Professional; Academic. В зависимости от типа поставки набор доступных компонентов может различаться. Версия Enterprise предназначена для корпоративного использования. В ней присутствуют: серверные компоненты Deductor Server и Deductor Client, интерфейс доступа к Deductor через механизм OLE Automation, традиционное хранилище данных Deductor Warehouse на трех СУБД: Firebird, MS SQL, Oracle 169 и виртуальное хранилище данных Deductor Virtual Warehouse. Версия Professional предназначена для небольших компаний и однопользовательской работы. В ней отсутствуют серверные компоненты, поддержка OLE, виртуальное хранилище, а традиционное хранилище данных можно создавать только на СУБД FireBird. Автоматизация выполнения сценариев обработки данных осуществляется только через пакетный режим. Версии Professional и Enterprise требуют установки драйверов Guardant для работы с лицензионным ключом. Версия Academic предназначена для образовательных и обучающих целей. Ее функционал аналогичен версии Professional за исключением: отсутствует пакетный запуск сценариев, т.е. работа в программе может вестись только в интерактивном режиме; отсутствует импорт из промышленных источников данных: 1С, СУБД, файлы MS Excel, Deductor Data File; некоторые другие возможности. Архитектура системы построена таким образом, что вся работа по анализу данных в Deductor Studio базируется на выполнении следующих действий: импорт данных; обработка данных; визуализация; экспорт данных. 170 Рис.4.14 Архитектура Deductor. Процесс построения моделей в Deductor основывается на следующих трех принципах: 1. Использование обработчиков; 2. Использование визуализаторов; 3. Создание сценариев. Реализованные в Deductor обработчики покрывают основную потребность в анализе данных и создания законченных аналитических решений на базе алгоритмов Data Mining. Любой набор данных можно визуализировать каким- либо доступным способом или несколькими способами, поскольку визуализация помогает интерпретировать построенные модели. 171 В Deductor предусмотрены следующие способы визуализации данных. OLAP. Многомерное представление данных. Любые данные, используемые в программе, можно посмотреть в виде кросс- таблицы и кросс-диаграммы. Таблица. Стандартное табличное представлении с возможностью фильтрации данных. Диаграмма. График изменения любого показателя. Гистограмма. График разброса показателей. Статистика. Статистические показатели набора данных. Диаграмма рассеяния. График отклонения прогнозируемых при помощи модели значений от реальных. Может быть построена только для непрерывных величин и только после использования механизмов построения модели, например, нейросети или линейной регрессии. Используется для визуальной оценки качества построенной модели. Таблица сопряженности. Предназначена для оценки результатов классификации вне зависимости от используемой модели. Таблица сопряженности отображает результаты сравнения категориальных значений исходного выходного столбца и категориальных значений рассчитанного выходного столбца. Используется для оценки качества классификации. «Что-если». Таблица и диаграмма. Позволяют «прогонять» через построенную модель любые интересующие пользователя данные и оценить влияние того или иного фактора на результат. 172 Обучающая выборка. Набор данных, используемый для построения модели. Диаграмма прогноза. Применяется после использования метода обработки – Прогнозирование. Прогнозные значения выделяются цветом. Граф нейросети. Визуальное отображение обученной нейросети. Отображается структура нейронной сети и значения весов; Дерево решений. Отображение дерева решений, полученного при помощи соответствующего алгоритма. Дерево правил. Отображение в иерархическом виде (в виде дерева) ассоциативных правил. Правила. Отображает в текстовом виде правила, полученные при помощи алгоритма построения деревьев решений или поиска ассоциаций. Карта Кохонена. Отображение карт, построенных при помощи соответствующего алгоритма. Описание. Текстовое описание параметров импорта/обработки/экспорта в дереве сценариев обработки. Сценарий представляет собой иерархическую последовательность обработки и визуализации наборов данных. Сценарий всегда начинается с импорта набора данных из произвольного источника. После импорта может следовать произвольное число обработчиков любой степени глубины и вложенности. Каждой операции обработки соответствует отдельный узел дерева, или объект сценария. Любой объект можно визуализировать тем или иным доступным средством. Набор данных служит механизмом, соединяющим все объекты сценария. Можно сказать, что 173 сценарий – наиболее естественный с точки зрения аналитика способ представления этапов построения модели. Это позволяет быстро создавать модели, обладающие большой гибкостью и расширяемостью, сравнивать несколько моделей. На рис. 1.4 изображен пример сценария. Интерфейс Deductor Studio состоит из главного окна (рис.4.15), внутри которого располагаются панели сценариев, отчетов, источников данных и результаты моделирования (таблицы, графики, кросс-диаграммы, правила и т.д.). Рис.4.15. Главное окно Deductor Studio. Все сценарии создаются на основе запуска мастеров. В распоряжение аналитика имеется 4 мастера: импорт, экспорт, обработка, отображение. Мастер импорта предназначен для автоматизации получения данных из любого источника, предусмотренного в системе. На первом шаге мастера импорта открывается список всех предусмотренных в системе типов источников данных. Число шагов мастера импорта, а также набор настраиваемых параметров отличается для разных типов источников. 174 Мастер обработки предназначен для настройки всех параметров выбранного алгоритма. Мастер отображений позволяет в пошаговом режиме выбрать и настроить наиболее удобный способ представления данных. В зависимости от обработчика, в результате которого была получена ветвь сценария, список доступных для него видов отображений будет различным. Например, после построения деревьев решений их можно отобразить с помощью визуализаторов «Деревья решений» и «Правила». Эти способы отображения не доступны для других обработчиков. Мастер экспорта позволяет в пошаговом режиме выполнить экспорт данных в файлы наиболее распространенных форматов. |