Database Management System

UNIT 1
Lecture 1 – Introduction to DBMS

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research,
Prayagraj
 Syllabus
Unit-I:
Introduction: Overview, Database System vs File System, Database
System Concept and Architecture, Data Model Schema and In-
stances, Data Independence and Database Language and Interfaces,
Data Definitions Language, DML, Overall Database Structure. Data
Modeling Using the Entity Relationship Model: ER Model Concepts,
Notation for ER Diagram, Mapping Constraints, Keys, Concepts of
Super Key, Candidate Key, Primary Key, Generalization, Aggrega- tion,
Reduction of an ER Diagrams to Tables, Extended ER Model,
Relationship of Higher Degree.
1

2
UNIT 1-AKTU Syllabus
 Introduction: Overview.
 Database System vs File System.
 Database System Concept and Architecture.
 Data Model Schema and Instances.
 Data Independence and Database Language and Interfaces.
 Data Definitions Language(DDL), Data Manipulation Language(DML).
 Overall Database Structure.
 Data Modelling Using the Entity Relationship Model: ER Model Concepts.
 Notation for ER Diagram.
 Mapping Constraints.
 Keys, Concepts of Super Key, Candidate Key, Primary Key.
 Generalization, Aggregation.
 Reduction of an ER Diagrams to Tables.
 Extended ER Model, Relationship of Higher Degree. 3
COURSE OUTCOME(CO1) -

 Learn Basics of databases and apply it for real life applications.

4
LECTURE OUTLINE-

 Introduction
 Database Management System
 Applications of DBMS
 Characteristics of DBMS
 Advantages / Disadvantages of DBMS
 Actors on the scene
 Workers Behind the scene
 DBMS vs Traditional File System
 AKTU Questions
 Placement Questions

5
INTRODUCTION-

Database:
 The database is a collection of inter-related data which is used to
retrieve, insert and delete the data efficiently. It is also used to organize
the data in the form of a table, schema, views, and reports, etc.
 For example: The college Database organizes the data about the admin,
staff, students and faculty etc.
 Using the database, you can easily retrieve, insert, and delete the
information.

6
DATABASE MANAGEMENT SYSTEM-
Database Management System-

 Database management system is a software which is collection of

programs that enables user to create and maintain a database.

 DBMS is a general purpose software system that facilitates the process

of defining, constructing, manipulating and sharing databases among
various users and applications.

 It provides protection and security to the database. In the case of

multiple users, it also maintains data consistency.

 Ex – MySQL, Oracle 7
 Defining – It involves specifying the datatypes structures &
constraints of the data to be stored in the database. Database
definition or descriptive information is also stored in the database
in the form of a database catalogue or dictionary, it is called Meta
Data.
 Constructing – Constructing the database is the process of storing
the data on some storage medium that is controlled by the DBMS.
 Manipulating – manipulating a database include functions such as
Querying the database to retrieve specific data, updating the
database to reflect changes in the mini -world and generating
reports form the data.
 Sharing – Sharing a database allows multiple users and programs to
access the database simultaneously.
8
APPLICATIONS OF DBMS-

9
CHARACTERISTICS OF DBMS -

Self
Multiple
Describing Insulation
Views
Nature

Backup and
Data sharing
Recovery

10
CHARACTERISTICS OF DBMS -
 Self Describing nature of a database system –

 Database system contains not only the database itself but also
a complete definition or description of the database structure
and constraints.

 Definition is stored in the DBMS catalogue, which contains

information such as the structure of each file, the type storage
format of each data item, and various constraints on the data.

 Information stored in the catalog is called Meta data.

11
CHARACTERISTICS OF DBMS -
 Insulation between programs, data and data abstraction –

 DBMS programs are Program Data Independence.

 An operation(also called a function or method) is specified in two parts –
 Interface
 Implementation
Interface of an operation includes the operation name and the data types
of its arguments
Implementation of the operation is specified separately and can be
changed without affecting the interface.
The characteristic that allows program data independence & program
operation independence is called Data Abstraction. 12
CHARACTERISTICS OF DBMS -
 Support of Multiple Views of Data –

 A Database has many users , so they require different

perspective or view of the database.
 View may be a subset of the database or it may contain
virtual data that is derived from the database files but is not
explicitally stored.

13
CHARACTERISTICS OF DBMS -
 Sharing of Data & Multiuser Transaction Processing –

 DBMS must include Concurrency Control software to ensure

that several users trying to update the same data do so in a
controlled manner.
 Atomicity, Consistency , Isolation and Durability (ACID)
properties of Transactions are to be taken care.

14
CHARACTERISTICS OF DBMS -
 Backup and Recovery -

 There are many chances of failure of the whole database.

 At that time no one will be able to get the database back and for
sure company will be in a big loss.

 The only solution is to take backup of database and whenever it

is needed, it can be stored back. A database must have this
characteristic to enable more effectiveness.

15
ADVANTAGES OF DBMS -
 Controls database redundancy: It can control data redundancy because it stores
all the data in one single database file and that recorded data is placed in the
database.
 Data sharing: In DBMS, the authorized users of an organization can share the data
among multiple users.
 Easily Maintenance: It can be easily maintainable due to the centralized nature of
the database system.
 Reduce time: It reduces development time and maintenance need.
 Backup: It provides backup and recovery subsystems which create automatic
backup of data from hardware and software failures and restores the data if
required.
 Multiple user interface: It provides different types of user interfaces like graphical
user interfaces, application program interfaces.
16
 DISADVANTAGES OF DBMS -

 Cost of Hardware and Software – It requires a high speed of data processor and
large memory size to run DBMS software.

 Size – It occupies a large space of disks and large memory to run them efficiently.

 Complexity – Database system creates additional complexity and requirements.

 Higher Impact of failure – Failure is highly impacted the database because in

most of the organization, all the data stored in a single database and if the
database is damaged due to electric failure or database corruption then the data
may be lost forever.

17
ACTORS ON THE SCENE-

 People whose jobs involve the day to day use of large

database.
Actors on the Scene

Database Database End Users System Analysts

Administrators Designers

Casual End User Naïve or Parametric End

User

Sophisticated End Stand Alone Users

18
User
DATABASE ADMINISTRATORS-
 In any organization where many people use the same resources, there is a
need for a chief administrator to oversee and manage these resources.

 In a database environment , the primary resource is the database itself

and the secondary resource is DBMS & related Software.

 Administrating these resources is the responsibility of the Database

Administrator(DBA).

 DBA is responsible for authorizing access to the database coordinating &

monitoring its use and acquiring software and hardware resources as
needed.

19
DATABASE DESIGNERS-
 Database designers are responsible for identifying the data to be stored in the
database and for choosing appropriate structures to represent and store this data.

 These tasks are mostly undertaken before the database is actually implemented &
populated with data.

 It is the responsibility of database designers to communicate with all perspective

database users in order to understand their requirement and to create a design
that meets these requirements.

 It typically interact with each potential group of users and develop views of the
database that meet the data & processing requirements of these20 groups.
END USERS -
 People whose jobs require access to the database for
Querying,
Updating and
generating reports the database primarily exists for their use.
 Four types of End Users
 Casual End Users
 Naïve Or parametric End Users
 Sophisticated End Users
 Stand Alone End Users
21
Types of End Users -
 Casual End Users –
 Occasionally access the database, but they may need different
information each time.
 Use a sophisticated database Query Language.
• Naïve Or Parametric End Users-
 Make up a sizable portion of database end users.
 Main job functions revolves around constantly Querying & updating the
databases , using standard types of queries & updates called Canned
Transactions.

22
Types of End Users -
 Sophisticated End Users –
 Include Engineers , business analysts and others who thoroughly
familiarize themselves with the facilities of the DBMS.

• Standalone End Users-

 Maintain personal databases end users.
 Main job functions revolves around constantly Querying & updating the
databases , using standard types of queries & updates called Canned
Transactions.

23
SYSTEM ANALYSTS AND PROGRAMMERS-

 They require the requirements of end users especially

naïve and parametric, and develops specifications for
canned transactions that meet these requirements.

 They implement these specifications as programs then

they test, debug, document and maintain these canned
transactions.

 Are also known as Software Engineers.

24
WORKERS BEHIND THE SCENE -
 They are those who work to maintain the database system environment but
who are not actively interested in the database itself.

Workers behind
the Scene

DBMS System Operators &

designers & Tool Developers Maintenance
Implementers Personnel
25
DBMS System Designers &
Implementers

 They design and implement the DBMS Modules &

interfaces as a software package.

 DBMS is a very complex software system that consists of

many components or modules , processing Query Language
, processing the interface, accessing and buffering data,
controlling concurrency & handling data recovery and
security.
26
Tool Developers -
 They design & implement tools – the software packages that facilitates database
modeling & design , database system design & improved performance
 Tools are optional packages that re often purchased separately.
 They include packages for database design, performance monitoring natural
language or graphical interfaces , prototyping , simulation and test data
generation.

Operators & Maintenance Personnel -

• They are responsible for the actual running & maintenance of the
hardware and software environment for the database system.
27
DBMS vs File System -
DBMS File System
Collection of data in which user is not Collection of data in which user is required to
required to write the procedures. write procedures for managing the database.

Gives an abstract view of data that hides the Provide the detail of data representation and
details. storage of data

Provides crash recovery mechanism Does not have crash mechanism

Provides a good protection mechanism Very difficult to protect a file under the file
system

Takes care of concurrent access of data using Concurrent access has many problems like
some form of locking. redirecting some information or updating
some.
28
AKTU Questions-

 Write the disadvantages of file system. Explain how these disadvantages can
overcome in database management system.
 Describe the different types of database users and their responsibilities over
the DBMS.
 Who are database administrators? What are the functions of DBA?

29
 Placement Questions-

• What is database management system? Write capabilities of database

management system.
• Write the advantage and disadvantage of DBMS.
• Write the major components of DBMS.
• What do you mean by File System? Explain
• Write the difference between database system and file system.
• Discuss the problem caused by data redundancies. Can data redundancies be
completely eliminated when the database approach is used?
• Discuss the role of DBA in database management system.
• Write the functions of DBA.

30
THANK YOU
Database Management System
KCS 501
Computer Science V Sem
Lecture 2- Database System Concept and
Architecture

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering
and Research, Prayagraj
DBMS Architecture-

 The architecture of DBMS packages has evolved from

early DBMS software package which were tightly
integrated system, to the modern DBMS packages that
are modular in design, with a client / server system
architecture.
Client Server Architecture -

 Two modules are there – Client Module and Server Module.

 Client Module – typically designed for user workstation or PC.
 Application programs & user interfaces that access the database
run in the client module.
 Client module handles user interaction & provides the user
friendly interfaces such as forms or menu based GUIs.

 Server Module – It typically handles data storage , access , search

& other functions.
 DATA MODEL -

 It is a collection of concepts that can be used to describe the

structure of a database – provides the necessary means to
achieve this abstraction.
 By structure means the datatype, relationships & constraints
that should hold for the data.
 Host data models also include a set of basic operations for
specifying retrievals & updates on the database.
 Categories of Data Model –
 High Level or Conceptual.
 Representational Or Implementation.
 Network & Hierarchical Models.
Types of Data Model
Cont.
E-R Model

Works
Employee Project
on

Employee_ Project
Employee_id Project_id
name Budget
Relational Model

 The relational model uses a collection of tables to

represent both data and the relationships among those
data. Each table has multi- ple columns, and each
column has a unique name. Following figure presents a
sample relational database comprising three tables: One
shows details of bank customers, the second shows
accounts, and the third shows which accounts belong
to which customers.
Cont.
Hierarchical Model
Cont.
Network Model
DBMS Architecture-
 DBMS design depends upon its architecture. The basic client /
server architecture is used to deal with a large number of PCs ,
web servers, database servers and other components that are
connected with networks.

 The client/ server architecture consists of many PCs and a

workstation which are connected via the network.

 DBMS architecture depends upon how users are connected to the

database to get their request done.
Types of DBMS Architecture-
 Database architecture can be seen as a single tier or multi-tier.
But logically, database architecture is of two types like:

 1-tier architecture

 2-tier architecture

 3-tier architecture.
1 Tier Architecture -
 In this architecture, the database is directly available to the
user. It means the user can directly sit on the DBMS and uses it.

 Any changes done here will directly be done on the database

itself. It doesn’t provide a handy tool for end users.

 It uses for development of the local application , where

programmers can directly communicate with the database for
the quick response.
2 Tier Architecture-
 It is same as basic client server.
 Applications on the client end can directly communicate with
the database at the server side.
 For this interaction , API’s like: ODBC, JDBC are used.
 User interfaces and application programs are run on the client
side.
 The server side is responsible to provide the functionalities
like: query processing and transaction management.
Cont.
 To communicate with the DBMS, client-side application establishes
a connection with the server side.
 The 3-Tier architecture is used in case of large web application.
3 Tier Architecture-

 It contains another layer between the client and server.

 In this architecture , client cannot directly communicate with
the server.
 The goal of the 3 schema architecture is to separate the user
applications & the physical database.
 The Application on the client end interacts with an application
server which further communicates with the database system.
 End users has no idea about the existence of the database
beyond the application server.
 3 Tier Architecture
 The 3-Tier architecture is used in case of large web application.
 INTERNAL LEVEL -

 It is the internal schema describing the physical

storage structure if database.

 It uses physical data model & describes complete

details of data storage & access path for the
database.
 CONCEPTUAL LEVEL -

 Has conceptual schema which describes the structure of

whole database.

 It hides details of physical storage & describes only

entities data type, relationships, user operation &
constraints.

 This implementation conceptual schema is often based on

a conceptual schema design in a high level data model.
 EXTERNAL OR VIEW LEVEL -

 It includes a number of external schemas or user views.

 Each external schema describes the part of the database

that a particular user group is interested in & hides the
rest of the database from the User group.

 Each external schema is typically implemented using a

representational data model, possibly based on an
external schema design in a high level data model.
 DATA INDEPENDENCE -

 It is capacity to change the schema at one level of a database

system without having to change the schema at the next higher
level.

 There are 2 types of data independence –

 Logical Data Independence

 Physical Data Independence

 LOGICAL DATA NDEPENDENCE -

 It is capacity to change the conceptual schema without having

to change external schemas or application programs.

 Ex- we may change conceptual schema to expand the database

(by adding a record type or data item) , to change constraints
or to reduce the database (by removing a record type or data
item).

 After the conceptual schema undergoes a logical reorganization

application programs that reference the external schema
constructs must work as before.
 PHYSICAL DATA INDEPENDENCE -

 It is the capacity to change the internal schema without having to

the change the conceptual schema.

 Changes in Internal schemas may be needed when some physical

files has to be reorganize for better performance.
ex – Changing File Organization from B to B+.

 Physical Data Independence exists in most databases & file

environments in which the exact location of data on disk, hardware
details of storage encoding, placement, compression , merging of
records & so on are hidden form the user.
 Database Management System
KCS 501
B-Tech - V Sem
Lecture 3- DBMS Languages and DBMS Interfaces

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research, Prayagraj
UNIT 1-AKTU Syllabus
 Introduction: Overview.
 Database System vs File System.
 Database System Concept and Architecture.
 Data Model Schema and Instances.
 Data Independence and Database Language and Interfaces.
 Data Definitions Language(DDL), Data Manipulation Language(DML).
 Overall Database Structure.
 Data Modelling Using the Entity Relationship Model: ER Model Concepts.
 Notation for ER Diagram.
 Mapping Constraints.
 Keys, Concepts of Super Key, Candidate Key, Primary Key.
 Generalization, Aggregation.
 Reduction of an ER Diagrams to Tables.
 Extended ER Model, Relationship of Higher Degree.
23-09-2023 2
COURSE OUTCOME(CO1)-

 Learn Basics of databases and apply it for real life applications.

23-09-2023 3
LECTURE OUTLINE (CO1)

 DBMS Languages
 Data definition Languages
 Data Manipulation Languages
 Data Control Languages
 Transaction Control languages
 DBMS Interfaces
 AKTU Questions
 Placement Questions

23-09-2023 4
DBMS Languages -

DBMS
Languages

Data Control Data Transaction

Data Definition
Language(DCL) Manipulation Control
Language(DDL)
Language(DML) Language(TCL)

23-09-2023 5
 Data Definition Language (DDL) -

• DDL stands for Data Definition Language. It is used to define database

structure or pattern.

• It is used to create schema, tables, indexes, constraints, etc. in the

database.

• Using the DDL statements, you can create the skeleton of the
database.

• Data definition language is used to store the information of metadata

like the number of tables and schemas, their names, indexes, columns
in each table, constraints, etc.
23-09-2023 6
Data Definition Language (DDL) -
Here are some tasks that come under DDL:
• Create: It is used to create objects in the database.
• Alter: It is used to alter the structure of the database.
• Drop: It is used to delete objects from the database.
• Truncate: It is used to remove all records from a table.
• Rename: It is used to rename an object.
• Comment: It is used to comment on the data dictionary.

23-09-2023 7
 Data Manipulation Language(DML)-

 DML stands for Data Manipulation Language. It is used for accessing and
manipulating data in a database. It handles user requests.
Here are some tasks that come under DDL:
• Select: It is used to retrieve data from a database.
• Insert: It is used to insert data into a table.
• Update: It is used to update existing data within a table.
• Delete: It is used to delete all records from a table.
• Merge: It performs UPSERT operation, i.e., insert or update operations.
• Call: It is used to call a structured query language or a Java subprogram.
• Explain Plan: It has the parameter of explaining data.
• Lock Table: It controls concurrency.
23-09-2023 8
 Data Control Language (DCL)
• DCL stands for Data Control Language. It is used to retrieve the stored
or saved data.
• The DCL execution is transactional. It also has rollback parameters.
 (But in Oracle database, the execution of data control language does
not have the feature of rolling back.)

Here are some tasks that come under DCL:

• Grant: It is used to give user access privileges to a database.
• Revoke: It is used to take back permissions from the user.
23-09-2023 9
Transaction Control Language(TCL)-

 TCL is used to run the changes made by the DML statement. TCL
can be grouped into a logical transaction.

Here are some tasks that come under TCL:

• Commit: It is used to save the transaction on the database.

• Rollback: It is used to restore the database to original since the
last Commit.
23-09-2023 10
23-09-2023 11
DBMS INTERFACES
DBMS INTERFACES-

23-09-2023 13
MENU BASED INTERFACES -
 These interfaces present the user with lists of options (called
menus) that lead the user through the formation of a request.
 Pull-down menus are a very popular technique in Web based
interfaces.
 They are also often used in browsing interface which allow a user
to look through the contents of a database in an exploratory and
unstructured manner.

23-09-2023 14
FORMS BASES INTERFACES-
 A forms-based interface displays a form to each user.
 Users can fill out all of the form entries to insert new data, or
they can fill out only certain entries, in which case the DBMS
will redeem same type of data for other remaining entries.
 Forms are usually designed or created and programmed for
the users.
 Many DBMSs have forms specification languages which are
special languages that help specify such forms.

23-09-2023 15
 Example: SQL* Forms is a form-based language that specifies
queries using a form designed in conjunction with the relational
database schema.

23-09-2023 16
GRAPHICAL USER INTERFACES-
A GUI typically displays a schema to the user in
diagrammatic form.

 Theuser then can specify a query by manipulating

the diagram. In many cases, GUIs utilize both
menus and forms.

 MostGUIs use a pointing device such as mouse, to

pick a certain part of the displayed schema
diagram. 23-09-2023 17
23-09-2023 18
 NATURAL LANGUAGE INTERFACES-
 It accept request written in English or some other
language and attempt to understand them.
 It has its own schema, which is similar to the database
conceptual schema as well as a dictionary of
important words.

23-09-2023 19
SPEECH INPUT AND OUTPUT INTERFACES –

 Applications with limited vocabularies such as

inquiries for telephone directory, flight
arrival/departure, and bank account
information are allowed speech for input and
output to enable ordinary folks to access this
information.

23-09-2023 20
INTERFACES FOR PARAMETRIC USERS-

Parametric users are users that have a

small set of operations that need to be
performed and that too repeatedly.

 System Analysts & programmers design and implement a

special interface for each known class of naïve users.
 Usually a small set of abbreviated commands is included
, with the goal of minimizing the number of keystrokes
required for each request.
 INTERFACES FOR DBA-
 Most database system contains privileged commands that can be used
only by the DBA’s staff.
 These include commands for creating accounts, setting system
parameters, granting account authorization, changing a schema,
reorganizing the storage structures of a databases.

23-09-2023 22
AKTU QUESTIONS-
 Identify various types if DBMS Languages an list their applications.(2017-18)
 Describe the classification of database Language. Which type of language is SQL?
 Clearly explain the DDL, DML with suitable examples.(2013-14)
 Explain DBMS interfaces,

23-09-2023 23
Database Management System
Lecture 4- Overall Database Structure

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research, Prayagraj
 DATABASE STRUCTURE -

DBMS is a software that allows access to data stored in a

database and provides an easy and effective method of –
• Defining the information.
• Storing the information.
• Manipulating the information.
• Differentiating access permissions for different users.
Database System Structure

Database System Structure

A database system is partitioned into modules that deal with each

of the responsibilities of the overall system. The functional compo-
nents of a database system can be broadly divided into the storage
manager and the query processor components.
1.Storage Manager
2.Query Processor

1
 Database System Structure

Storage Manager

A storage manager is a program module that provides the interface

between the low level data stored in the database and the applica-
tion programs and queries submitted to the system. The storage
manager is responsible for storing, retrieving, and updating data in
the database. The components of storage manager includes the
following modules:

2
 Database System Structure
Storage Manager(cont.)

Authorization and integrity manager: It checks the integrity con-

straints and the authority of users to access data.
Transaction manager: It ensures that the database remains in a consis-
tent (correct) state despite system failures, and that concurrent transaction
executions proceed without conflicting.
File manager: It manages the allocation of space on disk storage and
the data structures used to represent information stored on disk.
Buffer manager: It is responsible for fetching data from disk storage
into main memory, and deciding what data to cache in main memory. The
buffer manager is a critical part of the database system, since it enables
the database to handle data sizes that are much larger than the size of
main memory.
Database System Structure

Storage Manager(cont.)

The storage manager implements several data structures as part of

the physical system implementation:

• Data files, which store the database itself.

• Data dictionary, which stores metadata about the structure
of the database, in particular the schema of the database.
• Indices, which provide fast access to data items that hold
particular values.

4
 Database System Structure
Query Processor

The query processor includes the following components:-

DDL interpreter: It interprets DDL statements and records the
definitions in the data dictionary.
D M L compiler: It translates DML statements in a query language
into an evaluation plan consisting of low-level instructions that the
query evaluation engine understands. The DML compiler also per-
forms query optimization.
Query evaluation engine: It executes low-level instructions gen-
erated by the DML compiler.
Database System Structure

6
Database Management System

Lecture 5 – Introduction to ER Diagram

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research, Prayagraj
 ENTITIES -
 It is the basic object which is a thing in the real world
with an independent existence.
 An entity may be an object with a physical existence
(ex – Person, Car , House , Employee etc.)
 It may be an object with a conceptual existence.( ex-
A Company, A job, A university course)
 Entity is represented as
ATTRIBUTES -

 They can be defined as Qualifiers to entities

 It explains additional properties of entities.

 Eg. An employee entity may be qualified by attributes

like name, gender, address, salary , job etc.

 It has values that is stored in the database.

TYPES OF ATTRIBUTES-
SIMPLE ATTRIBUTE -
 Itis defined as the attribute that cannot be further
decomposed.
Eg. Age Attribute
COMPOSITE ATTRIBUTES-

 Composite attributes are those attributes which are composed of many other simple
attributes.
 Ex. Address is composed of Street, City, Country, State
SINGLE VALUED ATTRIBUTE -
 The attribute that has only one value for the particular entity is
called Single Value Attribute.
 Ex- Age Attribute
 MULTI VALUED ATTRIBUTE -
• The attribute that can have more than one value for a
particular Entity.
• Ex- Colour Attribute of Vehicle.
• Ex- College Degrees Attribute
of person.
DERIVED ATTRIBUTES -

 Derived attributes are those attributes which can be

derived from other attribute(s).
KEY ATTRIBUTES -
 Key attributes are those attributes which can identify an entity uniquely
in an entity set.
 In ER Diagram Key Attribute is represented by Underline.
NULL VALUES -
 In some cases a particular entity may not have an applicable values for an attribute.
 Ex – Apartment Number, Middle Name
 For such cases ‘NULL’ is created.
 NULL can be used to if we so not know the value of attribute for a particular entity.
 NULL can be not applicable or unknown.
 ENTITY TYPES-
 Database usually contains groups of entities that are similar.
 An Entity Type defines a collection of entities that have the
same attribute.

ENTITY SET-
• An Entity is an object of Entity Type and a set of all entities
is called an entity set. For Example, E1 is an entity having
Entity Type Student and the set of all students is called
Entity Set. In ER diagram, Entity Type is represented as:
• An entity type describes the schema or Intension for a set of
entities that share the same structure.
• The collection of a particular entity type is grouped into
entity set , which is also called the Extension of the Entity
Type.
Types of Entity

1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does
not depend on other Entity in the Schema. It has a primary key, that helps in
identifying it uniquely, and it is represented by a rectangle. These are called
Strong Entity Types.

2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the
entity set. But some entity type exists for which key attributes can’t be
defined. These are called Weak Entity types.

For Example, 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 Employee
will be Identifying Entity type for Dependent, which means it is Strong Entity
Type.
A weak entity type is represented by a Double
Rectangle. The participation of weak entity types is
always total. The relationship between the weak entity
type and its identifying strong entity type is called
identifying relationship and it is represented by a
double diamond.
RELATIONSHIP-

 Whenever an attribute of one entity type refers to

another entity type some Relationship exists.

 In ER diagrams , relationship types are displayed as

Diamond shaped Boxes, which are connected by straight
lines to the rectangular boxes representing the
participating entity types.

 The relationship name is displayed in the diamond shaped

box.
 Example-
 ‘Enrolled in’ is a relationship that exists between
entities Student and Course.
RELATIONSHIP SET -

 A relationship set is a set of relationships of same type.

Degree of a Relationship Set-

 The number of entity sets that participate in a

relationship set is termed as the degree of that
relationship set. Thus,

Degree of a relationship set = Number of entity sets participating

in a relationship set
TYPES OF RELATIONSHIP SETS-
UNARY REALTIONSHIP SET -
 Unary relationship set is a relationship set where only one entity set
participates in a relationship set.
BINARY RELATIONSHIP TYPE-
 Binary relationship set is a relationship set where two entity sets
participate in a relationship set.
 Most common type of relationship.
TERNARY RELATIONSHIP TYPE-
 Ternary relationship set is a relationship set where three entity sets
participate in a relationship set.
ROLE NAMES -
 Each entity type that participate in a relationship type plays a
particular role in the relationship.

 Role names signifies the role that participating entity from the
entity type plays in each relationship instance and helps to
explain what the relationship means.

 Ex – In the WORKS_FOR relationship type, EMPLOYEE plays the

role of employee or worker & DEPARTMENT plays the role of
department or employer.
RECURSIVE RELATIONSHIPS -
 In some cases, the same entity type participates more than once in a relationship type in different
roles.

 In such cases the role name becomes essential for distinguishing the meaning of each participation.

 Such relationship types are called Recursive Relationships.

Example of recursive Relationship

•The person who is a supervisor for many other employees also

come under employees category
•Student can be a class monitor and handle other students but a
person who is working as a class leader is itself a student of the
class and hence a class monitor has a recursive relationship of
entity student
Constraints on Relationship Types-

 Relationships types usually have certain constraints

that limit the possible combinations of entities that
may participation in the corresponding relationship
set.

 Two types of Relationship Constraints –

 Cardinality Ratio
 Participation Ratio
CARDINALITY RATIO -

 Cardinality defines the number of entities in one entity set, which can
be associated with the number of entities of other set via relationship
set.

 One to One Relationship (1:1) Type

 One to Many Relationship(1:N) Type

 Many to Many Relationship(M:N) Type

 Many to One Relationship(M:1) Type

One to One Relationship (1:1) Type -
 In this type of cardinality mapping, an entity in A is connected to at most one
entity in B. Or we can say that a unit or item in B is connected to at most one
unit or item in A.
One to One Relationship (1:1) Type -

 In a particular hospital, the surgeon department has one

head of department. They both serve one-to-one
relationships.
One to Many Relationship (1:N) Type-
 In this type of cardinality mapping, an entity in A is associated with any
number of entities in B. Or we can say that one unit or item in B can be
connected to at most one unit or item in A.
One to Many Relationship (1:N) Type-
Example:
 In a particular hospital, the surgeon department has multiple doctors.
They serve one-to-many relationships.
Many to Many Relationship (M:N) Type
-
 In this type of cardinality mapping, an entity in A is
associated with any number of entities in B, and an entity in
B is associated with any number of entities in A.
Many to Many Relationship (M:N) Type
-
Example:
 In a particular company, multiple people work on multiple
projects. They serve many-to-many relationship.

Work
Employee Project
s on
Many to One Relationship (M:1) Type-
 In this type of cardinality mapping, an entity in A is
connected to at most one entity in B. Or we can say a
unit or item in B can be associated with any number
(zero or more) of entities or items in A.
Many to One Relationship (M:1) Type-
Example:
 In a particular hospital, multiple surgeries are done by a single surgeon.
Such a type of relationship is known as a many-to-many relationship.
PARTICIPATION CONSTRAINTS -
 The participation constraint specifies whether the existence of an
entity depends on its being related to another entity via the
relationship type.

 This constraints specifies the minimum number of relationship

instances that each entity can participate in and is sometimes called
Minimum Cardinality Constraint.

 There are two types of participation constraints –

 Total Participation
 Partial Participation
TOTAL PARTICIPATON -

 Each entity in the entity set is involved in at least

one relationship in a relationship set i.e. the number
of relationship in every entity is involved is greater
than 0.
 Each entity in the entity set must participate in the
relationship. If each student must enroll in a course,
the participation of students will be total. Total
participation is shown by a double line in the ER
diagram
 Total Participation is represented by double line in
ER diagram.
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 students, the
participation in the course will be partial.
Steps to Draw E-R diagram
Usually the following six steps are followed to generate E-R Models.
a) Identify the entities: Look for general nouns in requirement specification
document which are of business interest to business
users
b) Find relationships: Identify the natural relationship and their cardinalities
between the entities
c) Identify the key attributes for every entity: Identify the attribute or set of attributes
which can identify instance of entity uniquely
d) Identify other relevant attributes: Identify other attributes which are interest to
business users and want to store the information in database
e) Complete E-R diagram: Draw complete E-R diagram with all attributes including
primary key
f) Review your results with your business users - Look at the list of attributes
associated with each entity to see if anything has been omitted.
Case study 1
An university has many departments• Each
department has multiple instructors; one among
them is the head of the department
• An instructor belongs to only one department
• Each department offers multiple courses, each
of which is
taught by a single instructor
• A student may enroll for many courses offered
by different departments
Step 1: Identify the Entities Generally the entities will have multiple
instances in a given business scenario. As per this guideline, we can identify
the following entities:
1. DEPARTMENT
2. COURSE
3. INSTRUCTOR
4. STUDENT
“ Head of the department” is NOT an Entity. It is a relationship between the
Instructor and department entities.

Step 2: Find relationships We can derive the following relationships:

1. The department offers multiple courses and each course belongs to only
one department, hence cardinality between department and course is
one to many.
Step 3: Identify the key attributes
1. DName (Department Name) which identifies the department uniquely
will be the key attribute for “DEPARTMENT” entity.
2. STUDENT# (Student Number) is the key attribute for “STUDENT” entity.
3. IName (Instructor Name) is the key attribute for “INSTRUCTOR” entity.
4. COURSE# (Course Number) is the key attribute for COURSE entity.

Step 4: Identify other relevant attributes

1. For the “ Department” entity, the relevant attribute other than “
Department Name” is “ Location”.
2. For the “ Course” entity, the relevant attributes other than “ Course
Number” are “ Course Name”, “Duration” and “Pre Requisite”.
3. For the “Instructor” entity, the relevant attributes other than
“Instructor Name” are “ Room Number” and “Telephone Number”.
4. For the “Student” entity, the relevant attributes other than “Student
Number” are “Student Name” and “ Date of Birth”.
Step 5: Complete E-R diagram After considering all the above mentioned guidelines
one can generate the E-R Model for the university database
Case Study 2 (ER diagram)
Assume in a city• There are multiple banks and
each bank has many branches. Each branch has
multiple customers
• Customers have various types of accounts
• Some customers also had taken different types
of loans from these bank
branches
• One customer can have multiple accounts and
loans
Step 1: Identify the entities Generally the entities will have multiple instances in a
given business scenario. As per this guideline, we can identify the following entities:
1. BANK
2. BRANCH
3. LOAN
4. ACCOUNT
5. CUSTOMER

Step 2: Find Relationships We can derive the following relationships:

1. One bank has many branches and each branch belongs to only one bank, hence
the cardinality between bank and branch is one to many.
2. One branch offers many loans and each loan is associated with one branch, hence
the cardinality between branch and loan is one to many.
3. One branch maintains multiple accounts and each account is associated to one
and only one branch, hence the cardinality between branch and account is one to
many.
4. One Loan can be availed by multiple customers, and each customer can avail
multiple loans, hence the cardinality between loan and customer is many to
many.
5. One customer can hold multiple accounts, and each account can be held by
multiple customers, hence the cardinality between customer and account is many
to many.
Step 3: Identify the key attributes
1. BankCode (Bank Code) is the key attribute for the entity “Bank”, as it
identifies the bank uniquely.
2. Branch# (Branch Number) and BankCode (Bank Code) are together key
attributes for “Branch” entity.
3. Customer# (Customer Number) is the key attribute for “ Customer” entity.
4. Loan# (Loan Number) is the key attribute for “ Loan” entity.
5. Account# (Account Number) is the key attribute for “Account” entity.

Step 4: Identify other relevant attributes

1. For the “Bank” entity, the relevant attributes other than “BankCode” would
be “ Name” and “Address”.
2. For the “Branch” entity, the relevant attributes other than “Branch#” would
be “ Name” and “Address”.
3. For the “ Loan” entity, the relevant attribute other than “ Loan#” would be
“ Loan Type”.
4. For the “Account” entity, the relevant attribute other than “Account#”
would be “Account Type”.
5. For the “ Customer” entity, the relevant attributes other than “
Customer#” would be “ Name”, “Phone” and “Address”.
Step 5: Complete E-R diagram After considering all the above mentioned guidelines,
one can generate the E-R Model for above mentioned banking business scenario as
shown

Branch
Case Study 3 (ER diagram)
Assume in a university
• There are multiple libraries and each library has multiple student
members
• Students can become members to multiple libraries by paying
appropriate
membership fee
• Each library has its own set of books. Within the library these books
are
identified by a unique number
• Students can borrow multiple books from subscribed library
• Students can order books using inter-library loan. This can be
useful if a student wishes to borrow books from a library where s/ he
is not a member. The student orders the books through a library
where s/ he is a member
Step 1: Generally the entities will have multiple instances in a given business
scenario. As per this guideline, we can identify the following entities:
1. LIBRARY
2. BOOK
3. STUDENT

Step 2: Find Relationships We can derive the following relationships:

1. One library has many member students and each student can become member of
many libraries, hence the cardinality between library and student is many to
many.
2. One book belongs to only one library and one library can have multiple books,
hence cardinality between library and book is one to many.
3. One library can loan multiple books and each book can be loaned to only one
library, hence the cardinality between library and book is one to many.
4. One student can borrow multiple books and one book can be borrowed by only
one student, hence the cardinality between student and book is many to one.
Step 3: Identify the key attributes
1. Library# (library ID) is the key attribute for the entity “ Library”, as it
identifies the library uniquely.
2. Book# (book ID) and Library# are together key attributes for “Book” entity.
3. Student# (student number) is the key attribute for “Student” entity.

Step 4: Identify other relevant attributes

1. For the “ Library” entity, the relevant attributes other than “ Library#”
would be “ Library Name” and “ Location”.
2. For the “Book” entity, the relevant attributes other than “Book#” would be
“Title” and “ISBN”.
3. For the “Student” entity, the relevant attribute other than “Student#”
would be “Student Name” and “ Date of Birth”.
Step 5: Complete E-R diagram After considering all the above mentioned guidelines,
one can generate the E-R Model for above mentioned banking business scenario as
shown

Book
Database Management System KCS
501
Computer Science V Sem

Lecture 6 – Entity Types and Key Concepts

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research, Prayagraj
STRONG ENTITY TYPE -
 A strong entity is complete by itself and is not dependent on any
other entity type.
 It possess a primary key which describes each instance in the
strong entity set uniquely.
 That means any element in the strong entity set can be uniquely
identified.
 A Strong entity is represented by square with a single line.
STRONG ENTITY TYPE -
WEAK ENTITY TYPE-
 A weak entity cannot be used independently as it is dependent
on a strong entity type known as its owner entity.

 Also, the relationship that connects the weak entity to its owner
identity is called the identifying relationship.

 A weak entity always has a total participation constraint with

respect to its identifying relationship because it cannot be
identified independently of its owner identity.
WEAK ENTITY TYPE-
WEAK ENTITY TYPE-
 A weak entity may have a partial key, which is a list of attributes that
identify weak entities related to the same owner entity.

 In the ER diagram, both the weak entity and its corresponding

relationship are represented using a double line and the partial key is
underlined with a dotted line.

 In the given ER diagram, Dependent is the weak entity and it depends

on the strong entity Employee via the relationship Depends on.

 There can be an employee without a dependent in the Company but

there will be no record of the Dependent in the company systems
unless the dependent is associated with an Employee.
KEYS -
 A key allows us to identify a set of attributes i.e suffix to
distinguish entities from each other.
 Keys play an important role in the relational database.
 Keys also help to uniquely identify relationships & thus
distinguish relationships from each other.
1) Super Key
2) Candidate Key
3) Primary Key
4) Foreign Key
PRIMARY KEY -
• It is the first key used to identify one and only one instance of an entity
uniquely. An entity can contain multiple keys, as we saw in the PERSON
table
• The key which is most suitable from those lists becomes a primary key.
• For each entity, the primary key selection is based on requirements and
developers.
CANDIDATE KEY -
• A candidate key is an attribute or set of attributes that can uniquely
identify a tuple.
• Except for the primary key, the remaining attributes are considered a
candidate key. The candidate keys are as strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the primary key. The
rest of the attributes, like SSN, Passport_Number, License_Number, etc., are
considered a candidate key.
SUPER KEY -
 Super key is an attribute set that can uniquely identify a tuple. A super
key is a superset of a candidate key.
 For example: In the above EMPLOYEE table, for(EMPLOEE_ID,
EMPLOYEE_NAME), the name of two employees can be the same, but
their EMPLYEE_ID can't be the same. Hence, this combination can also
be a key.
 The super key would be
EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME)
FOREIGN KEY-
• They are the column of the table used to point to the primary key
of another table.
• Every employee works in a specific department in a company, and
employee and department are two different entities. So we can't
store the department's information in the employee table. That's
why we link these two tables through the primary key of one table.
• We add the primary key of the DEPARTMENT table, Department_Id,
as a new attribute in the EMPLOYEE table.
• In the EMPLOYEE table, Department_Id is the foreign key, and both
the tables are related.
FOREIGN KEY-
ALTERNATE KEY -

 There may be one or more attributes or a combination

of attributes that uniquely identify each tuple in a
relation.
 These attributes or combinations of the attributes are
called the candidate keys.
 One key is chosen as the primary key from these
candidate keys, and the remaining candidate key, if it
exists, is termed the alternate key
ALTERNATE KEY -

For example, employee relation has two attributes,

Employee_Id and PAN_No, that act as candidate keys. In
this relation, Employee_Id is chosen as the primary key, so
the other candidate key, PAN_No, acts as the Alternate
key.
COMPOSITE KEY-
 Whenever a primary key consists of more than one attribute, it is known as a
composite key. This key is also known as Concatenated Key.

 For example, In employee relations, we assume that an employee may be

assigned multiple roles, and an employee may work on multiple projects
simultaneously.

 So the primary key will be composed of all three attributes, namely Emp_ID,
Emp_role, and Proj_ID in combination.

 So these attributes act as a composite key since the primary key comprises
more than one attribute.
COMPOSITE KEY-
ARTIFICIAL KEY-
 The key created using arbitrarily assigned data are known as artificial
keys.

 These keys are created when a primary key is large and complex and has
no relationship with many other relations.

 The data values of the artificial keys are usually numbered in a serial
order.

 For example, The Primary Key, which is composed of Emp_ID, Emp_role, and
Proj_ID, is large in employee relations.
Database Management System KCS
501
Computer Science V Sem

Lecture 7 – Reduction of ER Diagrams to Tables

Dr Shruti Bharadwaj
Assistant Professor
United College Of Engineering and Research, Prayagraj
Reduction of an E-R Schema to Tables
Every E-R schema or diagram can be converted into set of tables. In this
section, we describe how an E-R schema can be represented by tables.
The constraints specified in an E-R diagram, such as primary keys and
cardinality constraints, are mapped to constraints on the tables
generated from the E-R diagram.
Rule-01: For Strong Entity Set With Only Simple Attributes-

Strong entity set with only simple attributes will require only one table in
relational model.
•Attributes of the table will be the attributes of the entity set.
•The primary key of the table will be the key attribute of the entity set.

Example:

1
Rule-02: For Strong Entity Set With Composite Attributes-

•A strong entity set with any number of composite attributes

will require only one table in relational model.
•While conversion, simple attributes of the composite attributes
are taken into account and not the composite attribute itself.
 Example:

Roll_ First_na Last_na House_ Stre Cit

no me me no et y

Schema : Student ( Roll_no , First_name , Last_name , House_no , Street , City )

4
Rule-03: For Strong Entity Set With Multi Valued Attributes-

A strong entity set with any number of multi valued attributes

will require two tables in relational model.
•One table will contain all the simple attributes with the primary
key.
•Other table will contain the primary key and all the multi valued
attributes.

5
Example:

Roll_no City
Mobile
Roll_no
_no

6
Rule-04: Translating Relationship Set into a Table-

A relationship set will require one table in the relational model.

Attributes of the table are-
•Primary key attributes of the participating entity sets
•Its own descriptive attributes if any.
Set of non-descriptive attributes will be the primary key.
Example:

Emp_no Dept_id since

Schema : Works in ( Emp_no , Dept_id , since )

NOTE-

If we consider the overall ER diagram, three tables will be required in relational model-
•One table for the entity set “Employee”
•One table for the entity set “Department”
•One table for the relationship set “Works in”
Rule-05: For Binary Relationships With Cardinality Ratios-

The following four cases are possible-

Case-01: Binary relationship with cardinality ratio m:n

Case-02: Binary relationship with cardinality ratio 1:n
Case-03: Binary relationship with cardinality ratio m:1
Case-04: Binary relationship with cardinality ratio 1:1

8
Case-01: For Binary Relationship With Cardinality Ratio m:n

Here, three tables will be required-

1.A ( a1 , a2 )
2.R ( a1 , b1 )
3.B ( b1 , b2 )

8
Case-02: For Binary Relationship With Cardinality Ratio 1:n

Here, three tables will be required-

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

8
Case-03: For Binary Relationship With Cardinality Ratio m:1

Here, three tables will be required-

1.AR( a1 , a2 , b1)
2.B ( b1 , b2 )

8
Case-04: For Binary Relationship With Cardinality Ratio 1:1

Here, two tables will be required. Either combine ‘R’ with ‘A’ or ‘B’

Way-01:
1.AR ( a1 , a2 , b1 )
2.B ( b1 , b2 )

Way-02:
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
8
Rule-06: For Binary Relationship With Both Cardinality
Constraints and Participation Constraints-

•Cardinality constraints will be implemented as discussed in Rule-05.

•Because of the total participation constraint, foreign key
acquires NOT NULL constraint i.e. now foreign key can not be null.
Case-01: For Binary Relationship With Cardinality
Constraint and Total Participation Constraint From One
Side-

Because cardinality ratio = 1 : n , so we will combine the

entity set B and relationship set R.
Then, two tables will be required-
1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )

Because of total participation, foreign key a1 has acquired

NOT NULL constraint, so it can’t be null now.
Case-02: For Binary Relationship With Cardinality
Constraint and Total Participation Constraint From Both
Sides-

If there is a key constraint from both the sides of an entity

set with total participation, then that binary relationship is
represented using only single table.

Here, Only one table is required.

•ARB ( a1 , a2 , b1 , b2 )
Rule-07: For Binary Relationship With Weak Entity Set-

•Weak entity set always appears in association with identifying

relationship with total participation constraint.

Here, two tables will be required-

1.A ( a1 , a2 )
2.BR ( a1 , b1 , b2 )
Reduce (convert) the following ER diagram to relational schema
 ER components Given component Result
Strong Entity Set (a) STUDENT (a) STUDENT (Student_ID, Student_Name, DOB, Address)

Rule: Strong entity set can be directly converted (b) SUBJECT (b) SUBJECT (Subject_ID, Subject_Name, Teacher)
into table.
(c) CLASS (C) CLASS (Class_ID, Class_Name)

Derived attribute Age in STUDENT table No changes

Rule: No need to create a column in the table for

derived attribute.

Composite attribute Address in STUDENT table STUDENT (Student_ID, Student_Name, DOB, Door, Street, City, Pin)

Rule: Replace the composite attribute with its

component attributes.

1-1, 1-n, and n-1 Relationships Attends (1-1 from STUDENT to CLASS) CLASS (Class_ID, Class_Name, Student_ID)

Rule: Include the primary key of one side entity Studies (1-n from STUDENT to SUBJECT) SUBJECT (Subject_ID, Subject_Name, Teacher, Student_ID)
set as the foreign key of other side entity set.

Descriptive attribute DateOfJoin, Hours# of Attends relationship. CLASS (Class_ID, Class_Name, Student_ID, DateOfJoin, Hours#)

Rule: An attribute that is part of a relationship

is descriptive. Include the descriptive attributes
to 1 side as shown above.

Weak entity set (d) SECTION SECTION (Section_ID, Section_Name, Class_ID)

Rule: Weak entity set is totally participated

(existence dependent) on the strong entity set.
Include the primary key of strong entity set into
the weak entity set as foreign key.

Weak relationship Has No changes

Rule: No need to create as a table. If created,

then the table is redundant.
Final set of relation schemas: (Primary keys are
underlined)
STUDENT (Student_ID, Student_Name, DOB, Door, Street, City, Pin)

CLASS (Class_ID, Class_Name, Student_ID, DateOfJoin, Hours#)

Student_ID is the foreign key refers STUDENT table

SUBJECT (Subject_ID, Subject_Name, Teacher, Student_ID)

Student_ID is the foreign key refers STUDENT table

SECTION (Section_ID, Class_ID, Section_Name)

Class_ID is the foreign key refers CLASS table
 Exercise
Exercise

Question-1(a)

Construct an E-R diagram for a car-insurance company whose cus- tomers own
one or more cars each. Each car has associated with it zero to any number of
recorded accidents.
 Exercise
Solution An E-R diagram for a car-insurance company is
the following:-
 Exercise

Question-1(b)

Construct appropriate tables for the E-R diagrams.

Solution
Appropriate tables for the E-R diagrams
(1) Car insurance tables:

person (driver-id, name, address)

car (license, year, model)
accident (report-number, date, location)
participated(driver-id, license, report-number, damage-amount)
 Exercise

Question-2(a)

Construct an E-R diagram for a hospital with a set of patients and

a set of medical doctors. Associate with each patient a log of the
various tests and examinations conducted.
 Exercise
Solution An E-R diagram for a hospital with a set of patients and
a set of medical doctors is the following:-
 Exercise

Question-2(b)

Construct appropriate tables for the E-R diagrams.

Solution
Appropriate tables for the E-R diagrams
Hospital tables:
patients (patient-id, name, insurance, date-admitted, date-
checked-out) doctors (doctor-id, name, specialization)
test (testid, testname, date, time,
result) doctor-patient (patient-id,
doctor-id) test-log (testid, patient-id)
performed-by (testid, doctor-id)
DATABASE MANAGEMENT SYSTEM
KCS-501
B.TECH 3rd YEAR

UNIT 1 – Extented Entity Relationship Model - Lecture 8

Dr Shruti Bharadwaj
Assistant Professor
Department of CSE
United College of Engg. and Research, Prayagraj, India
 Aggregation
• Aggregation is an abstraction through which relationships are
treated as a higher level entity sets and can participate in
relationships.
• Aggregation allows us to indicate that a relationship set
participates in another relationship sets.
Extended E-R Features

Example: Consider the following E-R diagram:-

 Extended E-R Features
• There is redundant information in the above figure, however,
since every employee, branch, job combination in manages is
also in works- on. If the manager were a value rather than an
manager entity,we could instead make manager a multi-valued
attribute of the rela- tionship works-on.
• Using aggregation, the relationship set works-on (relating the
entity sets employee, branch, and job) is treated as a higher-level
entity set called works-on.
• Such an entity set is treated in the same manner as is any
other entity set. We can then create a binary relationship
manages between works-on and manager to represent who
manages what tasks. It is shown in the following figure:-
Extended E-R Features