vadiminfoКот МатроскинЭто как раз проще разрулить тем, что для элементов связующей таблицы (во всяком случае - для ключевых полей) не определена операция "изменение" - только "добавление" и "удаление". Действительно, что логически понимается под "связь банка и человека изменилась" - слабо понятно. "Связь с одним банком перестала действовать, связь с другим банком - начала действовать" - это да, понятно.
С одной стороны в БД всегда как "изменение" присуще. Как там м почему меняются связи в БД зависит от реализации проги. Зачем мне проетировщику БД думать как пишет прогу проггер. Он поменял в проге ид банка и человов массово, а другой части проги ему надо знать в каком каждый был до изменения. У меня есть ID и я легко отвечу на этот вопрос. Мое дело предоставлять требуемую инфу как можно проще, а не говорить ему как программировать.
146% вам с программистом еще аналитика не хватает, чтобы разобрался с требованиями историчности и версионности.

В первом приближении можно завести признак неактуальности связи и timestamp.

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

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

vadiminfoНи "аналитик", ни "требованиями историчности и версионности." здесь ни при чем.
Вопрос о том, есть польза или нет от того, чтобы было просто ответить на вопрос какая запись меняется в ходе "изменения" полей. А то что это запись интерпретируется как связь - просто частный случай. А так без разницы вообще про что таблица.
А в ходе позапрошлого изменения? А как восстановить картину на 23 часа 11 ноября 2014 года?

vadiminfoможет оказаться, что в коде программы после изменения изменяемых полей, нужно найти какие записи менялись, что поменять дугие поля этой таблицы
жуть какая :)

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

вот вопрос необходимости суррогатного ПК в таблице, необходимой только для реализации связи m:n, нмв дело вкуса - везде делаем, ну и здесь сделаем; или ни в одной такой таблице не делаем

если связь соответствует какой-то сущности, однозначно следует создать суррогатный ПК

если в планах репликация между серверами, однозначно следует создать суррогатный ПК (плюс озаботиться пулами значений)