Поиск записей

Утверждение 3.2 Для поиска k записей, произвольным образом расположенных в файле,

Одно из оптимальных решений достигается, когда p = r, т.е. все записи в одном блоке. Количество записей p не может превышать размеров физического блока. Это используется при оптимизации запроса.

3.2.3 Индексно-произвольный метод доступа

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

Идеологию этих методов рассмотрим на примере индексно-произвольного метода доступа; то есть, рассмотрим даже не метод доступа, а идеологию.

Файловая структура для индексно-произвольного метода доступа:

Ключ 1 Ключ 2

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

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

Пример. В DBF-файлах «Контрольная сумма» такова: если она содержит пробел, то запись актуальна, если «*» (символ звездочка) — запись стерта. Идентификатора конца нет, все записи имеют одинаковую длину. Поэтому наш способ более общий, чем пример.

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

Поиск в индексном файле. Метод 1. Блочный поиск

Пусть индексный файл содержит N записей. Выбирая число записей n, который будем считать блоком («условный блок»). При поиске записей искомое значение сначала сравнивается с первой записью исходного блока, далее сравнивается со значением ключа первой записи второго блока, и так далее.

Если при i-ом сравнении искомое значение меньше текущего, то искомая запись находится в i −1-ом блоке. Последовательно просматриваем этот блок, начиная со второй записи (первую уже просмотрели).

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

Метод 2. Бинарный поиск

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

Результаты: Оптимальный размер блока n = N2 , длина поиска log2 N.

Если известна функция распределения первичного ключа (например, для словарей), то вычисляется не середина интервала, а математическое ожидание местоположения исходной записи. При этом теоретическая длина поиска равняется log2(log2 N), то есть скорость поиска

выше.

√

Замечание. Теоретически, бинарный поиск быстрее блочного ( 2N > log2 N), однако, при бинарном поиске выполняется неупорядоченное перемещение механических частей устройства ввода-вывода, что существенно его замедляет. Блочный поиск не обладает таким недостатком, в нем все идет по порядку. Поэтому для файлов небольшого размера он работает быстрее бинарного. СУБД должна определить момент, когда необходимо переключиться с бинарного поиска на блочный.

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

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

Удаление записи. Ищем по значению ключа запись индексного файла и по ссылке — запись основного файла. В записи основного файла затираем контрольную сумму (в DBF пишется «*»). То есть, удаление происходит «на лету».

Модификация записи. Если не изменяется значение ключа, то выполняется попытка поместить новую запись на старое место; в противном случае на старом месте затирается контрольная сумма, новая запись помещается в конец файла со сменой указателя в индексном файле.

Если же значение ключа меняется, то процедура сводится к удалению старой записи и добавлению новой.

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

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

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

Для внешних устройств существуют свои алгоритмы сортировки, они гораздо более быстрые и эффективные.

Резюме. Очень надежный способ, при сбое все незатертые записи будут без проблем восстановлены, а о возникшем сбое будет сообщено оператору.

3.2.4 Прямой метод доступа

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

Для вычисления адреса записи необходимо, чтобы они имели фиксированную длину.

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

Основной недостаток данного метода доступа состоит в следующем. Допустим, первичный ключ — символьное выражение длины 20 из латинского алфавита. Тогда для файла нужно будет зарезервировать пространство 2620 записей, т.е. получим практически пустой файл огромного размера.

3.2.5 Методы хеширования

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

Обозначим функцию хеширования следующим образом: ϕ(k) = A , где k — значение ключа, A — адрес записи.

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

Определение 3.2 Ключи k1 и k2 называются синонимами относительно функции ϕ, если

ϕ(k1) = ϕ(k2).

Замечание. Хорошая функция хеширования должна давать наименьшее количество синонимов.

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

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

Каким должен быть масштабирующий множитель?

Если m = 10, то в файле будет занята каждая десятая запись, а остальные — нет.

Если m ≈ 0.1, то после округления в среднем 10 записей будут иметь один и тот же адрес. Значит, должно быть m = 1. Достижимо ли это значение? Мы ведь выбираем целое количество срединных разрядов (битов). Сколько их надо выбирать? Выбираем столько, чтобы m

был близок к единице снизу (т.е. m ≤ 1).

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