Well, this is a familiar problem. We see the room-booking DB question often enough. Must be a popular school problem.
OK, we won't tell you every step, because this isn't THAT kind of forum. But we can offer guidance and suggestions, some of which might even be sort of helpful. But you have some work to do, too.
When you are using Access for something such as you described, you are making a business model inside the computer. So your first step is to identify your business components:
1. Business entities - these are the things you track. Like rooms, meetings, consultants, etc. Each is likely to be described in a separate table. The rooms are probably static. I.e. unless someone does construction or demolition, this list won't change. But meetings constantly come and go. Consultations are also ephemeral.
2. Business rules - like meetings are first-come, first-served and no bumping to a different room (a.k.a. first-fit); or find the meeting room with the best match to the estimated number of people involved and if necessary (and possible) downgrade any meeting that was in a larger room than required.
3. Business actions - like what really happens (on paper) when you reserve a room. I ask it this way because of the "old programmer's rule": You cannot do in Access what you cannot do on paper.
As I have said to others with this class of question, you must know your business rules only slightly less intimately than you know your last several sex partners. Only then are you ready to "get in bed" with the problem.
Now, once the BUSINESS side of the problem is resolved, you need to worry about the Access/TECHNICAL side of the problem. When you reserve a room because of a meeting, you usually have to do something like link the meeting to the room. Not the other way around, for two reasons:
1. Rooms can have any number of non-overlapping meetings booked at the same time, depending on your BUSINESS RULE about how far in advance you take bookings. So you cannot put a meeting item in a room table. You would quickly run out of room in the record long before you ran out of rooms.
2. With JOIN queries, you can identify existing bookings for a room easily enough anyway.
OK, read up on normalization. The rule that helps you more often than not is the one that says, in effect, "Don't mix apples and oranges." If you are storing meeting data, it doesn't go in the room table.
There is another rule about normalization, one that says don't store anything that doesn't depend entirely and only on the table's prime key. Which means that meetings, because they involve both a room and a time, must depend on room number AND start time AND duration.
Now, as to who is in a room, that depends on lots of factors, too. In general, attendees depend on the meeting, and the meeting depends on having a room. So this is a case of a grandparent-parent-child dependency to define who is in a room at a given time. Your relationships should reflect this. In fact, if you have consultants listed in the own table (hint: you should) then you can also link them to particular meetings. However, again, you have many meetings per consultant (or other attendees), so again you have to consider how to list potential attendees per meeting. (Hint: Look up Junction tables in this forum.)
This is the kind of thinking you should use when attacking this problem.
