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

Отправной точкой проводимого в этой главе обсуждения является глобальная логическая модель данных- и сопроводительная документация, созданные на втором и третьем этапах предлагаемой методологии проектирования баз данных (см. главу 8). Их создание начиналось с преобразования локальных концептуальных моделей данных (см, главу 7) в локальные логические модели данных, которые впоследствии использовались для разработки набора соответствующих отношений. Логические модели и представляющие их наборы отношений были проверены на соответствие требованиям правил нормализации (см. главу 6) и возможность выполнения необходимых транзакций. Этап логического проектирования базы данных завершался процедурой слияния локальных логических моделей данных, отражающих представления отдельных пользователей, в единую глобальную логическую модель данных предприятия.

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

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

В главе 12, "Пример разработки физического проекта базы данных", будет продемонстрировано практическое использование предлагаемой методологии физического проектирования баз данных на примере приложения DreamHome (раздел 1.7), реализуемого в среде целевой СУБД Microsoft Access.

9.1. Сравнение этапов логического и физического проектирования баз данных

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

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

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

9.2. Общий обзор методологии физического проектирования баз данных

В этой главе описываются следующие этапы физического проектирования баз данных.

Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.

Этап 4.1. Проектирование таблиц базы данных в среде целевой СУБД.

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.

Этап 5. Проектирование физического представления базы данных.

Этап 5.1. Анализ транзакций.

Этап 5.2. Выбор файловой структуры.

Этап 5.3. Определение вторичных индексов.

Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.

Этап 5.5. Определение требований к дисковой памяти.

Этап 6. Разработка механизмов защиты.

Этап 6.1. Разработка пользовательских представлений (видов).

Этап 6.2. Определение прав доступа.

Этап 7. Организация мониторинга и настройка функционирования системы.

Обсуждаемая нами методология физического проектирования баз данных включает четыре основных этапа. Концептуальное и логическое проектирование охватывает три первых этапа разработки баз данных, а физическое проектирование — этапы 4- 7. Этап 4 фазы физического проектирования включает разработку таблиц базы данных и установку необходимых ограничений целостности данных. В обоих случаях должны использоваться все доступные функциональные возможности целевой СУБД.

Этап 5 включает выбор схемы хранения данных и определение методов доступа к таблицам базы данных. Как правило, каждая СУБД предоставляет несколько альтернативных вариантов схемы хранения данных. Исключением являются лишь настольные СУБД для платформы IBM PC, в которых чаще всего используется фиксированная схема хранения информации, С точки. зрения пользователя организация внутренней структуры хранения помещенных в таблицы данных должна быть совершенно прозрачна — пользователь должен иметь возможность получать доступ к любой таблице и отдельным ее строкам без необходимости указания способа хранения этих данных. Это означает, что СУБД должна обеспечивать полную независимость физического хранения данных от их логической организации. Только в; этом случае внесение изменений в физическую организацию базы данных не окажет никакого влияния на работу пользователей (см. раздел 2.1.5). Отображение логической модели данных на структуру их физической организации определяется внутренней схемой базы данных (см. рис. 2.1). Разработчик должен предоставить детальные физические проекты базы данных как с точки зрения СУБД, так и с точки зрения операционной системы. В проекте реализации базы данных в СУБД разработчик должен определить структуры файлов, которые будут использоваться для представления каждой из таблиц. В проекте реализации базы данных в операционной системе разработчик должен указать расположение отдельных файлов и обеспечить необходимую их защиту. На пятом этапе также анализируется необходимость снижения уровня требований нормализации данных в логической модели, что может способствовать повышению общей производительности системы. Однако эти действия следует предпринимать только в случае реальной необходимости, поскольку введение в базу данных избыточности неизбежно вызовет появление проблем с поддержанием целостности данных. Мы можем порекомендовать читателю, прежде чем приступать к рассмотрению пятого этапа данной методологии, внимательно ознакомиться с приложением В, содержащим подробное описание схем организации файлов и структур хранения данных.

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

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