Понимание роли ограничений внешнего ключа. Я правильно их использую?

Question

Мне нужна помощь в понимании применимости внешних ключей при настройке ограничений.Я понимаю, что роль установки внешних ключей состоит в том, чтобы предотвратить потерю данных, но я обнаружил желание поместить внешний ключ в дочерний элемент, что, кажется, нарушает закономерность.Не уверен, что я делаю это правильно, и хотел бы получить несколько советов, если у меня есть правильные ограничения.

Вот мой дизайн:

(1) Я хочу, чтобы у всех моих «продуктов» был тип единицы, связанный с количеством.Единицы измерения, такие как «каждый», «фут», «галлон» и т. Д., Поэтому между количеством и единицей у вас будет что-то вроде:

Количественная единица 5 галлонов

Я нехочу разрешить кучу сумасшедших юнитов, поэтому я установил это ограничение.Это в значительной степени относится к книге.

(2) Я также считаю, что не все продукты будут иметь «изображение», поэтому я поместил внешний ключ в таблицу «ProductImage», чтобы у меня не было «продукта»."с столбцом с пустой строкой, потому что я также пытаюсь" нормализовать "дизайн.

Та же проблема с" FeeTypes ", потому что не у всех" Продуктов "будут сборы.

Я чувствую вину за то, что нарушил шаблон наложения ограничения внешнего ключа на ребенка, а не на родителя.Я просто не могу обернуться вокруг того, что FeeType - родитель.В этом конфликте в логике у меня возникает вопрос.

Является ли мой дизайн правильным с точки зрения дизайна?Я все еще ограничиваю данные должным образом?Есть ли еще какая-то «роль» помимо предотвращения потерянных данных?

Заранее спасибо.

Answer 1

Здесь есть три случая (с точки зрения Product таблицы):

1. Отношение много-к-одному , например многие продукты имеют один и тот же тип единиц измерения - один тип единицы продукции.
   В этом случае внешний ключ должен находиться в таблице Product, ссылающейся на первичный ключ UnitType.UnitTypeID.
2. Отношение один-ко-многим , например один продукт может иметь несколько изображений - одно изображение может принадлежать только одному продукту
   В этом случае внешний ключ должен находиться в таблице ProductImages со ссылкой Product.ProductID.
3. отношение «многие ко многим» , например, любой продукт может иметь много категорий - любая категория может описывать множество продуктов
   В этом случае вам понадобится таблица соединений, содержащая пары ProductID / CategoryID, столбцы которых являются внешними ключами, ссылающимися на Product.ProductID и Category.CategoryID соответственно .

Итак, дизайн таблиц UnitType (случай 1.) и ProductImage (случай 2.) в порядке, но FeeType, вероятно, должен быть случай 1. и Category должен быть случай 3.

Кстати, было бы неплохо иметь NULL в столбце внешнего ключа; это не нарушит правила нормализации. Так, например, если с некоторыми продуктами не связаны сборы, вы можете указать NULL в столбце Product.FeeTypeID. Но вам нужно будет использовать внешнее объединение в своих запросах, чтобы гарантировать, что ни один продукт без каких-либо сборов не будет исключен из результатов.