How to Create a Database Model From Scratch

vertabelo.com/blog/technical-articles/how-to-create-a-database-model-from-scratch

21/2/2014

So you want to create your first database model but you don’t know how to start? Read on!

I assume you already know a little about tables, columns, and relationships. If you don’t, watch our video tutorials
before you continue.

Start With a System Description

You should always start creating a database model with a description of a system. In a classroom situation, a
system description is given to you by a teacher. In real life, preparing a description is a process in its own right. I will
just assume that you have the description. It doesn’t matter whether it was given to you by your client, your boss,
your teacher, or you wrote it up yourself.

Take a look at the description and highlight all nouns. The nouns in the description can roughly be divided into
three categories: tables, attributes, and examples.

Tables represent primary entities in the system: people, physical objects, events, transactions, etc.
Attributes are properties associated with a primary entity. They describe features of your entity. In the
database model they will be the columns in your tables.
Examples are just that, examples. They help you understand the datatypes of certain attributes and they
help you understand the relationship between different entities.

Starting with a description has the benefit of forcing you to use the same glossary as your users. If you create a
system for a primary school, you should talk about pupils. If you create a similar system for a university, you should
1/7
talk about students.

Tables, Relationships, Columns

1. Once your nouns are highlighted, identify the tables. You don’t have to model everything at once. Focus on
the core functionality of the system first.
2. When you have the tables, figure out the relationships between the tables. This step might lead to
introducing new intermediate (junction) tables.
3. Finally add the columns to the tables.

At this point, you should read the description again and see if anything is missing. I assure you there will be
something to add. Add the new tables, the new relationships, and the new columns. Read the description again...

Things to Keep in Mind

Creating a database model is an iterative process. Don’t try to model everything at once. Start with the core entities
of your system. You can add more details later.

It is OK to ask questions. No matter how precise the description is, you will always have some doubts. Something
will always be underspecified. Ask questions about the things you’re not sure about. If you can’t ask questions,
make a reasonable assumption and note down the assumption you make.

There is always more than one way to model each system. Some models are clearly bad, but with most others it’s
difficult to judge if they are right or wrong. The model depends on what the purpose of the system is, how data come
to the system, even on the personal taste of the designer. As you gain experience, you’ll get more confident about
your design decisions.

Example: Car Rental System

As an example we will create a database model for a car rental system. First, take a look at a description of the
system:

A car rental company rents cars to customers. The company owns several cars. Each car has a brand, model
name, production year, mileage, color, and so on. Cars are divided into different categories: small, mid-size, large,
limousines.

The company has many locations where you can rent a car. The rental locations are located in
different cities throughout the country. There can be more than one company location in a city.

Anyone over 21 who has a valid driver’s license can rent a car. Customers under 25 or over 75 years pay different
(higher) charges then other customers.

Before renting a car, a customer usually makes a reservation for a car. A customer specifies the dates when
the car will be rented, the pick-up location, the drop-off location, and the category of car he wants to rent.
A customer may specify, that he wants some extra equipment in the car, for example a GPS, a car seat for a child,
etc.

When a customer rents a car, he declares the pick-up and drop-off location, and the drop-off date.
The customer can buy various types of insurance. He can also decide that he doesn’t need insurance because
the insurance is covered otherwise, for example by his credit card company. The customer can choose
additional options such as the possibility of an early drop-off, various refueling options, etc.

2/7
The customer pays the charges when he returns the car.

We start with highlighting all nouns:

The next stage is to find tables. We look for the basic entities in the system. For a start, you should at least have
these: car, customer, location, city, equipment, (car) category, insurance. We put them in the diagram. I added the
id column in every table because every table should have some sort of id. You can always change the primary key
later.

EDIT MODEL IN YOUR BROWSER

category
id int PK

car customer company

id int PK id int PK id int PK

location city equipment

id int PK id int PK id int PK

insurance
id int PK

The basic system entities are in the model but you should notice that we’re missing the core functionality of the
system: renting cars and reservations. Remember what we said at the beginning: tables are not only physical
objects but also events and transactions. You should add reservation and rental as tables as well. Here we
go:

EDIT MODEL IN YOUR BROWSER

3/7
 category
id int PK

rental

car company
customer
id int PK reservation id int PK
id int PK

location city equipment

id int PK id int PK id int PK

insurance
id int PK

Now we add the references between the tables in the model. I numbered the references as I added them. The note
next to each reference tells you when it was added:

1. Each car belongs to a category,

2. Each reservation is for a category of cars,
3. Each location is in a city,
4. Each reservation has a pick up and a drop off location,
5. Each reservation is made by a customer,
6. Each rental is made by a customer,
7. Each rental is for a certain car,
8. Each rental has a pick up and a drop off location.
9. Each rental is connected to some insurance. But is there only one insurance for each rental? No. There can
be many pieces of insurance connected to a rental (insurance against vehicle damage, against personal
injuries, against injuring someone else’s car, ...). I added an intermediate table called rental_insurance
connected to rental and insurance tables.

EDIT MODEL IN YOUR BROWSER

4/7
 insurance
id int PK

company
id int PK
equipment
id int PK
rental_insurance 9:
rental_id int PK FK table rental_insurance
insurance_id int PK FK + references

7
car
id int PK
category_id int FK

8 rental
id int PK
customer_id int FK
car_id int FK
pick_up_location_id int FK
drop_off_location_id int FK 6

1
location city customer
id int PK id int PK id int PK
city_id int FK 3

4
5
reservation
id int PK
pick_up_location_id int FK
category
drop_off_location_id int FK
id int PK category_id int FK
2 customer_id int FK

We’re still missing the reference between car and equipment. Is equipment permanently attached to a car or can it
be moved from one car to the other? There’s no answer to that question in the description, so we’ll make a
reasonable assumption: yes, it can be moved. We add a new table car_equipment and references between car
and equipment.

We delete the company table. The rental company is implicitly present in the system. After all, another company will
have their own system and their own database.

EDIT MODEL IN YOUR BROWSER

5/7
 equipment
id int PK
insurance
11: delete id int PK
table company
car_equipment
id int PK
equipment_id int FK
car_id int FK 10
rental_insurance 9:
start_date date
rental_id int PK FK table rental_insurance
end_date date N
insurance_id int PK FK + references

7
car
id int PK
category_id int FK
8 rental
id int PK
customer_id int FK
car_id int FK
pick_up_location_id int FK
drop_off_location_id int FK 6

1 location customer
city
id int PK id int PK
id int PK
city_id int FK 3

4 5
reservation
id int PK
pick_up_location_id int FK
drop_off_location_id int FK
category
category_id int FK
id int PK customer_id int FK
2

Finally, we add the columns and their datatypes. We also notice that there is no relationship between reservation
and equipment. But is the reservation made for a particular piece of equipment? No, it’s made for a type of
equipment: we add the table equipment_category and connect the tables reservation and equipment to it.

EDIT MODEL IN YOUR BROWSER

6/7
 equipment_category equipment insurance
id int PK id int PK id int PK
name varchar(255) name varchar(255) name varchar(255)
equipment_category_id int FK description text
policy oid

11: delete
table company

car_equipment
id int PK rental_insurance 9:
equipment_id int FK rental_id int PK FK table rental_insurance
12 10
car_id int FK insurance_id int PK FK + references
start_date date
end_date date N

rental
car 7
id int PK
id int PK customer_id int FK
category_id int FK car_id int FK
brand varchar(255) pick_up_location_id int FK
model varchar(255) drop_off_location_id int FK
8
production_year int start_date date
mileage int end_date date N
color varchar(255) remarks text 6

customer
location city
id int PK
id int PK id int PK name varchar(255)
1 city_id int FK name varchar(255) birth_date date
3
driving_license_number varchar(255)

4
reservation 5
id int PK
pick_up_location_id int FK
category drop_off_location_id int FK
category_id int FK
id int PK customer_id int FK
name varchar(255)
2

reservation_equipment
reservation_id int PK FK
equipment_category_id int PK FK

Are we done? Read the description again. Our database model still omits the charges. Well...

That’s an exercise for the reader. (But if you don’t feel like practicing your database modeling skills, here you can
find a ready-to-use database structure for a car rental company.)

7/7