Components of ER Diagram

Components of an ER Diagram

An ER Diagram includes the following components

1. Entity
2. Attributes
3. Relationships

Entity

An entity is a person, place, element, event, or idea about which information is recorded. In an entity-relationship diagram, an entity is described by using a rectangle.

Some of the examples of the entities are given below

Person:

STUDENT, PATIENT, EMPLOYEE, DOCTOR, ENGINEER

Place:

CITY, COUNTRY, STATE

Event:

SEMINAR, SALE, RENEWAL, COMPETITION

Object:

BUILDING, AUTOMOBILE, MACHINE, FURNITURE, TOY

Concept:

COURSE, ACCOUNT, TRAINING CENTRE, WORK CENTRE

Entity Types

An entity is represented as a collection of entities that have similar attributes. For instance, an employee in a company database. The employee entities share similar attributes, however, such an entity has its value for each attribute. The entity type, the employee, is display in the figure:

An entity type is defined in ER diagrams as a rectangular box enclosing the entity type name. Attributes name are attached in ovals and are connected to their entity type by using straight lines as display in fig:

Entity Set

The collection of all entities of a specific entity type inside the database at any point in time is known as an entity set. It is also referred to as the extension of the entity type.

Parts of Entity Types

An entity can be divided into two types

Weak Entity Type

An entity type that does not have any key attribute is known as a weak entity type. The weak entity type is also referred to as the child entity type or a subordinate entity type.

The symbol for weak entity type is

Example

Strong Entity Type

Entity type, which has a key attribute, is known as the strong entity type. The strong entity type is also known as a regular entity type.

Attributes

An attribute in an Entity-Relationship Model specifies the properties or features of an entity. It is characterized by an oval or ellipse structure in the entity-relationship diagram. Each oval structures represent one attribute and is continuously linked to its entity, which is in the rectangle in structure.

The symbol for an attribute is

Types of Attributes

1. Simple Attribute

   A simple attribute is an attribute collected of a single element with an independent existence. A simple attribute cannot be subdivided or fragmented down into smaller components. Simple attributes are also known as atomic attributes.

   EMP-ID, EMP-NAME, EMP-DOB, EMP-CITY, and EMP-SALARY of the EMPLOYEE entity are the example of simple attributes.

   

2. Key Attribute

   The key attribute is used to characterize the primary featured of an entity. It describes a primary key. The key attribute is features by an ellipse with the text underlined.

   

3. Composite Attribute

   An attribute that is a mixture of two or more simple attributes is referred to as a composite attribute. The composite attribute is characterized by an ellipse, and those ellipses are a network with an ellipse. For example, the EMP-NAME entity type includes the First name and Last name.

   

4. Derived Attribute

   An attribute which can be changed from another attribute of the entity type is referred to as the derived attribute. In the Entity-Relationship diagram, a derived attribute is characterized by a dashed oval.

   The symbol for Derived Attribute is

   

5. Single-valued Attributes

   Attributes which have a single value for a specific entity is called single-value attributes.

6. Multi-valued Attributes

   Attributes which have a set of values for a similar entity is called multi-valued attributes.

   The symbol for Multi-valued Attribute is

   

   The complete entity type PERSON with its attributes can be defined as:

Relationships

A relationship is an associating between two or more entities. It represents a real-world association. For example, consider a relation method works_FOR among the two entity types employee and department, which associates or network each employee with the department, and the employee works for, as shown in the figure:

In this figure, each relationship instance r₁ is connected to the employee and department entities. Employee e₁,e₂ and e₅ work for department d₁ and employee e₃ and e₅ works for department d_2.

In ER diagrams, relationship types are represented as diamond-shaped boxes.

Relationships are described in the following types:

• Degree of a Relationship.
• Relationship Constraints.
• N-ary Relationship
• Existence of a Relationship.

Degree of a Relationship Type

The number of a participating entity type is referred to as the degree of a relationship type.

Following are the three degrees of relationships:

• Recursive or Unary Relationship.
• Binary Relationship.
• Ternary Relationship.

Recursive or Unary Relationship

A recursive relationship is a relationship between the instances of a single entity type. It is the relationship type in which the similar entity type is related more than once in several roles. Thus, the entity relates only to another instance of its own type. For example, a recursive binary relationship ‘manages’ relates an entity PERSON to another PERSON by management, as shown in the figure.

Recursive relationships are also referred to as unary relationships. Each entity type that performs in a relationship type plays a specific role in the relationship. A relationship may be given role names to signify the purpose that each participating entity type plays in a relationship. Role names can be important for recursive relationships to determine the function of each participant. The use of role names to describe the recursive relationship ‘manages’ is shown in the figure. The first participation of the PERSON entity type in the ‘manages’ relationship is given the role name ‘manager’ and the second participation is given the role name ‘managed’.

Role names are usually not necessary in relationship types where the function of the participating entities in a relationship is distinct and unambiguous.

Binary Relationship

The association between the two entities is called a binary relationship. As shown in the figure, two entities are associated in different ways; for example, DEPT and DIVN, PERSON and PROJECT, DEPT and PERSON, and so on. The binary relationship is the most standard type of relationship, and its degree of relationship is two.

Ternary Relationship

A ternary relationship is an associations among three entities, and its degree of relationship is three. The construct of a ternary relationship is a single diamond connected to three entities. For example, three entities SKILL, PERSON, and PROJECT are connected with single diamond ‘uses.’ Here, the connectivity of each entity is designated as either ‘one’ or ‘many.’ An entity in a ternary relationship is assumed to be ‘one’ if only one example of it can be associated with one instance of each of the other two associated entities.

Relationship Constraints

There are two important types of relationship constraints.

• Participation Constraints
• Mapping Constraints

Participation Constraints

It describes whether the existence of an entity depends on another entity via the relationship type.

There are two methods of participation constraints

1. Total Participation

   In total participation, every entity in the entity set must depend on another entity. For example, if an organization policy states that every employee must work for a department. Then an employee entity can exist only if it is linked to a department entity via WORKS_FOR relationship.

   Total participation is also referred to as an existence dependency. In ER diagrams, it is represented as a double line connecting the participating entity type to the relationship, as shown in figure (Total Participation of E₂ in R).

   

2. Partial Participation

   In partial participation, some entities in entity set depend on another entity.

Mapping Constraints

These express the number of entities to which another can be associated in a relationship set.

Types of Mapping Constraints

1. One to One

   An entity in A is linked with almost one entity in B. In this type of association, a record of one file is associated with only one record of another file.

   Example:

   Depositor relationship and with two entities, i.e., a user and an account-one user has only account in a bank.

   

   Using sets, it can be explained as:

   

2. One to Many (1: N)

   An entity A is associated with any number of entities in B. In this type of association, a record of one file will be associated with one or more records of another file.

   Example:

   Here, a user can have one or more accounts in that particular bank, i.e., a user may have joint accounts with others also. So, we can say that a user can have more than one account in the bank.

   

   Using sets, it can be explained as:

   

3. Many to One (N: 1)

   An entity in A is related to almost one entity in B. In this type of association, many records of the first file will be associated with a single record of the second file.

   Example:

   If many users have only one joint account.

   

   Using sets, it can be explained as:

   

4. Many to Many (M: N)

   An entity is associated with any number of entities B and an entity B is associated with any number of entities in A. In this type of association, each and every record of one file will be associated with one or more records of another file.

   Example:

   If many users have many accounts in the bank then it can be shown as follows

   

   Using sets, it can be explained as:

   

N-ary Relationship

In the case of n-ary relationship, a single relationship diamond with n connections, one to each entity, represents some association among n entities. An n-ary relationship has n+1 applicable variations of connectivity. All n-sides have connectivity ‘one,’ n-1 sides with connectivity ‘one’ and one side with connectivity ‘many’, n-2 sides with connectivity ‘one’ and two sides with ‘many’ and so on until all sides are ‘many’.

Existence of a Relationship

In case of existence relationship, the existence of entities of an enterprise depends on the existence of another entity. Existence of an entity in the relationship is described as either mandatory or optional.

In a mandatory existence, an occurrence of either the ‘one’ or ‘many’ entity must continuously exist for the entity to be contained in the relationship.

In an optional existence, the occurrence of that entity need not exist.

Example:

An Entity PERSON may or may not be the manager of any DEPT, thus making the entity DEPT optional in the ‘is managed by’ relationship between PERSON and DEPT.