- •Раздел 4. Проектирования бд
- •4.1. Метод нормальных форм
- •4.1.1. Цели проектирования реляционных бд
- •Возможность хранения всех необходимых данных в бд
- •Исключение избыточных данных.
- •Нормализация отношений.
- •Аномалии добавления (insert)
- •Аномалии обновления (update)
- •Аномалии удаления (delete)
- •4.1.2.Формирование исходного отношения. Функциональные зависимости (фз)
- •Существует 6 нормальных форм, на практике ограничиваются 4-мя. 1,2,3 нф и форма Бойса-Кодда (нфбк).
- •4.1.4. Рекомендации по разработке структур
- •4.2. Метод сущность - связь
- •4.2.1. Основные понятия метода
- •4.2.2. Этапы проектирования
- •Правила формирования отношений для 1:1
- •Правила формирования отношений для 1:м
- •Правила формирования отношений для м:м
- •4.2.3. Пример проектирования бд с использованием метода сущность связь
-
Нормализация отношений.
Для некоторых отношений важна проблема удаления и обновления, при которой может произойти потеря информации, поэтому необходимо обнаруживать такие отношения и нормализовать их. Э.Коддом эти проблемы были названы «аномалии обновления отношения».
Аномалиями называют такую ситуацию в таблицах, которая приводит к противоречиям либо усложняет обработку.
Список аномалий, которые могут встретиться:
-
Аномалия обновления.
-
Аномалия удаления.
-
Аномалия добавления.
-
Аномалия обновления проявляется в том, что изменение значения одного данного потребует просмотра всей таблицы и соответствующего изменения других записей. Изменив тел у Вагнера, надо просмотреть всю таб и внести изменения. (исходная таб.)
-
Аномалия удаления состоит в том, что при удалении некого данного может пропасть и другая информация не связанная с ним. Удалив номер тел Шеломова, мы потеряем сотрудника 102.
-
Аномалия добавления возникает в случаи, когда информацию в таблицу нельзя поместить до тех пор, пока она неполная или вставка новой записи требует просмотра таблицы. Т.е. при добавлении нового сотрудника необходимо внести данные и о завкафедры и о телефоне и проверить, что тел и фамилии завкафедрой совпадают.
На первом этапе проектирования создана однотабличная база данных.
Таблица 1 Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ
Н_СОТР |
ФАМ |
Н_ОТД |
ТЕЛ |
Н_ПРО |
ПРОЕКТ |
Н_ЗАДАН |
1 |
Иванов |
1 |
11-22-33 |
1 |
Космос |
1 |
1 |
Иванов |
1 |
11-22-33 |
2 |
Климат |
1 |
2 |
Петров |
1 |
11-22-33 |
1 |
Космос |
2 |
3 |
Сидорова |
2 |
33-22-11 |
1 |
Космос |
3 |
3 |
Сидорова |
2 |
33-22-11 |
2 |
Климат |
2 |
Даже одного взгляда на таблицу отношения СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ достаточно, чтобы увидеть, что данные хранятся в ней с большой избыточностью. Во многих строках повторяются фамилии сотрудников, номера телефонов, наименования проектов. Кроме того, в данном отношении хранятся вместе независимые друг от друга данные: данные о сотрудниках, об отделах, о проектах, о работах по проектам. Пока никаких действий с отношением не производится, это не страшно. Но как только состояние предметной области изменяется, то, при попытках соответствующим образом изменить состояние базы данных, возникает большое количество проблем.
Аномалии добавления (insert)
В отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ нельзя вставить данные о сотруднике, который пока не участвует ни в одном проекте. Действительно, если, например, во втором отделе появляется новый сотрудник, скажем, Пушников, и он пока не участвует ни в одном проекте, то мы должны вставить в отношение кортеж (4, Пушников, 2, 33-22-11, null, null, null). Это сделать невозможно, т.к. атрибут Н_ПРО (номер проекта) входит в состав потенциального ключа, и, следовательно, не может содержать null-значений.
Точно также нельзя вставить данные о проекте, над которым пока не работает ни один сотрудник.
Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и о проектах, и о работах по проекту).
Вывод - логическая модель данных неадекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.