книги / Проектирование систем управления технологическими процессами и производствами

и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle). В такую процедуру можно поместить серьезную часть приложения, которое при выпол­ нении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента;

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

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

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

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

“клиенты” становятся более требовательными к техническим ресур­ сам, однако при этом и ресурсы сервера не уменьшаются.

Архитектура “клиент - сервер” на первый взгляд кажется гораздо более дорогой, чем архитектура “файл - сервер”: требуются более мощные технические средства (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако это верно лишь частично. Наиболее существенным преиму­ ществом клиент-серверной архитектуры по сравнению с файлсерверной является ее маштабируемость и способность к развитию.

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

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

Intranet-приложения

Развитие глобальных вычислительных сетей Internet (e-mail, ftp, telnet, Gopher, www и т.д.) естественным образом повлияло на тех­ нологию создания корпоративных систем управления, породив новую архитектуру под названием Intranet. Intranet-система представляет собой корпоративную автоматизированную систему, в которой ис­ пользуются методы и средства Internet. Такая система может быть локальной, изолированной от глобальной вычислительной сети.

В //7/гаяе/-системе могут использоваться все возможные службы Internet, однако наибольшее внимание привлекает служба www (World Wide Web). Это обусловлено следующим:

- во-первых, применяя документы HTML, можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых ^6-серверов;

- во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров (“обходчиков”) избавляет разра­ ботчиков от необходимости создавать собственные интерфейсы, предоставляя пользователям удобные и развитые механизмы доступа к информации. Структурная схема простой организации Intranet- системы приведена на рис. 6.7.

Рис. 6.7. Структурная схема простой организации Intranet-системы

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

Для того чтобы изменить информационное наполнение веб­ сервера, необходимо приостановить работу системы, внести изме­ нения в #7Ш ,-описания и только затем продолжить нормальное функционирование.

Перечисленные трудности могут быть разрешены с использо­ ванием более развитых механизмов м'еб-технологий, которая непре­ рывно совершенствуется. Существенным недостатком этих механиз­ мов является полное отсутствие стандартов.

Использование внешних процедур обеспечивает также возмож­ ность модификации документов, поддерживаемых w ft-сервером, создание временных “виртуальных” HTML-страниц.

Основным программным продуктом, в среде которого разра­ батываются прикладные программы в Intranet, является язык Java. Мобильные коды (апплеты), полученные в результате компиляции Ляга-программы, могут быть привязаны к ЯГЖ-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть специализирован как шлюз к серверу баз данных. Струк­ турная схема автоматизированной системы на базе /л/галеЛ-системы с использованием апплетов представлена на рис. 6.9.

Рис. 6.9. Доступ к базе данных на стороне клиента

Intranet-системы

Intranet является удобным и мощным средством разработки и использования СУ. Единственным недостатком подхода можно счи­ тать постоянное изменение механизмов и отсутствие стандартов.

Выбор архитектуры программного обеспечения и операци­ онной системы

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

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

Кроме выбора платформы, необходимо выяснить:

-будет ли это архитектура “файл - сервер”, “клиент - сервер” или Intranet;

-будет ли применяться 3-уровневая архитектура: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

-будет ли база данных однородной, т.е. будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

-будут ли для достижения должной производительности ис­ пользоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

Эти решения обычно принимаются на начальном этапе проек­ тирования (на этапе структурного анализа).

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

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

6.6. Требования к разработке хранилищ данных

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

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

вцелом.

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

3.Хранилище данных содержит единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оператив­ ных баз данных и быть согласованной.

4.Оперативные системы управления проектируются и разраба­ тываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выби­

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

5. Оперативные базы данных по своей природе сильно измен­ чивы. Поэтому при выполнении операций массовой выборки необ­ ходимо использовать быстрые методы индексации, поддерживать упо­ рядоченность информационных массивов, сохранять заранее вычис­ ленные значения агрегатных функций и т.д.

Структурная схема хранилища данных и ее взаимодействие с про­ граммным обеспечением системы оперативной аналитической обработки данных представлена на рис. 6.10.

Рис. 6.10. Структурная схема хранилища данных и ее взаимодействие с программным обеспечением

системы оперативной аналитической обработки данных

К основным требованиям при разработке хранилищ данных систем управления, с точки зрения проектировщика относятся:

- многомерное концептуальное представление данных. Это требование возникает, когда пользователь представляет историю и деятельность своей организации многомерными. OZ/lP-модели должны поддерживать это представление, и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных;

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

- доступность. Логическая схема, с которой работает OLAP- система, должна отображаться в схемах разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление;

-согласованная эффективность производства отчетов, которая не должна деградировать при увеличении числа измерений;

-архитектура “клиент-сервер”. Серверная часть OLAP-систе­ мы должна быть достаточно развитой, что позволяет клиентам подключаться к ней с минимальными усилиями и затратами на дополнительное программирование;

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

-управление динамическими разреженными матрицами. Сервер OLAP-систшы должен эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, Л-деревья или комби­ нации этих методов;

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

-неограниченные операции между измерениями. При выпол­ нении многомерного анализа данных все измерения создаются и об­ рабатываются единообразно. OLAP-систша должна быть в состоянии выполнять соответствующие вычисления между измерениями;

-интуитивное манипулирование данными. Манипуляции должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства;

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

6.7. Технология программирования OLAP для поддержки принятия решений в системах управления

Основные определения

O LAP- это Online Analytical Processing, т.е. оперативный анализ данных. Двенадцать определяющих принципов OLAP сформулировал в 1993 г. Е.Ф. Кодц - “изобретатель” реляционных БД. Позже его определение было переработано в так называемый тест FASMI, требующий, чтобы OZ^P-приложение предоставляло возможности быстрого анализа разделяемой многомерной информации.

Тест FASMI можно расшифровать следующим образом:

-Fast (быстрый), т.е. анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время отклика

-5 с или менее;

-Analysis (анализ), т.е. должна быть возможность осущес­

твлять основные типы числового и статистического анализа, предоп­ ределенного разработчиком приложения или произвольно опре­ деляемого пользователем;

-Shared (разделяемой), т.е. множество пользователей должно иметь доступ к данным, при этом необходимо контролировать доступ

кконфиденциальной информации;

-Multidimensional (многомерной) - это основная, наиболее существенная характеристика OLAP\

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

6.7.1 Способы аналитической обработки данных в системах поддержки и принятия решений

Концепции хранения и анализа корпоративных данных

По критерию режима анализа данных информационно-аналити­ ческие системы (ИАС) подразделяются на две категории (табл. 6.1):

1) статические (включающие предопределенный набор сцена­ риев обработки данных и составления отчетов). В эту категорию средств поддержки принятия решений (СППР) входят так называемые информационные системы руководителя (ИСР);