ER model

o ER model stands for an Entity-Relationship model. It is a high-level

data model. This model is used to define the data elements and
relationship for a specified system.
o It develops a conceptual design for the database. It also develops a
very simple and easy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram
called an entity-relationship diagram.

For example, Suppose we design a school database. In this database, the

student will be an entity with attributes like address, name, id, age, etc. The
address can be another entity with attributes like city, street name, pin code,
etc and there will be a relationship between them.
Component of ER Diagram

1. Entity:
An entity may be any object, class, person or place. In the ER diagram, an
entity can be represented as rectangles.

Consider an organization as an example- manager, product, employee,

department etc. can be taken as an entity.

a. Weak Entity
An entity that depends on another entity called a weak entity. The
weak entity doesn't contain any key attribute of its own. The weak
entity is represented by a double rectangle.
2. Attribute
The attribute is used to describe the property of an entity. Eclipse is used to
represent an attribute.

For example, id, age, contact number, name, etc. can be attributes of a
student.

b. Composite Attribute

An attribute that composed of many other attributes is known as a

composite attribute. The composite attribute is represented by an ellipse,
and those ellipses are connected with an ellipse.

b. Multivalued Attribute
An attribute can have more than one value. These attributes are known as a
multivalued attribute. The double oval is used to represent multivalued
attribute.

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived attribute. It can be
represented by a dashed ellipse.

For example, A person's age changes over time and can be derived from
another attribute like Date of birth.

3. Relationship
A relationship is used to describe the relation between entities. Diamond or
rhombus is used to represent the relationship.
Types of relationship are as follows:

a. One-to-One Relationship

When only one instance of an entity is associated with the relationship, then
it is known as one to one relationship.

For example, A female can marry to one male, and a male can marry to
one female.

b. One-to-many relationship

When only one instance of the entity on the left, and more than one instance
of an entity on the right associates with the relationship then this is known
as a one-to-many relationship.

For example, Scientist can invent many inventions, but the invention is
done by the only specific scientist.

c. Many-to-one relationship

When more than one instance of the entity on the left, and only one instance
of an entity on the right associates with the relationship then it is known as a
many-to-one relationship.

For example, Student enrolls for only one course, but a course can have
many students.
c. Many-to-many relationship

When more than one instance of the entity on the left, and more than one
instance of an entity on the right associates with the relationship then it is
known as a many-to-many relationship.

For example, Employee can assign by many projects and project can have
many employees.

Notation of ER diagram
Database can be
represented
using the
notations. In ER
diagram, many
notations are
used to express
the cardinality.
These notations
are as follows:
ER Diagram
ER Diagram stands for Entity Relationship Diagram, also known as ERD is a

diagram that displays the relationship of entity sets stored in a database. In other
words, ER diagrams help to explain the logical structure of databases. ER diagrams
are created based on three basic concepts: entities, attributes and relationships.

ER Diagrams contain different symbols that use rectangles to represent entities,

ovals to define attributes and diamond shapes to represent relationships.
Generalization
o Generalization is like a bottom-up approach in which two or more
entities of lower level combine to form a higher level entity if they
have some attributes in common.
o In generalization, an entity of a higher level can also combine with the
entities of the lower level to form a further higher level entity.
o Generalization is more like subclass and superclass system, but the
only difference is the approach. Generalization uses the bottom-up
approach.
o In generalization, entities are combined to form a more generalized
entity, i.e., subclasses are combined to make a superclass.

For example, Faculty and Student entities can be generalized and create a
higher level entity Person.
Specialization
o Specialization is a top-down approach, and it is opposite to
Generalization. In specialization, one higher level entity can be broken
down into two lower level entities.
o Specialization is
some
distinguishing
characteristics.
o Normally, the
attributes are
defined next,
and relationship
set are then
added.

For example: In an
Employee management system, EMPLOYEE entity can be specialized as
TESTER or DEVELOPER based on what role they play in the company.

Aggregation
In aggregation, the relation between two entities is treated as a single entity.
In aggregation, relationship with its corresponding entities is aggregated into
a higher level entity.For example: Center entity offers the Course entity act
as a single entity in the relationship which is in a relationship with another
entity visitor. In the real world, if a visitor visits a coaching center then he
will never enquiry about the Course only or just about the Center instead he
will ask the enquiry about both.

1. Relationship Types, Sets, and Instances

A relationship type R among n entity types E1, E2, ..., En defines a set of associa-
tions—or a relationship set—among entities from these entity types. As for the
case of entity types and entity sets, a relationship type and its corresponding rela-
tionship set are customarily referred to by the same name, R. Mathematically, the
relationship set R is a set of relationship instances ri, where
each ri associates n individual entities (e1, e2, ..., en), and each entity ej in ri is a
member of entity set Ej, 1 f j f n. Hence, a relationship set is a mathematical
relation on E1, E2, ..., En; alter-natively, it can be defined as a subset of the Cartesian
product of the entity sets E1 × E2 × ... × En. Each of the entity
types E1, E 2, ..., En is said to participate in the rela-tionship type R; similarly, each
of the individual entities e1, e2, ..., en is said to participate in the relationship
instance
ri =
(e1, e2, ...
, en).
Informally, each relationship instance ri in R is an association of entities, where the
association includes exactly one entity from each participating entity type. Each
such relationship instance ri represents the fact that the entities participating
in ri are related in some way in the corresponding miniworld situation. For
example, consider a relationship type WORKS_FOR between the two entity
types EMPLOYEE and DEPARTMENT, which associates each employee with
the department for which the employee works in the corresponding entity set. Each
relationship instance in the relationship set WORKS_FOR associates
one EMPLOYEE entity and one DEPARTMENT entity. Figure 7.9 illustrates this
example, where each relationship

2. Relationship Degree, Role Names, and Recursive

Relationships

Degree of a Relationship Type. The degree of a relationship type is the

number of participating entity types. Hence, the WORKS_FOR relationship
is of degree two. A relationship type of degree two is called binary, and one of
degree three is called ternary. An example of a ternary relationship
is SUPPLY, shown in Figure where each relationship instance ri associates
three entities—a supplier s, a part p, and a project j—whenever s supplies
part p to project j. Relationships can generally be of any degree, but the ones
most common are binary relationships. Higher-degree relationships are
generally more complex than binary relationships;
3. Constraints on Binary Relationship Types

Relationship types usually have certain constraints that limit the possible
combinations of entities that may participate in the corresponding relationship set.
These constraints are determined from the miniworld situation that the
relationships rep-resent. For example, in Figure 7.9, if the company has a rule that
each employee must work for exactly one department, then we would like to
describe this constraint in the schema. We can distinguish two main types of binary
relationship constraints: cardinality ratio and participation.

Cardinality Ratios for Binary Relationships. The cardinality ratio for a

binary relationship specifies the maximum number of relationship instances that an
entity can participate in. For example, in the WORKS_FOR binary relationship
type, DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N, meaning that each
department can be related to (that is, employs) any number of employees, 9 but an
employee can be related to (work for) only one department. This means that for
this particular relationship WORKS_FOR, a particular department entity can be
related to any number of employees (N indicates there is no maximum number).
On the other hand, an employee can be related to a maximum of one department.
The possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and

M:N.