В целом процедура разработки включает следующие этапы:

     Концептуальное  проектирование базы данных

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

       Логическое  проектирование базы данных (для реляционной  модели)

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

       Физическое  проектирование базы данных (с использованием реляционной СУБД)

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

     Концептуальное  и логическое проектирование базы данных включает три основных этапа. Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представлений о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей. [6, С.99]

     На  втором этапе локальные концептуальные модели данных преобразуются в локальные логические модели данных (для реляционной модели данных), состоящие из ER-диаграммы, реляционной схемы и сопроводительной документации. Затем корректность логических моделей данных проверяется с помощью правил нормализации. Нормализация представляет собой эффективное средство, позволяющее убедиться в структурной согласованности, логической целостности и минимальной избыточности принятой модели данных. Дополнительно модель данных проверяется с целью выявления возможности осуществления транзакций, которые будут выполняться пользователями создаваемого приложения. Все эти проверки позволяют получить необходимую уверенность в том, что принятая модель данных является вполне приемлемой. По завершении этапа 2 каждая локальная логическая модель данных при необходимости может применяться для подготовки прототипов реализаций базы данных, предназначенных для отдельных типов пользователей приложения. [6, С.110]

     На  третьем этапе выполняется объединение  локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей). Глобальная логическая модель проверяется по такому же принципу, как и локальные модели; это позволяет убедиться в том, что ее структура является правильной и поддерживает все необходимые транзакции. Этот этап обычно требуется, если приложение состоит более чем из одного представления. [6, С.200]

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

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

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

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

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

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

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

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

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

     Физическое  проектирование базы данных предусматривает  принятие разработчиком окончательного решения о способах реализации создаваемой  базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать определенной корректировки логической модели данных. [7, С.189]

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

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

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

• Представление Branch, состоящее из пользовательских представлений таких типов пользователей, как Director и Manager.
• Представление Staff, состоящее из пользовательских представлений таких типов пользователей, как Supervisor и Assistant.

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

• типы сущностей;
• типы связей;
• атрибуты и домены атрибутов;
• первичные ключи;
• альтернативные ключи;
• ограничения целостности;

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

• Определение типов сущностей.
• Определение типов связей.
• Определение атрибутов и связывание их с типами сущностей и связей.
• Определение доменов атрибутов.
• Определение атрибутов, являющихся потенциальными и первичными ключами.
• Обоснование необходимости использования понятий расширенного моделирования (необязательный этап).
• Проверка модели на отсутствие избыточности,
• Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.
• Обсуждение локальных концептуальных моделей данных с конечными пользователями. [8, С.178]

     Первый  этап создания локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель (см. раздел 11.1). Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного и прилагательного (например, "табельный номер", "фамилия работника", "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата", "количество комнат"). Затем среди них выбираются самые значимые объекты (категории работников, направления деятельности) или важные концепции и исключаются все существительные, которые просто определяют другие объекты. Например, такие свойства, как "табельный номер" и "фамилия работника", могут быть объединены в сводном объекте под названием "работник" (staff), тогда как свойства "номер объекта недвижимости", "адрес объекта недвижимости", "арендная плата" и "количество комнат" можно объединить в сущности под названием "объект недвижимости" (PropertyForRent). [9, С.112]