Продолжая страдать на тему избыточности

Хорошо, с вопросом, как быть, если зольдат может быть поставлен в десант, а может быть оставлен на базе, разобрались. Корявенько, но.
А вот теперь попробуем чуть иначе поставить задачу.
Снова у нас есть Base, таблица икскомовских баз.
Снова у нас есть LandingCraft, таблица десантных транспортов с FK из неё на Base.
Снова у нас есть Trooper, который должен быть приписан к базе, и при этом может быть или не быть поставлен в десант на определённый транспорт.
Но теперь предположим, что у нас есть ещё BaseStation, таблица боевых постов на самой базе, из неё, разумеется, тоже есть FK на Base.
И пусть зольдат не так, что, как в прошлой постановке, может быть приписан к десанту, а может не приписан. Пусть у него будет ненулябельная обязанность на случай десанта и ненулябельная обязанность на случай вторжения. То есть у Trooper есть FK на LandingCraft и FK на BaseStation.
И вот как можно (если можно) на уровне структуры БД (не констрейнтов и тем более не бизнес-логики приложения) избежать ситуации, когда один зольдат ссылается на десантный корабль одной базы и боевой пост другой базы? В голову ничего не приходит. Так или иначе, зольдат имеет два транзитивных отношения к базе, которые чисто теоретически могут не соответствовать одно другому.
Инвертировать отношение к базе тоже нельзя: если мы сделаем, чтобы, наоборот, зольдат ссылался на базу, а таблица крафтов и таблица постов брали свою приписку к базе из зольдата, мы всё равно напоремся на ситуацию, когда у одного объекта больше одного отношения к базе, только теперь в другую сторону: на уровне структуры БД тогда ничего не мешает в один десант вбякать зольдат с разных баз.
Даже не вполне понимаю, какая нормальная форма тут могла бы помочь, если бы могла (возможно, как раз потому что выше третьей без шпаргалки не знаю).