To your specific question of (easily satisfied) plausibility, the answer is yes. Since you seem to be looking for a broader critique. You seem to be mostly on the right track, but a few things are making your description overly complex.
It looks like your Classes table is more like what I would consider a course to be and your departments_teachers_and_classes is more of what I would expect a Classes table to be. A course would be Math, but a class would be the Math course taught by a particular teacher during a particular school term. A class is like an instance of a course.
To carry this change through, your departments_teachers_classes_and_students could simply be ClassStudents.
It seems as though you are using the department concept on several different levels. You should decide where the department belongs and stop referencing it everywhere else. You've said that a teacher can teach for multiple departments, so we can't put the department in the teachers table. This leaves Classes and Courses. Whichever you decide, it need only have a foreign key to the Departments table (unless you decide that one can be in multiple Departments). This eliminates the Departments_and_teachers table.
Teachers_and_Students could be replaced with a teacher foreign key in the Classes table and students/classes foreign keys in a ClassStudents table.
In short, for the portion of the design you have described, you probably need the following tables:
Departments
Teachers
Students
Courses
Classes
ClassStudents
Terms
The process of data modeling is complex enough that you will need to go read some books about it to learn the details. The subject goes way beyond what can be covered here. However, to get you started, you can follow these (drastically oversimplified) steps:
Step 1: Make an Entity-Type for Each Tangible Thing
Start with making a logical data model. For each thing your system cares about (people, places, things, events) make an entity-type. For your system it might look like this:
Step 2: Identify Your Relationships
Look at your logical entity-types and determine how they relate to each other. Remember to focus on the relationships that matter to your system. Don't get bogged down looking at relationships that are possible or that are real, but which are not pertinent to your system.
Step 3: Transform Your Logical Model Into a Physical Model
Once you have a logical model that covers the objects and properties that are of interest to your system, you need to figure out how the logical model can be implemented using physical tables in your database.
This involves at least two very important steps:
- Resolving many-to-many relationships into intersection tables
- Normalizing your tables
In the case of your system, there are some many-to-many relationships that can be resolved. Normalization involves looking at table fields. Since we don't know what your fields are from your question, we can't really get into that topic here. Normalization is very important, however, and you should always make sure that you start from properly normalized tables and de-normalize only when you have very good, well considered, reasons to do so.
Your model with m:n relationships resolved would look like this:
Note that there isn't enough information in your question to be able to say for sure that this model is the start of what you need. I've had to make a number of assumptions about what your entities are and how they're related. This site isn't meant to be used for collaborative design in any case (see the FAQ) - but I've tried to give you a quick outline of the process so you have someplace to start. If you get stuck with a specific design issue along the way, then you can definitely come back to ask for advice about it here on dba.se.
Best Answer
Yes you could add three additional tables called Departments, DepartmentUsers and DepartmentClasses.
Departments would have a primary key field departmentId (and probably some other fields like departmentName, etc).
DepartmentUsers would be a linking table between Departments and InstitutionUsers so it would store the departmentId and institutionUserId (as foreign keys). (This table determines which users are in which department.)
DepartmentClasses would be the same as above, except it would link Departments to InstitutionClasses, so it would store the departmentId and institutionClassId. (This table determines which classes are in which department.)
Then for a particular class you can see only the applicable users (within the department) who can be added to it via InstitutionClasses join to DepartmentClasses join to Department join to DepartmentUsers.
(Then the institutionUserID field in your InstitutionClasses table only represents who's already been added to the class. You may want to rename the column to something more explicit like registeredInstitutionUserID.)