Кто знает, помогите разобраться.

Введение в задачу.

автомобиль (а/м) может выполнять два вида работ:
постоянную, зависящую от цеха;
и заявочную, формируемую вновь каждый день.
Первый вид определяет назначенным а/м определенную работу.
Второй вид определяет произвольную, не формализуемую, и а/м для этой работы
заранее не известен.
Для хранения данных о выполнении всех работ используется таблицы:

выполнение работ по заявкам:
table factClaim(idClaim, iDept, idCar, ...)
PK = {idClaim}; idClaim = FK сущности planClaim
выполнение постоянных работ:
table factNeed(idNeed, idDept, idCar, ...)
PK = {idNeed, idDept, idCar};
idNeed = FK сущности needWork, idDept = FK сущности Dept, idCar = FK сущности Car

Для обоих видов работ выписывается путевой лист (п/л).
Общая часть п/л - таблица
wayBill(idTypeWork, idWork, idDept, idCar, ...)
PK = {idTypeWork, idWork, idDept, idCar}
idWork имеет значение либо factClaim.idClaim, либо factNeed.idNeed.
idTypeWork - так называемый дискриминатор, определяющий смысл idWork.

Таблицы factClaim и factNeed не содержат никаких параметров работы, три точки
- это несущественные атрибуты. Все параметры - в таблице wayBill.

Меня смущает, что в общей части (wayBill), кажется, неверно выбраны общие атрибуты
для двух видов работ. Если исключить из wayBill.PK атрибут idDept, невозможно
установить вид постоянных работ (idNeed). А на существущей схеме, для заявочных
работ значение idDept не нужно.
Проблемы бы не было в случае уникальности ключа заявочных работ (idClaim) внутри
одного цеха, - тогда factClaim.PK = {idClaim, idDept}. Но это - искуственное
требование.

Вопрос: является ли предлагаемая схема правильной ?

to Слон: спасибо, а то я закомплексовал.

"наводят на подозрения повторения idCar & idDept в каждой таблице."
Уточню:
1. существует список необходимых работ, как:
- привезти продукты (1)
- привезти сырьё А (2)
- привезти сырьё Б (3)
- увезти сырьё В (4)
2. Эти работы назначены цехам:
- цех1: работы 1 (это столовая 1)
- цех2: работы 1 (это столовая 2)
- цех3: работы 2, 3
- цех4: работы 3, 4
и т.д.

Для п.1 сущность needWork(idNeed, ...)
Для п.2 сущность deptNeedWork(idNeed, idDept)

Транспортной службой для этих работ назначается автомобиль, - отсюда idCar.
Этот idCar может изменяться со временем. Назначенный а/м - сущность
carNeedWork(idNeed, idDept, idCar, dateBeg, dateEnd)
и, собственно "работа" - это не idNeed, а парочка {idNeed, idDept}, т.е.
"привезти продукты в столовую 1".

Отсюда и в факте выполнения: table factNeed(idNeed, idDept, idCar, ...)
присутствуют idCar & idDept.

Заявочные работы похожи на постоянные, но с оттенком аварийности, но и здесь необходимы
idCar & idDept.

Теперь я хочу выделить некую постоянную часть этих работ, чтобы описать путевой лист
всех работ, однако при этом, как Вы сказали, "чувствую, что тут что-то не то.".

to MarchCat
"Я бы не делил работы на формализованные и не формализованные"
Да, это было-бы идеально.
То, что в задаче называется "постоянные работы" - это, собственно, план.
При отсутствии заявок сформировать план работы автомобилей на день просто, - они
уже назначены. Но существуют непредусматриваемые (неформализуемые) работы, скажем,
похороны. В отличие от постоянных, для работ по заявкам и автомобиль неизвестен.
Короче, дифференциация работ нужна.

to MarchCat
Чувствую, Вы попали в точку, кажется, дело в правильном описании работ.
Попробую реализовать то, что Вы сказали. Но:
Если изобразить всё схематично,

[factClaim]---[wayBill]---[factNeed]

то вопрос вот в чем:

связь (wayBill - factClaim) использует атрибут {idWork},
а связь (wayBill - factNeed) использует атрибуты {idWork, idDept}

Вот что подозрительно.

При этом, сущности factClaim и factNeed должны быть именно таковы, с разной структурой PK.

to tygra
Не получается объединение в одну таблицу заявок (1) и постояных (2):

1. (1) в отличие от (2) имеет атрибуты город назначения, предприятие, и др.
2. (2) в отличии от (1) может быть связанным со справочником автомобилей.
3. не важный аргумент, но всё же: (1) пополняется каждый день, а (2) практически не меняется.

Хочется все путевые листы иметь в одной таблице.
А решение хранить путевые листы в разных таблицах я оставил, как последнюю надежду.

to marchCat
Вероятно, под "таб_Т.накладные" надо понимать путевой лист.
Вобще, путевой лист - это
table(anyWork, idCar, idDrive(s), date, {parameters})
при этом, в частности, № путевого листа лучше не использовать как ключ, -
для разных видов работ этот № может совпадать. [Путевой лист].PK - это
{anyWork, idCar, date} ANYWork, потому, что здесь может быть несколько атрибутов, в том числе idWork.

Вот это значение и ссылается либо на [заявка], либо на
[пост. работа]. /* это строка S */

Для "таб_операции" иметь "пустой шаблон" представляется искусственным.

и, если я правильно понял, "таб_операции" - это справочник всех работ ?

Меня же смущает, что ссылки в строке S структурно разные для
[заявка] и [пост. работа].

!! В последний момент увидел Вашу добавку. Конечно !!

Спасибо всем за обсуждение.
Извините за небольшое отступление: у меня нач. строгий, но умный. Ничего не аргументирует и не объясняет, только либо отвергает, либо принимает (реже). Посоветоваться не с кем. (а, кстати, что такое IMHO?)

А теперь по делу:
to dosemi
Согласен, я тоже видел эту опасность (новый тип работ), но не мог явно ткнуть в этот тип пальцем.
Похоже, я склонен согласиться со всеми, кто предлагал использовать одну таблицу для всех работ. Да, так должно быть.
Еще раз всем спасибо.

Vasiliy !
Спасибо!
Когда я рассматривал вариант справочника всех работ
(до форума), даже имена атрубутов были такие же, как у Вас.