SQL - «Нет уникальных ограничений, соответствующих данным ключам», несмотря на наличие первичного ключа

0

Я работаю над проектом, который предполагает внедрение упрощенной версии школьной базы данных. Ниже приведены 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. Как исправить эту ошибку?

Теги:
database
database-design

1 ответ

0
Лучший ответ

Внешние ключи также могут состоять из нескольких столбцов:

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/

Ещё вопросы

Сообщество Overcoder
Наверх
Меню