Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 7

Attribute Selection from Business Descriptions

Recommended resources

Hello! In our last session, we took a close look at the building blocks of entities by classifying attributes into types like simple, composite, single-valued, multi-valued, and derived. Understanding these categories is the first step. Now, let's put that knowledge into practice.

This lesson is all about the practical skill of translating a real-world problem—often described in plain English—into a structured list of entities and their attributes. You will learn a systematic process for reading a business description, identifying the key pieces of information the database needs to store, and choosing the right attributes to represent that information. This is a core competency in database design, moving us from abstract concepts to a concrete plan for our database.

1. From Business Needs to Attributes: A Step-by-Step Method

The goal of database design is to create a digital model of a real-world system. The process begins with understanding the system's requirements, which are often provided as a "business description" or "scenario." Our job is to act like a detective, extracting the crucial facts from this narrative.

Here is a reliable method to follow:

  1. Read the Requirements and Identify Nouns: Go through the business description and highlight or list all the nouns. These nouns are your initial candidates for both entities (the main "things" you need to track) and attributes (the properties of those things).
  2. Distinguish Entities from Attributes: A simple but powerful test is the "has a" sentence structure. An entity is typically a noun that has properties. An attribute is a property that an entity has. For example, a STUDENT has a Name, and a STUDENT has a Date of Birth. STUDENT is the entity; Name and Date of Birth are its attributes. You wouldn't say a Name has a STUDENT.
  3. Refine the Attribute List: Once you have a list of potential attributes for an entity, apply the concepts from our previous lesson.
    • Granularity: Should an attribute be simple or composite? Storing an Address as a single attribute makes it hard to search for everyone in a specific city. Breaking it into Street, City, and PostalCode is often better.
    • Relevance: Only include attributes that are necessary to meet the stated requirements.
    • Uniqueness: Think about what attribute(s) could uniquely identify an instance of the entity. This is a preview of our next topic, primary keys.

2. Practical Techniques for Identifying Attributes

To see these techniques in action, let's start with a couple of short video clips that explain this process clearly.

First, watch this segment on how to begin by extracting nouns from a requirement statement.

Entity Relationship Diagrams

This video from Decomplexify demonstrates the first step of analyzing a business scenario.

Watch the section from the beginning of the scenario to where the presenter creates a final list of nouns. Notice how they start with a broad list and then refine it by removing synonyms and clarifying terms.

Next, let's focus on the "has a" rule and the importance of choosing the right level of detail for your attributes.

Beginning Database Design: Entities and Attributes

This video from Code With Me provides excellent practical advice on selecting and structuring attributes.

First, watch the segment that introduces the "has a" sentence structure. This is a key heuristic for separating attributes from entities and data values. Then, pay close attention to the discussion on how to represent attributes. The explanation of why you should break down an address into smaller parts is crucial for designing searchable and efficient databases.

3. Worked Example: A Language School Database

Now let's apply this methodology to a complete example. We will use a business scenario for a language school and walk through the process of defining its entities and attributes.

Designing a Relational Database

This article from Medium provides a step-by-step walkthrough of designing a database for a language school, starting from the initial requirements.

Start by reading the section "Defining the requirements." This contains the business scenario for the "International Language School." As you read, try to identify the main nouns yourself. Next, read "Identifying the entities" to see how the author selects the main entities (clients, teachers, courses, participants) from the requirements. Finally, study the section "Which attributes do we want to store?". This is the core of our lesson today. Pay close attention to the attributes chosen for the Teacher, Client, and Course entities and the author's reasoning. Notice the practical decision to add a teacher_id to handle potential duplicate names.

The article demonstrates the thought process of a database designer. It moves from a high-level description to a concrete list of entities and their specific, well-chosen attributes, such as breaking name into first_name and last_name for the Teacher entity.

4. Practice Exercise: The "Buy Fresh" Food Store

It's your turn to be the database designer. The image below contains a case study for a food store. Your task is to read the scenario and determine the attributes for the given entities.

ERD Case Study: Buy Fresh Food Store
A business scenario for the "Buy Fresh" food store, along with a list of potential entities.

Your Task:

  1. Read the business scenario described in the image.
  2. For each of the following entities listed in the case study, write down the attributes you believe are necessary based only on the information given in the text:
    • Customer
    • Order
    • Food store
  3. Once you have your lists, compare them to the attributes suggested in the table within the image.
Reflection Questions (Click to expand)
  • Did you identify attributes like Date of order for the Order entity? Why is this important?
  • The scenario mentions "customer must pay for the order immediately". Does this imply an attribute is needed? Perhaps something like PaymentStatus or PaymentType on the Order entity?
  • The suggested attributes for Customer include Customer contact number and Customer physical address. Are these simple or composite attributes? How might you break them down further if needed?
  • Why is Store location a necessary attribute for the Food store entity, according to the business rules?

This exercise highlights that while a requirements document provides the foundation, a designer often needs to make logical inferences to create a complete and functional model.

Conclusion

In this lesson, we transitioned from theory to practice. You learned a systematic method for analyzing a business description to identify and select the attributes that form the backbone of a database design.

Here are the key takeaways:

  • Start with Nouns: Business descriptions are full of nouns that are strong candidates for entities and attributes.
  • Use the "Has A" Test: This simple sentence structure helps distinguish entities (the things you track) from their attributes (their properties).
  • Think About Usage: The decision to break down composite attributes (like Address) depends on how the data will be used for searching, sorting, and reporting.
  • Design is Iterative: Moving from requirements to a final list of attributes involves reading, analyzing, and refining.

So far, we've identified our entities and described them with attributes. But how do we uniquely identify each record—for example, telling two customers named 'John Smith' apart? And how do we formally link a customer to their specific orders? This requires keys. In our next lesson, we will define primary and foreign keys, the crucial mechanisms for ensuring data integrity and creating relationships between tables.