Let's do a design check. I gather from your relationships that:
A course ID (1) named Science1 could be put on a schedule, which may have 3 attendees signed up (3 bookings) and the bookings have personal details such as name, DOB, etc. A room needs to be allocated, but is it actually related to "Science1" (the course) which is what you have, or is it related to the course schedule? Might there not be 2 "Science1" courses running at the same time but in different rooms? Perhaps Room is related to the schedule, or it might even be a "resource" and perhaps there is not really a need for a separate "equipment" table, just a resource table (I don't know which are requirements of the project). IMO a room is not equipment so at the very least room doesn't belong there since there is a table for room data. Equipment, if it is to remain, seems more related to the things that one needs to teach the course, thus Room doesn't belong in Equipment when it's already in Room.
One of the more difficult aspects of db normalization is knowing what the attributes (fields) of the entity (table) are and which is which. You are an entity, having attributes of height, weight, gender, name, etc. How much money you have in your wallet is not an attribute of you. These things require a good deal of insight as to what process or business the db is supposed to support. Perhaps a quick review of the following will help with normalization and some other things I've touched on (e.g naming conventions, which I see you have already made great progress on). Don't know how much time or interest you have so I present it all
at the end here for your choosing.
the capacity for row of scheduleID 1 as an example will show '64'
I cannot see the entire query result and check if that's the count of 1's or not. Perhaps you get 64 because you've applied no criteria. Perhaps it on the criteria row it ought to be =Forms!frmNameOfFormHere.NameOfControlHere in the Schedule field where that control contains the scheduleID. That might depend on all the foregoing (which is a lot for you to digest, no doubt) - meaning if you alter table design and relationships, don't take that suggestion verbatim if it no longer applies.
You probably don't need a query to retrieve the current booking level. More like a domain aggregate function such (research "DSum with criteria") to limit the summing to a particular scheduleID. Research domain aggregate functions with a nod to DSum if you have to add a bunch of 1's for each attendee. If you have the value already (which I thought you were required to have) you only need to look it up - see "DLookup with criteria". Either way, I've reviewed your postings and I cannot see that you have stored the number (e.g.8) as the current number of attendees for a particular course but you did say it was a requirement. All I see now is a bunch of 1's in your latest images.
You might find something here under the topic of "students" that will help (or there may be valid schemas under a different topic)
The whole enchilada - pick and choose based on needs and time:
Normalization Parts I, II, III, IV, and V <<<primary reading
Thoughts, opinions, samples, tips, and tricks about Microsoft Access
rogersaccessblog.blogspot.com
and/or
holowczak.com
Entity-Relationship Diagramming: Part I, II, III and IV
Thoughts, opinions, samples, tips, and tricks about Microsoft Access
rogersaccessblog.blogspot.com
How do I Create an Application in Microsoft Access?
Thoughts, opinions, samples, tips, and tricks about Microsoft Access
rogersaccessblog.blogspot.com
Important for success:
Naming conventions -
General: Commonly used naming conventions
_________________________________________________________ Naming Conventions. This document is aimed at the user who is unfamiliar with any naming convention. It is based upon personal experience and the interaction I have had with others. It is not a hard and fast rule. Why use a...
www.access-programmers.co.uk
What not to use in names
-
Microsoft Access tips: Problem names and reserved words in Access
About Auto Numbers
-
UtterAccess.com
-
General: Use Autonumbers properly
The evils of lookup fields -
The Access Web - The Evils of Lookup Fields in Tables
Table and PK design tips -
Microsoft Access Tables, Primary Key Tips and Techniques
About calculated table fields -
Microsoft Access tips: Calculated Fields
About Multi Value Fields -
Multivalued Fields - Mendip Data Systems