Источник вашего замешательства в том, что вы видите ключи в нескольких местах и думаете, что это избыточность.Дело в том, что при нормализации нужно игнорировать псевдо-избыточность в ключах.Это не настоящая избыточность, а просто повторение информации.Повторение существует по причине, а именно для указания взаимосвязи между сущностями.
Если у вас есть таблица доступных начинки, т. Е. Первичный ключ topping_id, то таблица, которая сообщает вам, какая добавка включенакакая пицца 3NF.Если у вас нет таблицы поиска для начинки, и вместо этого вы добавили имя верха в таблицу составления пиццы, то я думаю, что многие люди скажут, что вы нарушаете 2NF.Они были бы правы, если топовые имена не неизменны.Если имена надстроек оказываются неизменными, то есть аргумент, чтобы сказать, что имя надписи является вашим первичным ключом к неявной таблице надписей.Тем не менее, в качестве наилучшей практики полезно иметь бессмысленные ключи в целом - если только вы не можете найти действительно вескую причину для использования значимого ключа в каждом конкретном случае.Поэтому избегайте использования верхнего названия в таблице составления пиццы.
Поскольку вы часто можете заказать более одной пиццы за раз (я вырезал код и у меня два сына-подростка, поэтому я говорю по опыту), ваша схема, вероятно, должна бытьвдоль этих линий:
ORDER:
order_id (PK)
, date_taken
, deliver_to (or FK to a CUSTOMER table if you're being ambitious)
PIZZA:
pizza_id (PK)
, order_id (FK)
, size
TOPPING:
topping_id (PK)
, topping_name
PIZZA_COMPOSITION:
, pizza_id (PK, FK)
, topping_id (PK, FK)
, quantity (My kids insist on double cheese)
, coverage (One likes half plain cheese...)
Эта схема 3NF, потому что единственное, что появляется в более чем одном месте, это внешний ключ.