В этой статье я объясню, как данные хранятся в
CUBRID RDBMS . Я опишу концепцию объектов, классов и OID в CUBRID.
Одной из характеристик CUBRID, которую часто обсуждают как « расширение реляционной модели данных », является его объектно-ориентированная модель . CUBRID имеет много объектно-ориентированных концепций. Все записи данных рассматриваются как объекты, которые содержат записи, а таблицы , определяющие структуру, рассматриваются как классы , определяющие объекты. Он реализован с использованием объектно-ориентированных концепций и предоставляет пользователям реляционную модель и SQL (язык реляционных запросов). Кроме того, он предоставляет « расширенные режимы реляционных данных », такие как наследование между классами ,типы данных для сбора ( SET, MULTISET, LIST) и композиции отношение .
Для реляционной модели данных не допускается, чтобы один столбец имел несколько значений. Однако в CUBRID вы можете определить несколько значений для столбца. Для этого в CUBRID предусмотрены типы данных для сбора. Типы данных Коллекции делятся SET, MULTISETи в LISTзависимости от того , дублирования элементов допускаются или нет.
наследование
Наследование — это концепция, которая позволяет повторно использовать в дочерних таблицах столбцы и методы, определенные в родительских таблицах. CUBRID поддерживает наследование для повторного использования. Используя функцию наследования, предоставляемую CUBRID, вы можете создать родительскую таблицу с некоторыми общими столбцами, а затем создать дочерние таблицы, унаследованные от родительской таблицы, с добавлением некоторых уникальных столбцов. Таким образом, вы можете моделировать базу данных, минимизируя количество необходимых столбцов.
OID
В реляционной базе данных отношение определяется, позволяя ссылочной таблице иметь первичный ключ указанной таблицы в качестве внешнего ключа. Если первичный ключ состоит из нескольких столбцов или размер ключа велик, производительность операций соединения между таблицами будет снижаться.
Однако CUBRID позволяет напрямую использовать физический адрес ( OID ), в котором находятся записи упомянутой таблицы, поэтому вы можете определять отношения, не используя операции соединения . То есть в объектно-ориентированной базе данных, такой как CUBRID, вы можете создать композиционное отношение, в котором одна запись имеет ссылочное значение для другой, используя столбец, отображаемый в указанной таблице как домен (тип), вместо ссылки на первичный ключ. столбец из приведенной таблицы.
Как правило, в объектно-ориентированных программах объектами являются фактические данные, хранящиеся в памяти, где указатели объектов используются для указания на эти объекты. И наоборот, CUBRID напрямую обрабатывает объекты базы данных, поэтому он не может выражать объекты. Вместо этого он выдает уникальный идентификатор объекта (OID) для каждого объекта. OID указывает физический адрес объекта базы данных, абсолютное местоположение в файле тома базы данных на диске. Как и указатель памяти, который обозначает физический адрес в области памяти, OID — это физический адрес в области базы данных.
OID, физический адрес объекта базы данных, состоит из номера тома ( volid), номера страницы в томе ( pageid) и номера слота в странице ( slotid). Следующий код является выдержкой из исходного кода CUBRID, который определил OID.
typedef struct db_identifier DB_IDENTIFIER;
struct db_identifier
{
int pageid;
short slotid;
short volid;
};
typedef DB_IDENTIFIER OID;
Прорезанные страницы
Объект БД или запись данных в CUBRID сохраняются на странице со слотами , традиционной структуре дискового хранилища СУБД. СУБД хранится на диске, поэтому дисковый ввод-вывод осуществляется страницами диска (или страницами базы данных) так же, как и операционная система. Размер страницы базы данных в CUBRID составляет 4 КБ или 16 КБ, последний является размером страницы по умолчанию (см. —Db-page-size ).
Одна страница содержит несколько записей данных (или объектов БД). Следовательно, для получения конкретных данных записи необходимо знать местоположение записи на странице и длину записи. Самый простой способ легко получить данные — это расположить записи одну за другой в начале страницы. Однако при создании новой записи или удалении другой записи содержимое и длина существующих записей часто изменяются. Итак, нам нужен способ избежать перемещения местоположения других записей при каждом изменении записи и быстрого определения местоположения нужной записи (из какого байта считываются данные соответствующей записи на странице), пока длина каждая запись отличается друг от друга. По этой причине большинство СУБД реализуют структуру страниц со слотами.
Рисунок 1: CUBRID.
Как показано на рисунке 1 , одна страница содержит несколько записей, и расположение каждой записи указывается в области слотов в конце страницы. Размер одного слота составляет 4 байта, и слоты нумеруются с конца страницы как слот 1, слот 2, …, слот N. Слот 1 указывает местоположение записи 1 , то есть смещение на странице, и слот 2 указывает местоположение записи 2 . На приведенном выше рисунке слот 6 не указывает местоположение записи (значение равно -1), что означает, что запись 6 была удалена.
Как показано на рисунке выше, записи заполняются и сохраняются с начала страницы, а слоты заполняются и сохраняются с конца страницы. Слот сохраняет смещение вместе с размером записи. 4-байтовый слот состоит из 14-битного смещения , 14-битной длины и 4-битного типа записи . Наконец, тип записи выражается с использованием 4 битов, а типы записей могут быть до 16. В CUBRID имеется 7 типов страниц слотов, и эти типы показаны в файле storage / slotted_page.h исходного кода. ( #define REC_HOME 2это код, который показывает тип записи.)
Как показано в приведенном выше фрагменте кода из OID структуры, идентификатор объекта состоит из номера тома , на номер страницы , и номер слота . Используя номер тома, вы можете найти файл, в котором хранится запись. Чтобы увидеть, какая часть файла должна быть прочитана, используется номер страницы. Номер слота показывает, где на этой странице находятся нужные данные записи.
Классы
Как и общая объектно-ориентированная концепция, структура объектов БД в CUBRID выражается через классы . Это похоже на запись данных и схему таблицы базы данных. Для объектно-ориентированного языка, такого как Java и C ++, класс — это фрейм, используемый для объявления структуры объекта, которая физически не существует. Однако в CUBRID все по-другому, когда класс также является своего рода объектом БД. Другими словами, класс — это одна из записей данных, которые имеют определенную информацию, как и другие объекты БД .
- Объект экземпляра БД — это запись с пользовательскими данными.
- Объект класса DB также является записью, которая содержит данные о структуре (схеме таблицы) объектов экземпляра (записей), которые принадлежат соответствующему классу (таблице).
Данные схемы таблицы показывают столбцы в таблице, типы данных каждого столбца и ограничения таблицы или ограничения столбца, определенные пользователем. В обычной реляционной СУБД эти данные называются данными схемы или словарем данных. Он сохраняется и управляется в отдельном пространстве как специальный формат. Однако в CUBRID он обрабатывается как один из объектов БД в соответствии с объектно-ориентированной концепцией CUBRID. Из исходного кода CUBRID вы можете видеть, что объект DB обрабатывается путем различения типа объекта ( объект класса или объект экземпляра ).
Корневой класс
Если класс (схема таблицы) рассматривается как объект БД, то как определяется структура объектов класса? Все объекты должны иметь свой класс. В этом случае требуется ли отдельный класс для объектов класса? Ответ — да. Объекты класса принадлежат классу, называемому корневым классом . Следовательно, объекты класса являются объектами экземпляра корневого класса. Другими словами, это записи в таблице, которая определена как корневой класс.
Рисунок 2: Корневой класс и объект класса в CUBRID.
Корневой класс можно рассматривать как таблицу, содержащую определения таблиц. Исходя из стандартной концепции SQL, эта таблица называется информационной схемой , обычно называемой системным каталогом . Чтобы увидеть, какие таблицы определены в базе данных, выполняется SELECT table_name FROM tables; запрос. Чтобы увидеть, какие столбцы определены для таблицы, выполняется SELECT column_name FROM columns WHERE table_name='t1'; запрос. Таблицы или таблицы столбцов, используемые здесь, являются информационной схемой, то есть таблицами системного каталога. Чтобы быть точным, таблицы системного каталога в CUBRID (например,db_classтаблицы) существуют отдельно, а объекты класса сохраняются и управляются отдельно. Со структурной точки зрения таблицы системного каталога идентичны общим таблицам: это таблицы, которые система создала заранее при создании базы данных. Объекты класса используются внутри. Структура записи (или схема) объекта класса заранее определена в исходном коде. Таким образом, когда объект класса читается с диска, он преобразуется в объект памяти для интерпретации содержимого. Структура языка Си, которая определяет структуру объекта памяти объекта класса, находится struct sm_classв файле object / class_object.h .
Вывод
На этом мы заканчиваем разговор о том, как данные хранятся в CUBRID RDBMS? Я объяснил отдельные блоки хранилища, такие как тома данных, страницы и слоты страниц, которые указывают на фактические записи данных. Теперь вы знаете, что составляет идентификатор объекта (OID). При непосредственном доступе к данным, хранящимся на диске, с использованием OID, CUBRID пропустит пересчет физического адреса запрашиваемой записи, поскольку вы уже указали OID записи. Это обеспечивает дополнительную производительность. Также из этой статьи вы узнали, что все в CUBRID является объектом, который имеет тип объекта класса или объекта экземпляра . Объекты экземпляра хранятся в объектах класса, а объекты класса хранятся в корневом классе.
В следующей статье я расскажу о типах данных и доменах в CUBRID и о том, как вы можете наследовать типы данных.
