What is stopping you from having three tables:
STUDENT [PK: st_id] (optionally also an attribute of type BOOLEAN or similar, "is_teen" or "is_adult")
TEEN [PK: st_id]
ADULT [PK: st_id]
We will add one row into STUDENT for every new student; each time you add a student, then create a TEEN row if the new student is a teen, otherwise create a new ADULT row.
In either case, the st_id to use will be that of the new student. The st_ids in TEEN and STUDENT will be mutually exclusive, but all st_ids will point back to the appropriate STUDENT row.
Your ERD snippet appears to be for a Logical Data Model; I have copied that into the physical implementation directly. In the real world, often we would "roll up" (denormalize) the TEEN and ADULT attributes into the STUDENT entity to limit the amount of joining needed to get to all the info. available for a given student.
Optionally, you may choose to define a pair of foreign key relationships between STUDENT and TEEN and between STUDENT and ADULT.