Designing a Data Model for a Hotel Room Booking System
It’s common knowledge that the best way to learn something is to practice it in a real-life scenario. Obviously, the same applies to database modeling. Therefore, in this article I decided to teach you how to create a simple database structure, taking a textbook example of a hotel room reservation system. I will show you how to get started and give you some ideas for extending the model.
Database Modeling: Discover, Discover, Discover
In this article we will design a data model for a hotel room reservation system. We look for a data model where we can represent information about the rooms, the guests and the reservations booked at our imaginary VERTABELO***** Hotel. All this information will be stored in tables.
Database modeling is a cyclic discovery process. We first identify the main tables and its attributes. In our model, the main tables are:
reservation. Then we continue refining our tables by discovering their attributes or columns. For example, the
room table has attributes like: room
smoke flag among others.
Reservation table has attributes
status (canceled, confirmed) and
made_by (online, in_person, phone, mail), while the attributes of the table
member_since. Perhaps you feel like the
reservation table needs more attributes (like room type, number of beds), we will cover this point later, until then, consider our
reservation table incomplete. The following data model created in Vertabelo shows the main tables.
Data Types: What Are the Domains of Allowed Values for a Column?
Note that every column has a data type (varchar, integer, date, boolean) to indicate what kind of values can be assigned to the column. For example, the column
smoke on table
room is boolean data type, meaning only true or false are the allowed values.
Primary Keys: the Social Security Number of Every Record
Every table should have a column (or more than one) acting as an identifier for every record in the table. This column is called the primary key (PK), and best practices on database design suggest that every table must have a PK.
If we take a look on the previous Vertabelo data model, we will see that every table has a column called
id with a PK indicator on the right. These id columns forms the PK (as a convention we name
id the PK column).
An important concept, perhaps obvious for many readers, is that a PK column can’t have duplicated values. In other words, every PK column has a unique constraint, and any attempt to create a new record with a duplicated value will be rejected with an error by the database manager.
Continue Discovering; Find New Database Objects
A reservation is one of the more complex elements to represent in this data model. One reservation can have many rooms associated with it (for example “I wish to make a reservation for one double room and a separate room with 3 beds for my kids”). This business requirement adds 4 things to our model:
A new table: We need to create a new table called
room_reserved, where we store all rooms belonging to one reservation.
Add two references: A reference is a very important element in a data model. A reference describes how one table is related to another table. In our model, every room reserved belongs to one reservation, so we will use a reference to model that fact. This reference is graphically represented as a line connecting both tables.
Moreover, as every reservation belongs to one guest, we need to create a new reference linking the
guest and the
Move a column: Since we can have several rooms belonging to one reservation, we must allow cancelation per individual room, after that we move the
attribute status from
The updated data model is showed in the following diagram designed in Vertabelo:
What Happens to the Tables Linked by a Reference?
When we create a reference between two tables, one new column is added to one of the tables. This just added column is called a Foreign Key, and acts as a pointer to the other table allowing connections between tables. For example, take a look to the followings diagrams:
Fig. 1 Tables
guest before and after adding a reference
Continue Discovering; Go for More
One point pending to be modeled is the fact that rooms can be in use by some guests for a period of time. To represent this business fact, we added 2 tables:
Note that every person who stayed at the hotel will have a record in
hosted_at. This record will have a reference to the room he/she occupied and to the guest. This is why
hosted_at has a double reference towards
occupied_room will have one record per each room being rented, on this record we can find the fields:
check_out of type timestamp indicating when the rent begin and finish. A timestamp data type stores a point in time with arbitrary precision. Every
occupied_room record will also have a reference to the room number being rented and indirectly via
hosted_at to the guests who stayed at this room.
We also added the table
room_type to the data model; the idea is to group the rooms by room category or room type. For example “standard one double bed”, “luxury 2 double beds” can be type descriptions. We also have a max_capacity attribute here.
Exercises: Database design is an easy to approach discipline, however, it takes time to become a subject matter expert. If you are doing your first steps on database design, please try to complete the current data model to allow:
- If two or more guests are sharing a room, allow different check-in and check-out for each guest.
- In some cases hotels can change the configuration of the rooms (for example from standard one double bed to luxury 2 double beds). Add to the data model the elements to represent those configuration changes, maintaining the history of every room.