Технологии анализа данных

Кафедра прикладных информационных технологий и программирования Технологии анализа данных. Часть II Конспект лекций Введение Согласно некоторым оценкам, количество информации в мире удваивается каждые 2-3 года. Огромные потоки данных приходят из науки, бизнеса, Интернета и других источников. Из-за огромного количества информации очень малая ее часть будет когда-либо увидена человеческим глазом, поэтому все более актуальным становится широкое применение методов Data Mining. По оценкам специалистов объем информации в обществе стремительно увеличивается: ‒ 2002 г. – объем информации в мире увеличился на 5 миллиардов байт (5 000 000 000 000 000 000); ‒ 2003 г. – самая большая база данных содержит 500 000 миллиардов байт (1 терабайт =1 000 миллиардов байт; 1 петабайт = 1 000 терабайт); ‒ 2011 г. – 1,8 зеттабайт (1,8 трлн Гб; 1 зеттабайт = 1021 ≈ 270 байт); ‒ 2012 г. – 2,8 зеттабайт; ‒ Прогноз на 2020 г. – до 40 зеттабайт. На графике (рисунок 1) хорошо виден рост объёмов информации, представленной в аналоговом и цифровом виде. Объём экспоненциально увеличивается. При этом видно, что где-то с 2000-х годов происходит переломный момент – цифровые носители получают широкое распространение тем самым давая всё большему количеству информации сохраняться и быть доступной уже в цифровом виде. Конечно же здесь не учитывается тот факт, что в 1986 году считалась информация, специально отобранная (библиотеки, фильмотеки и т.п.), а в 2002 году уже имеется просто вся информация, в том числе бесчисленные копии фильмов, фотографий и текстов. Следует отметить, что особый вклад в развитие цифровой эпохи внесли жёсткие диски. Удешевление их производства – основной фактор формирования тренда больших данных. Рисунок 1 – График роста объема информации в обществе Data Mining (также называемая Knowledge Discovery in Data – обнаружение знаний в данных) изучает процесс нахождения новых, действительно и потенциально полезных знаний в базах данных. Data Mining лежит на пересечении нескольких наук, главные из которых – это системы баз данных, статистика и искусственный интеллект. Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé 1.1. Çàäà÷è ñèñòåì ïîääåðæêè ïðèíÿòèÿ ðåøåíèé С появлением первых ЭВМ наступил этап информатизации разных сторон человеческой деятельности. Если раньше человек основное внимание уделял веществу, затем энергии (рис. 1.1), то сегодня можно без преувеличения сказать, что наступил этап осознания процессов, связанных с информацией. Вычислительная техника создавалась прежде всего для обработки данных. В настоящее время современные вычислительные системы и компьютерные сети позволяют накапливать большие массивы данных для решения задач обработки и анализа. К сожалению, сама по себе машинная форма представления данных содержит информацию, необходимую человеку, в скрытом виде, и для ее извлечения нужно использовать специальные методы анализа данных. Большой объем информации, с одной стороны, позволяет получить более точные расчеты и анализ, с другой — превращает поиск решений в сложную задачу. Неудивительно, что первичный анализ данных был переложен на компьютер. В результате появился целый класс программных систем, призванных облегчить работу людей, выполняющих анализ (аналитиков). Такие системы принято называть системами поддержки принятия решений — СППР (DSS, Decision Support System). Для выполнения анализа СППР должна накапливать информацию, обладая средствами ее ввода и хранения. Таким образом, можно выделить три основные задачи, решаемые в СППР:  ввод данных;  хранение данных;  анализ данных. Рис. 1.1. Уровень использования человеком различных объектов материального мира Таким образом, СППР — это системы, обладающие средствами ввода, хранения и анализа данных, относящихся к определенной предметной области, с целью поиска решений. Ввод данных в СППР осуществляется либо автоматически от датчиков, характеризующих состояние среды или процесса, либо человеком-оператором. В первом случае данные накапливаются путем циклического опроса, либо по сигналу готовности, возникающему при появлении информации. Во втором случае СППР должны предоставлять пользователям удобные средства ввода данных, контролирующие корректность вводимых данных и выполняющие сопутствующие вычисления. Если ввод осуществляется одновременно несколькими операторами, то система должна решать проблемы параллельного доступа и модификации одних и тех же данных. Постоянное накопление данных приводит к непрерывному росту их объема. В связи с этим на СППР ложится задача обеспечить надежное хранение больших объемов данных. На СППР также могут быть возложены задачи предотвращения несанкционированного доступа, резервного хранения данных, архивирования и т. п. Основная задача СППР — предоставить аналитикам инструмент для выполнения анализа данных. Необходимо отметить, что для эффективного использования СППР ее пользователь — аналитик должен обладать соответствующей квалификацией. Система не генерирует правильные решения, а только предоставляет аналитику данные в соответствующем виде (отчеты, таблицы, Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé графики и т. п.) для изучения и анализа, именно поэтому такие системы обеспечивают выполнение функции поддержки принятия решений. Очевидно, что, с одной стороны, качество принятых решений зависит от квалификации аналитика. С другой — рост объемов анализируемых данных, высокая скорость обработки и анализа, а также сложность использования машинной формы представления данных стимулируют исследования и разработку интеллектуальных СППР. Для таких СППР характерно наличие функций, реализующих отдельные умственные возможности человека. По степени "интеллектуальности" обработки данных при анализе выделяют три класса задач анализа:  информационно-поисковый — СППР осуществляет поиск необходимых данных. Характерной чертой такого анализа является выполнение заранее определенных запросов;  оперативно-аналитический — СППР производит группирование и обоб- щение данных в любом виде, необходимом аналитику. В отличие от информационно-поискового анализа в данном случае невозможно заранее предсказать необходимые аналитику запросы;  интеллектуальный — СППР осуществляет поиск функциональных и ло- гических закономерностей в накопленных данных, построение моделей и правил, которые объясняют найденные закономерности и/или (с определенной вероятностью) прогнозируют развитие некоторых процессов. Таким образом, обобщенная архитектура СППР может быть представлена следующим образом (рис. 1.2). Рис. 1.2. Обобщенная архитектура системы поддержки принятия решений Рассмотрим отдельные подсистемы более подробно. Ïîäñèñòåìà ââîäà äàííûõ. В таких подсистемах, называемых OLTP (Online transaction processing), реализуется операционная (транзакционная) обработка данных. Для их реализации используют обычные системы управления базами данных (СУБД). Ïîäñèñòåìà õðàíåíèÿ. Для реализации данной подсистемы используют современные СУБД и концепцию хранилищ данных. Ïîäñèñòåìà àíàëèçà. Данная подсистема может быть построена на основе:  подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL (Structured Query Language);  подсистемы оперативного анализа. Для реализации таких подсистем при- меняется технология оперативной аналитической обработки данных OLAP (On-line analytical processing), использующая концепцию многомерного представления данных;  подсистемы интеллектуального анализа. Данная подсистема реализует ме- тоды и алгоритмы Data Mining ("добыча данных"). 1.2. Áàçû äàííûõ — îñíîâà ÑÏÏÐ Ранее было отмечено, что для решения задач анализа данных и поиска решений необходимо накопление и хранение достаточно больших объемов данных. Этим целям служат базы данных (БД). Внимание! База данных является моделью некоторой предметной области, состоящей из связанных между собой данных об объектах, их свойствах и характеристиках. Системы, предоставляющие средства работы с БД, называются СУБД. Не решая непосредственно никаких прикладных задач, СУБД является инструментом для разработки прикладных программ, использующих БД. Чтобы сохранять данные согласно какой-либо модели предметной области, структура БД должна максимально соответствовать этой модели. Первой такой структурой, используемой в СУБД, была иерархическая структура, появившаяся в начале 60-х годов прошлого века. Иерархическая структура предполагала хранение данных в виде дерева. Это значительно упрощало создание и поддержку таких БД. Однако невозможность представить многие объекты реального мира в виде иерархии привела к использованию таких БД в сильно специализированных областях. Типичным Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé представителем (наиболее известным и распространенным) иерархической СУБД является Information Management System (IMS) фирмы IBM. Первая версия этого продукта появилась в 1968 году. Попыткой улучшить иерархическую структуру была сетевая структура БД, которая предполагает представление данных в виде сети. Она основана на предложениях группы Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL). Отчет DBTG был опубликован в 1971 году. Работа с сетевыми БД представляет гораздо более сложный процесс, чем работа с иерархической БД, поэтому данная структура не нашла широкого применения на практике. Типичным представителем сетевых СУБД является Integrated Database Management System (IDMS) компании Cullinet Software, Inc. Наиболее распространены в настоящее время реляционные БД. Термин "реляционный" произошел от латинского слова relatio — отношение. Такая структура хранения данных построена на взаимоотношении составляющих ее частей. Реляционный подход стал широко известен благодаря работам Е. Кодда, которые впервые были опубликованы в 1970 году. В них Кодд сформулировал следующие 12 правил для реляционной БД. 1. Данные представляются в виде таблиц — БД представляет собой набор таблиц. Таблицы хранят данные, сгруппированные в виде рядов и колонок. Ряд представляет собой набор значений, относящихся только к одному объекту, хранящемуся в таблице, и называется записью. Колонка представляет собой одну характеристику для всех объектов, хранящихся в таблице, и называется полем. Ячейка на пересечении ряда и колонки представляет собой значение характеристики, соответствующей колонке для элемента соответствующего ряда. 2. Данные доступны логически — реляционная модель не позволяет обращаться к данным физически, адресуя ячейки по номерам колонки и ряда (нет возможности получить значение в ячейке колонка 2, ряд 3). Доступ к данным возможен только через идентификаторы таблицы, колонки и ряда. Идентификаторами таблицы и колонки являются их имена. Они должны быть уникальны в пределах, соответственно, БД и таблицы. Идентификатором ряда является первичный ключ — значения одной или нескольких колонок, однозначно идентифицирующих ряды. Каждое значение первичного ключа в пределах таблицы должно быть уникальным. Если идентификация ряда осуществляется на основании значений нескольких колонок, то ключ называется составным. 3. NULL трактуется как неизвестное значение — если в ячейку таблицы значение не введено, то записывается NULL. Его нельзя путать с пустой строкой или со значением 0. 4. БД должна включать в себя метаданные — БД хранит два вида таблиц: пользовательские таблицы и системные таблицы. В пользовательских таблицах хранятся данные, введенные пользователем. В системных таблицах хранятся метаданные: описание таблиц (название, типы и размеры колонок), индексы, хранимые процедуры и др. Системные таблицы тоже доступны, т. е. пользователь может получить информацию о метаданных БД. 5. Должен использоваться единый язык для взаимодействия с СУБД — для управления реляционной БД должен использоваться единый язык. В настоящее время таким инструментом стал язык структурных запросов SQL. 6. СУБД должна обеспечивать альтернативный вид отображения данных — СУБД не должна ограничивать пользователя только отображением таблиц, которые существуют. Пользователь должен иметь возможность строить виртуальные таблицы — представления (View). Представления являются динамическим объединением нескольких таблиц. Изменения данных в представлении должны автоматически переноситься на исходные таблицы (за исключением нередактируемых полей в представлении, например вычисляемых полей). 7. Должны поддерживаться операции реляционной алгебры — записи реляционной БД трактуются как элементы множества, на котором определены операции реляционной алгебры. СУБД должна обеспечивать выполнение этих операций. В настоящее время выполнение этого правила обеспечивает язык SQL. 8. Должна обеспечиваться независимость от физической организации данных — приложения, оперирующие с данными реляционных БД, не должны зависеть от физического хранения данных (от способа хранения, формата хранения и др.). 9. Должна обеспечиваться независимость от логической организации данных — приложения, оперирующие с данными реляционных БД, не должны зависеть от организации связей между таблицами (логической организации). При изменении связей между таблицами не должны меняться ни сами таблицы, ни запросы к ним. 10. За целостность данных отвечает СУБД — под целостностью данных в общем случае понимается готовность БД к работе. Различают следующие типы целостности: • физическая целостность — сохранность информации на носителях и корректность форматов хранения данных; • логическая целостность — непротиворечивость и актуальность данных, хранящихся в БД. Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé Потеря целостности базы данных может произойти от сбоев аппаратуры ЭВМ, ошибок в программном обеспечении, неверной технологии ввода и корректировки данных, низкой достоверности самих данных и т. д. За сохранение целостности данных должна отвечать СУБД, а не приложение, оперирующее ими. Различают два способа обеспечения целостности: декларативный и процедурный. При декларативном способе целостность достигается наложением ограничений на таблицы, при процедурном — обеспечивается с помощью хранимых в БД процедур. 11. Целостность данных не может быть нарушена — СУБД должна обеспечивать целостность данных при любых манипуляциях, производимых с ними. 12. Должны поддерживать распределенные операции — реляционная БД может размещаться как на одном компьютере, так и на нескольких — распределенно. Пользователь должен иметь возможность связывать данные, находящиеся в разных таблицах и на разных узлах компьютерной сети. Целостность БД должна обеспечиваться независимо от мест хранения данных. На практике в дополнение к перечисленным правилам существует требование минимизации объемов памяти, занимаемых БД. Это достигается проектированием такой структуры БД, при которой дублирование (избыточность) информации было бы минимальным. Для выполнения этого требования была разработана теория нормализации. Она предполагает несколько уровней нормализации БД, каждый из которых базируется на предыдущем. Каждому уровню нормализации соответствует определенная нормальная форма (НФ). В зависимости от условий, которым удовлетворяет БД, говорят, что она имеет соответствующую нормальную форму. Например:  БД имеет 1-ю НФ, если каждое значение, хранящееся в ней, неразделимо на более примитивные (неразложимость значений);  БД имеет 2-ю НФ, если она имеет 1-ю НФ, и при этом каждое значение целиком и полностью зависит от ключа (функционально независимые значения);  БД имеет 3-ю НФ, если она имеет 2-ю НФ, и при этом ни одно из значений не предоставляет никаких сведений о другом значении (взаимно независимые значения) и т. д. В заключение описания реляционной модели необходимо заметить, что она имеет существенный недостаток. Дело в том, что не каждый тип информации можно представить в табличной форме, например изображения, музыку и др. Правда, в настоящее время для хранения такой информации в реляционных СУБД сделана попытка использовать специальные типы полей — BLOB (Binary Large OBjects). В них хранятся ссылки на соответствующую информацию, которая не включается в БД. Однако такой подход не позволяет оперировать информацией, не помещенной в базу данных, что ограничивает возможности по ее использованию. Для хранения такого вида информации предлагается использовать постреляционные модели в виде объектно-ориентированных структур хранения данных. Общий подход заключается в хранении любой информации в виде объектов. При этом сами объекты могут быть организованы в рамках иерархической модели. К сожалению, такой подход, в отличие от реляционной структуры, которая опирается на реляционную алгебру, недостаточно формализован, что не позволяет широко использовать его на практике. В соответствии с правилами Кодда СУБД должна обеспечивать выполнение операций над БД, предоставляя при этом возможность одновременной работы нескольким пользователям (с нескольких компьютеров) и гарантируя целостность данных. Для выполнения этих правил в СУБД используется механизм управления транзакциями. Внимание! Транзакция — это последовательность операций над БД, рассматриваемых СУБД как единое целое. Транзакция переводит БД из одного целостного состояния в другое. Как правило, транзакцию составляют операции, манипулирующие с данными, принадлежащими разным таблицам и логически связанными друг с другом. Если при выполнении транзакции будут выполнены операции, модифицирующие только часть данных, а остальные данные не будут изменены, то будет нарушена целостность. Следовательно, все операции, включенные в транзакцию, должны быть выполненными, либо не выполнена ни одна из них. Процесс отмены выполнения транзакции называется откатом транзакции (ROLLBACK). Сохранение изменений, производимых в результате выполнения операций транзакции, называется фиксацией транзакции (COMMIT). Свойство транзакции переводить БД из одного целостного состояния в другое позволяет использовать понятие транзакции как единицу активности пользователя. В случае одновременного обращения пользователей к БД транзакции, инициируемые разными пользователями, выполняются не параллельно (что невозможно для одной БД), а в соответствии с некоторым планом ставятся в очередь и выполняются последовательно. Таким образом, для пользователя, по инициативе которого образована транзакция, присутствие транзакций других пользователей будет незаметно, если не считать некоторого замедления работы по сравнению с однопользовательским режимом. Существует несколько базовых алгоритмов планирования очередности транзакций. В централизованных СУБД наиболее распространены алгоритмы, Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé основанные на синхронизированных захватах объектов БД. При использовании любого алгоритма возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания плана необходимо выполнять откат одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально ощутить присутствие в системе транзакций других пользователей. История развития СУБД тесно связана с совершенствованием подходов к решению задач хранения данных и управления транзакциями. Развитый механизм управления транзакциями в современных СУБД сделал их основным средством построения OLTP-систем, основной задачей которых является обеспечение выполнения операций с БД. OLTP-системы оперативной обработки транзакций характеризуются большим количеством изменений, одновременным обращением множества пользователей к одним и тем же данным для выполнения разнообразных операций — чтения, записи, удаления или модификации данных. Для нормальной работы множества пользователей применяются блокировки и транзакции. Эффективная обработка транзакций и поддержка блокировок входят в число важнейших требований к системам оперативной обработки транзакций. К этому классу систем относятся, кстати, первые СППР — информационные системы руководства (ИСР, Executive Information Systems). Такие системы, как правило, строятся на основе реляционных СУБД, включают в себя подсистемы сбора, хранения и информационно-поискового анализа информации, а также содержат в себе предопределенное множество запросов для повседневной работы. Каждый новый запрос, непредусмотренный при проектировании такой системы, должен быть сначала формально описан, закодирован программистом и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что неприемлемо для оперативного принятия решений. 1.3. Íåýôôåêòèâíîñòü èñïîëüçîâàíèÿ OLTP-ñèñòåì äëÿ àíàëèçà äàííûõ Практика использования OLTP-систем показала неэффективность их применения для полноценного анализа информации. Такие системы достаточно успешно решают задачи сбора, хранения и поиска информации, но они не удовлетворяют требованиям, предъявляемым к современным СППР. Подходы, связанные с наращиванием функциональности OLTP-систем, не дали удовлетворительных результатов. Основной причиной неудачи является противоречивость требований, предъявляемых к системам OLTP и СППР. Перечень основных противоречий между этими системами приведен в табл. 1.1. Таблица 1.1 Характеристика Требования к OLTP-системе Требования к системе анализа Степень детализации хранимых данных Хранение только детализированных данных Хранение как детализированных, так и обобщенных данных Качество данных Допускаются неверные данные из-за ошибок ввода Не допускаются ошибки в данных Формат хранения данных Может содержать данные в разных форматах в зависимости от приложений Единый согласованный формат хранения данных Допущение избыточных данных Должна обеспечиваться максимальная нормализация Допускается контролируемая денормализация (избыточность) для эффективного извлечения данных Управление данными Должна быть возможность в любое время добавлять, удалять и изменять данные Должна быть возможность периодически добавлять данные Количество хранимых данных Должны быть доступны все оперативные данные, требующиеся в данный момент Должны быть доступны все данные, накопленные в течение продолжительного интервала времени Характер запросов к данным Доступ к данным пользователей осуществляется по заранее составленным запросам Запросы к данным могут быть произвольные и заранее не оформлены Время обработки обращений к данным Время отклика системы измеряется в секундах Время отклика системы может составлять несколько минут Характер вычислительной нагрузки на систему Постоянно средняя загрузка процессора Загрузка процессора формируется только при выполнении запроса, но на 100 % Приоритетность характеристик системы Основными приоритетами являются высокая производительность и доступность Приоритетными являются обеспечение гибкости системы и независимости работы пользователей Рассмотрим требования, предъявляемые к системам OLTP и СППР более подробно. Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé Ñòåïåíü äåòàëèçàöèè õðàíèìûõ äàííûõ — типичный запрос в OLTPсистеме, как правило, выборочно затрагивает отдельные записи в таблицах, которые эффективно извлекаются с помощью индексов. В системах анализа, наоборот, требуется выполнять запросы сразу над большим количеством данных с широким применением группировок и обобщений (суммирования, агрегирования и т. п.). Например, в стандартных системах складского учета наиболее часто выполняются операции вычисления текущего количества определенного товара на складе, продажи и оплаты товаров покупателями и т. д. В системах анализа выполняются запросы, связанные с определением общей стоимости товаров, хранящихся на складе, категорий товаров, пользующихся наибольшим и наименьшим спросом, обобщение по категориям и суммирование по всем продажам товаров и т. д. Êà÷åñòâî äàííûõ — OLTP-системы, как правило, хранят информацию, вводимую непосредственно пользователями систем (операторами ЭВМ). Присутствие "человеческого фактора" при вводе повышает вероятность ошибочных данных и может создать локальные проблемы в системе. При анализе ошибочные данные могут привести к неправильным выводам и принятию неверных стратегических решений. Ôîðìàò õðàíåíèÿ äàííûõ — OLTP-системы, обслуживающие различные участки работы, не связаны между собой. Они часто реализуются на разных программно-аппаратных платформах. Одни и те же данные в разных базах могут быть представлены в различном виде и могут не совпадать (например, данные о клиенте, который взаимодействовал с разными отделами компании, могут не совпадать в базах данных этих отделов). В процессе анализа такое различие форматов чрезвычайно затрудняет совместный анализ этих данных. Поэтому к системам анализа предъявляется требование единого формата. Как правило, необходимо, чтобы этот формат был оптимизирован для анализа данных (нередко за счет их избыточности). Äîïóùåíèå èçáûòî÷íûõ äàííûõ — структура базы данных, обслуживающей OLTP-систему, обычно довольно сложна. Она может содержать многие десятки и даже сотни таблиц, ссылающихся друг на друга. Данные в такой БД сильно нормализованы для оптимизации занимаемых ресурсов. Аналитические запросы к БД очень трудно формулируются и крайне неэффективно выполняются, поскольку содержат в себе представления (view), объединяющие большое количество таблиц. При проектировании систем анализа стараются максимально упростить схему БД и уменьшить количество таблиц, участвующих в запросе. С этой целью часто допускают денормализацию (избыточность данных) БД. Óïðàâëåíèå äàííûìè — основное требование к OLTP-системам — обеспечить выполнение операций модификации над БД. При этом предполагается, что они должны выполняться в реальном режиме, и часто очень интенсивно. Например, при оформлении розничных продаж в систему вводятся соответствующие документы. Очевидно, что интенсивность ввода зависит от интенсивности покупок и в случае ажиотажа будет очень высокой, а любое промедление ведет к потере клиента. В отличие от OLTP-систем данные в системах анализа меняются редко. Единожды попав в систему, данные уже практически не изменяются. Ввод новых данных, как правило, носит эпизодический характер и выполняется в периоды низкой активности системы (например, раз в неделю на выходных). Êîëè÷åñòâî õðàíèìûõ äàííûõ — как правило, системы анализа предназначены для анализа временных зависимостей, в то время как OLTP-системы обычно имеют дело с текущими значениями каких-либо параметров. Например, типичное складское приложение OLTP оперирует с текущими остатками товара на складе, в то время как в системе анализа может потребоваться анализ динамики продаж товара. По этой причине в OLTP-системах допускается хранение данных за небольшой период времени (например, за последний квартал). Для анализа данных, наоборот, необходимы сведения за максимально большой интервал времени. Õàðàêòåð çàïðîñîâ ê äàííûì — в OLTP-системах из-за нормализации БД составление запросов является достаточно сложной работой и требует необходимой квалификации. Поэтому для таких систем заранее составляется некоторый ограниченный набор статических запросов к БД, необходимый для работы с системой (например, наличие товара на складе, размер задолженности покупателей и т. п.). Для СППР невозможно заранее определить необходимые запросы, поэтому к ним предъявляется требование обеспечить формирование произвольных запросов к БД аналитиками. Âðåìÿ îáðàáîòêè îáðàùåíèé ê äàííûì — OLTP-системы, как правило, работают в режиме реального времени, поэтому к ним предъявляются жесткие требования по обработке данных. Например, время ввода документов продажи товаров (расходных, накладных) и проверки наличия продаваемого товара на складе должно быть минимально, т. к. от этого зависит время обслуживания клиента. В системах анализа, по сравнению с OLTP, обычно выдвигают значительно менее жесткие требования ко времени выполнения запроса. При анализе данных аналитик может потратить больше времени для проверки своих гипотез. Его запросы могут выполняться в диапазоне от нескольких минут до нескольких часов. Õàðàêòåð âû÷èñëèòåëüíîé íàãðóçêè íà ñèñòåìó — как уже отмечалось, работа с OLTP-системами, как правило, выполняется в режиме реального Ñèñòåìû ïîääåðæêè ïðèíÿòèÿ ðåøåíèé времени. В связи с этим такие системы нагружены равномерно в течение всего интервала времени работы с ними. Документы продажи или прихода товара оформляются в общем случае постоянно в течение всего рабочего дня. Аналитик при работе с системой анализа обращается к ней для проверки некоторых своих гипотез и получения отчетов, графиков, диаграмм и т. п. При выполнении запросов степень загрузки системы высокая, т. к. обрабатывается большое количество данных, выполняются операции суммирования, группирования и т. п. Таким образом, характер загрузки систем анализа является пиковым. На рис. 1.3 приведены данные фирмы Oracle для систем OLTP, на рис. 1.4 — для систем анализа, отражающие загрузку процессора в течение дня. Рис. 1.3. Загрузка процессора для систем OLTP Рис. 1.4. Загрузка процессора для систем анализа Ïðèîðèòåòíîñòü õàðàêòåðèñòèê ñèñòåìû — для OLTP-систем приоритетным является высокая производительность и доступность данных, т. к. работа с ними ведется в режиме реального времени. Для систем анализа более приоритетными являются задачи обеспечения гибкости системы и независимости работы пользователей, другими словами то, что необходимо аналитикам для анализа данных. Противоречивость требований к OLTP-системам и системам, ориентированным на глубокий анализ информации, усложняет задачу интеграции их как подсистем единой СППР. В настоящее время наиболее популярным решением этой проблемы является подход, ориентированный на использование концепции хранилищ данных. Общая идея хранилищ данных заключается в разделении БД для OLTPсистем и БД для выполнения анализа и последующем их проектировании с учетом соответствующих требований. Âûâîäû Из материала, изложенного в данной главе, можно сделать следующие выводы.  СППР решают три основные задачи: сбор, хранение и анализ хранимой информации. Задача анализа разделяется на информационно-поисковый, оперативно-аналитический и интеллектуальный классы.  Подсистемы сбора, хранения информации и решения задач информацион- но-поискового анализа в настоящее время успешно реализуются в рамках ИСР средствами СУБД. Для реализации подсистем, выполняющих оперативно-аналитический анализ, используется концепция многомерного представления данных (OLAP). Подсистема интеллектуального анализа данных реализует методы и алгоритмы Data Mining.  Исторически выделяют три основные структуры БД: иерархическую, сете- вую и реляционную. Первые две не нашли широкого применения на практике. В настоящее время подавляющее большинство БД реализует реляционную структуру представления данных.  Основной недостаток реляционных БД заключается в невозможности об- работки информации, которую нельзя представить в табличном виде. В связи с этим предлагается использовать постреляционные модели, например объектно-ориентированные.  Для упрощения разработки прикладных программ, использующих БД, создаются системы управления базами данных (СУБД) — программное обеспечение для управления данными, их хранения и безопасности данных.  В СУБД развит механизм управления транзакциями, что сделало их ос- новным средством создания систем оперативной обработки транзакций (OLTP-систем). К таким системам относятся первые СППР, решающие задачи информационно-поискового анализа — ИСР.  OLTP-системы не могут эффективно использоваться для решения задач оперативно-аналитического и интеллектуального анализа информации. Основная причина заключается в противоречивости требований к OLTPсистеме СППР.  В настоящее время для объединения в рамках одной системы OLTP под- систем и подсистем анализа используется концепция хранилищ данных. Общая идея заключается в разделении БД для OLTP-систем и БД для выполнения анализа. Õðàíèëèùå äàííûõ 2.1. Êîíöåïöèÿ õðàíèëèùà äàííûõ Стремление объединить в одной архитектуре СППР возможности OLTPсистем и систем анализа, требования к которым во многом, как следует из табл. 1.1, противоречивы, привело к появлению концепции хранилищ данных (ХД). Концепция ХД так или иначе обсуждалась специалистами в области информационных систем достаточно давно. Первые статьи, посвященные именно ХД, появились в 1988 г., их авторами были Девлин и Мэрфи. В 1992 г. Уильман Г. Инмон подробно описал данную концепцию в своей монографии "Построение хранилищ данных". В основе концепции ХД лежит идея разделения данных, используемых для оперативной обработки и для решения задач анализа. Это позволяет применять структуры данных, которые удовлетворяют требованиям их хранения с учетом использования в OLTP-системах и системах анализа. Такое разделение позволяет оптимизировать как структуры данных оперативного хранения (оперативные БД, файлы, электронные таблицы и т. п.) для выполнения операций ввода, модификации, удаления и поиска, так и структуры данных, используемые для анализа (для выполнения аналитических запросов). В СППР эти два типа данных называются соответственно оперативными источниками данных (ОИД) и хранилищем данных. В своей работе Инмон дал следующее определение ХД. Внимание! Хранилище данных — предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений. Рассмотрим свойства ХД более подробно. Ïðåäìåòíàÿ îðèåíòàöèÿ — является фундаментальным отличием ХД от ОИД. Разные ОИД могут содержать данные, описывающие одну и ту же предметную область с разных точек зрения (например, с точки зрения бухгалтерского учета, складского учета, планового отдела и т. п.). Решение, принятое на основе только одной точки зрения, может быть неэффективным или даже неверным. ХД позволяют интегрировать информацию, отражающую разные точки зрения на одну предметную область. Предметная ориентация позволяет также хранить в ХД только те данные, которые нужны для их анализа (например, для анализа нет необходимости хранить информацию о номерах документов купли-продажи, в то время как их содержимое — количество, цена проданного товара — необходимо). Это существенно сокращает затраты на носители информации и повышает безопасность доступа к данным. Èíòåãðàöèÿ — ОИД, как правило, разрабатываются в разное время несколькими коллективами с собственным инструментарием. Это приводит к тому, что данные, отражающие один и тот же объект реального мира в разных системах, описывают его по-разному. Обязательная интеграция данных в ХД позволяет решить эту проблему, приведя данные к единому формату. Ïîääåðæêà õðîíîëîãèè — данные в ОИД необходимы для выполнения над ними операций в текущий момент времени. Поэтому они могут не иметь привязки ко времени. Для анализа данных часто важно иметь возможность отслеживать хронологию изменений показателей предметной области. Поэтому все данные, хранящиеся в ХД, должны соответствовать последовательным интервалам времени. Íåèçìåíÿåìîñòü — требования к ОИД накладывают ограничения на время хранения в них данных. Те данные, которые не нужны для оперативной обработки, как правило, удаляются из ОИД для уменьшения занимаемых ресурсов. Для анализа, наоборот, требуются данные за максимально больший период времени. Поэтому, в отличие от ОИД, данные в ХД после загрузки только читаются. Это позволяет существенно повысить скорость доступа к данным как за счет возможной избыточности хранящейся информации, так и за счет исключения операций модификации. При реализации в СППР концепции ХД данные из разных ОИД копируются в единое хранилище. Собранные данные приводятся к единому формату, согласовываются и обобщаются. Аналитические запросы адресуются к ХД (рис. 2.1). Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД. Однако Инмон в своей работе утверждает, что избыточность данных, Õðàíèëèùå äàííûõ хранящихся в СППР, не превышает 1 % ! Это можно объяснить следующими причинами. При загрузке информации из ОИД в ХД данные фильтруются. Многие из них не попадают в ХД, поскольку лишены смысла с точки зрения использования в процедурах анализа. Информация в ОИД носит, как правило, оперативный характер, и данные, потеряв актуальность, удаляются. В ХД, напротив, хранится историческая информация. С этой точки зрения дублирование содержимого ХД данными ОИД оказывается весьма незначительным. В ХД хранится обобщенная информация, которая в ОИД отсутствует. Во время загрузки в ХД данные очищаются (удаляется ненужная информация) и приводятся к единому формату. После такой обработки данные занимают гораздо меньший объем. Рис. 2.1. Структура СППР с физическим ХД Избыточность информации можно свести к нулю, используя виртуальное ХД. В данном случае в отличие от классического (физического) ХД данные из ОИД не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в оперативной памяти компьютера. Фактически такие запросы напрямую адресуются к ОИД (рис. 2.2). Основными достоинствами виртуального ХД являются:  минимизация объема памяти, занимаемой на носителе информацией;  работа с текущими, детализированными данными. При решении задачи очистки данных, прежде всего, необходимо отдавать себе отчет в том, что не все проблемы могут быть устранены. Возможны си­ туации, когда данные не существуют и не могут быть восстановлены, вне за­ висимости от количества приложенных усилий. Встречаются ситуации, когда значения настолько запутаны или найдены в стольких несопоставимых мес­ тах с такими на вид различными и противоположными значениями одного и того же факта, что любая попытка расшифровать такие данные может поро­ дить еще более неверные результаты, и, возможно, лучшим решением будет отказ от их обработки. На самом деле не все данные нужно очищать. Как уже отмечалось, процесс очистки требует больших затрат, поэтому те данные, достоверность которых не влияет на процесс принятия решений, могут оста­ ваться неочищенными. В целом, очистка данных включает несколько этапов: • выявление проблем в данных; • определение правил очистки данных; • тестирование правил очистки данных; • непосредственная очистка данных. Выявление проблем в данных. Для выявления подлежащих удалению ви­ дов ошибок и несоответствий необходим подробный анализ данных. Наряду с ручной проверкой следует использовать аналитические программы. Суще­ ствует два взаимосвязанных метода анализа: профайлинг данных и Data Mining. Профайлинг данных ориентирован на грубый анализ отдельных атрибутов данных. При этом происходит получение, например, такой информации, как тип, длина, спектр значений, дискретные значения данных и их частота, из­ менение, уникальность, наличие неопределенных значений, типичных стро­ ковых моделей (например, для номеров телефонов) и др., что позволяет обес­ печить точное представление различных аспектов качества атрибута. Data Mining помогает найти специфические модели в больших наборах дан­ ных, например отношения между несколькими атрибутами. Именно на это направлены так называемые описательные модели Data Mining, включая группировку, обобщение, поиск ассоциаций и последовательностей. При этом могут быть получены ограничения целостности в атрибутах. Например, функциональные зависимости или характерные для конкретных приложений бизнес-правила, которые можно использовать для восполнения утраченных и исправления недопустимых значений, а также для выявления дубликатов записей в источниках данных. Например, правило объединения с высокой вероятностью может предсказать проблемы с качеством данных в элементах данных, нарушающих это правило. Таким образом, 99 % вероятность правила зависимости невозможны. Это предварительная обработка или препроцессинг данных и составляет второй этап Для иллюстрации процесса подготовки данных рассмотри пример, связанный с подготовкой данных из базы данных издателя журнала. Издатель продает пять типов журнала - автомобильный, о доме, спортивный, музыкальный и комиксы. Целью процесса извлечения знаний в данной задаче состоит в том, чтобы найти новые значимые группы клиентов, чтобы установить рыночную конъюнктуру. Следовательно, множество запросов включает такие запросы как «каков типичный профиль читателя автомобильного журнала?», «существует ли корреляция между интересом к автомобилям и интересам к комиксам?». Отбор данных. Как правило, для решения конкретной задачи нужны не все данные из хранилища данных. Сначала необходимо выбрать то их подмножество, которое будет подвергнуто анализу. При этом возможно, потребуется объединить несколько таблиц, а полученные записи отфильтровать. В нашем примере начнем с общей базы данных, содержащей записи о подписке журналов. Она содержит выборку операционных данных из системы издательских счетов-фактур и содержит информацию о людях, которые подписались на журнал. Записи состоят из номера клиента, имени, адреса, даты подписки и типа журнала (табл.1.1). Очистка. Существуют несколько типов очистки данных (удаление дублирующих записей, исправление типографских ошибок, добавление отсутствующей информации и т.д.), некоторые из которых могут выполняться заранее, в то время как другие вызываются только после обнаружения загрязнения на этапах кодирования или обнаружения. В технологии ИАОД существует старое правило "мусор внутри, мусор снаружи". Чтобы внедрить процесс интеллектуальной обработки данных в организации, необходим процесс постоянного уточнения данных и устранения “мусора”. Очень важным элементом очистки является устранение дублирования записей (табл. 1.2). Таблица 1.1 Первичные данные Номер клиента 23003 23003 23003 23009 23013 23005 Имя Адрес Котов Котов Котов Иванов Петров Зотов Кирова 1 Кирова 1 Кирова 1 Бардина 2 Курако 6 Кирова 1 Дата покупки 04-15-94 06-21-93 05-30-92 01-01-01 02-30-95 01-01-01 Покупаемый журнал Автомобильный Музыкальный Комиксы Комиксы Спортивный “Дом” Таблица 1.2 Устранение дублирования Номер Имя Адрес Дата Покупаемый клиента покупки журнал 23003 Котов Кирова 1 04-15-94 Автомобильный 23003 Котов Кирова 1 06-21-93 Музыкальный 23003 Котов Кирова 1 05-30-92 Комиксы 23009 Иванов Бардина 2 01-01-01 Комиксы 23013 Петров Курако 6 02-30-95 Спортивный 23003 Котов Кирова 1 01-01-01 “Дом” В базе данных клиентов некоторые клиенты могут быть представлены несколькими записями, хотя во многих случаях это результат небрежности, такой как ошибка при набивке, или следствием того, что, например, клиенты перемещаются с одного места на другое без извещения об изменении адреса. Существуют также случаи, в которых люди преднамеренно записывают свои имена неправильно или дают неправильную информацию относительно себя, особенно в ситуации отказа им в некотором типе страхования. С помощью своего имени или неправильного адреса они пытаются избежать отрицательного решения. Конечно, для любой организации важно избегать такие аномалии в базе данных. Хотя обнаружение знаний и очистка данных - две различных дисциплины, они имеют много общего и при очистке данных могут быть применены алгоритмы распознавания паттернов. В представленном примере в атрибуте имени БД присутствуют значения Дженсон и Джонсон. Они имеют различные клиентские номера, но один и тот же адрес, что достаточно сильно свидетельствует о том, что эти двое - один и тот же человек, но что в имени одного существует ошибка. Конечно, нельзя быть уверенным до конца, что это так, но алгоритм устранения дублирования, используя технику анализа образцов, мог бы идентифицировать ситуацию и представить её пользователю для принятия решения. Этот тип загрязнения встречается часто: потому что ошибка в первичной БД там, где появляются два клиента, когда в действительности существует только один, создаёт впечатление, что организация имеет больше клиентов, чем в есть на самом деле. Так как это ситуация, которая часто происходит в реальной жизни, многие большие банки и страховые компании не имеют никакой надежной идеи узнать, как много заказчиков они действительно имеют. Это представляет серьезную проблему в маркетинговой деятельности, но после процедуры устранения дублирования две подписки Дженсона/Джонсона можно определенно решить, кто из них таковой на самом деле. Второй распространенный тип загрязнения - это недостаток области совместимости (табл. 1.3). Обратите внимание, что в первичной таблице мы имеем две записи, датированные 1 января 1901. Хотя организации вероятно даже не существовала в это время. Этот тип загрязнения особенно опасен, поскольку его трудно проследить, но он будет оказывать огромное влияние на тип образцов (паттернов), находимых применяемыми к этой таблице процедурами обнаружения знаний. В некоторых базах данных анализ показывает неожиданно высокое число людей, рожденных 11 ноября. Когда люди вынуждены заполнять дату рождения за монитором, и они или не знают или не хотят обнародовать свою дату рождения, они склоняются набить 11-11-11. Само собой разумеется, это катастрофично в контексте обнаружения знаний, так как если информация неизвестна, то она должна и представляться так в базе данных. В нашем примере мы заменили часть данных нулевым значением и исправили другие области несовместимости. Таблица 1.3 Область совместимости Номер Имя Адрес Дата Покупаемый клиента покупки журнал 23003 Котов Кирова 1 04-15-94 Автомобильный 23003 Котов Кирова 1 06-21-93 Музыкальный 23003 Котов Кирова 1 05-30-92 Комиксы 23009 Иванов Бардина 2 NULL Комиксы 23013 Петров Курако 6 02-30-95 Спортивный 23003 Котов Кирова 1 12-20-94 “Дом” Обогащение (добавление информации). Предположим, что мы получили дополнительную информацию о клиентах, состоящую из даты рождения, дохода, размера кредита, наличия автомобиля или дома (табл. 1.4.) Не очень важно, как была собрана информация, но необходимо оценить, можно ли новую информацию присоединить к существующим записям о клиентах. Таблица 1.4 Обогащение Имя Дата рождения Доход Кредит клиента Котов 04-13-76 $18,500 $17,800 Иванов 10-20-71 $36,000 $26,600 Владелец автомобиля Нет Да Владелец дома нет нет Кодирование. Данные в примере могут подвергаться ряду преобразований. Сначала дополнительная информация, которая была получена, чтобы обогатить базу данных, добавляется к записям, описывающим индивидуальности. На следующем этапе мы выделяем только те записи, которые имеют достаточно информации, чтобы быть ценными (табл.1.5). Хотя трудно дать детализированные правила для этого вида операции, это ситуация, которая часто происходит на практике. В большинстве таблиц, которые собраны из операционных данных, отсутствует множество желательных данных и большинство из них невозможно восстановить. Поэтому необходимо принять обдуманное решение или пропустить эту информацию, или удалить её. Общее правило говорит, что любое удаление данных должно быть сознательным решением после всестороннего анализа возможных последствий. В некоторых случаях, особенно в задачах определения мошенничества, недостаток информации может быть ценным указанием наличия значимых образцов. Таблица 1.5 Обогащенная таблица Номер Имя Дата Доход Кредит Владе- Владелец Адрес Дата поЖурнал клирожде- (тыс.) (тыс.) лец авто дома купки ента ния 23003 Котов 04-13-76 $18,5 $17,8 нет нет Кирова 1 04-15-94 Автомобильный 23003 Котов 04-13-76 $18,5 $17,8 нет нет Кирова 1 06-21-93 Музыкальный 23003 Котов 04-13-76 $18,5 $17,8 нет нет Кирова 1 05-30-92 Комиксы 23009 Иванов 10-20-71 $36,0 $26,0 да нет Бардина 2 нуль Комиксы 23013 Петров NULL NULL NULL NULL NULL Курако 6 02-30-95 Спортивный 23003 Котов 04-13-76 $18,5 $17,8 нет нет Кирова 1 12-20-94 Дом В представленном примере существует недостаток данных о Кинге, поэтому примем решение исключить эту запись из заключительной выборки. Конечно, это решение не бесспорно, потому что может существовать причинная связь между недостатком информации и поведением Кинга. Предположим, что можно игнорировать эти данные без каких-либо последствий для наших заключительных результатов. В этом примере мы не заинтересованы в именах клиентов, так как хотим только определить некоторые типы клиентов пользователя, так что их имена удаляются из базы данных (табл. 1.6). Таблица 1.6 Таблица с удаленными строками и столбцами Номер Дата клиента рождения 23003 23003 23003 23009 23003 04-13-76 04-13-76 04-13-76 10-20-71 04-13-76 Доход (тыс.) $18,5 $18,5 $18,5 $36,0 $18,5 Кредит (тыс.) $17,8 $17,8 $17,8 $26,0 $17,8 Владелец Владелец авто дома нет нет нет да нет нет нет нет нет нет Адрес Кирова 1 Кирова 1 Кирова 1 Бардина 2 Кирова 1 Дата покупки 04-15-94 06-21-93 05-30-92 нуль 12-20-94 Журнал Автомобильный Музыкальный Комиксы Комиксы Дом До сих пор фаза кодирования состояла из простых операций SQL, но теперь вводим этап, где требуется творческое преобразование данных. Информация в нашей базе данных слишком детализирована, чтобы использоваться в качестве входной для алгоритмов распознавания образцов. Возьмём, например, понятие даты рождения: алгоритм, который помещает людей с одной и той же датой рождения в определенный класс заказчиков, очевидно, слишком детализирован для наших целей, в то же время подобный алгоритм, обрабатывающий возрастные классы с интервалом, например, 10 лет был бы подходящим. То же справедливо и для адресов. Информация об адресах слишком детализирована для алгоритмов распознавания образцов и, в этом случае, нам необходимо записывать адреса в кодах регионов. Способ, которым кодируется информацию, в значительной степени, определит тип найденных нами паттернов. Следовательно, кодирование является творческой деятельностью, которое должно выполняться постоянно, чтобы получить наилучшие результаты. Возьмём, например, дату подписки; снова она слишком детализировано, но существуют различные способы записи этих дат так, чтобы обнаружились ценные образцы. Одним из решений могла бы быть трансформация даты приобретения в месяцы, начиная с 1990г. Таким образом, мы могли бы найти образцы во временной последовательности транзакций наших заказчиков, например, зависимости, подобные следующему правилу: Заказчик с кредитом > 13,000 и возрастом между 22 и 31, который подписался на комиксы во время T, пятью годами позже с большой вероятностью подпишется на автомобильный журнал. Или могли бы определить такую тенденцию: Число журналов о доме, проданных заказчикам с кредитом между12,000 и 31,000, проживающим в регионе 4, увеличивается. Или определить такую миграцию типов клиентов: Заказчик с кредитом между 5,000 и 10,000, читающий комиксы после 12 лет с большой вероятностью станет заказчиком с кредитом между 12,000 и 31,000, читающий спортивный журнал и журнал о доме. Однако, иногда мы интересуемся не временными отрезками, а такой информацией как сезонное влияние на поведение заказчика. В таких случаях можно изменить даты подписки на коды сезона и попытаться найти паттерны в этих терминах. Кодирование - творческий процесс и может существовать большое число различных кодов, которые связаны с произвольным числом различных потенциальных образцов, которые мы хотели бы найти. В нашем примере можно применить следующие шаги кодирования: 1). адресовать к региону. Это - просто упрощение адресной информации. В регионе, который исследуется, могут быть миллионы различных адресов, который слишком детальны для наших целей. Поэтому необходимо сжать информацию об адресах в четыре кода различных областей. Однако, обратите внимание, что это - не произвольное решение; мы могли решить использовать 20 или 1000 различных кодов области, или изменить определение области. Все эти решения могут воздействовать на результат алгоритмов обнаружения знаний и поэтому должны быть приняты осознанно, рассчитав последствия; 2). дату рождения преобразовать к возрасту. Это подразумевает разделение информации о дне рождения на дискретные значения приблизительно 100 классов по возрасту (люди в среднем не живут намного больше 100 лет). Здесь мы также могли бы выбрать меньшее или большее число классов, например, десять классов по 10 лет; 3). разделить доход по 1000. Это не только упрощает информацию о доходах, но также создает классы по доходу с тем же самым порядком величины, что и классы по возрасту. После этой операции большинство людей будет иметь класс по доходу где-нибудь между 10 и 100, так что будет намного проще сравнивать эту информацию с созданными нами классами по возрасту, так как эти числа близки друг другу; 4). разделить кредит по 1000. Рассуждение для этого случая такое же, как и для классов по доходу; 5). преобразовать информацию об автомобилях да-нет в информацию 1-0. В приложениях обнаружения знаний иногда полезно кодировать бинарные атрибуты в один бит, поскольку это облегчает эффективное выполнение алгоритмов распознавания образцов; 6). преобразовать дату приобретения в число месяцев, начиная с 1990г. Покупка в январе 1990г. соответствует месяцу номер 1; приобретение в декабре 1991- месяцу номер 24. Эта последняя операция помогает выполнять анализ временных отрезков на данных. Снова это творческое решение - кодирование в днях вероятно слишком детально, чтобы раскрыть общие временные зависимости. С другой стороны, следует кодировать в днях, чтобы определить нетипичное поведение заказчика по специальным дням типа Рождества, Пасхи и других праздников. Результаты процесса кодирования представлены в табл. 1.7. Таблица 1.7 Промежуточная стадия кодировки Номер Возраст Доход Кредит Владе- Владе- Район Месяц Журнал клиента (тыс. $) (тыс. $) лец авто лец дома (Р) покупки (ВА) (ВД) 23003 20 18.5 17.8 1 52 Автомобильный (А) 23003 20 18.5 17.8 1 42 Музыкальный (М) 23003 20 18.5 17.8 1 29 Комиксы (К) 23009 25 36.0 26.6 1 1 Нуль Комиксы (К) 23003 20 18.5 17.8 1 48 “Дом” (Д) Однако таблица в таком формате не очень полезна, если необходимо найти взаимосвязи между различными журналами. Каждая подписка представляется одной записью, хотя было бы бо- лее эффективно иметь краткий обзор всех журналов, подписанных каждым читателем. Поэтому выполняем заключительное преобразование над таблицей и создаем только одну запись для каждого читателя. Вместо того, чтобы иметь один атрибут " журналы" с пятью возможными значениями, мы создаём пять бинарных атрибутов по одному для каждого журнала. Если значение атрибута - "1" это означает, что читатель - подписчик, иначе - значение " 0 ". Такая операция называется "декомпозицией" - атрибут с кардинальным числом n заменяется на n бинарных атрибутов. Теперь имеем окончательно закодированное множество данных: номер клиента, возраст, доход, кредит, информация относительно собственности автомобиля и дома, код области, и пять битов, указывающих на какие журналы подписался заказчик (табл. 1.8). Таблица 1.8 Окончательная таблица Номер клиента 23003 23009 Возраст 20 25 Доход (тыс.дол.) 18.5 36.0 Кредит (тыс.дол.) 17.8 26.6 ВА ВД 1 Р А Д С М К 1 1 1 1 1 1 1 Обнаружение (извлечение) знаний. Этап обнаружения знаний является ядром процесса интеллектуального анализа и обработки знаний. Технология обнаружения знаний включает много методов и основана на идеи, что существует больше знаний, скрытых в данных, чем видно на поверхности. В настоящее время специалисты выделяют следующие основные методы извлечения знаний [3,4]: инструментальные средства запроса, статистическая техника, визуализация, интерактивная аналитическая обработка (OLAP), обучение, основанное на прецедентах (k-ближайший сосед), деревья решений, ассоциативные правила, нейронные сети, генетические алгоритмы. Фактически, в технологии обнаружения знаний необходимо различать четыре различных типа знания, которые могут быть извлечены из данных: 1). Поверхностное знание. Это информация, которая может быть легко найдена из баз данных, использующих инструментальное средство запроса типа структурированного языка запросов (SQL). 2). Многомерное знание. Это информация, которая может быть проанализирована, используя интерактивные аналитические инструментальные средства обработки OLAP. С помощью инструментальных средств OLAP можно быстро исследовать все виды кластеризации и различные упорядочения данных, но важно понимать, что большинство операций, которые можно делать с инструментом OLAP, могут также быть выполнены, используя SQL. Преимущество инструментальных средств OLAP состоит в том, что они оптимизированы для этого вида операций поиска и анализа. Однако, процедуры OLAP не так мощны, как процедуры обнаружения знаний, ибо они не могут искать оптимальные решения. 3). Скрытое знание. Это информация, которая может быть найдена относительно легко, используя алгоритмы распознавания образцов или машинного обучения. Для нахождения этих образцов также можно было бы использовать средства SQL, но это потребовало бы невероятно много времени. Алгоритм распознавания образцов может найти регулярности в базе данных за минуты или, в крайнем случае, всего за несколько часов, и в то же время чтобы достигнуть близкий результат, используя SQL средства, необходимо затратить месяцы. 4). Глубокое знание. Это информация, которая хранится в базе данных, но может быть обнаружена только, если имеется ключ, который сообщит нам, где смотреть. Различие между глубоким и скрытым знанием лучше всего можно объяснить в терминах пространства поиска. Скрытое знание - результат поиска в пространстве с пологим холмистым ландшафтом; алгоритм поиска может легко найти приемлемое оптимальное решение. Глубокое знание - это обычно результат поиска в пространстве, где существует только локальный оптимум, и отсутствуют какие-либо указания о любых возвышенностях по соседству. Алгоритм поиска может передвигаться вокруг этого ландшафта сколь угодно долго, не достигая хоть какого либо значительного результата. Примером этого может служить зашифрованная информация, хранимая в базе данных. Почти невозможно декодировать сообщение, которое зашифровано, если Вы не имеете ключа, который указывает что искать. Сообщение. Сообщение о результатах процесса обнаружения знаний может принимать много форм. В общем случае, можно использовать любой редактор сообщений или графическое инструментальное средство, чтобы сделать доступными результаты процесса.