Identify the Attributes
Episode #4 of the course Relational database design by Ben Brumm
Welcome to the fourth lesson.
In the last lesson, we looked at how to identify the entities in our database. These were the things we need to store data about.
In this lesson, we’ll go one step further and identify the attributes.
What Are Attributes?
Attributes are the pieces of information that we need to store for each entity.
If our entity is an object, an attribute is something related to that object to help define or describe it.
If you’re familiar with databases, then an entity is a table, and an attribute is a column.
In this course, we’ll learn how to define the tables and columns. This process starts with identifying the attributes.
How Do You Determine the Attributes?
To work out what to store for each attribute, you can use a combination of two methods:
1. Relate your design to real-world examples
2. Ask people and analyze the requirements
Let’s use both methods for our entities.
What are our entities?
In our example so far, the student enrollment database, we found these entities:
• Student
• Subject
• Teacher
• University
Let’s look at real-world examples to find out what we might need to store. Students are people, so they have a first name, last name, date of birth. Let’s put these down as attributes.
Now, when we design a database, there’s a traditional way to write it down if you’re not using a diagram.
The entity names go on a new line, like we have done so far.
The attributes go inside brackets next to the entities, separated by commas.
So, if we want to document the attributes for the student entity, it would look like this:
Student (first name, last name, date of birth)
We can add to this later. How about subjects? They might have a subject name.
Subject (subject name)
How about teachers? They are people too, so they would have a first name, last name, and date of birth.
Teacher (first name, last name, date of birth)
Now, what about universities? A university might have a name and an address.
University (name, address)
Those are based on our real-world examples. Now, let’s look at our requirements, which we gathered in an earlier email.
In that email, we determined our requirements to be:
• 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
For the first point, we were right with storing name and date of birth. But we need to store the address, so we’ll add that into our student entity as an attribute.
For subjects, we have got that listed, but we need to include the category.
Teachers also need to include address and the names of subjects they teach.
University looks to be OK.
So, our entities and attributes are:
Student (first name, last name, date of birth, address)
Subject (subject name, category)
Teacher (first name, last name, date of birth, address, subjects taught)
University (name, address)
Now, let’s put this into a diagram.
The ERD, or Entity Relationship Diagram, would look like this:
It shows boxes for each entity, and within each entity, a list of attributes. It’s incomplete, like our design, but we will refine it in the rest of this course.
So, that’s how you define attributes for your entities.
In the next lesson, we’ll take the first step of transforming our design into a well-designed database, which is applying a principle called “first normal form.”
Until next time,
Ben
Recommended book
Share with friends