22
категории;
2. прикладные программы, которые реализуют процедуры второй
категории;
3. программы доступа к информационным ресурсам, которые
реализуют процедуры третьей категории.
Согласно этому выделяют 3 модели реализации технологии «клиент-
сервер» [21,28]:
1. модель доступа к удаленным данным;
2. модель сервера базы данных;
3. модель сервера приложений.
Достоинства архитектуры клиент-сервер:
элементарная синхронизация данных;
небольшая цена аппаратного обеспечения (мощным может быть
исключительно сервер);
оперативность изменения структуры данных.
Недостатки архитектуры клиент-сервер:
низкая защита от несанкционированного доступа;
зависимость от компьютерной сети;
значительная цена.
Построение сетевого многопользовательского приложения
осуществляется по принципу файл-серверной архитектуры. Данные в виде
одного, либо ряда файлов, располагаются на файловом сервере [17].
Файловый сервер принимает запросы, которые поступают по сети от
компьютеров-клиентов и выполняет передачу им требуемых данных. Однако,
обрабатываются эти данные на компьютерах-клиентах. На всех компьютерах
выполняется запуск полной копии процедуры обработки данных. Любая
копия независимо управляет файлами базы данных, которые содержат
данные. Единственной связью между подобными независимыми действиями
считается файл блокировок, который в обязательном порядке формируется
23
для любого файла базы данных [24]. При этом каждая копия осуществляет
изменения индексов, работу с системными таблицами и остальные функции,
которые входят в компетенцию СУБД.
Архитектурой «клиент-сервер» предоставляется возможность
устранения всех указанных недостатков. Помимо этого, она позволяет
наилучшим образом распределять вычислительную нагрузку между сервером
и клиентом, что также оказывает влияние на многие характеристики
системы: поддержку, производительность, стоимость.
Архитектура «клиент-сервер» может быть как двухуровневой, так и
трехуровневой [3,29].
В двухуровневой архитектуре присутствуют два звена: это клиентская
ЭВМ и сервер СУБД (рисунок 7).
Рисунок 7 – Двухуровневая архитектура «клиент-сервер»
В свою очередь, двухуровневая архитектура может быть устроена по-
разному [24,29]:
По принципу «тонкий сервер» – «толстый клиент» (рисунок 8);
По принципу «толстый сервер» – «тонкий клиент» (рисунок 9).
Архитектура «толстый сервер» – «тонкий клиент» является наиболее
предпочтительной по ряду причин:
большее быстродействие и производительность системы за счет
того, что все операции манипулирования и выбора данных происходят на
сервере, а клиенту передается только результат запроса;
не происходит блокировок информации на период изменения её
24
одним из клиентов;
каналы передачи данных не перегружаются из-за необходимости
передачи всего объема данных для модификации на клиенте;
логику функционирования системы можно изменить на сервере без
перекомпиляции клиентского ПО, что особенно актуально в условиях
территориальной удаленности рабочих мест [21].
Рисунок 8 – Двухуровневая архитектура «тонкий сервер» – «толстый клиент»
Рисунок 9 – Двухуровневая архитектура «толстый сервер» – «тонкий клиент»
Отличительной особенностью трехуровневой архитектуры является
окончательное разделение функций хранения данных, их обработки и
представления пользователю [3,18].
Создание автоматизированной системы с применением трехуровневой
архитектуры «клиент-сервер» представлено на рисунке 10.
Доступ к данным выполняется при помощи промежуточного звена –
сервера приложений, что предоставляет существенные преимущества в
25
сравнении с двухуровневой архитектурой при построении
крупномасштабных ИС на разных аппаратных платформах в условиях
большого количества клиентов и их территориальной распределенности. В
частности, такая архитектура позволяет обеспечивать дополнительную
надежность и отказоустойчивость системы, неограниченно наращивать
мощность системы и количество клиентов за счет использования нескольких
серверов приложений. Также становится возможным перенос БД с одной
СУБД на другую и изменение логики изменения данных без необходимости
обновления клиентских программ [21,28]. Сервер приложений, помимо
реализации предметных задач, еще и существенно снижает нагрузку на
сервер БД.
Рисунок 10 – Трехуровневая архитектура «клиент-сервер»
Наиболее целесообразным для решения поставленной задачи является
выбор двухуровневой архитектуры «толстый сервер» – «тонкий клиент», так
как преимущества трехуровневой архитектуры являются избыточными для
текущей задачи, а стоимость и сложность организации существенно выше. К
тому же, существующая информационная инфраструктура отлично подходит
именно для двухуровневой архитектуры.
Сервер приложений разработан при помощи технологии Delphi XE2
DataSnap. Передача данных между сервером и клиентом осуществляется
через протокол TCP. Сервер приложений взаимодействует с базой данных
через СУБД MS Access [11]. Подключение к БД выполняется через
технологию ADO.
26
В структуре сервера можно выделить две основные части: модуль
управления сервером (TdmServer) и модуль предоставления данных
(TdssmRemoteData). Описание модулей приводится в таблице 1.
Таблица 1 – Структура сервера приложений
№
Название модуля
Описание
Функции
1
TdmServer
Содержит компоненты для
подключения к системе
управления базами данных
(через ADO) и компоненты
для организации сервера
приложений (передача
данных выполняется через
протокол TCP).
Подключение к СУБД.
Управление сервером приложений
(установка соединений с
клиентскими приложениями,
аутентификация пользователей,
передача данных клиентам).
2
TdssmRemoteData
Модуль системы, который
определяет доступные
клиенту данные и
функциональность системы.
Экземпляр данного модуля
создается для каждого
подключенного клиента.
Авторизация.
Предоставление данных.
Предоставление
функциональности.
Основой клиентской части является модуль TdmData. Модуль
выполняет следующие функции: соединение с сервером; управление
предоставленными сервером наборами данных; получение доступа к
функционалу сервера (создание проекции интерфейса взаимодействия
«TdssmRemoteData»).
2.2. Выбор модели и концепции базы данных
Для выполнения поставленных задач можно использовать любую
распространенную СУБД. Чтобы взаимодействие пользователя с системой
было удобным, необходимо скрупулезно обдумать интерфейс системы,
чтобы он был простым и одновременно функциональным.
На сегодняшний день существует большое количество СУБД. Невзирая
на то, что они способны работать по-разному с различными объектами и
предоставляют пользователю всевозможные средства и функции, основная
часть СУБД опирается на единую устоявшуюся совокупность основных
27
функций [31].
Требования к СУБД, могут изменяться в зависимости от обозначенных
целей. Впрочем, можно выделить следующие группы критериев:
функциональные возможности, структура данных, специфичность создания
приложений, производительность, запросы к рабочей среде.
Проанализируем 5-ть реляционных СУБД в соответствии с методом
анализа иерархий, который предложил Т. Саати, осуществляя попарное
сравнение СУБД по каждому из критериев, вследствие чего создадим пять
матриц попарных сравнений альтернатив [32].
В качестве альтернатив будем рассматривать СУБД: DB2, Oracle [19],
Microsoft SQL Server, Postgre SQL и MySQL [5].
Выполним сравнение выбранных СУБД согласно аспекту «Структура
данных».
Всеми вышеперечисленными альтернативами реализуется объектно-
реляционная модель данных (ОРСУБД) или реляционная модель данных
(РСУБД), следовательно, все эти системы подходят для сравнения и анализа.
Анализ рассматриваемых альтернатив будем проводить по предусмотренным
видам данных. Подведя итоги такого анализа возможно построение матриц
сравнений согласно первому критерию (таблица 2), определить главное
собственное значение, вектор приоритетов и другие показатели [32].
Таблица 2 – Матрица сравнений альтернатив согласно аспекту
«Структура данных»
DB2
Oracle
MySQL
MS SQL
Postgre SQL
DB2
1
1
1
1
1
Oracle
1
1
1/4
1/5
1/3
MySQL
1
4
1
1/2
2
MS SQL Server
1
5
2
1
2
Postgre SQL
1
3
1/2
1/2
1
Вектор приоритетов: ОД 8 0,08 0,24 0,33 0,17
Отношение согласованности (ОС): 0,07. Индекс согласованности (ИС):
0,084. Главное собственное значение: 5,34.
Видно, что ОС в границах нормы.
28
Выполним сравнение выбранных СУБД согласно аспекту
«Функциональные возможности».
Пунктом «Триггеры и хранимые процедуры» определяется
существование в некоторой СУБД класса функций, процедур.
Проанализируем альтернативы по этому пункту (таблица 3).
Таблица 3 – Анализ альтернатив согласно пункту
«Триггеры и хранимые процедуры»
Триггер
Функция
Процедура
DB2
+
+
+
Microsoft SQL Server
+
+
+
MySQL
+
+
+
Oracle
+
+
+
Postgre SQL
+
+
+
Пунктом «Масштабируемость» предусматриваются возможности
анализируемой СУБД по повышению объема данных со временем и при
необходимости [10]. Следует рассмотреть наибольший потенциальный объем
сохраняемых данных для любой альтернативы (таблица 4).
Таблица 4 – Анализ альтернатив согласно пункту «Масштабируемость»
Размер БД
Размер таблицы
Размер строки
DB2
512 Тб
512 Тб
32677 байт
Microsoft SQL Server
524258 Тб
524258 Тб
∞
MySQL
∞
256 Тб
64 Kб
Oracle
∞
4 Гб* Размер блока
8 Kб
Postgre SQL
∞
32 Тб
1,6 Тб
Таким образом, проанализированы рассматриваемые альтернативы
согласно пунктам аспекта «Функциональные возможности». По итогам
анализа возможно построение матрицы альтернатив согласно второму
критерию (таблица 5), рассчитать основные показатели и вектор
приоритетов.
Таблица 5 – Матрица сравнений альтернатив согласно аспекту
«Функциональные возможности»
DB2
Oracle
MySQL
MS SQL
Postgre SQL
DB2
1
1/4
2
1/7
1/5
Oracle
4
1
1
1/4
1/2
MySQL
1/2
1
1
1/4
1/2
MS SQL Server
7
4
4
1
3
Postgre SQL
5
2
2
1/3
1
29
Отношение согласованности (ОС): 0,09. Индекс согласованности (ИС):
ОД 11. Главное собственное значение: 5,45.
Вектор приоритетов: 0,07 0,13 0,09 0,49 0,22
Проанализируем аспект «Особенности разработки приложений». В
процессе рассмотрения данного критерия следует дать оценку трудозатратам
на администрирование БД. Главные задачи подобного администрирования:
запасное копирование/восстановление, текущее администрирование БД,
установка, а также конфигурирование БД [21].
Построим матрицу сравнений альтернатив согласно третьему критерию
(таблица 6), рассчитаем основные показатели и вектор приоритетов.
Таблица 6 – Матрица сравнений альтернатив согласно аспекту
«Особенности разработки приложений»
DB2
Oracle
MySQL
MS SQL
Postgre SQL
DB2
1
1
1
1/6
1
Oracle
1
1
1
1/4
1
MySQL
1
1
1
1/4
1
MS SQL Server
6
4
4
1
3
Postgre SQL
1
1
1
1/3
1
Отношение согласованности (ОС): 0,01. Индекс согласованности (ИС):
0,01. Главное собственное значение: 5,04.
Проведем сравнение выбранных СУБД согласно критерию
«Производительность».
Итоги теста производительности ТРС изображены в таблице 7.
Таблица 7 – Итоги теста TPC
Название
Количество
транзакций, tpmC
Стоимость транзакции,
долларов/tpmC
Монитор
транзакций
Microsoft SQL Server
2005 х64
661.475
1.16 USD
Microsoft COM+
Oracle Database
Standard
631.766
1.08 USD
Microsoft COM+
IBM DB2 9.5
1.200.011
1.99 USD
Microsoft COM+
Применяя имеющиеся данные, проведем оценку рассматриваемых
СУБД согласно критерию «Производительность», выстроим матрицу
сравнений альтернатив (таблица 8).
Вектор приоритетов: 0,47 0,15 0,07 0,24 0,07
30
Отношение согласованности (ОС): 0,03. Индекс согласованности (ИС):
0,036. Главное собственное значение: 5,14.
Таблица 8 – Матрица сравнений альтернатив согласно аспекту
«Производительность»
DB2
Oracle
MySQL
MS SQL
Postgre SQL
DB2
1
4
5
3
5
Oracle
1/4
1
3
1/2
3
MySQL
1/5
1/3
1
1/4
1
MS SQL Server
1/3
2
4
1
4
Postgre SQL
1/5
1/3
1
1/4
1
Проанализируем аспект «Требования к рабочей среде». В таблице 9
приведены итоги анализа альтернатив согласно аспекту «Поддерживаемые
операционные системы».
Таблица 9 – Поддерживаемые ОС анализируемых систем
DB2
MS SQL Server
MySQL
Oracle
Postgre SQL
Windows
+
+
+
+
+
Mac OS
+
+
+
+
+
Linux
+
+
+
+
+
BSD
-
+
+
-
+
UNIX
+
+
+
+
+
AmigaOS
-
+
+
-
-
Symbian
-
+
+
-
-
Дадим оценку рассматриваемых СУБД согласно аспекту «Требования к
рабочей среде», выстроим матрицу сравнений альтернатив (таблица 10).
Предположим, что производительность обладает максимальной
важностью в сравнении с остальными критериями, запросы к рабочей среде
также считаются важными, поскольку при выборе СУБД на начальных
этапах затрагивается вопрос о совместимости анализируемой системы с
имеющимися программными и аппаратными средствами [18].
Таблица 10 – Матрица сравнений альтернатив согласно аспекту
«Требования к рабочей среде»
DB2
Oracle
MySQL
MS SQL
Postgre SQL
DB2
1
1
1/4
1/4
1/3
Oracle
1
1
1/4
1/4
1/2
MySQL
4
4
1
1
3
MS SQL Server
4
4
1
1
3
Postgre SQL
3
2
1/3
1/3
1
Выстроим матрицу сравнений критериев (таблица 11), пронумеруем их
31
для удобства от 1 до 5.
Таблица 11 – Матрица сравнений критериев
1
2
3
4
5
1
1
1
1/2
1/6
1/4
2
1
1
1/2
1/6
1/3
3
2
2
1
1/5
1/2
4
6
6
5
1
2
5
4
3
2
1/2
1
Вектор приоритетов альтернатив: 0,07 0,07 0,12 0,49 0,25
Отношение согласованности (ОС): 0,01. Индекс согласованности (ИС):
0,01. Главное собственное значение: 5,03.
Следовательно, места анализируемых СУБД распределились
следующим образом: Postgre SQL (0.11), Oracle (0.13), MySQL (0.16), DB2
(0.28), Microsoft SQL Server (0.32). На основании данного сравнения
выбираем для использования СУБД Microsoft SQL Server.
С целью создания программ для Windows существует множество
интегрированных сред разработки. К ним относятся С++ Builder, Delphi,
Visual С++, Visual Basic [33].
С появлением средства быстрой разработки приложений (RAD – rapid
application development) стало возможным программирование при помощи
готовых шаблонов и компонентов [8]. Для выбора среды программирования
автоматизированной системы выполним сравнение C++ Builder и Delphi.
Компания Borland на базе языка Object Pascal разработала систему
визуального программирования Delphi, построенную на основе активно
развивавшейся в то время теории объектно-ориентированного
программирования. Значительным шагом можно считать объектно-
ориентированный подход по созданию компонент, что позволило работать с
объектами, заранее наделенными нужными свойствами, а не использовать
сложные процедуры и функции [22]. Благодаря нормальной компиляции,
которая обеспечивает получение наиболее производительных программ,
обеспечивалось дополнительное преимущество. Две первые версии Delphi