Поиск информации. Индексные файлы

Факт

Договор

Сплав-Параметр

Сплав

SL_PREM

PREM

Таб_ном Дата_присуж Код_прем

Главным ключом в этой таблице является

Таб_ном + Дата_присуж.

Если допустить, что в один день сотрудник может получить две премии (в юбилей), то в

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

Код_прем

Назв_прем

Рассмотрим еще один пример.

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

Код_спл, Пар1, Пар2, …., Пар100

или

Код_спл

Пар1

Пар2

…

Пар100

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

Поэтому добавляется таблица, хранящая только имеющиеся параметры:

Код_спл, Код_пар, Знач_пар

Код_спл

Код_пар

Знач_пар

к которой нужен один словарь (справочник) параметров.

Единственный недостаток этой таблицы- многократное повторение кода одного и того же сплава.

Проблема дублирования информации в последовательности полей устраняется на уровне конкретной оболочки СУБД. То есть, например, при переходе к следующему одноименному полю работает автоповтор и т.п.

Общие поля в связанных таблицах

Пусть имеется таблица хоздоговоров «Договор» с полями: Номер_догов (ключ), Код_заказчика, Цена_догов, и т.д.:

Номер_догов (кл.)

Код_заказчика

Цена_догов

Договор может быть заключен на несколько лет. С целью месячного учета фактических затрат по каждому договору создана таблицы «Факт» с полями: Ном_дог, Год, Месяц, Цена_дог, Затраты_на_оборуд, и т.д. Ключ этой таблицы: Номер_дог + Год + Месяц:

Номер_догов (кл.)

Год (кл.)

Месяц (кл.)

Цена_догов

Затраты_на_оборуд

Получилась связанная пара таблиц в которой ключ таблицы «Договор» является старшей частью ключа таблицы «Факт». Обратим внимание на поле «Цена» в обоих таблицах - одинаковые поля и казалось бы нужно принимать меры по устранению избыточности. Но в данном случае это поле заполняется по смыслу независимо и должен быть механизм контроля за одинаковостью.

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

Допустим, мы работаем с системой КАДРЫ и хотим найти зарплату для сотрудника с табельным номером N. Простейший метод- чтение всех записей до того как найдем N. Во многих случаях метод перебора не устраивает. При наличии очереди клиентов (касса аэропорта, оптовый склад) выполнение запроса по десяткам тысяч записей должно занимать единицы секунд.

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

Теперь усложним задачу и зададим следующий вопрос: «Перечислить сотрудников отдела В с зарплатой менее 80000 рублей». В этом случае придется сначала упорядочить таблицу по коду отдела, но тогда нарушится упорядочение по табельному номеру и по нему - опять придем к медленному варианту поиска - перебору.

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

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

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

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

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