The problem with calendars in the literal sense is that they are never-ending. Further, if you want them to not only tell you what IS booked, but what WAS booked, you can't easily get rid of them, and thus you get a huge pile of calendar records that just never go away. Most booking systems I have seen (which is certainly NOT all the systems that there are) will use a "booking slip" concept where you have a customer who books from a starting date to an ending date. You should be able to search the forum for "Booking" because we've had only about a gazillion of those questions. Some of them will be useful, probably.
I'm omitting some details because you wanted design-level info. You might have something like this:
You need a ROOMS or UNITS table (however you want to call it) starting with three entries to describe three apartments or rental units.
You would have a TENANT table to describe details about current tenants and to track info about prior tenants (if needed).
Then you would have a BOOKING table that has the TenantID, a UnitID, a starting date, and an ending date. NOTE: You can easily use a "fake" date for the ending of the booking. E.g. pick an arbitrary future date that is longer than either you or your tenant is likely to live. 31-Dec-9999 actually IS a legal date, for example, and Windows allows it. If your tenant says "I'm moving out on St. Swithin's Day" then you only have to edit the booking record's ending date, nothing else.
If you are tracking rent payments, you have a PAYMENT table that has the unit ID and customer ID and date and amount. (If you want, you can even add a TYPE code for DEPOSIT as well as for MonthlyRent.
If you are tracking maintenance info, you can have a MAINT table that links back to UNITID and has a date and cost.
What I suggested was a more or less normalized design. If you are not familiar with the concept of normalization, search this forum for "Normalization" or search the web for "Database Normalization" and read a few articles on the topic. If you do the web search, you have to qualify it with "Database" because other disciplines use the word "Normalization" as well. Also, if you are searching the web, look first at a couple of .EDU sites because the .COM sites have something to sell you a lot of the time. Once you are more comfortable, the .COM sites DO have some pretty good articles.
