The best way ... ? You need to start with a conceptual statement of what this database is for - what do you hope to be able to do with your database? Is it to manage the enrolment of students to Classes (Grades) year on year? Will you need to maintain student information, class (Grade) information, Teacher information? Fees for classes? Assessment Results? Attendance? Student Timetables? A statement of the scope / the problem(s) you want to solve. A full school administration system will require a sophisticated database - there are many that can be purchased. I assume this is not available to you and not what you desire.
By the Way - you can search for sample data models for school management systems - they will not fit your terminology but they might inform you about the data structures and relationships needed.
Start with the basics:
STUDENTS and the things that describe a student and nothing else eg Student Name, DoB(?), AdmissionNo, Date of Admission ...
GRADE (CLASS) and the things that describe a Grade (Class) and only the Grade - eg Class Name, enrolledStudents, Teacher assigned, Subject/Stream, Term, CalendarYear --- Implying that the concept of a grade is a specific collection of students being taught a unit /course/subject/stream by a teacher within a specific Calendar Year.
TEACHER: teacher name, dob, ...?
A Student may be enrolled in multiple Grades (Classes) and a Grade (Class) has many students enrolled. This is a real object. The StudentStream concept is I think something that emerges from the relationship between Students, Grades and Streams (Unit/Course/Subject)
A Teacher may conduct multiple Grades (Classes), and a Grade (Class) is conducted by a Teacher. (Although this may not be correct if you consider Teachers going on leave mid-term - if this need to be accounted then a table to resolve the many-to-many relationship is needed - capturing the date of departure/date of commencement for the teachers involved)
The above is represented by:
STUDENT m:n GRADE (Class) m:1 Teacher
which, applying normailsation rules
STUDENT 1-n ENROLEDIN n-1 GRADE n-1 TEACHER
Note:
EnrolledIn will have StudentID and GradeID as foreign keys
GRADE has the FK for a teacher
Streams? What are they? Are they UNITS of Study in a Subject?
Assuming they are, a STREAM (Unit) is taught in many GRADES (Classes), and a GRADE is held to teach a (1) STREAM (Unit)
STREAM 1:m GRADES
Grade then has a FK for STREAM.
If multiple teachers may be assigned the same Grade (class) - as in replacement due to leave - then an extra table is needed
ie Teacher !:n Grade becomes TEACHER m:n GRADE which is implemented as
Teacher 1:n Taught n: 1 GRADE with TAUGHT having a FK to Teacher and Grade and holding the data about commenced/ceased dates
As you were interested in "promoting" students, you will need to define the expected sequence for progression of students from one Stream (Unit) to the next Stream (Unit): eg BasicMaths 1 as step1, to BasicMaths 2 as step 2, to Geometry 1 as step 3, to Algebra1 as step 4 etc. If this is not how students progress then for eg Students may elect streams (units), then you will need to consider a process for future enrolment of students in grades rather than an automatic one or use the automated process and adjust the enrolments to match the elections.
I will leave it here to see if you can confirm/ take on board the above. There is more to do.