Проектирование баз данных

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

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

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

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

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

     Многие  современные СУБД содержат визуальные средства (нередко входящие в состав утилит администрирования), позволяющие  создать новую схему базы данных или просмотреть уже имеющуюся. Существуют также и утилиты (поставляемые отдельно от СУБД), позволяющие разрабатывать или редактировать метаданные. Однако в последнее время все более популярными становятся CASE-средства (Computer-Aided System Engineering). Существует несколько типов CASE-средств, но для создания баз данных чаще всего используются те из них, что содержат в своем составе инструменты для создания диаграмм «сущность-связь» и проектирования данных.

     Ниже  мы рассмотрим процесс проектирования данных с помощью подобных инструментов.

2. Составные части процесса проектирования данных

     Процесс проектирования данных можно условно  разделить на два этапа: логическое моделирование и физическое проектирование. Результатом первого из них является так называемая логическая (или концептуальная) модель данных, выражаемая обычно диаграммой «сущность-связь» или ER (Entity-Relationship) диаграммой, которая представлена в одной из стандартных нотаций, принятых для отображения подобных диаграмм. Результатом второго этапа является готовая база данных либо DDL-скрипт для ее создания.

3. Логическое моделирование

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

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

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

     Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент  размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей.

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

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

Рис. 1. Пример связи между сущностями логической модели

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

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

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

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

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

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

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

     В случае реляционной модели данных под  этим подразумевается следующее:

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

     Этапы концептуального и логического  проектирования больших систем следует  отделять от этапов физического проектирования. На это есть несколько причин.

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

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

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

1. Перенос глобальной логической модели данных в среду целевой СУБД.
2. Проектирование основных отношений.
3. Разработка способов получения производных данных.
4. Реализация ограничений предметной области.
5. Проектирование физического представления базы данных.
6. Анализ транзакций.
7. Выбор файловой структуры.
8. Определение индексов.
9. Определение требований к дисковой памяти.
10. Проектирование пользовательских представлений.
11. Разработка механизмов защиты.
12. Обоснование необходимости введения контролируемой избыточности.
13. Текущий контроль и настройка операционной системы.