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

Question

У нас есть три объекта, называемые Product, ProductType и ProductCategory.

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

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

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

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

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

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

Как бы вы эту модель?

Answer 1

продукта PRODUCT_TYPE

• PRODUCT_TYPE_ID (рк)
• PRODUCT_TYPE_DESCRIPTION

PRODUCT_CATEGORY

• PRODUCT_CATEGORY_ID (рк)
• PRODUCT_TYPE_ID (FK к PRODUCT_TYPE.PRODUCT_TYPE_ID)
• PRODUCT_CATEGORY_DESCRIPTION

ПРОДУКТ

• PRODUCT_ID (рк)
• PRODUCT_TYPE_ID (FK к PRODUCT_TYPE.PRODUCT_TYPE_ID)

PRODUCT_CATEGORY_MAP

• PRODUCT_ID (рк, Д к PRODUCT.PRODUCT_ID)
• PRODUCT_CATEGORY_ID (рк, Д к PRODUCT_CATEGORY.PRODUCT_CATEGORY_ID)
• PRODUCT_TYPE_ID (рк, Д к обоим PRODUCT.PRODUCT_TYPE_IDиPRODUCT_CATEGORY.PRODUCT_TYPE_ID)

Answer 2

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

Прояснение: Ваше заявление «Продукт имеет ProductType и может содержать много категорий продуктов» противоречит вашему описанию. Продукт может иметь только одну категорию продуктов (Fiction, Jazz), которая основана на ProductType (Book, Music).

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

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

Link to Product Classification

Я не понимаю, о необходимости «карту» таблицы.

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

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

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

Link to Two Possible Models

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

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

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

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