Cheerful CalfКатегории - торты, диваны
Цвета - коричневый, красный
Тип покрытия - кожа, шоколадная глазурь, велюр
Продукт - Торт "Нежность", диван "Серерио"
Покрытия - шоколадная глазурь коричневая, Кожа коричневая, велюр красный

надо ввести ограничение чтобы при вводе заказа диван не покрыли шоколадной глазурью. Какие есть более правильные варианты с точки зрения нормальной бд?Ты ждешь полную схему связей ? Или что ? Первоначальная схема больше задаёт вопросов, чем даёт ответов. Варианты уже были предложены. Тебе только надо определиться, что от чего зависит. Есть предположение, что типы покрытий должны зависеть от категории товаров. Но ! Неизвестна арность отношения, так как непонятно по каким признакам будет происходить категоризация. Пока ты с этим не определишься, можно будет долго обсуждать сферического коня в вакууме. Как на схемах Сахавата...

Cheerful CalfВсе! не надо додумывать что там у меня еще есть и может быть.Слишком часто в подобных ситуациях появлялся рояль из кустов со словами "А вот тут ещё..."

Cheerful Calfдаже таблицу "ограничения" нарисовал, где тип покрытия писобачивается именно к категории.Так вариант уже были предложены. Чтобы ограничение работало, то либо категория должна зависеть от типа покрытия, либо тип покрытия от категории. У тебя этой зависимости на первоначальной схеме нет. Вот один из вариантов:
КатегорияIDName
ПродуктКатегория_IDIDName
PK (Категория_ID, ID); FK (Категория_ID) => Категория(ID)

Тип покрытияIDКатегория_IDName
PK (Категория_ID, ID);FK (Категория_ID) => Категория(ID)

ПокрытияКатегория_IDIDТип покрытия_IDName
PK (Категория_ID, ID);FK (Категория_ID, Тип покрытия_ID) => Тип покрытия(Категория_ID, Тип покрытия_ID)

ОрдерСтрокаIDКатегория_IDПродукт_IDПокрытие_IDName
PK (неважно, например - ID);
FK1 (Категория_ID, Продукт_ID) => Продукт(Категория_ID, ID)
FK2 (Категория_ID, Покрытие_ID) => Покрытие(Категория_ID, ID)

Где-то так. В результате, принадлежность Продукт и Покрытия только одной категории будет диктоваться самой схемой данных.

softwarerChAТолько если диван и стул будут в разных категориях. Я именно об этом. То, что категории строятся "не по покрытиям" - имхо очевидно.Я где-то написал обратное ? Но типы покрытия зависят от категории, если верить ТСCheerful CalfChAЕсть предположение, что типы покрытий должны зависеть от категории товаров.опять не понятно - почему это только предположение ?? я четко сказал, что так и должно быть, даже таблицу "ограничения" нарисовал, где тип покрытия писобачивается именно к категории.Хотя я допускаю, что он не совсем понял смысла моего предположения. Вы, фактически, предложили сделать то же самое, что он и так уже сделал в стартовом топике. Т.е., просто ввести дополнительный справочник всевозможных допустимых комбинаций. Что он не сделал, так этоsoftwarerТип покрытия связать с категорией (многие ко многим). Из продуктов ссылаться на эту связку .Но смысл и достаточность такой связи неочевидны, так как она, на мой взгляд, никак
softwarerChA не помешает сделать связь между шоколадной глазурью и мебелью. Помешает. Эксперт по предметной области, который должен был бы внести в настройки такую пару.Как вы собираетесь проверять эту настройку, кроме использования знаний новой сущности "эксперта" ? Тригерами или процедурами ? Если "нет", то как она может помешать в строку ордера добавить "диван" в качестве продукта и в качестве покрытия - "синюю шоколадную глазурь" обычным insert-ом ? Если "да", то и первоначального варианта ТС вполне достаточно для подобного рода проверки.
Не то чтобы проверка в триггерах или процедурах как-то задевала мои религиозные чувства, но лично я предпочитаю по возможности реализовать ограничения декларативно и по возможности именно тем способом, который для этого формально предназначен.
Cheerful Calfа где цвета?Предполагал, что это очевидно. Добавьте таблицу цвета и установите связь(FK) с таблицей покрытий, как это было изображено в Вашем первом топике. Просто она не имеет отношения к озвученной Вами проблеме.
P.S. Хотя мне кажется, было бы разумнее вынести ссылку на цвет покрытия в строку ордера. Но не настаиваю, Вам виднее.
P.P.S. На всякий: связи могут устанавливаться не только с помощью PK, но и UQ. Поэтому вполне возможно заменить в моем примере PK, на UQ. А роль PK будет традиционно выполнять ID.

Cheerful Calfили так и предлогалось??Похоже всё-таки не въехали. Во-первых, связь от "Категория" к "Покрытия" это не моё, в ней нет смысла, так как они уже связаны через "Типы покрытия". Кроме того, от "Тип покрытия" к "Покрытия" связь насколько понимаю "1 ко многим", так же как и от "Продукты" и "Покрытия" к "ОрдерСтрока", причем в последнем случае это обычные одиночные, а не двойные непонятные связи.
В общем, ещё раз, но уже на MS SQL DDL:

P.S. Не понимаю, о каких-таких "циклах" вы здесь толкуете, в предлагаемой схеме они отсутствуют. Здесь обычный однонаправленный граф.

softwarerChAто как она может помешать в строку ордера добавить "диван" в качестве продукта и в качестве покрытия - "синюю шоколадную глазурь" обычным insert-ом ?
Помешает очень легко - отсутствием поля, куда можно было бы внести такую информацию. В строку ордера добавляется "диван артикул такой-то", согласны? Это ссылка на таблицу продуктов (внешний ключ). В таблице продуктов у "диван артикул такой-то" стоит ссылка на развязку (которая у ТС названа "ограничения"). В этих ограничениях эксперт вводит: категория=диван, покрытие=велюр. И до тех пор, пока эксперт не введёт категория=диван, покрытие=глазурь, ни один insert в ордера и в продукты ничего такого сформировать не сможет.А куда это поле денется-то ? Или предлагаете в строке ордера из комбинации (Продукт, Покрытие) выбросить Покрытие ? Если "нет", то в строку ордера благополучно вставляем диван с шоколадной глазурью, так как Покрытие не контролируется явно заданными ограничениями. Если "да", то где связь между конкретным продуктом и конкретным покрытием ? В предлагаемой Вами схеме в продуктах я вижу только ссылку на связь категорий и типов покрытий .
В общем, не мешало бы как-нибудь более внятно проиллюстрировать все необходимые изменения первоначальной схемы ТС. Тогда можно будет разговаривать более предметно, а не ждать очередных кроликов из шляпы.

softwarerВелюр может быть покрытием для кресла или дивана, может - для куртки. Ваша схема требует в этом случае ввести в справочник два велюраЛично я не знаю, какие варианты могут встречаться у ТС, при первой же попытке прояснить подробности, он настоятельно попросил не додумывать за него, а решить конкретную задачу. Поэтому фантазировать на тему, что может быть, а чего нет, я не берусь. Впрочем, если понадобиться рассматривать множественные связи между категориями и типами покрытий, то не составит большого труда слегка расширить и перекроить предлагаемую схему, чтобы ограничения по-прежнему контролировались самой схемой данных.

softwarerЯ бы предпочёл, чтобы смотрели написанное мное, а не фантазировали "вместо меня".Я тоже, но люди такие фантазеры, все время норовят прочитать между строчек. Какая жалость, что нет телепатии...

softwarerChAИли предлагаете в строке ордера из комбинации (Продукт, Покрытие) выбросить Покрытие ? Да, безусловно. Это вообще.. странная мысль иметь их рядом, поскольку Покрытие - очевидный атрибут Продукта.Т.е., очередной кролик, кроме добавления связи надо еще и поле выбросить из строки ордера. А без фантазии было так простоsoftwarerТип покрытия связать с категорией (многие ко многим). Из продуктов ссылаться на эту связку.IMHO, очевидность является прерогативой ТС и он тоже сильно просил за него не фантазировать. Вот если судить по его первоначальной схеме, то покрытие не является атрибутом продукта.

softwarerChAто где связь между конкретным продуктом и конкретным покрытием ? Согласен, забыл оговорить этот момент. Я пока не вижу смысла в сущности "конкретное покрытие". По изложенному в неё кроме типа покрытия входит только цвет, и имхо этого мало; удобнее вставить цвет в продукты.Ну вот как тут можно было обойтись только тем, что Вы пишете ? Там выбросили, здесь вообще всё не так, начинает напоминать допрос партизана. Может было бы проще нарисовать схему данных или DDL в качестве иллюстрации, дабы не оставлять место фантазиям читателям ?

softwarerChAЛично я не знаю, какие варианты могут встречаться у ТС,
Я тоже. Поэтому я отметил общий недостаток схемы, нигде не сказав "её нельзя применять". Даже если у ТС встречается такой вариант, дублирование может в его ситуации быть более удачным ходом. Просто об этом надо подумать заранее.Абсолютно здравый подход, ноCheerful Calfне надо додумывать что там у меня еще есть и может быть.