CC BY
134
ИНТЕЛЛЕКТУАЛЬНЫЕ СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ
РЕШЕНИЯ
М.С. Игнатов
Научный руководитель - д.т.н., профессор О.Ф. Немолочнов
Проблематика проецирования данных и доступа к ним для ОЬЛР анализа. Проектирование и разработка уровней агрегирования и обработки данных. Использование распределенных вычислительных систем для обработки данных на различных уровнях. Акцентирование необходимости развития систем автоматической нормализации хранилищ данных.
Введение
История развития систем управления базами данных (СУБД) тесно связана с совершенствованием подходов к решению задач хранения данных и управления транзакциями. Развитый механизм управления транзакциями в современных СУБД сделал их основным средством построения ОЬТР-систем (систем онлайновой обработки транзакций), основной задачей которых является обеспечение выполнения операций с БД. Современные ОЬТР-системы позволяют совершать большое количество параллельных изменений, а также предоставляют возможность одновременного обращения множества пользователей к одним и тем же данным для чтения, редактирования и удаления.
Тем не менее, с развитием структур данных и увеличения объема информации в БД, а также повышением требований к уровню, глубине и качеству анализа стало ясным, что ОЬТР-системы уже не могут эффективно решать возлагаемые на них задачи. Эти системы достаточно успешно решают задачи сбора, хранения и поиска информации, но они не удовлетворяют требованиям, предъявляемым к современным системам поддержки принятия решения (СППР). Основной причиной неудачи развития ОЬТР-систем послужило противоречие требований к ОЬТР и СППР. Причина лежит даже не в противоречии требований, предъявленных к ОЬТР и СППР, а в эволюции требований к самому анализу данных, т.е. что мы хотим получить в ответ от системы.
Несмотря на развитие ОЬТР-систем, в СППР узким местом является как раз обращение к БД, особенно при удалении и изменении данных. Поэтому в настоящее время при разработке СППР огромное внимание уделяется проектированию БД в зависимости от объема и структуры данных, а также предполагаемых задач по их анализу. Порой изначально неверно спроектированная архитектура БД приводит к неудачному завершению всего проекта.
Обзор средств
Для построения СППР существует множество средств, направленных на упрощение структуры СППР, увеличения производительности и надежности системы. Две основные группы средств, применяемые при реализации, - хранилища данных (ХД) и набор аналитических инструментов. ХД предоставляет собой единую среду хранения корпоративных данных, организованных в структурах и оптимизированных для выполнения аналитических операций. Аналитические средства позволяют конечному пользователю, не имеющему специальных знаний в области информационных технологий, осуществлять поиск, отбор и обработку необходимых данных, а также представляют эти данные в терминах предметной области. Для пользователей различной квалификации СППР располагают различными типами интерфейсов доступа к своим сервисам.
Концепция хранилищ данных
На данный момент существует ряд концептуальных подходов, направленных на снижение нагрузки на БД и увеличения скорости анализа данных. Один из таких под-
ходов, заключающийся в разделении данных по разным БД в зависимости от выполняемых над этими данными операциями, получил название «Хранилище данных» (ХД). Оперативные и часто изменяющиеся данные в этом случае следует хранить в OLTP БД, а данные, предназначенные для глубокого полноценного анализа, - в другой БД. При этом ввиду того, что при анализе выполняются только операции чтения данных и отсутствуют транзакционные задержки, связанные с ожиданием завершения операций записи и изменения данных, скорость анализа существенно возрастает.
Как правило, наиболее удобным способом представления информации для человека является отображение зависимости между различными рассматриваемыми параметрами. Часто возникает потребность в построении зависимостей между большим числом различных параметров, но реляционная БД не удовлетворяет таким требованиям. Такая модель БД, по словам Е. Кодда, «не способна объединять, просматривать и анализировать данные с точки зрения множественности измерений» [3]. Таким образом, было предложено построение многомерной модели данных в виде так называемого «гиперкуба». При построении гиперкуба возникает проблема актуализации всего массива данных в момент добавления новых данных в ХД. Впрочем, как и проектирование БД, проектирование структуры гиперкуба и его физическая реализация влияют как на скорость доступа к данным и скорость их анализа, так и на успешность всего проекта в целом.
По сути, принято создавать гиперкуб, содержащий только агрегированные данные, и лишь при необходимости получения детальных данных выполнять операцию агрегации (Drill Down). При этом следует внимательно выбирать между большим количеством измерений куба и высокой степенью агрегированности данных, так как в первом случае мы получаем дублирование данных, а во втором - набор практических бесполезных данных, требующих извлечения из хранилища, что снижает производительность системы. В случае наличия в структуре слабо связанных или не связанных между собой данных существует возможность снижения нагрузки на ХД путем разнесения таких данных по различным физическим хранилищам, что приведет к минимизации объема обрабатываемых данных и повышению быстродействия ХД в целом. Например, ХД предприятия можно разделить на физические хранилища, содержащие данные не взаимодействующих или мало взаимодействующих отделов предприятия.
По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения «предприятие - подразделение - отдел -служащий». Измерение Время может даже включать два направления консолидации -«год - квартал - месяц - день» и «неделя - день», поскольку счет времени по месяцам и по неделям несовместим.
Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (online analytical processing - аналитическая обработка в реальном времени) (таблица 1).
Набор этих требований, послуживших фактическим определением OLAP, следует рассматривать как рекомендательный, а конкретные продукты оценивать по степени приближения к идеально полному соответствию всем требованиям.
№ Правило Описание
1. Многомерное концептуальное представление данных (MultiDimensional Conceptual View) Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, т.е. позволять аналитикам выполнять интуитивные операции «анализа вдоль и поперек» («slice and dice»), вращения (rotate) и размещения (pivot) направлений консолидации.
2. Прозрачность (Transparency) Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
3. Доступность (Accessibility) Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением оставшихся от старого наследства СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
4. Устойчивая производительность (Consistent Reporting Performance) С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
5. Клиент - серверная архитектура (ClientServer Architecture) Большая часть данных, требующих оперативной аналитической обработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров. Поэтому одним из требований является способность продуктов OLAP работать в среде клиент-сервер. Серверный компонент инструмента OLAP должен быть достаточно интеллекту аль-ным и обладать способностью, строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности.
6. Равноправие измерений (Generic Dimensionality) Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.
7. Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling) Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной для моделей, имеющих разное число измерений и различную разреженность данных.
8. Поддержка многопользовательского режима (Multi-User Support) Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.
9. Неограниченная поддержка кросс-мерных операций (Unrestricted Cross-dimensional Operations) Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.
10. Интуитивное манипулирование данными (Intuitive Data Manipulation) Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе.
11. Гибкий механизм генерации отчетов (Flexible Reporting) Должны поддерживаться различные способы визуализации данных, т.е. отчеты должны представляться в любой возможной ориентации.
12. Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels) Настоятельно рекомендуется допущение в каждом серьезном OLAP-инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели. Более того, каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.
Таблица 1. Правила оценки программных продуктов класса OLAP
Интеллектуальный анализ данных
В нынешнее время активно используется направление в аналитических технологиях обработки данных - Data Mining, что переводится как «добыча» или «раскопка данных». Нередко рядом с Data Mining встречаются слова «обнаружение знаний в базах данных» (knowledge discovery in databases) и «интеллектуальный анализ данных».
Цель Data Mining состоит в выявлении скрытых правил и закономерностей в наборах данных. Дело в том, что человеческий разум сам по себе не приспособлен для восприятия больших массивов разнородной информации. Человек к тому же не способен улавливать более двух-трех взаимосвязей даже в небольших выборках. Но и традиционная математическая статистика, долгое время претендовавшая на роль основного инструмента анализа данных, также нередко пасует при решении задач из реальной сложной жизни. Она оперирует усредненными характеристиками выборки, которые часто являются фиктивными величинами. Поэтому методы математической статистики оказываются полезными главным образом для проверки заранее сформулированных гипотез (verification-driven data mining).
Современные технологии Data Mining (discovery-driven data mining) обрабатывают информацию с целью автоматического поиска шаблонов, характерных для каких-либо фрагментов неоднородных многомерных данных. В отличие от оперативной аналити-
ческой обработки данных (OLAP) в Data Mining бремя формулировки гипотез и выявления необычных шаблонов переложено с человека на компьютер.
Типы выявляемых закономерностей
Выделяют пять стандартных типов закономерностей, которые позволяют выявлять методы Data Mining.
• Ассоциация имеет место в том случае, если несколько событий связаны друг с другом.
• Если существует цепочка связанных во времени событий, то говорят о последовательности.
• С помощью классификации выявляются признаки, характеризующие группу, к которой принадлежит тот или иной объект. Это делается посредством анализа уже классифицированных объектов и формулирования некоторого набора правил.
• Кластеризация отличается от классификации тем, что сами группы заранее не заданы. С помощью кластеризации средства Data Mining самостоятельно выделяют различные однородные группы данных.
• Основой для всевозможных систем прогнозирования служит историческая информация, хранящаяся в БД в виде временных рядов. Если удается построить математическую модель и найти шаблоны, адекватно отражающие эту динамику, есть вероятность, что с их помощью можно предсказать и поведение системы в будущем.
Заключение
Обобщая вышеизложенный материал, хочется отметить масштабность и широту текущих исследований вопросов организации хранения и обработки данных, а также большое количество используемых для решения этих задач технологий, каждая из которых даже сама по себе требует существенных ресурсов для изучения и развития. Если методологии и технологии решения задач, связанных с выявлением закономерностей в больших объемах данных, в настоящее время развиваются стремительно, то таким вопросам, как заблаговременное проектирование оптимальных структур ХД и гиперкуба и распределение физического расположения данных, а также поддержка актуальности и оптимальности их состояния и структуры в условиях быстро меняющейся внешней среды, уделяется недостаточно внимания. Однако значимость этих вопросов в скором времени станет существенной в связи с постоянно растущими объемами обрабатываемой информации, а также повышающимися требованиями к оперативности их обработки. Таким образом, в ближайшем будущем необходимо уделять особое внимание созданию подсистем СППР, которые будут в состоянии решать подобные задачи.
Список литературы
1. Power D.J. Web-based and model-driven decision support systems: concepts and issues. Americas Conference on Information Systems, Long Beach, California, 2000.
2. Гасанов Э.Э. О сложности поиска в базах данных // Искусственный интеллект: Межвузовский сборник трудов. - Саратов, Изд-во Саратовского университета, 1993. - С. 41-56.
3. Codd E.F. Relational Database: A Practical Foundation for Productivity // Commun. of ACM. - 1982. - V. 25/ - № 2. - P. 140-155.
4. Литвак Б.Г. Разработка управленческого решения - М.: Издательство «Дело», 2004. - 392 с.
5. Thieranf R.J. Decision Support Systems for Effective Planing and Control. -Englewood Cliffs, N.J: Prentice Hall, Inc, 1982.
