SvDevЭто вы сейчас думаете, что вам не нужна история, или что её можно просто удалить, через некоторое время окажется по-другому.
Думать лучше не о том, как нажать поменьше кнопок при составлении модели, а о том, чтобы получить лучший результат.
Почему результат получится хуже, уже достаточно всякой информации приведено, имхо.

Мне пофиг, сколько кнопок нажимать - я не ленивый. Мне важно, чтобы логическая модель была максимально корректной и соответствующей предметной области. Минимальное "ручное вмешательство" в физическую модель избавляет меня от ошибок проектирования.

Вариантность данных во времени - серьезное бизнес-требование. Если его моделировать каждый раз "на всякий случай", OLTP-стсиемы требовали бы в 10 раз больше дискового пространства.

Однако для меня не очевиден Ваш постулат о том, что моя модель помешает накоплению истории.
Добавьте к 2-м полям составного ключа третье - типа "Дата окончания актуальности"... Есть и другие паттерны вариантности во времени, которые также не требуют суррогатного ключа с одним полем.

SvDev"Дата окончания актуальности" нельзя будет добавить в часть ключа, т.к. поле будет null-able, к тому же перестанут работать все DML (Например, delete будет удалять 2 записи, вместо одной, а select выбирать 2, вместо одной).

Я взрослый мальчик. И в проектировании БД не первый год. У меня в рукаве всегда есть паттерны, однозначно приводящие к успешному результату. Тот способ, что привёл в пример я, придуман не мной, но он как раз один из тех.
Достаточно полю EXPIRE_DATE, являющемуся частью композитного ПК, присваивать при создании новой записи значение "31/12/9999".

blkangelБлагодаря этой теме еще раз убедился в необходимости сурогатных ключей.
Если CASE настроен правильно, при формировании логической модели, в физическую никаких правок не надо.

Такого быть не может, как ничего идеального. :)
Иначе Вы потратите больше времени на настройку, чем на результат.
Приведу пример на модели со сделкой, в которой несколько участников.
Case-инструмент, скорее всего, сгенерирует FK для сделки типа
SUBJ_ID_1
SUBJ_ID_2
SUBJ_ID_3
SUBJ_ID_4
А вам по naming style положено называть
SUBJ_ID_CRED
SUBJ_ID_BORR
SUBJ_ID_GTEE
SUBJ_ID_GTOR
Так что придется вмешаться ручками. Можно, конечно, обзывать осмысленными именами referenses, и настроить CASE на использование части их имен в имени поля. Но найдутся и другие грабли несоответствия лог. модели и физ. модели.

blkangel,

Пример тиснул с какого-то обучающего слайда, поэтому там не видны атрибуты сущностей типа идентификаторов с кодом subj_id, deal_id ...

ОДнако в большинстве CASE-инструментов проектирования БД в логической модели FK и их поля не указываются.
Подразумевается, что они есть, раз есть relationship.
А вот при генерации физ.модели из логической, инструмент генерит и наименования полей для FK. И тут уж - как его настроишь :)