Выбор архитектуры. 
Информационная система службы выбора гостиниц п. Домбай. 
Отдел по работе с клиентами

По способу организации ИС имеют следующие виды;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.13.

Сравнительная характеристика архитектуры ИС.

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

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

k_j= 1.

Таблица 3.14.

Шкала оценок.

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

Таблица 3.15.

Оценка технико-экономической эффективности.

Посчитаем интегральный технико-экономический показатель:

для файл-сервера Q_f:

для клиент-сервер Q_k:

для многоуровневой системы Q_m:

для интернет/интранет технологии Q_i:

Интегральный технико-экономический показатель между файл-серверной архитектурой и клиент-серверной равен:

Q = Q_k/ Q_f = 3,5/0,9 = 3,89.

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

Интегральный технико-экономический показатель между клиент-серверной архитектурой и многоуровневой системой равен:

Q = Q_k/ Q_m = 3,5/1,7 = 2,06.

т.к. технико-экономический показатель больше 1 выбор в сторону клиент-серверной архитектуры.

Интегральный технико-экономический показатель между клиент-серверной архитектурой и интернет/интранет технологии равен:

Q = Q_k/ Q_m = 1,7/3,5 = 0,605.

т.к. технико-экономический показатель меньше 1 выбор в сторону интернет/интранет технологий.

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

Разработка логической и физической структуры БД

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

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

Результатом выполнения этих действия является логическая модель данных, представленная на рисунке 3.1.

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

Рис. 3.1 Логическая модель данных

На основе построенной логической модели данных используя утилиту PhpMyAdmin и СУБД MySQL создадим базу данных для нашей информационной системы, физическая модель которой представлена на рисунке 3.2.

Рис. 3.2 Физическая структура базы данных