Вы правы, из спецификации схемы вы не можете. вам нужно будет денормализовать таблицу Course_Fee, чтобы она также отображалась в таблице Student_course (так как это единственная таблица, отображающая 1-к-1 с феномой конкретного студента, посещающего определенный класс. )
Однако есть альтернатива.
Представьте, что в таблице курса у вас есть две строки, такие как:
...
2,'Intro to CS', '15 weeks', 2000.00
...
5,'Intro to CS', '15 weeks', 2500.00
...
так что теперь вы можете иметь исторические записи о студентах, взявших предыдущую версию курса за 2000 $, привязанных к записи ID = 2, а новых студентов, взявших новую версию за 2500 $, привязанных к ID = 5.
Выражение схемы, такое как определения вашей таблицы, не может рассказать вам все о том, как работает база данных. даже после рассмотрения полей, ключей, ограничений и т. д. приложение по-прежнему использует таблицу для рассмотрения. Например, в этом случае приложение предполагает наличие дублирующихся курсов и использует Top(1) в своих запросах:
select Top(1) * from Course order by ID DESC
Так, это может выразить это? да. Это плохой дизайн, да. Лучше денормализовать, а еще лучше создать таблицу платы за курс с активным битом, чтобы вы могли деактивировать старые платы, но при этом сохранить целостность данных и ссылок.
Я бы сделал это так:
Student(Id, Name)
Fee(Id, Fee)
Course(Id, course_name , course_duration , FeeId)
StudentCourse(StudentId, CourseId, FeeId)