Шаблон страниц

Введение

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

Наиболее оптимальным методом получения информации является выполнение запросов в удаленные БД в режиме реального времени (метод прямых запросов). Однако на практике применение такого метода не всегда выполнимо из-за низкой пропускной способности канала связи и неустойчивости соединений либо из-за специфики БД. Поэтому вопросы организации доступа к БД имеют столь большое значение и являются наиболее проблемными.

БД и их характеристики. СУБД
Классическое понятие "база данных" несколько абстрактно и требует некоторой детализации.

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

Задачами хранения, управления, построения и перестроения логических связей в таблицах и между ними, их взаимодействия и обслуживания занимаются специальные системы управления базами данных (СУБД).
Наиболее популярными СУБД, получившими широкое распространение в мире, являются: Paradox, dBase, Fox Pro, Access, Inter Base, My SQL, Microsoft SQL Server, Oracle и многие другие. Все перечисленные СУБД имеют индивидуальные особенности, различаются уровнем сложности, интерфейсом, степенью защиты от несанкционированного доступа, надежностью, производительностью, функциональными возможностями и т. п. Например, наиболее простыми СУБД являются dBase, Fox Pro, Paradox; более производительной - Microsoft SQL; более защищенной - Oracle.

Наиболее важными характеристиками СУБД являются: предельный объем базы данных, предельное число записей в таблицах, предельное значение объема информации одного поля таблицы, производительность. Существуют и другие характеристики СУБД, например возможность шифрования информации, разрядность ключа шифра, поддержка DTFS (распределенной файловой системы), наличие программного обеспечения (ПО) управления БД и т. д.

При проектировании БД и выборе СУБД необходимо учитывать их особенности, возможности развития и технической поддержки, условия совместного использования, возможность удаленного выполнения запросов (в рамках технического задания), взаимосвязь с другими БД и формат.

Для решения частных задач и проектирования локальной БД небольшого объема (до 100 Мбайт) можно остановить свой выбор на СУБД dBase, Fox Pro, Paradox, Access. Однако для сетевого использования эти системы слишком ненадежны и неустойчивы, а при отсутствии высокоскоростных каналов доступа (от 10 Мбайт/с) их сетевое или совместное применение невозможно.

Использование передовых СУБД (таких как Oracle, Mirosoft SQL) обеспечивает высокую надежность, стабильность и производительность системы в целом. Эти СУБД позволяют проектировать и успешно эксплуатировать огромные БД объемом до 2 Тбайт. Недостатком таких СУБД является их большой объем, значительное потребление ресурсов компьютера, а также то, что обслуживать их могут только высококвалифицированные специалисты. Поэтому эти системы, как правило, используются в сетевой среде и устанавливаются на наиболее мощные серверы локальных вычислительных сетей (ЛВС). Этот недостаток частично устранен в СУБД Microsoft SQL выпуском MSDE и My SQL, которые представляют собой "настольную" и "упрощенную" версии системы. Совместимость и интеграция (средства управления интегрируются в MMС) с операционными системами Windows (особенно на основе технологии NT) привели к росту популярности этих СУБД в мире.

Влияние выбора СУБД при проектировании БД на производительность системы приведено в тестовых таблицах 1, 2.

Таблица 1 Характеристики БД
Наименование показателей	Oracle	Microsoft SQL	MS Access	Fox Pro	dBase IV
Число записей в таблице	1 000 000	1 000 000	1 000 000	1 000 000	1 000 000
Число полей	20	20	20	20	20
Численность индексных полей	6	6	6	6	6
Размер таблицы, Мбайт (включая индексы)	725	295	420	348	352
Наличие уникальных полей	1	1	1	1	1
Возможность сжатия	нет	нет	нет	да	да

В качестве конструкции для проведения тестов была использована часть федеральной базы данных по розыску автомототранспорта с количеством 1 000 000 записей. В тестах использовались: сервер БД с конфигурацией 4xPIV/4 Гбайт DDR 2100/RAID 5 6x18,7 Гбайт Ultra SCSI/SVGA/Lan 10/100 Мбайт/с; установленная операционная система Windows 2000 Server (Standard Edition) SP4; СУБД Microsoft SQL Server Standard Edition, Oracle 9i, Microsoft Access 97, dBase IV, Fox Pro. В качестве клиентской станции использовалась ПЭВМ в составе: AMD 2200/256 Мбайт DDR 3200/80 Гбайт ATA 100/SVGA/Lan 10/100 Мбайт/с. Для тестов удаленного доступа использованы модемы US Robotics Courier 56000 (скорость соединений 33600 Байт/с со сжатием в канале).

Таблица 2 Производительность поисковой системы
Наименование показателей	Oracle		Microsoft SQL		MS Access		Fox Pro		dBase IV
Наименование показателей	Lan	Dial-Up	Lan	Dial- Up	Lan	Dial-Up	Lan	Dial-Up	Lan	Dial-Up
Время доступа к таблице, с	0,05	1,2	0,03	0,8	4,4	-*	3,2	-	3,8	-
Время поиска по индексному полю, с	0,03	0,03	0,01	0,02	1,9	-	8,8	-	12,1	-
Время поиска по полю (без индекса), с	2,2	2,2	1,8	1,9	24	-	138	-	149	-
Время загрузки результата поиска (100 записей), с	0,8	16,4	0,7	14,2	1,2	-	1,4	-	1,6	-
Время неуточненного поиска (с результатом 100 карточек), с	4,6	4,8	2,4	2,8	28,0	-	162	-	198	-
Время совместного поиска (3 поля с результатом 100 карточек), с	1,4	1,8	1,1	1,2	18	-	36	-	48	-
* - при проведении тестов с использованием соединения Dial-Up с выставлением максимального времени ожидания ответа 300 с отклик не получен и время ожидания превышено.

Использование объектно-ориентированного программирования для разработки приложений работы с БД

Наиболее популярными средами разработки приложений для ОС Windows являются Delphi и СИ.
В данной статье рассматриваются вопросы разработки клиент-серверских приложений в среде Delphi.

Архитектура доступа к БД

Программисты, создавшие Delphi, предлагают элегантное решение, которое позволяет в рамках открытой архитектуры доступа реализовать различные способы работы с данными. Подключение к БД происходит посредством Borland Database Engine (BDE - процессор доступа к базам данных), Microsoft Active Data Objects (ADO), Open Database Connectivity (ODBC) или Flat file (двумерных файлов). Таким образом, разработчик может использовать как "родные" драйвера и компоненты, поставляемые Inprise (Borland), так и программные продукты сторонних разработчиков.

Использование BDE значительно упрощает организацию подключения к БД, а также построение запросов (упрощен механизм преобразования типов данных). Однако имеются и существенные недостатки:
• обязательная установка на всех станциях-клиентах BDE (не менее 14 Мбайт);
• необходимость слежения за установкой и использованием версий BDE.

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

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

Архитектура доступа к БД может быть одно-, двух- и многозвенной. Необходимо отметить, что при двухзвенной архитектуре бизнес-правила могут реализовываться как на стороне клиента, так и на стороне сервера. При многозвенной архитектуре (многозвенные приложения для работы с БД) бизнес-правила выносятся на Application Server или сервер приложений. На стороне клиента и сервера расположены компоненты, которые обеспечивают удаленную связь между ними. Для этой цели могут служить протоколы TCP/IP, HTTP, DCOM, MTS, CORBA. Основное достоинство многозвенной архитектуры - возможность создания приложений, не зависящих от типа базы данных. Вся логика работы выносится на сервер приложений, а сервер БД занимается только хранением и обслуживанием информации.

На практике наибольшее распространение получили клиент-серверские приложения, выполненные по двухзвенной архитектуре (их основные достоинства - простота и возможность размещения бизнес-правил на стороне сервера). Модификация бизнес-правил на стороне сервера окажет влияние на всех клиентов, но не потребует изменения интерфейсов взаимодействия; кроме того, возможна работа клиентских частей различных версий. Балансировка нагрузки между клиентом и сервером для обеспечения максимальной производительности может проводиться путем изменения бизнес-правил как на стороне клиента (application), так и на стороне сервера. Эффективность такой структуры ощутима при реализации приложений, в которых необходимо реализовать связи с несколькими территориально удаленными БД.

Компоненты интерфейса базы данных

Необходимость использования тех или иных компонентов интерфейса базы данных определяется конкретным разработчиком (программистом) в зависимости от его характера, опыта работы с БД и т. п. Это все равно что написать сочинение - важен результат, а не способ реализации (описание). Однако выбор компонентов - немаловажная задача, ведь каждый из них имеет свои особенности и, соответственно, работает по-разному. Поэтому при использовании различных наборов компонентов время реализации задачи с получением одного и того же результата может быть различным.

При использовании компонентов из палитры Data Controls и Standard выявлено, что последние более эффективны в плане обеспечения максимальной производительности, хотя их адаптация для работы с БД требует значительных навыков в программировании и написания довольно простого, но объемного программного кода. Компоненты из палитры Standard не имеют прямых связей с БД и соединяются с ней только посредством бизнес-правил клиентского приложения. Эту важную особенность можно определить как "многослойность" реализации клиентского приложения.

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

Влияние на производительность приложения оказывает и выбор компонентов для реализации архитектуры организации доступа (из палитры ADO либо BDE соответственно при использовании BDE или ADO). Например, использование компонента Table на 30 % менее производительно, чем компонента Query, а использование компонента Stored Procedure (хранимая процедура) эффективнее Query еще на 20 %.

Концепция локализации массивов справочной информации

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

Концепция локализации реальных массивов справочной информации из базы данных заключается в их замене на локальные копии, создаваемые при первой загрузке ПО и существующие независимо от наличия соединения с БД. Такие массивы могут быть временными или постоянными в зависимости от поставленной задачи, могут существовать только в оперативной памяти или сбрасываться на "жесткий" диск. Таким образом, концепция локализации массивов справочной информации позволяет практически избавиться от связи с БД при реальном отсутствии запросов и устанавливать таковую при их наличии. Указанная концепция применима для разработки клиентских частей приложений при использовании их в условиях низкоскоростных каналов связи либо в условиях нестабильной связи.

При разработке клиент-серверских приложений для использования в ЛВС с достаточно большими каналами связи (от 10 Мбайт/с) такой метод является избыточным и практически нерентабельным.

Заключение
Применение вышеописанных методов (как при проектировании БД, так и при реализации конечных клиент-серверских приложений для выполнения запросов в централизованный банк информации) получило широкое распространение в объединенной ЛВС подразделений и служб МВД Карачаево-Черкесской Республики на территории республиканского центра. В настоящее время в пределах этой сети успешно эксплуатируются программные комплексы: "Разыскиваемый транспорт", "Зарегистрированный транспорт", "Лицо", "Оружие", "Документы".