Методы и средства обработки и хранения информации

Межвузовский сборник  
научных трудов

Под редакцией Б.В. Кострова

КУРС
Москва
2015

Методы и средства
обработки и хранениЯ

инФорМаЦии

удк 004.62
ббк 32.973

М54

©
Рязанский государственный 
радиотехнический университет, 2015

М54
Методы и средства обработки и хранения информации : межвузовский 
сборник научных трудов / Под ред. Б.В. Кострова. — М.: КУРС, 2015. — 
224 с.

ISBN 978-5-906818-26-3 (КУРС)

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

УДК 004.62
ББК 32.973

ISBN 978-5-906818-26-3 (КУРС)

Р е ц е н з е н т :
Б.В. Новоселов — д-р техн. наук, проф., засл. деятель науки РФ, засл. конструктор РФ, засл. 
изобретатель РСФСР, главный научный сотрудник АО «ВНИИ «Сигнал»

Р е д а к ц и о н н а я  к о л л е г и я :
Б.В. Костров 
— д-р техн. наук, проф., зав. кафедрой ЭВМ РГРТУ (Рязань) (ответственный 
редактор);
М.Б. Никифоров — канд. техн. наук, доц., зам. зав. кафедрой ЭВМ по НР РГРТУ (Рязань) (зам. 
ответственного редактора);
М.В. Новиков
— канд. техн. наук, главный конструктор бортовых информацион-ных комплексов ОАО «Корпорация «ВНИИЭМ» (Москва) (зам. ответственно-го 
редактора);
А.И. Баранчиков — д-р техн. наук, проф. кафедры ЭВМ РГРТУ (Рязань);
В.В. Сюзев
— д-р техн. наук, проф., директор НИИ СУ МГТУ им. Н.Э. Баумана (Москва); 
В.Н. Ланцов
— д-р техн. наук, проф., зав. кафедрой ВТ ВлГУ (Владимир);
Е.В. Ларкин
— д-р техн. наук, проф., зав. кафедрой РиАП ТулГУ (Тула);
К.Р. Таранцева
— д-р техн. наук, проф., проректор по НР ПензГТУ (Пенза);
И.И. Сальников — д-р техн. наук, проф., зав. кафедрой ВМиС ПензГТУ (Пенза);
А.Н. Пылькин
— д-р техн. наук, проф., зав. кафедрой ВПМ РГРТУ (Рязань);
В.П. Корячко
— д-р техн. наук, проф., зав. кафедрой САПР ВС (Рязань);
В.Н. Ручкин
— д-р техн. наук, проф., профессор кафедры ИиВТ РГУ (Рязань);
В.В. Нечаев
— канд. техн. наук, проф., зав. кафедрой ИТиС МГТУ МИРЭА (Москва);
Л.М. Шарнин
— д-р техн. наук, проф., зав. кафедрой АСОИиУ КАИ им. А.Н. Туполева 
(Казань);
А.И. Ефимов
— ответственный секретарь (Рязань)

Методы и средства обработки и хранения информации, 2015 

 
ВВЕДЕНИЕ 
 
Межвузовский сборник научных трудов содержит результаты 
научных исследований и разработок по следующим направлениям: 
– методы и алгоритмы обработки изображений и распознавания 
образов; 
– организация геоинформационных систем на основе аэрокосмической съемки; 
– программное обеспечение вычислительных машин, комплексов, систем и сетей; 
– программно-аппаратное обеспечение средств вычислительной 
техники, систем передачи информации и компьютерных сетей; 
– математическое обеспечение и администрирование информационных систем; 
– теория проектирования и организация баз данных и знаний, 
системы искусственного интеллекта. 
Сборник сформирован на основе статей, в которых рассматриваются различные аспекты цифровой обработки и распознавания изображений, в том числе аэрокосмических, а также вопросы, связанные с 
программным, аппаратным и математическим обеспечением работы 
информационных систем и систем искусственного интеллекта, математическим моделированием. Сборник предназначен для студентов, 
магистрантов, аспирантов, преподавателей технических вузов и научных работников. 
Материалы для сборника предоставлены студентами и сотрудниками: 
– Владимирского государственного университета им. А.Г. и Н.Г. 
Столетовых; 
– Казанского национального исследовательского технического 
университета имени А.Н.Туполева (КАИ); 
– Московского государственного технического университета 
им. Н.Э. Баумана. 
– Рязанского государственного радиотехнического университета 
(РГРТУ);  
 

Межвузовский сборник научных трудов 

 
УДК 004.658.2 
Д.В. Аникеев, С.В. Аникеев, А.В. Маркин 
D.V. Anikeev, S.V. Anikeev, A.V. Markin 
МЕТОДЫ СОКРАЩЕНИЯ ВРЕМЕНИ ВЫПОЛНЕНИЯ 
CRUD-ОПЕРАЦИЙ В РЕЛЯЦИОННЫХ БАЗАХ 
ДАННЫХ 
METHODS OF REDUCING CRUD-OPERATIONS 
RUNTIME IN RELATIONAL DATABASES 

Рязанский государственный радиотехнический университет 
Описаны способы и методы повышения качества базы данных 
за счет уменьшения  времени выполнения CRUD-операций. 
This article describes the ways and methods of improving the database quality by reducing CRUD-Operations runtime. 
Одним из критериев качества базы данных (БД) является время 
выполнения CRUD-операций БД [1]. Под CRUD-операцией понимают 
операции создания (Create), чтения (Read), обновления (Update) и удаления (Delete) записей в таблице БД [2]. CRUD-операции напрямую (в 
отличие, например, от операций резервного копирования) влияют на 
время отклика информационных систем (ИС), использующих БД. 
В зависимости от способа распространения ИС БД могут располагаться: 
- на сервере разработчика ИС; 
- на серверах конечных пользователей ИС. 
При этом в обоих случаях помимо БД, используемой в основной 
версии ИС, обычно также существуют БД, используемые для тестирования ИС. 
Особенность 
оптимизации 
времени 
выполнения 
CRUDопераций заключается в его зависимости от структуры (схемы) БД, от 
данных, хранящихся в БД, и от ее месторасположения [3]. Известными 
способами повышения качества реляционных БД являются следующие. 
1. Индексирование 
Наиболее распространенным способом сокращения времени 
выполнения CRUD-операций является индексирование. Индекс представляет собой упорядоченную последовательность значений одного 
или нескольких столбцов таблицы. Различают кластеризованные и 
некластеризованные индексы [4]. 

Методы и средства обработки и хранения информации, 2015 
5 

 
Кластеризованный индекс включает в себя все столбцы таблицы, упорядоченные, как правило, по значению столбцов, содержащих 
первичный ключ таблицы [3]. В связи с этим поиск по кластеризованному индексу выполняется за один этап (сразу возвращаются необходимые данные) 
Некластеризованный индекс представляет собой отдельную 
таблицу, содержащую значения столбцов, входящих в некластеризованный индекс, плюс значения столбцов, по которым создан кластеризованный индекс [3]. В общем случае поиск по некластеризованному 
индексу происходит в два этапа. На первом этапе согласно критерию 
отбора находится значение столбцов, входящих в кластеризованный 
индекс, а на втором - поиск по кластеризованному индексу. В случае 
если запрос предполагает возвращение только значений, входящих в 
некластеризованный индекс, то поиск будет выполняться в один этап. 
Некоторые системы управления базами данных (СУБД) имеют 
третий тип индексов: покрывающие. Покрывающий индекс представляет собой некластеризованный индекс, расширенный дополнительными столбцами. В покрывающем индексе сортировка столбцов индекса осуществляется по основным столбцам, входящим в индекс, а 
таблица индексации хранит в себе также значения дополнительных 
столбцов, что позволяет производить одноэтапный поиск. 
Существует также четвертый тип индекса — полнотекстовой [5, 
6]. Полнотекстовой индекс, в отличие от обычных индексов, включает 
в себя не полное предложение, но его составные элементы — отдельные слова. Полнотекстовой индекс используется для поиска документов по ключевым словам. 
Индекс на столбец добавляется: 
- при частой фильтрации по столбцу; 
- при использовании столбца в конструкции JOIN; 
- при использовании столбца в качестве внешнего ключа; 
- при использовании столбца в агрегатных функциях; 
- при высокой селективности (0 — 5 % повторяющихся значений в индексируемом столбце); 
- при использовании столбца в сортировке (конструкция 
ORDER BY) [2, 3, 7, 8]. 
Выявить столбцы, на которые следует добавить индекс, позволяет анализ плана запросов [4]. План запросов отличается в различных 
СУБД, поэтому методики выявления вышеуказанных столбцов, на которые следует добавить индекс, для каждой СУБД также различаются. 

Межвузовский сборник научных трудов 

 
Все типы индексов повышают скорость доступа к данным (операция Read), но при этом увеличивают объем БД на физическом носителе и снижают скорость выполнения трех других операций — Create, 
Update, Delete. В связи с этим существуют следующие общие правила 
оптимизации: 
- в OLTP-системах (Online Transaction Processing), которые 
предполагают активное добавление данных, рекомендуется иметь небольшое количество индексов на одну таблицу [3]; 
- в аналитических OLTA (Online Transaction Analytical)- и OLAP 
(Online Analytical Processing)-системах индексами покрывается большее количество столбцов [3]; 
- при вставке большого объема данных (от миллиона и выше) 
желательно отключать индексы [8]. 
Еще одной особенностью индексов является их подверженность 
фрагментации, наиболее ярко выраженная в OLTP системах с частым 
удалением/обновлением данных [3]. В связи с этим для успешной работы с индексами рекомендуется периодически удалять и вновь создавать их. 
2. Оптимизация запросов к БД 
Вторым способом является оптимизация текста запросов к БД. 
Этот способ имеет две особенности: 
- в некоторых случаях увеличивается сложность восприятия запроса разработчиком, что в свою очередь усложняет сопровождение 
запроса; 
- оптимизация на одном сервере при одном наборе данных может привести к увеличению времени работы запросов на другом сервере и других наборах данных. 
Существуют следующие общие рекомендации к оптимизации 
запросов. 
2.1. В конструкции «select» следует возвращать только необходимые данные. Использование конструкции «select *» приводит к увеличению времени поиска данных и нагрузки на каналы передачи данных. Кроме того если СУБД поддерживает покрывающие индексы, то 
возврат значений всех столбцов может привести к неэффективному 
использованию существующих в БД индексов [3, 7, 8]. 
2.2. Использование объединения (JOIN) вместо связанных вложенных запросов. Объединение таблиц выполняется один раз по всему 
массиву данных. Связанные вложенные запросы в свою очередь выполняются построчно. При этом повышение производительности дает 

Методы и средства обработки и хранения информации, 2015 
7 

 
даже использование представлений или таблиц, созданных с помощью 
конструкции «with» [2, 7, 8]. 
2.3. В случае сложных запросов промежуточные данные целесообразно хранить во временных таблицах. Во многих современных 
СУБД существует возможность работы с временными таблицами. 
Временной таблицей называют такую таблицу БД, данные в которой 
хранятся в течение одной транзакции. Концепция временных таблиц в 
различных СУБД реализована по-разному. В некоторых СУБД (например, MS SQL) временные таблицы хранятся в рамках одной транзакции, в других (например, Firebird) такие таблицы доступны на 
уровне всей БД. Преимущество временных таблиц перед стандартной 
SQL-конструкцией «with» в первую очередь заключается в возможности добавления индексов [8]. 
2.4. Проверку существования записи следует делать с использованием конструкции «exists» вместо конструкции «count > 0». Первая 
конструкция прерывает выполнение запроса в случае, если найдена 
хотя бы одна запись, в то время как вторая сначала подсчитывает количество всех записей и только после этого возвращает результат [3, 
8]. Помимо «exists» многие СУБД имеют и другие подобные конструкции. Так, в Firebird есть «any» (возвращает true, если хотя бы для 
одной записи выполняется условие), «all» (возвращает true, если для 
всех записей выполняется условие), «singular» (возвращает true, если 
условию соответствует ровно одна запись) [9]. 
2.5. Несколько конструкций «insert» и «update» рекомендуется 
заменять одной. В этом случае СУБД произведет вставку/обновление 
данных за один проход целевой таблицы в силу того, что поиск будет 
выполняться лишь один раз [8]. 
2.6. Не следует при обновлении менять значение в столбце на 
аналогичное ему. При замене значения в столбце затрачивается время 
как на непосредственную замену значения, так и на обновление индексов. В данном случае сравнение значения является менее дорогой операцией [5]. 
2.7. Следует избегать объединения таблиц по столбцам, 
имеющим различный тип данных. Помимо того, что приведение типа 
само по себе требует процессорного времени, оно также приводит к 
неэффективному использованию индексов [3]. 
2.8. Для выборки данных предпочтительнее использовать декларативный запрос (SQL) вместо процедурного (PSQL). Использование декларативного запроса позволяет СУБД произвести наиболее оптимальную выборку в соответствии с текущими настройками сервера и 

Межвузовский сборник научных трудов 

 
данными в БД [3]. Данная рекомендация распространяется и на программный код приложения, работающий с БД. 
2.9. Использование конструкции «union» предпочтительнее, чем 
использование «or» в случае, если выборка осуществляется по различным проиндексированным столбцам одной таблицы. Другими словами, конструкцию 
SELECT * FROM t WHERE f1 OR f2, 
где f1 и f2 – условие отбора по некоторым проиндексированным 
столбцам F1 и F2, рекомендуется заменить, где это возможно, конструкцией 
SELECT * FROM t WHERE f1 
UNION ALL 
SELECT * FROM t WHERE f2. 
В этом случае «union» позволяет задействовать оба индекса, тогда как 
«or» - всего один из них [3, 10]. 
2.10. Обращение к пользовательским функциям (UDF). Обращение к UDF в любых СУБД — дорогостоящая операция и ее следует 
избегать[3]. 
Вне зависимости от применяемых способов оптимизации запросов в первую очередь следует проводить изменение наиболее медленных из них. Для их выявления можно воспользоваться программойпрофилировщиком. Для каждой СУБД существуют свои собственные 
профилировщики. 
3. Использование триггеров 
Вызов и выполнение триггера также могут стать причиной 
ухудшения производительности работы с БД при выполнении модифицирующих операций Create, Update, Delete [3]. При этом в некоторых случаях (при расчете сложных значений) триггеры увеличивают 
производительность операций на чтение. Зачастую триггеры используются для поддержания целостности таблиц БД либо для расчета значений в отдельных столбцах. При этом современные СУБД имеют альтернативные средства  поддержания целостности и работы с вычисляемыми столбцами. Преимущество стандартных способов заключается в том, что СУБД обладает информацией о конфигурации сервера и 
данных в БД. 
4. Разделение таблиц и репликация 
Оптимизация высоконагруженных БД может производиться путем разделения одной таблицы на несколько. Существует два способа 
разбиения: горизонтальное и вертикальное. 

Методы и средства обработки и хранения информации, 2015 
9 

 
При вертикальном разделении таблиц отдельные столбцы таблицы выносятся в новые таблицы. Как правило, выносятся редко требующиеся данные больших размеров (например, blob-столбцы), после 
чего в приложении реализуется ленивое чтение этих данных: обращение к вынесенным столбцам производится в случае непосредственной 
необходимости [3]. 
При горизонтальном разделении создается несколько одинаковых по структуре таблиц, в каждой из которых хранится некоторый 
заранее определенный диапазон значений. Оптимизация при горизонтальном разделении достигается за счет того факта, что поиск по таблице с небольшим количеством записей выполняется быстрее [3]. 
Репликация позволяет распределить нагрузку на СУБД между 
различными серверами. При репликации главный сервер (мастер) 
транслирует зависимым (репликам) происходящие на нем изменения 
[11]. Репликация в первую очередь позволяет повысить скорость чтения данных за счет дублирования на нескольких репликах. 
Разделение таблиц, как и репликация, позволяет улучшить производительность всех четырех типов операций, однако усложняет сопровождение БД (особенно при разделении таблиц) и администрирование (во втором случае). 
5. Нормализация и денормализация 
С понятием реляционной БД неразрывно связано понятие нормализации. В нормализованных БД исключается избыточность данных, что приводит, с одной стороны, к оптимальному хранению данных и их непротиворечивости, а с другой — увеличивает время обработки информации в связи с необходимостью поиска данных в связанных таблицах [4]. 
Таким образом, нормализованные БД в силу отсутствия избыточности целесообразно использовать в OLTP-системах, в то время как 
денормализованные — в OLTA-системах [4]. 
В общем же случае разработчик БД обычно вынужден балансировать между нормализацией и денормализацией, делая выбор в пользу первой при частом изменении данных и в пользу второй при большом количестве запросов на чтение [3]. 
6. Типы данных и дефрагментация БД 
Фрагментации в БД подвержены не только индексы, но и сама 
БД в целом. Аналогично индексам для борьбы с фрагментацией используется техника пересоздания БД [6]. 
Конкретные шаги дефрагментации различны в различных 
СУБД. Так, дефрагментация в СУБД MySQL производится для от

Межвузовский сборник научных трудов 

 
дельных таблиц командой «optimize»[12], в СУБД Firebird путем бекапа и восстановления БД [13]. 
По возможности следует использовать типы данных фиксированной длины минимально возможного размера [7]. Данная рекомендация связана с тем, что, во-первых, типы данных фиксированной 
длины позволяют СУБД заранее рассчитать положение данных на диске, а во-вторых, чем меньше места занимают данные в БД, тем быстрее 
СУБД осуществляет поиск данных. 
7. Кэширование запросов 
Результаты часто выполняющихся запросов на выборку данных 
можно сохранять в оперативной памяти как средствами СУБД, так и 
непосредственно в клиентском приложении [6]. 
При кэшировании запросов для каждой системы в отдельности 
приходится ответить на два вопроса: что кэшировать и как обеспечить 
актуальность данных. На первый вопрос можно ответить, воспользовавшись данными профилировщика, в то время как вторая проблема 
зависит от характера предметной области и плохо формализована. 
Кэширование помогает при большом количестве запросов на 
чтение однотипных данных. 
8. Блокировки. Под блокировками понимается блокирование 
выполнения одной транзакции при выполнении второй транзакции. В 
одних случаях блокируемая транзакция возобновляет свою работу после завершения работы блокирующей транзакции, в других происходит взаимная блокировка (deadlock) и одна из транзакций уничтожается, а внесенные ею незафиксированные изменения откатываются [14]. 
Для того чтобы уменьшить вероятность возникновения блокировок, можно воспользоваться следующими рекомендациями: 
- доступ к таблицам следует организовывать в одинаковом порядке; 
- время существования транзакции должно быть как можно более коротким; 
- никогда не следует ждать ввода данных пользователем в открытой транзакции [3]. 
Влияние вышеописанных методов на каждую из CRUDопераций представлено в сводной таблице. 
В таблице «-» означает увеличение времени выполнения операции, «+» - сокращение времени выполнения операции, «0» - несущественное изменение времени выполнения операции.