При обработке данных желательно использовать массивы нормативно-справочной информации. Это дает преимущества в скорости поиска, выбора, сортировки и т.д. При этом необходима возможность просмотра полученных результатов перед оформлением и передачей выходной информации. Очень актуальным становится вопрос выбора режима: пакетный или диалоговый.
Пакетный режим позволяет уменьшить вмешательство пользователя в процесс решения задачи и требует от него только выполнения операций по вводу и корректировке данных, но вместе с этим появляется вероятность полной загрузки ЭВМ, что не всегда удобно для пользователя.
Практика показывает, что использование АРМ с применением методов построения модели на основе диалога обеспечивает более гибкую связь пользователя с ЭВМ.
Диалоговый режим имеет ряд преимуществ: удобен при работе с базой; обеспечение защиты при несанкционированном доступе; обеспечивает непосредственное участие пользователя в процессе решения задачи; управляемость процессом; быстрый доступ, поиск и выдача информации в любой момент времени, выбор различных режимов работы; осуществление быстрого перехода от одной операции к другой.
Существует несколько типов диалога: управляющие команды, запросы, меню, диалог на ограниченном естественном языке.
В данной работе будет использоваться метод меню с многоуровневойструктурой.
Под программным обеспечением следует понимать совокупность программ, обеспечивающих функционирование вычислительной системы (системное программное обеспечение), а также программ, предназначенных для решения конкретных задач пользователя (прикладное программное обеспечение).
К выбираемому программному обеспечению в данном случае относятся операционная система (ОС) и среда программирования.
Все ОС подразделяются на:
· однопользовательские и многопользовательские;
· однозадачные и многозадачные.
Обоснование выбора обеспечивающих технологий включает в себя определение программных и аппаратных средств, необходимых для создания комплекса АРМ.
Выбор системы управления базами данных (СУБД) представляет собой сложную многопараметрическую задачу и является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала.
Для сравнения были выбраны три СУБД: InterBase, MySQL и MS SQL Server. Сравнение проводилось по пяти основным параметрам: поддержка СУБД механизма триггеров и хранимых процедур, удобство и доступность средств разработки приложений СУБД, перечень поддерживаемых операционных систем, минимальные требования к серверу баз данных, и производительность.
Триггеры и хранимые процедуры.
Для серьезных информационных систем наиболее распространенной является клиент-серверная архитектура, то есть архитектура, в которой под БД выделяется отдельный, достаточно мощный и надежный сервер, сетевой доступ к которому осуществляют несколько клиентов. Поддержка СУБД механизма триггеров и хранимых процедур позволяет перенести часть вычислительной нагрузки по обработке данных на сервер, несколько снижает сетевой трафик, облегчает модернизацию ПО.
MySQL в отличие от Microsoft SQL Server и InterBase не поддерживает ни триггеры, ни хранимые процедуры, что является в определенной степени недостатком, так как в приложениях информационной системы большую часть необходимых проверок введенных данных, а также обеспечение целостности базы данных приходится выполнять на уровне клиентского приложения, что несколько усложняет процесс создания программного продукта.
Средства разработки приложений СУБД.
Многие производители СУБД выпускают средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера БД, поэтому при анализе СУБД стоит рассмотреть также возможности средств разработки приложений.
В MSSQLServer следует обратить особое внимание на основное средство разработки и администрирования, включенное в состав дистрибутива, – Enterprise Manager, который позволяет решать практически все задачи администрирования MS SQL Server и, кроме того, удобен для разработчика.
В InterBase, к сожалению, средство разработки и администрирования, поставляемое в составе дистрибутива (Interbase Console), недостаточно удобно, но обладает необходимой функциональностью. Поэтому существуют более удобные средства разработки и администрирования, созданные сторонними разработчиками, такие как IB Expert, EMSIBManager.
Похожим образом обстоит дело и со средствами администрирования и разработки MySQL, но при желании также можно воспользоваться продуктами сторонних разработчиков: EMSMySQLManager, WinSQL, PHP Admin.
Перечень операционных систем,
под управлением которых способна работать СУБД. В этом разделе, безусловно, лидирует MySQL, которая способна работать под управлением большинства из имеющихся на настоящее время операционных систем. Список совместимости СУБД и ОС представлен в табл. 1.1.
Таблица 1.1 – Совместимость СУБД и ОС
| СУБД | ОС |
| InterBase | Windows 95/98/ME/NT/2000 и Linux-системы |
| MS SQL Server | Windows NT, 2000, XP (Intel и Alpha) |
| MySQL | Linux (x86, libc6, S/390, IA64, Alpha, Sparc), Windows 95/98/NT/2000/XP, Solaris 2.9 (Sparc, 64-bit, 32-bit), FreeBSD 4.x ELF (x86), Mac OS X v10.2, HP-UX 10.20 (RISC 1.0), HP-UX 11.11 (PA-RISC 1.1 или 2.0), AIX 5.1 (RS6000), QNX 6.2.0 (x86), Novell NetWare 6 (x86), SCO OpenUnix 8.0 (x86), м SGI Irix 6.5, Dec OSF 5.1 (Alpha) |
Минимальные требования к серверу БД представлены в табл. 1.2. Из данной таблицы видно, что наименее требовательна к ресурсам сервера – СУБД InterBase.
Таблица 1.2 – Минимальные требования к серверу БД
| СУБД | Сервер |
| InterBase 7.0 | Pentium 100 MHz, ОЗУ – 32 Мбайт, 50 Мбайт свободного места на диске. |
| MS SQL Server 7.0 | Pentium II 350 MHz, ОЗУ – 128 Мбайт, 250 Мбайт свободного места на диске |
| MySQL 4.0.20 | Pentium 100 MHz, ОЗУ – 64 Мбайт, 100 Мбайт свободного места на диске |
Производительность.
Для сравнительного исследования СУБД после их установки на каждой из них встроенными средствами администрирования создавалась база данных TEST_DB, в которую помещалась одна таблица с именем TEST_TABLE (NUM: INTEGER; FIO_B: CHAR; NUM_CARD: INTEGER; NUM_POLUS: INTEGER; POL: CHAR; AGE_B: INTEGER; BORN_B: INTEGER; ADRESS_H: CHAR; TEL_H: INTEGER; ADRESS_R: CHAR; TEL_R: INTEGER; MED_PLACE: CHAR; VID_POS: CHAR; VID_BOL: CHAR; STATUS: CHAR; LGOTA: CHAR; VID_DOC: CHAR; FIO_DOC: CHAR; TDATE: DATE; VID_MON: INTEGER), содержащая 20 столбцов и 28096 строк записей. Как пример реальной практической задачи в этой таблице находилась информация о выданных больничных листах.
Данные таблицы были сгенерированны случайным образом. В исследовании участвовал компьютер со следующими основными характеристиками: Asus P4S533-MX / P4 2,4 GHz / RAM 256 Mb / HDD 80 Gb.
Для проведения исследования была использована программа SERVERTESTER. В ходе исследования для каждого из тестируемого сервера БД указанная программа по команде пользователя последовательно в течение 1 сессии выполняла все указанные ниже SQL – запросы и замеряла их время выполнения в мсек. Затем сессия повторялась. Количество повторов равнялось 20. Результаты каждого теста программа записывала в журнал работы, который затем был обработан – вычислены среднее значение времени выполнения каждого запроса. При этом на используемом при тестировании компьютере для исследования динамики работы серверов СУБД было запущено программное обеспечение System Monitor, в котором был включен 1 счетчик –% загруженности процессора. Перед началом каждого теста работа счетчика начиналась сначала. После окончания теста фиксировались 2 показателя – средний и максимальный проценты использования процессора, которые затем вручную вносились в журнал работы программы тестирования.
Текст SQL-запросов для тестирования подбирался таким образом, чтобы исследовать эффективность различных механизмов СУБД: безусловный запрос (характеризующий скорость доступа к данным вообще), запрос с простым условием (характеризующий скорость отбора данных по условию), запрос с группировкой и агрегатной функцией (характеризующий эффективность выполнения вычислений). Запросы выполнявшиеся в ходе тестирования приведены в табл. 1.3.
Таблица 1.3– SQL – запросы, выполнявшиеся в ходе тестирования
| № | Название запроса | SQL запрос |
| 1 | Простой Select | SELECT * FROM TEST_TABLE |
| 2 | Выбор больных, которые обращались до 20.01.05 | SELECT FIO_B, NUM_CARD, FROM TEST_TABLE WHERE TDATE<’20.01.05’ |
| 3 | Выбор среднего по возрасту больного, по группам цели посещения | SELECT FIO_BOL, AVG (AGE_B), VID_POS FROM TEST_TABLE GROUP BY VID_POS |
U – количество пользователей, подключенных к СУБД;
P av – средняя загрузка процессора;
P max – максимальная загрузка процессора;
D – длительность выполнения запроса, мсек.
В табл. 1.4–1.6 приведены результаты выполнения тестовых запросов.
Таблица 1.4 – Результаты выполнения запроса №1
| Тест | U=1 | U=2 | U=3 | ||||||
| D | Pav | Pmax | D | P av | P max | D | P av | P max | |
| MySQL | 5450,8 (±66,5) | 14,3 | 46,88 | 5608,2 (±71,8) | 28,8 | 64,3 | 6011,4 (±68,0) | 41,3 | 62,2 |
| MS SQL Server | 5237,2 (±42,0) | 7,5 | 32,8 | 5721,7 (±20,4) | 61,2 | 83,7 | 6387,3 (±54,7) | 91 | 100 |
| InterBase | 6304,3 (±38,3) | 28 | 51 | 6273,4 (±23,2) | 63 | 98 | 6222,9 (±50,9) | 86 | 100 |
Таблица 1.5 – Результаты выполнения запроса №2
| Тест | U=1 | U=2 | U=3 | ||||||
| D | P av | P max | D | P av | P max | D | P av | P max | |
| MySQL | 163,0 (±3,2) | 14,3 | 46,88 | 155,3 (±4,0) | 28,8 | 64,3 | 153,7 (±14,5) | 41,3 | 62,2 |
| MS SQL Server | 153,3 (±10,9) | 30,1 | 92 | 233,9 (±21,7) | 73,5 | 100 | 340,8 (±20,3) | 97 | 100 |
| InterBase | 184,8 (±3,4) | 28 | 51 | 192,8 (±4,0) | 63 | 98 | 201,1 (±5,9) | 86 | 100 |
Таблица 1.6 – Результаты выполнения запроса №3