12. Этапы проектирования.

Процесс проектирования базы данных – это процесс, допус­кающим возврат к предыдущим этапам для пересмотра ранее принятых ре­шений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER-типа с учетом всех сущностей и их связей.

1. Формирование набора предварительных отношений с указанием пред­полагаемого первичного ключа для каждого отношения и использованием диаграмм ER-типа.

3. Добавление неключевых атрибутов в отношения.

4. Приведение предварительных отношений к нормальной форме Бойса-Кодда, например, с помощью метода нормальных форм.

5. Пересмотр ER-диаграмм в следующих случаях:

• некоторые отношения не приводятся к нормальной форме Бойса-Кодда;

• некоторым атрибутам не находится логически обоснованных мест в пред­варительных отношениях.

После преобразования ER-диаграмм осуществляется повторное выполне­ние предыдущих этапов проектирования (возврат к этапу 1).

Одним из узловых этапов проектирования является этап формирования отношений. Рассмотрим процесс формирования предварительных отноше­ний, составляющих первичный вариант схемы БД.

В рассмотренных выше примерах связь ВЕДЕТ всегда соединяет две сущно­сти и поэтому является бинарной. Сформулированные ниже правила формиро­вания отношений из диаграмм ER-типа распространяются именно на бинарные связи. Поэтому, когда речь идет о связях, слово «бинарные» далее опускается.

13. Проблемы проектирования.

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

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

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

При проектировании структур данных для автоматизированных систем можно выделить 3 основных подхода:

1) сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений;

2) формулирование знаний о системе и требований к обработке данных, получение с помощью CASE-системы готовой схемы БД или даже готовой прикладной ИС;

3) структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Следует различать простое и избыточное дублирование данных. Наличие первого из них допускается в БД, а избыточное дублирование данных может приводить к проблемам при обработке данных.

Пример неизбыточного дублирования данных представляет собой отношение С (Т) с атрибутами «сотрудник» и «телефон». для сотрудников, находящихся в одном помещении, номера телефонов совпадают. Номер телефона 4328 встречается несколько раз, хотя для каждого служащего номер телефона уникален. поэтому ни один из номеров не является избыточным.

С_Т

Сотрудник	Телефон
Иванов	3721
Петров	4328
Егоров	4328
Сидоров	4328

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

С_Т_Н

Сотрудник	Телефон	Н_комн
Иванов	3721	109
Петров	4328	111
Егоров	4328	111
Сидоров	4328	111

Избыточное дублирование данных создает проблеиы при обработке кортежей отношения, названные Коддом «аномалиями обновления отношений».