What’s the Goal of Your Database?
Episode #2 of the course Relational database design by Ben Brumm
Welcome to the second lesson of this course.
After looking at the benefits of a relational database in the last lesson, today we’ll look at how to get started with designing your database.
What’s the Goal?
The first place I always start with designing a database is to ask, “What’s the goal?” What is the database trying to achieve? What’s the purpose?
This might seem obvious, but if you think about it and how it relates to your website or application, it might not be.
For example, let’s say we want to design a “student” database. This might seem a bit vague. Let’s go back and work out why. Why do we want to design a student database?
So we can capture student data from our enrollment system. Ok, that’s better. It’s close.
What’s the purpose of this enrollment system? The purpose (of this example) is to help universities keep track of the students who have enrolled, what subjects they are taking, and the teachers of those subjects.
So, that’s the goal of our website, and therefore the goal of our database.
What Are the Requirements?
The second part of working out what your database will be used for is to determine the requirements. This goes a little further than specifying the goal. The steps you take will depend on who you’re designing the database for.
If you’re designing the database for a personal project of yours, then it’s probably simpler. You might already know what you want your website or application to do. If not, think about it. Write down what the required features of your application or website are. This can be just bullet points at the moment or short sentences.
I’ll show some examples shortly.
If it’s for a project at work, then the process might involve a bit more work. You’ll need to speak to someone who knows the requirements or gather the requirements yourself. First, work out who to speak to. This could be another project member or a user of the system. The aim is to find out what the application or website is meant to do or what features it has.
Example
For example, if we refer to our student enrollment system, we might determine that some of the features are:
• Students are allowed to enter their details—first name, last name, date of birth, and address
• The system needs store the details of subjects that are offered, including the name and category
• Teacher information will be stored in the database—first name, last name, date of birth, address, and which subjects they teach
• There will be records of different university campuses
Just as important as working out what features are allowed is what features will not be allowed.
In our example, we might say:
• User account creation is not included
• Enrollment fee calculation and payment is not included
These two features being excluded means that we don’t have to include them in our design.
So, working out the requirements and scope of your database will help in designing it. It will help you work out what information you need to store.
In the next lesson, we’ll take the next step in designing our database, which is identifying the objects or entities that need to be stored.
Until next time,
Ben
Recommended book
“Show Me the Numbers: Designing Tables and Graphs to Enlighten” by Stephen Few
Share with friends