Postgresql constrains on FK I am trying to design a (part of a) database which has to accomplish the following:


There is a students table, containing a bunch of students. 
There are educations in the database.
Each student can have 0..n educations.
There are x different types of educations, in which x is small (&lt;10) and known in advance.
The different types of education all have the same type of data associated with it (location, name etc.)
Some more data is associated with a student-education connection (e.g. grades, start date etc.).
The type of data which is associated with a student-education connection depends on the type of education (e.g. a masters degree has a specialization, a course does not).


I try to create a good database design to represent this data, however there are quite a few difficulties. A design I came up with is as followed:


Student table, which contains student data
Education table, which contains data of educations. There is a type column to specify the type.
Student_Education junction table, which links students with educations. 
x &lt;type&gt;Education tables which will contain data associated with student-education connections (thus a FK to Student_Education is always present). Each education type will have it's own table. 


However, there is a problem with this design: a &lt;type&gt;Education row should only be allowed to reference a Student_Education connection when the education type matches. E.g. a MasterEducation row can only reference a row in the Student_Education table that references a row in the Education table with type == master.

Would it be possible to add a constraint which can check exactly that? 

If not, what other options are available?
From a design perspective, why would the Student_Education table be needed at all?

The information that a specific student follows a certain type of education is implied by the existence of the corresponding row in the &lt;type&gt;Education table.

If Student_Education's reason for being is for SQL joins, it could be a view returning the union of all the &lt;type&gt;Education tables.

As for the foreign keys to Education, to be sure that each entry in &lt;type&gt;Education can only refer to its corresponding type, I can see two options:


As @hypercube suggests in the comments, add a &lt;type&gt;Education.educ_type column with a fixed value and a table-level foreign key:
FOREIGN KEY (educ_id,educ_type) REFERENCES Education(unique_id,type)
Split Education into as many subtables as they are education types, and have column-level foreign keys from each &lt;type&gt;Education.educ_id to the corresponding subtable. It's also the proper design choice if the Education table should be expanded in the future with columns that are specific to certain education types. Education could also be turned into a view as the union of the subtables, at least for the common columns.