NextManТовар классифицируется по Типу, и по Классу. И Тип, и Класс классифицируются Видом продукции.
Тип продукции и Класс продукции - независимы. Поэтому разные сущности.

В для сущности Товар - Тип и Класс должны относиться к одному Виду...NextManТовар классифицируется по Типу, и по Классу. И Тип, и Класс классифицируются Видом продукции.
Тип продукции и Класс продукции - независимы. Поэтому разные сущности.
И чем такой вариант не устраивает ? Насколько понимаю, это похоже на первый вариант этого поста . Хотя он выглядит несколько избыточным, но только потому, что избегаете составных ключей. Если бы ID, в таблицах "Тип товара" и "Класс товара", были уникальными только в пределах класса, то это была бы вполне естественная схема, без проявления какой бы то ни было денормализации. Можно притвориться, что всё так и есть, а уникальность идентификаторов типа и класса считать дополнительным бонусом :) В обмен получаете контроль ссылочной целостности средствами СУБД.
Второй предложенный вариант , с промежуточной таблицей "КлассоТип", в которой будут зафиксированы сочетания классов и типов товаров, на мой взгляд, несколько экзотичен и не менее избыточен, чем первый. Да и логика модификации данных в таком варианте будет несколько сложнее. Возможно, такой вариант имеет право на жизнь в каких-либо ситуациях, но в данном случае, я бы его избегал.
Еще один вариант, это добавить CHECK CONSTRAINT к таблице "Товар", в котором с помощью функции проверялись бы совпадение видов для типов и классов. Не то чтобы он сильно плох, но мне кажется, что было бы правильнее, если бы контроль ссылочной целостности проходил всё-таки с использованием FOREIGN KEY, а не CHECK.

NextManА по какой логике модифицировать (редактировать) связи таблички Товар с табличками Тип и Класс?Возможно не понимаю проблемы. Зачем и как Вы собираетесь редактировать связи ? Чтобы изменить принадлежность товара к другому типу или классу просто меняете его на другое, подходящее по виду. Можете одновременно поменять тип и класс, один UPDATE, естественно с совпадением вида товара.

NextManИли менять принадлежность конкретных записей Тип и Класс к другому Виду?
Изменю отношение Типа и, если этот Тип использоваатлся в како-либо Товаре, сразу же FK-ограничения выстрелят, и будет мне головная боль...Так, собственно, ради этого схема и предлагалась, чтобы обеспечить ограничения стандартными механизмами СУБД. Для товара невозможно поменять вид только у типа или только класса, только одновременно(они же должны принадлежать одному и тому же виду). Поэтому очевидна следующая логика:
Создается новый тип, относящийся к другому виду.

Если не существует соответствующего класса такого же вида, то он тоже создается.

Изменяются одновременно, одним UPDATE, все три соответствующих поля в таблице товаров

Если старый тип старого вида более не нужен, то он удаляется.

Если старый класс старого вида более не нужен, то он удаляется.
Естественно, все эти операции рекомендуется делать единой транзакцией.

NextManПожалуй, что тут действительно лучше КлассоТип вводить...Тут получаем типичную ситуацию многозначной зависимости, т.е., нарушения 4НФ. Вы будете вынуждены делать групповые операции, охватывающие все комбинации данного типа с его классами, а то один и тот же тип будет принадлежать, как минимум, к паре видов и, как минимум, один класс "переедет" с типом в новый вид и также может сработать нарушение FK. При смене вида класса история аналогична, но уже относительно типа. В общем, этот путь, в данной ситуации, IMHO, глубоко порочен. Прежде чем пойти по нему, просто прикиньте все ситуации, может даже стоит обрисовать их на бумаге. Увидите, что не всё так радужно, как могло показаться с первого взгляда.