Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ИСМ ответы.doc
Скачиваний:
15
Добавлен:
02.08.2019
Размер:
1.82 Mб
Скачать

Сппр, использующие независимые витрины данных

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

СППР на основе двухуровневого хранилища данных

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

СППР на основе трехуровневого хранилища данных

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

Структура

Выделяют четыре основных компонента:

  • информационные хранилища данных;

  • средства и методы извлечения, обработки и загрузки данных (ETL);

  • многомерная база данных и средства анализа OLAP;

  • средства Data Mining.

Преимущества

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

Динамическое моделирование

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

15.

База моделей в системах поддержки принятия решений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Система управления базой моделей должна обладать следующими возможностями: создавать новые модели или изменять существующие, поддерживать и обновлять параметры моделей, манипулировать моделями.

Сетевые технологии в управлении

Сложные сети требуют комплексного подхода к управлению. Если вся сеть состоит из десятка свичей и управляется одним инженером, то для поддержания ее в рабочем состоянии достаточно набота простейших скриптов, нескольких электронных таблиц и любой примитивной системы мониторинга. В более крупных сетях, сотоящих из разношерсного оборудования разных вендоров, поддерживаемого десятками инженеров, разбросанных по разным городам и странам, начинают вылезать весьма специфичные проблемы: ворох самописных скриптов становится абсолютно неуправляемым и непредсказуемым в поведении, на интеграцию различных систем управления между собой уходит больше ресурсов, чем на разработку с нуля и установку и так далее. В результате быстро приходит понимание, что решать задачу системы управления сложной сетью можно только комплексно. Еще в начале 80-х комитет ISO выделил основные компоненты системы управления сетью. Модель получила название FCAPS. По версии ISO, для успешного управления сетью надо уметь управлять отказами (F), конфигурацией оборудования и сервисов (C ), собирать и обрабатывать статистику по потреблению услуг (A), оценивать производительность (P) и централизованно управлять безопасностью (S). Прошедшие три десятка лет не добавили ничего принципиально нового, и все задачи управления сетью так или иначе прыгают вокруг основных составляющих. Коммерческие комплексы подобного рода весьма дороги и далеко не безгрешны, а среди open-source систем присутсвовал явный и откровенный пробел, что просто подталкивало на разработку своего велосипеда. В результате обобщения нашего личного опыта по созданию и эксплуатации сетей, после долгих проб и ошибок появилась система NOC В целом нужно отметить, что NOC — это не система мониторинга, и не альтернатива zabbix/nagios/кактус/etc. Основная задача — автоматизация повседневной работы центра управления сетью. При разработке системы мы исходили из нескольких предпосылок: Одна из предпосылок — источник информации должен быть один и им должно быть удобно пользоваться. Вторая предпосылка — делегирование полномочий. Данные в системе набиваются разными людьми из разных подразделений. Третья предпосылка — нечего цацкаться с каждой отдельной железкой — это разменная монета. Сегодня здесь может стоять шеститонник, завтра окажется Force10. Для управления сетью нужен интерфейс более высокого уровня, который по максимуму абстрагирован от конкретного вендора и конткретной модели. Четвертая — гремлинов среди гоблинов всегда хватает. Существенная часть аварий вызвана человеческим фактором. Нужно иметь возможность быстро понять, что же такого наворотили и что привело к аварии. Для этого надо сопоставлять и изменения конфигурации, и события syslog/snmp и многое другое. На настоящий момент NOC состоит из нескольких модулей:

DNS Management — если уж привели в порядок адреса, то почему бы не синхронизировать все с DNS. Таким образом получается единый интерфейс для управления зонами и provisioning зон на различные DNS серверы по описанной логике. Например, данные для зон можно генерировать автоматом, зоны города и клиентов этого города уедут на серверы, расположенные в этом городе. Отпадает необходимость в slave зонах, можно легко мигрировать на другие DNS-серверы. Попутно по базам регистраторов отслеживается, когда протухнет конкретный домен.

Service Activation — интерфейс для работы с оборудованием. Поддерживается широкий спектр оборудования. Основная идея заключается в том, что существует набор скриптов-кубиков, имеющих общий интерфейс, выполняющих какое-нибудь действие и целиком и полностью абстрагирующих особенности работы конкретной железки. Примеры — получить конфиг, получить версию софта, создать vlan, и так далее. Полученные кубики можно заставить работать в разных комбинациях и решать при помощи них весьма широкий спектр задач. Также реализован механизм map/reduce tasks, который позволяет выполнить однотипное действие на большом количестве оборудования и проанализировать результат исполнения.

Configuration Management — отслеживает, где, что и когда изменилось. Начиналось как интерфейс к mercurial, сейчас функционал модуля стал гораздо больше. В частности, при изменении конфига свича в городе специально выделенному инженеру в этом городе придет сообщение. В большом количестве случаев он успеет оперативно отреагировать на местную самодеятельность, даст по шапке и предотвратит аварию. Система умеет проверять полученные конфиги на предмет соответсвия установленным политикам и способна принимать активные действия в случае подозрительных ситуаций.

VC Management — управление VLAN'ами. При полном развертывании достаточно заносить и удалять vlan'ы в базу, и они автоматически будут появляться на нужных свичах, вне зависимости от вендора. Например, в одной инсталляции надо было рулить одновременно горой кисковских шеститонников, четырехтоников, nexus'ов, 3750/CBS3120, force10 E, C, S-series, HP ProCurve и GbE2c и мелкими Alcatel'ами. Fault Management — сбор, анализ и кореллирование событий syslog/snmp trap с железа. NOC применяет оригинальный и гибкий подход к обработке событий. FM — отдельная тема для разговора, можно сказать, что вменяемых open-source реализаций просто нет, а вменяемые коммерческие можно пересчитать по пальцам одной руки. Текущая реализация FM в NOC способна обрабатывать сотни событий в секунду и выявлять среди них аномальные и аварийные ситуации. Коррелятор находит связи между авариями и пытается установить первопричину. Например, упавший линк способен породить сотни аварий разных типов в разных местах сети. Коррелятор, оперируя знаниями о топологии сети и встроенным набором правил в может установить, что истиная причина множества аварий кроется именно в упавшем линке и явно укажет, где надо искать причину Peering Management — все, что связано с пирингом и BGP. Позволяет хранить базу пиров, генерировать фильтры для BGP, обновлять базу RIPE и делать многое другое. Когда счет пирам идет на десятки и сотни, вещь незаменимая. Knowledge Base — обычная встроенная wiki с набором дополнительных интересных макросов. Например, при помощи макроса rack можно прорисовать набивку ряда из стоек. В KB можно хранить инструкции, сертификаты, договоры, правила и политики, полезные рецепты и так далее. Performance Management — активный сбор параметров производительности (в том числе и snmp). Модуль достаточно интересный и еще будет активно дорабатываться. Inventory — общая база по физическому железу. Позволяет работать с объектами разных уровней — от города и узла связи до стойки и шнурка питания коммутатора. Модуль находится в активной разработке. В качестве итога — NOC, в первую очередь, узкоспециальный инструмент для управления сложными сетями. Если смотреть в отрыве от этого контекста, то вполне можно уподобиться трем слепым, которые ощупали слона и первый признал его шлангом, второй — деревом, а третий — веревочкой. NOC является open-source, распространяется по лицензии BSD и успешно эксплуатируется уже несколько лет в ряде крупных российских и зарубежных сетей. Основной язык программирования — python. В качестве баз данных используется связка PostgreSQL и MongoDB. Web-интерфейс реализован на Django. Приглашаем компететнных специалистов принять участие в работе над проектом, у нас есть множество интереснейших направлений работы для светлых голов.

16.

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

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

Значительно возросла за последнее время популярность визуального интерфейса. С помощью манипулятора "мышь" пользователь выбирает представленные ему на экране в форме картинок объекты и команды, реализуя таким образом свои действия.

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

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

Каждая форма в зависимости от типа задачи, особенностей пользователя и принимаемого решения может иметь свои достоинства и недостатки.

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

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

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

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

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

Совершенствование интерфейса системы поддержки принятия решений определяется успехами в развитии каждого из трех указанных компонентов. Интерфейс должен обладать следующими возможностями:

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

  • передавать данные системе различными способами;

  • получать данные от различных устройств системы в различном формате;

  • гибко поддерживать (оказывать помощь по запросу, подсказывать) знания пользователя.

Коммуникационное оборудование