Вы всегда создаете отношения «многие ко многим» между двумя таблицами, используя третью таблицу, строки которой содержат столбцы для первичного ключа каждой таблицы, а комбинация всех столбцов является первичным ключом третьей таблицы. Правило не изменяется для таблиц с составными первичными ключами.
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 (которая имеет первичный ключ из трех частей) и таблицей User. Не ясно, может ли конкретная машина использоваться для нескольких задач в данную смену. Непонятно, цикличны ли номера смен в течение дня или уникальна ли каждая дата смены по дням, но предполагается, что, скажем, три смены в день, а номер и дата смены необходимы для определения того, когда что-то произошло. Предположительно, таблица Shift будет определять время и другую такую информацию.
Первичный ключ из трех частей на машине в порядке, но может быть лучше иметь два уникальных идентификатора. Одним из них будет текущая комбинация первичных ключей; другой будет автоматически назначенным номером - автоинкремент, серийный номер, последовательность или любой другой ...
Обращение к расширенной информации.
Мне уже не ясно, что вы хотите отследить. Если предполагается, что таблица «Machine» отслеживает то, для чего использовалась данная машина, то вам, вероятно, нужно сделать более структурирование данных. Учитывая, что машина может использоваться для разных задач в разных полях в течение одной смены, вам следует подумать, возможно, с точки зрения таблицы MachineTasks, в которой указывается (дата и) время начала и завершения операции, а также тип операции. , Для ремонтных работ вы должны хранить информацию в таблице, описывающей ремонт; для рутинных операций в поле вам может не потребоваться много дополнительной информации. Или, может быть, это излишне.
Мне не ясно, выполняются ли определенные задачи от имени нескольких отделов, или вы просто пытаетесь заметить, что в течение одной смены машина может использоваться несколькими отделами, но по одному отделу за раз для каждой задачи , Если каждая задача предназначена для отдельного отдела, просто включите информацию об отделе в основную таблицу MachineTasks в качестве поля внешнего ключа.
Если вы выбрали автоинкрементный ключ, вам все равно необходимо сохранить уникальность составного ключа. Это самая большая ошибка, которую я вижу, когда люди делают с автоинкрементными полями. Это не так просто, как «таблица с ключом автоинкремента должна также иметь второе уникальное ограничение», но это не так уж далеко от цели.
Когда вы используете ключ автоинкремента, вам нужно получить значение, назначенное при вставке записи в таблицу; Затем вы используете это значение в столбцах внешнего ключа при вставке других записей в другие таблицы.
Вы должны прочитать о дизайне базы данных - я не уверен, какие текущие хорошие книги, как я делал большую часть своего обучения десятилетие и более назад, и поэтому мои книги, вероятно, будут еще доступны. *