DATABASE SYSTEMS

Database Systems
▪ DBMS contains information about a particular enterprise
• Collection of interrelated data
• Set of programs to access the data
• An environment that is both convenient and efficient to use
▪ Database systems are used to manage collections of data that are:
• Highly valuable
• Relatively large
• Accessed by multiple users and applications, often at the same time.
▪ A modern database system is a complex software system whose task is to manage a
large, complex collection of data.
▪ Databases touch all aspects of our lives.
Database Applications Examples
▪ Enterprise Information
• Sales: customers, products, purchases
• Accounting: payments, receipts, assets
• Human Resources: Information about employees, salaries, payroll taxes.
▪ Manufacturing: management of production, inventory, orders, supply chain.
▪ Banking and finance
• customer information, accounts, loans, and banking transactions.
• Credit card transactions
• Finance: sales and purchases of financial instruments (e.g., stocks and bonds;
storing real-time market data
▪ Universities: registration, grades
▪ Airlines: reservations, schedules
▪ Telecommunication: records of calls, texts, and data usage, generating monthly bills,
maintaining balances on prepaid calling cards
▪ Web-based services
• Online retailers: order tracking, customized recommendations
 • Online advertisements
▪ Document databases
▪ Navigation systems: For maintaining the locations of varies places of interest along
with the exact routes of roads, train systems, buses, etc.
Purpose of Database Systems
In the early days, database applications were built directly on top of file systems, which leads
to:
▪ Data redundancy and inconsistency: data is stored in multiple file formats resulting
induplication 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
▪ Concurrent access by multiple users
• Concurrent access needed for performance
• Uncontrolled concurrent accesses can lead to inconsistencies
▪ Ex: 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
Database systems offer solutions to all the above problems
University Database Example
▪ In this text we will be using a university database to illustrate all the concepts
▪ Data consists of information about:
 • Students
• Instructors
• Classes
▪ Application program examples:
• Add new students, instructors, and courses
• Register students for courses, and generate class rosters
• Assign grades to students, compute grade point averages (GPA) and generate
transcripts
View of Data
▪ A database system is a collection of interrelated data and a set of programs that allow
users to access and modify these data.
▪ A major purpose of a database system is to provide users with an abstract view of the
data.
• Data models
▪ A collection of conceptual tools for describing data, data relationships,
data semantics, and consistency constraints.
• Data abstraction
▪ Hide the complexity of data structures to represent data in the database
from users through several levels of data abstraction.
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)
▪ Semi-structured data model (XML)
▪ Other older models:
• Network model
• Hierarchical model
Relational Model
▪ All the data is stored in various tables.
▪ Example of tabular data in the relational model
A Sample Relational Database

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.
View of Data
An architecture for a database system

Instances and Schemas

▪ Similar to types and variables in programming languages
▪ Logical Schema – the overall logical structure of the database
• Example: The database consists of information about a set of customers and
accounts in a bank and the relationship between them
▪ Analogous to type information of a variable in a program
▪ Physical schema – the overall physical structure of the database
▪ Instance – the actual content of the database at a particular point in time
• Analogous to the value of a variable
Physical 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.
Data Definition Language (DDL)
▪ Specification notation for defining the database schema

Example: create table instructor (

ID char(5),
name varchar(20),
dept_name varchar(20),
salary numeric(8,2))
▪ DDL compiler generates a set of table templates stored in a data dictionary
▪ Data dictionary contains metadata (i.e., data about data)
• Database schema
• Integrity constraints
▪ Primary key (ID uniquely identifies instructors)
• Authorization
▪ Who can access what
Data Manipulation Language (DML)
▪ Language for accessing and updating the data organized by the appropriate data
model
• DML also known as query language
▪ There are basically two types of data-manipulation language
• Procedural DML -- require a user to specify what data are needed and how
to get those data.
• Declarative DML -- require a user to specify what data are needed without
specifying how to get those data.
▪ Declarative DMLs are usually easier to learn and use than are procedural DMLs.
▪ Declarative DMLs are also referred to as non-procedural DMLs
▪ The portion of a DML that involves information retrieval is called a query language.
SQL Query Language
▪ SQL query language is nonprocedural. A query takes as input several tables (possibly
only one) and always returns a single table.
▪ Example to find all instructors in Comp. Sci. dept
select name
from instructor
where dept_name = 'Comp. Sci.'
 ▪ SQL is NOT a Turing machine equivalent language
▪ To be able to compute complex functions SQL is usually embedded in some higher-
level language
▪ Application programs generally access databases through one of
• Language extensions to allow embedded SQL
• Application program interface (e.g., ODBC/JDBC) which allow SQL queries
to be sent to a database

Database Access from Application Program

▪ Non-procedural query languages such as SQL are not as powerful as a universal
Turing machine.
▪ SQL does not support actions such as input from users, output to displays, or
communication over the network.
▪ Such computations and actions must be written in a host language, such as C/C++,
Java or Python, with embedded SQL queries that access the data in the database.
▪ Application programs -- are programs that are used to interact with the database in
this fashion.
Database Design
▪ Logical Design – Deciding on the database schema. Database design requires that we
find a “good” collection of relation schemas.
• Business decision – What attributes should we record in the database?
• Computer Science decision – What relation schemas should we have and how
should the attributes be distributed among the various relation schemas?
▪ Physical Design – Deciding on the physical layout of the database
Database Engine
A database system is partitioned into modules that deal with each of the responsibilities of the
overall system.
▪ The functional components of a database system can be divided into
• The storage manager,
• The query processor component,
• The transaction management component.
Storage Manager
▪ A program module that provides the interface between the low-level data stored in the
database and the application programs and queries submitted to the system.
 ▪ The storage manager is responsible to the following tasks:
• Interaction with the OS file manager
• Efficient storing, retrieving and updating of data
▪ The storage manager components include:
• Authorization and integrity manager
• Transaction manager
• File manager
• Buffer manager
▪ The storage manager implements several data structures as part of the physical system
implementation:
• Data files -- store the database itself
• Data dictionary -- stores metadata about the structure of the database, in
particular the schema of the database.
• Indices -- can provide fast access to data items. A database index provides
pointers to those data items that hold a particular value.

▪ Query Processor

The query processor components include:

• DDL interpreter -- interprets DDL statements and records the definitions in
the data dictionary.
• DML compiler -- translates DML statements in a query language into an
evaluation plan consisting of low-level instructions that the query evaluation
engine understands.
▪ The DML compiler performs query optimization; that is, it picks the
lowest cost evaluation plan from among the various alternatives.
• Query evaluation engine -- executes low-level instructions generated by the
DML compiler.

Query Processing

1. Parsing and translation

2. Optimization
3. Evaluation
Transaction Management

▪ A transaction is a collection of operations that performs a single logical function in a

database application
▪ 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.
Database Architecture

▪ Centralized databases
• One to a few cores, shared memory
▪ Client-server,
• One server machine executes work on behalf of multiple client machines.
▪ Parallel databases
• Many core shared memory
• Shared disk
• Shared nothing
▪ Distributed databases
• Geographical distribution
• Schema/data heterogeneity
Database Architecture (Centralized/Shared-Memory)

Database Applications
Database applications are usually partitioned into two or three parts

▪ Two-tier architecture -- the application resides at the client machine, where it invokes
database system functionality at the server machine
▪ Three-tier architecture -- the client machine acts as a front end and does not contain
any direct database calls.
• The client end communicates with an application server, usually through a
forms interface.
• The application server in turn communicates with a database system to access
data.
Two-tier and three-tier architectures
Database Users

Database Administrator
A person who has central control over the system is called a database administrator (DBA).
Functions of a DBA include:

▪ Schema definition
▪ Storage structure and access-method definition
▪ Schema and physical-organization modification
▪ Granting of authorization for data access
▪ Routine maintenance
▪ Periodically backing up the database
 ▪ Ensuring that enough free disk space is available for normal operations, and
upgrading disk space as required
▪ Monitoring jobs running on the database
History of Database Systems
▪ 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 (Michael Stonebraker) begins Ingres prototype
▪ Oracle releases first commercial relational database
• High-performance (for the era) transaction processing
▪ 1980s:
• Research relational prototypes evolve into commercial systems
▪ SQL becomes industrial standard
• Parallel and distributed database systems
▪ Wisconsin, IBM, Teradata
• Object-oriented database systems
▪ 1990s:
• Large decision support and data-mining applications
• Large multi-terabyte data warehouses
• Emergence of Web commerce
▪ 2000s
• Big data storage systems
▪ Google BigTable, Yahoo PNuts, Amazon,
▪ “NoSQL” systems.
 • Big data analysis: beyond SQL
▪ Map reduce and friends
▪ 2010s
• SQL reloaded
▪ SQL front end to Map Reduce systems
▪ Massively parallel database systems
▪ Multi-core main-memory databases
Domain Types in SQL
▪ char(n). Fixed length character string, with user-specified length n.
▪ varchar(n). Variable length character strings, with user-specified maximum length
n.
▪ int. Integer (a finite subset of the integers that is machine-dependent).
▪ smallint. Small integer (a machine-dependent subset of the integer domain type).
▪ numeric(p,d). Fixed point number, with user-specified precision of p digits, with d
digits to the right of decimal point. (ex., numeric(3,1), allows 44.5 to be stores
exactly, but not 444.5 or 0.32)
▪ real, double precision. Floating point and double-precision floating point numbers,
with machine-dependent precision.
▪ float(n). Floating point number, with user-specified precision of at least n digits.

Create Table Construct

▪ An SQL relation is defined using the create table command:
create table r
(A1 D1, A2 D2, ..., An Dn,
(integrity-constraint1),
...,
(integrity-constraintk))
• r is the name of the relation
• each Ai is an attribute name in the schema of relation r
• Di is the data type of values in the domain of attribute Ai
▪ Example:
create table instructor (
ID char(5),
 name varchar(20),
dept_name varchar(20),
salary numeric(8,2))

Integrity Constraints in Create Table

▪ Types of integrity constraints
• primary key (A1, ..., An )
• foreign key (Am, ..., An ) references r
• not null
▪ SQL prevents any update to the database that violates an integrity constraint.
▪ Example:
create table instructor (
ID char(5),
name varchar(20) not null,
dept_name varchar(20),
salary numeric(8,2),
primary key (ID),
foreign key (dept_name) references department);

And a Few More Relation Definitions

▪ create table student (
ID varchar(5),
name varchar(20) not null,
dept_name varchar(20),
tot_cred numeric(3,0),
primary key (ID),
foreign key (dept_name) references department);
▪ create table takes (
ID varchar(5),
course_id varchar(8),
sec_id varchar(8),
semester varchar(6),
year numeric(4,0),
grade varchar(2),
primary key (ID, course_id, sec_id, semester, year) ,
foreign key (ID) references student,
foreign key (course_id, sec_id, semester, year) references section);
Updates to tables
▪ Insert
• insert into instructor values ('10211', 'Smith', 'Biology', 66000);
▪ Delete
• Remove all tuples from the student relation
▪ delete from student
▪ Drop Table
• drop table r
▪ Alter
• alter table r add A D
▪ where A is the name of the attribute to be added to relation r and D is
the domain of A.
▪ All exiting tuples in the relation are assigned null as the value for the
new attribute.
• alter table r drop A
▪ where A is the name of an attribute of relation r
▪ Dropping of attributes not supported by many databases.
The select Clause
▪ The select clause lists the attributes desired in the result of a query
• corresponds to the projection operation of the relational algebra
▪ Example: find the names of all instructors:
select name
from instructor
▪ NOTE: SQL names are case insensitive (i.e., you may use upper- or lower-case
letters.)
• E.g., Name ≡ NAME ≡ name
• Some people use upper case wherever we use bold font.
▪ SQL allows duplicates in relations as well as in query results.
▪ To force the elimination of duplicates, insert the keyword distinct after select.
▪ Find the department names of all instructors, and remove duplicates
 select distinct dept_name
from instructor
▪ The keyword all specifies that duplicates should not be removed.

select all dept_name

from instructor

The where Clause

▪ The where clause specifies conditions that the result must satisfy
• Corresponds to the selection predicate of the relational algebra.
▪ To find all instructors in Comp. Sci. dept
select name
from instructor
where dept_name = 'Comp. Sci.'
▪ SQL allows the use of the logical connectives and, or, and not
▪ The operands of the logical connectives can be expressions involving the comparison
operators <, <=, >, >=, =, and <>.
▪ Comparisons can be applied to results of arithmetic expressions
▪ To find all instructors in Comp. Sci. dept with salary > 70000
select name
from instructor
where dept_name = 'Comp. Sci.' and salary > 70000

The from Clause

▪ The from clause lists the relations involved in the query
• Corresponds to the Cartesian product operation of the relational algebra.
▪ Find the Cartesian product instructor X teaches
select * from instructor, teaches
• generates every possible instructor – teaches pair, with all attributes from both
relations.
 • For common attributes (e.g., ID), the attributes in the resulting table are
renamed using the relation name (e.g., instructor.ID)
▪ Cartesian product not very useful directly, but useful combined with where-clause
condition (selection operation in relational algebra).

▪ Find the names of all instructors who have taught some course and the course_id
• select name, course_id
from instructor , teaches
where instructor.ID = teaches.ID

▪ Find the names of all instructors in the Art department who have taught some course
and the course_id
• select name, course_id
from instructor , teaches
where instructor.ID = teaches.ID
and instructor. dept_name = 'Art'

Aggregate Functions
▪ These functions operate on the multiset of values of a column of a relation, and return
a value
avg: average value
min: minimum value
max: maximum value
sum: sum of values
count: number of values
▪ Find the average salary of instructors in the Computer Science department
• select avg (salary)
from instructor
where dept_name= 'Comp. Sci.';
▪ Find the total number of instructors who teach a course in the Spring 2018 semester
• select count (distinct ID)
from teaches
where semester = 'Spring' and year = 2018;
▪ Find the number of tuples in the course relation
• select count (*)
from course;

▪ Find the average salary of instructors in each department

• select dept_name, avg (salary) as avg_salary
from instructor
group by dept_name;
Set Comparison – “some” Clause
▪ Find names of instructors with salary greater than that of some (at least one) instructor
in the Biology department.
▪ Same query using > some clause

select name
from instructor
where salary > some (select salary
from instructor
where dept name = 'Biology');
 ▪ F <comp> some r ⇔ ∃ t ∈ r such that (F <comp> t )
Where <comp> can be: <, ≤, >, =, ≠
▪ Yet another way of specifying the query “Find all courses taught in both the Fall 2017
semester and in the Spring 2018 semester”
select course_id
from section as S
where semester = 'Fall' and year = 2017 and
exists (select *
from section as T
where semester = 'Spring' and year= 2018
and S.course_id = T.course_id);

▪ Correlation name – variable S in the outer query

▪ Correlated subquery – the inner query
Subqueries in the Form Clause
▪ SQL allows a subquery expression to be used in the from clause
▪ Find the average instructors’ salaries of those departments where the average salary is
greater than $42,000.”
select dept_name, avg_salary
from ( select dept_name, avg (salary) as avg_salary
from instructor
group by dept_name)
where avg_salary > 42000;
▪ Note that we do not need to use the having clause
▪ Another way to write above query
select dept_name, avg_salary
from ( select dept_name, avg (salary)
from instructor
group by dept_name)
as dept_avg (dept_name, avg_salary)
where avg_salary > 42000;

Complex Queries using With Clause

with dept _total (dept_name, value) as
(select dept_name, sum(salary)
from instructor
 group by dept_name),
dept_total_avg(value) as
(select avg(value)
from dept_total)
select dept_name
from dept_total, dept_total_avg
where dept_total.value > dept_total_avg.value;

Entity Sets
▪ An entity is an object that exists and is distinguishable from other objects.
• Example: specific person, company, event, plant
▪ 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
▪ An entity is represented by a set of attributes; i.e., descriptive properties possessed by
all members of an entity set.
• Example:
instructor = (ID, name, salary )
course= (course_id, title, credits)
▪ A subset of the attributes form a primary key of the entity set; i.e., uniquely
identifying each member of the set.

Representing Entity sets in ER Diagram

▪ Entity sets can be represented graphically as follows:
 • Rectangles represent entity sets.
• Attributes listed inside entity rectangle
• Underline indicates primary key attributes

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
Representing Relationship Sets via ER Diagrams

▪ An attribute can also be associated with 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

Relationship Sets with Attributes

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

Non-binary Relationship Sets

▪ Most relationship sets are binary
▪ There are occasions when it is more convenient to represent relationships as non-
binary.
▪ E-R Diagram with a Ternary Relationship

Representing Complex Attributes in ER Diagram

Mapping Cardinalities

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,
Notation for Expressing More Complex Constraints
▪ A line may have an associated minimum and maximum cardinality, shown in the form
l..h, where l is the minimum and h the maximum cardinality
• A minimum value of 1 indicates total participation.
• A maximum value of 1 indicates that the entity participates in at most one
relationship
• A maximum value of * indicates no limit.
▪ Example
• Instructor can advise 0 or more students. A student must have 1 advisor;
cannot have multiple advisors

Cardinality Constraints on Ternary Relationship

▪ We allow at most one arrow out of a ternary (or greater degree) relationship to
indicate a cardinality constraint
▪ For example, an arrow from proj_guide to instructor indicates each student has at
most one guide for a project
▪ If there is more than one arrow, there are two ways of defining the meaning.
• For example, a ternary relationship R between A, B and C with arrows to B
and C could mean
1. Each A entity is associated with a unique entity from B
and C or
2. Each pair of entities from (A, B) is associated with a unique C entity, and
each pair (A, C) is associated with a unique B
• Each alternative has been used in different formalisms
• To avoid confusion we outlaw more than one arrow
Primary key for Entity Sets
▪ By definition, individual entities are distinct.
▪ From database perspective, the differences among them must be expressed in terms of
their attributes.
 ▪ The values of the attribute values of an entity must be such that they can uniquely
identify the entity.
• No two entities in an entity set are allowed to have exactly the same value for
all attributes.
▪ A key for an entity is a set of attributes that suffice to distinguish entities from each
other
Expressing Weak Entity Sets
▪ In E-R diagrams, a weak entity set is depicted via a double rectangle.
▪ We underline the discriminator of a weak entity set with a dashed line.
▪ The relationship set connecting the weak entity set to the identifying strong entity set
is depicted by a double diamond.
▪ Primary key for section – (course_id, sec_id, semester, year)

Redundant Attributes

▪ Suppose we have entity sets:

• student, with attributes: ID, name, tot_cred, dept_name
• department, with attributes: dept_name, building, budget
▪ We model the fact that each student has an associated department using a relationship
set stud_dept
▪ The attribute dept_name in student below replicates information present in the
relationship and is therefore redundant
• and needs to be removed.
▪ BUT: when converting back to tables, in some cases the attribute gets reintroduced, as
we will see later.
E-R Diagram for a University Enterprise

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

Representation of Entity Sets with Composite 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 (name_first_name could be
first_name)
▪ 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)
Representation of Entity Sets with 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)

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
▪ Example
Specialization

▪ Top-down design process; we designate sub-groupings within an entity set that are
distinctive from other entities in the set.
▪ These sub-groupings 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.

CONCLUSION:
In conclusion, databases play a critical role in the efficient storage, management, and retrieval
of data across various domains. By enabling structured data organization, ensuring data
integrity, and supporting concurrent access, databases serve as the backbone of modern
information systems. With the evolution of technology, database systems have become more
robust, scalable, and adaptable, meeting the growing demands of big data, real-time
processing, and cloud integration. A solid understanding of database concepts and
architecture is essential for designing efficient systems that can support informed decision-
making and ensure long-term data sustainability.