yamaxim По какому принципу Вы проектируете логическую модель базы?
А на кой фик она вообще нужна )))

В принципе физ. и лог. модель - это одни и те же яйца, только с разных сторон.
Лог. модель в большинстве случаев один в один накладывается на физическую (за исключением быть может кросс-таблиц).
Более объемно прописываются связи. Если связь "Сотрудник-Отдел" в физ. модели ты просто указываешь как один-ко-многим, то в лог. модели ты еще должен указывать с каждой стороны характер связи, например со стороны сущности Сотрудник ставим "работает в", а со стороны Отдела - "имеет в штате".
Нас тоже в инсте пытали такими вещами, пробовал я этот подход потом на практике, но пришел к выводу что кроме дополнительного геммороя от лог. модели никакой пользы, вся картина прекрасно видна на физике. ИМХО конечно...

Проба сил№То есть, все что объеденяет несколько сущностей это процесс.
нууу, это несколько спорное утверждение

Выкладывай, люблю аллегории :))

BrigadeFuhrer

неверно, будет 3 таблицы и 3 сущности форма договора, договор с сотрудником, сотрудник.
cущность - это прежде всего объект из бизнес-процесса, из реального мира.
в реальном мире есть только две сущности - это договор(бумажка), и сотрудник(человек) подписавший эту бумажку.
Что вы понимаете под сущностями "форма договора" и "договор с сотрудником"?
в логической модели эти две сущности связываются отношением многие-ко-многим, т.е. один человек может подписать несколько бумажек, в то же время одна бумажка может быть подписана нескольким людьми.
Третья таблица появляется уже на физическом уровне, только потому что иным способом реализовать связь M:M не получится

BrigadeFuhrerреальный мир. Рыба договора в ворде - это реальный мир? по твоей логике - нет.
Какая рыба? Где автор упоминал что ему нужна рыба?
Я согласен, в мире есть много интересных и полезных вещей: рыба, птица, тапочки, деревья, целлюлозный комбинат на озере Байкал, в получают бумагу, на которой печатаются договора, которые подписывают сотрудники, но вы же не собираетесь все это втискивать в модель
Автор по моему четко ограничил ее границы: сотрудники и договора

Проба сил№
Есть табуретка, которая обладает своей совокупностью свойств, которые можно описать в куче таблиц. Типа: Вес, материал, количество ножек, етс. Есть пол, обладающий тоже огромным количеством свойств. Табуретка, стоящая на полу учувствует в процессе «стояние на полу».
В реляционной базе этот процесс описывается связями многие ко многим (таблица с количеством ножек с таблицей фактуры пола, етс). Количество связей зависит от необходимой детализации процесса. В общем случае все просто.
Но при усложнении возникает две (основные) проблемы.
1. Садясь на табуретку, я участвую в процессе «сидения на табуретке», а взаимодействую с полом посредством процесса «табуретка».
2. Проблемы с уровнем детализации. Пол может изменить наклон (к примеру, если это пол поезда) и сев на табуретку клиент навернется. Один раз навернувшись куча проехтировщиков тратит кучу ресурсов на учет данного фактора. Я не знаю, что хужее…
Честно признаться, я мало что понял,но думаю если какой-то принцип в одном случае работает, а в другом нет, или его нужно за уши притягивать, то это уже не принцип, а частный случай.

И еще, если уж лезть под кожу, как может быть связь табуретка-пол многие-ко-многим?
Если на одном полу стоит несколько табуреток - это я понимаю!
А как может табуретка стоять на нескольких полах?