9. Многозначные зависимости

В ходе проектирования БД выявлен один тип зависимости - многозначная зависимость. Многозначные зависимости выявляет проблемы и избыточностью данных.

Отделение – Сотрудник – Клиент

N_отдела	ФИО_сотрудника	ФИО_клиента
011	Кот	Чижик
012	Крот	Лебедев
011	Кот	Гусев
012	Крот	Тупик

В данном отношении имеются многозначные зависимости типа один ко многим (1:N).

1:N

N_отдела – ФИО_клиента

1:N

N_отдела – ФИО_сотрудника

Если для каждого атрибута A имеется набор атрибутов B и C. Хотя атрибут B и C не зависят друг от друга.

Многозначная зависимость A -> B A -> C .

Многозначная зависимость подразделяется на тривиальную и нетривиальную зависимости. Многозначная зависимость A и B, определенных на некотором отношении R, называется тривиальной, если атрибут B является подмножеством атрибут A. В противном случае тривиальная зависимость является не тривиальной.

10. 4–ая нормальная форма

Отношение находится в 4-ой НФ, если оно удовлетворяет НФ БК и не содержит многозначных нетривиальных зависимостей.

Отделение – Сотрудник (N_отделения, ФИО_сотрудника)

Отделение – Клиент (N_отделения, ФИО_клиента)

Бывают случаи, когда необходимо выполнять декомпозицию на более чем два отношения. В этом случае необходимо учитывать зависимость соединения. Зависимость соединения - это свойство декомпозиции, которая вызывает генерацию ложных строк при обратном соединении декомпозированных отношений. Что бы не возникало зависимостей соединения, необходимо отношение приводить к 5-ой НФ.

11. 5–ая нормальная форма

Отношение в 5-ой НФ – это отношение без зависимостей соединения .

Например: Объект – Мебель – Поставщик

N_объекта	Мебель	N_поставщика
31	Стол	P1
31	Стул	P2
52	Стул	P3
52	Кровать	P1

Для того, что бы отношение удовлетворяло 5-ой НФ, необходимо его разбить на следующие отношения:

Объект – Мебель (N_объекта, Мебель)

Поставщик – Мебель (N_поставщика, Мебель)

Объекта - Поставщик (N_объекта, N_поставщика )

Методология проектирования бд

1. Основные понятия.

2. Методология концептуального проектирования.

3. Методология логического проектирования.

4. Методология физического проектирования.

1. Основные понятия.

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

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

1. концептуальное проектирование

2. логическое проектирование

3. физическое проектирование

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

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

Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.

В целом процедура проектирования БД будет включать следующие этапы:

1. Создание концептуальной модели данных, исходя из представлений о предметной области, каждого из пользователей. Шаги:

   1. определение типов сущности;

   2. определение типов связей;

   3. определение атрибутов и связывание их с типами сущностей и связей;

   4. определение доменов атрибутов;

   5. определение атрибутов, являющихся потенциальными и первичными ключами;

   6. создание диаграмм “сущность ­– связь”;

   7. обсуждение локальной концептуальной модели с конечным пользователем.

2. Построение и проверка локальной логической модели данных на основе представления.

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

   2. определение наборов отношений, исходя из структур локальной логической модели данных;

   3. проверка модели с помощью правил нормализации;

   4. проверка модели в отношении транзакции пользователя;

   5. создание диаграмм “сущность – связь”;

   6. определение требований поддержки целостности данных;

   7. обсуждение локальной логической модели с конечным пользователем;

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

   1. слияние локальных и логических моделей в единую модель;

   2. проверка глобальной логической модели;

   3. проверка возможности расширения проблемы в будущем;

   4. создание окончательного варианта диаграммы “сущность – связь”;

   5. обсуждение глобальной логической модели с конечным пользователем;

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

   1. создание основных таблиц в среде СУБД;

   2. реализация бизнес-правил предприятия среди СУБД.

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

   1. анализ транзакций;

   2. выбор файловой структуры;

   3. определение вторичных индексов;

   4. контроль за избыточностью данных;

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

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

   1. разработка пользовательских представлений;

   2. определение прав доступа к данным;

Этапы 4, 5, 6 – это физическое проектирование данных и ориентировано на реляционные СУБД.