Методология физического проектирования базы данных
В ходе третьей и последней фазы процесса разработки базы данных разработчик должен принять решение о том, как преобразовать логический проект базы данных (т.е. совокупность сущностей, атрибутов, связей и установленных ограничений) в проект физической базы данных, реализуемой в среде выбранной целевой СУБД. Поскольку многие аспекты физического проектирования баз данных существенно зависят от типа выбранной целевой СУБД, возможно существование более чем одного способа реализации любого заданного элемента базы данных. Совершенно очевидно, что разработчик должен хорошо знать функциональные возможности выбранной целевой СУБД, а также четко понимать все ее достоинства и недостатки, что позволит ему принимать обоснованные решения при выборе того или иного метода реализации базы данных. Кроме того, в каждом конкретном случае разработчик должен уметь выбрать оптимальную стратегию размещения и хранения данных.
Фаза, предшествующая физическому проектированию, называется фазой логического проектирования. Результаты ее выполнения в значительной степени независимы от особенной физической реализации проекта. При логическом проектировании не принимаются во внимание специфические функциональные возможности целевой базы данных и прикладных программ, однако учитываются особенности выбранной модели хранения данных. Результатом логического проектирования являются глобальная логическая модель данных и комплект описывающей ее сопроводительной документации, включающий, в частности, словарь данных и реляционную схему. В совокупности эти результаты являются исходной информацией для фазы физического проектирования базы данных и предоставляют ее разработчику все необходимое для принятия решений, направленных на достижение максимальной эффективности создаваемого проекта.
Образно говоря, при логическом проектировании разработчик сосредоточивается на том, что надо сделать, тогда, как при физическом проектировании он ищет способ, как это сделать. В каждом случае требуется наличие различных навыков. Так, специалист по физическому проектированию баз данных должен ясно представлять, как та или иная СУБД функционирует в компьютерной системе, а также хорошо знать все функциональные возможности целевой СУБД. Поскольку функциональные возможности различных СУБД достаточно сильно отличаются друг от друга, физическое проектирование всегда тесно связано с особенностями конкретной выбранной системы. Однако этап физического проектирования базы данных не является совершенно изолированным от других – как правило, между логическим и физическим проектированием имеется постоянная обратная связь, часто охватывающая и разработку пользовательских приложений. Например, решения, принятые на этапе физического проектирования с целью повышения производительности системы, могут влиять на структуру ее логической схемы.
Физическое проектирование состоит из таких этапов:
- Перенос глобальной логической модели данных в среду целевой СУБД.
- Проектирование таблиц базы данных в среде целевой СУБД.
- Реализация бизнес-правил предприятия в среде целевой СУБД.
- Проектирование физического представления базы данных.
- Анализ транзакций.
- Выбор файловой структуры.
- Определение вторичных индексов.
- Анализ необходимости ввода контролируемой избыточности данных.
- Определение требований к дисковой памяти.
- Разработка механизмов защиты.
- Разработка пользовательских представлений (видов).
- Определение прав доступа.
- Организация мониторинга и настройка функционирования системы.
Физическое проектирование базы данных представляет собой процесс подготовки описания реализации этой базы во вторичной памяти. Создается описание таблиц базы данных и выбранных для них структур хранения, а также методов доступа, которые будут использоваться для эффективного доступа к данным. Высококачественный проект реализации таблиц базы данных может быть создан только разработчиками, хорошо знающими все функциональные возможности выбранной целевой СУБД.
Первый этап (этап 4) физического проектирования базы данных состоит в преобразовании глобальной логической модели данных в форму, которая может быть реализована в среде целевой реляционной СУБД.
Следующий этап (этап 5) предусматривает выбор структуры файлов и методов доступа, которые будут применены при реализации каждой из таблиц базы данных. Как правило, каждая СУБД предоставляет несколько альтернативных вариантов схемы хранения данных. Исключением являются лишь настольные СУБД для платформы IBM РС, в которых чаще всего используется фиксированная схема хранения информации. Выполнение этого этапа предусматривает проведение анализа транзакций, которые будут выполняться в базе данных. Результаты анализа используются для выбора оптимальной файловой организации таблиц. С целью оптимизации производительности системы могут быть приняты решения о создании вторичных индексов или внесении в данные контролируемой избыточности. Завершается данный этап проведением оценки объема дискового пространства, необходимого для размещения создаваемой базы данных. Существует несколько показателей, которые могут быть использованы для оценки достигнутой эффективности:
- Пропускная способность транзакций. Этот показатель представляет собой количество транзакций, которые могут быть обработаны за заданный интервал времени. В некоторых системах - например, в службах резервирования авиабилетов - обеспечение высокой пропускной способности транзакций является решающим фактором успеха всей системы.
- Время ответа. Характеризует временной промежуток, необходимый для выполнения одной транзакции.
- Дисковая память. Этот показатель представляет собой объем дискового пространства, необходимого для размещения файлов базы данных. Разработчик должен стремиться минимизировать объем используемой дисковой памяти.
Однако ни один из этих факторов не является самодостаточным. Как правило, разработчик вынужден жертвовать одним из показателей ради другого, чтобы достичь оптимального баланса.
Последовательные файлы являются оптимальным вариантом формата файла для таблиц, в которые планируется внести большое количество записей. Их использование малоэффективно, если требуется выборочный доступ только к отдельным записям файла. Хешированные файлы эффективны в тех случаях, если данные выбираются по точному соответствию, заданному значению ключа. Этот формат файлов не подходит для выборки данных по шаблону с символами подстановки, по диапазону значений ключа, по неполному значению ключа или по значению атрибута, отличного от ключа перемешивания.
Индексно-последовательные (ISAM) файлы представляют собой более гибкую структуру, чем хешированные файлы. Они эффективны при выборке данных по заданному значению ключа, по шаблону с символами подстановки, по диапазону ключей или по части ключа. Однако индекс ISАМ-файлов статичен и создается непосредственно при создании самого файла. В результате производительность выборки данных из ISАМ-файла уменьшается по мере внесения изменений в его данные. Обновление данных файла также вызывает нарушение правильной последовательности ключей, поэтому выборка данных в по рядке главного ключа все более замедляется. Последние две проблемы разрешаются при использовании файлов со структурой двоичного дерева, имеющих динамически формируемый индекс. Однако, в отличие от файлов со структурой B+-Tree, ISАМ-файлы благодаря статичности своего индекса могут успешно использоваться для организации конкурентного доступа. Если уровень обновления данных в таблице относительно низок, а ее размеры не слишком велики или слишком малы, индексно-последовательная организация будет для нее оптимальным решением, поскольку она имеет на один уровень индекса ниже, чем файлы со структурой двоичных деревьев.
Вторичные индексы представляют собой механизм определения дополнительных ключей для таблиц базы данных, которые могут использоваться для повышения эффективности выборки данных. Однако наличие вторичного индекса создает дополнительную нагрузку при внесении изменений в данные, что должно учитываться при принятии решения о создании этих индексов.
В некоторых случаях может потребоваться отказаться от преимуществ, достигаемых при использовании полностью нормализованных отношений, в пользу обеспечения более высокого уровня производительности системы. Подобные решения следует принимать только тогда, когда удовлетворить требования к производительности системы любыми иными способами невозможно. Практика показывает, что денормализация части отношений может оказаться подходящим методом, если уровень производительности системы неудовлетворителен, данные в таблицах базы данных обновляются относительно редко, а количество выполняемых запросов весьма велико.
База данных представляет собой ценный корпоративный ресурс, поэтому организация ее защиты является одной из важнейших задач разработчиков. Назначение следующего этапа физического проектирования (этап 6) состоит в реализации тех требований к защите данных, которые были установлены еще на этапе логического проектирования базы данных. Используемые решения могут включать создание пользовательских представлений (видов) и организацию механизма контроля над доступом пользователей к данным, реализуемого с помощью средств языка SQL.
Каждому пользователю базы данных администратор этой базы присваивает идентификатор пользователя. Как правило, этот идентификатор защищается личным паролем - по вполне очевидным причинам. Любой SQL-оператор, который выполняется в среде СУБД, выполняется от имени определенного пользователя. Идентификатор пользователя используется для определения того, на какие объекты базы данных этот пользователь может ссылаться, а также какие именно операции он может выполнять с этими объектами. Любой объект, создаваемый средствами языка SQL, имеет своего владельца. Владелец указывается его идентификатором пользователя. Владелец объекта является единственной персоной, которая знает о существовании данного объекта и имеет право выполнять над ним любые операции.
Привилегиями (или правами доступа) называются действия, которые пользователю разрешено выполнять в отношении конкретной таблицы или представления. Например, привилегия SELECT разрешает пользователю выбирать информацию из соответствующей таблицы. Когда пользователь создает таблицу с помощью оператора CREATE TABLE, он автоматически назначается владельцем созданного объект и получает полный набор прав доступа к нему. Все остальные пользователи не имеют никаких прав доступа к созданному им объекту. Для предоставления прочим пользователям возможности доступа к новой таблице, ее владелец должен явно предоставить им необходимые привилегии с помощью оператора GRANT. Если в операторе GRANT будет указана фраза ЮТН GRANT OPTION, то пользователю-получателю дополнительно будет предоставлено право передавать данный тип привилегии другим пользователям по его собственному усмотрению. Любая предоставленная ранее привилегия может быть отменена с помощью оператора REVOKE.
Когда пользователь создает представление с помощью оператора CREATE VIEW, он автоматически становится его владельцем, но это вовсе не означает, что он получает полный набор прав доступа к нему. Чтобы создать новое представление, пользователь должен иметь привилегию SELECT для всех таблиц, входящих в его состав. Однако любые другие типы привилегий для вновь созданного представления пользователь получит только в том случае, если он имеет их для всех таблиц, входящих в состав данного представления.
Последний этап (этап 7) физического проектирования базы данных состоит в проведении непрерывного контроля за функционированием созданной системы и выполнением настройки, способствующей достижению ее максимальной производительности. Большинство коммерческих СУБД предоставляет в распоряжение администратора базы данных набор утилит, предназначенных для наблюдения за функционированием системы и ее настройки.