Хранение отношений

Организация физического хранения информации в БД. Структуры хранения данных.

Файл

Классификация файлов и файловых структур, использующихся для хранения информации в БД.

Прямого доступа

Индексные

Последовательного доступа

Инвертированные списки

Взаимосвязанные файлы

Двунаправленные цепочки

Однонаправленные цепочки

Неплотный индекс(Индексно последовательные)

Индексно прямые(Плотный индекс)

В - деревья

Соответственно в реляционной СУБД возникают следующие разновидности объектов во внешней памяти:

1. Строки отношений. Основная часть БД непосредственно видима пользователю.

2. Управляющие структуры. Индексы, составляемые по инициативе пользователя или администратора СУБД или самой СУБД из соображений повышения эффективности выполняемых запросов.

3. Журнальная информация, необходимая для надежного хранения данных.

4. Служебная информация, необходимая для удовлетворения внутренних потребностей системы

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

1. Каждый картеж обладает уникальным идентификатором(tid), неизменяемым за всё время существования картежа.

2. Обычно каждый картеж хранится целиком на одной странице, из чего следует, что максимальная длина картежа ограничена размерами страницы. Если данные не помещаются на одной странице, применяются несколько методов. Наиболее простым решением является хранение таких данных в отдельных файлах с заменой такого длинного данного «картежа» на имя соответствующего файла. Второй метод заключается в хранении таких данных в отдельном наборе страниц внешней памяти, соответственно связанном физическими ссылками. В настоящее время в основном используется еще один метод, когда такие большие данные организуются в виде B-деревьев.

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

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

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

Второй способ – хранение отношений по столбцам.

Менее распространенным подходом является хранение отношений по столбцам, т.е. единицей хранения является столбец с исключенными дубликатами.

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

Дата добавления: 2014-01-04