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

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

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

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

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

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

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

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

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

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

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

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

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

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

Индексирование

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

Для повышения производительности реляционные СУБД используют специальные объекты, называемые индексами. Индекссодержит набор записей из двух элементов: {значение ключевого поля;указатель на соответствующую запись в таблице}. Индекс упорядочен по значению ключевого поля, что позволяет быстро находить нужные значения. Для оптимизации поиска в индексах используются специальные алгоритмы. Упорядоченный индекс можно просматривать во много раз быстрее, чем саму неупорядоченную таблицу. Фактически индексная структура является «оглавлением» таблицы. В таблице 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	Попов В. М.	Бизнес-план инвестиционного проекта

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

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

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

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

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

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