Этапы проектирования базы данных

Каждая информационная система в зависимости от ее назначения имеет дело с частью реального мира, которую принято называть предметной областью (ПО) системы. ПО может относится к любому типу организаций: банк, университет, завод, магазин и т.д.

Предметная область информационной системы представляет собой совокупность реальных объектов (сущностей), которые представляют интерес для пользователей. Объект (сущность) – предмет, процесс или явление, о котором собирается информация, необходимая для решения задачи, Объектом может быть человек, предмет, событие. Каждый объект характеризуется рядом основных свойств – атрибутов (поименованная характеристика объекта). Атрибут показывает, какя информация должна быть сохранена об объекте (Например, объект – клиент банка; атрибуты – номер счета, адрес, сумма вклада).

Важным этапом разработки любой информационной системы является проектирование – процесс разработки структуры БД в соответствии с требованиями заказчиков.

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

1) целостность базы данных – требование полноты и непротиворечивости данных;

2) многократное использование данных;

3) быстрый поиск и получение информации по запросам пользователей;

4) простота обновления данных;

5) уменьшение излишней избыточности данных;

6) защита данных от несанкционированного доступа, искажения и уничтожения.

Жизненный цикл БД (ЖЦБД) – это процесс проектирования, реализации и поддержки БД. ЖЦБД состоит из этапов:

Основные действия, выполняемые на каждом этапе жизненного цикла приложения базы данных:

Этап	Описание
Планирование разработки базы данных	Планирование наиболее эффективного способа реализации этапов жизненного цикла системы. Также проводится проверка осуществимости – предполагает подготовку отчетов по трем вопросам: - есть технология – необходимое оборудование и ПО для реализации запланированной БД (технологическая осуществимость); - имеются ли персонал, средства и эксперты для успешного осуществления плана создания БД (операционная осуществимость) - окупится ли запланированная база данных (экономическая осуществимость)
Определение требований к системе	Определение диапазона действий и границ приложения базы данных, состава его пользователей и областей применения, требования к оборудованию и ПО.
Сбор и анализ требований пользователей	Сбор и анализ требований пользователей из всех возможных областей применения. Сбор информации осуществляется для последующего создания основных пользовательских представлений. Собранная информация анализируется для определения требований, которые реализованы в разрабатываемом приложении базы данных. Эти требования описываются в документах – спецификации требований к новому приложению БД (технология структурного анализа и проектирования (SAD), диаграммы потоков данных (DFD) и графики "вход-процесс-выход" (HIPO). Для получения гарантий того, что составленный набор требований является полным и непротиворечивым, могут использоваться CASE-инструменты, предназначенные для автоматизированного проектирования и создания программ.
Проектирование базы данных	Полный цикл разработки включает концептуальное, логическое и физическое проектирование базы данных
Выбор целевой СУБД (необязательный этап)	Выбор наиболее подходящей СУБД для приложения базы данных
Разработка приложений	Определение пользовательского интерфейса и прикладных программ, которые используют и обрабатывают данные в базе данных
Создание прототипов (необязательный этап)	Создание рабочей модели приложения базы данных, которая позволяет разработчикам или пользователям представить и оценить окончательный вид и способы функционирования системы
Реализация	Создание внешнего, концептуального и внутреннего определений базы данных и прикладных программ
Преобразование и загрузка данных	Преобразование и загрузка данных (и прикладных программ) из старой системы в новую.
Тестирование	Приложение базы данных тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями
Эксплуатация и сопровождение	На этом этапе приложение базы данных считается полностью разработанным и реализованным. Впредь вся система будет находиться под постоянным наблюдением и соответствующим образом поддерживаться, В случае необходимости в функционирующее приложение могут вноситься изменения, отвечающие новым требованиям. Реализация этих изменений проводится посредством повторного выполнения некоторых из перечисленных выше этапов жизненного цикла

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

Сбор и анализ требований является предварительным этапом концептуального проектирования БД.

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

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

Цель этапа концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.

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

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

3. Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области.

4. Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения:

- имя атрибуту и его описание;

- тип и размерность значений;

- значение, принимаемое для атрибута по умолчанию (если такое является);

- может ли атрибут иметь Null-значения;

- является ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Например, атрибут «ФИО клиента» может состоять из простых атрибутов «Фамилия», «Имя», «Отчество», а может быть простым, содержащим единые значения. Если пользователь не нуждается в доступе к отдельным элементам «ФИО», то атрибут представляется как простой;

- является ли атрибут расчетным, и если это так, то как вычисляются его значения.

5. Определение значений атрибутов и их документирование. Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. Например, «Тип счета» может иметь только значений «депозитный», «текущий», «до востребования», «карт-счет». Обновляются записи словаря данных, относящихся к атрибутам, - в них заносятся имена наборов значений атрибутов.

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

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

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

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

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

1. Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.

2. Определение набора таблиц исходя из ER-модели. Для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Осуществляется формирование структуры таблиц. Устанавливаются связи между таблицами с помощью первичных и внешних ключей.

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

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

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

5. Определение требований поддержки целостности данных. Эти требования представляют собой ограничения, которые вводятся с целью предотвратить помещение в БД противоречивых данных. Должны быть рассмотрены следующие типы ограничений:

- обязательные данные. Выясняется, есть ли атрибуты, которые не могут иметь Null-значений;

- ограничения для значений атрибутов. Определяются допустимые значения для атрибутов;

- целостность сущностей. Она достигается, если первичный ключ не содержит Null-значений;

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

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

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

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

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

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

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

• разработка средств защиты создаваемой системы.

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

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

2. Проектирование основных отношений.

3. Разработка способов получения производных данных.

4. Реализация ограничений предметной области.

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

6. Анализ транзакций.

7. Выбор файловой структуры.

8. Определение индексов.

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

10. Проектирование пользовательских представлений.

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

12. Обоснование необходимости введения контролируемой избыточности.

13. Текущий контроль и настройка операционной системы.