ER diagram is created based on three principal components: entities, attributes, and relationships.


Conceptual modelling is a very important phase in defining a successful
database application.

ER model is a popular high level conceptual data model .

This model and its variations are frequently used for the conceptual
design of database applications, and many database design tools employ
its concepts.


Figure shows a simplified description of the database design process.

The first step is requirements collection and analysis.

During this step, the database designers interview prospective database users to
understand and document their data requirements.

The result of this step is a concisely written set of users’ requirements.

These requirements should be specified in as detailed and complete a form as
possible.


In this step we can also specify the known functional requirements of the application.

These consist of the user-defined operations or transactions that will be applied to the
database, and they include both retrievals and updates.


Next step is to create a conceptual schema for the database, using a high-level conceptual data
model.

This step is called conceptual design.

The conceptual schema is a concise description of the data requirements of the users and includes
detailed descriptions of the entity types, relationships, and constraints; these are expressed using the
concepts provided by the high-level data model.

These concepts do not include implementation details, and are usually easier to understand and can
be used to communicate with nontechnical users.


The next step in database design is the actual implementation of the database, using a
commercial DBMS.

The conceptual schema is transformed from the high-level data model into the
implementation data model.

This step is called logical design or data model mapping, and its result is a database
schema in the implementation data model of the DBMS.


The last step is the physical design phase, during which the internal
storage structures, access paths, and file organizations for the database
files are specified.

In parallel with these activities, application programs are designed and
implemented as database transactions corresponding to the high-level
transaction specifications.

ER model

ER model describes data as entities ,relationships and attributes.

Entities and Attributes

Entity: A "thing" in the real world with an independent existence.

An entity may be an object with a physical existence or it may be an object with a
conceptual existence.

Eg: a person, car, house, or employee – physical existence

Eg: a job, or a university course – conceptual existence


Each entity has it’s own attributes—the particular properties that describe
it.

Eg: an employee entity may be described by the employee’s name, age,
address, salary, and job.

Eg: student entity -name,regno,DOB,course,email,phone no,address

A particular entity will have a value for each of its attributes.

The employee entity e 1 has five attributes: Name, Age,
Address ,salary ,job and their values are "John," “38”, "2311 Kirby,
Houston, Texas 77001,",”60,000”, and "manager" .


Composite Versus Simple (Atomic) Attributes

Composite attributes can be divided into smaller subparts, which represent more basic
attributes with independent meanings.

Example, the Address attribute can be sub-divided into StreetAddress, City, State, and
PIN code.

The value of a composite attribute is the concatenation of the values of its constituent
simple attributes.

Attributes that are not divisible are called simple or atomic attributes.

Eg: Age


Single-valued Versus Multivalued Attributes

Attributes that have a single value for a particular entity are called single-valued.

Example, Age is a single-valued attribute of person.

An attribute with a set of values for the same entity are called multivalued attribute.

Example -Degrees of a person


Stored Versus Derived Attributes

Derived Attributes: Attributes that do not exist in physical database but their values
can be derived from other attributes present in the database.

Eg: DOB-> Age

Stored Attribute: Attributes physically exist in database.


Complex Attributes

Attibutes formed by nesting composite and multivalued attributes .


If a particular entity does not have an applicable value for an attribute,a special value
called null is created.

Example, the ApartmentNumber attribute of an address applies only to addresses that
are in apartment buildings and not to other types of residences, such as single-family
homes.

Null can also be used if we do not know the value of an attribute for a particular
entity.


Entity tye:An entity type defines a collection (or set) of entities that have the same
attributes.

Each entity type in the database is described by its name and attributes.

Eg: Employee (Name,age,salary,department)

Student (Name,course,DOB,address)


Entity set :The collection of all entities of a particular entity type in the database at
any point in time is called an entity set.

Eg e1: John,38,60000,finanace

e2: Kevin,44,45000,HR

e3: Maria,35,50000,accounts


Key attribute of an entity type

An important constraint on the entities of an entity type is the key or uniqueness
constraint on attributes.

An entity type usually has an attribute whose values are distinct for each individual
entity in the collection. Such an attribute is called a key attribute, and its values can
be used to identify each entity uniquely.

Example for a PERSON entity type -key attribute is Aadhar Number.

For employee entity -key attribute -Employee ID


Value Sets (Domains) of Attributes

Each simple attribute of an entity type is associated with a value set (or domain of
values), which specifies the set of values that may be assigned to that attribute for
each individual entity.

If the range of ages allowed for employees is between 23 and 60, we can specify the
value set of the Age attribute of EMPLOYEE to be the set of integer numbers
between 23 and 60.

Name: String of alphabets

Relationships, Relationship Types, Roles, and Structural
Constraints

Relationship: Association among several entities.

Eg: Employee works for a department

Student enrolls in a course

A relationship type R among n entity types , E1,E2,...En, defines a set of
associations—or a relationship set—among entities from these entity types.

Realtionship set: A set of relationships of the same type.


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 type Ej where 1 ≤j≤ n.

Each of the entity types , E1,E2....En, is said to participate in the relationship type R,
and each of the individual entities , e1,e2,,,,,en is said to participate in the relationship
instance ri.

The association between entity sets is referred to as particiation, that is the entity sets
E1,E2....En participate in a relationship set R.


Degree of a Relationship Type

The degree of a relationship type is the number of participating entity types.

Eg:WORKS_FOR relationship - degree two.

A relationship type of degree two is called binary.

A relationship type of degree three is called ternary.


Role name:Each entity type that participates in a relationship type plays a particular
role in the relationship.

Role name signifies the role that a participating entity from the entity type plays in
each relationship instance, and it helps to explain what the relationship means.

Example, in the WORKS_FOR relationship type, EMPLOYEE plays the role of
employee or worker and DEPARTMENT plays the role of department or employer.

Recursive relationships: Same entity type participates more than once in a
relationship type in different roles.


The SUPERVISION relationship type relates an employee to a supervisor, where both
employee and supervisor entities are members of the same EMPLOYEE entity type.

The EMPLOYEE entity type participates twice in SUPERVISION: once in the role of
supervisor (or boss), and once in the role of supervisee (or subordinate).

Each relationship instance in SUPERVISION associates two employee entities e j and
e k , one of which plays the role of supervisor and the other the role of supervisee.

Constraints on Relationship Types

There are two main types of relationship constraints: cardinality ratio and
participation.

Cardinality ratio

The cardinality ratio for a binary relationship specifies the number of relationship
instances that an entity can participate in.


Example, in the WORKS_FOR binary relationship type,

DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N, meaning that each department
can be related to numerous employees but an employee can be related to (work for)
only one department.

The possible cardinality ratios for binary relationship types are 1:1, 1:N, N:1, and M:N.

One to one

An entity in A (Entity type) is associated with only one entity in B (Entity type) and an
entity in B is associated with only one entity in A.

Eg: Manages relation between employee and department


One to many : An entity in A can be associated with any number of entities in another
entity type (B), and an entity in entity type (B) can be associated with only one entity
in entity type (A).

Many to one: An entity in A is associated with at most one entity in B and an entity in
B can be associated with any number of entities in A.

Many to many:An entity in (A) can be associated with any number of entities in
another entity type (B), and an entity in entity type (B) can be associated with any
number of entities in entity type (A).

Eg: Employee works on project


The participation constraint specifies whether the existence of an entity depends on
its being related to another entity via the relationship type.

There are two types of participation constraints—total and partial.

Total participation: The participation of an entity set E in a relationship set R is said
to be total if every entity in E participates in atleast one relationship in R.

Eg: Employee in a works for relation with department is total because every
employee must work for a department.

Total participation is also called existence dependency.


Partial participation: The participation of an entity set E in a relationship set R is said
to be partial if only some entity in E participates in R.

Participation of employee in manages relation is partial.

Cardinality ratio and participation constraints together are called the structural
constraints of a relationship type.


Weak entity types:Entity types that do not have key attributes of their own are called
weak entity types.

Employee-(Name,Age,DOB,Salary,Department)

Dependent-(Name,Gender,Age,Relation)

Strong entity types:Entity types that have key attributes are called strong entity
types.
Eg: Employee-(EID,Name,Age,DOB,Salary,Department) :- EID
Patient- (PID,Name,Age,Address,Doctor) :- PID


Entities belonging to a weak entity type are identified by being related to specific
entities from another entity type in combination with some of their attribute values.


The other entity type is called the identifying or owner entity type.

The relationship type that relates a weak entity type to its owner is called the
identifying relationship of the weak entity type.

Eg: Employee -Strong Entity ( Attributes-EID,Name,Age,DOB, Salary, Department)

Dependent – Weak entity ( Attributes-Name,Age,Gender,Relation)


A weak entity type always has a total participation constraint (existence dependency)
with respect to its identifying relationship, because a weak entity cannot be identified
without an owner entity.


Partial key or discriminator: It’s the set of attributes that can uniquely identify
weak entities that are related to the same owner entity .

Eg: Name in dependent (EID,Name)

ER diagram is created based on three principal components: entities, attributes, and relationships.

More Related Content

Similar to ER diagram is created based on three principal components: entities, attributes, and relationships. (20)

Recently uploaded (20)

ER diagram is created based on three principal components: entities, attributes, and relationships.