допустим есть у нас три сущности

Подразделение ID_Подразд
Человек ID_Сотрудник
Автомобиль ID_CAR

а мы являемся отделом по распределению автомобилей. Мы интегрированны в общую систему ЗАВОДА.
Причем у нас действует такое правило что сотрудники одного отдела ездят на машине одинаковой марки, но они могут перекрасить машину впоследствии в любой цвет, но изначально для всех машина черного цвета.

В итоге нужно чтобы в любой момент можно было вытянуть из базы, что в таком-то подразделении - ЧЕРНАЯ ВОЛГА (Например), но Сотрудник Иванов уже ездит на КРАСНОЙ ВОЛГЕ, а сотрудник Петров на БЕЛОЙ ВОЛГЕ

Теперь о том как это будет представлено в базе:

мой вариант..

Соединительная таблица
где или ID_Подразд или ID_Сотрудник равно NULL
ID_CAR NOT nULL, и с единственным сурогатным первичным ключом..
и DATE - дата выдачи в подразделении этих ЧЕРНЫХ ВОЛГ..

Правильно? или есть какиенить еще выходы из ситуации?

Сразу скажу - это абстрактная модель.. ничего неимеет общего с реальностью.
Просто возникла мысль, можно ли так организовывать соединение..

to softwarer
Попытаюсь развернуть задачу.

Проблема в том что автомобиль это не просто автомобиль - а набор деталей.
изначально каждый автомобиль состоит из 100 деталей (условно)
детали беруца из справочника, также есть справочник тип детали
в итоге деталь у нас - это таблица:

ID_Детали АВТО PK
ID_Детали FK
ID_Типа детали FK

посколько некоторые автомобили состоят из одинаковых деталей (например колесо в количестве 4 шт) то используем соединительную таблицу между сущностью Автомобиль(ID, Название, Год выпуска) и сущностью Деталь_Автомобиля

вид таблицы (ID_Детали_АВТО PKFK, ID_АВТОМОБИЛЯ PKFK, Колличество деталей)

Есть сущность Отдел и Сотрудник между ними связь Many-to-Many
между сотрудником и автомобилем Many-to-Many
Сотрудник может изменять набор деталей, но в подразделении должно всегда числиться базовая версия с базовым набором деталей.

Есть у меня такой ещё вариант, если сотрудников в отделе 10 человек, то внося авто в систему, мы делаем 10+1 копию одного и тогоже автомобиля причем 10 ID-шников фигурируют в соединительной таблице между Сотрудником и Авто, а один ID идет как внешний ключ в сущность отдел

Решил не создавать новую тему.. с предыдущими догадками вроде разрулил..

НО одна вещь не очень ясна:
Как реализовать одновременно понятие Базовый Автомобиль. и измененный автомобиль?
Пояснение:
Скомплектованый автомобиль - сущность, и с выделением нового автомобиля, мы добавляем ещё одну запись о автомобили с учетом количества всех его составляющих.. т.е. просто копируем базовую версию прекрепленную к отделу, имееющую более позднее время создание..
возможно ошибки при проектировании.. подскажите пожалуйста.

PS Прилагаю ER-модель.. возможно станет более понятна задумка

нужно не только цвет .. а впринципе изменение деталей..

И в любой момент получить:
a) базовую конфигурацию для отдела
б) текущую конф. у сотрудника отдела
в) то какая кофигурация у данного сотрудника была базовой (проверяеца по году выдачи)

Спасибо всем за ответы но проблма разрешенной так и не осталась..

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

А вот теперь кажеться решилась :)
т.е. вообще не связывать машину с отделом.. ни с сотрудником.. а связывать с Сотрудник-Отдела
Копируем набор данных о машине на всех сотрудников отдела.
это и есть базовый автомобиль на сотрудников этого отдела.
при изменениях накапливать историю путем предков\потомков..
в любой момент можно получить базовый конфиг авто просто перейдя на корень дерева - он у всех сотрудников отдела одинаков..
и легко получить текущую ситуацию перейдя на конечный элемент дерева - у всех сотрудников конец свой..

Вот и всё.. Как вам такой выход?