Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Пособие часть1.doc
Скачиваний:
22
Добавлен:
01.03.2025
Размер:
6.94 Mб
Скачать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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