yamaximВот если бы я понимал как строить логическую - то так бы и делал. А пока для меня понятнее более приземленные вещи: Сотрудник - это сотрудник со своими данными, а справочник Городов - это Код и наименование и тд. Поэтому я и хочу разобраться как строить логическую модель.Логическая модель - это данные с точки зрения бизнес-логики.

Например, Сотрудники связаны с Договорами , в которых они учавствуют. Связь - многие ко многим.

Физическая модель учитывает средства и возможности конкретной БД.
Например, в распространённых СУБД связь многие ко многим не поддерживается. Поэтому делают таблицу СотрудникДоговор

BrigadeFuhrer автор
Логическая модель - это данные с точки зрения бизнес-логики.

Например, Сотрудники связаны с Договорами, в которых они учавствуют. Связь - многие ко многим.

Физическая модель учитывает средства и возможности конкретной БД.
Например, в распространённых СУБД связь многие ко многим не поддерживается. Поэтому делают таблицу СотрудникДоговор


неверно, будет 3 таблицы и 3 сущности форма договора, договор с сотрудником, сотрудник.
Это как раз зависит от бизнес-логики.

Говоря "Сотрудники связаны с Договорами, в которых они учавствуют" я имел в виду любое участие в договоре, например:
"носил на подпись"
"составлял"
"является стороной договора"
"визировал"
и т.п., т.е. все люди, которые хоть как-то то причастны к договору, у которых можно про него что-то поспрашивать.

Если нужно отражать эти события как реальные сущности реального мира, то нужно делать отдельную сущность.

А если не нужно и достаточно только факта участия, то в логической модели можно это описать как связь сущностей сотрудник и договор типа "многие ко многим".

PS.
Ну и, собственно, таблиц в этом случае получится не обязательно три. Ведь мы вправе по логической модели данных построить нереляционную физическую модель? Скажем, схему xml-документа? :-)