ogienko_evДа, на программном уровне это можно легко обыграть, но меня волнует, как наложить ограничения именно на уровне бд.
Можно прямым и естественным образом. Добавьте в ProductParameters поле CategoryId. Сошлитесь из неё на Products по составному ключу (ProductId, CategoryId). По этому же составному ключу сошлитесь из ProductParameters на CategoryParameters. Единственно, таким образом Вы не сможете обыграть иерархию в категориях. Декларативные ограничения целостности в СУБД не позволяют проверять принадлежность ветке дерева.

Кроме того, существует хакерский путь, которым я пользуюсь в Oracle для того, чтобы декларативно реализовывать "забубенистые" ограничения, не выражаемые нормальными способами (например, вот такую ситуацию с деревом). Для этого я делаю materialized view с опцией refresh on commit. В условиях where я прописываю критерии отбора записей, нарушающих требуемое ограничение (то есть в Вашем случае view должно выдавать записи параметров, в которых категории не соответствуют продукту). А теперь фокус! В части select этого view я пишу что-нибудь типа raise_application_error('Параметр не из той категории!'). И вуаля! Как только меняются данные в одной из задетых таблиц - view пересчитывается, и если в нём появляется хотя бы одна запись - вылетает ошибка и данные не сохраняются. Красота!