Вопрос реляционного моделирования - PullRequest
Новая
       31

Вопрос реляционного моделирования

1 голос
/ 30 октября 2010

У нас есть три сущности с именами Product, ProductType и ProductCategory.

Давайте представим, что у нас есть три вида ProductType: Book, Music и Video.

У нас есть три разных ProductCategory для Book: Fiction, Novel, Technical.

Три разных ProductCategory для Music:Rock, Jazz, Pop.

И у нас есть три разных ProductCategory для Video: Fiction, Comic, Drama.

A Product имеет ProductType и может иметь много ProductCategory.Но его ProductCategory должен совпадать с ProductType.Например, если ProductType равно Book, он может принимать Fiction, Novel и Technical как ProductCategory.

Возможно ли смоделировать эту схему сэто ограничение (т.е. ProductCategory для Product должно совпадать с ProductType) без использования кода приложения или триггеров и т. д. - просто с использованием таблиц, внешних ключей и т. д.

Как быВы моделируете это?

Ответы [ 2 ]

3 голосов
/ 30 октября 2010

1001 * продукт PRODUCT_TYPE * PRODUCT_TYPE_ID (pk) PRODUCT_TYPE_DESCRIPTION PRODUCT_CATEGORY

  • PRODUCT_CATEGORY_ID (pk)
  • PRODUCT_TYPE_ID (от fk до PRODUCT_TYPE.PRODUCT_TYPE_ID)
  • PRODUCT_CATEGORY_DESCRIPTION

ПРОДУКТ

  • PRODUCT_ID (pk)
  • PRODUCT_TYPE_ID (от fk до PRODUCT_TYPE.PRODUCT_TYPE_ID)

PRODUCT_CATEGORY_MAP

  • PRODUCT_ID (pk, fk to PRODUCT.PRODUCT_ID)
  • PRODUCT_CATEGORY_ID (от pk, fk до PRODUCT_CATEGORY.PRODUCT_CATEGORY_ID)
  • PRODUCT_TYPE_ID (pk, fk на PRODUCT.PRODUCT_TYPE_ID и PRODUCT_CATEGORY.PRODUCT_TYPE_ID)
2 голосов
/ 30 октября 2010

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

Одно уточнение: Ваше утверждение "Продукт имеет тип продукта и может иметь много категорий продукта" противоречит вашему описанию. Продукт может иметь только одну категорию продукта (художественная литература, джаз), основанную на типе продукта (книга, музыка).

Здесь нет необходимости в суррогатных ключах (могут быть и другие требования к моделированию), они здесь просто избыточны. Для простых классификаций, подобных этой, CHAR (1) или (2) намного лучше, удобен для пользователя и разработчика (когда вы сканируете вывод, вы знаете, что «B» означает «Книга» и т. Д.), А также быстрее, чем любое числовое ключ (кроме, конечно, tinyint).

Здесь нет «хитрости», это прямая нормализация, которая поддерживает определенные вами правила.

Ссылка на классификацию продуктов

Я не понимаю необходимости таблицы "map".

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

Ответы на комментарии

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

Ссылка на две возможные модели

Кажется, что "стесненность" вашего администратора и администратора в отношении пользователей очень слабая. Пожалуйста, выберите один из следующих вариантов, чтобы мы могли продолжить и закрыть вопрос:

  1. Product.ProductType устанавливается администратором. Это позволяет администратору и пользователям выбирать любые допустимые категории продуктов для Product.ProductType для любого использования.

  2. Для каждого продукта администратор выбирает ProductType и подмножество ProductCategories (из списка ProductCategories, которые действительны для Product.ProductType). Пользователи могут , затем использовать только категории продуктов , выбранные администратором для Продукта , для любого использования.

Ответьте пожалуйста, а потом я опубликую окончательную версию.

...