Индексирование. Физическое проектирование

Физическое проектирование

Главными вопросами физического проектирования являются оптимизация времени выполнения основных запросов к базе данных и обеспечение безопасности данных.

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

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

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

Словарь данных

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

В словаре данных обычно отражены следующие сведения:

– имена таблиц, количество столбцов в каждой таблице, описание столбцов: тип данных, размер поля, является ли столбец ключевым;

– ограничения целостности, наложенные на связанные таблицы;

– сведения о доступе отдельных пользователей к таблицам на выполнение определенных операций с таблицами: выборка, модификация, удаление (безопасность данных);

– описание пользовательских представлений (запросов) и доменов, определяемых пользователями.

При любом пользовательском обращении к данным СУБД обращается к словарю данных, определяет наличие затребованных элементов (таблиц, записей, полей), проверяет права доступа и соответствие запрошенной операции ограничениям целостности.

Таким образом, управление базой данных в реляционных СУБД осуществляется через словарь данных.

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

Для повышения производительности реляционные СУБД используют специальные объекты, называемые индексами. Индекс содержит набор записей из двух элементов: { значение ключевого поля; указатель на соответствующую запись в таблице }. Индекс упорядочен по значению ключевого поля, что позволяет быстро находить нужные значения. Для оптимизации поиска в индексах используются специальные алгоритмы. Упорядоченный индекс можно просматривать во много раз быстрее, чем саму неупорядоченную таблицу. Фактически индексная структура является «оглавлением» таблицы. В таблице 7.5. приведен индекс к таблице КНИГА и записи самой таблицы.

Таблица 7.5 Схема индексирования
Индекс		Таблица КНИГА
ISBN-код		ISBN-код	Автор	Наименование
5-272-00046-3		966-03-1257-1	Глушаков С.В.	Базы данных. Учебный курс
5-279-02346-9		5-272-00046-3	Мелихова Л.	Энциклопедия Интернет
…			…
966-03-1257-1		5-279-02346-9	Попов В. М.	Бизнес-план инвестиционного проекта

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

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

Так как обработка целых чисел производится значительно быстрее, чем текстовых данных, целесообразно в качестве ключевых полей (атрибутов) применять числовые коды, например, код товара, номер заказа и т. п.

Если в информационной системе предполагается часто выполнять поиск по полям, не входящим в первичный ключ, можно задать дополнительные индексы для этих полей. Например, для таблицы КНИГА можно провести индексирование записей по полю Раздел литературы. В этом случае ускоряется выполнение всех запросов, связанных с поиском книг определенного раздела.

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

В нашем примере для таблицы ЗАКАЗ СУБД автоматически создаст индекс для первичного ключа Код заказа. Также целесообразно создать индексы для внешних ключей Код покупателя, Тип доставки, Код курьера. Если известно, что будет часто проводиться поиск заказов по дате, то целесообразно построить дополнительный индекс по полю Дата заказа.

Разделение таблиц

Разделение означает разбиение таблицы на части в целях ускорения работы системы. Разделение таблиц может быть горизонтальным или вертикальным.

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

Например, при длительной эксплуатации информационной системы Интернет-магазина в таблицах ЗАКАЗ и КОРЗИНА ЗАКАЗА будет накоплено огромное число записей, что значительно ухудшит производительность системы. Конечно, информация обо всех заказах важна с точки зрения анализа работы нашего магазина и ведения денежной и другой документации и должна храниться длительное время. Однако для текущей работы отдела заказов достаточно хранить информацию лишь о невыполненных или недавно выполненных заказах.

В этом случае целесообразно создать новые связанные между собой таблицы АРХИВ ЗАКАЗОВ и АРХИВ КОРЗИН ЗАКАЗОВ, в которые нужно переписать все записи о заказах, произведенных месяц назад или ранее, кроме записей о невыполненных заказах. Основная работа будет вестись с таблицами ЗАКАЗ и КОРЗИНА ЗАКАЗА, содержащими относительно небольшой объем записей. Операцию перезаписи в архивные таблицы надо будет проводить ежемесячно.

При проведении горизонтального разделения таблицы следует изменить запросы, относящиеся ко всем записям. Теперь они должны включать операцию объединения двух таблиц. Например, при установлении количества заказов, доставленных по Москве за последний год, поиск должен проводиться по временно создаваемой таблице, полученной в результате объединения таблиц ЗАКАЗ и АРХИВ ЗАКАЗОВ. Такие запросы будут выполняться значительно медленнее, чем поиск в каждой таблице в отдельности. Разделение таблиц оправдано, если запросы к записям архивных таблиц будут выполняться значительно реже, чем к записям основных таблиц.

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

Например, таблицу, содержащую информацию о сотрудниках:

СОТРУДНИК (Табельный номер, Фамилия, Имя, Отчество, Должность, Отдел, Дата рождения, Дата приема на работу, Образование, Специальность, Семейное положение, Количество детей)

можно разделить на две:

СОТРУДНИК (Табельный номер, Фамилия, Имя, Отчество, Должность, Отдел);

СОТРУДНИК-АНКЕТА (Табельный номер, Дата рождения, Дата приема на работу, Образование, Специальность, Семейное положение, Количество детей).

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

Таблицы при вертикальном разделении связаны связью «один-к-одному» по полю первичного ключа исходной таблицы. При запросе полных сведений происходит объединение таблиц по первичному ключу, что замедляет выборку.

Дата добавления: 2014-12-29