|
|
Системы поддержки принятия решенияСодержание лист Введение 3 1. Сосредоточенные и распределённые СППР 7 2. Методы, используемые в СППР 7 2.1. Метод анализа иерархий 7 2.2. Метод Парето 10 2.3. Метод кусочно-линейной аппроксимации 11 3. Согласование решений 12 4. Зарождение концепции хранилища данных 14 5. Технология разработки и внедрения Хранилища Данных 15 5.1. Этапы проекта 15 5.2. Выбор модели данных Хранилища 17 5.3. Выбор структуры Хранилища Данных 19 5.4. Витрины Данных 20 5.5. Хранилище Метаданных (Репозитарий) 22 5.6. Загрузка Хранилища 23 5.7. Анализ данных: OLAP 25 6. Интеллектуальный анализ данных 27 Заключение 29 Список использованных источников 30 Введение Принятие решений - это основа основ любого бизнеса. Независимо от функций организации и ее подразделений или от уровня руководства, постоянно требуется принимать те или иные решения. Они могут касаться оперативных вопросов, требующих немедленного реагирования, или быть более долгосрочными, затрагивающими проблемы стратегического характера. В свою очередь, основа основ принятия решений - это доступ к качественной информации. Качество это определяется четырьмя показателями: точность, полнота, своевременность и непротиворечивость. Кроме того, подразумевается (хотя и не всегда говорится в явном виде), что информация должна быть в доступной форме. За последнее десятилетие организации инвестировали в новые компьютерные системы более триллиона долларов, модернизируя ведение бизнеса путем автоматизации рутинных операций. Они накопили огромные объемы информации, хранящейся в реляционных базах данных, электронных таблицах или в так называемых унаследованных (legacy) системах. Эти данные распределены по сетям персональных компьютеров, хранятся на мэйнфреймах и серверах. Однако во многих организациях до сих пор не решена проблема эффективного доступа к этим данным, и большая их часть практически не используется для принятия критически важных бизнес-решений. Почему так происходит? Дело в том, что аналитические задачи менее регламентированы, чем приложения транзакционной обработки, требуют особого подхода и более гибких инструментальных средств. Попытки же реализовать системы анализа традиционными методами не дали в руки конечным пользователям той свободы доступа к корпоративной информации, которая была им необходима. Ограничиваясь, как правило, набором отчетов с параметрами, эти системы не позволяли, например, финансовому менеджеру задать бизнес-вопрос типа "А как изменилась средняя дебиторская задолженность предприятий госсектора в Северо-Западном регионе за последний год по сравнению с предыдущим?" или подобные этому сложные аналитические запросы. Осознание этого факта дало мощный толчок развитию специализированных программных продуктов для построения систем поддержки принятия решений, реализующих технологии Хранилищ и Витрин Данных, а также оперативной аналитической обработки (On-Line Analytical Processing, или OLAP). Основная задача этих технологий - дать в руки всем конечным пользователям инструменты, с помощью которых они смогли бы самостоятельно анализировать любую корпоративную информацию, необходимую им для принятия более правильных и своевременных решений. Проблемы принятия решений пронизывают всю человеческую практику (и общественную, и личную), и поэтому отличаются большим разнообразием. В зависимости от выбираемого основания классификации выделяют задачи принятия решений: - хорошо структурированные, плохо структурированные и неструктурированные; - уникальные и повторяющиеся; - статистические и динамические; - в условиях определенности и в условиях неопределенности ( в частности, при риске, при противодействии); - с фиксированным (заданным) набором (множеством) вариантов решений (стратегий, альтернатив, . ..) и с формируемым в процессе принятия решений; - с одним критерием (показателем качества или эффективности, целевой функцией, . . . ) и с многими (несколькими) критериями, а также задачи: выбора одного наилучшего (оптимального) варианта, нескольких лучших вариантов, ранжирования всех вариантов, разбиения их на упорядоченные классы, принятия индивидуальных решений и принятия коллективных решений. Поддержка принятия решений заключается в помощи ЛПР в процессе принятия решений. Она включает: - помощь ЛПР при анализе объективной составляющей, т.е. в понимании и оценке сложившейся ситуации и ограничений, накладываемых внешней средой; - выявлении предпочтений ЛПР, т.е. в выявлении и ранжировании приоритетов, учёте неопределённости в оценках ЛПР и формировании его предпочтений; - генерации возможных решений, т.е. формирование списка альтернатив; - оценке возможных альтернатив, исходя из предпочтений ЛТР и ограничений, накладываемых внешней средой; - анализе последствий принимаемых решений; - выборе лучшего, с точки зрения ЛПР, варианта. Компьютерная поддержка процесса принятия решений, так или иначе основана на формализации методов получения исходных и промежуточных оценок, даваемых ЛПР, и алгоритмизации самого процесса выработки решения. Формализация методов генерации решений, их оценка и согласование является чрезвычайно сложной задачей. Эта задача стала интенсивно решаться с возникновением вычислительной техники. Решение этой задачи в различных приложениях сильно зависело и зависит от характеристик доступных аппаратных и программных средств, степени понимания проблем, по которым принимаются решения, и методов формализации. Термин "система поддержки принятия решений" появился в начале семидесятых годов. За это время дано много определений СППР. Так, в [1] она определяется следующим образом: "Системы поддержки принятия решений являются человеко-машинными объектами, которые позволяют лицам, принимающим решения (ЛПР), использовать данные, знания, объективные и субъективные модели для анализа и решения слабоструктурированных и неструктурированных проблем". В этом определении подчёркивается предназначение СППР для решения слабоструктурированных и неструктурированных задач. В соответствии с [2] к слабоструктурированным относятся задачи, которые содержат как количественные, так и качественные переменные, причём качественные аспекты проблемы имеют тенденцию доминировать. Неструктурированные проблемы имеют лишь качественное описание. В [3] СППР даётся такое определение: "Система поддержки принятия решений - это компьютерная система, позволяющая ЛПР сочетать собственные субъективные предпочтения с компьютерным анализом ситуации при выработке рекомендаций в процессе принятия решения". Основной пафос этого определения ? сочетание субъективных предпочтений ЛПР с компьютерными методами. В [4] СППР определяется "как компьютерная информационная система, используемая для различных видов деятельности при принятии решений в ситуациях, где невозможно или нежелательно иметь автоматическую систему, полностью выполняющую весь процесс решения". Все три определения не противоречат, а дополняют друг друга и достаточно полно характеризуют СППР. Человеко-машинная процедура принятия решений с помощью СППР представляет собой циклический процесс взаимодействия человека и компьютера. Цикл состоит из фазы анализа и постановки задачи для компьютера, выполняемым лицом, принимающим решения (ЛПР), и фазы оптимизации (поиска решения и выполнения его характеристик), реализуемой компьютером [5]. В той или иной степени системы поддержки принятия решений (СППР) присутствуют в любой информационной системе (ИС). Поэтому, осознанно или нет, к задаче создания системы поддержки принятия решений организации приступают сразу после приобретения вычислительной техники и установки программного обеспечения. По мере развития бизнеса, упорядочения структуры организации и налаживания межкорпоративных связей, проблема разработки и внедрения СППР становится особенно актуальной. Одним из подходов к созданию таких систем стало использование хранилищ данных. В настоящей статье рассматриваются этапы и методики проведения подобных работ на опыте и с применением методологии компании Price Waterhouse, которая на сегодня выполнила 40 крупномасштабных проектов по созданию корпоративных Хранилищ Данных. СППР можно, в зависимости от данных, c которыми они работают, разделить на оперативные, предназначенные для немедленного реагирования на текущую ситуацию, и стратегические - основанные на анализе большого количества информации из разных источников с привлечением сведений, содержащихся в системах, аккумулирующих опыт решения проблем. СППР первого типа получили название Информационных Систем Руководства (Executive Information Systems, ИСР). По сути, они представляют собой конечные наборы отчетов, построенные на основании данных из транзакционной информационной системы предприятия или OLTP-системы, в идеале адекватно отражающей в режиме реального времени все аспекты производственного цикла предприятия. Для ИСР характерны следующие основные черты: отчеты, как правило, базируются на стандартных для организации запросах; число последних относительно невелико; ИСР представляет отчеты в максимально удобном виде, включающем, наряду с таблицами, деловую графику, мультимедийные возможности и т. п.; как правило, ИСР ориентированы на конкретный вертикальный рынок, например финансы, маркетинг, управление ресурсами. СППР второго типа предполагают достаточно глубокую проработку данных, специально преобразованных так, чтобы их было удобно использовать в ходе процесса принятия решений. Неотъемлемым компонентом СППР этого уровня являются правила принятия решений, которые на основе агрегированных данных подсказывают менеджерскому составу выводы и придают системе черты искусственного интеллекта. Такого рода системы создаются только в том случае, если структура бизнеса уже достаточно определена и имеются основания для обобщения и анализа не только данных, но и процессов их обработки. Если ИСР есть не что иное как развитие системы оперативного управления производственными процессами, то СППР в современном понимании ? это механизм развития бизнеса, который включает в себя некоторую часть управляющей информационной системы, обширную систему внешних связей предприятия, а также технологические и маркетинговые процессы развития производства. 1. Сосредоточенные и распределённые СППР Сосредоточенные СППР включают в себя одну экспертную систему, установленную на одной вычислительной машине, они выполняют функции, перечисленные ранее, помогая одному ЛПР (или небольшой группе специалистов) оценивать обстановку и принимать решения. Они проще, чем распределённые системы, т.к. в них отсутствует проблема обмена информацией. Возможны следующие типы сосредоточенных СППР: - решение в автоматическом режиме принимает система принятия решений, состоящая из одного узла. Такая система включает в себя ЭВМ, систему автоматического и/или ручного ввода информации и средства представления решения (возможно стандартное устройство вывода). Примером такой системы может быть система тушения пожара на каком-нибудь особо опасном объекте. В этой системе автоматические датчики температуры и газоанализаторы передают в ЭВМ результаты измерений, экспертная система определяет момент опасности возникновения пожара (если она есть) и её место включает средства тушения пожара и/или передаёт сигнал тревоги. В соответствии с третьим определением СППР - это системы, принимающие решения (СПР), а не поддерживающие принятие решений; - решение принимает специалист, имеющий в своём распоряжении систему поддержки принятия решений. Система может включать в себя экспертные системы, моделирующие программы, средства оценки принятых решений и т.д. Такой системой может быть система поддержки принятия решений при управлении подвижным объектом, когда пилоту или командиру корабля предлагают варианты решений и он реализует один из вариантов. Распределённые вычислительные системы могут быть распределены пространственно и/или функционально. Пространственно или функционально распределённые СППР состоят из локальных СППР, расположенных в связанных между собой узлах вычислительной сети, каждый из которых может независимо решать свои частные задачи, но для решения общей проблемы ни одна из них не обладает достаточными знаниями, информацией и ресурсами (или некоторыми из этих составляющих). Общую проблему они могут решать только сообща, объединяя свои локальные возможности и согласовывая принятые частные решения. 2. Методы, используемые в СППР 2.1. Метод анализа иерархий Метод анализа иерархий (МАИ), предложенный Т. Л. Саати, основан на парных сравнениях альтернативных вариантов по различным критериям с использованием девятибалльной шкалы и последующим ранжированием набора альтернатив по всем критериям и целям. Взаимоотношения между критериями учитываются путем построения иерархии критериев и применением парных сравнений для выявления важности критериев и подкритериев. Метод отличается простотой и дает хорошее соответствие интуитивным представлениям. Главным недостатком этого подхода является большое количество требуемой экспертной информации, которая представляет собой множество оценок предпочтительности, полученных в процессе парного сравнения альтернатив и критериев. Метод имеет ограничение на количество одновременно сравниваемых альтернатив (не рекомендуется больше 9). Это связано с установленным психологами фактом, что обычному человеку трудно осуществлять рациональный выбор, если число объектов выбора превышает 7 + 2. Благодаря простоте метод хорошо подходит для решения динамических задач принятия решений, при этом возникают новые возможности для оценки последствий принимаемых решений. К основным процедурам метода анализа иерархий относятся следующие: - генерация множества альтернативных вариантов; - формирование множества критериев для оценки альтернативных вариантов и представление его в виде иерархии; - выявление предпочтений экспертов на множестве альтернатив по различным критериям; - установление относительной важности влияния критериев на цель выбора и другие критерии; - получение ранжированных наборов альтернатив по всем критериям и целям. Все перечисленные процедуры связаны с обработкой информации, поступающей от экспертов. Так, сначала экспертами генерируется множество допустимых альтернатив, среди которых необходимо провести выбор лучшей альтернативы или упорядочивание всех элементов. Обычно на этом этапе должно проводиться разумное усечение множества всех возможных альтернатив или его кластеризация в связи с ограничением метода на число одновременно сравниваемых объектов. Процесс генерации иерархии целей, критериев и альтернатив занимает достаточно продолжительное время и базируется на всей совокупности знаний специалистов заданной предметной области, привлекаемых для решения конкретной задачи. Вершиной иерархий обычно является глобальная цель (фокус), на следующих уровнях присутствуют критерии и на самом нижнем уровне - альтернативы. В иерархиях, строящихся для принятия решений в области техники, часто присутствуют уровни, соответствующие подсистемам некоторого сложного технического объекта. Иерархическая структура критериев и целей является моделью знаний конкретной предметной области, которая изменяется и уточняется с течением времени. Элементы одного уровня иерархии попарно сравниваются по силе их влияния на элементы более высокого уровня иерархии. Сравнение производится по шкале, представленной в табл. 1. Таблица1 Степень важности Определение Объяснение 1 Одинаковая значимость Два действия вносят одинаковый вклад в достижение цели 3 Некоторое преобладание значимости одного действия перед другим (слабая значимость) Опыт и суждения дают легкое предпочтение одному действию перед другим 5 Существенная или сильная значимость Опыт и суждения дают сильное предпочтение одному действию перед другим 7 Очень сильная или очевидная значимость Предпочтение одного действия перед другим очень сильно. Его превосходство практически явно 9 Абсолютная значимость Свидетельство в пользу предпочтения одного действия другому в высшей степени убедительны 2,4,6,8 Промежуточные значения между соседними значениями шкалы Ситуация когда необходимо компромиссное решение Обратные величины приведенных выше чисел Если действию i при сравнении с действием j приписывается одно из приведенных выше чисел, то действию j при сравнении с i приписывается обратное значение Обоснованное предположение 1. Результаты заносятся в матрицу попарных сравнений. Следующий шаг состоит в вычислении вектора приоритетов по данной матрице. Существует несколько методов оценки этого вектора: 1. Суммировать элементы каждой строки и нормализовать делением каждой суммы на сумму всех элементов; сумма полученных результатов будет равна единице. Первый элемент результирующего вектора будет приоритетом первого объекта, второй - второго объекта и т.д. 2.Суммировать элементы каждого столбца и получить обратные величины этих сумм. Нормализовать их так, чтобы их сумма равнялась единице, разделить каждую обратную величину на сумму всех обратных величин. 3.Разделить элементы каждого столбца на сумму элементов этого столбца (т.е. нормализовать столбец), затем сложить элементы каждой полученной строки и разделить эту сумму на число элементов строки. Это ? процесс усреднения по нормализованным столбцам. Точное решение получается возведением матрицы в произвольно большие степени и деления суммы каждой строки на общую сумму элементов матрицы. Иерархия оценивается следующим образом: 1. Производится попарное сравнение элементов 2-го уровня по степени влияния на цель. Результаты заносятся в матрицу попарных сравнений A1; 2. Производится попарное сравнение элементов 3-го уровня по степени влияния на каждый критерий 2-го уровня. Результаты заносятся в n1 матриц попарных сравнений A11...An1; 3. Действия п.2 повторяются для всех оставшихся уровней; 4. Для каждой матрицы вычисляется вектор приоритетов; 5. Каждый элемент вектора приоритетов 2-го уровня умножается на соответствующий элемент вектора приоритетов каждой из матриц (A11...An1). После сложения всех произведений получется вектор приоритетов 3-го уровня; 6. Действия п.5 выполняются для всех оставшихся уровней. В результате получается вектор приоритетов n-го уровня по степени влияния на цель. 2.2. Метод Парето Одним из первых методов, позволяющих производить многокритериальную оптимизацию является метод Парето, предложенный в 1927 г. для решения экономических задач. В тех случаях, когда нет необходимости учитывать "вес" критериев, а число параметров, по которым производится оценка относительно невелико, этот метод может оказаться достаточно полезен. Он прост в реализации и требует минимум информации от эксперта или ЛПР. Применение скалярного критерия и методов свертки позволяет линейно упорядочивать сравниваемые объекты, т.е. выстроить их по старшинству оценок. Ранжирование по Парето (это понятие объясняется ниже) позволяет упорядочивать объекты не линейно, а по группам, считая, что все объекты внутри группы равноценны, т.е. перейти от линейного упорядочивания к групповому. При этом очередность устанавливается не между отдельными объектами а между их равноценными группами. Такой подход не дает никаких преимуществ, если упорядочивание производится по одному показателю, но открывает новые возможности, если таких показателей несколько. Определение правила выбора по Парето. Будем считать, что объект li строго предпочтительнее объекта lk, если оценка объекта li превосходит оценку объекта lk, хотя бы по одному показателю, а по всем остальным показателям не хуже нее. Будем считать, что объекты li и lk эквивалентны, если соответствующие показатели этих оценок равны. Будем считать, что объекты li и lk несравнимы между собой, если оценка li превосходит оценку lk по одним показателям, а оценка lk превосходит оценку li по другим. Например, оценки l 1= {10,7}, 1 2= {12,5} несравнимы между собой. Независимо от того, считается ли "лучшим" больший показатель или меньший, сравнивать эти оценки без дополнительной информации мы не умеем. Отсутствие требования линейного упорядочивания оценок позволяет объединить некоторые несравнимые и эквивалентные по оценкам объекты в одну группу и этой группе присваивать номер, определяющий ранг группы. Будем считать, что чем меньше номер, тем выше ранг группы объектов. Разбиение объектов на группы будем осуществлять следующим образом: отберем такие объекты, для каждого из которых в очереди не существует оценок строго их предпочтительнее. Такие оценки называются оптимальными по Парето. Таким объектам присвоим ранг 1. Аналогично для оставшейся группы объектов (т.е. для тех, которые не вошли в первоочередные) выделим оптимальные и им присвоим ранг 2. Изложенный принцип разбиения на классы поясним на следующем примере. Пусть предпочтение в обслуживании отдается наиболее "коротким" (по времени) и требующим наименьшего объема оперативной памяти задачам, решаемым на вычислительной машине. Естественно, что для наиболее "коротких" задач не обязательно требуются наименьшие объемы оперативной памяти. Необходимо подчеркнуть, что это единственная информация, которая требуется от эксперта или ЛПР. ЛПР должен сказать системе поддержки принятия решений, что значит "лучшие": когда чего-то больше, что-то легче, быстрее, надежнее, объемнее, меньше и т.д. Затем в систему вводятся характеристики сравниваемых объектов и по приведенным ниже алгоритмам (или каким-нибудь другим) СПР выдает результаты ранжирования. 2.3. Метод кусочно-линейной аппроксимации В тех случаях, когда ЛПР четко представляет себе "что за что он готов поменять" может быть использован метод кусочно-линейной аппроксимации. Метод позволяет осуществить линейное, а не групповое упорядочивание, но требует от ЛПР очень много информации. Тем не менее, в некоторых случаях, например при управлении очередями задач операционной системой ЭВМ, при решении задач численными методами, когда значение коэффициентов при неизвестных определяет эксперт или ЛПР, при принятии решений в чрезвычайных ситуациях и в некоторых других случаях метод может оказаться полезным. Пусть множество объектов А можно разбить на какие-то подмножества: А=u Bj которые можно рассортировать Bj=u Bji.J(-j усть, далее, в каждом классе Bj выделяется некоторый представитель bB1(-Вi(-Вj(-А причем множество В°, состоящее из всех представителей также сортируемо и выбор лица, принимающего решение на любом наборе представителей соответствует охватывающей этот набор сортировке. Доказано, что в этом случае глобальная сортировка оказывается единственной для всех систем частичных сортировок. Этот метод реализует решение задачи классификации лицом, принимающим решение о состояниях объектов по совокупности качественных и/или количественных признаков. Приведем вначале алгоритм определения структуры предпочтения ЛПР путем построения поверхностей безразличия. Введем понятие кривой безразличия. Гиперповерхность уровня функции U(xi,...,xm ) определяется как множество точек x=(xi, xz, ..., xm), для которых функция полезности U(x)=const. Гиперповерхности уровня функции полезности называются кривыми безразличия. Термин "кривая безразличия" связан с тем, что полезность альтернатив х и у, лежащих на одной кривой, одинакова U(x)=U(y). Норма замены между i-м и j-м критериями равна числу единиц по i-ому критерию, потеря которых может быть компенсирована одной единицей по j-ому критерию. Приведем пример, иллюстрирующий понятия локальной цены. Встречаются два туриста. Каждый из них хочет обменять часть продуктов из своего запаса на продукты из запасов другого. Один турист согласен обменять 0,5 кг своего хлеба на некоторое количество сахара. Если второй турист очень голоден, то за 0,5 кг хлеба он согласен отдать 0,5 кг сахара. В этом случае локальная цена хлеба в единицах сахара равна 1. Если второй турист не очень голоден, то за 0,5 кг хлеба он согласен отдать 0,1 кг сахара. В этом случае локальная цена хлеба в единицах сахара равна 1/5. На этом простом примере видно как может меняться норма замены в зависимости от условий ее оценки. Таким образом, если в операционную систему ввести механизм многокритериальной сортировки, то операционная система будет работать в оптимальном (по заданным критериям) режиме, обеспечивая реконфигурацию программ, повышая эффективность выполнения процессов на имеющейся аппаратуре. 3. Согласование решений Задача согласования решений возникает только в распределенных СППР как между узлами различных уровней, так и между узлами одного уровня. Такое согласование требуется осуществлять в самых различных, если не во всех областях применения распределенных систем поддержки принятия решений и его важность в обосновании, видимо, не нуждается. Заметим следующий чрезвычайно важный момент. Если использование лингвистических переменных при оценке решений одним ЛПР может существенно облегчить оценку решения, то при согласовании решений, использование лингвистических переменных может создать, и действительно создает, существенные трудности, т.к. одна и та же вербальная оценка, например "хорошо", для различных людей может иметь совершенно различные значения. Поэтому при согласовании решений очень важно уточнение, что же значит "хорошо". Это тоже одна из проблем согласования решений. Для того, чтобы процедура согласования решения реализовывалась эффективно, специалистам, участвующим в ней, надо предложить какие-то правила или процедуры, по которым они осуществляли бы поиск компромисса. В настоящее время разработано большое количество таких процедур. Грубо их можно разделить на две категории: "чисто переговорные", т.е. без использования вычислительной техники и человеко-машинные, опирающиеся на компьютерные процедуры. Эти компьютерные процедуры, применяемые на практике, в большинстве случаев достаточно просты. Традиционно выделяется два типа процедур согласования решений: 1) процедура с личным контактом между специалистами - в нашем случае вся информация, которой они хотят обменяться, высвечивается на дисплеях и 2) многоуровневые (итеративные) процедуры без личных контактов с контролируемой обратной связью, осуществляемой специальным программным обеспечением. Информация обратной связи также представляется на дисплее заинтересованным участникам принятия группового решения. Классический представитель процедуры первого типа - "дискуссия за круглым столом", в ходе которой участники неоднократно высказывают суждения с учетом других точек зрения. В нашем случае - это обмен информацией по вычислительной сети посредством многопользовательского интерфейса. Несколько слов о процедурах второго типа. Они ведут свою историю от широко известного метода "Делфи". Специалисты, принимающие решения, изолированы друг от друга, а процедура реализуется за несколько разделенных во времени итераций. Эта процедура получила распространение при проведении всякого рода экспертиз, поэтому описывая ее, будем говорить не об ЛПР, а об экспертах. Суть процедуры "Делфи" заключается в следующем. Экспертам предъявляется оцениваемый объект. Опрос экспертов осуществляется в несколько итераций. На первой итерации каждый эксперт дает числовую оценку объекта. После этого подсчитывается и сообщается всем экспертам средняя оценка и показатель разброса оценок. Экспертов, давших крайние оценки, просят дать письменное обоснование своего мнения, и с ним знакомят всех остальных экспертов, передавая его по сети, после чего проводится вторая итерация опроса. Подобные итерации заканчиваются тогда, когда будет достигнуто "достаточное" согласие между оценками экспертов. Этот исходный вариант процедуры, называемый иногда стандартным "Делфи", повлек за собой множество разновидностей и модификаций. Большая часть модификаций обусловлена только конкретной областью применения метода "Делфи" и выразилась в характере постановки вопросов. В некоторых случаях с целью сближения исходных оценок экспертов предлагается следующая процедура: на каждой итерации происходит случайное разбиение всех экспертов на пары, в каждой паре эксперты обмениваются оценками. Один (любой) эксперт в паре пересматривает оценку, когда это произойдет во всех парах, осуществляется переход к следующей итерации. Снова случайно образуются новые пары и т.д. Для того, чтобы процедура согласования решения с помощью системы поддержки принятия решений реализовывалась эффективно специалистам, участвующим в ней, надо предложить какие-то методы, по которым они осуществляли бы поиск компромисса. 4. Зарождение концепции хранилища данных Ясно, что чем больше информации вовлечено в процесс принятия решений, тем более обоснованное решение может быть принято. Информация, на основе которой принимается решение, должна быть достоверной, полной, непротиворечивой и адекватной. Поэтому при проектировании СППР возникает вопрос о том, на основе каких данных эти системы будут работать. В ИСР качество оперативных решений обеспечивается тем, что данные выбираются непосредственно из информационной системы управления предприятием (или из БД предприятия), которая адекватно отражает состояние бизнеса на данный момент времени. Ранние версии СППР второго типа в качестве исходных использовали относительно небольшой объем агрегированных данных, поддающихся проверке на достоверность, полноту, непротиворечивость и адекватность. По мере роста и развития ИСР, а также совершенствования алгоритмов принятия решений на основе агрегированных данных, системы принятия решений столкнулись с проблемами, вызванными необходимостью обеспечить растущие потребности бизнеса. В ИСР накопился объем данных, замедляющий процесс построения отчетов настолько, что менеджерский состав не успевал готовить на их основе соответствующие решения. Кроме того, с развитием межкорпоративных связей потребовалось вовлекать в процесс анализа данные из внешних источников, не связанных напрямую с производственными процессами и потому не входящих в систему управления предприятием. В СППР второго типа традиционная технология подготовки интегрированной информации на основе запросов и отчетов стала неэффективной из-за резкого увеличения количества и разнообразия исходных данных. Это стало сильно задерживать менеджмент, для которого требовалось быстро принимать решения. Кроме того, постепенное накопление в БД предприятия данных для принятия решений и последующий их анализ стали отрицательно сказываться на оперативной работе с данными. Решение было найдено и сформулировано в виде концепции Хранилища Данных (Data Warehouse, ХД), которое выполняло бы функции предварительной подготовки и хранения данных для СППР на основе информации из системы управления предприятием (или базы данных предприятия), а также информации из сторонних источников, которые в достаточном количестве стали доступны на рынке информации. Этот подход потребовал новых технологических решений, к созданию которых несколько лет назад приступили основные производители промышленных СУБД и разработчики систем анализа данных. Сегодня накоплен обширный опыт разработки и внедрения специализированных структур данных и создания СППР на основе СУБД разных типов. Известна и технология создания больших Хранилищ, как правило, на основе реляционных СУБД. 5. Технология разработки и внедрения Хранилища Данных 5.1. Этапы проекта Первой фазой проекта разработки ХД является бизнес-анализ процессов и данных предприятия. В России, несмотря на широкое распространение CASE-технологии, к бизнес-анализу и проектированию данных на концептуальном уровне не всегда относятся достаточно серьезно. Между тем относительно СППР на основе ХД можно с уверенностью утверждать, что ее разработка без подобного анализа заранее обречена на неудачу. Без ясного понимания разработчиками целей бизнеса, способов их достижения, возникающих при этом проблем и методов их решения, ресурсы, необходимые для разработки ХД, будут потрачены зря. Самым критичным из ресурсов сейчас является время, и тот, кто начал разработку СППР, не определив заранее, кто, когда, зачем и как будет принимать решения, какое влияние то или иное решение оказывает на бизнес, какие решения отнести к оперативным, а какие к стратегическим и т. д., обрекает себя на неизбежное отставание в конкурентной борьбе. Основное назначение модели предприятия - определение и формализация данных, действительно необходимых в процессе принятия решения. Известно два подхода к бизнес-анализу. Первый ориентируется на описание бизнес-процессов, протекающих на предприятии, которое моделируется набором взаимосвязанных функциональных элементов. Поскольку эти процессы, как правило, хорошо известны, на первый взгляд кажется, что это самый естественный и быстрый путь бизнес-анализа. Действительно, если бизнес стабилен и внешние факторы не играют в нем решающей роли либо также стабильны, этот путь может оказаться наиболее эффективным. Второй подход основан на первичном анализе бизнес-событий. При проектировании СППР на основе ХД именно он обеспечивает наибольшую эффективность: позволяет гибко модифицировать бизнес-процессы, ставя их в зависимость от бизнес-событий; интегрирует данные, которые при анализе бизнес-процессов остаются скрытыми в алгоритмах обработки данных; объединяет управляющие и информационные потоки; наглядно показывает, какая именно информация нужна при обработке бизнес-события и в каком виде она представляется. Иными словами, бизнес-событие является более устойчивым и более тесно связанным с информационными и управляющими потоками понятием, чем бизнес-процесс. Через анализ бизнес-событий необходимо перейти к анализу данных, используемых предприятием. При этом должна быть собрана информация об используемых внешних данных и их источниках; о форматах данных, периодичности и форме их поступления; о внутренних информационных системах предприятия, их функциях и алгоритмах обработки данных, используемых при наступлении бизнес-событий. Такой анализ, как правило, производится при проектировании любой информационной системы. Особенность анализа данных при проектировании СППР на основе ИХ состоит в необходимости создания моделей представления информации. То, что в транзакционных системах является вторичным понятием, а именно состав и форма отображаемых данных, в СППР приобретает особую важность, так как нужно выявить все без исключения признаки, требуемые для менеджерского состава. Модель представления данных является организационно-функциональным срезом модели системы, а при ее разработке последовательно изучаются: распределение пользователей системы: географическое, организационное, функциональное; доступ к данным: объем данных, необходимый для анализа, уровень агрегированности данных, источники данных (внешние или внутренние), описание информации, совместно используемой различными функциональными группами предприятия; аналитические характеристики системы: измерения данных, основные отчеты, последовательность преобразования аналитической информации, степень предопределенности анализа, существующие или находящиеся в стадии разработки средства анализа. При проектировании транзакционной системы обычно строго выдерживается последовательность процессов: бизнес-анализ, концептуальная модель данных, физическая модель данных, структура интерфейса и т. п. Возврат на предыдущий уровень происходит редко и считается отклонением от нормального хода выполнения проекта. В случае СППР на основе ХД нормальным считается итерационный, а иногда и параллельный, характер моделирования, при котором возврат на предыдущую стадию - обычное явление. Это связано с необходимостью выделения всех требуемых данных для произвольных запросов (ad-hoc), для чего следует составить исчерпывающий перечень необходимых данных и построить схему их связей через бизнес-события. При этом из общего массива выделяется значимая информация и выясняется потребность в дополнительных источниках данных для принятия решений. В ходе анализа бизнес-событий необходимо также сформировать схему взаимодействия между транзакционной и аналитической системами на предприятии. Помимо того, что транзакционная система зачастую является важнейшим источником данных для хранилища, желательно задействовать один и тот же пользовательский интерфейс в ИСР и СППР. Подходы к совместному использованию этих систем определяются именно на данной фазе выполнения проекта. Итак, по результатам анализа бизнес-процессов и структур данных предприятия отбирается действительно значимая для бизнеса информация с учетом неопределенности будущих запросов. Следующий шаг связан с пониманием того, в каком виде и на каких аппаратных и программных платформах размещать структуру данных СППР на основе ХД. 5.2. Выбор модели данных Хранилища В самом простом варианте для Хранилищ Данных используется та модель данных, которая лежит в основе транзакционной системы. Если, как это часто бывает, транзакционная система функционирует на реляционной СУБД (Oracle, Informix, Sybase и т. п.), самой сложной задачей становится выполнение запросов ad-hoc, поскольку невозможно заранее оптимизировать структуру БД так, чтобы все запросы работали эффективно. Однако практика принятия решений показала, что существует зависимость между частотой запросов и степенью агрегированности данных, с которыми запросы оперируют, а именно чем более агрегированными являются данные, тем чаще запрос выполняется. Другими словами, круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это наблюдение легло в основу подхода к поиску и выборке данных, называемого Оперативной Аналитической Обработкой (On-line Analytical Processing, OLAP). OLAP-системы построены на двух базовых принципах: все данные, необходимые для принятия решений, предварительно агрегированы на всех соответствующих уровнях и организованы так, чтобы обеспечить максимально быстрый доступ к ним; язык манипулирования данными основан на использовании бизнес-понятий. В основе OLAP лежит понятие гиперкуба, или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объемы продаж. Измерения представляют собой совокупности значений других данных, скажем названий товаров и названий месяцев года. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, показывающую значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных может идти по нескольким направлениям: увеличение числа измерений - данные о продажах не только по месяцам и товарам, но и по регионам. В этом случае куб становится трехмерным; усложнение содержимого ячейки - например нас может интересовать не только уровень продаж, но и, скажем, чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений; введение иерархии в пределах одного измерения - общее понятие ВРЕМЯ естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т. д. Речь пока идет не о физической структуре хранения, а лишь о логической модели данных. Другими словами, определяется лишь пользовательский интерфейс модели данных. В рамках этого интерфейса вводятся следующие базовые операции: поворот; проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону; раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба; свертка (roll-up/drill-up). Операция, обратная раскрытию; сечение (slice-and-dice). В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В первых гиперкуб реализуется как отдельная база данных специальной нереляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма чувствительны к объемам хранимых данных. Поэтому данные из хранилища сначала помещаются в специальную многомерную базу (Multidimensional Data Base, MDB), а затем эффективно обрабатываются OLAP-сервером. Одним из первых производителей таких систем стала компания Arbor Software, выпустившая продукт Essbase. Компания Oracle предлагает систему Oracle Express, интегрированную с универсальным Oracle Server. Известны и другие производители MOLAP-систем, например SAS Institute. Однако, в отличие от Essbase, их продукты часто интегрированы в приложения, созданные для конкретных вертикальных или горизонтальных рынков, и поставляются лишь в составе этих приложений. Для систем ROLAP гиперкуб - это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP - операций. Опыт эксплуатации ROLAP-продуктов показал, что они больше подходят на роль интеллектуальных генераторов отчетов, чем действительно оперативных средств анализа. Они применяются в таких областях, как розничная торговля, телекоммуникации, финансы, где количество данных велико, а высокой эффективности запросов не требуется. Примерами промышленных ROLAP-систем служат MetaCube фирмы Informix и Discoverer 3.0 фирмы Oracle. На практике иногда реализуется комбинация этих подходов. Некоторые поставщики программных продуктов (Sybase - Sybase IQ, Teradata) поставляют более сложные решения, основанные на специальных методах хранения и индексации данных и связей между данными. При определении программно-технологической архитектуры Хранилища следует иметь в виду, что система принятия решения, на какие бы визуальные средства представления она ни опиралась, должна предоставить пользователю возможность детализации информации. Руководитель предприятия, получив интегрированное представление данных и/или выводы, сделанные на его основе, может затребовать более детальные сведения, уточняющие источник данных или причины выводов. С точки зрения проектировщика СППР, это означает, что необходимо обеспечить взаимодействие СППР не только с Хранилищем Данных, но и в некоторых случаях с транзакционной системой. 5.3. Выбор структуры Хранилища Данных Несколько лет назад для Хранилищ Данных было предложено использовать схемы данных, получившие названия "звезда" и "снежинка". Суть технологии проектирования этих схем заключается в выделении из общего объема информации собственно анализируемых данных (или фактов) и вспомогательных данных (называемых измерениями). Необходимо, однако, отдавать себе отчет в том, что это приводит к дублированию данных в Хранилище, снижению гибкости структуры и увеличению времени загрузки. Все это - плата за эффективный и удобный доступ к данным, необходимый в СППР. Несмотря на то что предсказать, какую именно информацию и в каком виде захочет получить пользователь, работая с СППР, практически невозможно, измерения, по которым проводится анализ, достаточно стабильны. В процессе подготовки того или иного решения пользователь анализирует срез фактов по одному или нескольким измерениям. Анализ информации, исходя из понятий измерений и фактов, иногда называют многомерным моделированием данных (MultiDimensional Modelling, MDM). Таблицы фактов обычно содержат большие объемы данных, тогда как таблицы измерений стараются сделать поменьше. Этого подхода желательно придерживаться потому, что запрос по выборке из объединения таблиц выполняется быстрее, когда одна большая таблица объединяется с несколькими малыми. При практической реализации ХД небольшие таблицы измерений иногда удается целиком разместить в оперативной памяти, что резко повышает эффективность выполнения запросов. Поскольку в Хранилищах Данных, наряду с детальными, должны храниться и агрегированные данные, в случае "снежинки" или "звезды" появляются таблицы агрегированных фактов (агрегатов). Подобно обычным фактам, агрегаты могут иметь измерения. Кроме того, они должны быть связаны с детальными фактами для обеспечения возможной детализации. На практике Хранилища часто включают в себя несколько таблиц фактов, связанных между собой измерениями, которые таким образом разделяются между несколькими таблицами фактов. Такая схема носит название "расширенная снежинка", и именно она, как правило, встречается в Хранилищах Данных. Для достижения наивысшей производительности иногда используют подход, при котором каждая "звезда" располагается в отдельной базе данных или на отдельном сервере. Хотя такой подход приводит к увеличению размера дискового пространства за счет дублирования разделенных измерений, он может оказаться весьма полезным при организации Витрин Данных. При проектировании структуры хранилища часто возникает желание использовать как можно больше агрегатов и за счет этого повысить производительность системы. Нетрудно подсчитать, что для модели "звезда" с 10 измерениями можно построить 10!=3.63 миллиона различных агрегированных значений, размещение которых в памяти при установлении связей с соответствующими измерениями приведет к резкому увеличению занимаемого дискового пространства и замедлению доступа к данным. Другая крайность состоит в использовании слишком малого числа агрегатов, а это может привести к необходимости выполнять агрегирование динамически, что заметно снижает эффективность запросов. По некоторым оценкам, при определении оптимального количества агрегатов следует придерживаться принципа 80:20 - 80% ускорения достигается за счет использования 20% кандидатов на агрегаты. 5.4. Витрины Данных Идея Витрины Данных (Data Mart) возникла несколько лет назад, когда стало очевидно, что разработка корпоративного хранилища - долгий и дорогостоящий процесс. Это обусловлено как организационными, так и техническими причинами: информационная структура реальной компании, как правило, очень сложна, и руководство зачастую плохо понимает суть происходящих в компании бизнес-процессов; технология принятия решений ориентирована на существующие технические возможности и с трудом поддается изменениям; может возникнуть необходимость в частичном изменении организационной структуры компании; требуются значительные инвестиции до того, как проект начнет окупаться; как правило, требуется значительная модификация существующей технической базы; освоение новых технологий и программных продуктов специалистами компании может потребовать много времени; на этапе разработки бывает трудно наладить взаимодействие между разработчиками и будущими пользователями Хранилища. В совокупности это приводит к тому, что разработка и внедрение корпоративного хранилища требуют значительных усилий по анализу деятельности компании и переориентации ее на новые технологии. Витрины Данных возникли в результате попыток смягчить трудности разработки и внедрения Хранилищ. Сейчас под Витриной Данных понимается специализированное Хранилище, обслуживающее одно из направлений деятельности компании, например учет запасов или маркетинг. Важно, что происходящие здесь бизнес-процессы, во-первых, относительно изучены и, во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, вовлеченных в конкретную деятельность, также невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). При этих условиях удается с использованием современных технологий развернуть Витрину подразделения за 3-4 месяца. Необходимо отметить, что успех небольшого проекта (стоимость которого невелика по сравнению со стоимостью разработки корпоративного Хранилища), во-первых, способствует продвижению новой технологии и, во-вторых, приводит к быстрой окупаемости затрат. Первые же попытки внедрения Витрин Данных оказались настолько успешными, что вокруг новой технологии начался настоящий бум. Предлагалось вообще отказаться от реализации корпоративного Хранилища и заменить его совокупностью Витрин Данных. Однако вскоре выяснилось, что с ростом числа Витрин растет сложность их взаимодействия, поскольку сделать витрины полностью независимыми не удается. Сейчас принята точка зрения, в соответствии с которой разработка корпоративного Хранилища должна идти параллельно с разработкой и внедрением Витрин Данных. Фактическим стандартом структуры данных при разработке Витрины является "звезда", основанная на единственной таблице фактов. При построении схемы взаимодействия корпоративного Хранилища и Витрин Данных в рамках создания СППР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть ряд Витрин, заполняемых данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и их анализ. Несколько фирм предлагает системы построения Витрин Данных: Informatica (PowerMart Suite), Sagent Technology (Data Mart Solution) и Oracle (DataMart Suite). Для иллюстрации процесса разработки Витрины Данных можно рассмотреть вкратце состав и функциональность пакета DataMart Suite. Пакет включает пять основных компонентов: Data Mart Designer, Data Mart Builder, Oracle7 Enterprize Server, Web Server и Discoverer 3.0. Data Mart Designer позволяет описывать структуру Витрины и запоминать ее в Репозитарии. На выходе Data Mart Designer порождает описание на языке DDL SQL, которое затем подается на вход Oracle7 Enterprize Server. В результате создается структура базы данных, реализующая Витрину Данных. В ходе построения Витрины пользователь может применять существующие описания структур или строить Витрину "с нуля". Кроме того, Data Mart Designer позволяет строить приложения для Oracle Web Server на базе PL/SQL. Data Mart Builder извлекает данные из внешних источников и заполняет Витрину. Он обладает наглядным специализированным интерфейсом, отображающим потоки данных при заполнении Хранилища. Data Mart Builder способен извлекать данные из реляционных СУБД и CSV-файлов. Web Server предоставляет открытую платформу для разработки Web-приложений. Он включает Web Request Broker (WRB), реализованный на основе технологии картриджей и позволяющий разрабатывать Web-приложения, встраиваемые в Web Server. В качестве средств разработки могут использоваться Java, PL/SQL, LiveHTML, C и C++. Discoverer 3.0 - это средство конечного пользователя, позволяющее генерировать отчеты, а также выполнять некоторые OLAP-операции с Витриной Данных. Отчеты, построенные с помощью Discoverer 3.0, можно экспортировать в формате HTML, делая их доступными для Web-браузеров. Discoverer 3.0 также позволяет создавать и поддерживать таблицы агрегированных данных. Помимо этого, DataMart Suite включает готовое приложение, называемое Sales Analyzer. 5.5. Хранилище Метаданных (Репозитарий) Принципиальное отличие Системы Поддержки Принятия Решений на основе Хранилищ Данных от интегрированной системы управления предприятием состоит в обязательном наличии в СППР метаданных. В общем случае метаданные помещаются в централизованно управляемый Репозитарий, в который включается информация о структуре данных Хранилища, структурах данных, импортируемых из различных источников, о самих источниках, методах загрузки и агрегирования данных, сведения о средствах доступа, а также бизнес-правилах оценки и представления информации. Там же содержится информация о структуре бизнес-понятий. Так, например, клиенты могут подразделяться на кредитоспособных и некредитоспособных, на имеющих или не имеющих льготы, они могут быть сгруппированы по возрастному признаку, по местам проживания и т. п. Как следствие, появляются новые бизнес-понятия: ПОСТОЯННЫЙ КЛИЕНТ, ПЕРСПЕКТИВНЫЙ КЛИЕНТ и т. п. Некоторые бизнес-понятия (соответствующие измерениям в Хранилище Данных) образуют иерархии, например ТОВАР может включать ПРОДУКТЫ ПИТАНИЯ и ЛЕКАРСТВЕННЫЕ ПРЕПАРАТЫ, которые, в свою очередь, подразделяются на группы продуктов и лекарств и т. д. Широко известны Репозитарии, входящие в состав популярных CASE-средств (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA Research)), систем разработки приложений (Developer 2000 (Oracle), Power Builder (Sybase)), администрирования и поддержки информационных систем (Platinum, MSP). Все они, однако, решают частные задачи, работая с ограниченным набором метаданных, и предназначены, в основном, для облегчения труда профессионалов - проектировщиков, разработчиков и администраторов информационных систем. Репозитарий метаданных СППР на основе ХД предназначен не только для профессионалов, но и для пользователей, которым он служит в качестве поддержки при формировании бизнес-запросов. Более того, развитая система управления метаданными должна обеспечивать возможность управления бизнес-понятиями со стороны пользователей, которые могут изменять содержание метаданных и образовывать новые понятия по мере развития бизнеса. Тем самым репозитарий превращается из факультативного инструмента в обязательный компонент СППР и ХД. Разработка системы управления метаданными сходна с разработкой распределенной транзакционной системы. При ее создании необходимо решать следующие задачи: анализ процессов возникновения, изменения и использования метаданных; проектирование структуры хранения метаданных (например, в составе реляционной базы данных); организация прав доступа к метаданным; блокировка и разрешение конфликтов при совместном использовании метаданных (что очень часто возникает при изменении общих бизнес-понятий в рамках структурного подразделения); разделение метаданных между Витринами Данных; согласование метаданных ХД с Репозиториями CASE-средств, применяемых при проектировании и разработке Хранилищ; реализации пользовательского интерфейса с Репозитарием. Опыт реализации систем управления метаданными показывает, что основная трудность состоит не в программной реализации, а в определении содержания конкретных метаданных и методики работы с ними, в практическом внедрении Репозитория. Кроме того, если подходить к проектированию итерационно, последовательно переходя от разработки соответствующих бумажных форм и методик к созданию CASE-модели метаданных, от централизованной к распределенной модели, используя в качестве системы для хранения метаданных промышленную реляционную СУБД, можно значительно упростить задачу. Поскольку большинство CASE-средств использует различные форматы метаданных, поставщики систем управления метаданными выработали стандарт обмена MDIS, обеспечивающий возможность интеграции CASE-средств в СППР на основе ХД. К сожалению, не все предлагаемые сегодня на российском рынке продукты соответствуют этому стандарту, поэтому преобразование форматов метаданных представляет собой достаточно сложный процесс, упростить который призваны специализированные программные продукты, в том числе, например, средства фирмы Evolutionary Technologies International или Prism Solutions (Data Warehouse Directory). Когда структура метаданных разработана и система управления ими спроектирована, решается задача заполнения и обновления данных в ХД. 5.6. Загрузка Хранилища Какие данные должны быть помещены в Хранилище? Как найти и извлечь эти данные? Как обеспечить корректность данных в Хранилище? Подобные вопросы являются ключевыми при проектировании Хранилищ. В сущности, определяя, чем заполняется Хранилище, мы неявно определяем спектр задач, которые будут решаться с его помощью, и круг потенциальных пользователей. При описании технологии заполнения Хранилища будем различать три взаимосвязанные задачи: Сбор Данных (Data Acquisition), Очистка Данных (Data Cleansing) и Агрегирование Данных (Data Consolidation). Под Сбором Данных будем понимать процесс, который состоит в организации передачи данных из внешних источников в Хранилище. Лишь некоторые аспекты этого процесса полностью или частично автоматизированы в имеющихся продуктах. Прежде всего, это относится к интерфейсам с существующими БД. Как правило, здесь имеется несколько возможностей. Во-первых, поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.). Во-вторых, практически всегда имеется ODBC-интерфейс, и, в-третьих, можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase. Набор имеющихся интерфейсов - важнейшая характеристика, которая часто позволяет оценить, для каких задач проектировался продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, DB2/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку Lotus Notes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования "чужих" данных (таков, например, Replication Server фирмы Sybase). Второй аспект процесса сбора данных, который автоматизирован в некоторых продуктах, - это организация процесса пополнения Хранилища. В том же InfoPump, например, имеется возможность строить расписание пополнения Хранилища данными либо на временной основе, либо с использованием механизма событий. Имеются и более сложные программные комбинации, например корпорация Software AG разработала собственное решение для сбора и очистки данных, называемое, SourcePoint, которое на нижнем уровне использует PASSPORT, а функции организации расписаний реализует как надстройку над этим нижним уровнем. Помимо этого SourcePoint реализует параллельные извлечение, передачу данных и заполнение Хранилища. Под очисткой данных обычно понимается процесс модификации данных по ходу заполнения Хранилища: исключение нежелательных дубликатов, восстановление пропущенных данных, приведение данных к единому формату, удаление нежелательных символов (например, управляющих) и унификация типов данных, проверка на целостность. Практически все продукты располагают тем или иным набором средств очистки данных и соответствующими средствами диагностики. При заполнении Хранилища агрегированными данными мы должны обеспечить выборку данных из транзакционной базы данных и других источников в соответствии с метаданными, поскольку агрегирование происходит в терминах бизнес-понятий. Так, например, агрегированная величина "объем продаж продукта Х в регионе Y за последний квартал" содержит понятия "продукт" и "регион", которые являются бизнес-понятиями данного предприятия. Следует подчеркнуть, что задача выборки необходимых данных не может быть решена полностью автоматически: возможны коллизии (отсутствие необходимых данных, ошибки в данных и т. п.), когда вмешательство человека окажется необходимым. Далее, предполагая, что объектом анализа являются числовые показатели, связанные с бизнес-понятиями, такие как ОБЪЕМ ПРОДАЖ или ПРИБЫЛЬ, необходимо определить правила вычисления этих показателей для составных бизнес-понятий, исходя из их значений для более простых бизнес-понятий. Это и есть правила агрегирования. Простейшей архитектурой системы на основе ХД является архитектура клиент-сервер. Традиционно само хранилище размещается на сервере (или на серверах), а анализ данных выполняется на клиентах. Некоторое усложнение в эту схему вносят Витрины Данных. Они также размещаются на серверах, но, учитывая взаимодействия между Витринами, приходится вводить так называемые переходники (Hub Servers), через которые идет обмен данными между Витринами. 5.7. Анализ данных: OLAP Предположим теперь, что в общем случае имеется корпоративное ХД и ряд Витрин Данных. Каким образом следует организовать доступ к информации для анализа? Сейчас принята точка зрения, согласно которой требуется обеспечить возможность анализа данных как из Витрин, так и непосредственно из Хранилища. Разница здесь определяется не столько размером базы (Витрина может лишь ненамного уступать Хранилищу), сколько тем, что Витрины, как правило, не содержат детальных - неагрегированных данных. Это означает, что анализ данных Витрины не требует глубокой детализации и часто может быть выполнен более простыми средствами. Наряду с мощными серверами многомерных баз данных и ROLAP-серверами на рынке предлагаются клиентские OLAP-серверы, предназаначенные, главным образом, для работы с небольшими объемами данных и ориентированные на индивидуального пользователя. Подобные системы были названы настольными, или DOLAP-серверами (Desktop OLAP). В этом направлении работают фирмы Business Objects (Business Objects 5.0), Andyne (CubeCreator, PaBLO), Cognos, Brio Technology. Лидером пока считается компания Cognos, поставляющая продукты PowerPlay, Impromptu и Scenario. PowerPlay - это настольный OLAP-сервер, для извлечения данных из реляционных баз данных (Paradox, dBase, Clipper), "плоских" файлов и электронных таблиц (Microsoft Excel) используется генератор запросов и отчетов Impromptu. Затем специальный компонент, называемый Transformer, помещает извлеченные данные в клиентскую многомерную базу, которая называется PowerCube. Потребителям предоставляются широкие возможности по управлению PowerCube: передавать ее от пользователя к пользователю по запросу и принудительно, помещать на сервер для разделения доступа к ней или пересылать по электронной почте. Cognos постаралась сделать свой продукт максимально открытым: во-первых, PowerCube может быть помещен в реляционные базы Oracle, Informix, Sybase, MS SQL Server на платформах UNIX, HP/UX, Sun Solaris, IBM AIX, во-вторых, сам PowerPlay способен анализировать содержимое не только PowerCube, но и других многомерных баз данных. Стоит отметить, что все эти фирмы объединяет стремление включить в свои продукты компоненты, предназначенные для Интеллектуального Анализа Данных (Data Mining, ИАД). Например, усилия Business Objects и Cognos направлены на подготовку окончательных версий компонентов Business Miner и Scenario, соответственно, предназначенных именно для ИАД. Необходимо также упомянуть о новом направлении развития архитектур систем клиент-сервер, называемом трехуровневой архитектурой клиент-агент-сервер. Применительно к СППР традиционная двухуровневая архитектура подразумевает, что Хранилище Данных или Витрина Данных размещаются на сервере, а аналитическая обработка и пользовательские интерфейсы поддерживаются клиентом. Можно привести некоторые условия, при которых двухуровневая архитектура работает эффективно: объем данных, пересылаемых между клиентом и сервером, не очень велик; большая часть вычислений может быть выполнена заранее; круг пользователей-клиентов четко определен, так что сервер обслуживает умеренное число запросов в единицу времени; нет необходимости поддерживать разделение данных между клиентами (клиенты изолированы друг от друга); приложения не требуют постоянных модификаций и усовершенствований. Практика показывает, что аналитическая обработка, несмотря на подготовленность агрегированных данных в Хранилище или Витрине, может оказаться не такой простой задачей. Например, если требуется проанализировать отношение прибыли к расходам, возможно, эту задачу придется решать динамически, поскольку именно такого отношения в Хранилище может и не быть (при том, что прибыль и расходы, скорее всего, там присутствуют). Выполнение подобных вычислений на клиенте перегружает систему, увеличивает время отклика, требует повторных вычислений при повторении запроса или хранения однажды вычисленных значений в памяти клиента. В этом случае принято говорить, что клиент становится "тяжелым" (fat), что приводит к деградации всей системы. В трехуровневых архитектурах между клиентом и сервером (который теперь называется корпоративным сервером) помещается еще одни сервер, называемый сервером приложений. Обязанностью корпоративного сервера является работа с корпоративными данными, например с Хранилищем Данных: организация доступа к Хранилищу, разделение ресурсов между клиентами и т. д. Клиент по-прежнему реализует пользовательский интерфейс, выполняет пользовательские операции с данными и хранит локальные данные. Сервер приложений выполняет роль посредника между клиентом и корпоративным сервером, снижая нагрузку на последний. Для данной архитектуры в примере с поиском отношения прибыль/расходы вычисление этого отношения следовало бы выполнять на сервере приложений. В ROLAP-системах сервер приложений выполняет соединения таблиц в соответствии с пользовательским запросом. Кроме того, сервер приложений может осуществлять динамическое агрегирование данных. В DOLAP-системах сервер приложений может хранить клиентские гиперкубы. Логическое разделение системы на три уровня не означает наличия трех физических уровней обработки. Теоретически все три уровня могут быть реализованы на одной машине. Наличие трех логических уровней означает, во-первых, строгое разделение обязанностей между уровнями и, во-вторых, регламентацию связей между ними. Так, например, клиент не может непосредственно обратиться к корпоративному серверу. 6. Интеллектуальный анализ данных Интеллектуальный анализ данных (ИАД) обычно определяют как метод поддержки принятия решений, основанный на анализе зависимостей между данными. В рамках такой общей формулировки обычный анализ отчетов, построенных по базе данных, также может рассматриваться как разновидность ИАД. Чтобы перейти к рассмотрению более продвинутых технологий ИАД, посмотрим, как можно автоматизировать поиск зависимостей между данными. Существует два подхода. В первом случае пользователь сам выдвигает гипотезы относительно зависимостей между данными. Фактически традиционные технологии анализа развивали именно этот подход. Действительно, гипотеза приводила к построению отчета, анализ отчета к выдвижению новой гипотезы и т. д. Это справедливо и в том случае, когда пользователь применяет такие развитые средства, как OLAP, поскольку процесс поиска по-прежнему полностью контролируется человеком. Во многих системах ИАД в этом процессе автоматизирована проверка достоверности гипотез, что позволяет оценить вероятность тех или иных зависимостей в базе данных. Типичным примером может служить, такой вывод: вероятность того, что рост продаж продукта А обусловлен ростом продаж продукта В, составляет 0,75. Второй подход основывается на том, что зависимости между данными ищутся автоматически. Количество продуктов, выполняющих автоматический поиск зависимостей, говорит о растущем интересе производителей и потребителей к системам именно такого типа. Сообщается о резком росте прибылей клиентов за счет верно найденной, заранее неизвестной зависимости. Упоминается пример сети британских универсамов, где ИАД применялся при анализе убытков от хищений товаров в торговых залах. Было обнаружено, что к наибольшим убыткам приводят хищения мелких "сопутствующих" товаров: ручек, батареек и т. п. Простой перенос прилавков с этими товарами ближе к расчетным узлам позволил снизить убытки на 1000%. Сегодня количество фирм, предлагающих продукты ИАД, исчисляется десятками, однако, не рассматривая их подробно, приведем лишь классификацию процессов ИАД, применяющихся на практике. Процессы ИАД подразделяются на три большие группы: поиск зависимостей (discovery), прогнозирование (predictive modelling) и анализ аномалий (forensic analysis). Поиск зависимостей состоит в просмотре базы данных с целью автоматического выявления зависимостей. Проблема здесь заключается в отборе действительно важных зависимостей из огромного числа существующих в БД. Прогнозирование предполагает, что пользователь может предъявить системе записи с незаполненными полями и запросить недостающие значения. Система сама анализирует содержимое базы и делает правдоподобное предсказание относительно этих значений. Анализ аномалий - это процесс поиска подозрительных данных, сильно отклоняющихся от устойчивых зависимостей. В системах ИАД применяется чрезвычайно широкий спектр математических, логических и статистических методов: от анализа деревьев решений (Business Objects) до нейронных сетей (NeoVista). Пока трудно говорить о перспективности или предпочтительности тех или иных методов. Технология ИАД сейчас находится в начале пути, и практического материала для каких-либо рекомендаций или обобщений явно недостаточно. Необходимо также упомянуть об интеграции ИАД в информационные системы. Многие методы ИАД возникли из задач экспертного анализа, поэтому входными данными для них традиционно служат "плоские" файлы данных. При использовании ИАД в СППР часто приходится сначала извлекать данные из Хранилища, преобразовывать их в файлы нужных форматов и только потом переходить собственно к интеллектуальному анализу. Затем результаты анализа требуется сформулировать в терминах бизнес-понятий. Важный шаг вперед сделала компания Information Discovery, разработавшая системы OLAP Discovery System и OLAP Affinity System, предназначенные специально для интеллектуального анализа многомерных агрегированных данных. Заключение ПО итгам работы необходимо сделать выводы. Итак, системы поддержки принятия решений: 1. Помогают произвести оценку обстановки (ситуаций), осуществить выбор критериев и оценить их относительную важность. 2. Генерируют возможные решения (сценарии действий). 3. Осуществляют оценку сценариев (действий, решений) и выбирают лучший. 4. Обеспечивают постоянный обмен информацией об обстановке принимаемых решений и помогают согласовать групповые решения. 5. Моделируют принимаемые решения (в тех случаях, когда это возможно). 6. Осуществляют компьютерный динамический анализ возможных последствий принимаемых решений. 7. Производят сбор данных о результатах реализации принятых решений и осуществляют оценку результатов. 8. Системы поддержки принятия решений могут быть сосредоточенные и распределённые. Создание СППР на основе хранилища данных ? сложный, но обозримый процесс, требующий знания бизнеса, программно-технического инструментария и опыта выполнения крупных проектов. Вместе с тем внедрение подобных систем может дать преимущества в бизнесе, которые будут тем ощутимее, чем раньше организация начнет создание СППР. По прогнозам консалтинговой фирмы Gartner Group, к 2000 году примерно 90-95% компаний будут использовать ХД. Значимость информационных систем подобного уровня признается и представителями большинства российских компаний. Однако в силу ряда причин, инициативные или заказные работы ведутся зачастую достаточно бессистемно, в основном в двух направлениях: закупка и тестирование разнообразных продуктов, применяемых при создании СППР и ХД (к сожалению, большинство из них плохо сопрягаются друг с другом, из-за чего создается ложное впечатление "неподъемности" проблемы); решение частного вопроса о повышении производительности отчетных систем путем локального перепроектирования структуры хранения или перехода на более современные и сложные программные средства. Список использованных источников Ларичев О.И., Мошкович Е.М. Качественные методы принятия решений. -М.: Наука. Физматлит, 1996. Лебедев И. П., Соколова Л. Е. Система поддержки принятия хозяйственных решений в производственном менеджменте. / Под ред. В. И. Павловца. - М.: Изд-во МЭИ, 1997. Луценко Е. В. Теоретические основы и технология адаптивного семантического анализа в поддержке принятия решений. -Краснодар: Науч.-произв. предприятие "ЭЙДОС": КЮИ, 1996. - 278 с. Матвеев Л. А. Информационные системы: поддержка принятия решений. -СПб.: Изд-во С.-Петерб. ун-та экономики и финансов, 1996. - 241 с. Отчет "Системы поддержки принятия решений". //НИИ "Контур" ГУИС ФАПСИ, -М., 1998. Программный комплекс "ПРОГНОЗ" ? интеллектуальная система поддержки принятия решения для оператора реактора РБМК / Р. В. Арутюнян, А. М. Афанасьев, А. А. Афанасьева, Л. А. Большов. - М.: ИБРАЭ РАН, 1997. Синюк В. Г., Котельников А. П. Системы поддержки принятия решений: основные понятия и вопросы применения. - Белгород: Изд-во БелГТАСМ, 1998. - 78 с. Устинова Г. М. Информационные системы менеджмента: Основные аналит. технологии в поддержке принятия решений: Учеб. пособие / Г.М. Устинова. - СПб.: DiaSoftUP, 2000. - 357 с. Хованов Н. В. Математические модели риска и неопределенности - СПб.: Изд-во С.-Петерб. ун-та, 1998. - 199 с. 29 Работа на этой странице представлена для Вашего ознакомления в текстовом (сокращенном) виде. Для того, чтобы получить полностью оформленную работу в формате Word, со всеми сносками, таблицами, рисунками, графиками, приложениями и т.д., достаточно просто её СКАЧАТЬ.  |
|
Банк готовых работ
Форма заказа
Скачать работу
экономические  Copyright © refbank.ru 2005-2024
Все права на представленные на сайте материалы принадлежат refbank.ru. Перепечатка, копирование материалов без разрешения администрации сайта запрещено. |
|