Системы поддержки решений

 

Министерство образования  Российской Федерации Российский государственный  профессионально-педагогический университет Институт экономики  и управления           Реферат По курсу  «Информационные системы в Маркетинге»   на тему «Системы поддержки  решений»     Выполнил: студент заочного отделения II курса, группы   Допуск к собеседованию   Рецензент:                 Екатеринбург 2011

 

СОДЕРЖАНИЕ

Введение……………………………………………………………………………...4

1. Понятие систем поддержки принятия решений………………………………...6

2. Характеристика систем поддержки принятия решений………………………..7

3. Архитектурно-технологическая схема СППР…………………………………………9

4. Хранилища данных……………………………………………………………...10

5. OLAP-технологии………………………………………………………………..12

6. Интеллектуальный  анализ данных……………………………………………..13

Заключение………………………………………………………………………….15

Список используемой литературы………………………………………………...16

 

ВВЕДЕНИЕ

Задачи, решаемые с помощью  информационных технологий, лежат в  пределах от сильно структурируемых (повторяющихся  и рутинных, с заранее выработанной процедурой, детально описывающей алгоритм получения решения) до неструктурируемых, для которых описание процесса получения решения невозможно.

Большую группу в этой совокупности составляют слабо структурируемые  задачи, решение которых связано с определением количественных и качественных переменных.

Это привело к созданию программных систем, основанных как  на традиционных методах алгоритмической  обработки данных, так и на методах  создания и использования баз  знаний. Наиболее плодотворными программными системами для решения таких задач является новая информационная технология, связанная с разработкой экспертных систем (ЭС) и системы поддержки принятия решений.

 

1. Понятие систем  поддержки принятия решений

Под системой поддержки принятия решений (СППР) понимаются   человеко-машинные системы, которые позволяют лицам, принимающим решение, использовать данные и знания объективного и субъективного характера для решения слабо структурированных (плохо формализованных) проблем.

СППР требует трех первичных компонентов: модели управления, управления данными для сбора и ручной обработки данных и управления диалогом для облегчения доступа пользователя к СППР

Пользователь взаимодействует  с СППР через пользовательский интерфейс, выбирая частную модель и набор  данных, которые нужно использовать, а затем СППР представляет результаты пользователю через тот же самый пользовательский интерфейс.

Модель управления и  управления данными действуют, в  основном, незаметно и варьируются  от простой модели до сложной комплексной модели планирования, основанной на математическом программировании.

Наиболее широкой сферой практического применения СППР являются планирование и прогнозирование  для различных видов управленческой деятельности.

Пример популярного  типа СППР – СППР в виде генератора финансового отчета. С помощью электронной таблицы, например, Microsoft Excel, создаются модели, чтобы прогнозировать различные элементы организации или финансового состояния. В качестве данных используются предыдущие финансовые отчеты организации. Начальная модель включает различные предположения относительно будущих трендов в категориях расхода и дохода. После рассмотрения результатов базовой модели менеджер проводит ряд исследований типа «Что, если...?», изменяя одно или большее количество предположений, чтобы определить их влияние на исходное состояние. Это простые типы генератора финансового отчета, но мощные СППР для руководства принятием финансовых решений.

 

2. Характеристика систем поддержки принятия решений

Системы поддержки принятия решений:

• предполагают гибкость пользователей, адаптируемость и быструю реакцию;
• допускают, чтобы пользователи управляли входом и выходом;
• оперируют с небольшой помощью профессиональных программистов или без нее;
• обеспечивают поддержку для решений и проблем, которые не могут быть определены заранее;
• используют сложный анализ и инструментальные средства моделирования.

СППР имеют большую  аналитическую мощность, чем другие системы: они построены с рядом  моделей, чтобы анализировать данные. Системы СППР интерактивны; пользователь может изменять предположения и включать новые данные.

Процесс принятия решений  человеком, как блоком принятия решений  в СППР, включаетчетыре стадии:

• распознавание или осмысление- состоит из идентификации и понимания проблем, встречающихся в организации: почему проблемы возникают, где и с каким результатом. Традиционные управляющие информационные системы (УИС), которые поставляют широкое многообразие детальной информации, могут помогать опознавать проблемы, особенно если системы сообщают об исключениях;
• проект или продумывание - в течение принятия решений лицо, принимающее решение, продумывает возможные варианты решения проблем. Малые системы СППР идеальны в этой стадии принятия решений, потому что они оперируют на простых моделях, могут быть быстро развиты и работать с ограниченными данными;
• выбор - заключается в подборе решений среди альтернатив. Здесь изготовитель решений мог бы нуждаться в большой системе СППР, чтобы использовать более обширные данные относительно ряда альтернатив и комплексные аналитические модели, чтобы объяснить все затраты, следствия и возможности;
• реализация - в течение выполнения решения менеджеры могут использовать систему сообщения, которая поставляет обычные доклады относительно прогресса определенного решения. Системы поддержки выполнения могут быть от полномасштабной управляющей информационной системы до меньших систем, таких, как программное обеспечение планирования проекта, использующего микрокомпьютеры.

Стадии принятия решений  могут следовать и в другой последовательности.

СППР предназначены, чтобы помогать проектировать, оценивать альтернативы и контролировать процесс реализации.

СППР помогают находить ответы на следующие типичные вопросы:

1. Анализ примеров (case analysis) – оценка значений выходных величин для заданного набора значений входных переменных.
2. Параметрический анализ {«Что, если... ?») – оценка поведения выходных величин при изменении значений входных переменных.
3. Анализ чувствительности - исследование поведения результирующих  переменных в зависимости от изменения значений одной или нескольких входных переменных.
4. Анализ возможностей – нахождение значений входной переменной, которые обеспечивают желаемый результат (известен также под названием «поиск целевых решений», «анализ значений целей», «управление по целям»).
5. Анализ влияния – выявление для выбранной результирующей переменной всех входных переменных, влияющих на ее значение, и оценка величины изменения результирующей переменной при заданном изменении входной переменной, скажем, на 1 %.
6. Анализ данных – прямой ввод в модель ранее имевшихся данных и манипулирование ими при прогнозировании.
7. Сравнение и агрегирование – сравнение результатов двух или более прогнозов, сделанных при различных входных предположениях, или сравнение предсказанных результатов с действительными, или объединение результатов, полученных при различных прогнозах или для разных моделей.
8. Командные последовательности (sequences) – возможность записывать, исполнять, сохранять для последующего использования регулярно выполняемые серии команд и сообщений.
9. Анализ риска – оценка изменения выходных переменных при случайных изменениях входных величин.
10. Оптимизация – поиск значений управляемых входных переменных, обеспечивающих наилучшее значение одной или нескольких результирующих переменных.

3. Архитектурно-технологическая схема СППР

Концепция систем поддержки  принятия решений (СППР) включает целый  ряд средств, объединенных общей  целью — способствовать принятию рациональных и эффективных управленческих решений.

Система поддержки принятия решений — это диалоговая автоматизированная система, использующая правила принятия решений и соответствующие модели с базами данных, а также интерактивный компьютерный процесс моделирования. [4, С. 128]

Основу СППР составляет комплекс взаимосвязанных моделей  с соответствующей информационной поддержкой исследования, экспертные и интеллектуальные системы, включающие опыт решения задач управления и обеспечивающие участие коллектива экспертов в процессе выработки рациональных решений.

Ниже на рис. 1 приведен архитектурно-технологическая схема информационно-аналитической поддержки принятия решений:

Поддержка принятия решений

Рис. 1. Архитектурно-технологическая схема СППР

Первоначально информация хранится в оперативных базах данных OLTP-систем. Но ее сложно использовать в процессе принятия решений по причинам, о которых будет сказано ниже. Агрегированная информация организуется в многомерное хранилище данных. Затем она используется в процедурах многомерного анализа (OLAP) и для интеллектуального анализа данных (ИАД). Рассмотрим более подробно каждый элемент этой схемы.

4. Хранилища  данных

Ясно, что принятие решений  должно основываться на реальных данных об объекте управления. Такая информация обычно хранится в оперативных базах данных OLTP-систем. Но эти оперативные данные не подходят для целей анализа, так как для анализа и принятия стратегических решений в основном нужна агрегированная информация. Кроме того, для целей анализа необходимо иметь возможность быстро манипулировать информацией, представлять ее в различных аспектах, производить различные нерегламентированные запросы к ней, что затруднительно реализовать на оперативных данных по соображениям производительности и технологической сложности.

Решением данной проблемы является создание отдельного хранилища данных (ХД), содержащего агрегированную информацию в удобном виде. Целью построения хранилища данных является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. При этом в основе концепции хранилищ данных лежит признание необходимости разделения наборов данных, используемых для транзакционной обработки, и наборов данных, применяемых в системах поддержки принятия решений. Такое разделение возможно путем интеграции разъединенных в различных системах обработки данных (СОД) и внешних источниках детализированных данных в едином хранилище, их согласования и, возможно, агрегации.

Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а действительную реализацию единого интегрированного источника данных. Альтернативным по отношению к этой концепции способом формирования единого взгляда на корпоративные данные является создание виртуального источника, опирающегося на распределенные базы данных различных СОД. При этом каждый запрос к такому источнику динамически транслируется в запросы к исходным базам данных, а полученные результаты на лету согласовываются, связываются, агрегируются и возвращаются к пользователю. Однако, при внешней элегантности, такой способ обладает рядом существенных недостатков.

1. Время обработки запросов к распределенному хранилищу значительно превышает соответствующие показатели для централизованного хранилища. Кроме того, структуры баз данных СОД, рассчитанные на интенсивное обновление одиночных записей, в высокой степени нормализованы, поэтому в аналитическом запросе к ним требуется объединение большого числа таблиц, что также приводит к снижению быстродействия.
2. Интегрированный взгляд на распределенное корпоративное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Таким образом, временная недоступность хотя бы одного из источников может либо сделать работу информационно-аналитической системы (ИАС) невозможной, либо привести к ошибочным результатам.
3. Выполнение сложных аналитических запросов над таблицами СОД потребляет большой объем ресурсов сервера БД и приводит к снижению быстродействия СОД, что недопустимо, так как время выполнения операций в СОД часто весьма критично.
4. Различные СОД могут поддерживать разные форматы и кодировки данных, данные в них могут быть несогласованны. Очень часто на один и тот же вопрос может быть получено несколько вариантов ответа, что может быть связано с несинхронностью моментов обновления данных, отличиями в трактовке отдельных событий, понятий и данных, изменением семантики данных в процессе развития предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. В таком случае цель – формирование единого непротиворечивого взгляда на объект управления – может не быть достигнута.
5. Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД. Основное назначение СОД – оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе.

Таким образом, хранилище данных функционирует по следующему сценарию. По заданному регламенту в него собираются данные из различных источников – баз данных систем оперативной обработки. В хранилище поддерживается хронология: наравне с текущими хранятся исторические данные с указанием времени, к которому они относятся. В результате необходимые доступные данные об объекте управления собираются в одном месте, приводятся к единому формату, согласовываются и, в ряде случаев, агрегируются до минимально требуемого уровня обобщения.