Вы всегда создаете отношения «многие ко многим» между двумя таблицами, используя третью таблицу, строки которых содержат столбцы для первичного ключа каждой таблицы, а комбинация всех столбцов является первичным ключом третьей таблицы , Правило не изменяется для таблиц с составными первичными ключами.
CREATE TABLE Table1(Col11 ..., Col12 ..., Col1N ...,
PRIMARY KEY(Col11, Col12));
CREATE TABLE Table2(Col21 ..., Col22 ..., Col2N ...,
PRIMARY KEY(Col21, Col22));
CREATE TABLE RelationTable
(
Col11 ...,
Col12 ...,
FOREIGN KEY (Col11, Col12) REFERENCES Table1,
Col21 ...,
Col22 ...,
FOREIGN KEY (Col21, Col22) REFERENCES Table2,
PRIMARY KEY (Col11, Col12, Col21, Col22)
);
Это прекрасно работает. Это предполагает, что вы должны стараться и держать ключи простыми, когда это возможно, но абсолютно нет необходимости наклоняться назад, добавляя столбцы автоматического увеличения в ссылочные таблицы, если у них есть естественный составной ключ, который удобен в использовании. OTOH, соединения, связанные с таблицей отношений, сложнее писать, если вы используете составные клавиши - я бы несколько раз подумал о том, что я хочу, если в составном ключе задействовано более двух столбцов, не в последнюю очередь потому, что это может указывать на проблемы в дизайн ссылочных таблиц.
Глядя на фактическую диаграмму ER - URL-адрес er_lp в вопросе - префикс 'tbl' кажется ненужным; вещи, хранящие данные в базе данных, всегда являются таблицами, поэтому сообщаем мне, что с префиксом ... не нужно. Стол под названием «Машина», по-видимому, называется неназванным; он не столько описывает машину, сколько обязанность, отведенную машине на конкретном сдвиге. Я предполагаю, что таблица «Поле» относится к областям земли, а не к частям базы данных. У вас есть таблица «IsDone» (опять же, не очень хорошо названная), которая идентифицирует пользователя, который работал на машине для определенного перехода и, следовательно, для конкретной задачи. Это связано с соединением между таблицей Machine (имеющей 3-компонентный первичный ключ) и таблицей User. Неясно, может ли конкретная машина использоваться для нескольких задач при заданном сдвиге. Неясно, цикличны ли числа сдвига в течение дня или каждый номер сдвига уникален в разные дни, но предположение должно состоять в том, что есть, скажем, три смены в день, а число и дата сдвига необходимы, чтобы определить, когда что-то произошло. Предположительно, таблица Shift будет определять время и другую такую информацию.
Первичный ключ с тремя частями на машине в порядке - но лучше иметь два уникальных идентификатора. Одной из них будет комбинация первичных ключей; другой будет автоматически присвоенным номером - автоматическим приращением, последовательностью, последовательностью или любым другим ...
Адрес расширенной информации.
Мне уже не ясно, что вы хотите отслеживать. Если таблица «Машина» должна отслеживать, для какой машины использовалась данная машина, вам, вероятно, потребуется провести дополнительную структуризацию данных. Учитывая, что машина может использоваться для разных задач на разных полях в течение одной смены, вы должны подумать, пожалуй, с точки зрения таблицы MachineTasks, которая идентифицировала бы (дату и время) время начала и завершения операции и тип операции , Для ремонтных операций вы должны хранить информацию в таблице, описывающей ремонт; для рутинных операций в поле вам может не понадобиться дополнительная информация. Или, может быть, это перебор.
Я не знаю, выполняются ли конкретные задачи от имени нескольких отделов или вы просто пытаетесь заметить, что в течение одной смены машина может использоваться несколькими отделами, но один отдел за раз для каждого задача. Если каждая задача предназначена для отдельного отдела, просто укажите информацию отдела в главной таблице MachineTasks в качестве поля внешнего ключа.
Если вы решите использовать ключ с автоматическим приращением, вам все равно необходимо сохранить уникальность составного ключа. Это самая большая ошибка, которую я вижу, когда люди делают с полями автоматического увеличения. Это не так просто, как «таблица с ключом автоматического инкремента должна также иметь второе уникальное ограничение», но она не слишком далеко от знака.
При использовании ключа автоматического инкремента необходимо получить значение, назначенное при вставке записи в таблицу; вы затем используете это значение в столбцах внешнего ключа, когда вы вставляете другие записи в другие таблицы.
Вам нужно прочесть информацию о дизайне базы данных - я не уверен, что представляют собой хорошие хорошие книги, как я это делал большую часть своего обучения в течение десятилетия и более назад, и поэтому мои книги, как правило, менее доступны.