Database Design Series: Attribute Types in ER model with simple examples

Alae Taouab
5 min readMar 24, 2022

--

Introduction

In today’s world, data plays a crucial role in our daily lives. We rely on data to identify, classify, and understand various entities around us. One of the key components of data is attributes. Attributes are characteristics or properties that provide descriptive information about entities. They help distinguish one entity from another and are essential to identifying and understanding the entity.

In this article, we examine the different types of attributes and how they can be used to make rational decisions when choosing key attributes for a database. We’ll also look at examples of how attributes can be used in different contexts and how user preferences can affect the choice of attributes. By the end of this article, you will have a better understanding of the importance of attributes in data management and how to use them effectively.

Learning Outcomes

By reading this article you will be able to:

  • Understand the different types of attributes and their properties.
  • identify and distinguish between different types of attributes.
  • Select key attributes for a database based on context, circumstances, and user preferences.
  • Understand the importance of attributes in data management and how to use them effectively.

What is an attribute?

Attributes are characteristics or properties that provide descriptive information about entities.

What are the different types of attributes?

It is crucial to know that there are several types of attributes, including atomic, composite, multivalued, and derived attributes.

Atomic Attribute: it is a type of attribute that cannot be decomposed or subdivided any further.

How to distinguish the atomic attribute from all the others?

You can examine the domain of values (the set of values that an attribute can accept) to determine whether or not the attribute is atomic. For example, the national registration number cannot be decomposed into subcategory attributes. In addition to its indivisibility, this type of attribute is distinguished by its uniqueness, since each of its values is exclusive to one and only one person.

Figure 1: Customer entity with an atomic attribute.

You can also inquire whether the attribute should be recognized as an atomic one from the individual for whom the database is being designed. A retailer’s owner, for example, may request that you consider a customer’s date of birth as an atomic attribute. Veterinarians, on the other hand, may encourage you to regard an animal’s date of birth as a different attribute because the treatment given to a five-day-old animal differs significantly from that given to a five-year-old animal.

Figure 2: Customer entity with two atomic attributes.

In a nutshell, we can say from this example that if you are not sure about the type of attribute to take into account, it is better to check with the people for whom you are developing the database.

Composite attribute: It’s an attribute made up of related atomic attributes that have been grouped together. An email address, for example, can be thought of as a composite attribute because it is composed of a username, a domain name, and a domain.

How to differentiate the composite attribute from the others?

The decision to make an attribute composite or not will be greatly influenced not just by the context or circumstance in which the database is created, but also by the user’s preferences. A marketer, for example, may just want to know the email addresses of each of his customers. A fraud analyst, on the other hand, may be interested in both the username as well as the domain name of the email address in order to determine whether or not the email belongs to a fraudulent individual.

Figure 3: Customer entity with two atomic attributes accompanied by a decomposed attribute.

Multivalued attribute: as its name implies, may take on more than one value for a given occurrence of an entity. For example, the attribute “profession” can be multivalued if a person has more than one function. Even though we have opted to represent the profession as a multi-valued attribute, this does not mean that this will always be the case in all databases. In fact, the profession attribute can take a single value if we add the word current beside the word profession in this particular case.

How to discriminate the Multivalued attribute from the others?

Circumstances and user preference are the two factors that determine whether an attribute is multivalued or not. If the user, for instance, only wants to capture the current profession of a person, then you should replace the profession with the current profession and represent it as a single-valued attribute.

Figure 4: Customer entity with two atomic attributes, a decomposed attribute, and a multivalued attribute.

Derived attribute: it is a type of attribute that is not stored but calculated from the other attributes in the database. A good example of a derived attribute would be the attribute “age”, which could be calculated based on the customer’s date of birth.

Figure 5: Customer entity with two atomic attributes, a decomposed attribute, a multivalued attribute, and a derived attribute.

Keys

A database is used to store information for later retrieval. Data retrieval is only possible through the use of an attribute that has already been defined as a key. Some of the attributes are naturally qualified to be candidate keys. Despite the number of candidates you have, one attribute will be chosen to serve as a unique identifier, which becomes a primary key for the entity.

Figure 6: Customer entity with two atomic attributes, a decomposed attribute, a multivalued attribute, and a derived attribute.

We decide to consider the Customer_ID as a unique identifier for the entity, since each value can only be associated with one and only one customer. Given the possibility of two or more customers being born on the same day, month, and year, the birthdate attribute cannot be used as a primary key. Similarly, the same profession may be held by two or more customers, so the profession attribute is unlikely to be considered as a primary key. Email address, in contrast, can be considered as a primary key since the email service provider asks users to choose a username that has never been used before by any other user.

Wrap up

If you have any specific questions on the subject or any other general questions, please feel free to leave a comment; I will reply as soon as I become available.

If you find our article worth reading and informative, please share with those who are probably in need of it.

--

--

Alae Taouab

A consultant and researcher who assists organizations in achieving their goals.