How you store the data and how you display it on the screen or printed page need not be the same.
I'd use tables and relationships that look like this:
Student---<SchoolYears-----<Quarters-----<Grades>-----Courses (---< means "one to many")
The fields in Grades would include:
Other fields specific to this one grade for this one student for this one course.
I'd then use one of several options for presenting this information such that the 4 grades for a given course are presented in the columns you show such that all for quarter grades are in one row for one course.
To list a few options: a "horizontal portal" could list the individual grades in a row, so could a "virtual list" as could a repeating calculation field where the repetitions use ExecuteSQL to query data from Grades.
You can research those terms as well as "pivot table" and "cross tab" to research these options and more for how you might do this.
I have been thinking about your suggested solution and I believe it would be a terrific way to generate a report card application. However, I am only processing data that already exists. My challenge is to get it from one format to another while also cleaning the variables for better analysis.
To help you better understand the problem, I am attaching a sample spreadsheet that shows the type of data and how we receive it. Please note that I used four separate tabs, but the data would actually be delivered in four separate spreadsheets.
Given this information, does that change your advice?
Sample Grades.xlsx 38.5 K
If you are importing this data from a spreadsheet, it doesn't change my recommendation. You can set up a script that imports this data and moves it into the tables I've recommended. As long as the spreadsheet is kept to the same design of rows and columns, the user need not do more than select the file from which to import the data.
The data model that I recommended makes for much more flexible options for how you might choose to work with this info.