Индексирование

Основная проблема в физическом представлении БД – это хранение файлов, содержащих записи с идентичным форматом. Формат записи – список полей, каждый из которых имеет фиксированный тип данных и фиксированную длину. Основные операции, выполняемые над хранимым файлом: 1. добавление записи; 2. удаление; 3. изменение; 4. поиск. Сложность организации хранения файлов зависит от комбинации операций, которые будут выполняться. Существует определенная схема управления физическим доступом: Интерфейс внешней записи – предназначен для отвлечения пользователя от изучения структуры файлов, связей между файлами и т.д. Интерфейс хранимых записей – позволяет представить структуру хранения в виде файлов, каждый из которых состоит из записей одного типа, а также связей между файлами. Интерфейс физических записей – представляет структуру хранения файлов в соответствии с установленной файловой системой. Как правило, дисковая память делится на физические блоки равного размера, каждый блок имеет адрес, который является абсолютным. Задача файловой системы – установить соответствие между именем файла и соответствующим адресом блоков. Запись в блоке может иметь адрес, который рассматривается как абсолютный, если существует ссылка на первый байт этой записи, или как относительный, если используется адрес блока со смещением (число байт, которое надо пройти до первого байта). Если дисковая память организована как виртуальная, то на блоки (или записи) можно ссылаться, задавая их смещение от начала воображаемой области виртуальной памяти. Обработку блока информации выполняет ОС, точнее ее часть отвечающая за ввод-вывод. Обработку каждой записи выполняет СУБД. Вместо смещения в блоке в качестве указателя на запись может быть использован какой-либо признак (если база индексирована). Основные методы организации данных на уровне интерфейса хранимых записей. Данный файл на уровне интерфейса физических записей будет представлен в соответствии с файловой структурой ОС. А на уровне интерфейса хранимых записей его организация м.б. различной, т.е. СУБД будет видеть записи в базе в зависимости от варианта организации: 1 вариант: Создание таблицы с первичным ключом. Существует единственный хранимый файл, который содержит 5 записей по одной на каждого поставщика. Преимущества: простота и очевидность. Недостатки: 1) медленный поиск (кроме запроса «найти все сведения о поставщике»); 2) нет экономии памяти. 2 вариант: Факторизация. В случае факторизации данные размещаются по 2-м файлам, причем с указателями из исходного на дополнительный. Это основной принцип организации справочника. Преимущества: экономия памяти в том случае, если количество записей в исходной файле (SUPLIER) велико, а в факторизованном файле (CITY) мало. Недостатки: с т.з. поиска данная структура не является достаточно оптимальной особенно для запросов «найти все сведения о поставщике» и «найти всех поставщиков в одном городе». 3 вариант: Индексирование по определенному полю. Данный метод с т.з. памяти аналогичен предыдущему, с т.з. поиска он обеспечивает лучшие характеристики для запроса «найти всех поставщиков в одном городе» и худшее для запроса «все сведения о поставщике», «статус поставщика». Механизм индексирования. Один из механизмов индексирования предполагает, что записи в исходном файле имеют ключи со значениями из натурального ряда и перед выполнением индексирования эти ключи упорядочены по возрастанию. Записи загружаются в файл, плотно заполняя блоки (размер определяется программой) и после чего система формирует строку в таблице младших индексов, ставя в соответствие № блока и мах-ый ключ в этом блоке (такая таблица формируется на определенное кол-во блоков). После заполнения таблицы формируется строка в таблице старшего индекса, где ставится в соответствие № таблицы младшего индекса и мах-го ключа. Количество уровней индексирования зависит от размера файла. 4 вариант: Сочетание факторизации и индексирования. Данная модель характерна большими объемами памяти, неопределенным количеством указателей, поэтому возникает сложность их организации и поддержание их целостности (сложность поддержание системы при изменении данных). С т.з. запросов очень быстро обрабатываются запросы «о городе поставщика» и «о поставщиках в конкретном городе». Остальные запросы вызывают сложности. Данным методом редко кто пользуется. 5 вариант: Использование цепочек – указателей. В данном методе каждый экземпляр записи файла городов (CITY) имеет только один указатель: на первого поставщика в этом городе. Первая запись поставщика содержит указатель на следующего в этом же городе, и так до последнего поставщика. Если последний поставщик не имеет ссылку на город, то цепочка называется разомкнутая, если имеет – замкнутая. Недостатки: 1) долгий поиск по запросу «найти конкретного поставщика в городе» и «все сведения о поставщике»; 2) возможность потери связи при удалении и т.д. Данные недостатки м.б. устранены при условии использования двунаправленных цепочек или путем включения в запись поставщика указателя на соответствующую запись города. Преимущества: 1) запрос «найти всех поставщиков в данном городе»; 2) файл городов, точнее, каждая его запись имеет только один указатель. 6 вариант: Иерархическая организация: В этом методе любая хранимая запись является иерархической. Каждый элемент файла содержит № поставщика, его имя и связь между городом и поставщиком в нем. Такая связь достигается за счет расположения данных в одном экземпляре хранимой записи. Левостороннее движение по дереву позволяет сделать из иерархической системы простой список (последовательная организация). При такой структуре лучшие временные характеристики имеет запрос «получить всех поставщиков в конкретном городе». Запросы типа «найти конкретного поставщика» или «его отдельные характеристики» проходят гораздо медленнее и вызывают определенные сложности. Операции добавления данных удобны только в случае добавления информации на самый нижний уровень (т.е. новых поставщиков в уже известные города), удаление и корректировка информации происходит с такими же проблемами. 7 вариант: Инвертированная организация. Метод состоит в использовании вторичного индексирования. При этом любое данное записи можно объявить вторичным ключом. В этом случае система построит индексную таблицу, устанавливающую соответствие между значениями вторичного ключа и ключа БД. 8 вариант: Хеш-адресация. Принцип состоит в том, что любой экземпляр записи размещается по адресу, который м.б. вычислен как функция от значения некоторого поля в этом экземпляре записи Вывод по всему вопросу: не существует понятия «наилучшая структура хранения», определение такой структуры входит в обязанности администратора БД, при этом должно учитываться большое количество противоречивых требований. Следовательно, для каждой конкретной задачи существует своя наилучшая структура хранения.