7.3. Процедура индексирования и хеширования

Для того чтобы детальнее разобраться с индексами, рассмот­рим в качестве примера таблицу с данными об оценках и запрос на поиск студентов, сдававших тот или иной учебный предмет. При таких условиях в БД можно выбрать способ хранения дан­ных, схематически показанный на рис. 7.1.

Он основан на двух хранимых файлах: файле с данными об успеваемости студентов USP и файле с данными об учебных предметах. Эти файлы могут размещаться в различных наборах страниц, при этом предполагается, что в файле предметов ис­пользуется упорядочение по алфавитному перечню их названий.

Рис. 7.1. Индексирование файла оценок по полю PN

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

- найти весь файл успеваемости, найти все записи, для ко­торых названием дисциплины является строка "Физика";

- найти файл предметов со строкой "Физика", а затем соглас­но указателям извлечь все соответствующие записи из файла успеваемости.

Если доля всех студентов, сдавших физику, по отношению к общему количеству студентов невелика, то вторая стратегия бу­дет гораздо эффективнее первой. Дело в том, что СУБД известна физическая последовательность записей в файле предметов, а поиск будет прекращен после извлечения следующего за физикой в алфавитном порядке названии предмета. Кроме того, даже если придется просмотреть файл предметов полностью, для такого поиска потребуется гораздо меньше операций ввода-вывода, по­скольку физический размер файла предметов меньше, чем размер файла успеваемости из-за меньшего размера записей.

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

Если индексирование организовано на основе ключевого по­ля, например, на основе поля SN файла успеваемости, то индекс называется первичным. А если индекс организован на основе другого поля, например, поля PN, то он называется вторичным.

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

Основным преимуществом использования индексов являет­ся значительное ускорение процесса выборки или извлечения данных, а основным недостатком - замедление процесса об­новления данных, т. к. при каждом добавлении новой записи в индексированный файл потребуется также добавить новый индекс в индексный файл. Индексы можно использовать двумя разными способами:

- для последовательного доступа к индексированному фай­лу, т. е. в последовательности, заданной значениями ин­дексного поля. Например, индекс PN будет определять доступ к записям файла успеваемости согласно алфавит­ному перечню предметов;

- индексы могут использоваться и для прямого доступа к отдельным записям индексированного файла на основе заданного значения индексного поля, как это было сдела­но в приведенном примере.

Хранимый файл может иметь несколько индексов: например, хранимый файл успеваемости может иметь индекс PN и индекс OCENKA (см. рис. 7.2).

Рис. 7.2. Индексирование файла оценок по полю PN и OCENKA

Индексы могут как раздельно, так и совместно использоваться для более эффективного доступа к данным об успеваемости, на­пример, при запросе на поиск студентов, сдавших физику на 5.

Тогда согласно индексу PN для студентов будут найдены записи с идентификационными указателями z3412 и z3414, а согласно индексу OCENKA - записи с указателями z3412 и z3415. Понят­но, что на основе сравнения этих двух наборов записей условиям запроса удовлетворяет только запись с данными о студенте z3412 и только после этого в СУБД будет организован доступ к файлу успеваемости и будет извлечена данная запись.

Часто индекс создают на основе комбинации двух или более полей. Например, на рис. 7.3 показана схема индексирования файла успеваемости на основе комбинации полей PN и OCENKA. При такой организации индексов в СУБД можно выполнить за­прос на поиск студентов, сдавших физику на 5 на основе одно­кратного просмотра с помощью одного индекса, а, как было по­казано выше, при использовании пары индексов требуется два отдельных просмотра, тем более, что скорость выполнения за­проса может сильно зависеть от последовательности выполнения отдельных просмотров по индексам.

Рис. 7.3. Индексирование файла оценок по комбинации полей PN и OCENKA

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

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

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

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

Другим недостатком хеширования является возможность воз­никновения ситуаций, когда две или более различных записей имеют одинаковые адреса, поэтому иногда возникает необходи­мость функцию исправлять. Если на одной странице располагает­ся несколько записей, то для исправления можно воспользоваться методом прямого перебора. Суть метода заключается в следую­щем: предположим, что на пустой странице s размещается n за­писей. Тогда, при размещении записей и возникновении первых n совпадений по некоторому хеш-адресу s, все такие записи будут размещены на этой странице и найдены при необходимости с помощью прямого перебора. Однако при размещении следующей n+1 записи и возникновении очередного совпадения, запись при­дется разместить на дополнительной странице переполнения, для чего понадобится дополнительная дисковая операция ввода-вывода.

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

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

- если в качестве хеш-функции используется функция f, а значение ключевого поля для некоторой записи z равно р, то в качестве результата хеширования значения ключево­го поля будет получено значение псевдоключа для записи z в виде f(р). Здесь псевдоключ используется не в качест­ве адреса записи, а лишь как косвенный указатель на ме­сто их хранения;

- хранимый файл имеет связанный с ним каталог, который также сохраняется на диске. Он состоит из заголовка, со­держащего значение g, которое называется глубиной ка­талога, а также 2⁸ указателей на страницы с несколькими записями данных на каждой.

Таким образом, с помощью каталога глубиной g можно орга­низовать доступ к файлу, содержащему несколько различных страниц с данными.

Если рассматривать первые g бит псевдоключа как целое без­знаковое двоичное число b, то i-й указатель в каталоге будет от­носиться к странице, содержащей все записи, для которых вели­чина b равна. Для того чтобы найти запись со значением клю­чевого поля, равным р, следует с помощью хеш-функции вычис­лить значение псевдоключа, а затем по первым g бит псевдоклю­ча определить численное значение i-1 и найти в каталоге соответ­ствующий ему i-й указатель на страницу, содержащую искомую запись, что реализуется за два доступа к диску.

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

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

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

Стоит обратить внимание на то, что поле с названиями пред­метов PN отсутствует в файле успеваемости, т. к. СУБД для по­иска студентов в зависимости от сданного предмета будет искать строку с названием предмета в родительском файле, а затем из­влекается вся связанная с данной строкой цепочка указателей.

Рис. 7.4. Родительско-дочерняя структура для файла с данными об успеваемости

Основным преимуществом родительско-дочерней структуры является значительно более простое выполнение операций встав­ки или удаления записей по сравнению с индексной структурой.

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

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