Database Management

Systems
 CS312 Database Management Systems
Course Objectives:
1. Knowledge
(i) Understand the fundamental concepts of database management System
(ii) To provide a strong formal foundation in database concepts, DBMS architectures recent technologies and best industry
practices.
2. Skills
(i) To learn the SQL database system.
(ii) To program PL/SQL including stored procedures, stored functions, cursors and packages.
3. Attitude
(i) To design the database system for real world applications.
(ii) To access, modify, program and authenticate the database system.
Course Outcomes:
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.
7/17/2020 DATABASE MANAGEMENT SYSTEM LABORATORY 2
 CCA & LCA Component

CCA-100M LCA-50M

Theory Assignment-20M Lab Continuous Assessment-20M

Mid term Exam-20M PR+OR-20M

Active Learning-20M Mini Project-10M

End Term Exam-40M

3
 Module 1- Introduction to Database Management Systems and Data Modeling

Syllabus:
• DBMS Vs File Systems, Database System Architecture,
• Database Architectures: Centralized, Client
Server, Parallel, Distributed, Data Abstraction, Data Independence, Data Definition an
d Data Manipulation Languages, Data Models
• ER diagram: Components of ER 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 Eg.-University Database
– Collection of interrelated data
Example
– Set of programs to access the data
– An environment that is both convenient and efficient to • Application program examples
use – Add new students, instructors,
– Databases can be very large. and courses
• Database Applications: – Register students for courses,
– Banking: transactions
and generate class rosters
– Airlines: reservations, schedules
– Assign grades to students,
– Universities: registration, grades
– Sales: customers, products, purchases
compute grade point averages
– Online retailers: order tracking, customized
(GPA) and generate transcripts
recommendations
– 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
• Run on a single computer system and do not
Centralized Systems
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 • Server systems satisfy requests generated at
m client systems, whose general structure is
Systems 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
• 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.

An architecture for a database system

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

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

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

– Indexing and hashing 25

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

Realtionship set 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 relationship
• Without introducing redundancy, ▪However, some proj_guide relationships
▪A student is guided by a particular instructor on may not correspond to any eval_for
a particular project relationships
◦So we can’t discard the proj_guide
▪A student, instructor, project combination may relationship
have an associated evaluation 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