RELATIONAL DATABASE MANAGEMENT SYSTEM

UNIT - I
Purpose of Database Systems - Overall system structure - Entity
relationship model - Mapping constraints - Primary Keys - Foreign
Keys - E.R. Diagrams.

DATABASE:
Database is a collection of interrelated (organized) data.
DBMS:

Data Base Management System (DBMS) is a collection of interrelated

data and a set of programs to access those data. The collection of data,
usually referred to as the database, contains information relevant to an
enterprise. The primary goal of a DBMS is to provide a way to store and
retrieve database information that is both convenient and efficient.
Database systems are designed to manage large bodies of
information. Management of data involves both defining structures for
storage of information and providing mechanisms for the manipulation of
information. In addition, the database system must ensure the safety of
the information stored, despite system crashes or attempts at
unauthorized access. If data are to be shared among several users, the
system must avoid possible anomalous results.
Because information is so important in most organizations,
computer scientists have developed a large body of concepts and
techniques for managing data.

Database System Applications

Databases are widely used. Here are some representative applications:

Banking : For customer information, accounts, and loans, and

banking transactions.
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.
Universities : For student information, course registrations, and
grades.
Credit and Transactions : For purchases on credit cards and
generation of monthly statements.
Telecommunication : For keeping records of calls mode,
generating monthly bills, maintaining balances on prepaid calling
cards, and storing information about the communication networks.
 Finance : For storing information about holdings, sales, and
purchases of financial instruments such as stocks and bonds.
Sales : For customer, product, and purchase information.
Manufacturing : For management of supply chain and for tracking
production of items in factories, inventories of items in
warehouses/stores, and orders for items.
Human resources: For information about employees, salaries,
payroll taxes and benefits, and for generation of paychecks.

Database Systems versus File Systems

Consider part of a savings-bank enterprise that keeps information about

all customers and savings accounts. One way to keep the information on
a computer is to store it in operating system files. To allow users to
manipulate the information, the system has a number of application
programs that manipulate the files, including

 A program to debit or credit an account

 A program to add a new account
 A program to find the balance of an account
 A program to generate monthly statements

System programmers wrote these application programs to meet the

needs of the bank.
New application programs are added to the system as the need
arises. For example, suppose that the savings bank decides to offer
checking accounts. As a result, the bank creates new permanent files
that contain information about all the checking accounts maintained in
the bank, and it may have to write new application programs to deal
with situations that do not arise in savings accounts, such as overdrafts.
Thus, as time goes by, the system acquires more files and more
application programs.
This typical file-processing system is supported by a conventional
operating system. The system stores permanent records in various files,
and it needs different application programs to extract records from, and
add records to, the appropriate files. Before database management
systems (DBMS) came along, organizations usually stored information in
such systems.
Keeping organizational information in a file-processing system has
a number of major disadvantages:
 Data redundancy and inconsistency. Since different
programmers create the files and application programs over
a long period, the various files are likely to have different
 formats and the programs may be written in several
programming languages. Moreover, the same information
may be duplicated in several places (files). For example, the
address and telephone number of a particular customer may
appear in a file that consists of savings-account records and
in a file that consists of checking-account records. This
redundancy leads to higher storage and access cost. In
addition, it may lead to data inconsistency; that is, the
various copies of the same data may no longer agree. For
example, a changed customer address may be reflected in
savings-account records but not elsewhere in the system.

 Difficulty in accessing data. Suppose that one of the bank

officers needs to find out the names of all customers who live
within a particular postal-code area. The officer asks the
data-processing department to generate such a list. Because
the designers of the original system did not anticipate this
request, there is no application program on hand to meet it.
There is, however, an application program to generate the
list of all customers. The bank officer has now two choices:
either obtain the list of all customers and extract the needed
information manually or ask a system programmer to write
the necessary application program. Both alternatives are
obviously unsatisfactory. Suppose that such a program is
written, and that, several days later, the same officer needs
to trim that list to include only those customers who have an
account balance of $10,000 or more. As expected, a
program to generate such a list does not exist. Again, the
officer has the preceding two options, neither of which is
satisfactory.
The point here is that conventional file-processing
environments do not allow needed data to be retrieved in a
convenient and efficient manner. More Responsive data-
retrieval systems are required for general use.

 Data isolation. Because data are scattered in various files,

and files may be in different formats, writing new application
programs to retrieve the appropriate data is difficult.

 Integrity problems. The data values stored in the database

must satisfy certain types of consistency constraints. For
example, the balance of a bank account may never fall below
a prescribed amount (say, $25). Developers enforce these
constraints in the system by adding appropriate code in the
various application programs. However, when new
 constraints are added, it is difficult to change the programs
to enforce them. The problem is compounded when
constraints involve several data items from different files.
 Atomicity problems. A computer system, like any other
mechanical or electrical device, is subject to failure. In many
applications, it is crucial that, if a failure occurs, the data be
restored to the consistent state that existed prior to the
failure. Consider a program to transfer $50 from account A
to account B. if a system failure occurs during the execution
of the program, it is possible that the $50 was removed from
account A but was not credited to account B, resulting in an
inconsistent database state. Clearly, it is essential to
database consistency that either both the credit and debit
occur, or that neither occur. That is, the funds transfer
must be atomic—it must happen in its entirety or not at all.
It is difficult to ensure atomicity in a conventional file-
processing system.

 Concurrent-access anomalies. For the sake of overall

performance of the system and faster response, many
systems allow multiple users to update the data
simultaneously. In such an environment, interaction of
concurrent updates may result in inconsistent data.
Consider bank account A, containing $500. if two
customers withdraw funds (say $50 and $100 respectively)
from account A at about the same time, the result of the
concurrent executions may leave the account in an incorrect
(or inconsistent) state. Suppose that the programs executing
on behalf of each withdrawal read the old balance, reduce
that value by the amount being withdrawn, and write the
result back. If the two programs run concurrently, they may
both read the value $500, and write back $450 and $400,
respectively. Depending on which one writes the value last,
the account may contain $450 or $400, rather than the
correct value of $350. To guard against this possibility, the
system must maintain some form of supervision. But
supervision is difficult to provide because many different
application programs that have not been coordinated
previously may access data.

 Security problems. Not every user of the database system

should be able to access all the data. For example, in a
banking system, payroll personnel need to see only that part
of the database that has information about the various bank
employees. They do not need access to information about
 customer accounts. But since application programs are
added to the system in an ad hoc manner, enforcing such
security constraints is difficult.

These difficulties, among others, prompted the development of database

systems. In what follows, we shall see the concepts and algorithms that
enable database systems to solve the problems with file-processing
systems. In most of this book, we use a bank enterprise as a running
example of a typical data-processing application found in a corporation.

ADVANTAGES OF A DBMS
Using a DBMS to manage data has many advantages:
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: If data is always accessed through the
DBMS, the DBMS can enforce integrity constraints on the data. For
example, before inserting salary information for an employee, the DBMS
can check that the department budget is not exceeded. Also, 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. Experienced
professionals who understand the nature of the data being managed, and
how different groups of users use it, can be responsible 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. This, in conjunction with the high-level interface
to the data, facilitates quick development of applications. Such applications
are also likely to be more robust than applications developed from scratch
because many important tasks are handled by the DBMS instead of being
implemented by the application.
 Given all these advantages, is there ever a reason not to use a DBMS? A
DBMS is a complex piece of software, optimized for certain kinds of
workloads (e.g., answering complex queries or handling many concurrent
requests), and its performance may not be adequate for certain specialized
applications. Examples include applications with tight real-time constraints
or applications with just a few well-defined critical operations for which e
client custom code must be written. Another reason for not using a DBMS
is that an application may need to manipulate the data in ways not
supported by the query language. In such a situation, the abstract view of
the data presented by the DBMS does not match the application’s needs,
and actually gets in the way. As an example, relational databases do not
support exible analysis of text data (although vendors are now extending
their products in this direction). If specialized performance or data
manipulation requirements are central to an application, the application
may choose not to use a DBMS, especially if the added benefits of a DBMS
(e.g., exible querying, security, concurrent access, and crash recovery) are
not required. In most situations calling for large-scale data management,
however, DBMSs have become an indispensable tool.

OVERALL SYSTEM STRUCTURE:

STRUCTURE OF DBMS
The various components of DBMS are shown below: -
1. DDL Compiler - Data Description Language compiler processes
schema definitions specified in the DDL. It includes Metadata ( is “data
about data.” or “Information about data”) metadata information such as
the name of the files, data items, storage details of each file, mapping
information and constraints etc.
2. DML Compiler and Query optimizer - The DML commands such as
insert, update, delete, retrieve from the application program are sent to
the DML compiler for compilation into object code for database access.
The object code is then optimized in the best way to execute a query by
the query optimizer and then send to the data manager.
3. Data Manager - The Data Manager is the central software component
of the DBMS also knows as Database Control System.
. Data Dictionary - Data Dictionary is a repository of description of data
in the database. It contains information about Database.
• Data - names of the tables, names of attributes of each table, length of
attributes, and number of rows in each table.
• Relationships between database transactions and data items
referenced by them which is useful in determining which transactions
are affected when certain data definitions are changed.
• Constraints on data i.e. range of values permitted.
• Detailed information on physical database design such as storage
structure, access paths, files and record sizes.
• Access Authorization - is the Description of database users their
responsibilities and their access rights.
• Usage statistics such as frequency of query and transactions

5. Data Files - It contains all the data of the database.

6. Compiled DML - The DML complier converts the high level Queries
into low level file access commands known as compiled DML.
7. End Users -

The Entity-Relationship Model

The Entity-Relationship (E-R) data model is based on a perception of a

real world that consists of a collection of basic objects, called entities,
and of relationship among these objects. An entity is a “thing” or “object”
in the real world that is distinguishable from other objects. For example,
each person is an entity, and bank accounts can be considered as
entities.
 Entities are described in a database by a set of attributes. For
example, the attributes account-number and balance may describe one
particular account in a bank, and they form attributes of the account
entity set. Similarly, attributes customer-name, customer-street address
and customer-city may describe a customer entity.
An extra attribute customer-id is used to uniquely identify
customers (since it may be possible to have two customers with the same
name, street address, and city). A unique customer identifier must be
assigned to each customer. In the United States, many enterprises used
the social-security number of a person (a unique number the U.S.
government assigns to every person in the United States) as a customer
identifier.
A relationship is an association among several entities. For
example, a depositor relationship associates a customer with each
enterprise use the social-security number of a person (a unique number
the U.S. government assigns to every person in the United Sates) as a
customer identifier.
A relationship is an association among several entities. For
example, a depositor relationship associates a customer with each
account that she has. The set of all entities of the same type and the set
of all relationships of the same type are termed an entity set and
relationship set, respectively,

Relationship Types
• We may distinguish four different types of relationships based on
the cardinalities of the upper bounds on either side of the
relationship
1:1
1:M
M:1
M: M
1:1- Relationship
An entity in A is associated with atmost one entity
in B, and an entity in B is associated with atmost one entity in A.
A B

1: M Relationship (One to Many)

An entity in A is associated with any number of entities in
B,An entity in B,however,can be associated with at most one entity in A.
 A B

A A
B
C

M:1 Relationship (Many to One)

An entity in A is associated with at most one
entity in [Link] entity in B, however, can be associated with any number
of entities in A.
A B

A A
B
C

M:M Relationship(Many to Many)

An entity in A is associated with any number of
entities in B, and an entity in B is associated with any number of entities
in A.
A B

A A
B B
C C

Primary Keys:
A primary key is the column or a group of columns
that can uniquely identify any row in the table. This key should also
identify the table through the database. Listed below are some of the
important elements of a primary key:
 It must uniquely identify each record in a table.
 It must contain unique values.
 It cannot be a null field.
  It cannot be a multi-part field.
 It should contain a minimum number of fields necessary to be
called unique.
 Its value cannot be modified except in very rare cases.

Let us take the example of our library issues register.

Mem-Cd Mem-Name Book Code Issue Date Return Date

M001 JOE B0020 18-3-98 18-4-98
M008 SAM B0189 18-3-98 18-4-98
M067 PENNY B0656 19-3-98 19-4-98
M0123 JENNY B0198 20-3-98 20-4-98

We have seen that in this table the member code is the primary
key. Whenever a new member joins the library, a unique number will be
assigned to the member. This number will not be assigned to anyone else
so that it can remain unique. Numbers are preferred as key as they can
remain unique. Member’s names could be duplicates, so they cannot
qualify as primary keys.
Listed below are some rules for establishing primary keys:
 Each table must have only one primary key.
 Each table within a database should have a unique primary key.

Foreign Keys:
A foreign key is a copy of a primary key in another
table. The key connects to another table when a relationship is being
established. Consider the issues table again.
Mem-Cd Book Code Issue Date Return Date
M001 B0020 18-3-98 18-4-98
M008 B0189 18-3-98 18-4-98
M067 B0656 19-3-98 19-4-98
M0123 B0198 20-3-98 20-4-98

Mapping Constraints:
It contains two most important types of
constraints,
 Mapping Cardinalities
 Existence dependencies

Mapping Cardinalities
Mapping Cardinalities, or cardinality ratios,
express the number of entities to which another entity can be
associated via a relationship set.
 Mapping cardinalities are useful in
describing binary relationship sets. For a binary relationship set R
between entity sets A and B, the mapping cardinality must be one of
the following:

 One to One:
An entity in A is associated with at most one
entity in B,and an entity in B is associated with at most one entity
in A.
 One to Many Relationship :
An entity in A is associated with any
number of entities in B,An entity in B,however,can be associated
with at most one entity in A.
 Many to One Relationship :
An entity in A is associated with at most
one entity in [Link] entity in B, however, can be associated with any
number of entities in A.
 Many to Many Relationship:
An entity in A is associated with any
number of entities in B, and an entity in B is associated with any
number of entities in A.

Existence Dependencies
Another important class of constraints is
existence [Link],if the existence of entity X
depends on the existence of entity Y,then X is said to be existence
dependent on [Link],if Y is deleted, so is [Link] Y is said
to be a dominant entity, and X is said to be a subordinate entity.
Consider the entity set Loan and the entity
set Payment that keeps information about all the payments that
were made in connection to a particular loan.
The Payment entity set is described by the
attributes payment number, payment-date, and payment-amount.
We form a relationship set loan-payment between these two entity
sets. which is one to many from loan to payment.
Every payment entity must be associated
with a loan entity. if a loan entity is deleted, then all its associated
payment entities must be deleted also.
In contrast, payment entities can be deleted from
the database without affecting any loan. The entity set Loan is dominant,
and payment is subordinate, in the loan-payment relationship set.

E-R Diagram:
The overall logical structure (schema) of a database can be expressed
graphically by an E-R diagram, which is built up from the following
components:

 Rectangles, which represent entity sets

 Ellipses, which represent attributes
 Diamonds, which represent relationships among entity sets.
 Lines, which link attributes to entity sets and entity sets to
relationships

Design of an E-R database Schema

The E-R data model gives us much flexibility in designing a database

schema to model a given enterprise. In this section, we consider how a
database designer may select from the wide range of alternatives. Among
the designer’s decisions are:
 Whether to use an attribute or an entity set to represent an
object.
 Whether a real-world concept is expressed more accurately
by an entity set or by a relationship set .
 Whether to use a ternary relationship or a pair of binary
relationship.
 total disjoint
IS generalization
A generalization
IS
A

Figure 2.20. Symbols used in the E-R notation.

 Whether to use a strong or a weak entity set a strong

entity set and its dependent weak entity sets may be regarded as
a single “object” in the database, since weak entities are
existence dependent on a strong entity
  Whether using generalization is appropriate;
generalization, or a hierarchy of ISA relationships, contributes to
modularity by allowing

Figure 2.21. Alternative E-R notations.

common attributes of similar entity sets to be represented in

one place in an E-R diagram

Each component is labeled with the entity or relationship that it

represents.
As an illustration, consider part of a database banking system
consisting of customers and of the accounts that these customers have.
Figure 1.2 shows the corresponding E-R diagram indicates that there are
two entity sets, customer and account, with attributes so outlined
earlier. The diagram also shows a relationship depositor between
customer and account.
In addition to entities and relationships, the E-R model represents
certain constraints to which the contents of a database must conform.
One important constraint is mapping cardinalities, which express the
number of entities of which another entity can be associated via a
relationship set. For example, if each account must belong to only one
customer, the E-R model can express that constraint.
The entity-relationship model is widely used in database design,
and Chapter 2 explores it in detail.

Figure 1.2. A sample E-R diagram.

Entities and Entity Sets

According to the above diagram shown an
employee name Basu with address 10,Palm Anenue,Calcutta 10 and an
unique employee number 79003 is an entity since it uniquely identifies
one particular person in the [Link],proj_no-CS1177 with a
name compiler is an entity since it uniquely identifies one particular
project.
An entity may be either concrete, such as an
employee or a book, or it may be abstract, such as a project or a concept.
An entity set is a set of entities of the same type.
The set of all employees of an organization can be defined as the entity
set employees. Similarly the entity set projects represents the set of all
the projects undertaken by the organization.
An entity set is represented by a set of
attributes. Possible attributes of the employees entity set are emp_no,
emp_name, and address. Possible attributes of the projects entity set are
project_no and proj_name.For each attribute there is a set of permitted
values, called the domain of that attribute, which can be assigned to the
attribute. The domain of the attribute emp_name is the set of all
alphabetic strings of finite length. One instance of the entity set
Employees and one instance of the entity set Projects are below.

Attributes are properties of an entity

– measures or descriptions of properties possessed by
instances of the entity
Attributes may be
 – simple or atomic values
– composite or complex values
– single and multi-valued
– derived

Simple or Atomic attributes:

Attributes that can’t be divided into subparts are called Simple or Atomic
attributes. For example, Employee Number is a simple attribute. Age of a
person is a simple attribute.

composite or complex values

• Composite attributes can be divided into smaller subparts. These
subparts represent basic attributes with independent meanings of
their own. For example, take Name attributes. We can divide it into
sub-parts like First_name, Middle_name, and Last_name.

Single valued and multi-valued Attributes

Attributes that can have single value at a particular instance of time are
called single valued. A person can’t have more than one age value.
Therefore, age of a person is a single-values attribute. A multi-valued
attribute can have more than one value at one time. For example, degree
of a person is a multi-valued attribute since a person can have more
than one degree. Where appropriate, upper and lower bounds may be
placed on the number of values in a multi-valued attribute. For example,
a bank may limit the number of addresses recorded for a single customer
to two.

Derived Attributes
There may be a case when two or more attributes values are related.
Take the example of age. Age of a person can be calculated from
person’s date of birth and present date. Difference between the two gives
the value of age. In this case, age is the derived attribute.
The attribute from which another attribute value is derived is called
stored attribute. In the above example, date of birth is the stored
attribute. Take another example, if we have to calculate the interest on
some principal amount for a given time, and for a particular rate of
interest, we can simply use the interest formula
Interest=NPR/100;
In this case, interest is the derived attribute whereas principal
amount(P), time(N) and rate of interest(R) are all stored attributes.
Derived attributes are usually created by a formula or by a summary
operation on other attributes.

Composite
Street

Address
City

State Simple
DOB

Null
Passport
port

Phone
No’s
Multi-valued

Age Derived

drive
Person s Car

Guidelines for Constructing an ERD

• determine the entities
• identify relationships between entities
• determine participation in each relationship
• determine cardinality of each relationship
• determine the unique identifier for each entity
• determine the unique identifier for each relationship
The degree of a relationship
• The degree of a relationship is the number of associated entities
– unary when relationship exists within a single entity
– binary when 2 entities are associated
– ternary when 3 entities are associated
– Relationships of degree higher than 3 are rare

Example of a unary relationship

• A subject requires a prerequisite, ie, another subject
• Hence is recursive, ie, has a relationship with itself

SUBJECT

Requires

Example of a binary relationship

• A child plays an instrument

Child Instrument
Plays
Example of Ternary Relationship set

E-R diagram with composite, multivalued, and derived attributes.

Weak Entity Sets

An entity set may not have sufficient attributes to form a primary key.
Such an entity set is termed a weak entity set. An entity set that has a
primary key is termed a strong entity set.
As an illustration, consider the entity set payment, which has the
three attributes: Payment-number, payment-date, and payment-amount.
Payment numbers are typically sequential numbers, starting from 1,
generated separately for each loan. Thus, although each payment entity
is distinct, payments for different loans may share the same payment
number. Thus, the entity set does not have a primary key; it is a weak
entity set.
For a weak entity set to be meaningful, it must be associated with
another entity set, called the identifying or owner entity set. Every weak
entity must be associated with an identifying entity; that is, the weak
entity set is said to be existence dependent on the identifying entity set.
The identifying entity set is said to own the weak entity set that it
identifies. The relationship associating the weak entity set with the
identifying entity set is called the identifying relationship. The
identifying relationship is many to one from the weak entity set to the
identifying entity set, and the participation of the weak entity set in the
relationship is total.
In our example, the identifying entity set for payment is loan, and
a relationship loan-payment that associates payment entities with their
corresponding loan entities is the identifying relationship.
Although a weak entity set does not have a primary key, we
nevertheless need a means of distinguishing among all those entities in
the weak entity set that depend on one particular strong entity. The
discriminator of a week entity set is a set of attributes that allows this
distinction to be made. For example, the discriminator of the weak entity
set payment is the attribute payment-number, since, for each loan, a
payment number uniquely identifies one single payment for that loan.
The discriminator of a weak entity set is also called the partial key of the
entity set.
The primary key of the identifying entity set, plus the weak entity
set’s discriminator forms the primary key of a weak entity set. In the
case of the entity set payment, its primary key is {loan-number,
payment-number}, where loan-number is the primary key of the
identifying entity set, namely loan, and payment-number distinguishes
payment entities within the same loan.
The identifying relationship set should have no descriptive
attributes, since any required attributes can be associated with the weak
entity set.
 A weak entity set can participate in relationships other than the
identifying relationship. For instance, the payment entity could
participate in a relationship with the account entity set, identifying the
account from which the payment was made. A weak entity set may
participate as owner in an identifying relationship with another weak
entity set. It is also possible to have a weak entity set with more than
one identifying entity set. A particular weak entity would then be
identified by a combination of entities, one from each identifying entity
set. The primary key of the weak entity set would consists of the union
of the primary keys of the identifying entity sets, plus the discriminator
of the weak entity set.
In E-R diagrams, a doubly outlined box indicates a weak entity set,
and a doubly outlined diamond indicates the corresponding identifying
relationship. In Figure 2.16, the weak entity set payment depends on the
strong entity set loan via the relationship set loan-payment.
The figure also illustrates the use of double lines to indicate total
participation—the participation of the (weak) entity set payment in the
relationship loan-payment is total, meaning that every payment must be
related via loan-payment to some loan. Finally, the arrow from loan-
payment to loan indicates that each payment is for a single loan. The
discriminator of a weak entity set also is underlined, but with a dashed,
rather than a solid, line.
In some cases, the database designer may choose to express a
weak entity set as a multivalued composite attribute of the owner entity
set. In our example, this alternative would require that the entity set
loan have a multivalued, composite attribute payment, consisting of
payment-number, payment-date, and payment-amount. A weak entity
set may be more appropriately modeled as an attribute if it participates
in only the identifying relationship, and if it has few attributes.
Conversely, a weak- entity-set representation will more aptly model a
situation where the set participates in relationships other than the
identifying relationship, and where the weak entity set has several
attributes.
 payment-date

loan-
number amoun
t
payment- payment-
number amount

loan-
loan paymen
t
payment

Figure 2.16. E-R diagram with a weak entity set.

As another example of an entity set that can be modeled as a weak
entity set, consider offerings of a course at a university. The same
course may be offered in different semesters, and within a semester there
may be several sections for the same course; different offerings of the
same course are identified by a semester and a section-number, which
form a discriminator but not a primary key.