DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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, Centralized and Client Server architecture for the database.
Entity Relationship Model: Introduction, Representation of entities, attributes,
entity set, relationship, relationship set, constraints, sub classes, super class, inheritance, specialization,
generalization using ER Diagrams.

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”.

1
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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.

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.
2
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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.

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.

3
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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.

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.
4
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
 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”.

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.

5
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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)

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.

6
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
 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 Architecture of a DBMS

The functional components of a database system can be broadly divided into query processor
components and storage manager components. The query processor includes:
1. DML Compiler: It translates DML statements in a query language into low-level instructions
that the query evaluation engine understands.
2. Embedded DML Pre-compiler: It converts DML statements embedded in an application
program to normal procedure calls in the host language. The pre-compiler must interact
with the DML compiler to generate the appropriate code.
3. DDL Interpreter: It interprets DDL Stateline its and records them in a set of tables containing

metadata.
4. Transaction Manager: Ensures that the database remains in a consistent (correct) state despite
system failures, and that concurrent transaction executions proceed without conflicting.
5. File Manager: Manages the allocation of space on disk storage and the data structures
used to represent information stored on disk.
6. Buffer Manager: Is responsible for fetching data from disk storage into main memory
and deciding what data to cache in memory.
Also some data structures are required as part of the physical system implementation:
1. Data Files: The data files store the database by itself.
2. Data Dictionary: It stores metadata about the structure of the database, as it is used heavily.
3. Indices: It provides fast access to data items that hold particular values.
4. Statistical Data: It stores statistical information about the data in the database. This
information used by the query processor to select efficient ways to execute a query.

7
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

1.11 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.

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.
8
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

 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.12 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.

9
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

1.13 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.

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.

10
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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.14 Centralized DBMS Architecture

Architectures for DBMSs have followed trends similar to those for general computer system
architectures. Earlier architectures used mainframe computers to provide the main processing for
all functions of the system, including user application programs and user interface programs,
as well as all the DBMS functionality.

As prices of hardware declined, most users replaced their terminals with personal computers
(PCs) and workstations. At first, database systems used these computers in the same way as
they had used display terminals, so that the DBMS itself was still a centralized DBMS in
which all the DBMS functionality, application program execution, and user interface
processing were carried out on one machine.

Gradually, DBMS systems started to exploit the available processing power at the user side,
which led to client/server DBMS architectures.

11
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
1.15 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
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 clientrequires 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.

12
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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.
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.

ENTIITY-RELATIONSHIP MODEL

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
13
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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 description constructs that hide many low-level storage details) of the
DBMS. We will consider 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.

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

14
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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.

15
DATABASE MANAGEMENT SYSTEMS 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

16
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

 Unary = degree 1
 Binary = degree 2

 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.

17
 DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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

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.

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.

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.

18
DATABASE MANAGEMENT SYSTEMS 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.

19
DATABASE MANAGEMENT SYSTEMS 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.

20
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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.

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
21
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
3. Projects PNo. PName, PLocation
4. Dependents (weak) DepName, DateOf Birth, Sex, Relationship
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.

22
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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

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

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-
23
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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 than a Project or Department entity) with an
Employees entity. However, again we have to define relationships to associate two or

24
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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.
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
25
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
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

1. 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
26
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION
one manager, as before, because of the key constraint. This approach is illustrated in
below Figure.
2. 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.

27
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

3. 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.

Integrity Constraints

o Integrity constraints are a set of rules. It is used to maintain the quality of information.
o Integrity constraints ensure that the data insertion, updating, and other processes have to be
performed in such a way that data integrity is not affected. Thus, integrity constraint is used to guard
against accidental damage to the database.

Types of Integrity Constraint

28
 DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

1. Domain constraints

o Domain constraints can be defined as the definition of a valid set of values for an
attribute.

o The data type of domain includes string, character, integer, time, date, currency, etc. The
value of the attribute must be available in the corresponding domain.

Example:

2. Entity integrity constraints

o The entity integrity constraint states that primary key value can't be null.

o This is because the primary key value is used to identify individual rows in relation and
if the primary key has a null value, then we can't identify those rows.

o A table can contain a null value other than the primary key field.

3. Referential

Integrity Constraints

o A referential integrity constraint is specified between two tables.

o In the Referential integrity constraints, if a foreign key in Table 1 refers to the Primary
Key of Table 2, then every value of the Foreign Key in Table 1 must be null or be
available in Table 2.

29
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

2. Key constraints

o Keys are the entity set that is used to identify an entity within its entity set uniquely.

o An entity set can have multiple keys, but out of which one key will be the primary key.
A primary key can contain a unique and null value in the relational table.

30
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

E-R DIAGRAM FOR UNIVERSITY DATABASE

31
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

E-R DIAGRAM FOR RAILWAY RESERVATION SYSTEM

32
DATABASE MANAGEMENT SYSTEMS UNIT – I : INTRODUCTION

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

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.

33