скачать рефераты
  RSS    

Меню

Быстрый поиск

скачать рефераты

скачать рефератыРеферат: Создание систем поддержки принятия решений

Для систем ROLAP гиперкуб - это лишь пользовательский интерфейс, который эмулируется на обычной реляционной СУБД. В этой структуре можно хранить очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP - операций. Опыт эксплуатации ROLAP-продуктов показал, что они больше подходят на роль интеллектуальных генераторов отчетов, чем действительно оперативных средств анализа. Они применяются в таких областях, как розничная торговля, телекоммуникации, финансы, где количество данных велико, а высокой эффективности запросов не требуется. Примерами промышленных ROLAP-систем служат MetaCube фирмы Informix и Discoverer 3.0 фирмы Oracle. На практике иногда реализуется комбинация этих подходов.

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

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

 

2.3. Выбор структуры Хранилища Данных

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

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

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

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

При проектировании структуры хранилища часто возникает желание использовать как можно больше агрегатов и за счет этого повысить производительность системы. Нетрудно подсчитать, что для модели "звезда" с 10 измерениями можно построить 10!=3.63 миллиона различных агрегированных значений, размещение которых в памяти при установлении связей с соответствующими измерениями приведет к резкому увеличению занимаемого дискового пространства и замедлению доступа к данным. Другая крайность состоит в использовании слишком малого числа агрегатов, а это может привести к необходимости выполнять агрегирование динамически, что заметно снижает эффективность запросов. По некоторым оценкам, при определении оптимального количества агрегатов следует придерживаться принципа 80:20 - 80% ускорения достигается за счет использования 20% кандидатов на агрегаты.

 

2.4. Витрины Данных

Идея Витрины Данных (Data Mart) возникла несколько лет назад, когда стало очевидно, что разработка корпоративного хранилища - долгий и дорогостоящий процесс. Это обусловлено как организационными, так и техническими причинами:

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

-     технология принятия решений ориентирована на существующие технические возможности и с трудом поддается изменениям;

-     может возникнуть необходимость в частичном изменении организационной структуры компании;

-     требуются значительные инвестиции до того, как проект начнет окупаться;

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

-     освоение новых технологий и программных продуктов специалистами компании может потребовать много времени;

-     на этапе разработки бывает трудно наладить взаимодействие между разработчиками и будущими пользователями Хранилища.

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

Сейчас под Витриной Данных понимается специализированное Хранилище, обслуживающее одно из направлений деятельности компании, например учет запасов или маркетинг. Важно, что происходящие здесь бизнес-процессы, во-первых, относительно изучены и, во-вторых, не столь сложны, как процессы в масштабах всей компании. Количество сотрудников, вовлеченных в конкретную деятельность, также невелико (рекомендуется, чтобы Витрина обслуживала не более 10-15 человек). При этих условиях удается с использованием современных технологий развернуть Витрину подразделения за 3-4 месяца. Необходимо отметить, что успех небольшого проекта (стоимость которого невелика по сравнению со стоимостью разработки корпоративного Хранилища), во-первых, способствует продвижению новой технологии и, во-вторых, приводит к быстрой окупаемости затрат.

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

Фактическим стандартом структуры данных при разработке Витрины является "звезда", основанная на единственной таблице фактов. При построении схемы взаимодействия корпоративного Хранилища и Витрин Данных в рамках создания СППР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть ряд Витрин, заполняемых данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и их анализ.

2.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).

Когда структура метаданных разработана и система управления ими спроектирована, решается задача заполнения и обновления данных в ХД.

 

2.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), через которые идет обмен данными между Витринами.

 

2.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-системах сервер приложений может хранить клиентские гиперкубы.

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

 

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

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

Существует два подхода. В первом случае пользователь сам выдвигает гипотезы относительно зависимостей между данными. Фактически традиционные технологии анализа развивали именно этот подход. Действительно, гипотеза приводила к построению отчета, анализ отчета к выдвижению новой гипотезы и т. д. Это справедливо и в том случае, когда пользователь применяет такие развитые средства, как OLAP, поскольку процесс поиска по-прежнему полностью контролируется человеком. Во многих системах ИАД в этом процессе автоматизирована проверка достоверности гипотез, что позволяет оценить вероятность тех или иных зависимостей в базе данных. Типичным примером может служить, такой вывод: вероятность того, что рост продаж продукта А обусловлен ростом продаж продукта В, составляет 0,75.

Второй подход основывается на том, что зависимости между данными ищутся автоматически. Количество продуктов, выполняющих автоматический поиск зависимостей, говорит о растущем интересе производителей и потребителей к системам именно такого типа. Сообщается о резком росте прибылей клиентов за счет верно найденной, заранее неизвестной зависимости. Упоминается пример сети британских универсамов, где ИАД применялся при анализе убытков от хищений товаров в торговых залах. Было обнаружено, что к наибольшим убыткам приводят хищения мелких "сопутствующих" товаров: ручек, батареек и т. п. Простой перенос прилавков с этими товарами ближе к расчетным узлам позволил снизить убытки на 1000%.

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

Процессы ИАД подразделяются на три большие группы: поиск зависимостей (discovery), прогнозирование (predictive modelling) и анализ аномалий (forensic analysis). Поиск зависимостей состоит в просмотре базы данных с целью автоматического выявления зависимостей. Проблема здесь заключается в отборе действительно важных зависимостей из огромного числа существующих в БД. Прогнозирование предполагает, что пользователь может предъявить системе записи с незаполненными полями и запросить недостающие значения. Система сама анализирует содержимое базы и делает правдоподобное предсказание относительно этих значений. Анализ аномалий - это процесс поиска подозрительных данных, сильно отклоняющихся от устойчивых зависимостей.

В системах ИАД применяется чрезвычайно широкий спектр математических, логических и статистических методов: от анализа деревьев решений (Business Objects) до нейронных сетей (NeoVista). Пока трудно говорить о перспективности или предпочтительности тех или иных методов. Технология ИАД сейчас находится в начале пути, и практического материала для каких-либо рекомендаций или обобщений явно недостаточно.

Необходимо также упомянуть об интеграции ИАД в информационные системы. Многие методы ИАД возникли из задач экспертного анализа, поэтому входными данными для них традиционно служат "плоские" файлы данных. При использовании ИАД в СППР часто приходится сначала извлекать данные из Хранилища, преобразовывать их в файлы нужных форматов и только потом переходить собственно к интеллектуальному анализу. Затем результаты анализа требуется сформулировать в терминах бизнес-понятий. Важный шаг вперед сделала компания Information Discovery, разработавшая системы OLAP Discovery System и OLAP Affinity System, предназначенные специально для интеллектуального анализа многомерных агрегированных данных.


Заключение

Создание СППР на основе хранилищ данных - сложный, но обозримый процесс, требующий знания бизнеса, программно-технического инструментария и опыта выполнения крупных проектов. Вместе с тем внедрение подобных систем может дать преимущества в бизнесе, которые будут тем ощутимее, чем раньше организация начнет создание СППР. По прогнозам консалтинговой фирмы Gartner Group, к 2010 году примерно 90-95% компаний будут использовать хранилища данных.

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

-     закупка и тестирование разнообразных продуктов, применяемых при создании СППР и ХД (к сожалению, большинство из них плохо сопрягаются друг с другом, из-за чего создается ложное впечатление "неподъемности" проблемы);

-     решение частного вопроса о повышении производительности отчетных систем путем локального перепроектирования структуры хранения или перехода на более современные и сложные программные средства.


Список литературы

1. Система поддержки принятия решений в человеко-машинных системах управления. Труды Института проблем управления РАН им. В.А.Трапезникова. Том УШ. М.: ИПУРАН, 2000г. с. 46-59. 

2. Арлазаров В.Л., Журавлев Ю.И., Ларичев О.И., Лохин В.М., Макаров И.М., Рахманкулов В.З., Финн В.К. Теория и методы создания интеллектуальных компьютерных систем // Информационные технологии и вычислительные системы. -1998. -№1.

3. Валькман Ю.Р. Интеллектуальные технологии исследовательского проектирования. -Киев.: Port-Royal. -1998.

4. Комарцова Л.Г. Оптимизация вычислительной системы на ее имитационной модели. // Вестник МГТУ им. Н.Э.Баумана. - сер. "Приборостроение". -1999. -№2. -С.48-60.

5. Литвак Б.Г. Экспертные технологии управления. М.: Дело, 2004г.

6. Трахтенгеру Э.А. Компьютерная поддержка принятия решений. – М.: Наука, 1998.

7. Чекинов Г.П., Куляница А.Л., Бондаренко В.В. Применение ситуационного управления в информационной поддержке принятия решений при проектировании организационно-технических систем // Информационные технологии в проектировании и производстве, № 2, 2003.



Страницы: 1, 2


Новости

Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

  скачать рефераты              скачать рефераты

Новости

скачать рефераты

Обратная связь

Поиск
Обратная связь
Реклама и размещение статей на сайте
© 2010.