My best advice is to remember the old programmer's rule:
When designing an Access project, if you can't do the job on paper, you won't be able to do it in Access.
When laying out data, you should spend some up-front time because no less an authority than Nicklaus Wirth (father of the Pascal language) stated a simple statistic over 30 years ago: Over 80% of all programming problems stem from poor data design.
You state that you can't enforce referential integrity because you don't house the data. BUT if you get CSV files, you DO control some part of that process of data import. 'cause I KNOW you don't have a CSV file as part of your live DB. No .DLL exists (that I know of) to support a CSV-based database file. So if there are abominations in the imported data, you can flag them and refuse to handle them in their current form.
The whole problem of referential integrity is the ability to control the data you need to use. If you truly cannot control the content of your DB, it isn't your DB. So the solution to this problem is to make it your DB or make the DB someone else's problem, one or the other. I.e. either you get to make decisions OR you pass the problems on to the person who won't let you make the decisions. Advise that person of the problems you face and get a resolution so you can do something constructive. If the person tries to delegate the authority, get it in writing. If the person is dismissive (I.e. "Just go make it work and don't bother me"), don't take that for an answer without pointing out that your current situation cannot be improved without a change. I.e. make your manager MANAGE for a change. Otherwise you will spin your wheels on sand.
OK, now to the techie side of this issue: Normalization is going to be paramount in a DB this complex. The idea of defining your relationships in the query screens is NOT necessarily wrong in the situation you describe, but it is less efficient than having a central repository of relationships. (Centralized: Takes up less space, takes less labor for maintenance.)
I give this advice to many people. A simple yet practical (and usually cheap) method to do a good DB design is to define your tables ON PAPER. Go find yourself a dry-erase board or a chalkboard. Buy a box of sticky notes. Not a pad. A BOX.
Put your table names on the board. Create some sticky notes to act as sample records for each table. When you have the normalization rules in front of you, start populating the tables. Whenever you are about to store something in a record but the something is a candidate for another table, you hit one of the normalization rules: Thou shalt not mix apples and oranges unless you were planning to make fruit salad. Apples go in the apples table. Oranges go in the oranges table. Records containing both apples AND oranges usually have to go into a linking table (representing the fruit salad, of course.) The "real" rule is that you don't store any details in a table if the details don't depend entirely and only on the prime key of said table.
OK, how does that work in practice? Well, look at your schedule. You've got students. You've got classes. You need a table to show what students are in what classes. But you ALSO need separate tables that hold the details for each student independent of their classes, and for the classes independent of each student. The class population table is where these two tables overlap. This is also where the prime keys of the "pure" tables are used as foreign keys for the table that uses both types of information.
Anyway, go find the rules of normalization. Access lists the three biggies (first through third-normal forms), though a web search could turn up more. Trust me, if you get the big three properly implemented, the others are obscure enough that you COULD survive without breaking things up that far. (Yeah, for the purists out there, I'm noted for uttering such blasphemies now and then. Good for the soul to get those out of your system, don't you know?)
You commented that not all of your tables have primary keys. Well, for the linking tables, this is possible. You should still have non-unique indexes on the foreign keys, though. And a primary key MIGHT be possible as the combination of the foreign keys in those cases. Take, for example, the class membership table. A student cannot be a member of the same class twice, so the combination of student ID and class ID should be unique. But in other cases, this might not be so. Depends on your business rules.
