Предварительные знания
 Скачать 3.17 Mb.
|
|
Классификация СППР Вопрос классификаций СППР на сегодняшний день является актуальным, продолжаются разработки новых таксономий. Рассмотрим две из них. Ниже приведена классификация СППР по сходству некоторых признаков (D.J. Power, 2000). C подробным описанием групп можно ознакомиться в [75]. • СППР, ориентированные на данные (Data-driven DSS, Data-oriented DSS); • СППР, ориентированные на модели (Model-driven DSS); • СППР, ориентированные на знания (Knowledge-driven DSS); • СППР, ориентированные на документы (Document-driven DSS); • СППР, ориентированные на коммуникации и групповые СППР (Communications-Driven ? Group DSS); • Интер-организованные и Интра-организованные СППР (Inter-Organizational або Intra- Organizational DSS); • Специфически функциональные СППР или СППР общего назначения (Function-Specific або General Purpose DSS); • СППР на базе Web (Web-Based DSS). В зависимости от данных, с которыми работают СППР, выделяют два основных их типа СППР: EIS и DSS [75,78]. EIS (Execution Information System) - информационная система Руководства, ИСР. СППР этого типа являются оперативными, предназначенными для немедленного реагирования на текущую ситуацию. В большинстве они ориентированы на неподготовленного пользователя, потому имеют упрощенный интерфейс, базовый набор предлагаемых возможностей, фиксированные формы представления информации и перечень решаемых задач. Такие системы основаны на типичных запросах, число которых относительно невелико; отчеты, полученные в результате таких запросов, представляются в максимально удобном виде. DSS (Decision Support System). К системам этого типа относят многофункциональные системы анализа и исследования данных. Они предполагают глубокую проработку данных, которую можно использовать в процессе принятий решений. Системы этого типа, в отличие от EIS, рассчитаны на пользователей, имеющих как знания в предметной области, так и возможности использования современных компьютерных технологий. Этим системам присущи черты искусственного интеллекта, за счет 197 возможности проработки исходных данных в конкретные выводы по поставленной задаче. Такие системы имеет смысл создавать, если есть основания для обобщения и анализа данных и процессов их обработки. В последнее время к СППР относят только второй тип, т.е. DSS. Системы этого типа иногда называют динамическими, т.е. они должны быть ориентированы на обработку неожиданных (ad hoc) запросов. Поддержка принятия решений на основе накопленных данных может выполняться в трех базовых сферах [79]. Более подробно с этим материалом можно ознакомиться в [11]. 1. Область детализированных данных (OLTP-системы). Целью большинства таких систем является поиск информации, это так называемые информационно-поисковые системы. Они могут использоваться в качестве надстроек над системами обработки данных или как хранилища данных. 2. Сфера агрегированных показателей ( OLAP-системы). Задачами OLAP систем является обобщение, агрегация, гиперкубическое представление информации и многомерный анализ. Это могут быть многомерные СУБД или же реляционные базы с предварительной агрегацией данных. 3. Сфера закономерностей (Data Mining). Такое деление систем на EIS и DSS не обязательно означает реализацию СППР одного из типов. Они могут существовать параллельно, когда каждая из систем предоставляет свои функции определенной категории пользователей. Общая схема поддержки принятия решений, предлагаемая в [80], включает: • помощь ЛПР при оценке состояния управляемой системы и воздействий на нее; выявление предпочтений ЛПР; • генерацию возможных решений; • оценку возможных альтернатив, исходя из предпочтений ЛПР; • анализ последствий принимаемых решений и выбор лучшего с точки зрения ЛПР. OLAP-системы В основе концепции OLAP, или оперативной аналитической обработки данных (On-Line Analytical Processing), лежит многомерное концептуальное представление данных (Multidimensional conceptual view). Термин OLAP введен Коддом (E. F. Codd) в 1993 году. Главная идея данной системы заключается в построении многомерных таблиц, которые могут быть доступны для запросов пользователей. Эти многомерные таблицы или так называемые многомерные кубы строятся на основе исходных и агрегированных данных. И исходные, и агрегированные данные для многомерных таблиц могут храниться как в реляционных, так и в многомерных базах данных. Взаимодействуя с OLAP-системой, пользователь может осуществлять гибкий просмотр информации, получать различные срезы данных, выполнять аналитические операции детализации, свертки, сквозного распределения, 198 сравнения во времени. Вся работа с OLAP-системой происходит в терминах предметной области. OLAP-продукты Сейчас на рынке представлено огромное многообразие OLAP-систем. Разработано несколько классификаций продуктов этого типа: например, классификация по способу хранения данных, по месту нахождения OLAP-машины, по степени готовности к применению. Рассмотрим первую из приведенных классификаций. Существует три способа хранения данных в OLAP-системах или три архитектуры OLAP- серверов [77]: • MOLAP (Multidimensional OLAP); • ROLAP (Relational OLAP); • HOLAP (Hybrid OLAP). Таким образом, согласно этой классификации OLAP-продукты могут быть представлены тремя классами систем. • В случае MOLAP, исходные и многомерные данные хранятся в многомерной БД или в многомерном локальном кубе. Такой способ хранения обеспечивает высокую скорость выполнения OLAP-операций. Но многомерная база в этом случае чаще всего будет избыточной. Куб, построенный на ее основе, будет сильно зависеть от числа измерений. При увеличении количества измерений объем куба будет экспоненциально расти. Иногда это может привести к "взрывному росту" объема данных, парализующему в результате запросы пользователей. • В ROLAP-продуктах исходные данные хранятся в реляционных БД или в плоских локальных таблицах на файл-сервере. Агрегатные данные могут помещаться в служебные таблицы в той же БД. Преобразование данных из реляционной БД в многомерные кубы происходит по запросу OLAP-средства. При этом скорость построения куба будет сильно зависеть от типа источника данных, и поэтому время отклика системы порой становится неприемлемо большим. • В случае использования гибридной архитектуры, т.е. в HOLAP-продуктах, исходные данные остаются в реляционной базе, а агрегаты размещаются в многомерной. Построение OLAP- куба выполняется по запросу OLAP-средства на основе реляционных и многомерных данных. Такой подход позволяет избежать взрывного роста данных. При этом можно достичь оптимального времени исполнения клиентских запросов. Следующая классификация - по месту размещения OLAP-машины. По этому признаку OLAP-продукты делятся на OLAP-серверы и OLAP-клиенты. В серверных OLAP-средствах вычисления и хранение агрегатных данных выполняются отдельным процессом - сервером. Клиентское приложение получает только результаты запросов к многомерным кубам, которые хранятся на сервере. Некоторые OLAP-серверы поддерживают хранение данных только в реляционных базах, другие - только в многомерных. Многие современные OLAP-серверы поддерживают все три способа хранения данных: MOLAP, ROLAP и HOLAP. Одним из самых распространенным в настоящее время серверным решением является OLAP-сервер корпорации Microsoft. OLAP-клиент устроен по-другому. Построение многомерного куба и OLAP-вычисления выполняются в памяти клиентского компьютера. 199 С помощью OLAP-сервера может быть организовано физическое хранение обработанной многомерной информации [81], что позволяет быстро выдавать ответы на запросы пользователя. Кроме того, предусматривается преобразование данных из реляционных и других баз в многомерные структуры в режиме реального времени. Каким образом реляционные и многомерные средства работают совместно? OLAP продукты вливаются в существующую корпоративную инфраструктуру путем интегрирования с реляционными системами. Администраторы баз данных либо загружают реляционные данные в многомерный кэш, либо настраивают кэш для доступа к SQL-данным. В таблице 17.1 приведены сравнительные характеристики различных моделей управления данными [81]: Таблица 17.1. Сравнительные характеристики различных моделей управления данными Характеристики Реляционные СУБД OLTP Реляционные СУБД СППР/Хранилища данных Многомерные СУБД OLAP Типовая операция Обновление Отчет Анализ Уровень аналитических требований Низкий Средний Высокий Экраны Неизменяемые Определяемые пользователем Определяемые пользователем Объем данных на транзакцию Небольшой От малого до большого Большой Уровень данных Детальные Детальные и суммарные В основном суммарные Сроки хранения данных Только текущие Исторические и текущие Исторические, текущие и прогнозируемые Структурные элементы Записи Записи Массивы Интеграция OLAP и Data Mining Обе технологии можно рассматривать как составные части процесса поддержки принятия решений. Однако эти технологии как бы движутся в разных направлениях: OLAP сосредотачивает внимание исключительно на обеспечении доступа к многомерным данным, а методы Data Mining в большинстве случаев работают с плоскими одномерными таблицами и реляционными данными. Интеграция технологий OLAP и Data Mining "обогащает" функциональность и одной, и другой технологии. Эти два вида анализа должны быть тесно объединены, чтобы интегрированная технология могла обеспечивать одновременно многомерный доступ и поиск закономерностей. По словам N. Raden, "многие компании создали ... прекрасные хранилища данных, идеально разложив по полочкам горы неиспользуемой информации, 200 которая сама по себе не обеспечивает ни быстрой, ни достаточно грамотной реакции на рыночные события" [82]. K. Parsaye [83] вводит составной термин "OLAP Data Mining" (многомерный Data Mining) для обозначения такого объединения. Средство многомерного интеллектуального анализа данных должно находить закономерности как в детализированных, так и в агрегированных с различной степенью обобщения данных. Анализ многомерных данных должен строиться над специального вида гиперкубом, ячейки которого содержат не произвольные численные значения (количество событий, объем продаж, сумма собранных налогов), а числа, определяющие вероятность соответствующего сочетания значений атрибутов. Проекции такого гиперкуба (исключающие из рассмотрения отдельные измерения) также должны исследоваться на предмет поиска закономерностей. J. Han предлагает еще более простое название - "OLAP Mining" и выдвигает несколько вариантов интеграции двух технологий. 1. "Cubing then mining". Возможность выполнения интеллектуального анализа должна обеспечиваться над любым результатом запроса к многомерному концептуальному представлению, то есть над любым фрагментом любой проекции гиперкуба показателей. 2. "Mining then cubing". Подобно данным, извлеченным из хранилища, результаты интеллектуального анализа должны представляться в гиперкубической форме для последующего многомерного анализа. 3. "Cubing while mining". Этот гибкий способ интеграции позволяет автоматически активизировать однотипные механизмы интеллектуальной обработки над результатом каждого шага многомерного анализа (перехода между уровнями обобщения, извлечения нового фрагмента гиперкуба и т.д.). На сегодняшний день немногие производители реализуют Data Mining для многомерных данных. Кроме того, некоторые методы Data Mining, например, метод ближайших соседей или байесовская классификация, в силу их неспособности работать с агрегированными данными неприменимы к многомерным данным. Хранилища данных Информационные системы современных предприятий часто организованы таким образом, чтобы минимизировать время ввода и корректировки данных, т.е. организованы не оптимально с точки зрения проектирования базы данных. Такой подход усложняет доступ к историческим (архивным) данным. Изменения структур в базах данных информационных систем очень трудоемки, а иногда попросту невозможны. В то же время, для успешного ведения современного бизнеса необходима актуальная информация, предоставляемая в удобном для анализа виде и в реальном масштабе времени. Доступность такой информации позволяет как оценивать текущее положение дел, так и делать прогнозы на будущее, следовательно, принимать более взвешенные и обоснованные решения. К тому же, основой для принятия решений должны быть реальные данные. Если данные хранятся в базах данных различных информационных систем предприятия, при их анализе возникает ряд сложностей, в частности, значительно возрастает время, необходимое для обработки запросов; могут возникать проблемы с поддержкой 201 различных форматов данных, а также с их кодированием; невозможность анализа длительных рядов ретроспективных данных и т.д. Эта проблема решается путем создания хранилища данных. Задачей такого хранилища является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. На основе хранилищ данных возможно составление всевозможной отчетности, а также проведение оперативной аналитической обработки и Data Mining. Билл Инмон (Bill Inmon) определяет хранилища данных как "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления" и призванные выступать в роли "единого и единственного источника истины", который обеспечивает менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений [84]. Предметная ориентация хранилища данных означает, что данные объединены в категории и сохраняются соответственно областям, которые они описывают, а не применениям, их использующим. Интегрированность означает, что данные удовлетворяют требованиям всего предприятия, а не одной функции бизнеса. Этим хранилище данных гарантирует, что одинаковые отчеты, сгенерированные для разных аналитиков, будут содержать одинаковые результаты. Привязка ко времени означает, что хранилище можно рассматривать как совокупность "исторических" данных: возможно восстановление данных на любой момент времени. Атрибут времени явно присутствует в структурах хранилища данных. Неизменность означает, что, попав один раз в хранилище, данные там сохраняются и не изменяются. Данные в хранилище могут лишь добавляться. Ричард Хакаторн, другой основоположник этой концепции, писал, что цель Хранилищ Данных - обеспечить для организации "единый образ существующей реальности" [86]. Другими словами, хранилище данных представляет собой своеобразный накопитель информации о деятельности предприятия. Данные в хранилище представлены в виде многомерных структур под названием "звезда" или "снежинка". Преимущества использования хранилищ данных Хранилище данных имеет преимущества в сравнении с использованием оперативных систем или баз данных, в [88] приведены следующие из них: • В отличие от оперативных систем, хранилище данных содержит информацию за весь требуемый временной интервал - вплоть до нескольких десятилетий - в едином информационном пространстве, что делает такие хранилища идеальной основой для выявления трендов, сезонных зависимостей и других важных аналитических показателей. 202 • Как правило, информационные системы предприятия хранят и представляют аналогичные данные по-разному. Например, одни и те же показатели могут храниться в различных единицах измерения. Одна и та же продукция или одни и те же клиенты могут именоваться по-разному. В системах хранилищ несоответствия в данных устраняются на этапе сбора информации и погружения ее в единую базу данных. При этом организуются единые справочники, все показатели в которых приводятся к одинаковым единицам измерения. • Очень часто оперативные системы вследствие ошибок операторов содержат некоторое количество неверных данных. На этапе помещения в хранилище данных информация предварительно обрабатывается. Данные по специальной технологии проверяются на соответствие заданным ограничениям и при необходимости корректируются (очищаются). Технология обеспечивает построение аналитических отчетов на основе надежных данных и своевременное оповещение администратора хранилища об ошибках во входящей информации. • Универсализация доступа к данным. Хранилище данных предоставляет уникальную возможность получать любые отчеты о деятельности предприятия на основе одного источника информации. Это позволяет интегрировать данные, вводимые и накапливаемые в различных оперативных системах, легко и просто сравнивать их. При этом в процессе создания отчетов пользователь не связан различиями в доступе к данным оперативных систем. • Ускорение получения аналитических отчетов. Получение отчетов при помощи средств, предоставляемых оперативными системами, - способ неоптимальный. Эти системы затрачивают значительное время на агрегирование информации (расчет суммарных, средних, минимальных, максимальных значений). Кроме того, в текущей базе оперативной системы находятся только самые необходимые и свежие данные, в то время как информация за прошлые периоды помещается в архив. Если данные приходится получать из архива, продолжительность построения отчета возрастает еще в два-три раза. Следует также учитывать, что сервер оперативной системы зачастую не обеспечивает необходимую производительность при одновременном построении сложных отчетов и вводе информации. Это может катастрофически сказываться на работе предприятия, так как операторы не смогут оформлять накладные, фиксировать отгрузку или получение продукции в то время, когда выполняется построение очередного отчета. Хранилище данных позволяет решить эти проблемы. Во-первых, работа сервера хранилища не мешает работе операторов. Во-вторых, в хранилище помимо детальной информации содержатся и заранее рассчитанные агрегированные значения. В-третьих, в хранилище архивная информация всегда доступна для включения в отчеты. Все это позволяет значительно сократить время создания отчетов и избежать проблем в оперативной работе. • Построение произвольных запросов. Информацию в хранилище данных недостаточно только централизовать и структурировать. Аналитику нужны средства визуализации этой информации, инструмент, с помощью которого легко получать данные, необходимые для принятия своевременных решений. Одно из главных требований любого аналитика - простота формирования отчетов и их наглядность. В случае оперативных систем построение отчетов часто лишено гибкости; чтобы создать новый отчет, приходится задействовать специалистов ИТ-отдела, которые объединяют данные нескольких систем. В случае же использования хранилища данных решение проблемы предоставляет технология OLAP (On-Line Analytical Processing). Эта технология обеспечивает доступ к данным в терминах, привычных для аналитика. Технология OLAP базируется на концепции многомерного представления данных. Действительно, каждое числовое значение, содержащееся в хранилище данных, имеет до нескольких десятков атрибутов (например, количество продаж определенным менеджером в определенном регионе на определенную дату и т.п.). Таким образом, можно считать, что работа идет с многомерными структурами данных (многомерными кубами), в которых числовые 203 значения расположены на пересечении нескольких измерений. Именно этот подход используется в OLAP-системах. Они предоставляют гибкие средства навигации по многомерным структурам - так называемые OLAP-манипуляции. С их помощью аналитик может получать различные срезы данных, "крутить" данные. Как видно из перечисленных преимуществ использования технологии хранилищ данных, большая их часть может существенно упростить, повысить скорость и качественно улучшить процесс Data Mining. Таким образом, комплексное внедрение этих технологий дает разработчикам и пользователям неоспоримые преимущества перед использованием разрозненных баз данных различных информационных систем при создании систем поддержки принятия решений. 204 |