Hotel reservation system: a room is sold by the night

Reservation, room type, room and stay

Four entities do the work. Room type describes what is sold: a double that sleeps two at a nightly rate. Room is a physical room with a number, one of several of its type. Reservation is a promise: this guest, these dates, so many rooms of these types. Stay is what actually happens: this guest in room 214, checked in at 15:10, checked out two days later.

Keeping reservation and stay apart is the decision to defend in a write-up. A reservation can end without a stay (a cancellation, a guest who never arrives), and a family reservation for two rooms turns into two stays. Reserved room is the join that says how many of which type a reservation holds, because one reservation can cover a double and a twin at once. Its key is the reservation and the room type together, so its two lines are solid, identifying relationships; every other line is dashed, because each of the other entities has an id of its own.

Charges hang off the stay, not the reservation: the minibar, the restaurant and each night's room rate are all run up by someone actually staying. Payments hang off the reservation, because a deposit is paid before anyone has a room key.

Availability is a question, not a column

With that model there is no "booked" flag anywhere, and there should not be one. Whether a double is free on the night of the 13th is worked out: the doubles the hotel has, less the doubles held by reservations that include that night. A flag on each room would be wrong the moment a reservation is made for next month, since the room is free tonight and taken then.

The test for "includes that night" is where most answers slip. leaves_on is the first morning the guest is gone, not the last night they sleep there, so a stay from the 12th to the 15th covers the nights of the 12th, 13th and 14th. Two date ranges, each running from its start up to but not including its end, overlap exactly when each one starts before the other ends. That rule lets one guest leave on the 15th and another arrive the same day with no clash, which is how a hotel expects it to work.

Making a reservation online

The sequence below books a double for three nights with a deposit. Its key idea is the hold. Between the guest seeing "four free" and paying, other guests are booking too, so the site holds one room for a few minutes, takes the deposit, and only then confirms. If the payment fails or the hold runs out, the room goes back.

The fifteen minutes is this example's choice; what matters is that the hold has a limit, or an abandoned payment page would keep a room off sale for good. Availability and reservations are drawn as separate participants because the first only answers questions and the second is the only one allowed to change anything.

Use cases: three kinds of staff work

The guest searches, books and cancels, perhaps without speaking to anyone. The front desk books on the phone, checks guests in and out. Housekeeping marks rooms clean, which is the step people leave out, and it is why a room can be free tonight but not ready at two in the afternoon.

Every reservation includes a deposit in this hotel, so Take a deposit is «include»d. A late cancellation fee is charged only when a guest cancels inside the hotel's notice period, so it extends Cancel a reservation. If your brief says deposits are optional, turn the include into an extend and say why in one line.

Data flow: from promise to key card

The level 1 DFD follows a reservation through the building. Process 1.0 reads the nights already sold to answer the guest, writes the new reservation, and exchanges the deposit with the payment provider. Process 2.0 reads the reservation when the guest arrives, picks a ready room, and marks it occupied. Process 3.0 is housekeeping's: it turns a cleaned room back into a ready one.

D2 has two writers, and that is the thing to check in a design review: check-in sets a room to occupied and housekeeping sets it back to ready, so the diagram shows exactly where a room's status can change and where it cannot.

Classes

In the class diagram the overlap rule gets a home, Reservation.overlaps(from, to), and RoomType.freeRooms(from, to) uses it. Room status is an enumeration, so a room can only be ready, occupied, waiting to be cleaned, or out of service. A stay owns its charges, drawn as composition, because a charge without its stay is a number with no one to bill.

Where marks go missing

1. An "is booked" flag on Room. A room is booked on some nights and free on others; the flag cannot say which.
2. Reserving room 214 at booking time, with no room types. It makes moving a guest or holding a room back for maintenance a data change instead of a decision at the desk.
3. The departure date treated as a night stayed, which double-books every changeover day.
4. Reservation and stay as one table, so a no-show looks like a stay and a two-room booking cannot be checked in room by room.
5. Charges attached to the guest rather than the stay, which mixes up a guest's separate visits.
6. No housekeeping, so every free room is assumed to be ready.

A brief about a chain of hotels adds a Hotel entity above room type; one about a guest house with four rooms might reasonably skip room types altogether. Say which you are modelling, and the choices above fall into place.