Semaphore На первый взгляд обе схемы равноценны. Но обратите внимание, что в первой схеме в передаче может участвовать только один материал, а во второй схеме может возникнуть коллизия, поскольку можно связать операцию производящую один материал с операцией, которая потребляет совсем другой материал. То есть, запись в таблице передач может быть абсурдна. В первом случае такая возможность исключена, поскольку поле материалов одно и то же для обоих внешних ключей.
Это не единственная проблема, решаемая с помощью составных ключей.
Да-да, помню эту вашу страсть к составным первичным ключам, которые якобы решают дополнительные проблемы корректности данных в БД. При этом вы отвергаете решения с проверкой в триггере и утверждаете, что ваше решение как минимум не хуже.
Берусь показать, что в данном случае ваше решение не только не лучше решения с проверкой в триггере, но и потенциально опаснее его.
Пусть в вашей БД есть вот примерно такие данные
Пусть в PASSINGS есть запись
OP_SRC=26 OP_DST=7 MAT_NO=20

Теперь представим редактирование этой записи, а именно — смену производящей операции на другую (типа ошиблись при вводе, надо исправить). Например, надо ошибочный внешний ключ (OP_SRC=26 MAT_NO=20) сменить на правильный (OP_SRC=28 MAT_NO=20) . Чтобы редактирование происходило корректно, надо чтобы при смене любой из операций материал оставался одинаковым для обеих операций. Если при редактировании допустить ошибку, что произойдет? Если попытаться FK (OP_SRC=26 MAT_NO=20) заменить на (OP_SRC=27 MAT_NO=100) , то оба варианта, и ваш на ключах, и «наш» на триггере, обнаружат ошибку и отвергнут попытку изменения, т.к. не существует (OP_DST=7 MAT_NO=100) .
А вот если ошибиться так: присвоить FK (OP_SRC=25 MAT_NO=17) ? Вариант на триггере может установить ошибку, т.к. два FK после редактирования будут ссылаться на записи с разными MAT_NO. А вот ваш вариант на «суперключе» ошибки не заметит, т.к. неправильный FK (OP_SRC=25 MAT_NO=17) «перетрет» общее значение MAT_NO на 17, а пара (OP_ DST =7 MAT_NO=17) существует.

SemaphoreЧто сие означает: "дополнительные проблемы корректности"?
А то, что первичные ключи по определению обязаны обеспечивать только уникальность записей в таблице, а внешние - ссылочную целостность. Как естественные, так и суррогатные, как простые, так и составные ключи эти задачи решают. Какие-либо другие задачи PK и FK решать не обязаны. По определению. Точка. Поэтому ваши хитроумные пересекающиеся ключи есть трюк , с помощью которого вы пытаетесь решить дополнительные задачи корректности данных.

SemaphoreВы исходите из того, что меняется сразу пара значений. А на каком основании?
Опаньки! По существу аргументы на нашлись? ОК. Отвечу. Пара значений меняется потому, что это одно целое - внешний ключ. В принципе, этого уже достаточно, но добавлю, что странно будет выглядеть интерфейс, не позволяющий выбирать и присваивать внешний ключ целиком. А интерфейс, позволяющий выбирать и присваивать куски составного внешнего ключа вообще будет выглядеть по-идиотски.
SemaphoreОбъясните, пожалуйста, почему Ваша схема запрещает выполнять корректное (во всех смыслах) действие. И почему Вы ставите это ей в заслугу?
Да вы просто молодец! Действие, по определению обявленное ошибочным, вы называете корректным во всех смыслах. До чего люди не доходят, чтобы не признавать своих ошибок!
Дальнейшее участие в дискусии считаю бессмысленным. Всего доброго.