Структура каталога | Участники сборника 2005 г. | Участники сборника 2004 г.
 
ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ОРГАНИЗАЦИЯ ДОСТУПА К НИМ  
  Акаевич Вадим Владимирович,
старший инженер-инспектор ОСиА ОССиА МВД Карачаево-Черкесской Республики, капитан милиции
 
Часть 2. Другие статьи

Некоторые аспекты построения системы связи МВД Республики Бурятия

Проектирование баз данных и организация доступа к ним

История создания и развития службы связи МВД Республики Коми

Развитие службы связи МВД Республики татарстан

Организация мультисервисных телекоммуникационных сетей на базе систем спутниковой связи

Развитие службы связи УВД Белгородской области

В борьбе с автоугонщиками

Оперативность во всем!

Система обеспечения безопас-ности города (СОБГ): аппаратные и программные средства

Технологии D-Link на страже правопорядка

Развитие службы связи ГУВД Нижегородской области

Развитие службы связи УВД Омской области

Организация документированной связи на базе телеграфного комплекса

Совершенствование радиосвязи - основа нашей работы

Опыт эксплуатации DSL-модемов "Зелакс"

Современное состояние и перспективы развития системы связи УВД Тамбовской области

Отделение связи, спецтехники и автоматизации Приволжского УВД на транспорте на страже магистралей
Введение

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

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

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

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

Задачами хранения, управления, построения и перестроения логических связей в таблицах и между ними, их взаимодействия и обслуживания занимаются специальные системы управления базами данных (СУБД).
Наиболее популярными СУБД, получившими широкое распространение в мире, являются: 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 Мбайт/с) такой метод является избыточным и практически нерентабельным.

Заключение
Применение вышеописанных методов (как при проектировании БД, так и при реализации конечных клиент-серверских приложений для выполнения запросов в централизованный банк информации) получило широкое распространение в объединенной ЛВС подразделений и служб МВД Карачаево-Черкесской Республики на территории республиканского центра. В настоящее время в пределах этой сети успешно эксплуатируются программные комплексы: "Разыскиваемый транспорт", "Зарегистрированный транспорт", "Лицо", "Оружие", "Документы".
ООО "ИНФОРМАЦИОННЫЙ МОСТ"
117133, Москва, ул. Халтуринская, д. 6А
Тел./факс: (095) 160-9992, 160-9892