Проясните, пожалуйста !
У меня в таблице в состав PK должны входить две даты, но по логике работы, таких запросов не существует, т.к. эти даты суть границы диапазона. Если я не буду декларировать наличие PK у таблицы, что я нарушу, или в чем здесь ошибка ?
P.S. Индексы существуют. У значений дат время сброшено в нуль.

to AVL
в состав PK кроме пары дат входят и другие атрибуты.
А чем мне грозит использование "слабой сущности" ?

Вдогонку:
Согласен, что PK - это выбранный из всех возможных. Меня смущает, что Codd, кажется говорил, что для каждого базового отношения PK должен быть выбран.
Или я путаю ?

Многострадальная таблица - это так называемая таблица связи "работник" - "бригада":
table kadrdept(idKadr, idDept, dbeg, dEnd),
она хранит принадлежность работника к подразделению предприятия. Ссылки на нее конечно есть. По idKadr и idDept.

1.Правильно ли я понял, что объявлять для этой таблицы
PK as {idKadr, idDept, dbeg, dEnd} не обязательно ?
2. Думаю в данном случае и формирование PK как некий суррогатный ключ также не нужно.

to Genady
1. Я считаю также.
2. Следовательно, в таблицу
table kadrdept(idKadr, idDept, dbeg, dEnd) требуется добавить поле idSurrogate ?

to Genady
Да, таблица
table kadrdept(idKadr, idDept, dbeg, dEnd)
связана с table kadr(idKadr, ...) как (M:1) и с таблицей
table dept(idDept, ...) как (N:1).
А суррогатные ключи я использую не редко.
Однако, (к моему сожалению) не вижу, чем грозит отказ от объявления PK для таблицы kadrdept ?

to Genady
1. Если использовать только два поля idKadr и idDept, то где хранить "историю данных" ? Например, как отследить изменени численности работников подразделения за период (месяц, квартал, год) ?
2. У меня большинство ключей - суррогатные ключи, но
на чем основано приведенное Вами правило "Суррогатные ключи надо либо использовать либо не использовать." ?

to Genady
1. Согласен со всеми Вашими замечаниями (короткие наименования типа "dept" я просто использую для форума).
2. Если мое решение ошибочно (как часть проекта), то рискну предложить вариант:
вместо таблицы kadrdept(idKadr, idDept, dbeg, dEnd)
использовать
новаю таблицу kadrdept(idKadr, idDept, idSurrogate) и
дополнительную таблицу history(idSurrogate, dBeg, dEnd).
При этом нет вопросов о PK.
Это - решение ?

to AVL
Предложенный вариант усложняет немало, однако в исходном виде в проекте, я согласен с Genady, есть ошибки. И я их не вижу.

to AVL
1. Человек в течении месяца может быть переведен в другую бригду неоднократно (более 2-х раз).
2. В каждый момент времени человек может работать только в одной бригаде.
3. Согласованность дат, - требуется только их непересекаемость, отслеживается логикой работы с данными.

Задача такова:
1. Существуют работники.
2. Существуют бригады.
3. В каждый момент времени работник может работать не более чем в одной бригаде, или ни в какой. Момент времени - это дата.
4. В любой момент времени работник может быть переведен в другую бригаду, или перестать работать в какой л.б.

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

Приведенное мной на форуме решение содержит ошибки.

Я просто очарован:
обновлення сущность
kadrDepartament(idKadr, idDepartament, dateEnd)
позволяет решить задачу, и, как всякая реляционная
имеет PK as {idKadr, idDepartament, dateEnd}.
Я правильно все понял ?
Если так, то какой бес навеял мне использование именно пары дат ?

Извиняюсь, занесло.
Структура таблицы kadrDept не меняется, но, по условиям задачи (в каждый момент времени работник в одной бригаде) в качестве PK может использоваться набор
{idKadr, idDept, dBeg}.
По-моему, так ?

Genady, AVL !
Спасибо.
И всем, кто помог.

Прошу прощения за еще одно послание.
Завтра у меня день рождения, так что неплохой подарочек
приготовили мне рыцари Genady and AVL. Благодарю.