Database Reference
In-Depth Information
For this example, let's use a domain that is easily understood and that everyone can relate to: a
hotel that wants to allow guests to book a reservation.
Our conceptual domain includes hotels, guests that stay in the hotels, a collection of rooms for
each hotel, and a record of the reservation, which is a certain guest in a certain room for a certain
period of time (called the “stay”). Hotels typically also maintain a collection of “points of in-
terest,” which are parks, museums, shopping galleries, monuments, or other places near the hotel
that guests might want to visit during their stay. Both hotels and points of interest need to main-
tain geolocation data so that they can be found on maps for mashups, and to calculate distances.
NOTE
Obviously, in the real world there would be many more considerations and much more complexity. For
example, hotel rates are notoriously dynamic, and calculating them involves a wide array of factors.
Here we're defining something complex enough to be interesting and touch on the important points, but
simple enough to maintain the focus on learning Cassandra.
Here's how we would start this application design with Cassandra. First, determine your queries.
We'll likely have something like the following:
▪ Find hotels in a given area.
▪ Find information about a given hotel, such as its name and location.
▪ Find points of interest near a given hotel.
▪ Find an available room in a given date range.
▪ Find the rate and amenities for a room.
▪ Book the selected room by entering guest information.
Hotel App RDBMS Design
Figure 4-1
shows how we might represent this simple hotel reservation system using a relational
database model. The relational model includes a couple of “join” tables in order to resolve the
many-to-many relationships of hotels-to-points of interest, and for rooms-to-amenities.
