Учебная дисциплина «Базы данных» для студентов специальности ЛЕКЦИЯ №3 ВНУТРЕННЯЯ ОРГАНИЗАЦИЯ РЕЛЯЦИОННЫХ СУБД

Учебная дисциплина «Базы данных»
для студентов специальности
Бизнес-информатика (бакалавриат) 080500.62
ЛЕКЦИЯ №3
ВНУТРЕННЯЯ ОРГАНИЗАЦИЯ РЕЛЯЦИОННЫХ СУБД
Учебные вопросы:
1. Cтруктуры внешней памяти и методы организации
индексов.
2. Организация и порядок использования индексов.
3. Организация и ведение журнальной и служебной
информации.
Литература
1. Базы данных: учеб. Пособие для студ. высш.
учеб. Заведений / А.В. Кузин, С.В.
Левонисова. – 2-е изд. стер. – М.:
Издательский центр «Академия», 2008.
2. Марков А.С., Лисовский К.Ю. Базы данных.
Введение в теорию и методологию: Учебник.
–М.: Финансы и статистика, 2006.
3. Теория и практика построения баз данных. 8е изд. / Д. Крёнке. –СПб: Питер, 2003.
1 Cтруктуры внешней памяти, методы организации
индексов
Реляционные СУБД обладают рядом особенностей, влияющих на
организацию внешней памяти. К наиболее важным особенностям можно
отнести следующие:
1. Наличие двух уровней системы: уровня непосредственного управления
данными во внешней памяти (а также обычно управления буферами
оперативной памяти, управления транзакциями и журнализацией изменений
БД) и языкового уровня (например, уровня, реализующего язык SQL). При такой
организации подсистема нижнего уровня должна поддерживать во внешней
памяти набор базовых структур, конкретная интерпретация которых входит в
число функций подсистемы верхнего уровня.
2. Поддержание
отношений-каталогов.
Информация,
связанная
с
именованием объектов базы данных и их конкретными свойствами (например,
структура ключа индекса), поддерживается подсистемой языкового уровня. С
точки зрения структур внешней памяти отношение-каталог ничем не отличается
от обычного отношения базы данных.
3. Регулярность структур данных. Поскольку основным объектом реляционной
модели данных является плоская таблица, главный набор объектов внешней
памяти может иметь очень простую регулярную структуру.
4. Для выполнения требования надежного хранения баз данных необходимо
поддерживать избыточность хранения данных, что обычно реализуется в виде
журнала изменений базы данных.
Соответственно возникают следующие разновидности
объектов во внешней памяти базы данных:
1. Строки отношений - основная часть базы данных,
большей частью непосредственно видимая пользователям;
2. Управляющие структуры - индексы, создаваемые по
инициативе пользователя (администратора) или верхнего
уровня системы из соображений повышения эффективности
выполнения
запросов
и
обычно
автоматически
поддерживаемые нижним уровнем системы;
3. Журнальная
информация,
поддерживаемая
для
удовлетворения потребности в надежном хранении данных;
4. Служебная
информация,
поддерживаемая
для
удовлетворения внутренних потребностей нижнего уровня
системы (например, информация о свободной памяти).
Существует два альтернативных подхода к организации
реляционной СУБД с точки разделения функций между
различными компонентами:
1) интегрированная
подсистема
управления
данными,
транзакциями и журнализацией;
2) управление данными отделено от управления транзакциями и
журнализацией.
Первый подход позволяет использовать более эффективные
методы за счет совместного решения проблем физической и
логической синхронизации, использовании общих протоколов при
управлении буферами и журнализации и т.д. Но при этом в
некотором смысле подсистема нижнего уровня становится
монолитом; при самой удачной ее структуризации компоненты
остаются связанными общими протоколами взаимодействия.
Непродуманные локальные изменения одного компонента могут
привести к фатальным последствиям для всей системы.
Второй подход позволяет упростить структуру системы и
сделать ее более гибкой, но это возможно только за счет
огрубления алгоритмов: применения более грубых методов
управления
транзакциями;
жестких
протоколов
журнализации и т.д.
В конечном счете любая конкретная система основывается
на конкретном комплексном решении.
Существуют два принципиальных подхода к физическому
хранению отношений. Наиболее распространенным является
покортежное хранение отношений (кортеж является единицей
физического хранения). Естественно, это обеспечивает быстрый
доступ к целому кортежу, но при этом во внешней памяти
дублируются общие значения разных кортежей одного отношения и,
вообще говоря, могут потребоваться лишние обмены с внешней
памятью, если нужна часть кортежа.
Альтернативным (менее распространенным) подходом является
хранение отношения по столбцам, т.е. единицей хранения является
столбец отношения с исключенными дубликатами. Естественно, что
при такой организации суммарно в среднем тратится меньше
внешней памяти, поскольку дубликаты значений не хранятся; за
один обмен с внешней памятью в общем случае считывается больше
полезной информации. Дополнительным преимуществом является
возможность использования значений столбца отношения для
оптимизации выполнения операций соединения. Но при этом
требуются существенные дополнительные действия для сборки
целого кортежа (или его части).
Рисунок 1 - Структура страницы при организации
хранения по строкам
К основным характеристикам этой организации можно отнести
следующие:
1. Каждый кортеж обладает уникальным идентификатором (tid), не
изменяемым во все время существования кортежа. Структура tid следует из
приведенного выше рисунка.
2. Обычно каждый кортеж хранится целиком в одной странице. Из этого
следует, что максимальная длина кортежа любого отношения ограничена
размерами страницы.
3. Как правило, в одной странице данных хранятся кортежи только одного
отношения.
4. Изменение схемы хранимого отношения с добавлением нового столбца
не вызывает потребности в физической реорганизации отношения.
5. Поскольку отношения могут содержать неопределенные значения,
необходима соответствующая поддержка на уровне хранения.
6. Проблема распределения памяти в страницах данных связана с
проблемами синхронизации и журнализации и не всегда тривиальна.
7. Распространенным способом повышения эффективности СУБД является
кластеризация отношения по значениям одного или нескольких столбцов.
8. С целью использования возможностей распараллеливания обменов с
внешней памятью иногда применяют схему декластеризованного хранения
отношений: кортежи с общим значением столбца декластеризации
размещают на разных дисковых устройствах, обмены с которыми можно
выполнять в параллель.
Что же касается хранения отношения по
столбцам, то основная идея состоит в
совместном хранении всех значений одного (или
нескольких) столбцов. Для каждого кортежа
отношения хранится кортеж той же степени,
состоящий из ссылок на места расположения
соответствующих
значений
столбцов.
В
последней лекции мы будем рассматривать
особенности
организации
распределенных
реляционных СУБД. Одним из приемов является
так называемое вертикальное разделение
отношений, когда в разных узлах сети хранятся
разные проекции данного отношения. Хранение
отношения по столбцам в некотором смысле
является предельным случаем вертикального
разделения отношений.
2. Организация и порядок использования индексов
Как бы не были организованы индексы в конкретной СУБД, их
основное назначение состоит в обеспечении эффективного прямого
доступа к кортежу отношения по ключу. Обычно индекс определяется для
одного отношения, и ключом является значение атрибута (возможно,
составного). Если ключом индекса является возможный ключ отношения,
то индекс должен обладать свойством уникальности, т.е. не содержать
дубликатов ключа.
Поскольку при выполнении многих операций языкового уровня
требуется сортировка отношений в соответствии со значениями некоторых
атрибутов, полезным свойством индекса является обеспечение
последовательного просмотра кортежей отношения в диапазоне значений
ключа в порядке возрастания или убывания значений ключа.
Общей идеей любой организации индекса, поддерживающего прямой
доступ по ключу и последовательный просмотр в порядке возрастания или
убывания значений ключа является хранение упорядоченного списка
значений ключа с привязкой к каждому значению ключа списка
идентификаторов кортежей. Одна организация индекса отличается от
другой главным образом в способе поиска ключа с заданным значением.
2.1 Использование техники B-деревьев
Наиболее популярным подходом к организации индексов в базах данных
является использование техники B-деревьев. С точки зрения внешнего
логического представления B-дерево - это сбалансированное сильно
ветвистое дерево во внешней памяти. Сбалансированность означает, что
длина пути от корня дерева к любому его листу одна и та же. Ветвистость
дерева - это свойство каждого узла дерева ссылаться но большое число узловпотомков. С точки зрения физической организации B-дерево представляется
как мультисписочная структура страниц внешней памяти, т.е. каждому узлу
дерева соответствует блок внешней памяти (страница). Внутренние и
листовые страницы обычно имеют разную структуру.
В типовом случае структура внутренней страницы выглядит следующим
образом:
При этом выдерживаются следующие свойства:
• ключ(1) <= ключ(2) <= ... <= ключ(n);
• в странице дерева Nm находятся ключи k со значениями ключ(m) <= k <=
ключ(m+1).
Листовая страница обычно имеет следующую структуру:
Листовая страница обладает следующими свойствами:
ключ(1) < ключ(2) < ... < ключ(t);
Где сп(r) - упорядоченный список идентификаторов кортежей
(tid), включающих значение ключ(r);
листовые страницы связаны одно- или двунаправленным
списком.
Поиск в B-дереве - это прохождение от корня к листу в
соответствии с заданным значением ключа. Заметим, что
поскольку деревья сильно ветвистые и сбалансированные, то для
выполнения поиска по любому значению ключа потребуется
одно и то же (и обычно небольшое) число обменов с внешней
памятью.
2.2. Хэширование
Альтернативным и все более популярным подходом к организации
индексов является использование техники хэширования. Это очень обширная
тема, которая заслуживает отдельного рассмотрения. Мы ограничимся лишь
несколькими замечаниями. Общей идеей методов хэширования является
применение к значению ключа некоторой функции свертки (хэш-функции),
вырабатывающей значение меньшего размера. Свертка значения ключа затем
используется для доступа к записи.
В самом простом, классическом случае, свертка ключа используется как
адрес в таблице, содержащей ключи и записи. Основным требованием к хэшфункции является равномерное распределение значение свертки. При
возникновении коллизий (одна и та же свертка для нескольких значений
ключа) образуются цепочки переполнения. Главным ограничением этого
метода является фиксированный размер таблицы. Если таблица заполнена
слишком сильно или переполнена, но возникнет слишком много цепочек
переполнения, и главное преимущество хэширования - доступ к записи почти
всегда за одно обращение к таблице - будет утрачено. Расширение таблицы
требует ее полной переделки на основе новой хэш-функции (со значением
свертки большего размера).
В случае баз данных такие действия являются абсолютно
неприемлемыми. Поэтому обычно вводят промежуточные
таблицы-справочники, содержащие значения ключей и адреса
записей, а сами записи хранятся отдельно. Тогда при
переполнении справочника требуется только его переделка, что
вызывает меньше накладных расходов.
Чтобы избежать потребности в полной переделки
справочников, при их организации часто используют технику Bдеревьев с расщеплениями и слияниями. Хэш-функция при этом
меняется динамически, в зависимости от глубины B-дерева.
Путем дополнительных технических ухищрений удается добиться
сохранения порядка записей в соответствии со значениями
ключа. В целом методы B-деревьев и хэширования все более
сближаются.
3. Организация и ведение журнальной и служебной
информации
Структура журнала обычно является сугубо частным делом
конкретной реализации. Мы отметим только самые общие свойства.
Журнал обычно представляет собой чисто последовательный файл с
записями переменного размера, которые можно просматривать в
прямом или обратном порядке. Обмены производятся стандартными
порциями (страницами) с использованием буфера оперативной
памяти. В грамотно организованных системах структура (и тем более,
смысл) журнальных записей известна только компонентам СУБД,
ответственным за журнализацию и восстановление. Поскольку
содержимое журнала является критичным при восстановлении базы
данных после сбоев, к ведению файла журнала предъявляются особые
требования по части надежности. В частности, обычно стремятся
поддерживать две идентичные копии журнала на разных устройствах
внешней памяти.
Для корректной работы подсистемы управления данными во
внешней памяти необходимо поддерживать информация, которая
используется только этой подсистемой и не видна подсистеме
языкового уровня. Набор структур служебной информации зависит от
общей организации системы, но обычно требуется поддержание
следующих служебных данных:
Внутренние каталоги, описывающие физические свойства объектов
базы данных, например, число атрибутов отношения, их размер и,
возможно, типы данных; описание индексов, определенных для
данного отношения и т.д.
Описатели свободной и занятой памяти в страницах отношения.
Такая информация требуется для нахождения свободного места при
занесении кортежа. Отдельно приходится решать задачу поиска
свободного места в случаях некластеризованных и кластеризованных
отношений (в последнем случае приходится дополнительно
использовать кластеризованный индекс). Как мы уже отмечали,
нетривиальной является проблема освобождения страницы в условиях
мультидоступа.
Связывание страниц одного отношения. Если в одном файле
внешней памяти могут располагаться страницы нескольких
отношений (обычно к этому стремятся), то нужно каким-то
образом связать страницы одного отношения. Тривиальный
способ использования прямых ссылок между страницами часто
приводит к затруднениями при синхронизации транзакций
(например, особенно трудно освобождать и заводить новые
страницы отношения). Поэтому стараются использовать
косвенное связывание страниц с использованием служебных
индексов. В частности, известен общий механизм для описания
свободной памяти и связывания страниц на основе B-деревьев.
Контрольные вопросы
1. Охарактеризуйте основные особенности реляционных
СУБД, влияющие на организацию внешней памяти.
2. Охарактеризуйте разновидности объектов во внешней
памяти реляционных баз данных.
3. Охарактеризуйте два альтернативных подхода к
организации реляционной СУБД с точки разделения
функций между различными компонентами.
4. Охарактеризуйте два подхода к физическому хранению
отношений.
5. Приведите структуру страницы при организации хранения
по строкам и дайте ее характеристику.
6. Охарактеризуйте подход к организации индексов в базах
данных с использованием техники B-деревьев.
7. Охарактеризуйте подход к организации индексов в базах
данных с использованием техники хэширования.
8. Дайте понятие журнальной и служебной информации в
базе данных и охарактеризуйте порядок их ведения.