DATABASE MANAGEMENT SYSTEMS

UNIT I: Introduction

Syllabus:
Introduction: Database system, Characteristics (Database Vs File System), Database
Users (Actors on Scene, Workers behind the scene), Advantages of Database systems,
Database applications. Brief introduction of different Data Models; Concepts of Schema,
Instance and data independence; Three tier schema architecture for data independence;
Database system structure, environment,ER-MODEL.
 UNIT – I : INTRODUCTION

Introduction

The information storage and retrieval has become very important in our day-to-day life. The
old era of manual system is no longer used in most of the places. For example, to book your
airline tickets or to deposit your money in the bank the database systems may be used. The
database system makes most of the operations automated. A very good example for this is the
billing system used for the items purchased in a super market. Obviously this is done with the
help of a database application package. Inventory systems used in a drug store or in a
manufacturing industry are some more examples of database. We can add similar kind of
examples to this list.
Apart from these traditional database systems, more sophisticated database systems are used in
the Internet where a large amount of information is stored and retrieved with efficient search
engines. For instance, http://www.google.com is a famous web site that enables users to
search for their favorite information on the net. In a database we can store starting from text
data to very complex data like audio, video, etc.

1.1 Database Management Systems (DBMS)

A database is a collection of related data stored in a standard format, designed to be shared by

multiple users. A database is defined as “A collection of interrelated data items that can be
processed by one or more application programs”.
A database can also be defined as “A collection of persistent data that is used by the application
systems of some given enterprise”. An enterprise can be a single individual (with a small
personal database), or a complete corporation or similar large body (with a large shared
database), or anything in between.

Example: A Bank, a Hospital, a University, a Manufacturing company

Data
Data is the raw material from which useful information is derived. The word data is the plural
of Datum. Data is commonly used in both singular and plural forms. It is defined as raw facts
or observations. It takes variety of forms, including numeric data, text and voice and images.
Data is a collection of facts, which is unorganized but can be made organized into useful
information. The term Data and Information come across in our daily life and are often
interchanged.
Example: Weights, prices, costs, number of items sold etc.
Information
Data that have been processed in such a way as to increase the knowledge of the person who
uses the data. The term data and information are closely related. Data are raw material
resources that are processed into finished information products. The information as data that
has been processed in such way that it can increase the knowledge of the person who uses it.
In practice, the database today may contain either data or information.
Data Processing
The process of converting the facts into meaningful information is known as data processing.
Data processing is also known as information processing.
Metadata
Data that describe the properties or characteristics of other data.

1
 UNIT – I : INTRODUCTION

Data is only become useful when placed in some context. The primary mechanism for
providing context for data is Metadata. Metadata are data that describe the properties, or
characteristics of other data. Some of these properties include data definition, data structures
and rules or constraints. The Metadata describes the properties of data but do not include that
data.

1.2 Database System Applications

Databases are widely used. Here are some representative applications:

1. Banking: For customer information, accounts, and loans, and banking transactions.
2. Airlines: For reservations and schedule information. Airlines were among the first to use
databases in a geographically distributed manner - terminals situated around the world
accessed the central database system through phone lines and other data networks.
3. Universities: For student information, course registrations, and grades.
4. Credit card transactions: For purchases on credit cards and generation of monthly
statements.
5. Telecommunication: For keeping records of calls made, generating monthly bills,
maintaining balances on prepaid calling cards, and storing information about the
communication networks.
6. Finance: For storing information about holdings, sales, and purchases of financial
instruments such as stocks and bonds.
7. Sales: For customer, product, and purchase information.
8. Manufacturing: For management of supply chain and for tracking production of items in
factories, inventories of items in warehouses / stores, and orders for items.
9. Human resources: For information about employees, salaries, payroll taxes and benefits,
and for generation of paychecks.

1.3 File Systems Versus A DBMS (Characteristics)

In earlier days, the databases were created directly on top of file systems. File system has many
disadvantages.

1. Not enough primary memory to process large data sets. If data is maintained in other
storage devices like disks, tapes and bringing relevant data to main memory, it increases
the cost of performance. Problem in accessing the large data due to addressing the data
using 32 bit or 64 bit mode addressing mechanism.
2. Programs must be written to process the user request to process the data stored in
files which are complex in nature because of large volume of data to be searched.
3. Inconsistent data and complexity in providing concurrent accesses.
4. Not sufficiently flexible to enforce security policies in which different users
have permission to access different subsets of the data.

A DBMS is a piece of software that is designed to make the preceding tasks easier. By storing
data in a DBMS, rather than as a collection of operating system Files, we can use the DBMS's
features to manage the data in a robust and efficient manner.

2
 UNIT – I : INTRODUCTION

1.4 Advantages of DBMS

One of the main advantages of using a database management system is that the organization
can exert via the DBA, centralized management and control over the data. The database
administrator is the focus of the centralized control.

The following are the major advantages of using a Database Management System (DBMS):
Data independence: Application programs should be as independent as possible from details
of data representation and storage. The DBMS can provide an abstract view of the data to
insulate application code from such details.

Efficient data access: A DBMS utilizes a variety of sophisticated techniques to store and
retrieve data efficiently. This feature is especially important if the data is stored on external
storage devices.

Data integrity and security: The DBMS can enforce integrity constraints on the data. The
DBMS can enforce access controls that govern what data is visible to different classes of users.

Data administration: When several users share the data, centralizing the administration of data
can offer significant improvements. It can be used for organizing the data representation to
minimize redundancy and for fine-tuning the storage of the data to make retrieval efficient.

Concurrent access and crash recovery: A DBMS schedules concurrent accesses to the data in
such a manner that users can think of the data as being accessed by only one user at a time.
Further, the DBMS protects users from the effects of system failures. .

Reduced application development time: Clearly, the DBMS supports many important
functions that are common to many applications accessing data stored in the DBMS.

1.5 Disadvantages of DBMS

The disadvantage of the DBMS system is overhead cost. The processing overhead introduced
by the DBMS to implement security, integrity, and sharing of the data causes a degradation of
the response and throughput times. An additional cost is that of migration from a traditionally
separate application environment to an integrated one.

Even though centralization reduces duplication, the lack of duplication requires that the
database be adequately backup so that in the case of failure the data can be recovered.

Backup and recovery operations are complex in a DBMS environment, and this is an increment
in a concurrent multi-user database system. A database system requires a certain amount of
controlled redundancies and duplication to enable access to related data items.

1.6 Data Models

A data model is a collection of high-level data description constructs that hide many low-level
storage details. A DBMS allows a user to define the data to be stored in terms of a data model. Most
database management systems today are based on the relational data model.

A schema is a description of a particular collection of data, using the given data model. The
relational model of data is the most widely used model today.

3
 UNIT – I : INTRODUCTION

Main concept: relation, basically a table with rows and columns.

Every relation has a schema, which describes the columns, or
fields.
Data Model is a collection of high-level data description constructs that hide many low-level
storage details. A DBMS allows a user to define the data to be stored in terms of a data model. Most
database management systems today are based on the Relational data model. Relational models
include – IBM’s DB2, Informix, Oracle, Sybase, Microsoft’s Access, Foxbase, Paradox, Tandem and
Teradata.

1.7 Categories of data models

 Conceptual (high-level, semantic) data models: Provide concepts that are close to the way
many users perceive data (Also called entity-based or object-based data models).
 Physical (low-level, internal) data models: Provide concepts that describe details of how data
is stored in the computer.
 Implementation (representational) data models: Provide concepts that fall between the
above two.

1. Hierarchical models:
Advantages:
 Hierarchical model is simple to construct and operate on.
 Corresponds to a number of natural hierarchical organized domains – e.g., assemblies
in manufacturing, personal organization in companies.
 Language is simple; uses constructs like GET, GET UNIQUE, GET NEXT, GET NEXT
WITHIN PARENT etc.,
Disadvantages:
 Navigational and procedural nature of processing.
 Database is visualized as a linear arrangement of records.
 Little scope for “query optimization”.
 One-to-many relationships.

2. Network model:
Advantages:

 Network model is able to model complex relationships and represents semantics of

add/delete on the relationships.
 Can handle most situations for modeling using record types and relationship types.
 Language is navigational; uses constructs like FIND, FIND member, FIND owner, FIND
NEXT within set, GET etc. Programmers can do optimal navigation through the database.
Disadvantages:

 Navigational and procedural nature of processing.

 Database contains a complex array of pointers that are expensive and difficult to update
when inserting and deleting.
 Little scope for automated “query optimization”.

4
 UNIT – I : INTRODUCTION

3. Relational model:
 A relation, basically a table with rows and columns.
 Every relation has a schema, which describes the columns, or fields.
 Student information in a university database may be stored in a relation with the
following schema
 Students (sid: string, name: string, login: string, age: integer, gpa: real)

1.8 Levels of Abstraction in a DBMS (Three tier schema architecture )

The data in a DBMS is described at three levels of abstraction.

The database description consists of a schema at each of these three levels of abstraction.
External, Conceptual and Physical
Views describe how users see the data.
Conceptual schema defines logical
structure.
Physical schema describes the files and indexes used.

Conceptual schema:

 The conceptual schema(also called as logical schema) describes the stored data in terms of the
data model of the DBMS.
 In a relational DBMS, the conceptual schema describes all relations that are stored in the
database.
 In our sample university database, these relations contain information about entities, such as
students and faculty, and about relationships, such as students’ enrollment in courses.
Students(sid: string, name: string, login: string, age: integer, gpa:
real)
Faculty(fid: string, fname: string, salary : real)
Courses(cid: string, cname: string, credits: integer)
Rooms(nw: integer, address: string, capacity: integer)
Enrolled (sid: string, cid: string, grade: string)
Teaches (fid: string, cid: string)

5
 UNIT – I : INTRODUCTION

The choice of relations, and the choice of fields for each relation, is not always obvious, and
the process of arriving at a good conceptual schema is called conceptual database design.

Physical Schema:

 The physical schema specifies storage details.

 It summarizes how the relations described in the conceptual schema are actually stored on
secondary storage devices such as disks and tapes.
 Decides what file organizations to use to store the relations and create auxiliary data
structures, called indexes, to speed up data retrieval operations.
 A sample physical schema for the university database is to store all relations as unsorted files
of records.
o Create indexes on the first column of the students, faculty and courses relations, the
salary column of faculty, and the capacity of column of rooms.

External Schema:

 This schema allows data access to be customized at the level of individual users or groups of
users.
 A database has exactly one conceptual schema and one physical schema, but it may have
several external schemas.
 An external schema is a collection of one or more views and relations from the conceptual
schema.
 A view is conceptually a relation, but the records in a view are not stored in the DBMS.

1.9 Data Independence

Application programs are insulated from changes in the way the data is structured and stored.
Data independence is achieved through use of the three levels of data abstraction.
Logical data independence: users can be shielded from changes in the logical structure of the
data, or changes in the choice of relations to be stored. This is the independence to change the
conceptual schema without having to change the external schemas and their application
programs.
Physical data independence: the conceptual schema insulated users from changes in physical
storage details. This is the independence to change the internal schema without having to change
the conceptual schema.

1.10 People Who Deal With Databases

Quite a variety of people are associated with the creation and use of databases. Obviously, there
are database implementors, who build DBMS software, and end users who wish to store and use
data in a DBMS.
Database implementors work for vendors such as IBM or Oracle. End users come from a diverse
and increasing number of fields.

6
 UNIT – I : INTRODUCTION

In addition to end users and implementors, two other classes of people are associated with a
DBMS: application programmers and database administrators (DBAs).
Database application programmers develop packages that facilitate data access for end users,
who are usually not computer professionals, using the host or data languages and software tools
that DBMS vendors provide.

The task of designing and maintaining the database is entrusted to a professional called the
database administrator.

The DBA is responsible for many critical tasks:

 Design of the conceptual and physical schemas: The DBA is responsible for interacting with
the users of the system to understand what data is to be stored in the DBMS and how it is
likely to be used. Based on this knowledge, the DBA must design the conceptual schema
(decide what relations to store) and the physical schema (decide how to store them).
 Security and authorization: The DBA is responsible for ensuring that unauthorized data
access is not permitted. In general, not everyone should be able to access all the data. In a
relational DBMS, users can be granted permission to access only certain views and relations.
 Data availability and recovery from failures: The DBA must take steps to ensure that if the
system fails, users can continue to access as much of the uncorrupted data as possible.
 Database tuning: The needs of users are likely to evolve with time. The DBA is responsible
for modifying the database, in particular the conceptual and physical schemas, to ensure
adequate performance as user requirements change.

1.11 Database Environment

A database management system (DBMS) is a collection of programs that enables users to
create and maintain a database. The DBMS is hence a general-purpose software system that
facilitates the processes of defining, constructing, manipulating, and sharing databases among
various users and applications.

Defining a database involves specifying the data types, structures, and constraints for the data
to be stored in the database.

Constructing the database is the process of storing the data itself on some storage medium that
is controlled by the DBMS.

Manipulating a database includes such functions as querying the database to retrieve specific
data, updating the database to reflect changes in the mini world, and generating reports from the
data.

Sharing a database allows multiple users and programs to access the database concurrently.

Other important functions provided by the DBMS include protecting the database and maintaining
it over a long period of time.

Protection includes both system protection against hardware or software malfunction (or crashes),
and security protection against unauthorized or malicious access. A typical large database may
have a life cycle of many years, so the DBMS must be able to maintain the database system by
allowing the system to evolve as requirements change over time. We can call the database and
DBMS software together a database system.

7
 UNIT – I : INTRODUCTION

1.12 Database Architecture

Database architecture uses programming languages to design a particular type of software for
businesses or organizations. Database architecture focuses on the design, development,
implementation and maintenance of computer programs that store and organize information for
businesses, agencies and institutions.

The architecture of a DBMS can be seen as either single tier or multi-tier. The tiers are classified as
follows:

1-tier architecture

2-tier architecture

3-tier architecture

n-tier

architecture

1- tier architecture:

One-tier architecture involves putting all of the required components for a software application
or technology on a single server or platform.

8
 UNIT – I : INTRODUCTION

2- tier architecture:
The two-tier is based on Client Server architecture. The two-tier architecture is like client server
application. The direct communication takes place between client and server. There is no
intermediate between client and server.

3- tier architecture:
A 3-tier architecture separates its tiers from each other based on the complexity of the users and
how they use the data present in the database. It is the most widely used architecture to design a
DBMS.

1.13 Client/Server Architecture:

The client/server architecture was developed to deal with computing environments in which a
large number of PCs, workstations, file servers, printers, database servers, Web servers, and other
equipment are connected via a network. The idea is to define specialized servers with specific
functionalities.

The resources provided by specialized servers can be accessed by many client machines. The

9
 UNIT – I : INTRODUCTION
client machines provide the user with the appropriate interfaces to utilize these servers, as well as
with local processing power to run local applications. This concept can be carried over to
software, with specialized software-such as a DBMS or a CAD (computer-aided design) package
being stored on specific server machines and being made accessible to multiple clients.

The concept of client/server architecture assumes an underlying framework that consists of

many PCs and workstations as well as a smaller number of mainframe machines, connected via
local area networks and other types of computer networks. A client in this framework is typically
a user machine that provides user interface capabilities and local processing. When a client

10
 UNIT – I : INTRODUCTION

requires access to additional functionality-such as database access-that does not exist at that
machine, it connects to a server that provides the needed functionality.

A server is a machine that can provide services to the client machines, such as file access,
printing, archiving, or database access. In the general case, some machines install only client
software, others only server software, and still others may include both client and server
software. However, it is more common that client and server software usually run on separate
machines.

In client/server architecture, the user interface programs and application programs can run on
the client side. When DBMS access is required, the program establishes a connection to the DBMS
(which is on the server side); once the connection is created, the client program can communicate
with the DBMS. A standard called Open Database Connectivity (ODBC) provides an application
programming interface (API), which allows client-side programs to call the DBMS, as long as
both client and server machines have the necessary software installed. Most DBMS vendors
provide ODBC drivers for their systems.

Review Questions

1. Distinguish between database systems and file systems.

2. Discuss about the client server architecture of the database.
3. Define DBMS. Explain database users in detail.
4. What are advantages of DBMS? Explain.
5. With a neat diagram, explain the structure of Database Management System.
6. What is data independence and how does a DBMS support it? Explain.
7. What is a Database model? List out various database models and explain any two of them.
8. Explain the difference between external, logical and physical level schemas. How are these
different schema layers related to the concepts of logical and physical data independence?
9. Compare and contrast various Data Models.
10. Demonstrate data abstraction implementation in DBMS.
11. List and explain various data models used for database design.
12. Explain about Buffer management in DBMS.

11
 UNIT – I : INTRODUCTION
13. Who are the different database users? Explain their interfaces to database management system.
14. Describe the client server architecture for the database with necessary diagram.
15. Define Schema. Explain three level architecture in DBMS.
16. Explain Data Independence and its types in detail.
17. How does DBMS provide data abstraction? Explain the concept of data independence.
18. With a neat diagram describe the overall system structure of DBMS.

References:

 Raghurama Krishnan, Johannes Gehrke, Database Management Systems, 3rd Edition, Tata
McGraw Hill.
 C.J. Date, Introduction to Database Systems, Pearson Education.
 Elmasri Navrate, Fundamentals of Database Systems, Pearson Education.
3.1 Introduction

The entity-relationship (ER) data model allows us to describe the data involved in a real-world
enterprise in terms of objects and their relationships and is widely used to develop an initial
database design.
The ER model is important primarily for its role in database design. It provides useful concepts
that allow us to move from an informal description of what users want from their database to a
more detailed and precise, description that can be implemented in a DBMS.
Even though the ER model describes the physical database model, it is basically useful in the
design and communication of the logical database model.

3.2 Overview of Database Design

Our primary focus is the design of the database. The database design process can be divided into
six steps:

Requirements Analysis

The very first step in designing a database application is to understand what data is to be stored
in the database, what applications must be built on the database, and what operations must be
performed on the database. In other words, we must find out what the users want from the
database. This process involves discussions with user groups, a study of the current operating
environment, how it is expected to change an analysis of any available documentation on existing
applications and so on.

Conceptual Database Design

The information gathered in the requirement analysis step is used to develop a high-level
description of the data to be stored in the database, along with the conditions known to hold this
data. The goal is to create a description of the data that matches both—how users and developers
think of the data (and the people and processes to be represented in the data). This facilitates
discussion among all the people involved in the design process i.e., developers and as well as
users who have no technical background. In simple words, the conceptual database design phase
is used in drawing ER model.

Logical Database Design

We must implement our database design and convert the conceptual database design into a
database schema (a description of data) in the data model (a collection of high-level data

2
description constructs that hide many low-level storage details) of the DBMS.
UNITWe
– I will consider
: INTRODUCTION
only relational DBMSs, and therefore, the task in the logical design step is to convert the
conceptual database design in the form of E-R Schema (Entity-Relationship Schema) into a
relational database schema.

Schema Refinement

The fourth step in database design is to analyze the collection, of relations (tables) in our relational
database schema to identify future problems, and to refine (clear) it.

3
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

Physical Database Design

This step may simply involve building indexes on some tables and clustering some tables, or it
may involve redesign of parts of the database schema obtained from the earlier design steps.

Application and Security Design

Any software project that involves a DBMS must consider applications that involve processes
and identify the entities.

3.3 Entities, Attributes and Entity Sets

Entity: An entity is an object in the real world that is distinguishable from other objects.
Entity set: An entity set is a collection of similar entities. The Employees entity set with attributes
ssn, name, and lot is shown in the following figure.

Attribute: An attribute describes a property associated with entities. Attribute will have a name
and a value for each entity.
Domain: A domain defines a set of permitted values for an attribute
Entity Relationship Model: An ERM is a theoretical and conceptual way of showing data
relationships in software development. It is a database modeling technique that generates an
abstract diagram or visual representation of a system's data that can be helpful in designing a
relational database.
ER model allows us to describe the data involved in a real-world enterprise in terms of objects and
their relationships and is widely used to develop an initial database design.

3.4 Representation of Entities and Attributes

ENTITIES: Entities are represented by using rectangular boxes. These are named with the entity
name that they represent.

ATTRIBUTES: Attributes are the properties of entities. Attributes are represented by means of
ellipses. Every ellipse represents one attribute and is directly connected to its entity.

Types of attributes:
 Simple attribute − Simple attributes are atomic values, which cannot be divided further. For
example, a student's roll number is an atomic value.

4
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

 Composite attribute − Composite attributes are made of more than one simple attribute.
For example, a student's complete name may have first_name and last_name.

 Derived attribute − Derived attributes are the attributes that do not exist in the physical
database, but their values are derived from other attributes present in the database. For
example, average_salary in a department should not be saved directly in the database,
instead it can be derived. For another example, age can be derived from data_of_birth.

 Single-value attribute − Single-value attributes contain single value. For example −

Social_Security_Number.
 Multi-value attribute − Multi-value attributes may contain more than one values. For
example, a person can have more than one phone number, email_address, etc.

3.5 Relationship and Relationship set

Relationships are represented by diamond-shaped box. Name of the relationship is written inside the
diamond-box. All the entities (rectangles) participating in a relationship, are connected to it by a line.
Types of relationships:

Degree of Relationship is the number of participating entities in a relationship defines the degree of the
relationship. Based on degree the relationships are categorized as

 Unary = degree 1
 Binary = degree 2

5
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

 Ternary = degree 3
 n-array = degree
Unary Relationship: A relationship with one entity set. It is like a relationship among 2 entities of
same entity set. Example: A professor ( in-charge) reports to another professor (Head Of the Dept).

Binary Relationship: A relationship among 2 entity sets. Example: A professor teaches a course
and a course is taught by a professor.

Ternary Relationship: A relationship among 3 entity sets. Example: A professor teaches a course
in so and so semester.

n-array Relationship: A relationship among n entity sets.

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. Cardinality ratios are categorized into 4. They are.

1. One-to-One relationship: When only one instance of entities is associated with the
relationship, then the relationship is one-to-one relationship. Each entity in A is
associated with at most one entity in B and each entity in B is associated with at most one
entity in A.

6
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

2. One-to-many relationship: When more than one instance of an entity is associated with a
relationship, then the relationship is one-to-many relationship. Each entity in A is
associated with zero or more entities in B and each entity in B is associated with at most

one entity in A.

3. Many-to-one relationship: When more than one instance of entity is associated with the
relationship, then the relationship is many-to-one relationship. Each entity in A is
associated with at most one entity in B and each entity in B is associated with 0 (or) more
entities in A.

4. Many-to-Many relationship: If more than one instance of an entity on the left and more
than one instance of an entity on the right can be associated with the relationship, then it
depicts many-to-many relationship. Each entity in A is associated with 0 (or) more entities in
B and each entity in B is associated with 0 (or) more entities in A.

7
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

Relationship Set:
A set of relationships of similar type is called a relationship set. Like entities, a relationship too can
have attributes. These attributes are called descriptive attributes.

Participation Constraints:
 Total Participation − If Each entity in the entity set is involved in the relationship then the
participation of the entity set is said to be total. Total participation is represented by double
lines.
 Partial participation − If, Not all entities of the entity set are involved in the relationship then
such a participation is said to be partial. Partial participation is represented by single lines.
Example:

3.6 Additional Features Of The ER Model

Key Constraints

Consider a relationship set called Manages between the Employees and Departments entity sets
such that each department has at most one manager, although a single employee is allowed to
manage more than one department. The restriction that each department has at most one manager
is an example of a key constraint, and it implies that each Departments entity appears in at most
one Manages relationship in any allowable instance of Manages. This restriction is indicated in the
ER diagram of below Figure by using an arrow from Departments to Manages. Intuitively, the
arrow states that given a Departments entity, we can uniquely determine the Manages relationship
in which it appears.

8
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

Key Constraints for Ternary Relationships

If an entity set E has a key constraint in a relationship set R, each entity in an instance of E appears
in at most one relationship in (a corresponding instance of) R. To indicate a key constraint on
entity set E in relationship set R, we draw an arrow from E to R.

Below figure show a ternary relationship with key constraints. Each employee works in at most
one department, and at a single location.

Weak Entities

Strong Entity set: If each entity in the entity set is distinguishable or it has a key then such an entity
set is known as strong entity set.

Weak Entity set: If each entity in the entity set is not distinguishable or it doesn't has a key then
such an entity set is known as weak entity set.

eno is key so it is represented by solid underline. dname is partial key. It can't distinguish the
tuples in the Dependent entity set. so dname is represented by dashed underline.
Weak entity set is always in total participation with the relation. If entity set is weak then the
relationship is also known as weak relationship, since the dependent relation is no longer needed
when the owner left.
Ex: policy dependent details are not needed when the owner (employee) of that policy left or fired
from the company or expired. The detailed ER Diagram is as follows.

9
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

The cardinality of the owner entity set is with weak relationship is 1 : m. Weak entity set is
uniquely identifiable by partial key and key of the owner entity set.
Dependent entity set is key to the relation because the all the tuples of weak entity set are
associated with the owner entity set tuples.

Dependents is an example of a weak entity set. A weak entity can be identified uniquely only by
considering some of its attributes in conjunction with the primary key of another entity, which is
called the identifying owner.
The following restrictions must hold:
 The owner entity set and the weak entity set must participate in a one-to-many
relationship set (one owner entity is associated with one or more weak entities, but each
weak entity has a single owner). This relationship set is called the identifying relationship
set of the weak entity set.

 The weak entity set must have total participation in the identifying relationship set

3.7 E-R Diagrams Implementation

Now we are in a position to write the ER diagram for the Company database which was introduced
in the beginning of this unit. The readers are strictly advised to follow the steps shown in this unit
to design an ER diagram for any chosen problem.

Step 1: Identify the Strong and Weak Entity Sets

After careful analysis of the problem we come to a conclusion that there are four possible entity sets
as shown below:
1. Employees Strong Entity Set
2. Departments Strong Entity Set
3. Projects Strong Entity Set
4. Dependents Weak Entity Set

Step 2: Identify the Relevant Attributes

The next step is to get all the attributes that are most applicable for each entity set. Do this work
by considering each entity set in mind and also the type of attributes. Next job is to pick the
primary key for strong entity sets and partial key for weak entity sets.

Example: Following are the attributes:

1. Employees SSN. Name, Addr, DateOfBirth, Sex, Salary
2. Departments DNo. DName, DLocation
3. Projects PNo. PName, PLocation
4. Dependents (weak) DepName, DateOf Birth, Sex, Relationship

10
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

The underlined attributes are the primary keys and DepName is the partial key of
Dependents. Also, DLocation may be treated as a multivalued attribute.

Step 3: Identify the Relationship Sets

In this step we need to find all the meaningful relationship sets among possible entity sets.
This step is very tricky, as redundant relationships may lead to complicated design and in turn
a bad implementation.

Example: Let us show below what the possible relationship sets are:
1. Employees and Departments WorksFor
2. Employees and Departments Manages
3. Departments and Projects Controls
4. Projects and Employees WorksOn
5. Dependents and Employees Has
6. Employees and Employees Supervises

Some problems may not have recursive relationship sets but some do have. In fact, our Company
database has one such relationship set called Supervises. You can complete this step adding
possible descriptive attributes of the relationship sets (Manages has StartDate and WorksOn has
Hours).

Step 4: Identify the Cardinality Ratio and Participation Constraints

This step is relatively a simple one. Simply apply the business rules and your common sense.
So, we write the structural constraints for our example as follows:

1. WorksFor N: 1 Total on either side

2. Manages 1: 1 Total on Employees and Partial on Departments side
3. Controls 1: N Total on either side
4. WorksOn M: N Total on either side
5. Has 1: M Total on Dependents and Partial on Employees

Step 5: Identify the IS-A and Has-A Relationship Sets

The last step is to look for “is-a” and “has-a” relationships sets for the given problem. As far as
the Company database is concerned, there are no generalization and aggregation
relationships in the Company database.

The complete single ER diagram by combining all the above five steps is shown in figure

11
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

3.8 Class Hierarchies

To classify the entities in an entity set into subclass entity is known as class hierarchies. Example,
we might want to classify Employees entity set into subclass entities Hourly-Emps entity set and
Contract-Emps entity set to distinguish the basis on which they are paid. Then the class hierarchy
is illustrated as follows.

This class hierarchy illustrates the inheritance concept. Where, the subclass attributes ISA (read as
: is a) super class attributes; indicating the “is a” relationship (inheritance concept).Therefore, the

12
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

attributes defined for a Hourly-Emps entity set are the attributes of Hourly-Emps plus attributes
of Employees (because subclass can have superclass properties). Likewise the attributes defined
for a Contract-Emps entity set are the attributes of Contract-Emps plus attributes of Employees.

Class Hierarchy based on Sub-super Set

1. Specialization: Specialization is the process of identifying subsets (subclasses) of an entity set

(superclass) that share some special distinguishable characteristic. Here, the superclass
(Employee) is defined first, then the subclasses (Hourly-Emps, Contract-Emps, etc.) are defined
next.
In short, Employees is specialized into subclasses.
2. Generalization: Generalization is the process of identifying (defining) some generalized
(common) characteristics of a collection of (two or more) entity sets and creating a new
entity set that contains (possesses) these common characteristics. Here, the subclasses (Hourly-
Emps, Contract-Emps, etc.) are defined first, then the Superclass (Employee) is defined, next.
In shortly, Hourly-Emps and Contract-Emps are generalized by Employees.

Class Hierarchy based on Constraints

1. Overlap constraints: Overlap constraints determine whether two subclasses are
allowed to contain the same entity.

Example: Can Akbar be both an Hourly-Emps entity and a Contract-Emps entity?

The answer is, No.
Other example, can Akbar be both a Contract-Emps entity and a Senior-Emps entity (among
them)?
The answer is, Yes. Thus, this is a specialisation hierarchy property. We denote this by
writing “Contract-Emps OVERLAPS Senior-Emps”.

2. Covering Constraints: Covering constraints determine whether the entities in

the subclasses collectively include all entities in the superclass.

Example: Should every Employee be a Hourly-Emps or .Contract-Emps?

The Answer is, No. He can be a Daily-Emps.
Other example, should every Motor-vehicle (superclass) be a Bike (subclass) or a Car
(subclass)?
The Answer is YES. Thus generalization hierarchies property is that every instance of a
superclass is an instance of a subclass.
We denote this by writing “ Bikes and Cars COVER Motor-vehicles”.

3.9 Aggregation
Aggregation allows us to indicate that a relationship set (identified through a dashed box)
participates in another relationship sets. That is, a relationship set in an association between
entity sets. Sometimes we have to model a relationship between a collection of entities and
relationships.

Example: Suppose that we have an entity set called Project and that each Project entity is sponsored
by one or more departments. Thus, the sponsors relationship set captures this information but, a
department that sponsors a project, might assign employees to monitor the sponsorship.
Therefore, Monitors should be a relationship set that associates a sponsors relationship (rather

13
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

than a Project or Department entity) with an Employees entity. However, again we have to define
relationships to associate two or more entities.

Use of Aggregation
We use an aggregation, when we need to express a relationship among relationships. Thus, there
are really two distinct relationships, Sponsors and Monitors, each with its own attributes.

3.10 Conceptual Database Design With The ER Model (ER Design Issues)
The following are the ER design issues:

1. Use entry sets attributes

2. Use of Entity sets or relationship sets

3. Binary versus entry relationship sets

4. Aggregation versus ternary relationship.

1. Use of Entity Sets versus Attributes

Consider the relationship set (called Works In2) shown in Figure

Intuitively, it records the interval during which an employee works for a department. Now
suppose that it is possible for an employee to work in a given department over more than one
period.

14
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

This possibility is ruled out by the ER diagram’s semantics. The problem is that we want to record
several values for the descriptive attributes for each instance of the Works_In2 relationship. (This
situation is analogous to wanting to record several addresses for each employee.) We can address
this problem by introducing an entity set called, say, Duration, with attributes from and to, as
shown in Figure

2. Entity versus Relationship

Consider the relationship set called Manages that each department manager is given a
discretionary budget (dbudget), as shown in below figure, in which we have also renamed the
relationship set to Manages2.

There is at most one employee managing a department, but a given employee could manage
several departments; we store the starting date and discretionary budget for each manager-
department pair. This approach is natural if we assume that a manager receives a separate
discretionary budget for each department that he or she manages.

But what if the discretionary budget is a sum that covers all departments managed by that
employee? In this case each Manages2 relationship that involves a given employee will have the
same value in the dbudget field. In general such redundancy could be significant and could cause
a variety of problems. Another problem with this design is that it is misleading.

We can address these problems by associating dbudget with the appointment of the employee
as manager of a group of departments. In this approach, we model the appointment as an entity
set, say Mgr_Appts, and use a ternary relationship, say Man ages3, to relate a manager, an
appointment, and a department. The details of an appointment (such as the discretionary
budget) are not repeated for each department that is included in the appointment now, although
there is still one Manages3 relationship instance per such department. Further, note that each
department has at most one manager, as before, because of the key constraint. This approach is
illustrated in below Figure.

15
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

3. Binary versus Ternary Relationships

Consider the ER diagram shown in below figure. It models a situation in which an employee can
own several policies, each policy can be owned by several employees, and each dependent can
be covered by several policies.

Suppose that we have the following additional requirements:

 A policy cannot be owned jointly by two or more employees.

 Every policy must be owned by some employee.

 Dependents is a weak entity set, and each dependent entity is uniquely identified by
taking pname in conjunction with the policyid of a policy entity (which, intuitively,
covers the given dependent).

The first requirement suggests that we impose a key constraint on Policies with respect to Covers,
but this constraint has the unintended side effect that a policy can cover only one dependent. The
second requirement suggests that we impose a total participation constraint on Policies. This
solution is acceptable if each policy covers at least one dependent. The third requirement forces us
to introduce an identifying relationship that is binary (in our version of ER diagrams, although
there are versions in which this is not the case).

Even ignoring the third point above, the best way to model this situation is to use two binary
relationships, as shown in below figure.

16
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER MODEL
UNIT – I : INTRODUCTION

4. Aggregation versus Ternary Relationships

The choice between using aggregation or a ternary relationship is mainly determined by the
existence of relationship that relates a relationship set to an entity set (or second relationship
set). The choice may also be guided by certain integrity constraints to we want to express.

Consider the constraint that each sponsorship (of a project by a department) be monitored by at
most one employee. We cannot express this constraint in terms of the Sponsors2 relationship
set. Also we can express the constraint by drawing an arrow from the aggregated relationship.
Sponsors to the relationship Monitors. Thus, the presence of such a constraint serves as another
reason for using aggregation rather than a ternary relationship set.

Review Questions

1. Define the following terms and give examples

(i) cardinality (ii)unary relationships (iii)aggregation (iv)specialization

2. What is Entity set? and also define Relationship set. List and explain the symbols
used to draw ER Diagram.
3. Design a database for an airline. The database must keep track of customers and their

17
 UNIT – I : INTRODUCTION
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER
MODEL

reservations, flights and their status, seat assignments on individual flights, and the
schedule and routing of future flights. Your design should include an E-R diagram, a set of
relational schemas, and a list of constraints, including primary-key and foreign-key
constraints.
4. Discuss the representation of total participation and multivalued attribute in an E/R
diagram.
5. What is an Entity Relationship diagram and why it is useful?
6. What is a weak entity in ER diagram?
7. Give the diagrammatic representation of recursive relationship in an ER diagram and
also explain the importance of role names in representing a recursive relationship by
taking a real time example.
8. Consider a database used to record the marks that students get in different exams of
different course offerings.
a. Construct an E-R diagram that models exams as entities, and uses a ternary
relationship, for the above database.
b. Construct an alternative E-R diagram that uses only a binary relationship
between students and course-offerings. Make sure that only one relationship exists
between a particular student and course-offering pair, yet you can represent the
marks that a student gets in different exams of a course offering.
9. Explain about relationship sets in ER model with examples.
10. Explain about ER model design issues.

References:

 Raghurama Krishnan, Johannes Gehrke, Database Management Systems, 3rd Edition,

Tata McGraw Hill.

 C.J. Date, Introduction to Database Systems, Pearson Education.

 Elmasri Navrate, Fundamentals of Database Systems, Pearson Education.

18
UNIT – I : INTRODUCTION

19