It is hard to really be specific without knowing exactly what you are trying to track, but let me give you an example.
Let's say that you are a teacher and every week you give your students (there just happens to be four of them) an assignment. Each assignment will have a name, a status (open, closed, etc.), a start date and a due date. Each student will be given a grade, a date completed, and a status (not started, completed, etc.). So in this example, you have two parts: many students' grades to one assignment. This is known as a one-to-many relationship and involves two tables.
- tblAssignments
-
AssignmentID
-
AssignmentName
-
Status
-
StartDate
-
DueDate
- tblGrades
-
GradeID
-
AssignmentID
-
StudentName
-
CompletionDate
-
Status
-
Grade
You will notice that tblGrades has a field called AssignmentID. That is a foreign key field that links to the primary key field in tblAssignments. That is what ties the grades to the specific assignment. Now, the idea is to take away duplicated information. For example, you wouldn't put the assignment due date in the tblGrades because it would be the same for each student for that assignment, so you put it in the "one" side of the relationship.
Now to get back to your situation, you can think of each week percent as a grade and your group of four weeks as an assignment. Your job would then be to decipher which fields need to be on the "one" side and which need to be in the "many" side of the relationship. Make sure that you read the article that I linked to in my previous post.
Also keep in mind that there is often room for more tables than you originally think. For example, going back to the grades situation, you would probably want to not use the student's name in the tblGrades, but another foreign key field tied to a table with all the student information. Again, not knowing your data, I can't say that this would be the situation for you, but just keep your eyes open for the possibility.
Let us know if you have any more questions.