Нормальные формы ER- диаграмм

21

Первая нормальная форма

Каждый столбец в строке должен быть атомарным, т.е. столбец может содержать одно и только одно значение для заданной строки.

Каждая строка в таблице обязана содержать одинаковое количество столбцов. Учитывая обязательную атомарность столбцов, следует, что все строки в таблице должны иметь одинаковое количество значений.

Все строки в таблице, в общем, должны быть уникальны. Значения в столбцах могут дублироваться, но строки, взятые целиком — не могут.

23

рассмотрим пример таблицы с фильмами:

Здесь сразу видны два нарушения первой нормальной формы. В первой строке, в столбце release указаны два значения (для США и Австралии), что запрещено первым правилом. Исправить это можно, записав еще одну строку для фильма, но с другим значением release.

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

24

Вторая нормальная форма

Два правила второй нормальной формы говорят о том, что:

Таблица обязана соответствовать первой нормальной форме.

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

25

Пример

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

26

В таблице первичным ключем объявлены поля archSurname (фамилия архитектора) и title (название станции). Если таблица следует нормальной форме, то все поля, не входящие в первичный ключ, зависят от него. Итак, смотрим: archName (имя архитектора) зависит от archSurname, и это логично. Поле completedDate (дата сдачи станции в эксплуатацию) зависит от title (от ее названия), это тоже логично. Но имя архитектора совершенно не зависит от названия станции, а дата сдачи станции, в свою очередь, никак не зависит от имени архитектора. Следовательно, два поля таблицы не зависят от соответственных полей в первичном ключе и таблица не соответствует второй нормальной форме.

Как мы решим проблему? Достаточно грамотный выход — раскидать данные по двум таблицам: Stations и Architectors. При этом нам понадобится третья, связующая таблица (что, плюс ко всему, позволит присваивать один проект нескольким архитекторам). В результате у нас получаются три таблицы:

27

Теперь у нас нет независимых от первичного ключа полей, таблица соответствует второй нормальной форме.

28

Третья нормальная форма

Третья норма данных расширяет две предыдущие, неся в себе два правила:

Таблица должна соответствовать второй нормальной форме.

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

29

Пример – таблица автомобилей

30