Я работаю над проектом, который предполагает внедрение упрощенной версии школьной базы данных. Ниже приведены 3 релевантные таблицы:
create table classes( --A given class
class_code varchar(10) primary key
);
create table class_offerings( --A particular instance of a class
class_code varchar(10),
class_name varchar(128) not null,
semester_code integer,
maximum_capacity integer check (maximum_capacity >= 0),
teacher_name varchar(50) not null, --heavily simplified
primary key (class_code, semester_code),
foreign key (class_code) references classes(class_code)
on delete cascade on update cascade
);
create table prerequisites(
prereq varchar(10),
class_code varchar(10),
semester_code integer,
primary key (class_code, semester_code),
foreign key (class_code) references classes(class_code)
on delete cascade on update cascade,
foreign key (semester_code) references class_offerings(semester_code)
on delete cascade on update cascade,
foreign key (prereq) references classes(class_code)
on delete cascade on update cascade
);
Когда я пытаюсь создать "предварительные условия", мне присваивается сообщение "ОШИБКА: нет уникального ограничения, сопоставляющего заданные ключи для ссылочной таблицы class_offerings". Хотя верно, что я не применял ограничение UNIQUE к semester_code, это часть первичного ключа, что, на мой взгляд, обеспечивает уникальную комбинацию всех элементов первичного ключа. Если я ошибаюсь, я все равно не хочу применять UNIQUE к semester_code, так как нужно использовать несколько записей одного и того же семестра_кода, если они не используют один и тот же class_code. Как исправить эту ошибку?
Внешние ключи также могут состоять из нескольких столбцов:
foreign key (class_code, semester_code)
references class_offerings(semester_code,class_code)
on delete cascade on update cascade,
Лично, однако, я бы избегал такого дизайна. Если возможно, я бы вводил искусственные идентификаторы в качестве столбцов автоматического увеличения, которые всегда служат первичным ключам. Таким образом, внешние ключи всегда могут находиться в столбце искусственного идентификатора.
Естественные ключи хороши и должны быть помещены в качестве ограничений для db, а я просто не буду строить отношения на естественных клавишах. Тем не менее, это мое личное предпочтение, и есть аргументы в пользу наличия естественных ключей и первичных ключей: https://sqlstudies.com/2016/08/29/natural-vs-artificial-primary-keys/