Database Management

Systems
SCHOOL OF COMPUTER ENGINEERING AND TECHNOLOGY
 Database Management Systems

Course Objectives:

1.Understand and successfully apply logical database design principles, including E-R diagrams and database
normalization.
2. Learn Database Programming languages and apply in DBMS applications.
3. Understand transaction processing and concurrency control in DBMS.
4. Learn database architectures, DBMS advancements and its usage in advance applications.

Course Outcomes: Upon completion of the course, the students will be able to:

1.Design ER-models to represent simple database application scenarios and Improve the database design by
normalization.
2. Design Database Relational Model and apply SQL , PLSQL concepts for database programming.
3. Describe Transaction Processing and Concurrency Control techniques for databases.
4. Identify appropriate database architecture for the real world database applications.
DATABASE MANAGEMENT 2
SYSTEMS
 Introduction to Database Management Systems and Data
Modeling

Syllabus :
DBMS Vs File Systems, Database System Architecture, Data Abstraction, Data
Independence, Data Definition and Data Manipulation Languages, Database
System Internals-Components of a database system,
Data Models , E-R diagram: Components of E-R Model, Conventions, Keys, EER
diagram Components, E-R diagram into tables, Relational Model, Relational
Integrity, Referential Integrities, Enterprise Constraints, Schema Diagram,
Relational Algebra- Basic Operations, Normalization.

DATABASE MANAGEMENT 3
SYSTEMS
 Database Management System Basics

▪ It contains information about a particular enterprise. Database Applications

• Banking: Transactions
▪ It provides :
• Airlines: Reservations, Schedules
⮚Collection of interrelated data. • Universities : Student Registration.
• Sales: Customers, Orders, Products
⮚Set of programs to access the collected data. • Online retailers : Order tracking,
⮚An environment that is both convenient and recommendations
• Manufacturing :Production,
efficient to use.
Inventory, Supply Chain
⮚Databases touch all aspects of our lives. • Human Resources :Employee
payroll.

DATABASE MANAGEMENT 4
SYSTEMS
 Motivation for Database Management Systems
Traditional file Systems have following drawbacks to store data :
▪ Data Redundancy and Inconsistency
⮚ Multiple file formats, duplication of information in differentfiles
 Difficulty in accessing data
⮚Need to write a new program to carry out each new task.
▪ Data Isolation
⮚ Multiple files andformats.
Question : What can be other drawbacks related to usage of file systems ?

DATABASE MANAGEMENT 5
SYSTEMS
 Motivation for Database Management Systems
Answer : Traditional file Systems have following drawbacks to store data:
▪ Integrity Problems
⮚Integrity constraints (e.g., account balance > 0) become “buried” in
program code rather than being stated explicitly
⮚Difficult to add new constraints or change existing ones
▪ Atomicity of Updates
⮚Failures may leave database in an inconsistent state with partial updates
carried out.

DATABASE MANAGEMENT 6
SYSTEMS
 Motivation for Database Management Systems
Traditional file Systems have following drawbacks to store data :
▪ Concurrent Access by Multiple users
⮚Concurrent access needed for performance.
⮚Uncontrolled concurrent accesses can lead to inconsistencies.
▪ Security Problems
⮚Hard to provide user access to some, but not all, data
Database Management Systems offers solutions to all the above
problems/limitations of traditional file systems.

DATABASE MANAGEMENT 7
SYSTEMS
Database System Architectures

Centralized and Client-Server Systems

Server System Architectures
Parallel Systems
Distributed Systems
Centralized Systems
Run on a single computer system and do not interact with other computer systems.
General-purpose computer system: one to a few CPUs and a number of device controllers that are
connected through a common bus that provides access to shared memory.
Single-user system (e.g., personal computer or workstation): desk-top unit, single user, usually has
only one CPU and one or two hard disks; the OS may support only one user.
Multi-user system: more disks, more memory, multiple CPUs, and a multi-user OS. Serve a large
number of users who are connected to the system vie terminals. Often called server systems.
Client-Server Systems

Server systems satisfy requests generated at m client systems, whose general

structure is shown below:
Client-Server Systems (Cont.)
Database functionality can be divided into:
Back-end: manages access structures, query evaluation and optimization,
concurrency control and recovery.
Front-end: consists of tools such as forms, report-writers, and graphical user
interface facilities.
The interface between the front-end and the back-end is through SQL or through an
application program interface.
 Client-Server Systems (Cont.)

Advantages of replacing mainframes with networks of

workstations or personal computers connected to back-end
server machines:
better functionality for the cost
flexibility in locating resources and expanding facilities
better user interfaces
easier maintenance
 Parallel Systems
Parallel database systems consist of multiple processors and multiple disks connected by a fast interconnection network.
A coarse-grain parallel machine consists of a small number of powerful processors
A massively parallel or fine grain parallel machine utilizes thousands of smaller processors.
Two main performance measures:
throughput --- the number of tasks that can be completed in a given time interval
response time --- the amount of time it takes to complete a single task from the time it is submitted
Parallel Database Architectures
 Shared Memory
Processors and disks have access to a common memory,
typically via a bus or through an interconnection network.
Extremely efficient communication between processors —
data in shared memory can be accessed by any processor
without having to move it using software.
Downside – architecture is not scalable beyond 32 or 64
processors since the bus or the interconnection network
becomes a bottleneck
Widely used for lower degrees of parallelism (4 to 8).
Shared Disk
All processors can directly access all disks via an interconnection network, but
the processors have private memories.
The memory bus is not a bottleneck
Architecture provides a degree of fault-tolerance — if a processor fails,
the other processors can take over its tasks since the database is resident
on disks that are accessible from all processors.
Examples: IBM Sysplex and DEC clusters (now part of Compaq) running Rdb
(now Oracle Rdb) were early commercial users
Downside: bottleneck now occurs at interconnection to the disk subsystem.
Shared-disk systems can scale to a somewhat larger number of processors,
but communication between processors is slower.
 Shared Nothing
Node consists of a processor, memory, and one or more disks. Processors at one
node communicate with another processor at another node using an
interconnection network. A node functions as the server for the data on the disk
or disks the node owns.
Examples: Teradata, Tandem, Oracle-n CUBE
Data accessed from local disks (and local memory accesses) do not pass through
interconnection network, thereby minimizing the interference of resource
sharing.
Shared-nothing multiprocessors can be scaled up to thousands of processors
without interference.
Main drawback: cost of communication and non-local disk access; sending data
involves software interaction at both ends.
Hierarchical

Combines characteristics of shared-memory, shared-disk, and shared-nothing

architectures.
Top level is a shared-nothing architecture – nodes connected by an interconnection
network, and do not share disks or memory with each other.
Each node of the system could be a shared-memory system with a few processors.
Alternatively, each node could be a shared-disk system, and each of the systems
sharing a set of disks could be a shared-memory system.
Reduce the complexity of programming such systems by distributed virtual-memory
architectures
Also called non-uniform memory architecture (NUMA)
Distributed Systems
Data spread over multiple machines (also referred to as sites or nodes).
Network interconnects the machines
Data shared by users on multiple machines
 Distributed Databases
Homogeneous distributed databases
Same software/schema on all sites, data may be partitioned among sites
Goal: provide a view of a single database, hiding details of distribution
Heterogeneous distributed databases
Different software/schema on different sites
Goal: integrate existing databases to provide useful functionality
Differentiate between local and global transactions
A local transaction accesses data in the single site at which the transaction
was initiated.
A global transaction either accesses data in a site different from the one at
which the transaction was initiated or accesses data in several different
sites.
 Levels of Data Abstraction in Database System

▪ Physical level: describes how a record (e.g.,

customer) is stored.
▪Logical level: describes data stored in database, and
the relationships among the data.
type instructor = record
ID : string;
name : string;
dept_name : string;
salary : integer;
end;

▪View level: application programs hide details of data

types. Views can also hide information (such as an
employee’s salary) for security purposes.
Levels of Abstraction in a Database System
DATABASE MANAGEMENT 21
SYSTEMS
 Instances and Schema

▪Schema – the logical structure of the

database
◦ Example: The database consists of information about a set
of customers and accounts and the relationship between
them
⮚ Physical schema: database design at the physical level
⮚ Logical schema: database design at the logical level

– the actual content of the

▪Instance
database at a particular point in time
⮚ Analogous to the value of a variable.

DATABASE MANAGEMENT 22
SYSTEMS
 Data Independence
Types of Data Independence :
▪ Physical Data Independence : the ability to modify the physical schema without
changing the logical schema
⮚ Applications depend on the logical schema
⮚In general, the interfaces between the various levels and components should be
well defined so that changes in some parts do not seriously influence others.
▪Logical Data Independence : the ability to change the conceptual scheme without
changing
⮚External views
⮚External API or programs
⮚Any change made will be absorbed by the mapping between external and
conceptual levels.
⮚When compared to Physical Data independence, it is challenging to achieve
logical data independence.

DATABASE MANAGEMENT 23
SYSTEMS
Database System Languages

Data Definition Language(DDL) Data Manipulation Language(DML)

Specification notation for defining the database schema Language for accessing and manipulating the data
Example: create table instructor ( organized by the appropriate data model
ID char(5), ◦ DML also known as query language
name varchar(20),
dept_name varchar(20), Two classes of languages
salary numeric(8,2))
◦ Procedural – user specifies what data is required
DDL compiler generates a set of table templates stored in a and how to get those data
data dictionary ◦ Declarative (nonprocedural) – user specifies
Data dictionary contains metadata (i.e., data about what data is required without specifying how to
data) get those data
◦ Database schema
SQL is the most widely used query language
◦ Integrity constraints
◦ Primary key (ID uniquely identifies instructors)
◦ Referential integrity (references constraint in SQL)
◦ e.g. dept_name value in any instructor tuple must
appear in department relation
DATABASE MANAGEMENT 24
SYSTEMS
 Data Models
A collection of tools for describing :
▪ Data
▪ Data relationships
▪ Data semantics
▪ Data constraints

DATABASE MANAGEMENT 25
SYSTEMS
Database System Structure/Architecture

Important Components of
Database System :
⮚Database Users
⮚Query Processing
⮚Storage Management
⮚Transaction Management

DATABASE MANAGEMENT 26
SYSTEMS
Database System Components : Database Users

Types of Database Users :

⮚Naive Users
⮚Application Programmers
⮚Sophisticated Users
⮚Database Administrators

DATABASE MANAGEMENT 27
SYSTEMS
Database System Components : Query Processing

Query Processing
Steps :

1.Parsing and
Translation
2.Optimization
3.Evaluation

DATABASE MANAGEMENT 28
SYSTEMS
 Database System Components :Storage
Management

Storage manager : is a program module Issues:

that provides the interface between the
low-level data stored in the database and
the application programs and queries ▪ Storage access
submitted to the system. ▪ File organization
It is responsible for the following tasks: ▪ Indexing and hashing
▪ Interaction with the file manager
▪ Efficient storing, retrieving and
updating of data

DATABASE MANAGEMENT 29
SYSTEMS
 Database System Components :Transaction
Management

What if the system fails? ▪ Transaction-management component

What if more than one user is concurrently updating ensures that the database remains in a
the same data? consistent (correct) state despite system
failures (e.g., power failures and operating
A transaction is a collection of operations that system crashes) and transaction failures.
performs a single logical function in a database
application.
▪ Concurrency-control manager controls
Two Important Components related to the interaction among the concurrent
Transactions: transactions, to ensure the consistency of
the database.
▪ Transaction Manager
▪ Concurrency Control Manager

DATABASE MANAGEMENT 30
SYSTEMS
 Entity Relationship Model
▪ A database can be modeled as:
◦ a collection of entities,
◦ relationship among entities.
▪ An entity is an object that exists and is distinguishable
from other objects.
◦ Example: specific person, company, event, plant
▪ Entities have attributes
◦ Example: people have names and addresses
▪ An entity set is a set of entities of the same type that
share the same properties.
◦ Example: set of all persons, companies, trees,
holidays

DATABASE MANAGEMENT 31
SYSTEMS
 Relationship Sets

A relationship is an association among several entities

Example:
44553 (Peltier) advisor 22222
(Einstein)
student entity relationship set instructor
entity
A relationship set is a mathematical relation among n ≥
2 entities, each taken from entity sets
{(e1, e2, … en) | e1 ∈E1, e2 ∈E2, …, en ∈En}

where (e1, e2, …, en) is a relationship

◦ Example:
(44553,22222) ∈advisor
DATABASE MANAGEMENT 32
SYSTEMS
 Relationship Sets

▪ An attribute can also be property of a

relationship set.
⮚For instance, the advisor relationship set
between entity sets instructor and student
may have the attribute date which tracks
when the student started being associated
with the advisor

DATABASE MANAGEMENT 33
SYSTEMS
 Degree of a Relationship Set

▪ Binary relationship ▪ Ternary relationship

⮚involve two entity sets (or degree two). ⮚ Example: students work on research
⮚most relationship sets in a database system projects under the guidance of an
are binary. instructor.
⮚ relationship proj_guide is a ternary
Relationships between more than two entity relationship between instructor, student,
sets are rare. Most relationships are binary. and project

DATABASE MANAGEMENT 34
SYSTEMS
 Attributes

▪ Attribute types
⮚ Simple and composite attributes. ▪An entity is represented by a set of
⮚ Single-valued and multivalued attributes. attributes, that is descriptive properties
Example: multivalued attribute: possessed by all members of an entity set.
phone_numbers ◦ Example:
⮚ Derived attributes instructor = (ID, name, street, city,
Can be computed from other attributes salary )
Example: age, given date_of_birth course= (course_id, title, credits)
▪ Domain – the set of permitted values for
each attribute

DATABASE MANAGEMENT 35
SYSTEMS
 Mapping Cardinality Constraints

Express the number of entities to which

another entity can be associated via a
relationship set.
Most useful in describing binary relationship
sets.
For a binary relationship set the mapping One to one One to many
cardinality must be one of the following types:
⮚One to one
⮚One to many
⮚Many to one
⮚Many to many
Many to one Many to many
DATABASE MANAGEMENT 36
SYSTEMS
 Keys for Relationship Sets

The combination of primary keys of the participating entity sets forms a

super key of a relationship set.
◦ (s_id, i_id) is the super key of advisor
◦ NOTE: this means a pair of entity sets can have at most one relationship in
a particular relationship set.
◦ Example: if we wish to track multiple meeting dates between a student and
her advisor, we cannot assume a relationship for each meeting. We can use a
multivalued attribute though
Must consider the mapping cardinality of the relationship set when deciding
what are the candidate keys

DATABASE MANAGEMENT 37
SYSTEMS
Entity Relationship Diagram

DATABASE MANAGEMENT 38
SYSTEMS
 Entity-Relationship Diagram
It is a graphical Representation of ER Model
Basic Notations :

▪ Rectangles represent entity sets.

▪ Diamonds represent relationship sets.
▪ Attributes listed inside entity rectangle
▪ Underline indicates primary key attributes

DATABASE MANAGEMENT 39
SYSTEMS
 Entity Relationship Diagram Continued
▪ Entity With Composite, ▪ Relationship Sets with Attributes
Multivalued, and Derived
Attributes

DATABASE MANAGEMENT 40
SYSTEMS
 Entity Relationship Diagram Continued

Roles
⮚ Entity sets of a relationship need not be distinct.
⮚Each occurrence of an entity set plays a “role” in the relationship.
The labels “course_id” and “prereq_id” are called roles.

DATABASE MANAGEMENT 41
SYSTEMS
 Entity Relationship Diagram Continued

Cardinality Constraints
⮚We express cardinality constraints by drawing either a directed line (→), signifying “one,” or
an undirected line (—), signifying “many,” between the relationship set and the entity set.
1. One-to-One Relationship
one-to-one relationship between an
instructor and a student
◦ an instructor is associated with at
most one student via advisor
◦ and a student is associated with at
most one instructor via advisor

DATABASE MANAGEMENT 42
SYSTEMS
 Entity Relationship Diagram Continued

b. One-to-Many Relationship
A one-to-many relationship between an instructor and a student
⮚a an instructor is associated with several (including 0) students viaadvisor
⮚student is associated with at most one instructor via advisor
c. Many-to-One Relationship
In a many-to-one relationship between an instructor and a student,
⮚an instructor is associated with at most one student via advisor,
⮚and a student is associated with several (including 0) instructors via advisor
d. Many-to Many Relationship
⮚An instructor is associated with several (possibly 0) students via advisor

⮚A student is associated with several (possibly 0) instructors via advisor

DATABASE MANAGEMENT 43
SYSTEMS
 Entity Relationship Diagram Continued

Participation of an Entity Set in a Relationship

Set
▪ Total participation (indicated by double line):
every entity in the entity set participates in at least
one relationship in the relationship set
• E.g., participation of section in sec_course is
total
4 every section must have an associated course
▪ Partial participation: some entities may not
participate in any relationship in the relationship
set
▪ Example: participation of instructor in advisor
is partial

DATABASE MANAGEMENT 44
SYSTEMS
 Entity Relationship Diagram : Weak Entity Sets

⮚An entity set that does not have a primary key is referred to as a
weak entity set.
⮚The existence of a weak entity set depends on the existence of a
identifying entity set
◦ It must relate to the identifying entity set via a total, one-to-
many relationship set from the identifying to the weak entity
set
◦ Identifying relationship depicted using a double diamond ▪ We underline the discriminator of a
weak entity set with a dashed line.
⮚The discriminator (or partial key) of a weak entity set is the set ▪ We put the identifying relationship
of attributes that distinguishes among all the entities of a weak of a weak entity in a double
entity set.
diamond.
The primary key of a weak entity set is formed by the primary key ▪ Primary key for section –
of the strong entity set on which the weak entity set is existence (course_id, sec_id, semester, year)
dependent, plus the weak entity set’s discriminator.
DATABASE MANAGEMENT 45
SYSTEMS
Example of Strong and Weak Entity

Strong Entity :
Professor(ID,Name,City,Salary)

Weak Entity :
Dependent(Name,DOB,Relation)
The Dependent Entity will share the ID
attribute of Professor.
Resultant Schema :
Dependent(ID,Name,DOB,Relation)
The primary key for Weak Entity Dependent
will be ID + Name as Name is the
discriminator attribute.

DATABASE MANAGEMENT 46
SYSTEMS
 E-R Diagram Example
Question : Design an ER Diagram for Airline Reservation scenario given below :
The flight database stores details about an airline’s fleet, flights, and seat bookings.
Consider the following scenario:
• The airline has one or more airplanes.
• An airplane has a model number, a registration number, and the capacity to take one or more passengers.
• An airplane flight has a unique flight number, a departure airport, a destination airport, a departure date
and time, and an arrival date and time.
• Each flight is carried out by a single airplane.
• A passenger has given names(first name, last name),contact and a unique email address.
• Passengers can book seats on flights.

DATABASE MANAGEMENT 47
SYSTEMS
 Flight Reservation ERD
Last
Name
Contact
Airline Passenger
_name Airline
Name

Email
Has Books
First
NAme
Model
_no

Airplane particip Flight

Model_ ates To
name

Flight_ Arrival_Dat
Capacity
No e_Time
From Departure
_Date_Ti
me
DATABASE MANAGEMENT 48
SYSTEMS
Extended ER Features :
⮚ Specialization
⮚ Generalization
⮚ Aggregation

DATABASE MANAGEMENT 49
SYSTEMS
 Extended ER Features : Specialization

⮚Top-down design process; we designate subgroupings within an entity set that are distinctive from other
entities in the set.
⮚These subgroupings become lower-level entity sets that have attributes or participate in relationships
that do not apply to the higher-level entity set.
⮚Depicted by a triangle component labeled IS A (E.g., instructor “is a” person).
⮚Attribute inheritance – a lower-level entity set inherits all the attributes and relationship participation
of the higher-level entity set to which it is linked.

DATABASE MANAGEMENT 50
SYSTEMS
Specialization : Example

DATABASE MANAGEMENT 51
SYSTEMS
 Extended ER Features : Generalization
⮚A bottom-up design process – combine a number of entity sets that share the same
features into a higher-level entity set.
⮚Specialization and generalization are simple inversions of each other; they are
represented in an E-R diagram in the same way.
⮚The terms specialization and generalization are used interchangeably.

DATABASE MANAGEMENT 52
SYSTEMS
Generalization : Example

DATABASE MANAGEMENT 53
SYSTEMS
 Extended ER Features : Aggregation

▪ Consider the ternary relationship proj_guide, which

we saw earlier
▪ Suppose we want to record evaluations of a student
by a guide on a project.
▪Relationship sets eval_for and proj_guide represent
overlapping information
▪ Every eval_for relationship corresponds to a
proj_guide relationship
▪ However, some proj_guide relationships may not
correspond to any eval_for relationships
◦ So we can’t discard the proj_guide relationship

DATABASE MANAGEMENT 54
SYSTEMS
 Extended ER Features : Aggregation
⮚Eliminate this redundancy via aggregation
▪ Treat relationship as an abstract entity
▪ Allows relationships between relationships
▪ Abstraction of relationship into new entity

⮚Without introducing redundancy, the following

diagram represents:
▪ A student is guided by a particular instructor on a
particular project
▪ A student, instructor, project combination may have
an associated evaluation

DATABASE MANAGEMENT 55
SYSTEMS
Reduction of ER Diagram to
Relation Schemas

DATABASE MANAGEMENT 56
SYSTEMS
 Reduction to Relation Schemas

▪Entity sets and relationship sets can be expressed uniformly as relation

schemas that represent the contents of the database.
▪A database which conforms to an E-R diagram can be represented by a
collection of schemas.
▪For each entity set and relationship set there is a unique schema that is
assigned the name of the corresponding entity set or relationship set.
▪ Each schema has a number of columns (generally corresponding to
attributes), which have unique names

DATABASE MANAGEMENT 57
SYSTEMS
 Reduction to Relation Schemas

Representing Entity Sets with Simple Attributes Representing Relationship Sets :

A strong entity set reduces to a schema with the same

attributes
course(course_id,title,credits) A many-to-many relationship set is represented as
a schema with attributes for the primary keys of
course_id title credits the two participating entity sets, and any
descriptive attributes of the relationship set.
A weak entity set becomes a table that includes a
column for the primary key of the identifying strong Example: schema for relationship set advisor
entity set
section ( cours e_id, sec_id, sem, year ) year advisor = (s_id, i_id) S_id i_id
Course_id Sec_id sem
DATABASE MANAGEMENT 58
SYSTEMS
 Reduction to Relation Schema
Redundancy of schemas:
▪Many-to-one and one-to-many relationship sets that are total on the many-side can be
represented by adding an extra attribute to the “many” side, containing the primary
key of the “one” side.

Inst_d
Dept Instructor
ept

Example: Instead of creating a schema for relationship set inst_dept, add an attribute
dept_name to the schema arising from entity set instructor

DATABASE MANAGEMENT 59
SYSTEMS
 Reduction to Relation Schema
Representing Composite and Multi-valued
Attributes
▪ Composite attributes are flattened out by creating a
separate attribute for each component attribute
◦ Example: given entity set instructor with composite
attribute name with component attributes first_name and
last_name the schema corresponding to the entity set has
two attributes name_first_name and name_last_name
◦ Prefix omitted if there is no ambiguity
▪ Ignoring multivalued attributes, extended instructor schema is :
ID First_nam Middle_initial Last_name Street_ Street_ Apt_num city state zip Date_of
e number name ber _birth

DATABASE MANAGEMENT 60
SYSTEMS
 Reduction to Relation Schema
Representing Composite and Multi-valued Attributes
A multivalued attribute M of an entity E is represented by a
separate schema EM
◦ Schema EM has attributes corresponding to the primary key of
E and an attribute corresponding to multivalued attribute M
◦ Example: Multivalued attribute phone_number of instructor is
represented by a schema:
inst_phone= ( ID, phone_number)
◦ Each value of the multivalued attribute maps to a separate tuple
of the relation on schema EM
◦ For example, an instructor entity with primary key 22222 ID Phone_number
and phone numbers 456-7890 and 123-4567 maps to two
tuples: 22222 456-7890
(22222, 456-7890) and (22222, 123-4567) 22222 123-4567

DATABASE MANAGEMENT 61
SYSTEMS
Extended ER Features Reduction to Relation Schemas

DATABASE MANAGEMENT 62
SYSTEMS
Example for Reduction of ER Diagram to Relation schemas
University
1 Reduced
Schema-
Names
Contains Universit
y
N Facult
y
Faculty Scho
1 ol
Progra
Divided m
into Lecture
r
Cours
1 N 1 e
School offers Program Studen
1 t
Full-
time_
Employe
contains Lecturer
e Part-
time_Lecture
M N r
M N Lect_Cours
Lecturer teaches Course enrolls e
N (Associativ
IS
e Entity
A
due to
enrolls Student_Course
Contact M:M)
( Associative
Full-Time Part-time N Entity due to
Lecturer DATABA MANAGEMENT
Lecturer N 5
SE SYSTEMS Student M:M) 0
Relational Algebra

DATABASE MANAGEMENT 64
SYSTEMS
 Relational Algebra

▪ Basic Relational Algebra Operations:

⮚Select σ
▪ What is “algebra ?
⮚Project ∏
▪ Mathematical model consisting of: ⮚Union ∪
▪ Operands --- Variables or values; ⮚Set Difference (or Subtract or minus) –
▪ Operators --- Symbols denoting procedures
that construct new values from a given values ⮚Cartesian Product X

▪Relational Algebra : is an algebra whose ⮚Natural Join

operands are relations and operators are
designed to do the most commons things that
we need to do with relations

DATABASE MANAGEMENT SYSTEMS 65

 Relational Algebra: Select Operation

Example of selection:
▪ Notation: σ p(r)
Account(account_number, branch_name,balance)
p is called the selection predicate σ branch-name=“Perryridge”(account)
⮚Defined as:
A B C D A B C D
σp(r) = {t | t ∈r and p(t)} α 1 7 α 1 7
α α
⮚ Where p is a formula in propositional
calculus consisting of terms connected by : ∧ α β 5 7 β β 23 10
(and), ∨(or), ¬ (not)
Each term is one of: β β 12 3
<attribute> op <attribute> or <constant> σA=B ^ D > 5 (r)
β β 23 10
where op is one of: =, ≠, >, ≥. <. ≤
Relation r
DATABASE MANAGEMENT SYSTEMS 66
 Relational Algebra: Project Operation

▪ Notation: ∏A1, A2, …, Ak (r) Example of Project Operation :

where A1, A2 are attribute names and r is a relation. A B C A C

⮚The result is defined as the relation of k columns α 10 1 1
α
obtained by erasing the columns that are not listed A C
⮚Duplicate rows removed from result, since relations α 20 1
α 1 α 1
are sets
=
E.g. to eliminate the branch-name attribute of β 30 1 β 1 β 1
account
∏account-number, balance (account) 2
β 40 2 β 2
β
⮚If relation Account contains 50 tuples, how many
tuples contains ∏account-number, balance (account) ? Relation r ∏A,C (r)
That is, the projection of a relation on a set of attributes is
a set of tuples

DATABASE MANAGEMENT SYSTEMS 67

 Relational Algebra: Union Operation

▪ Notation: r ∪s Example of Union:

A B
⮚Consider relational schemas: A B
α 1
Depositor(customer_name, account_number) α 1
A B
Borrower(customer_name, loan_number) α 2
α 2 α 2
⮚For r ∪ s to be valid. β 1
β 1 β 3
1. r, s must have the same number of attributes β 3
2.The attribute domains must be compatible (e.g., 2nd
column of r deals with the same type of values as does Relation r Relation s
the 2nd column of s) r ∪s
⮚ Find all customers with either an account or a loan
∏customer-name (depositor) ∪ ∏customer-name (borrower)

DATABASE MANAGEMENT SYSTEMS 68

 Relational Algebra: Set Difference Operation

Example of Set Difference:

▪ Notation : r – s
A B
Set differences must be taken between
α 1
compatible relations. A B A B
▪ r and s must have the same number 2 1
α 2 α α
of attributes
▪ attribute domains of r and s must be β 1 β 3 β 1
compatible
Relation r Relation s r-s

DATABASE MANAGEMENT SYSTEMS 69

 Relational Algebra: Cartesian Product Operation

▪ Notation : rxs A B C D E
C D E
α 1 α 10 a
α 10 a
α 1 β 10 a
Assume that attributes of r(R) and s(S) are disjoint.
(That is, R ∩ S = ∅). β 10 a
A B r ⅹs α 1 β 20 b
If attributes of r(R) and s(S) are not disjoint, then 1
renaming must be used. α β 20 b
α 1 γ 10 b
β 2 γ 10 B β 2 α 10 a

β 2 β 10 a
Relation r
Relation s β 2 β 20 b
β 2 γ 10 b

DATABASE MANAGEMENT SYSTEMS 70

 Relational Algebra: Natural Join Operation

▪ Notation : r ⋈s
▪ We can perform a Natural Join only if there is
at least one common attribute that exists
between two relations
▪ The common attributes must have the same
name and domain. A B A C r ⋈s A B C
▪ Natural join acts on those matching attributes
α 1 α 10 α 1 10
where the values of attributes in both the
relations are same. β 30 β 2 30
β 2
▪ It avoids duplication of columns while
providing the result as compared to other
joins/cartesian-product. Relation r Relation s

DATABASE MANAGEMENT SYSTEMS 71

Relational Algebra Operators

DATABASE MANAGEMENT 72
SYSTEMS
 References

Text Books:
• Abraham Silberschatz, Henry F. Korth and S. Sudarshan, Database System Concepts 6th
Ed, McGraw Hill, 2010.
• Elmasi, R. and Navathe, S.B., “Fundamentals of Database Systems”, 4th
• Ed., Pearson Education.
Reference Books :
• Ramakrishnan, R. and Gherke, J., “Database Management Systems”, 3rd Ed., McGraw-
Hill.
• Connally T, Begg C.,”Database Systems”,Pearson Education

DATABASE MANAGEMENT 73
SYSTEMS
End

DATABASE MANAGEMENT 74
SYSTEMS