2.4.10. Многосписочные структуры
Вариант представления, изображенный на предыдущем рисунке (использующий цепочки указателей), является простым примером многосписочной организации.
Здесь мы соединили вместе всех поставщиков одного и того же города. Другими словами, для каждого города мы составили список соответствующих поставщиков.
Таким же способом (с помощью дополнительных указателей) можно организовать список поставщиков, имеющих одинаковое значение поля статуса. В общем случае многосписочная организация может содержать произвольное число списков.
2.4.11. Инвертированная организация
Вернёмся к рассмотрению вторичного индексирования. Так же, как это было сделано для списков в многосписочной организации, можно обеспечить произвольное число вторичных индексов. В предельном случае мы имеем ситуацию, иллюстрируемую следующим рисунком, где предусмотрен индекс по каждому вторичному полю (т.н. «инвертированную организацию»).
Рисунок 2.4.11.1 – Инвертированная организация
Однако, несмотря на то, что инвертированная организация обеспечивает хорошую производительность для запросов о всех поставщиках, обладающих определенным значением атрибута (например, значением статуса, равным 20), ответ на запрос о всех атрибутах конкретного поставщика потребует продолжительного времени.
Поэтому на практике часто используется компромиссный вариант, предусматривающий обычную организацию совместно со вторичными индексами по тем полям, которые являются важными с точки зрения администратора базы данных.
Такой вариант является одной из наиболее общих структур хранения, используемых в настоящее время.
2.4.12. Иерархическая организация
Другим вариантом представления является иерархическая организация, иллюстрируемая следующим рисунком:
Рисунок 2.4.12.1 – Иерархическая организация
Здесь также есть один хранимый файл, содержащий три экземпляра (иерархической) хранимой записи, по одному экземпляру на город.
Каждый экземпляр хранимой записи содержит список произвольной длины, каждый элемент которого содержит номер поставщика, его имя и статус.
Здесь мы осуществляем факторизацию (группировку) по значениям поля «город», но на этот раз для представления связи между городом и расположенными в нём поставщиками данные о городе и всех таких поставщиках размещены в одном экземпляре хранимой записи (вместо использования указателей).
2.4.13. Хэш-аресация
Последним вариантом представления, который мы будем рассматривать, является хэш-адресация.
Основная идея хэш-адресации состоит в том, что каждый экземпляр хранимой записи размещается в базе данных по адресу, который может быть вычислен как некоторая функция (хэш-функция) от значения некоторого поля в этом экземпляре записи – обычно значения первичного ключа.
Подробнее о хэш-функциях – в конце этой темы.
Таким образом, чтобы первоначально сохранить экземпляр записи, СУБД вычисляет адрес хранимой записи и заставляет метод доступа разместить этот экземпляр в соответствующей позиции; при поиске экземпляра СУБД выполняет те же самые вычисления и запрашивает метод доступа для вызова экземпляра из вычисленной позиции.
Преимущество такой организации заключается в очень быстром прямом доступе на основе значений хэшируемого поля.
Рассмотрим пример хэш-адресации.
Предположим, что значениями S# являются S100, S200, S300, S400, S500 (вместо S1, S2, S3, S4, S5).
Рассмотрим хэш-функцию:
АдресХранимойЗаписи = S# % 13
(остаток от деления значения S# на 13)
Это простой пример общего класса хэш-функций – «деление/остаток» (делителем обычно является простое число).
Адресами хранимых записей в данном случае будут 9, 5, 1, 10, 6 соответственно.
Рисунок 2.4.13.1 – Хэш-адресация
Теоретически возможно использовать числовое значение первичного ключа в качестве адреса хранимой записи.
Однако этот вариант неприемлем из-за того, что диапазон значений первичного ключа обычно много шире диапазона доступных адресов хранимых записей.
Например, предположим, что номера поставщиков являются трёхзначными, как это было определено ранее.
Теоретически это допускает 1000 различных поставщиков, в то время как на практике может существовать, допустим, 10.
Чтобы избежать колоссальных издержек памяти, в идеальном случае необходимо, чтобы хэш-функция переводила любое значение из диапазона 0-999 в значение из диапазона 0-9.
Чтобы учесть возможное расширение в будущем диапазон обычно увеличивают на 20%.
Так, в только что рассмотренном примере мы выбрали функцию, которая генерирует значения в диапазоне 0-12, а не в диапазоне 0-9.
Этот пример также иллюстрирует недостаток хэш-адресации: последовательность экземпляров хранимых записей в пределах хранимого файла не совпадает с последовательностью, определяемой первичным ключом (кроме того, могут существовать промежутки произвольного размера между следующими друг за другом экземплярами).
Фактически хранимый файл с хэш-адресацией обычно рассматривается как неупорядоченный.
Другим недостатком хэш-адресации является возможность коллизий, когда двум различным экземплярам хранимых записей назначается один и тот же адрес.
Например, предположим, что в наш пример включён поставщик со значением номера равным S1400.
Хранимые записи этого поставщика и поставщика S100 будут иметь, в соответствии с использованной нами хэш-функцией, одинаковый адрес хранимой записи – 9.
Выходом из подобного положения является усложнение хэш-функции с целью управления такими ситуациями.
Одна из возможностей заключается в использовании адреса хранимой записи, выработанного хэш-функцией, в качестве начальной точки для последовательного просмотра.
В этом случае для того, чтобы добавить запись о поставщике S1400 осуществляется поиск свободного места вперёд, начиная с позиции, определяемой адресом хранимой записи – 9.
В данном случае запись о новом поставщике будет размещена по адресу 11. При последующей выборке поставщика S1400 выполняются аналогичные действия.