AID2PM02A Database Management System

SY AIDS SEM-3 AY-2024-25

School of Computer Science and Engineering
 AID2PM02A Database Management System
Course Objectives:
1. Understand the fundamental concepts of database management System
2. To provide a strong formal foundation in database concepts, DBMS architectures recent technologies
and best industry practices.
3. To learn the SQL database system.
4. To program PL/SQL including stored procedures, stored functions, cursors and packages.
5. To design the database system for real world applications.
6. To access, modify, program and authenticate the database system.

Course Outcomes:
After completion of this course students will be able to:
1. Understand the different data models.
2. Implement relational database design from any data model.
3. Create database system for real world applications
4. Handle the transaction management system.

2
CCA & LCA Component & Evaluation

CCA1 CCA2 CCA3

MCQ on Moodle Midterm Problem-based
Learning

Unit 3 Unit 1 & 2 Unit 4, 5

15 mks 30mks 15 mks
18th to 24th August 14th to 20th October 18th to 23rd
November

3
 Unit 1: Introduction to DBMS and Data Modelling

Unit 1: Introduction to DBMS and Data Modelling

DBMS Vs. File Systems, Database System Architecture, Database Architectures:
Centralized,
Client-Server, Parallel, Distributed, Data Abstraction, Data Independence, Data
Definition and
Data Manipulation Languages, Data Models, E-R diagram: Components of E-R
Model, Conventions, Keys, EER diagram Components, Reduce E-R diagram into
Tables

4
 History of Database Management System

• 1950s and early 1960s:

– Data processing using magnetic tapes for storage
• Tapes provided only sequential access
– Punched cards for input
• Late 1960s and 1970s:
– Hard disks allowed direct access to data
– Network and hierarchical data models in widespread use
– Ted Codd defines the relational data model
• Would win the ACM Turing Award for this work
• IBM Research begins System R prototype
• UC Berkeley begins Ingres prototype
– High-performance (for the era) transaction processing

5
 History(Contd.)
• 1980s:
– Research relational prototypes evolve into commercial systems
• SQL becomes industrial standard
– Parallel and distributed database systems
– Object-oriented database systems
• 1990s:
– Large decision support and data-mining applications
– Large multi-terabyte data warehouses
– Emergence of Web commerce
• Early 2000s:
– XML and XQuery standards
– Automated database administration
• Later 2000s:
– Giant data storage systems
• Google BigTable, Yahoo PNuts, Amazon, ..

6
 Basics of Database Management System
• DBMS contains information about a particular enterprise
– Collection of interrelated data Eg.-University Database
– Set of programs to access the data Example
– An environment that is both convenient and efficient to use • Application program examples
– Databases can be very large. – Add new students, instructors,
• Database Applications: and courses
– Banking: transactions – Register students for courses,
– Airlines: reservations, schedules and generate class rosters
– Universities: registration, grades – Assign grades to students,
– Sales: customers, products, purchases compute grade point averages
– Online retailers: order tracking, customized recommendations (GPA) and generate transcripts
– Manufacturing: production, inventory, orders, supply chain
– Human resources: employee records, salaries, tax deductions

7
 DBMS Vs File Systems
• Drawbacks of using file systems to store data
– Data redundancy and inconsistency
• Multiple file formats, duplication of information in different files
– Difficulty in accessing data
• Need to write a new program to carry out each new task
– Data isolation
• Multiple files and formats
– Integrity problems
• Integrity constraints (e.g., account balance > 0) become “buried” in program code rather than
being stated explicitly
• Hard to add new constraints or change existing ones Atomicity of updates
– Failures may leave database in an inconsistent state with partial updates carried out
– Example: Transfer of funds from one account to another should either complete or not happen at all

8
 DBMS Vs File Systems contd.
• Concurrent access by multiple users
– Concurrent access needed for performance
– Uncontrolled concurrent accesses can lead to inconsistencies
• Example: Two people reading a balance (say 100) and updating it by withdrawing money (say 50
each) at the same time
• Security problems
– Hard to provide user access to some, but not all, data

9
 Database System Architectures

• Centralized and
• Client-Server Systems
• Parallel Systems
• Distributed Systems

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

11
Client-Server
Systems
• Server systems satisfy requests
generated at m client systems,
whose general structure is shown
in the dig.
• 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.
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

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

14
 Levels of Abstraction

An architecture for a database system

• Physical level: describes how a record (e.g.,
instructor) 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.

15
 Instances and Schemas

• 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

• Instance – the actual content of the database at a

particular point in time
⮚ Analogous to the value of a variable.

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

17
 Data Models
• A collection of tools for describing
– Data
– Data relationships
– Data semantics
– Data constraints
• Relational model
• Entity-Relationship data model (mainly
for database design)
• Object-based data models (Object-
oriented and Object-relational)
• Semistructured data model (XML)
• Other older models:
– Network model
– Hierarchical model
 Database System Languages

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

• Specification notation for defining the database schema • Language for accessing and manipulating
Example: create table instructor ( the data organized by the appropriate
ID char(5), data model
name varchar(20),
dept_name varchar(20), – DML also known as query language
salary numeric(8,2)) • Two classes of languages
• DDL compiler generates a set of table templates stored – Pure – used for proving properties about
in a data dictionary computational power and for optimization
• Data dictionary contains metadata (i.e., data about data) • Relational Algebra
– Database schema • Tuple relational calculus
– Integrity constraints • Domain relational calculus
• Primary key (ID uniquely identifies instructors) – Commercial – used in commercial systems
– Authorization • SQL is the most widely used commercial
language
• Who can access what

19
 Database System
Structure/Architecture

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

20
Database System Components
: Database Users

Types of Database Users :

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

21
Database System Components : Query Processing

DML Pre-Compiler:
• It converts DML statements embedded in an application program to normal procedure calls in the host
language.
• The pre-complier must interact with the query processor in order to generate the appropriate code.
DDL Compiler:
• The DDL compiler converts the data definition statements into a set of tables. These tables contains
information concerning the database and are in a form that can be used by other components of the
dbms.
File Manager:
• File manager manages the allocation of space on disk storage and the data structure used to represent
information stored on disk.
Query Processor:
• The query processor used to interpret to online user’s query and convert it into an efficient series of
operations in a form capable of being sent to the data manager for execution.
• The query processor uses the data dictionary to find the details of data file and using this information it
create query plan/access plan to execute the query.
22
Database System Components
: Query Processing

1.Parsing and Translation

2.Optimization
3.Evaluation
• Alternative ways of evaluating a
given query
• Equivalent expressions
• Different algorithms for each
operation

• Need to estimate the cost of

operations
• Depends critically on statistical
information about relations which
the database must maintain
• Need to estimate statistics for
intermediate results to compute
cost of complex expressions

23
Database System Components : Query Processing

Data Dictionary:
• Data dictionary is the table which contains the information about database objects. It contains
information like

1. external, conceptual and internal database description

2. description of entities, attributes as well as meaning of data elements
3. synonyms, authorization and security codes
4. database authorization

Database Manager/Storage Manager:

• A database manager is a program module which provides the interface between the low level
data stored in the database and the application programs and queries submitted to the system.

24
 Database System Components :Storage
Management

• A general purpose database manager (DBM) has five responsibilities:

a. interaction with the file manager.
b. integrity enforcement.
c. security enforcement.
d. backup and recovery.
e. concurrency control.

• Issues:
– Storage access
– File organization
25
– Indexing and hashing
 Database System Components :Transaction
Management

• What if the system fails?

• What if more than one user is concurrently updating the same data?
• A transaction is a collection of operations that performs a single logical
function in a database application.
• Two Important Components related to Transactions:
▪ Transaction Manager
▪ Concurrency Control Manager

• Transaction-management component ensures that the database remains in a

consistent (correct) state despite system failures (e.g., power failures and
operating system crashes) and transaction failures.

• Concurrency-control manager controls the interaction among the concurrent

transactions, to ensure the consistency of the database.
26
 Data Models
• A collection of tools for describing
– Data
– Data relationships
– Data semantics
– Data constraints
• Relational model
• Entity-Relationship data model (mainly
for database design)
• Object-based data models (Object-
oriented and Object-relational)
• Semistructured data model (XML)
• Other older models:
– Network model
– Hierarchical model
 Modeling-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
 Keys
• A super key of an entity set is a set of one or more attributes whose values uniquely determine each
entity.
• A candidate key of an entity set is a minimal super key
– ID is candidate key of instructor
– course_id is candidate key of course
• Although several candidate keys may exist, one of the candidate keys is selected to be the primary
key.
 Relationship Sets
Realtionship set Advisor
• 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
 E-R Diagrams

● Rectangles represent entity sets.

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

Note: ER diagram notation in 6th edition of Database System Concepts changed from earlier
editions; now based on UML class diagram notation with some modifications.
 Relationship Sets With Attributes
• 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
– E.g. date may track when the student started being associated with the advisor
Relationship Sets with Attributes
 Attributes
• An entity is represented by a set of attributes, that is descriptive properties possessed by all members
of an entity set.
– Example:
instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
• Domain – the set of permitted values for each attribute
• Attribute types:
– Simple and composite attributes.
– Single-valued and multivalued attributes
• Example: multivalued attribute: phone_numbers
– Derived attributes
• Can be computed from other attributes
• Example: age, given date_of_birth
Composite Attributes
Entity With Composite, Multivalued, and Derived Attributes

composite

multivalued

derived
 Degree of a Relationship Set
• binary relationship
– involve two entity sets (or degree two).
– most relationship sets in a database system are
binary.
• Relationships between more than two entity sets are
rare. Most relationships are binary. (More on this
later.)

Example:

students work on research projects under the guidance of

an instructor.

relationship proj_guide is a ternary relationship between

instructor, student, and project
 Degree of a Relationship Set

• Ternary relationship
⮚Example: students work
on research projects under
the guidance of an
instructor.
⮚relationship proj_guide
is a ternary relationship
between instructor,
student, and project
38
 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 cardinality must be one of the following types:
– One to one
– One to many
– Many to one
– Many to many
 Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any

elements in the other set
 Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any

elements in the other set
 ER Notation for 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.
• One-to-one relationship:
– A student is associated with at most one instructor via the relationship advisor
– A student is associated with at most one department via stud_dept
 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
 One-to-Many Relationship
• one-to-many relationship between an instructor and a student
– an instructor is associated with several (including 0) students via advisor
– a student is associated with at most one instructor via advisor
 Many-to-One Relationships
• 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
 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
 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 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
Alternative Notation for Cardinality Limits

• Cardinality limits can also express participation constraints

– Number on line represents how many times the entity can participate in the relationship

Quiz Q2: The above relationship is

(1) Many to one from instructor to student
(2) One to many from instructor to student
(3) One to one
(4) many to many
 Redundant Attributes
• Suppose we have entity sets
– instructor, with attributes including dept_name
– department
and a relationship
– inst_dept relating instructor and department
• Attribute dept_name in entity instructor is redundant since there is an explicit relationship inst_dept
which relates instructors to departments
– The attribute replicates information present in the relationship, and should be removed from
instructor
– BUT: when converting back to tables, in some cases the attribute gets reintroduced, as we will
see.
 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.
 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
• The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes
among all the entities of a weak entity set.
• The primary key of a weak entity set is formed by the primary key of the strong entity set on
which the weak entity set is existence dependent, plus the weak entity set’s discriminator.
 Weak Entity Sets (Cont.)
• We underline the discriminator of a weak entity set with a dashed line.
• We put the identifying relationship of a weak entity in a double diamond.
• Discriminator of the weak entity set is underlined by dashed lines
• Primary key for section – (course_id, sec_id, semester, year)
 Weak Entity Sets (Cont.)
• Note: the primary key of the strong entity set is not explicitly stored with the weak entity set,
– it is implicit in the identifying relationship.
• If course_id were explicitly stored, section could be made a strong entity
– but then there is an implicit relationship defined by the attribute course_id common to course
and section
– and the implicit relationship duplicates the explicit relationship between section and course
• Example:
– 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.
E-R Diagram for a University Enterprise
 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.

55
Extended E-R Features: Specialization

• Top-down design process; we designate subgroupings within an entity set that are distinctive
from other entities in the set.
• It is a top-down approach in which one higher level entity can be broken down into two lower
level entity.
• 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 ISA (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.
Specialization Example
 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.

Generalization is a bottom-up approach in which two lower level entities combine

to form a higher level entity.

In generalization, the higher level entity can also combine with other lower level
entities to make further higher level entity.

58
Generalization Example

59
 Extended ER Features : Aggregation

• Aggregration is a process when relation • Consider the ternary relationship

between two entities is treated as a single proj_guide, which we saw earlier
entity. ▪ Suppose we want to record
• Eliminate this redundancy via aggregation evaluations of a student by a guide
on a project.
▪Treat relationship as an abstract entity
▪ Relationship sets eval_for and
▪Allows relationships between relationships proj_guide represent overlapping
▪Abstraction of relationship into new entity information
▪Every eval_for relationship
corresponds to a proj_guide
• Without introducing redundancy, relationship
▪A student is guided by a particular instructor on ▪However, some proj_guide
relationships may not correspond to
a particular project any eval_for relationships
▪A student, instructor, project combination may ◦So we can’t discard the proj_guide
have an associated evaluation relationship
60
Aggregation Example

61
 Reduction to Relational 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

62
 Representing Entity Sets With Simple Attributes

• A strong entity set reduces to a schema with the same attributes

student(ID, name, tot_cred)
• A weak entity set becomes a table that includes a column for the primary key of the identifying strong
entity set
section ( course_id, sec_id, sem, year )
 Representing Relationship Sets
• A many-to-many relationship set is represented as a schema with attributes for the primary keys
of the two participating entity sets, and any descriptive attributes of the relationship set.
• Example: schema for relationship set advisor
advisor = (s_id, i_id)
 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
● Example: Instead of creating a schema for relationship set inst_dept, add an attribute dept_name
to the schema arising from entity set instructor
 Redundancy of Schemas (Cont.)
• For one-to-one relationship sets, either side can be chosen to act as the “many” side
– That is, extra attribute can be added to either of the tables corresponding to the two
entity sets
• If participation is partial on the “many” side, replacing a schema by an extra attribute in the
schema corresponding to the “many” side could result in null values
• The schema corresponding to a relationship set linking a weak entity set to its identifying
strong entity set is redundant.
– Example: The section schema already contains the attributes that would appear in the
sec_course schema
Composite and Multivalued 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
– instructor(ID,
first_name, middle_initial, last_name,
street_number, street_name,
apt_number, city, state, zip_code,
date_of_birth)
 Composite and Multivalued 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 and phone numbers 456-
7890 and 123-4567 maps to two tuples:
(22222, 456-7890) and (22222, 123-4567)
69
Extended ER Features Reduction to
Relation Schemas

70
71
72
73