Back to articles list
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: room, guest and reservation. Then we continue refining our tables by discovering their attributes or columns. For example, the room table has attributes like: room number, name and smoke flag among others.
Reservation table has attributes date_in, date_out, status (canceled, confirmed) and made_by (online, in_person, phone, mail), while the attributes of the table guest are: first_name, last_name and 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 reservation tables.
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 reservation to reserved_room table.
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 reservation and 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: hosted_at and occupied_room.
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 guest and occupied_room.
The table occupied_room will have one record per each room being rented, on this record we can find the fields: check_in and 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.
