Цепочки указателей

Для выполнения запроса типа «Найти поставщиков из города С» можно применить другой способ сохранения данных с использованием цепочек указателей. Этот способ бывает более эффективен, чем индексирование. На рис.7 показан пример использования цепочек указателей для файла поставщиков и файла городов. Однако, в отличие от примера с индексированием (рис.3), теперь оба файла могут находиться в одном наборе файлов. Причем файл городов называетсяродительским (не индексным), а файл поставщиковдочерним файлом. Соответственно вся структура в целом называетсяродительско-дочерней. При этом поле с названиями городов удалено из файла поставщиков, поскольку в СУБД для поиска всех поставщиков из заданного города будет предпринят поиск строки с данным городом в файле городов, а затем извлечена вся связанная с данной строкой цепочка указателей. Родительский же файл содержит одну хранимую запись для каждого города, предоставляя по требованию название города в качестве заголовка цепочки или кольца указателей, связывающих вместе все дочерние записи поставщиков из этого города.

Азов



Ростов



Таганрог



S1

Иванов

20



S2

Петров

10



S3

Сидоров

30



S4

Федоров

20



S5

Аверьянов

30



Рис.7. Пример реализации родительско-дочерней структуры

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

1. Для данного города единственным путем доступа к n-му поставщику является цепочка с последовательным перебором всех предыдущих записей поставщиков. Если для этих записей не выполнена кластеризация, то для каждого доступа может потребоваться отдельная операция поиска, а время доступа к записи с даннымиnго поставщика оказаться очень большим.

2. Хотя данная структура может оказаться оптимальной для выполнения запроса типа «Найти поставщиков из заданного города», она весьма неэффективна для обратного запроса «Найти город данного поставщика», где поставщик задан с помощью номера. Здесь лучше бы подошла бы индексная или хешированная структура. Дело в том, что для поиска названия города пришлось бы просмотреть всю цепочку.

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

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

4. Указатели можно задать как в одном направлении, так и в обратном. При такой организации существенно упрощается процесс согласования указателей при удалении дочерней записи.

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

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

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