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

Question

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

Вот дизайн у меня есть:

(1) Я хочу, чтобы все мои «продукт» s иметь тип блока ассоциированной с количеством. Блоки являются как «каждый», «Нога», «Галлон», и т.д., так что между количеством и блоком, вы бы что-то вроде:

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

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

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

Та же проблема с «FeeTypes», потому что не все «Продукт» будут иметь сборы.

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

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

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

Answer 1

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

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

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

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