Updated July 6, 2023
Introduction to Entity-Relationship Model
Entity-Relationship Model is the diagrammatical representation of a database structure called an ER diagram. The ER diagram is considered a database blueprint with mainly two components, i.e., relationship set and entity set. We use the ER diagram to represent the relationship among the entity set. We consider the entity set as a group of entities of similar types that contain attributes.
The database management system considers the entity as a table and attributes as columns of the table. So the ER diagram shows the relationship among tables in the database. We regard the entity as a real-world object physically stored in the database. The entities have attributes that help to identify the entity uniquely. We can consider the entity set as a collection of entities of similar types.
Why do we use Entity Diagram?
- The entity diagram represents the database in diagram form.
- It helps to understand the database properly.
- We can represent the necessary details of the database as an ER diagram.
- The entities represent all the tables of the database; attributes are the columns of tables, and the relationship represents the association among the tables of a database.
Diagram of ER Model
Given below is the diagram of ER Model:
The above figure represents the ER diagram of the college student database. The student, college, mechanical, electronics, and computer science are entities that enroll in and specialize in the relationship. The attributes are name, age, gender, DOB, affiliation, and address.
Components of Entity-Relationship Model
The ER model serves as a conceptual view of the database. The ER model consists of real-world entities and their related associations. The ER model gives the whole idea of a database used for any application and is very easy to understand.
The below section contains information about the components of the ER diagram:
1. Entity
We consider the entity as a real-world object that can be easily identified, representing any object. For example, we can consider employee details, location, and contact details as entities in an employee database. All types of entities have some attributes or properties which will help give the proper idea of the entity. We can consider the entity set as a collection of entities of similar types. In the entity set, some entities can exist that can contain similar types of values. For example, the employee set will contain information from all employees. The entity set does not require to be disjoint.
- Weak entity: We consider a weak entity as an entity whose attribute cannot be easily chosen and requires a relationship with another entity. This type of entity is known as a weak entity. In the ER diagram, the double rectangle represents a weak entity. For example, suppose there is only a bank account without any information about the associated bank. In that case, we consider it a weak entity because it does not allow the identification of the bank to which it belongs.
2. Attributes
We represent the entities using properties, and we refer to these properties as attributes. All the attributes have some value. For example, the employee entity can have the following attributes: name, age, and contact details. For the attributes, there can be considered a domain of values that can be allocated to the attribute. For example, we cannot assign a numeric value to the employee name. The employee’s name should always be alphabetic. The employee age cannot be in a negative number; it should always be positive.
Types of attributes:
- Simple attribute: We can consider simple attributes as atomic values that cannot be further segregated. For example, we cannot further segregate the employee’s phone number from another attribute.
- Composite attribute: The composite attribute contains more than one attribute in the group. For example, we can consider the employee name attribute as a composite attribute since it can be further segregated into first and last names.
- Derived attribute: The derived attribute is the type of attribute that does not exist in the database physically; however, the values derived are from the other database which is present in the database physically. For example, the average salary of an employee is derived from attributes as it is not directly stored in the database. The value can e derived from other attributes present in the database physically.
- Single value attribute: The single attribute contains a single value. For example, the security number.
- Multi-value attribute: The multi-value attribute is the attribute that contains more than value. For example, the employee can have multiple email IDs and phone numbers.
3. Relationship
The relationship serves as another type of component in the ER diagram, demonstrating the dependency among the database entities. The ER diagram represents the relationship with a diamond-shaped box. A line in the ER diagram connects all the relationships between the entities.
There are different types of relationships which are given below:
- One-to-one: In this relationship, the one entity is related to some other entity in a one-to-one relationship. E.g., an individual has a passport, and the passport is allocated to one individual.
- Many-to-one: In this relationship, when many instances of an entity are linked to one entity. E.g., many students can read in one college.
- One-to-many: When one entity is linked to more than one entity is a one-to-many relationship. E.g., one customer placed multiple orders.
- Many-to-many: We know a relationship as a many-to-many relationship when many entities link to many other entities. E.g., students can have multiple projects allocated to various students.
Conclusion
We consider the ER diagram a database blueprint containing all the necessary details. We regard the entities as tables of a database, view attributes as columns of tables, and consider tuples as rows of tables. And in between entities, some relationship exists, which makes a complete relational database.
Recommended Articles
This is a guide to Entity-Relationship Model. Here we discuss the introduction, why we use the entity diagram, and the components of the Entity-Relationship Model. You can also go through our other related articles to learn more–
