Внутренняя реализация функций базы данных

Как мы уже говорили в лекции 3, функции базы данных AS/400 реализуются по разные стороны MI. В предыдущих разделах обсуждалась, в основном, база данных, реализованная как часть DB2/400 поверх MI. Давайте теперь рассмотрим некоторые системные объекты MI, используемые в DB2/400, а также то, как некоторые из операций над этими системными объектами реализованы в SLIC ниже MI. В этой книге нет места для детального описания всех средств и функций базы данных, и мы остановимся только на самых важных.

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

SLIC поддерживает большие базы данных. Приведем некоторые предельные величины:

• до 240 ГБ на физический файл;
• более 2 миллиардов записей на физический файл;
• до 4 ГБ на индекс;
• до 2048 байтов на ключ.

Следует отметить, что эти ограничения размеров связаны с текущей реализацией SLIC. Для MI нет какоголибо ограничения размеров системных объектов, так как он независим от технологии. SLIC же зависит от технологии, то есть размеры полей некоторых внутренних структур данных предопределены, что, в свою очередь, задает ограничения сверху. Мы обсудим некоторые из этих ограничений при рассмотрении внутренней реализации. Впрочем, как и в любой хорошей системе, здесь остается возможность модификаций, если таковые понадобятся, и об этом мы тоже поговорим.

А сейчас, начнем с рассмотрения системных объектов MI, поддерживающих базу данных.

Объекты базы данных

Ранее мы рассмотрели три основных системных объекта для поддержки базы данных: области данных, индексы областей данных и курсоры. Как и остальные системные объекты, они занимают несколько сегментов в одноуровневой памяти. Каждый из них имеет базовый сегмент, содержащий заголовок сегмента, заголовок ЕРА и специфический заголовок объекта; а кроме того — сегмент ассоциированного пространства.

Области данных

Области данных содержат записи базы данных. Все записи одной области данных схожи: однородны и имеют фиксированную длину. Записи хранятся в порядке их поступления, и все удаленные записи попрежнему занимают место.

Объект "область данных" состоит из сегментов трех типов. Кроме базового сегмента и сегмента ассоциированного пространства, в его состав может входить до 120 сегментов записей области данных. Каждый элемент сегмента содержит байты состояния и записи базы данных. Байт состояния содержит информацию о нынешнем состоянии записи, или о том, была ли она удалена.

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

Начинающийся с нуля порядковый номер указывает, является ли запись первой, второй или n-ной в сегменте. Так как длина всех записей одинакова, необходимости хранения в сегменте порядковых номеров нет. Зная порядковый номер и длину каждой записи можно найти стартовый байт любой записи сегмента. Далее будет рассказано, как порядковый номер используется для поиска записей в базе данных.

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

Ассоциированное пространство содержит таблицу описателей полей с описанием каждого поля записи. Там также размещается рабочая область, используемая компонентами базы данных OS/400. Например, в ассоциированном пространстве хранятся указатели на логические курсоры.

Индексы области данных

Индекс области данных задает альтернативный порядок записей в области данных. Для альтернативного упорядочения используется дерево с двоичным основанием. В разделе "Деревья с двоичным основанием" мы рассмотрим такое дерево и его использование для поддержки ряда функций AS/400, включая индекс области данных.

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

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

В лекции 5 были приведены примеры объектов, включая индекс области данных. Мы видели, что последний состоит из сегментов трех типов: базового, ассоциированно го пространства и отложенной коррекции. Последние два сегмента уже были подробно рассмотрены, теперь остановимся на базовом сегменте.

Базовый сегмент содержит атрибуты альтернативной сортировки, обеспечиваемой индексом, а также таблицу, описывающую как индекс "видит" каждое поле записей в области данных. Это описание логического представления. Базовый сегмент также содержит до 32 адресов областей данных. Наконец, в базовом сегменте находится дерево с двоичным основанием.

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

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

Курсоры

Курсоры — механизм просмотра данных в области данных; через них осуществляется весь доступ к данным. Курсор, о котором мы сейчас говорим, — системный объект MI. DB2/400 поддерживает позиционируемые (scrollable) и последовательные файловые курсоры в соответствии со стандартом SQL 1992. Курсор SQL — это не то же самое, что и системный объект MI "курсор", хотя последний и используется для реализации первого.

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

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

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

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

Курсор состоит из двух сегментов: базового и ассоциированного пространства. Базовый сегмент содержит два набора адресов для указания областей данных и индексов областей данных, которые могут использоваться курсором; и тех и других может быть по 32. Единственный случай, когда может потребоваться более одного индекса области данных — логический файл объединения (joinlogical file, а не проекция SQL). Базовый сегмент также содержит код проецирования и код выборки, используемые курсором. Ассоциированное пространство курсора содержит текст описания раздела и его атрибуты. Связи на уровне раздела поддерживаются компонентом базы данных в OS/400.

Теперь, изучив каждый из трех основных системных объектов поддержки базы данных, можно говорить о том, как пользователь обращается к файлам базы данных в AS/400.