Выбор архитектуры информационной системы

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы :

• · архитектура файл-сервер;
• · архитектура клиент-сервер;
• · многоуровневая система;
• · на основе интернет/интранеттехнологий.

Рассмотрим более подробно особенности архитектуры построения информационных приложений.

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью файл-серверной архитектуры является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации. Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными размещаются на сервере, а диалог логики, обработка логики — на клиенте. Двух уровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД — на сервере.

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней;

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

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Borland и д.р. [7].

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

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

Интернет/интранет — технологии основной акцент пока что делается на разработке инструментальных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение интернет/интранет — технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер — сервер приложений — сервер баз данных — сервер динамических приложений — web-сервер. [7].

Благодаря интеграции интернет/интранет — технологии и архитектуре клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.

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

Таблица 3.13 — Сравнительная характеристика архитектуры ИС.

Проведем расчет выбора архитектуры ИС по выбранным параметрам на основании технико-экономической эффективности.

Оценим их по каждому i-ому показателю качества по 5-ти бальной шкале.

Определим каждому критерию весовой коэффициент kj, причем.

kj= 1.

Таблица 3.14 — Шкала оценок.

Результаты сравнения сведем результаты сравнения в таблицу 3.15.

Таблица 3.15 — Оценка технико-экономической эффективности.

Параметры сравнения/. оценка.	Весовой коэффициент.	Файл-сервер	Клиент-сервер	Многоуровневая система.	Интернет/интранет технологии.
		Ajf.	kj •Ajf.	Ajk.	kj •Ajk.	Ajm.	kj •Ajm.	Aji.	kj •Aji.
Установка СУБД.	0,15.		0,15.		0,6.		0,45.		0,45.
Объемы передаваемых данных.	0,25.		0,25.		0,75.
Применение на предприятии.	0,35.				1,4.
Знакомство персонала.	0,25.		0,5.		0,75.		0,25.		0,25.
Интегральный технико-экономический показатель, Q.		Qf = 0,9.	Qk = 3,5.	Qm = 1,7.	Qi = 1,… Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими. Преимущества IDEF1X Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком. Согласно данной методологии, [2,9], процесс построения информационной модели состоит из следующих шагов: · определение сущностей; определение зависимостей между сущностями; · задание первичных и альтернативных ключей; · определение атрибутов сущностей; · приведение модели к требуемому уровню нормальной формы; · переход к физическому описанию модели: назначение соответствий имя сущности — имя таблицы, атрибут сущности — атрибут таблицы; · задание триггеров, процедур и ограничений; · генерация базы данных. Логическая структура базы показана на рисунке 3.5. Рисунок 3.5 — Логическая модель данных Логическая модель данных показывает основные объекты, данные о которых необходимо хранить в процессе работы информационной системы службы сбыта КФХ «Воля». Для перехода на физический уровень следует исключить связи «многие ко многим» и указать типы данных (рисунок 3.6). Рисунок 3.6 — Физическая модель данных Устранения связей многие-ко-многим не понадобилось ввиду их отсутствия, поэтому переход был произведен путем спецификации СУБД и типов данных атрибутов. Сведем описание структуры в таблицу 3.16. Таблица 3.16 — Описание сущностей. Имя. Описание. Связи. Загруженность. Хранение истории загруженности каждой из площадок. Площадка. Заказ. Хранение информации о заказах клиентов, необходимой для печати внутренней документации. История посещений, Клиент Спецификация. История посещений. Хранение истории посещения службы сбыта для каждого транспорта. Транспорт, заказ. Клиент. Хранение минимально необходимой информации о клиентах. заказ. Накладная. Хранение информации для заполнения товарно-транспортной накладной. транспорт. Площадка. Хранение данных об отгрузочных площадках. Смена, загруженность. Смена. Состав рабочих, задействованных на каждой из площадок. Сотрудник, площадка. Сотрудник. Хранение информации о рабочих, необходимой для формирования смен. смена. Спецификация. Хранение перечня товаров, содержащихся в заказе. заказ. Транспорт. Хранение информации о транспорте. Накладная, история посещений.