Третья нормальная форма — Основы реляционных баз данных

Текущая структура:

users

id	first_name	last_name
2	Сергей	Иванов
3	Иван	Петров
5	Виктор	Сидоров

goods

id	name
50	утюг
30	кофеварка
20	телевизор
33	ноутбук

order_items

id	user_id	address	good_id	price
8	2	Москва, ул. Промышленная	50	1000.00
2	3	Самара, ул. Энгельса	30	5000.00
7	5	Омск, ул. Дворцовая	50	1000.00
4	5	Омск, ул. Дворцовая	20	6500.00
9	2	Москва, ул. Матросова	33	20000.00
6	2	Москва, ул. Матросова	33	20000.00

Третья нормальная форма, так же как и вторая, включает в себя два пункта:

Таблица должна быть во второй нормальной форме
Все колонки в таблице зависят от первичного ключа и не зависят друг от друга

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

goods

id	name	price
50	утюг	1000.00
30	кофеварка	5000.00
20	телевизор	6500.00
33	ноутбук	20000.00

И наша таблица приобретает такой вид:

order_items

id	user_id	address	good_id
8	2	Москва, ул. Промышленная	50
2	3	Самара, ул. Энгельса	30
7	5	Омск, ул. Дворцовая	50
4	5	Омск, ул. Дворцовая	20
9	2	Москва, ул. Матросова	33
6	2	Москва, ул. Матросова	33

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

Это значит, что цена товара должна копироваться в таблицу order_items. Но и в таблице goods она тоже нужна. В первую очередь для вывода на сайте на витрине.

А что насчет адреса? Адрес тоже зависит от пользователя, но более сложным образом. Один пользователь может иметь несколько адресов (от нуля до бесконечности). Учитывая все что мы говорили про нормальные формы, перенести адреса в таблицу пользователей нельзя. Мы не можем хранить несколько значений в одной колонке и не можем дублировать записи, так как нарушится уникальность первичного ключа.

Правильное решение – завести под адреса свою собственную таблицу. В этой таблице адрес будет связан с пользователем, а вместо поля address в таблице заказов появится поле user_address_id.

Так, по крайней мере, мы бы поступили в теории. На практике же, неизвестно нужно ли выносить адрес или нет, все зависит от конкретной бизнес-логики конкретного приложения.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Об обучении на Хекслете

Статья «Как учиться и справляться с негативными мыслями»
Статья «Ловушки обучения»
Статья «Сложные простые задачи по программированию»
Урок «Как эффективно учиться на Хекслете»
Вебинар «Как самостоятельно учиться»

Для полного доступа к курсу нужен базовый план

Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.

Получить доступ

130

курсов

900

упражнений

2000+

часов теории

3200

тестов

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.