What is ER Modeling?
As we know that the data is stored in the form of rows which are also called records and columns which are also called attributes. When we view a database we can see the data stored in this format. But, apart from this format, there is one more format which is called ER model. In this, the data is stored in the form of records and attributes.
We will learn about some of the terms to understand this –
Entity
A simple piece of data that is stored in the database is called an entity. It is also known as the entity type. The notation for entity type is given below –
Entity instance
An entity instance is a particular member of the entity type. Example for entity instance: A particular employee.
Regular Entity
entities that have an independent existence and generally represent real-world objects such as persons and products.
Weak entity
An entity that is dependent on another strong entity for its existence is called a weak entity.
Example for a weak entity: In a parent/child relationship, a parent is considered a strong entity and the child is a weak entity because the child is dependent on its parent for its existence
In ER modeling, the notation for a weak entity is –
Attributes
A piece of data that describes an entity is called an attribute.
The domain of Attributes –
The set of all possible values that an attribute can take is called the domain of attributes. For example, if the month is an attribute, then the domain of the attribute is {January, February, March, April, May, June, July, August, September, October, November, December}.
Key attribute
The attribute (or combination of attributes) which is distinct for every entity record is called a key attribute. E.g the employee_id of an employee, adhaar card number of a person, etc.
Composite key
If the key attribute contains more than one attribute then it is called a composite key attribute.
In ER modeling, the notation for the key attribute is given below.
Simple attribute
If an attribute can’t be separated into easier components, it is a simple attribute.
Example for simple attribute: adhaar_no of an employee
Composite attribute –
If an attribute can be separated into components, it is called a composite attribute.
Example for composite attribute: Address of employee, which can be split into the street, area, and city.
Single valued Attributes
If an attribute can take only a single value for each entity instance, it is a single-valued attribute.
Example of a single-valued attribute: Age of a student. It can take only one value for a particular student.
Multi-valued Attributes
If an attribute can take more than one value for each entity instance, it is a multi-valued attribute.
Example of a multi-valued attribute: the telephone number of an employee, a particular employee may have multiple telephone numbers. In ER modeling, the notation for the multi-valued attributes is given below.
Stored Attribute
An attribute that needs to be stored permanently is a stored attribute.
Example of stored attribute: name of a student.
Derived Attribute
An attribute that can be calculated or derived based on other attributes is a derived attribute.
Example of derived attribute: experience of an employee can be calculated on the basis of the date of hire. In ER modeling, the notation for the derived attribute is given below –
Relationships
The way in which two or more datasets are linked is defined as relationships in a database.
Example of relationship: An employee works for an organization. Here “works for” is a relation between the entity employee and the organization. The standard notation for a relationship is given below –
However in ER Modeling, To connect a weak Entity with others, you should use a weak relationship notation as given below –
Degree of a Relationship –
degree of relationship represents the number of entity types that associate in a relationship.
Example of the degree of a relationship: a customer purchased an item from a shopkeeper.
The cardinality of a Relationship
The relationship can have four possible types which are also called types of cardinalities of a relationship –
- One-to-one (1:1) relationship
- One-to-many (1:N) relationship
- Many-to-one (M:1) relationship
- Many-to-many (M:N) relationship
Example for Cardinality – One-to-One (1:1)
An employee is assigned a parking space.
Each employee is assigned a parking space. Therefore, this is an example of one to one relationship.
In ER modeling, this can be mentioned as given below –
Example for Cardinality – One-to-Many (1:N)
Organization has employees
One organization can have multiple employees working under it. Therefore, this is an example of the one-to-many relationship.
In ER modeling, this can be mentioned using notations as given below –
Example for Cardinality – Many-to-One (M:1)
It is just the reverse of a one-to-many relationship.
One employee works in only one organization But one organization can have many employees. Hence it is an M:1 relationship and cardinality is Many-to-One (M:1)
In ER modeling, this can be mentioned using notations as given below –
Cardinality – Many-to-Many (M: N)
Students enrolled in courses
One student can enroll in many courses and one course can have many students. So, this is an example of many-to-many relationships.
In ER modeling, this can be mentioned using notations as given below –
So, in this article we learned about the Entity–Relationship model that is used in DataBase Management. This ER Model is of great use as it provides an easily understandable graphical method to represent the Database.
You may also like to read: Data Structures Tutorials
Also, attempt the free DBMS Practice Test
