5. Структуры и алгоритмы для поиска данных

5.1. Общие сведения

5.1.1. Постановка задачи поиска

Слово «поиск» имеет очень широкое толкование, поэтому, прежде чем переходить к материалу данной главы, поясним суть задачи.

Пусть имеется совокупность данных, состоящая из отдельных элементов, каждый из которых представляет собой запись из нескольких полей. Одно из полей выделим в качестве ключа для поиска, остальные поля образуют связанную с ключом информацию (точно так же, как в задаче сортировки — key и satellite data). При этом в одной записи вместе с ключом может храниться либо реальная информация, либо ссылка на другую запись, где хранится эта информация. Последняя ситуация является стандартной в базах данных, где поиск обычно ведется по нескольким различным ключам и по каждому из них создается своя структура для поиска (а реальная информация вообще хранится в другом месте).

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

Ситуация, когда искомого значения найти не удалось, называется промахом, в противном случае говорят об успешном поиске (попадании). При анализе алгоритмов поиска обычно случаи промаха и попадания рассматриваются отдельно.

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

• найти первую попавшуюся запись;

• найти все записи.

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

Перечислим ряд дополнительных соображений, которые также входят в постановку задачи.

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

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

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

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

Можно сформулировать этот вывод и так — фактически задача поиска сводится к реализации абстрактного типа данных, который поддерживает эти три базовых операции. В литературе встречается два различных названия для такого АТД — таблица [7, 13] и словарь [3]. Название и формальная функциональная спецификация в данном случае не имеют принципиального значения, поскольку постановка задачи уже понятна, а формальные соглашения по реализации функций мы приведем чуть ниже. Сосредоточим внимание на анализе структур данных для поддержки поиска.