Это ограничение внешнего ключа.
ALTER TABLE student
ADD CONSTRAINT somename
FOREIGN KEY (major_id) REFERENCES major (id);
Обратите внимание, что если student.major_id имеет значение NULL, значение столбца может быть равно нулю.
Обратите внимание, что на вашем столе не размещаются двойные специальности. Для этого у нас была бы таблица student_major, которая является отношением «многие ко многим» между студентом и мажором. Это также демонстрирует создание внешних ключей в таблице создания, а не в таблице изменения
create table student_major (
id serial not null unique primary key, -- optional, but good idea
student_id int not null references student(id), -- fk
major_id int not null references major(id), -- fk
UNIQUE (student_id, major_id) -- no redundant relations
);
Комментарий:
-1 для отклонения составных ключей. - Билл Карвин
Итак, дайте мне понять это. Билл согласен, что я правильно ответил на вопросы ОП об ограничениях. Он согласен с тем, что я правильно понял, о чем не спрашивал ОП, о возможных двойных специализациях. Но Билл все еще отмечает этот ответ как неправильный, потому что Билл и я не согласны с составными ключами.
Я даже не сказал, что синтетический идентификатор был необходим ; действительно, я специально сказал, что это опционально , но, на мой взгляд, хорошая идея. (Почему? Он «играет лучше» с удалениями, с таблицами, которые могут ссылаться на student_majors, а также с ORMS и сгенерированным кодом в целом.)
Билл, это откровенно мелко. Вы отметили правильный ответ над разработкой (составной / синтетической), касающейся разработки (учащиеся: специальности: М: М, а не М: 1), и над тем, что такое «религиозная» война. Вы отмечаете правильные ответы, потому что не согласны с позицией ответчика на вкладках против пробелов или vi против emacs? Возможно, вам стоило потратить время на то, чтобы дать свой собственный ответ, а не отмечать правильные ответы.