DBMS | ER - Model | Technical Interview Series | Part-3

ER Model is used to model the logical view of the system from the data perspective which consists of these components:

  • Entity
  • Entity Type
  • Entity Set

An Entity may be an object with a physical existence - a particular person, car, house, or employee - or

it may be an object with a conceptual existence - a company, a job, or a university course.

An Entity is an object of Entity Type and set of all entities is called as Entity Set. e.g.; E1 is an entity having Entity Type Student and set of all students is called Entity Set.

In ER diagram, Entity Type is represented as:

Attribute(s) Attributes are the properties which define the entity type. For example, Roll_No, Name, DOB, Age, Address, Mobile_No are the attributes which defines entity type Student. In the ER diagram, attribute is represented by an oval.

  1. Key Attribute - The attribute which uniquely identifies each entity in the entity set is called key attribute. For example, Roll_No will be unique for each student. In the ER diagram, the key attribute is represented by an oval with underlying lines.

  2. Composite Attribute - An attribute composed of many other attributes is called as composite attribute. For example, the Address attribute of student Entity type consists of Street, City, State, and Country. In the ER diagram, composite attribute is represented by an oval consisting of ovals.

  3. Multivalued Attribute - An attribute consisting of more than one value for a given entity. For example, Phone_No (can be more than one for a given student). In the ER diagram, a multivalued attribute is represented by a double oval.

  4. Derived Attribute - An attribute which can be derived from other attributes of the entity type is known as a derived attribute. e.g. Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed oval.

The complete entity type Student with its attributes can be represented as:

Relationship Type and Relationship Set A relationship type represents the association between entity types. For example Enrolled in is a relationship type that exists between entity type Student and Course.

In the ER diagram, relationship type is represented by a diamond and connecting the entities with lines.

Degree of a relationship set: The number of different entity sets participating in a relationship set is called as degree of a relationship set.

a. Unary Relationship - When there is only ONE entity set participating in a relation, the relationship is called as unary relationship.

Example 1: A student is a friend of itself.

Example 2: A person is married to a person.

Example 3: An employee manages an employee.

b. Binary Relationship - When there are TWO entities set participating in a relation, the relationship is called as binary relationship.

For example, a Student is enrolled in course.

Example 1: A student attends a course.

Example 2: A supplier supplies an item.

Example 3: A Professor teaches a subject.

c. n-ary Relationship - When there are n entities set participating in a relation, the relationship is called as n-ary relationship.

Example: A Professor, student and Project is related to a Project_Guide.

Cardinality The number of times an entity of an entity set participates in a relationship set is known as cardinality.

Cardinality can be of different types:

a. One to One - When each entity in each entity set can take part only once in the relationship, the cardinality is one to one.

Example 1: Let us assume that a driver can drive one carand a cat can be driven by the same driver. So the relationship will be one to one.

Example 2: A person can have only one Aadhar card and one Aadhar card can belong to only one person.

Example 3: Let us assume that a male can marry to one female and a female can marry to one male. So the relationship will be one to one.

b. One to Many - When entities in one entity set can take part only once in the relationship set and entities in other entity sets can take part more than once in the relationship set, cardinalities is one to many. Many to one also come under this category.

Example 1: A professor teaching many courses Example 2: Many employees working for one department. Example 3: Let us assume that a student can take only one course but one course can be taken by many students. So the cardinality will be n to 1. It means that for one course there can be n students but for one student, there will be only one course.

c. Many to many - When entities in all entity sets can take part more than once in the relationship cardinality is many to many. Example 1: Any number of student can take any number of subjects. Example 2: Any number of customer can order any number of products. Example 3: Let us assume that a student can take more than one course and one course can be taken by many students. So the relationship will be many to many.

Participation Constraint: Participation Constraint is applied on the entity participating in the relationship set.

  1. Total Participation - Each entity in the entity set must participate in the relationship. Example 1: If each student must attend a course, the participation of the student will be total. Total participation is shown by a double line in ER diagram. Example 2: Each employee must join a department.

  2. Partial Participation - The entity in the entity set may or may NOT participate in the relationship. If some courses are not enrolled by any of the student, the participation of course will be partial.

Weak Entity Type and Identifying Relationship As discussed before, an entity type has a key attribute that uniquely identifies each entity in the entity set. But there exists some entity type for which key attribute can’t be defined. These are called the Weak Entity type. A weak entity type is represented by a double rectangle. The participation of a weak entity type is always total. The relationship between a weak entity type and its identifying strong entity type is called an identifying relationship and it is represented by a double diamond.

Example 1: a school might have multiple classes and each class might have multiple sections. The section cannot be identified uniquely and hence they do not have any primary key. Though a class can be identified uniquely and the combination of a class and section is required to identify each section uniquely.

Therefore, the section is a weak entity, and it shares total participation with the class.

Example 2: A company may store the information of dependents (Parents, Children, Spouse) of an Employee. But the dependents don’t have existed without the employee. So Dependent will be a weak entity type and the Employee will be Identifying Entity type for Dependent.

Example 3: In case of multiple hosts, the login id cannot become primary key as it is dependent upon the hosts for its identity.