Professional Documents
Culture Documents
Boris Glavic
Course Information!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
0.2!
I am a database guy!
0.3!
I am a database guy!
0.4!
0.5!
Banks!
Insurance!
Government!
Google, !
0.6!
business!
IBM DB2!
Oracle Oracle !
Microsoft SQLServer!
0.7!
Low-level
optimization!
cache-conscious algorithms!
Exploit modern hardware!
of query answering!
Expressiveness
Concurrency
of query languages!
theory!
0.8!
Distributed systems!
Getting
Compilers!
Modeling!
mining!
Hardware!
Hardware-software
co-design!
0.9!
Google Group:
https://groups.google.com/d/forum/cs425-2013-fall-group!
Used
Use
for announcements!
Syllabus: http://cs.iit.edu/~cs425/les/syllabus.pdf!
Faculty!
Email: bglavic@iit.edu!
Phone: 312.567.5205!
0.10!
TAs!
Tas!
Maria Ramirez!
Email: mramire8@hawk.iit.edu!
0.11!
Midterm (25%)!
Final (35%)!
HW2 (SQL)!
Course Project!
In groups of 3 students!
a database model!
Implement
0.12!
Course Objectives!
Understand the underlying ideas of database systems !
Understand the relational data model !
Be able to write and understand SQL queries and data denition
statements !
Understand relational algebra and its connection to SQL !
Understand how to write programs that access a database server !
Understand the ER model used in database design !
Understand normalization of database schemata !
Be able to create a database design from a requirement analysis for
a specic domain !
Know basic index structures and understand their importance !
Have a basic understanding of relational database concepts such as
0.13!
Course Project!
Forming groups!
Your responsibility!!
Inform me + TA!
Timeline:!
0.14!
Late policy:!
No exceptions!!
Course projects:!
me or TA immediatly!
0.15!
McGraw Hill
publication date:2006,
ISBN 0-13-0-13-142938-8.
Prerequisites:!
0.16!
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
0.17!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Textbook: Chapter 1!
1.2!
Database Applications:!
Banking: transactions!
1.3!
le systems!
1.4!
Integrity problems!
Integrity
Hard
1.5!
Atomicity of updates!
Security problems!
1.6!
Levels of Abstraction!
Physical level: describes how a record (e.g., customer) is stored.!
Logical level: describes data stored in database, and the relationships
!ID : string;
!name : string;
!dept_name : string;
!salary : integer;!
end;!
View level: application programs hide details of data types. Views can
1.7!
View of Data!
An architecture for a database system !
view level
view 1
view 2
view n
logical
level
physical
level
CS425 Fall 2013 Boris Glavic!
1.8!
Physical Data Independence the ability to modify the physical schema without
In general, the interfaces between the various levels and components should be
well dened so that changes in some parts do not seriously inuence others.!
1.9!
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!
Other newer (or revived) models:!
Key-value!
1.10!
Relational Model!
Relational model (Chapter 2)!
Example of tabular data in the relational model!
Columns (attributes)!
Rows (tuples)!
1.11!
1.12!
1.13!
Example:
data dictionary"
Database schema !
Integrity constraints!
Authorization!
1.14!
SQL!
SQL: widely used declarative (non-procedural) language!
1.15!
Database Design!
The process of designing the general structure of a database:!
!
Logical Design Deciding on the database schema. Database design
!
Physical Design Deciding on the physical layout of the database
!
!
1.16!
Database Design?!
Is there any problem with this design?!
1.17!
Database Design?!
Example: Changing the budget of the Physics department!
1.18!
Design Approaches!
Normalization Theory (Chapter 8)!
Relationship:
1.19!
by a set of attributes!
instructor
ID
name
salary
department
member
dept_name
building
budget
1.20!
E.g., integer!
Allow attributes of tuples to have complex types, including nonatomic values such as nested relations.!
1.21!
database language!
The ability to specify new tags, and to create nested tag structures
formats.!
A wide variety of tools is available for parsing, browsing and
1.22!
Storage Management!
Storage manager is a program module that provides the interface
between the low-level data stored in the database (on disk) and the
application programs and queries submitted to the system.!
The storage manager is responsible to the following tasks: !
Issues:!
Storage access!
File organization!
1.23!
Query Processing!
1. !Parsing and translation!
2. !Optimization!
3. !Evaluation!
query
relational-algebra
expression
parser and
translator
optimizer
query
output
evaluation engine
statistics
about data
data
CS425 Fall 2013 Boris Glavic!
execution plan
1.24!
Equivalent expressions!
Cost difference between a good and a bad way of evaluating a query can
be enormous!
Need to estimate the cost of operations!
1.25!
Transaction Management
1.26!
Database!
1.27!
sophisticated
users
(analysts)
application
programmers
use
write
application
interfaces
use
application
programs
query
tools
compiler and
linker
DML queries
application
program
object code
use
administration
tools
DDL interpreter
DML compiler
and organizer
query evaluation
engine
buffer manager
database
administrators
query processor
authorization
and integrity
manager
file manager
transaction
manager
storage manager
disk storage
indices
data
data dictionary
statistical data
1.28!
Database Architecture!
The architecture of a database systems is greatly inuenced by!
the underlying computer system on which the database is running:!
Centralized!
Client-server!
Parallel (multi-processor)!
Distributed
1.29!
1.30!
1.31!
History (cont.)!
1980s:!
Recap!
Why databases?!
What do databases do?!
Data independence!
1.33!
End of Chapter 1!
1.34!
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
1.35!
Figure 1.02!
1.36!
Figure 1.04!
1.37!
Figure 1.06!
user
user
client
application
application client
network
network
application server
database system
server
database system
1.38!
Modies from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Textbook: Chapter 2!
2.2!
Example of a Relation!
attributes!
(or columns)!
tuples!
(or rows)!
2.3!
Attribute Types!
The set of allowed values for each attribute is called the domain
indivisible!
operations!
2.4!
y
r
o
The rning
Wa
!
R = (A1, A2, , An ) is a relation schema!
!Example:!
!
instance) is a subset of
D 1 x D 2 x x D n
Thus, a relation is a set of n-tuples (a1, a2, , an) where each ai Di!
! The current values (relation instance) of a relation are often
specied in tabular form!
!
Caveat: being a set, the tuples of the relation do not have any
!
order dened as implied by the tabular representation!
An element t of r is a tuple, represented as a row in a table!
2.5!
Alternative Denitions!
A relation schema is often dened as a list of attribute-domain pairs!
y
r
o
The rning
Wa
CS425 Fall 2013 Boris Glavic!
2.6!
order)!
Example: instructor relation with unordered tuples!
2.7!
Database!
A database schema S consists of multiple relation schema!
A database instance I for a schema S is a set of relation instances!
instructor
student
advisor!
Bad design:
the need for many null values (e.g., represent an student with no
advisor)!
2.8!
to break integrity!
If
2.9!
Keys!
Let K R!
K is a superkey of R if values for K are sufcient to identify a unique
superkey)
Example: {ID} is a candidate key for Instructor!
One of the candidate keys is selected to be the primary key.!
Referencing relation!
Referenced relation!
2.10!
Keys!
Formally, a set of attributes K R is a superkey if for every instance r of
R holds that!
t, t r: t.K = t.K t = t!
K K: K is not a superkey!
y
r
o
e
h
T rning
Wa
CS425 Fall 2013 Boris Glavic!
2.11!
takes
section
course_id
sec_id
semester
year
building
room_no
time_slot_id
time_slot
course
course_id
title
dept_name
credits
department
dept_name
building
budget
advisor
s_id
i_id
time_slot_id
day
start_time
end_time
classroom
building
room_no
capacity
ID
name
dept_name
tot_cred
ID
course_id
sec_id
semester
year
grade
prereq
instructor
course_id
ID
name
dept_name
salary
prereq_id
teaches
ID
course_id
sec_id
semester
year
2.12!
Pure languages:!
Relational algebra!
Relational algebra:!
2.13!
Selection of tuples!
Relation r!
and D > 5!
(r)!
2.14!
Select A and C!
Projection!
A, C
(r) !
2.15!
r x s:!
2.16!
r s:!
2.17!
r s:!
2.18!
!
!
r s!
2.19!
2.20!
Natural Join!
r
s!
2.21!
Figure in-2.1!
2.22!
End of Chapter 2!
Modies from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Recap!
Database Schema (or short schema)!
Declarative!
2.24!
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
2.25!
Figure 2.01!
2.26!
Figure 2.02!
2.27!
Figure 2.03!
2.28!
Figure 2.04!
2.29!
Figure 2.05!
2.30!
Figure 2.06!
2.31!
Figure 2.07!
2.32!
Figure 2.10!
2.33!
Figure 2.11!
2.34!
Figure 2.12!
2.35!
Figure 2.13!
2.36!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Textbook: Chapter 6!
3.2!
Relational Algebra!
Procedural language!
Six basic operators!
select: !
project: !
union: !
set difference: !
Cartesian product: x!
rename: !
The operators take one or two relations as inputs and produce a new
relation as a result.!
composable!
3.3!
3.4!
Select Operation!
Notation: p(r)!
p is called the selection predicate!
Dened as:
!!
p (r)
= {t | t r p(t)}
!
Where p is a formula in propositional calculus consisting of terms
connected by : (and), (or), (not)
Each term is one of:!
!
!<attribute>
! dept_name=
Physics
(instructor)!
3.5!
y
r
o
e
h
T rning
Wa
Silberschatz, Korth and Sudarshan!
!A,C
(r)
3.6!
Project Operation!
Notation:
A1 ,!!A2 ,, Ak
(r )
A (r) = {t.A | t r}
Example: To eliminate the dept_name attribute of instructor
3.7!
y
r
o
e
h
T rning
Wa
Silberschatz, Korth and Sudarshan!
r s:!
3.8!
Union Operation!
Notation: r s!
Dened as: !
r s = {t | t r t s}
For r s to be valid.!
year=2009 (section))
3.9!
year=2010 (section))!
Silberschatz, Korth and Sudarshan!
r s:!
3.10!
r s = {t | t 2 r ^ t 62 s}
!
!
3.11!
r x s:!
3.12!
Cartesian-Product Operation!
Notation r x s!
Dened as:!
!!
!
r s = {t, t | t r t s}
3.13!
Composition of Operations!
Can build expressions using multiple operations!
Example: A=C(r x s)!
!
r x s!
A=C(r x s)!
3.14!
Rename Operation!
Allows us to name, and therefore to refer to, the results of relational-
algebra expressions.!
Allows us to refer to a relation by more than one name.!
Example:!
! x (r)!
!returns the result of expression E under the name X, and with the!
!attributes renamed to A1 , A2 , ., An .!
X (r) = {t(X) | t r}
X(A) (r) = {t(X).A | t r}
CS425 Fall 2013 Boris Glavic!
3.15!
Example Query!
Find the largest salary in the university!
instructor.salary (instructor.salary<d.salary
(instructor d (instructor)))
salary (instructor)
instructor.salary (instructor.salary<d.salary
(instructor d (instructor)))
3.16!
Example Queries!
Find the names of all instructors in the Physics department, along with the
Query 1
!
instructor.ID,course
id (dept name=0 P hysics0 (
Query 2!
!
instructor.ID,course
id (instructor.ID=teaches.ID (
3.17!
following:!
relational-algebra expressions:!
E1 E2!
E1 E2!
E1 x E2!
3.18!
y
r
o
The rning
Wa
Silberschatz, Korth and Sudarshan!
y
r
o
The rning
Wa
CS425 Fall 2013 Boris Glavic!
3.19!
3.20!
y
r
o
The rning
Wa
Null Values!
It is possible for tuples to have a null value, denoted by null, for some
of their attributes!
null signies an unknown value or that a value does not exist.!
The result of any arithmetic expression involving null is null.!
Aggregate functions simply ignore null values (as in SQL)!
For duplicate elimination and grouping, null is treated like any other
value, and two nulls are assumed to be the same (as in SQL)!
3.21!
Null Values!
Comparisons with null values return the special truth value: unknown!
not (A < 5)
A >= 5!
3.22!
Additional Operations!
We dene additional operations that do not add any expressive power to
the relational algebra, but that simplify common queries.!
Set intersection!
Natural join!
Assignment!
Outer join !
3.23!
Set-Intersection Operation!
Notation: r s!
Dened as:!
r s = {t | t r t s}
Assume: !
Note: r s = r (r s)!
3.24!
!
!
r s!
3.25!
Natural-Join Operation!
Notation: r
s!
Then, r
Example:!
R = (A, B, C, D)!
S = (E, B, D)!
s is dened as:
r.A, r.B, r.C, r.D, s.E (r.B = s.B r.D = s.D (r x s))!
3.26!
Then, r
s is dened as:!
X =RS
0
S =SR
r ./ s = R,S 0 (r.X=s.X (r s))
3.27!
s!
3.28!
the course titles of all the courses that the instructors teach!
teaches
(instructor
instructor
teaches)
(teaches
course
course)!
is equivalent to
instruct
teaches
teaches
is equivalent to
instructor!
s is dened as!
r ./ s = (r s)
CS425 Fall 2013 Boris Glavic!
3.29!
Assignment Operation!
The assignment operation () provides a convenient way to
series of assignments !
followed
E1 salary>40000 (instructor)
E2 salary<10000 (instructor)
E3 E1 E2
CS425 Fall 2013 Boris Glavic!
3.30!
Outer Join!
An extension of the join operation that avoids loss of information.!
Computes the join and then adds tuples form one relation that does not
3.31!
name!
ID!
Srinivasan!
Wu!
Mozart!
10101!
12121!
15151!
dept_name!
Comp. Sci.!
Finance!
Music!
Relation teaches1!
ID!
10101!
12121!
76766!
course_id!
CS-101!
FIN-201!
BIO-101!
3.32!
instructor
teaches!
ID!
10101!
12121!
name!
Srinivasan!
Wu!
dept_name! course_id!
Comp. Sci.! CS-101!
Finance!
FIN-201!
instructor
ID!
10101!
12121!
15151!
teaches!
name!
Srinivasan!
Wu!
Mozart!
dept_name! course_id!
Comp. Sci.!
Finance!
Music!
3.33!
CS-101!
FIN-201!
null!
instructor
teaches!
name!
ID!
Srinivasan!
Wu!
null!
10101!
12121!
76766!
dept_name!
course_id!
Comp. Sci.!
Finance!
null!
CS-101!
FIN-201!
BIO-101!
instructor
teaches!
ID!
10101!
12121!
15151!
76766!
name!
Srinivasan!
Wu!
Mozart!
null!
dept_name!
course_id!
Comp. Sci.!
Finance!
Music!
null!
CS-101!
FIN-201!
null!
BIO-101!
3.34!
3.35!
Division Operator!
Given relations r(R) and s(S), such that S R, r s is the largest
Alternatively, all tuples from r.(R-S) such that all their extensions on
R S with tuples from s exist in R!
!!
E1 RS (r)
E2 RS ((E1 s) RS,S (r ./ s))
r s = E1 E 2
CS425 Fall 2013 Boris Glavic!
3.36!
newspaper!
reads!
newspaper!
name!
Peter!
Bob!
Alice!
Alice!
newspaper!
Times!
Wall Street!
Times!
Wall Street!
Times!
Wall Street!
E1 name (reads)
E2 ((E1 newspaper) name,newspaper (reads ./ newspaper))
reads newspaper = E1 E2
[reads newspaper] = {(Alice)}
3.37!
Extended Relational-Algebra-Operations!
Generalized Projection!
Aggregate Functions!
3.38!
Generalized Projection!
Extends the projection operation by allowing arithmetic functions to be
F1 ,...,F
(E)
n
!!
annual salary, get the same information but with monthly salary !
!ID, name, dept_name, salary/12 (instructor)!
3.39!
as a result.!
!avg: average value
!min: minimum value
!max: maximum value
!sum: sum of values
!count: number of values!
!!
!
E is any relational-algebra expression!
instead of
3.40!
(Calligraphic G)!
sum(c) (r)
A!
B! C!
7!
7!
3!
! 10!
sum(c )!
27!
3.41!
avg(salary) (instructor)!
avg_salary!
3.42!
3.43!
operations:!
Deletion!
Insertion!
Updating!
operator!
Example: Delete instructors with salary over $1,000,000!
R R (salary>1000000 (R))
3.44!
R C>5 (S)
This would change the schema of R!!
3.45!
3.46!
!{t | P (t ) }!
3.47!
!x y x v y!
5. !Set of quantiers:!
3.48!
Example Queries!
Find the ID, name, dept_name, salary for instructors whose salary is
!
{t | s instructor (t [ID ] = s [ID ] s [salary ] > 80000)}!
!
Notice that a relation on schema (ID) is implicitly dened by
3.49!
Example Queries!
Find the names of all instructors whose department is in the Watson
building!
{t | s instructor (t [name ] = s [name ]
u department (u [dept_name ] = s[dept_name]
u [building] = Watson ))}!
Find the set of all courses taught in the Fall 2009 semester, or in
3.50!
Example Queries!
Find the set of all courses taught in the Fall 2009 semester, and in
Find the set of all courses taught in the Fall 2009 semester, but not in
3.51!
Safety of Expressions!
It is possible to write tuple calculus expressions that generate innite
relations.!
For example, { t | t r } results in an innite relation if the domain of
E.g.
3.52!
Universal Quantication!
Find all students who have taken all courses offered in the
Biology department!
3.53!
3.54!
relational calculus!
Each query is an expression of the form:!
!
!
!
<Einstein,Physics>!
3.55!
Example Queries!
Find the ID, name, dept_name, salary for instructors whose salary is
!
!
!
building!
{< n > | i, d, s (< i, n, d, s > instructor
b, a (< d, b, a> department b = Watson ))}!
3.56!
Example Queries!
Find the set of all courses taught in the Fall 2009 semester, or in
3.57!
Safety of Expressions!
The expression:!
! !
!
true if and only if P1(x ) is true for all values x from dom (P1).!
3.58!
Universal Quantication!
Find all students who have taken all courses offered in the Biology
department!
3.59!
That means that every query expressible in relational algebra can also
3.60!
Recap!
Relational algebra!
Null values!
joins, division,!
Extensions:!
Aggregation,
extended projection !
Tuple Calculus!
safety!
Domain Calculus!
3.61!
End of Chapter 3!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL - Introduction!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
3.63!
Figure 6.01!
3.64!
Figure 6.02!
3.65!
Figure 6.03!
3.66!
Figure 6.04!
3.67!
Figure 6.05!
3.68!
Figure 6.06!
3.69!
Figure 6.07!
3.70!
Figure 6.08!
3.71!
Figure 6.09!
3.72!
Figure 6.10!
3.73!
Figure 6.11!
3.74!
Figure 6.12!
3.75!
Figure 6.13!
3.76!
Figure 6.14!
3.77!
Figure 6.15!
3.78!
Figure 6.16!
3.79!
Figure 6.17!
3.80!
Figure 6.18!
3.81!
Figure 6.19!
3.82!
Figure 6.20!
3.83!
Figure 6.21!
3.84!
Deletion!
A delete request is expressed similarly to a query, except
particular attributes!
A deletion is expressed in relational algebra by:!
!r r E!
3.85!
Deletion Examples!
Delete all account records in the Perryridge branch.!
depositor)!
3.86!
Insertion!
To insert data into a relation, we either:!
!r r E!
3.87!
Insertion Examples!
Insert information in the database specifying that Smith has $1200 in
r1 (branch_name =
Perryridge
(borrower
loan))!
3.88!
Updating!
A mechanism to change a value in a tuple without charging all values in
the tuple!
Use the generalized projection operator to do this task!
r F ,F ,,F!!, (r )
1
Each Fi is either !
3.89!
Update Examples!
Make interest payments by increasing all balances by 5 percent.!
3.90!
Example Queries!
Find the names of all customers who have a loan and an account at
bank.!
loan amount!
3.91!
loan)!
Example Queries!
Find all customers who have an account from at least the
Downtown
customer_name (branch_name =
(depositor
Uptown
account )) !
(depositor
account))!
Query 2!
account)
! customer_name, branch_name (depositor
!
temp(branch_name) ({( Downtown ), ( Uptown )})!
3.92!
Brooklyn city.!
! branch_name (branch_city =
3.93!
Brooklyn
account)
(branch))!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Textbook: Chapter 3!
CS425 Fall 2013 Boris Glavic!
4.2!
History!
IBM Sequel language developed as part of System R project at
the IBM San Jose Research Laboratory!
Renamed Structured Query Language (SQL)!
ANSI and ISO standard SQL:!
4.3!
4.4!
4.5!
!
!
!
!
!
!
!(integrity-constraint1),
!...,
!(integrity-constraintk))!
4.6!
4.7!
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 );!
4.8!
Even more!
create table course (
course_id
varchar(8) primary key,
title
varchar(50),
dept_name
varchar(20),
credits
numeric(2,0),
foreign key (dept_name) references department) );!
4.9!
All
Dropping
And more !
4.10!
4.11!
!
!
!select name
!from instructor!
NOTE: SQL keywords are case insensitive (i.e., you may use upper- or
lower-case letters.) !
4.12!
4.13!
!select *
!from instructor!
substring!
The query: !
!
4.14!
! !
4.15!
!select name
!from instructor
!where dept_name = Comp. Sci.' and salary > 80000!
Comparison results can be combined using the logical
connectives and, or, and not. !
Comparisons can be applied to results of arithmetic expressions.!
SQL standard: any valid expression that returns a boolean result!
4.16!
teaches!
4.17!
Joins!
For all instructors who have taught some course, nd their names
and the course ID of the courses they taught.!
!
section
course
course_id
sec_id
semester
year
building
room_no
time_slot_id
course_id
title
dept_name
credits
time_slot
time_slot_id
day
start_time
4.18!
4.19!
Joined Relations!
Join operations take two relations and return as a result
another relation.!
A join operation is a Cartesian product which requires that
4.20!
Relation prereq!
Observe that !
prereq information is missing for CS-315 and !
course information is missing for CS-437!
CS425 Fall 2013 Boris Glavic!
4.21!
Natural Join!
Natural join matches tuples with the same values for all
select *
4.22!
they taught.!
!
4.23!
name, title
from instructor natural join teaches natural join course;!
Correct version!
select
name, title
from instructor natural join teaches, course
where teaches.course_id = course.course_id;!
name, title
from (instructor natural join teaches)
join course using(course_id);!
4.24!
Outer Join!
An extension of the join operation that avoids loss of
information.!
Computes the join and then adds tuples form one relation
that does not match tuples in the other relation to the result
of the join. !
Uses null values.!
4.25!
4.26!
4.27!
Joined Relations!
Join operations take two relations and return as a result
another relation.!
These additional operations are typically used as subquery
expressions in the from clause!
Join condition denes which tuples in the two relations
match, and what attributes are present in the result of the join.!
Join type denes how tuples in each relation that do not
4.28!
4.29!
course.course_id = prereq.course_id!
4.30!
4.31!
!
E.g. !
Find the names of all instructors who have a higher salary than
some instructor in Comp. Sci .!
instructor as T instructor T!
4.32!
String Operations!
SQL includes a string-matching operator for comparisons on
Find the names of all instructors whose name includes the substring
dar .
! select name
!from instructor
!where name like '%dar%'
Match the string 100 % !
!
4.33!
!
SQL supports a variety of string operations such as!
concatenation (using || )!
4.34!
Case Construct!
Like case, if, and ? Operators in programming languages!
case!
when c1 then e1!
when c2 then e2!
!
[else en]!
end!
!
Each ci is a condition!
Each e1 is an expression!
Returns the rst ei for which ci evaluates to true!
4.35!
select!
name,!
case!
when salary > 1000000 then premium!
else standard!
end as customer_group!
from customer!
4.36!
4.37!
select name
from instructor
where salary between 90000 and 100000!
Tuple comparison!
4.38!
Set Operations!
Find courses that ran in Fall 2009 or in Spring 2010!
(select course_id from section where sem = Fall and year = 2009)
union
(select course_id from section where sem = Spring and year = 2010)!
Find courses that ran in Fall 2009 and in Spring 2010!
(select course_id from section where sem = Fall and year = 2009)
intersect
(select course_id from section where sem = Spring and year = 2010)!
Find courses that ran in Fall 2009 but not in Spring 2010!
(select course_id from section where sem = Fall and year = 2009)
except
(select course_id from section where sem = Spring and year = 2010)!
4.39!
Set Operations!
Set operations union, intersect, and except !
4.40!
Null Values!
It is possible for tuples to have a null value, denoted by null, for
some of their attributes!
null signies an unkown value or that a value does not exist.!
The result of any arithmetic expression and comparisons
involving null evaluate to null!
!from instructor
!where salary is null!
4.41!
or
null = null!
4.42!
Aggregate Functions!
These functions operate on the multiset of values of a
column of a relation, and return a value!
!
4.43!
4.44!
4.45!
Aggregation (Cont.)!
Attributes in select clause outside of aggregate functions must
appear in group by list!
/* erroneous query */
select dept_name, ID, avg (salary)
from instructor
group by dept_name;!
4.46!
4.47!
count returns 0!
4.48!
count: returns 0!
4.49!
Duplicates!
In relations with duplicates, SQL can dene how many copies
of tuples appear in the result.!
Multiset versions of some of the relational algebra operators
given multiset relations r1 and r2:!
4.50!
allowed)!
4.51!
Duplicates (Cont.)!
Example: Suppose multiset relations r1 (A, B) and r2 (C)
are as follows:!
!
! r1 = {(1, a) (2,a)}
!!
A ,A ,,A ( P (r1 r2 rm ))
1
4.52!
4.53!
4.54!
4.55!
Nested Subqueries!
SQL provides a mechanism for the nesting of subqueries.!
A subquery is a select-from-where expression that is nested
within another query.!
A common use of subqueries is to perform tests for set
membership, set comparisons, and set cardinality.!
4.56!
Example Query!
Find courses offered in Fall 2009 and in Spring 2010!
4.57!
Example Query!
Find the total number of (distinct) studentswho have taken
course sections taught by the instructor with ID 10101!
4.58!
Quantication!
Find names of instructors with salary greater than that of some
(at least one) instructor in the Biology department.!
4.59!
0
5
6
) = true!
(5 < some!
0
5
) = false!
(5 = some!
0
5
) = true!
(5 some!
0
5
) = true (since 0 5)
(5 < some!
(= some) in
However, ( some) not in
4.60!
Example Query!
Find the names of all instructors whose salary is greater than
the salary of all instructors in the Biology department.!
select name!
from instructor!
where salary > all (select salary!
from instructor!
where dept_name = Biology );!
4.61!
0
5
6
) = false!
(5 < all!
6
10
) = true!
(5 = all!
4
5
) = false!
(5 all!
4
6
(5 < all!
( all) not in
However, (= all) in
4.62!
4.63!
Correlation Variables!
Yet another way of specifying the query Find all courses
taught in both the Fall 2009 semester and in the Spring 2010
semester !
! select course_id
from section as S
where semester = Fall and year= 2009 and
exists (select *
from section as T
where semester = Spring and year= 2010
and S.course_id= T.course_id);!
Correlated subquery!
Correlation name or correlation variable!
4.64!
Not Exists!
Find all students who have taken all courses offered in the
Biology department.!
Note that X Y = X Y!
Note: Cannot write this query using = all and its variants
4.65!
in its result.!
select T.course_id
from course as T
where unique (select R.course_id
from section as R
where T.course_id= R.course_id
and R.year = 2009);!
4.66!
4.67!
With Clause!
The with clause provides a way of dening a temporary view
4.68!
variations!
Find all departments where the total salary is greater than the
4.69!
Scalar Subquery!
Scalar subquery is one which is used where a single value is expected!
E.g.
select dept_name,
(select count(*)
from instructor
where department.dept_name = instructor.dept_name)
as num_instructors
from department;!
!
E.g. select name
from instructor
where salary * 10 >
(select budget from department
where department.dept_name = instructor.dept_name)
!
Runtime error if subquery returns more than one result tuple!
4.70!
4.71!
SELECT 1;!
Convention:
a,b FROM r !
4.72!
Syntax - SELECT!
SELECT [DISTINCT [ON (distinct_list)]] select_list!
select_list!
[AS name]!
expr!
Expression
distinct_list!
List of expressions!
Examples:!
4.73!
Syntax - FROM!
FROM from_list!
from_list!
subquery!
Any
relation!
A
constant_relation!
(VALUES
join_expr!
joins
alias!
[AS]
b [(attribute_name_list)]!
4.74!
4.75!
Syntax - WHERE!
WHERE where_condition!
where_condition: A boolean expression over!
Attributes!
Function calls!
Examples!
4.76!
List of expressions!
Expression
Examples:!
4.77!
Syntax HAVING!
HAVING having_condition!
having_condition!
Examples:!
4.78!
Examples:!
4.79!
Query Semantics!
Evaluation Algorithm (you can do it manually sort of)!
1. Compute FROM clause!
1.
nothing to do!
Subqueries:
Join
!
CS425 Fall 2013 Boris Glavic!
4.80!
Use
4.81!
((G(((F1 . . . Fn ))))
Where Fi is the translation of the ith FROM clause item !
Note: we leave out the arguments!
4.82!
4.83!
4.84!
Deletion (Cont.)!
Delete all instructors whose salary is less than the average
salary of instructors!
4.85!
!
or equivalently
insert into course (course_id, title, dept_name, credits)
values ( CS-437 , Database Systems , Comp. Sci. , 4);!
!
Add a new tuple to student with tot_creds set to null!
!
4.86!
Insertion (Cont.)!
Add all instructors to the student relation with tot_creds set to 0!
!
its results are inserted into the relation (otherwise queries like
!insert into table1 select * from table1
would cause problems, if table1 did not have any primary key
dened. !
4.87!
update instructor
set salary = salary * 1.03
where salary > 100000;
update instructor
set salary = salary * 1.05
where salary <= 100000;!
4.88!
! update instructor
set salary = case
when salary <= 100000 then salary * 1.05
else salary * 1.03
end!
4.89!
update student S
set tot_cred = ( select sum(credits)
from takes natural join course
where S.ID= takes.ID and
takes.grade <> F and
takes.grade is not null);!
Sets tot_creds to null for students who have not taken any course!
Instead of sum(credits), use:!
case
when sum(credits) is not null then sum(credits)
else 0
end!
Or COALESCE(sum(credits),0)!
!
CS425 Fall 2013 Boris Glavic!
4.90!
Recap!
SQL queries!
Nested subqueries!
SQL DDL!
4.91!
End of Chapter 4!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL - Intermediate!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
4.93!
4.94!
Figure 3.02!
4.95!
Figure 3.03!
4.96!
Figure 3.04!
4.97!
Figure 3.05!
4.98!
Figure 3.07!
4.99!
Figure 3.08!
4.100!
Figure 3.09!
4.101!
Figure 3.10!
4.102!
Figure 3.11!
4.103!
Figure 3.12!
4.104!
Figure 3.13!
4.105!
Figure 3.16!
4.106!
Figure 3.17!
4.107!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Textbook: Chapter 4!
CS425 Fall 2013 Boris Glavic!
5.2!
Views!
In some cases, it is not desirable for all users to see the
entire logical model (that is, all the actual relations stored in
the database.)!
Consider a person who needs to know an instructors name
and department, but not the salary. This person should see a
relation described, in SQL, by
!
!
select ID, name, dept_name
from instructor!
!
A view provides a mechanism to hide certain data from the
5.3!
View Denition!
A view is dened using the create view statement which has
the form!
!
5.4!
Example Views!
A view of instructors without their salary
select name
from faculty
where dept_name = Biology !
Create a view of department salary totals
!!
5.5!
5.6!
View Expansion!
Expand use of a view in a query/another view!
5.7!
from v1 to v2 !
A view relation v is said to be recursive if it depends on itself.!
5.8!
View Expansion!
A way to dene the meaning of views dened in terms of other
views.!
Let view v1 be dened by an expression e1 that may itself
contain uses of view relations.!
View expansion of an expression repeats the following
replacement step:!
!
!repeat
5.9!
Update of a View!
Add a new tuple to faculty view which we dened earlier!
5.10!
if no department is in Taylor?!
Any attribute not listed in the select clause can be set to null!
5.11!
select *
from instructor
where dept_name= History ;!
What happens if we insert ( 25566 , Brown , Biology ,
100000) into history_instructors?!
5.12!
Materialized Views!
Materializing a view: create a physical table containing all the tuples
5.13!
Transactions!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Transactions!
Unit of work!
Atomic transaction!
automatically!
Can turn off auto commit for a session (e.g. using API)!
5.15!
Transactions Example!
Example Atomicity (all-or-nothing)!
A user want to transfer $100 from his savings (accID = 100) to his
checking account (accID= 101)!
This can cause inconsistencies if the system crashes after the rst
update (user would loose money)!
BEGIN!
UPDATE accounts SET balance = balance 100 WHERE accID = 100;!
UPDATE accounts SET balance = balance + 100 WHERE accID = 101;!
COMMIT!
!
5.16!
users!
Recall from the introduction that if several users are modifying the
5.17!
Integrity Constraints!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Integrity Constraints!
Integrity constraints guard against accidental damage to the
5.19!
5.20!
"
5.21!
where P is a predicate!
Example: ensure that semester is one of fall, winter, spring
or summer:!
!
create table section ("
course_id varchar (8),!
sec_id varchar (8),!
semester varchar (6),!
year numeric (4,0),!
building varchar (15),!
room_number varchar (7),!
time slot id varchar (4), !
primary key (course_id, sec_id, semester, year),!
check (semester in ( Fall , Winter , Spring ,
Summer ))
);!
CS425 Fall 2013 Boris Glavic!
5.22!
Silberschatz, Korth and Sudarshan!
Referential Integrity!
Ensures that a value that appears in one relation for a given
5.23!
dept_name varchar(20),
foreign key (dept_name) references department
on delete cascade
on update cascade,
...
)!
alternative actions to cascade: set null, set default!
"
"
CS425 Fall 2013 Boris Glavic!
5.24!
5.25!
5.26!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
time 09:00:30.75 !
Example: timestamp
2005-7-27 09:00:30.75 !
Example: interval
1 day!
5.28!
Index Creation!
create table student"
e.g. select *
from student
where ID = 12345 !
5.29!
User-Dened Types!
create type construct in SQL creates user-dened type!
!
!
!
5.30!
Domains!
create domain construct in SQL-92 creates user-dened
domain types!
!
! !create domain person_name char(20) not null!
!
Types and domains are similar. Domains can have
constraint degree_level_test
check (value in ( Bachelors , Masters , Doctorate ));!
5.31!
Large-Object Types!
Large objects (photos, videos, CAD les, etc.) are stored as a
large object:!
5.32!
Access Control!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Access Control!
Forms of authorization on parts of the database:!
Read - allows reading, but not modication of data.!
Insert - allows insertion of new data, but not modication of
existing data.!
Update - allows modication, but not deletion of data.!
Delete - allows deletion of data.!
!
Forms of authorization to modify the database schema!
Index - allows creation and deletion of indices.!
Resources - allows creation of new relations.!
Alteration - allows addition or deletion of attributes in a relation.!
Drop - allows deletion of relations.!
5.34!
a user-id!
5.35!
Privileges in SQL!
select: allows read access to relation,or the ability to query
using the view!
5.36!
different grantees, the user may retain the privilege after the
revocation.!
All privileges that depend on the privilege being revoked are
also revoked.!
!
5.37!
Roles!
create role instructor;!
grant instructor to Amit;!
Privileges can be granted to roles:!
Chain of roles!
5.38!
Authorization on Views!
create view geo_instructor as
(select *
from instructor
where dept_name = Geology );!
grant select on geo_instructor to geo_staff"
Suppose that a geo_staff member issues!
select *
from geo_instructor;!
What if !
5.39!
transfer of privileges!
Etc. read text book Section 4.6 for more details we have
omitted here.!
5.40!
Understanding RESTRICT/CASCADE!
Bob grants right X on Y to Alice with grant option!
Bob!
!
Abandoned right!
Alice!
Peter!
5.41!
Understanding RESTRICT/CASCADE!
Bob grants right X on Y to Alice with grant option!
Bob!
Abandoned privilege!
Peter!
5.42!
Recap!
Views!
Virtual!
Materialized!
Updates!
Integrity Constraints!
Not null, unique, check!
Foreign keys: referential integrity!
Access control!
Users, roles!
Privileges!
GRANT / REVOKE!
Data types!
Build-in types, Domains, Large Objects!
UDTs!
Indices!
5.43!
End of Chapter 5!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL - Advanced!
Database Design!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
5.45!
Figure 4.01!
5.46!
Figure 4.02!
5.47!
Figure 4.03!
5.48!
Figure 4.04!
5.49!
Figure 4.05!
5.50!
Figure 4.07!
Taylor
5.51!
Figure 4.06!
Join conditions
natural
on < predicate>
using (A1, A2, . . ., An)
Join types
inner join
le! outer join
right outer join
full outer join
5.52!
Figure 4.03!
DBA
U1
U4
U2
U5
U3
5.53!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Dynamic SQL!
JDBC
and ODBC!
Embedded SQL!
Textbook: Chapter 5!
CS425 Fall 2013 Boris Glavic!
5.2!
5.3!
5.4!
Native APIs!
Most DBMS also dene DBMS specic APIs!
Oracle: OCI!
Postgres: libpg!
!
!
5.5!
JDBC!
JDBC is a Java API for communicating with database systems
supporting SQL.!
JDBC supports a variety of features for querying and updating
data, and for retrieving query results.!
JDBC also supports metadata retrieval, such as querying about
Open a connection!
5.6!
JDBC Code!
public static void JDBCexample(String dbid, String userid, String passwd) !
{!
try { !
Class.forName ("oracle.jdbc.driver.OracleDriver"); // load driver!
Connection conn = DriverManager.getConnection( // connect to server
"jdbc:oracle:thin:@db.yale.edu:2000:univdb", userid, passwd); !
Statement stmt = conn.createStatement(); // create Statement object!
Do Actual Work .!
stmt.close(); // close Statement and release resources !!
conn.close(); // close Connection and release resources
}!
!!
!!
!!
!!
!!
}!
5.7!
try {
stmt.executeUpdate(
"insert into instructor values( 77987 , Kim , Physics ,
98000)");
} catch (SQLException sqle)
{
System.out.println("Could not insert tuple. " + sqle);
}!
Execute query and fetch and print results!
5.8!
5.9!
Prepared Statement!
PreparedStatement pStmt = conn.prepareStatement(
"insert into instructor values( " + ID + " , " + name + " , " +
" + dept name + " , " balance +
")
5.10!
SQL Injection!
Suppose query is constructed using!
which is:!
select * from instructor where name = X or Y = Y !
User could have even used!
X ; update instructor set salary = salary + 10000; --!
Prepared statement internally uses:
"select * from instructor where name = X\ or \ Y\ = \ Y !
Always use prepared statements, with user inputs as
parameters!
5.11!
Metadata Features!
ResultSet metadata!
E.g., after executing query to get a ResultSet rs:!
}!
5.12!
Metadata (Cont)!
Database metadata!
DatabaseMetaData dbmd = conn.getMetaData();!
!ResultSet rs = dbmd.getColumns(null, "univdb", "department", "%");!
!// Arguments to getColumns: Catalog, Schema-pattern, Table-pattern,!
!// and Column-Pattern!
!// Returns: One row for each column; row has a number of attributes!
!// such as COLUMN_NAME, TYPE_NAME!
!while( rs.next()) {!
!
System.out.println(rs.getString("COLUMN_NAME"),!
rs.getString("TYPE_NAME");!
}!
And where is this useful?!
5.13!
conn.setAutoCommit(false);!
conn.commit();
conn.rollback();!
or!
5.14!
5.15!
SQLJ!
JDBC is overly dynamic, errors cannot be caught by compiler!
SQLJ: embedded SQL in Java!
!!
!while (iter.next()) {!
! ! String deptName = iter.dept_name();!
!
!}!
!iter.close();!
5.16!
ODBC!
Open DataBase Connectivity(ODBC) standard !
send
get
back results.!
many languages.!
!
5.17!
ODBC (Cont.)!
Each database system supporting ODBC provides a "driver"
SQLConnect:!
connection handle,!
password !
5.18!
ODBC Code!
int ODBCexample()!
!{!
RETCODE error;!
HENV env; /* environment */ !
HDBC conn; /* database connection */ !
SQLAllocEnv(&env);!
SQLAllocConnect(env, &conn);!
SQLConnect(conn, db.yale.edu", SQL_NTS, "avi", SQL_NTS,
"avipasswd", SQL_NTS); !
{ . Do actual work }!
!
SQLDisconnect(conn); !
SQLFreeConnect(conn); !
SQLFreeEnv(env); !
}!
5.19!
The
5.20!
char deptname[80];
oat salary;
int lenOut1, lenOut2;
HSTMT stmt;
char * sqlquery = "select dept_name, sum (salary)
from instructor
group by dept_name";
SQLAllocStmt(conn, &stmt);
error = SQLExecDirect(stmt, sqlquery, SQL_NTS);
if (error == SQL SUCCESS) {
SQLBindCol(stmt, 1, SQL_C_CHAR, deptname , 80, &lenOut1);
SQLBindCol(stmt, 2, SQL_C_FLOAT, &salary, 0 , &lenOut2);
while (SQLFetch(stmt) == SQL_SUCCESS) {
printf (" %s %g\n", deptname, salary);
}
}
SQLFreeStmt(stmt, SQL_DROP);!
CS425 Fall 2013 Boris Glavic!
5.21!
To prepare a statement
SQLBindParameter(stmt, <parameter#>,
type information and value omitted for simplicity..)!
To execute the statement
5.22!
SQL_AUTOCOMMIT, 0)} !
SQL_COMMIT) or!
SQLTransact(conn,
SQL_ROLLBACK)!
5.23!
by the standard.!
Core!
5.24!
ADO.NET!
API designed for Visual Basic .NET and C#, providing database access
5.25!
Dynamic SQL!
code!
Compiler!
Preprocessor!
code!
Compiler!
binary!
binary!
Library!
Library!
DBMS!
DBMS!
5.26!
Embedded SQL!
The SQL standard denes embeddings of SQL in a variety of
programming languages such as C, Java, and Cobol.!
A language to which SQL queries are embedded is referred to as
!
!Note: this varies by language (for example, the Java embedding
uses # SQL { . }; ) !
5.27!
Example Query!
From within a host language, nd the ID and name of
EXEC SQL!
!
5.28!
The fetch statement causes the values of one tuple in the query
Note: above details vary with language. For example, the Java
embedding denes Java iterators to step through result tuples.!
CS425 Fall 2013 Boris Glavic!
5.29!
is for update!
declare c cursor for
select *
from instructor
where dept_name = Music
for update!
To update tuple at the current location of cursor c!
update instructor
set salary = salary + 100
where current of c"
!
5.30!
5.31!
Stored Procedures!
5.32!
5.34!
SQL Functions!
Dene a function that, given the name of a department, returns
the count of the number of instructors in that department.!
"from department
"where dept_count (dept_name ) > 1"
CS425 Fall 2013 Boris Glavic!
5.35!
Table Functions!
SQL:2003 added functions that return a relation as a result!
Example: Return all accounts owned by a given customer!
!create function instructors_of (dept_name char(20)!
!
!name varchar(20),
dept_name varchar(20),
!salary numeric(8,2))!
!return table
!select *
5.36!
SQL Procedures!
The dept_count function could instead be written as procedure:!
!create procedure dept_count_proc (in dept_name varchar(20),
begin!
! select count(*) into d_count
from instructor
where instructor.dept_name = dept_count_proc.dept_name"
end!
Procedures can be invoked either from an SQL procedure or from
embedded SQL, using the call statement.!
!
!declare d_count integer;
!call dept_count_proc( Physics , d_count);!
!Procedures and functions can be invoked also from dynamic SQL!
SQL:1999 allows more than one function/procedure of the same
5.37!
Procedural Constructs!
Warning: most database systems implement their own variant of the
5.38!
Example:
declare n integer default 0;
for r as
select budget from department
where dept_name = Music
do
!
set n = n - r.budget
end for!
5.39!
is not exceeded!
5.40!
!
!create procedure dept_count_proc(in dept_name varchar(20),
out count integer)
language C
external name /usr/avi/bin/dept_count_proc
5.41!
Drawbacks!
security
5.42!
5.43!
Triggers!
5.44!
Triggers!
A trigger is a statement that is executed automatically by
5.45!
Trigger Example!
E.g. time_slot_id is not a primary key of timeslot, so we cannot
create a foreign key constraint from section to timeslot."
Alternative: use triggers on section and timeslot to enforce integrity
constraints!
5.46!
5.47!
5.48!
(grade)
referencing new row as nrow
referencing old row as orow
for each row
when nrow.grade <> F and nrow.grade is not null
and (orow.grade = F or orow.grade is null)
begin atomic
update student
set tot_cred= tot_cred +
(select credits
from course
where course.course_id= nrow.course_id)
where student.id = nrow.id;
end;!
5.49!
Use
row!
5.50!
instead of
for each
5.51!
Cascading execution!
5.52!
Recursive Queries!
5.53!
Recursion in SQL!
SQL:1999 permits recursive view denition!
Example: nd which courses are a prerequisite, whether
5.54!
Given
Alternative:
required!
See procedure ndAllPrereqs in book!
5.55!
tuples to rec_prereq"
The nal result is called the xed point of the recursive view
denition.!
5.56!
5.57!
manager(employee_name, manager_name)!
Find all employee-manager pairs, where the employee reports to the
5.58!
Recap!
Programming Language Interfaces for Databases!
Recursive Queries!
5.59!
End of Chapter!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL - Advanced!
Database Design ER model!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
5.61!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
7.2!
Database Design!
World!
???!
Relational DB schema!
7.3!
Database Design!
World!
Requirement Analysis!
Mind Model!
English (e.g.)!
???!
Relational DB schema!
7.4!
animals, but there may be cages that are currently empty. Cages have
a size in square meter.!
Zoo keepers are identied by their social security number. We store a
rst name, last name, and for each zoo keeper. Zoo keepers are
assigned to cages they have to take care of (clean, ). Each cage
that is not empty has a zoo keeper assigned to it. A zoo keeper can
take care of several cages. Each zoo keeper takes care of at least one
cage.!
7.5!
7.6!
Database Design!
World!
Requirement Analysis!
Mind Model!
English (e.g.)!
Conceptual modeling!
Conceptual Model!
ER model!
???!
Relational DB schema!
7.7!
Database Design!
World!
Requirement Analysis!
Mind Model!
English (e.g.)!
Conceptual modeling!
Conceptual Model!
ER model!
7.8!
SQL (e.g.)!
Modeling ER model!
A database can be modeled as:!
a collection of entities,!
objects.!
An entity set is a set of entities of the same type that share the same
properties.!
7.9!
instructor_ID instructor_name
student-ID student_name
76766 Crick
98988
Tanaka
45565 Katz
12345
Shankar
10101 Srinivasan
00128
Zhang
98345 Kim
76543
Brown
76543 Singh
76653
Aoi
22222 Einstein
23121
Chavez
44553
Peltier
instructor
student
7.10!
Relationship Sets!
A relationship is an association among several entities!
!Example:
! 44553 (Peltier)
! student entity
!advisor
! 22222 (Einstein)
!relationship set ! instructor entity!
Example: !
!
(44553,22222) advisor!
7.11!
98988 Tanaka
45565 Katz
12345 Shankar
10101 Srinivasan
00128 Zhang
98345 Kim
76543 Brown
76543 Singh
76653 Aoi
22222 Einstein
23121 Chavez
44553 Peltier
instructor
student
7.12!
instructor and student may have the attribute date which tracks when
the student started being associated with the advisor!
98988 Tanaka
76766 Crick
45565 Katz
10101 Srinivasan
3 May 2008
10 June 2007
12 June 2006
12345 Shankar
00128 Zhang
98345 Kim
6 June 2009
76543 Brown
76543 Singh
30 June 2007
76653 Aoi
22222 Einstein
31 May 2007
4 May 2006
23121 Chavez
44553 Peltier
instructor
student
CS425 Fall 2013 Boris Glavic!
7.13!
Relationships between more than two entity sets are rare. Most
7.14!
Attributes!
An entity is represented by a set of attributes, that are descriptive
Example: !
!instructor = (ID, name, street, city, salary )
!course= (course_id, title, credits)!
Derived attributes!
Can
Example:
7.15!
Composite Attributes!
composite
attributes
first_name
name
middle_initial
address
last_name
street
city
state
postal_code
component
attributes
street_number
7.16!
street_name
apartment_number
7.17!
Mapping Cardinalities!
One to many!
One to one!
7.18!
Birth certicate!
Advisor!
Student!
One to many!
One to one!
7.19!
Mapping Cardinalities!
Many to one!
Many to many!
7.20!
Student!
Department!
Many to one!
Course!
Many to many!
7.21!
element?!
E.g., 0:1 1 !
1-1!
1-1!
N-1!
0:1-1!
N-0:1!
1-0:1!
0:N-1!
0:1-0:1!
0:N-0:1!
N-M!
1-N!
0:1-N!
N-M!
0:1-0:N!
N-0:M!
1-N!
0:N-M!
1-0:N!
0:N-0:M!
7.22!
(0:1) (1:N) !
7.23!
Keys!
A super key of an entity set is a set of one or more attributes
7.24!
7.25!
hasBc: (Person-Birthcerticate)!
worksFor: (Instructor-Department)!
takes: (Student-Course)!
7.26!
Redundant Attributes!
Suppose we have entity sets!
department!
and a relationship!
7.27!
E-R Diagrams!
student
instructor
ID
name
salary
advisor
ID
name
tot_cred
7.28!
7.29!
Multi-valued!
ID
name
first_name
middle_initial
last_name
address
street
street_number
street_name
apt_number
city
state
zip
{ phone_number }
date_of_birth
age ( )
7.30!
composite!
derived!
instructor
ID
name
salary
student
advisor
7.31!
ID
name
tot_cred
Roles!
Entity sets of a relationship need not be distinct!
course
course_id
title
credits
course_id
prereq_id
7.32!
prereq
Cardinality Constraints!
We express cardinality constraints by drawing either a directed line
7.33!
One-to-One Relationship!
one-to-one relationship between an instructor and a student!
instructor
ID
name
salary
student
advisor
7.34!
ID
name
tot_cred
One-to-Many Relationship!
one-to-many relationship between an instructor and a student!
student
instructor
ID
name
salary
advisor
7.35!
ID
name
tot_cred
Many-to-One Relationships!
In a many-to-one relationship between an instructor and a student,!
instructor
ID
name
salary
student
advisor
7.36!
ID
name
tot_cred
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 !
student
instructor
ID
name
salary
advisor
7.37!
ID
name
tot_cred
course
course_id
title
credits
sec_course
7.38!
section
sec_id
semester
year
instructor
ID
name
salary
student
0.. *
advisor
7.39!
1..1
ID
name
tot_cred
instructor
ID
name
salary
student
0.. *
advisor
1..1
(1,1)!
(0,n)!
7.40!
ID
name
tot_cred
...
student
instructor
ID
name
salary
proj_ guide
7.41!
ID
name
tot_cred
meaning. !
7.42!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
The discriminator (or partial key) of a weak entity set is the set of
the strong entity set on which the weak entity set is existence
dependent, plus the weak entity sets discriminator.!
7.45!
line.!
We put the identifying relationship of a weak entity in a double
diamond. !
Primary key for section (course_id, sec_id, semester, year) !
course
course_id
title
credits
sec_course
7.46!
section
sec_id
semester
year
entity, but then the relationship between section and course would
be duplicated by an implicit relationship dened by the attribute
course_id common to course and section!
7.47!
dept_name
building
budget
stud_dept
inst_dept
instructor
ID
name
salary
student
advisor
takes
teaches
course_id
title
credits
prereq
grade
section
course
course_id
ID
name
tot_cred
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.48!
7.49!
7.50!
course
course_id
title
credits
sec_course
7.51!
section
sec_id
semester
year
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!
student
instructor
ID
name
salary
advisor
7.52!
ID
name
tot_cred
Redundancy of Schemas!
Many-to-one and one-to-many relationship sets that are total on the
rse_dept
dept_name
building
budget
stud_dept
inst_dept
instructor
ID
name
salary
student
advisor
7.53!
ID
name
tot_cred
7.54!
schema is!
instructor(ID,
rst_name, middle_initial, last_name,
street_number, street_name,
apt_number, city, state, zip_code,
date_of_birth)!
7.55!
schema EM!
7.56!
section
sec_id
semester
year
sec_class
time_slot
sec_time_slot
7.57!
time_slot_id
{ day
start_time
end_time
}
Silberschatz, Korth and Sudarshan!
Design Issues!
Use of entity sets vs. attributes
instructor
ID
name
salary
phone_number
instructor
inst_phone
ID
name
salary
phone
phone_number
location
Designing phone as an entity allow for primary key constraints for phone!
Designing phone as an entity allow phone numbers to be used in
7.58!
Design Issues!
Use of entity sets vs. relationship sets!
Possible hint: the relationship only relates entities, but does not have an
existence by itself. E.g., hasAddress: (department-address)
!
registration
section_reg
...
...
...
student_reg
section
student
sec_id
semester
year
ID
name
tot_cred
7.59!
Design Issues!
Binary versus n-ary relationship sets!
!!
7.60!
proj_guide!
7.61!
RA
(a)
CS425 Fall 2013 Boris Glavic!
RB
RC
(b)
7.62!
7.63!
(a)
7.64!
If both sides are total merge the two relation into a new relation E
and choose either PK(A) as PK(B) as the new PK. Add any
attributes of the relationship R to the new relation E.!
7.65!
one!
Add PK of the one side as foreign key to the many side. !
Add any attributes of the relationship R to the many side.!
Rule 5) Binary relationship R between A and B: many-to-many!
Create a new relation R. !
Add PKs of A and B as attributes + plus all attributes of R. !
The primary key of the relationship is PK(A) + PK(B). The PK
attributes of A/B form a foreign key to A/B!
Rule 6) N-ary relationship R between E1 En!
7.66!
7.67!
dept_name
building
budget
stud_dept
inst_dept
instructor
ID
name
salary
student
advisor
takes
teaches
course_id
title
credits
prereq
grade
section
course
course_id
ID
name
tot_cred
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.68!
department
course_dept
dept_name
building
budget
stud_dept
inst_dept
instructor
ID
name
salary
time_slot(time_slot_id)!
classroom(building,room_number, capacity)!
student
ID
name
tot_cred
advisor
takes
teaches
grade
section
course
course_id
title
credits
course_id
prereq
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.69!
dept_name
building
budget
None exist!
stud_dept
inst_dept
instructor
ID
name
salary
student
takes
teaches
course_id
prereq
sec_course
prereq_id
time_slot(time_slot_id)!
classroom(building,room_number, capacity)!
7.70!
grade
section
course
course_id
title
credits
ID
name
tot_cred
advisor
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
time_slot(time_slot_id)!
classroom(building,room_number, capacity)!
department
course_dept
instructor
ID
name
salary
prereq(course_id, prereq_id)!
course_id
takes
prereq
grade
section
course
student
ID
name
tot_cred
advisor
teaches
course_id
title
credits
none exist!
stud_dept
inst_dept
dept_name
building
budget
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.71!
time_slot(time_slot_id)!
classroom(building,room_number, capacity)!
department
course_dept
stud_dept
inst_dept
instructor
ID
name
salary
prereq(course_id, prereq_id)!
dept_name
building
budget
student
ID
name
tot_cred
advisor
takes
teaches
grade
course
course_id
title
credits
course_id
prereq
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.72!
Extended ER Features!
7.73!
person).!
Attribute inheritance a lower-level entity set inherits all the attributes
7.74!
Specialization Example!
person
ID
name
address
student
employee
salary
instructor
rank
tot_credits
secretary
hours_per_week
7.75!
interchangeably.!
7.76!
features. !
E.g., permanent_employee vs. temporary_employee, in addition to
relationship!
7.77!
set.!
condition-dened!
Example:
all customers over 65 years are members of seniorcitizen entity set; senior-citizen ISA person.!
user-dened!
Constraint on whether or not entities may belong to more than one lower-
Disjoint!
an
Noted
Overlapping!
an
7.78!
Specialization Example!
person
ID
name
address
Disjoint, employees
are either instructors or
secretaries !
student
employee
salary
instructor
rank
Overlapping, a
person can be
both an employee
and a student!
tot_credits
secretary
hours_per_week
7.79!
the higher-level entity set must belong to at least one of the lowerlevel entity sets within a generalization.!
7.80!
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!
project
instructor
proj_ guide
student
eval_ for
evaluation
7.81!
Aggregation (Cont.)!
Relationship sets eval_for and proj_guide represent overlapping
information!
7.82!
Aggregation (Cont.)!
Without introducing redundancy, the following diagram represents:!
instructor
proj_ guide
student
eval_ for
evaluation
7.83!
schema
person
student
employee
! attributes
! ID, name, street, city
! ID, tot_cred
! ID, salary!
7.84!
Form a single relation schema for each entity set with all local and
inherited attributes
!schema
!
attributes
person
!
ID, name, street, city
!
student
!
ID, name, street, city, tot_cred
employee !
ID, name, street, city, salary!
But
Drawback: name, street and city may be stored redundantly for people
who are both students and employees!
7.85!
Form a single relation schema for each entity set with all local and
inherited attributes!
For
!
!schema
person
!
!
!
attributes
ID, type, name, street, city, tot_cred, salary!
For
!schema
!
person
!
!
attributes
ID, isEmployee, isStudent, name, street, city, tot_cred, salary!
7.86!
7.87!
Schemas Corresponding to
Aggregation (Cont.)!
For example, to represent aggregation manages between
project
instructor
proj_ guide
student
eval_ for
evaluation
7.88!
Create a new relation with all attributes from E and S1, ,Sn. !
Add single attribute type or a boolean type attribute for each Si!
The primary key is PK(E)!
7.89!
7.90!
ER Design Decisions!
The use of an attribute or entity set to represent an object.!
Whether a real-world concept is best expressed by an entity set or
a relationship set.!
The use of a ternary relationship versus a pair of binary
relationships.!
The use of a strong or weak entity set.!
The use of specialization/generalization contributes to modularity
in the design.!
The use of aggregation can treat the aggregate entity set as a
single unit without concern for the details of its internal structure.!
7.91!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
entity set
A1
A2
A2.1
A2.2
relationship set
{A3}
a!ributes:
simple (A1),
composite (A2) and
multivalued (A3)
derived (A4)
A4()
identifying
relationship set
for weak entity set
E
A1
total participation
of entity set in
relationship
E
A1
7.93!
primary key
discriminating
a!ribute of
weak entity set
many-to-many
relationship
one-to-one
relationship
rolename
l..h
E1
total
cardinality
limits
E1
role indicator
E2
E2
many-to-one
relationship
E3
E1
total (disjoint)
generalization
E3
E2
7.94!
ISA: generalization
or specialization
disjoint
generalization
E3
Alternative ER Notations!
Chen, IDE1FX, !
entity set E with
simple a!ribute A1,
composite a!ribute A2,
multivalued a!ribute A3,
derived a!ribute A4,
and primary key A1
A2.1
A2.2
A2
A1
E
generalization
7.95!
ISA
A3
A4
total
generalization
ISA
Alternative ER Notations!
Chen
many-to-many
relationship
E1
one-to-one
relationship
E1
many-to-one
relationship
E1
participation
in R: total (E1)
and partial (E2)
E1
E2
E1
E2
E1
E2
E1
E2
E1
7.96!
E2
E2
E2
E2
UML!!
UML: Unied Modeling Language!
UML has many components to graphically model different aspects
differences.!
7.97!
E
A1
M1()
E1
Equivalent in UML
role1
role2
E2
A1
+M1()
binary
relationship
E1
role1 R role2
E1
role1
0.. *
E2
R
A1
A1
E1
role2
0..1
E2
relationship
a!ributes
E2
cardinality
constraints
E1
E1
role1
role2
0..1 R 0.. *
E2
E2
7.98!
R
E3
Equivalent in UML
n-ary
relationships
E2
E1
R
E3
E1
E1
overlapping
overlapping
generalization
E2
E3
E1
E1
disjoint
generalization
E2
E3
E2
E3
disjoint
E2
E3
7.99!
line connecting the entity sets. The relationship set name is written
adjacent to the line. !
The role played by an entity set in a relationship set may also be
specied by writing the role name on the line, adjacent to the entity
set. !
The relationship set name may alternatively be written in a box,
7.100!
Recap!
ER-model!
Entities!
Strong!
Weak!
Attributes!
Simple vs. Composite!
Single-valued vs. Multi-valued!
Relationships!
Degree (binary vs. N-ary)!
Cardinality constraints!
Specialization/Generalization!
Total vs. partial!
Disjoint vs. overlapping!
Aggregation!
!!
7.101!
Recap Cont.!
ER-Diagrams !
Alternative notations!
UML-Diagrams!
Design decisions!
Multi-valued attribute vs. entity!
Entity vs. relationship!
Binary vs. N-ary relationships!
Placement of relationship attributes!
Total 1-1 vs. single entity!
ER to relational model!
Translation rules!
7.102!
End of Chapter 7
!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Outline!
Introduction!
Relational Data Model!
Formal Relational Languages (relational algebra)!
SQL - Advanced!
Database Design Database modelling!
Transaction Processing, Recovery, and Concurrency Control!
Storage and File Structures!
Indexing and Hashing!
Query Processing and Optimization!
7.104!
Figure 7.01!
76766 Crick
98988
Tanaka
45565 Katz
12345
Shankar
10101 Srinivasan
00128
Zhang
98345 Kim
76543
Brown
76543 Singh
76653
Aoi
22222 Einstein
23121
Chavez
44553
Peltier
instructor
student
7.105!
Figure 7.02!
76766 Crick
98988 Tanaka
45565 Katz
12345 Shankar
10101 Srinivasan
00128 Zhang
98345 Kim
76543 Brown
76543 Singh
76653 Aoi
22222 Einstein
23121 Chavez
44553 Peltier
instructor
student
7.106!
Figure 7.03!
98988 Tanaka
76766 Crick
45565 Katz
10101 Srinivasan
3 May 2008
10 June 2007
12 June 2006
12345 Shankar
00128 Zhang
98345 Kim
6 June 2009
76543 Brown
76543 Singh
30 June 2007
76653 Aoi
22222 Einstein
31 May 2007
4 May 2006
23121 Chavez
44553 Peltier
instructor
student
7.107!
Figure 7.04!
composite
attributes
first_name
name
middle_initial
address
last_name
street
city
state
postal_code
component
attributes
street_number
7.108!
street_name
apartment_number
Figure 7.05!
A
B
b1
a1
a2
a3
a4
b1
a1
b2
b2
a2
b3
b3
a3
b4
b5
(a)
(b)
7.109!
Figure 7.06!
A
a1
a
aa22
b1
a3
b2
a4
a1
b1
a2
b2
a3
b3
a4
b4
b3
a5
(a)
(b)
7.110!
Figure 7.07!
student
instructor
ID
name
salary
advisor
7.111!
ID
name
tot_cred
Figure 7.08!
date
instructor
ID
name
salary
student
advisor
7.112!
ID
name
tot_cred
Figure 7.09!
instructor
ID
name
salary
student
advisor
ID
name
tot_cred
(a)
student
instructor
ID
name
salary
advisor
ID
name
tot_cred
(b)
instructor
ID
name
salary
student
advisor
ID
name
tot_cred
(c)
CS425 Fall 2013 Boris Glavic!
7.113!
Figure 7.10!
instructor
ID
name
salary
student
0.. *
advisor
7.114!
1..1
ID
name
tot_cred
Figure 7.11!
instructor
ID
name
first_name
middle_initial
last_name
address
street
street_number
street_name
apt_number
city
state
zip
{ phone_number }
date_of_birth
age ( )
CS425 Fall 2013 Boris Glavic!
7.115!
Figure 7.12!
course
course_id
title
credits
course_id
prereq_id
7.116!
prereq
Figure 7.13!
course
course_id
title
credits
course_id
prereq_id
7.117!
prereq
Figure 7.14!
course
course_id
title
credits
sec_course
7.118!
section
sec_id
semester
year
Figure 7.15!
department
course_dept
dept_name
building
budget
stud_dept
inst_dept
instructor
ID
name
salary
student
advisor
takes
teaches
course_id
title
credits
prereq
grade
section
course
course_id
ID
name
tot_cred
sec_course
prereq_id
sec_id
semester
year
time_slot
sec_time_slot
time_slot_id
{ day
start_time
end_time
}
sec_class
classroom
building
room_number
capacity
7.119!
Figure 7.17!
instructor
ID
name
salary
phone_number
instructor
inst_phone
ID
name
salary
(a)
phone
phone_number
location
(b)
7.120!
Figure 7.18!
registration
section_reg
...
...
...
section
student
sec_id
semester
year
student_reg
ID
name
tot_cred
7.121!
Figure 7.19!
A
RA
(a)
RB
RC
(b)
7.122!
Figure 7.20!
76766 Crick
98988
Tanaka
May 2009
45565 Katz
12345
Shankar
June 2007
10101 Srinivasan
00128
Zhang
June 2006
98345 Kim
76543
Brown
June 2009
76543 Singh
76653
Aoi
June 2007
22222 Einstein
23121
Chavez
May 2007
44553
Peltier
May 2006
instructor
student
7.123!
Figure 7.21!
person
ID
name
address
student
employee
salary
tot_credits
instructor
rank
CS425 Fall 2013 Boris Glavic!
secretary
hours_per_week
7.124!
Figure 7.22!
project
instructor
proj_ guide
student
eval_ for
evaluation
7.125!
Figure 7.23!
project
instructor
proj_ guide
student
eval_ for
evaluation
7.126!
Figure 7.24!
E
entity set
A1
a!ributes:
simple (A1),
composite (A2) and
multivalued (A3)
derived (A4)
A2
A2.1
R
A2.2
relationship set
{A3}
A4()
identifying
relationship set
for weak entity set
many-to-many
relationship
one-to-one
relationship
A1
many-to-one
relationship
l..h
cardinality
limits
E1
E
E1
total
discriminating
a!ribute of
weak entity set
role indicator
E2
E2
primary key
A1
total participation
of entity set in
relationship
rolename
E3
E3
E1
total (disjoint)
generalization
E2
7.127!
ISA: generalization
or specialization
disjoint
generalization
E3
Silberschatz, Korth and Sudarshan!
many-to-many
relationship
E1
one-to-one
relationship
E1
many-to-one
relationship
E1
participation
in R: total (E1)
and partial (E2)
E1
Figure 7.25!
A2.1
A2.2
A2
A3
A1
A4
E2
E1
E2
E1
E2
E1
E2
E1
generalization
7.128!
ISA
E2
E2
E2
E2
total
generalization
ISA
Figure 7.26!
ER Diagram Notation
entity with
a!ributes (simple,
composite,
multivalued, derived)
E
A1
M1()
E1
Equivalent in UML
role1
role2
E2
A1
+M1()
binary
relationship
E1
role1 R role2
E1
role1
0.. *
role2
0..1
E2
relationship
a!ributes
E1
E2
cardinality
constraints
E1
E2
E1
R
E3
n-ary
relationships
role1
role2
0..1 R 0.. *
E1
E3
E1
overlapping
E3
E3
E2
E1
E1
disjoint
generalization
E2
overlapping
generalization
E2
E2
E2
E1
E2
E2
R
A1
A1
E1
E3
disjoint
E2
7.129!
E3
Silberschatz, Korth and Sudarshan!
Figure 7.27!
A
RA
RB
(a)
RC
(b)
RAB
RAC
RBC
(c)
CS425 Fall 2013 Boris Glavic!
7.130!
Figure 7.28!
7.131!
Figure 7.29!
author
publisher
name
address
URL
name
address
phone
URL
customer
written_by
book
ISBN
title
year
price
published_by
email
name
address
phone
number
shopping_basket
basket_id
contains
basket_of
number
warehouse
code
address
phone
stocks
7.132!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
8.2!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Combine Schemas?!
Suppose we combine instructor and department into inst_dept!
8.4!
Redundancy is Bad!!
Update Physics Department!
8.5!
8.6!
8.7!
A Lossy Decomposition!
8.8!
!R1 = (A, B)
A,B (r)
A! B! C!
A! B!
B!
C!
! 1! A!
! 2! B!
! 1!
! 2!
1!
2!
A!
B!
r!
A,B(r)!
B,C (r)
B,C(r)!
A! B! C!
! 1! A!
! 2! B!
8.9!
A (r)
A! B! C!
A! B!
B!
C!
! 1! A!
! 2! B!
! 1!
! 2!
1!
2!
A!
B!
r!
A,B(r)!
B (r)
B,C(r)!
A! B! C!
! 1! A!
! 2! B!
8.10!
dependencies!
! multivalued
dependencies!
of values!
! Avoidance
! Lossless
of redundancy!
decomposition!
8.11!
Functional Dependencies!
Constraints on the set of legal instances for a relation schema.!
Require that the value for a certain set of attributes determines
8.13!
! R and R!
!
The functional dependency!
!
!
holds on R if and only if for any legal relations r(R), whenever any
two tuples t1 and t2 of r agree on the attributes , they also agree
on the attributes . That is, !
! t1[] = t2 [] t1[ ] = t2 [ ] !
!
Example: Consider r(A,B ) with the following instance of r.!
1
1
3
4!
5!
7!
8.14!
! R and R!
!
The functional dependency!
!
!
holds on R if and only if for any legal relations r(R), whenever any
two tuples t1 and t2 of r agree on the attributes , they also agree
on the attributes . That is, !
! t1[] = t2 [] t1[ ] = t2 [ ] !
!
Example: Consider r(A,B ) with the following instance of r.!
1
1
3
A = 1 and B = 4!
A = 1 and B = 5!
4!
5!
7!
8.15!
K R, and!
for no K, R!
!
and
!dept_name building!
ID building!
!dept_name salary!
8.16!
test relations to see if they are legal under a given set of functional
dependencies. !
!
! We
dependency even if the functional dependency does not hold on all legal
instances. !
8.17!
relation!
Example:!
!
name name!
In general, is trivial if
!
8.18!
closure of F.!
We denote the closure of F by F+.!
F+ is a superset of F.!
8.19!
Functional-Dependency Theory!
We now consider the formal theory that tells us which functional
Example:!
8.20!
Armstrongs Axioms:!
if , then
(reexivity)!
if , then
(augmentation)!
8.21!
Example!
R = (A, B, C, G, H, I)
F = { A B
! A C
!CG H
!CG I
! B H}!
some members of F+!
AH
! by
AG I
! by
CG HI
! by
8.22!
1) A B, C implies A B and A C !
2) A B and A C implies A B, C!
3) A, B B, C implies A C
4) A B and C D implies A, C B, D!
8.23!
!!
!
F + = F
repeat
!for each functional dependency f in F+
!
apply reexivity and augmentation rules on f
!
add the resulting functional dependencies to F +
!for each pair of functional dependencies f1and f2 in F +
!
if f1 and f2 can be combined using transitivity
!
! then add the resulting functional dependency to F +
until F + does not change any further!
!
NOTE: We shall see an alternative more efcient procedure for this task
later!
8.24!
8.25!
8.26!
!A C
!CG H
!CG I
!B H}!
(AG)+!
1. !result = AG!
2. !result = ABCG !(A C and A B)!
3. !result = ABCGH !(CG H and CG AGBC)!
4. !result = ABCGHI !(CG I and CG AGBCH)!
Is AG a candidate key? !
1. Is AG a super key?!
1. Does AG R? == Is (AG)+ R!
2. Is any subset of AG a superkey?!
1.
Does A R? == Is (A)+ R!
2.
Does G R? == Is (G)+ R!
8.27!
Computing closure of F!
8.28!
list<int>[] rhs: an array of lists with one element per FD. The
element stores the numeric ID of the attributes of the FDs RHS!
8.29!
while(!todo.isEmpty) {!
"curA = todo.pop();!
"// add curA to result!
"aplus.add(curA);
"for fd in lhs[curA]
"
c[fd]--;
"
if (c[fd] == 0) {!
"
"
"
"
"
"
"
"
"
"
"}!
}!
"}!
}!
CS425 Fall 2013 Boris Glavic!
8.30!
Canonical Cover!
Sets of functional dependencies may have redundant dependencies
to
{A B, B C, A D} !
! E.g.:
on LHS:
{A B, B C, AC D} can be simplied
to
{A B, B C, A D} !
Intuitively, a canonical cover of F is a minimal set of functional
8.31!
Extraneous Attributes!
Consider a set F of functional dependencies and the functional
dependency in F.!
Attribute A is extraneous in if A
and F logically implies (F { }) {( A) }.!
Attribute A is extraneous in if A
and the set of functional dependencies
(F { }) { ( A)} logically implies F.!
8.32!
dependency in F.!
To test if attribute A is extraneous in !
1.
2.
2.
8.33!
Canonical Cover!
A canonical cover for F is a set of dependencies Fc such that !
repeat
!Use the union rule to replace any dependencies in F
!
! 1 1 and 1 2 with 1 1 2
!Find a functional dependency with an
!
!extraneous attribute either in or in
/* Note: test for extraneous attributes done using Fc, not F*/
!If an extraneous attribute is found, delete it from
until F does not change!
Note: Union rule may become applicable after some extraneous attributes
have been deleted, so it has to be re-applied!
8.34!
F = {A BC
! B C
! A B
!AB C}!
Combine A BC and A B into A BC!
A is extraneous in AB C!
C is extraneous in A BC !
!
CS425 Fall 2013 Boris Glavic!
!A B
!B C!
8.35!
Lossless Join-Decomposition
Dependency Preservation!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
So Far!
Theory of dependencies!
What is missing?!
decomposition!
! Dependencies
forms!
normal forms!
decomposition!
8.37!
Lossless-join Decomposition!
For the case of R = (R1, R2), we require that for all possible relation
instances r on schema R!
!r
= R1 (r )
R2 (r ) !
R1 R2 R1!
R 1 R 2 R2!
8.38!
Example!
R = (A, B, C)
F = {A B, B C)!
Lossless-join decomposition:!
!
Dependency preserving!
Lossless-join decomposition:!
!
8.39!
R2)!
Dependency Preservation!
! If
8.40!
result =
while (changes to result) do
!for each Ri in the decomposition
!
!t = (result Ri)+ Ri
!
!result = result t!
Fn)+ !
8.41!
Example!
R = (A, B, C )
F = {A B
! B C}
Key = {A}!
Decomposition R1 = (A, B), R2 = (B, C)!
Lossless-join decomposition!
Dependency preserving!
8.42!
Normal Forms!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
So Far!
Theory of dependencies!
Decompositions and ways to check whether they are good!
Lossless!
Dependency preserving!
What is missing?!
forms!
normal forms!
decomposition!
8.44!
Goals of Normalization!
Let R be a relation scheme with a set F of functional dependencies.!
Decide whether a relation scheme R is in good form.!
In the case that a relation scheme R is not in good form,
decompose it into a set of relation scheme {R1, R2, ..., Rn} such that !
8.45!
! Identication
parts!
A relational schema R is in rst normal form if the domains of all
8.46!
used.!
Suppose that students are given roll numbers which are strings of
the form CS0012 or EE1127!
8.47!
8.48!
A,B C,D!
A C!
B D!
StudentName)!
Indication that we are putting stuff together that does not belong
together!
8.49!
redudancy!
StudentCWID StudentName!
8.50!
A B,C,D!
C D!
8.51!
! in F+
!
at least one of the following holds:!
is trivial (i.e., )!
is a superkey for R!
!
Alternatively,!
8.52!
3NF Example!
Instructor(Name, Salary, DepName, DepBudget) = I(A,B,C,D)!
A B,C,D!
C D!
8.53!
F+.!
Use attribute closure to check for each dependency , if is a
superkey.!
If is not a superkey, we have to verify if each attribute in is
8.54!
8.55!
8.56!
2.
employee_id branch_name!
3.
8.57!
result will not depend on the order in which FDs are considered!
8.58!
R is in 3NF!
! s_ID,
dept_name is a superkey!
!
i_ID dept_name
!!
8.59!
Redundancy in 3NF!
There is some redundancy in this schema dept_advisor (s_ID, i_ID,
dept_name)!
Example of problems due to redundancy in 3NF!
R = (J, K, L)
F = {JK L, L K }!
J!
L!
K!
j1!
!
j2!
l1!
k1!
!
j3!
l1!
!
l1!
!
!
null! l2!
k1!
!
k1!
!
k2!
(i_ID, dept_name)!
8.60!
8.61!
8.62!
relation in a decomposition of R!
Consider R = (A, B, C, D, E), with F = { A B, BC D}!
! Decompose R into R1 = (A,B) and R2 = (A,C,D, E) !
! Neither of the dependencies in F contain only attributes from
(A,C,D,E) so we might be mislead into thinking R2 satises
BCNF. !
! In fact, dependency AC D in F+ shows R2 is not in BCNF. !
CS425 Fall 2013 Boris Glavic!
8.63!
! If
! We
8.64!
8.65!
8.66!
F = {A B
! B C}
Key = {A}!
R is not in BCNF (B C but B is not superkey)!
Decomposition!
R1 = (B, C)!
R2 = (A,B)!
8.67!
! class-1
8.68!
! section
8.69!
F = {JK L
! L K }
Two candidate keys = JK and JL!
R is not in BCNF!
Any decomposition of R will fail to preserve!
!JK L!
8.70!
sufciently normalized !
Consider a relation !
where an instructor may have more than one phone and can have
multiple children!
!
!
ID!
99999!
99999!
99999!
99999!
child_name!
phone!
512-555-1234!
512-555-4321!
512-555-1234!
512-555-4321!
David!
David!
William!
Willian!
inst_info!
8.71!
relation is in BCNF !
Insertion anomalies i.e., if we add a phone 981-992-3443 to 99999,
8.72!
ID!
inst_child!
inst_phone!
99999!
99999!
99999!
99999!
child_name!
David!
David!
William!
Willian!
ID!
phone!
99999!
99999!
99999!
99999!
512-555-1234!
512-555-4321!
512-555-1234!
512-555-4321!
This suggests the need for higher normal forms, such as Fourth
Normal Form (4NF), which we shall see later.!
CS425 Fall 2013 Boris Glavic!
8.73!
8.74!
atomic attributes!
2NF!
3NF!
BCNF!
8.75!
BCNF.!
Lossless join.!
Dependency preservation.!
8.76!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Multivalued Dependencies!
Suppose we record names of children, and phone numbers for
instructors:!
inst_child(ID, child_name)!
inst_phone(ID, phone_number)!
Example data:
(99999, David, 512-555-1234)
(99999, David, 512-555-4321)
(99999, William, 512-555-1234)
(99999, William, 512-555-4321)!
Why?!
8.78!
multivalued dependency !
!
! !
!holds on R if in any legal relation r(R), for all pairs for tuples t1 and t2
in r such that t1[] = t2 [], there exist tuples t3 and t4 in r such that: !
!
! t1[] = t2 [] = t3 [] = t4 []
! t3[]
= t1 []
! t3[R ] = t2[R ]
! t4 []
= t2[]
! t4[R ] = t1[R ]
8.79!
MVD (Cont.)!
Tabular representation of !
8.80!
Example!
Let R be a relation schema with a set of attributes that are partitioned
!Y, Z, W!
!then!
!
Note that since the behavior of Z and W are identical it follows that !
!Y Z if Y W !
!
8.81!
Example (Cont.)!
In our example:!
!ID child_name !
!ID phone_number!
The above formal denition is supposed to formalize the notion that given
If Y Z then Y Z!
8.82!
!!
8.83!
Theory of MVDs!
From the denition of multivalued dependency, we can derive the
following rule:!
If , then !
8.84!
8.85!
8.86!
8.87!
Example!
R =(A, B, C, G, H, I)!
!F ={ A B!
!
!B HI!
!
!CG H }!
R is not in 4NF since A B and A is not a superkey for R!
Decomposition!
!a) R1 = (A, B) !
!
!(R1 is in 4NF)!
!b) R2 = (A, C, G, H, I) !
!(R2 is not in 4NF, decompose into R3 and R4)!
!c) R3 = (C, G, H)
!
!(R3 is in 4NF)!
!d) R4 = (A, C, G, I)
!
!(R4 is not in 4NF, decompose into R5 and R6)!
A B and B HI A HI, (MVD transitivity), and!
and hence A I (MVD restriction to R4)!
!e) R5 = (A, I) !
!
!(R5 is in 4NF)!
!f)R6 = (A, C, G)
!
!(R6 is in 4NF)!
8.88!
8.89!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
R could have been a single relation containing all attributes that are
of interest (called universal relation).!
8.91!
correctly, the tables generated from the ER diagram should not need
further normalization.!
However, in a real (imperfect) design, there can be functional
8.92!
faster lookup!
extra coding work for programmer and possibility of error in extra code!
course
prereq!
8.93!
! Is
! Used
8.94!
Recap!
Functional and Multi-valued Dependencies!
Axioms!
Closure!
Minimal Cover!
Attribute Closure!
Redundancy and lossless decomposition!
Normal-Forms!
1NF, 2NF, 3NF!
BCNF!
4NF, 5NF!
!!
8.95!
End of Chapter!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
8.98!
separately.!
8.99!
8.100!
Q.E.D.!
8.101!
Figure 8.02!
8.102!
Figure 8.03!
8.103!
Figure 8.04!
8.104!
Figure 8.05!
8.105!
Figure 8.06!
8.106!
Figure 8.14!
8.107!
Figure 8.15!
8.108!
Figure 8.17!
8.109!
Chapter 9: Transactions!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Chapter 9: Transactions!
Transaction Concept!
Transaction State!
Concurrent Executions!
Serializability!
Recoverability!
Implementation of Isolation!
Transaction Denition in SQL!
Testing for Serializability.!
9.2!
Transaction Concept!
A transaction is a unit of program execution that accesses and
9.3!
Atomicity requirement !
if the transaction fails after step 3 and before step 6, money will be lost
leading to an inconsistent database state!
!
Durability requirement once the user has been notied that the transaction
has completed (i.e., the transfer of the $50 has taken place), the updates to the
database by the transaction must persist even if there are software or
hardware failures.!
9.4!
9.5!
4. !read(B)!
5. !B := B + 50!
6. !write(B!
9.6!
ACID Properties!
A transaction is a unit of program execution that accesses and possibly
updates various data items.To preserve the integrity of data the database
system must ensure:!
Atomicity. Either all operations of the transaction are properly reected
That is, for every pair of transactions Ti and Tj, it appears to Ti that
either Tj, nished execution before Ti started, or Tj started execution
after Ti nished.!
has made to the database persist, even if there are system failures. !
9.7!
Transaction State!
Active the initial state; the transaction stays in this state while it is
executing!
Partially committed after the nal statement has been executed.!
Failed -- after the discovery that normal execution can no longer
proceed.!
Aborted after the transaction has been rolled back and the
9.8!
Transaction Model!
Operations!
Data Items!
9.9!
commi!ed
failed
aborted
active
9.10!
Concurrent Executions!
Multiple transactions are allowed to run concurrently in the system.
Advantages are:!
! In
9.11!
Schedules!
Schedule a sequences of instructions that specify the chronological
9.12!
Schedule 1!
Let T1 transfer $50 from A to B, and T2 transfer 10% of the
balance from A to B. !
A serial schedule in which T1 is followed by T2 :!
!
!!
T1
T2
read (A)
A := A 50
write (A)
read (B)
B := B + 50
write (B)
commit
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + temp
write (B)
commit
CS425 Fall 2013 Boris Glavic!
9.13!
Schedule 2!
A serial schedule where T2 is followed by T1!
T1
T2
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + temp
write (B)
commit
read (A)
A := A 50
write (A)
read (B)
B := B + 50
write (B)
commit
CS425 Fall 2013 Boris Glavic!
9.14!
Schedule 3!
Let T1 and T2 be the transactions dened previously. The
!!
T1
T2
read (A)
A := A 50
write (A)
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + 50
write (B)
commit
read (B)
B := B + temp
write (B)
commit
9.15!
Schedule 4!
The following concurrent schedule does not preserve the
value of (A + B ).
!!
T1
T2
read (A)
A := A 50
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
write (A)
read (B)
B := B + 50
write (B)
commit
B := B + temp
write (B)
commit
CS425 Fall 2013 Boris Glavic!
9.16!
Serializability!
Basic Assumption Each transaction preserves database
consistency.!
Thus serial execution of a set of transactions preserves
database consistency.!
A (possibly concurrent) schedule is serializable if it is
9.17!
9.18!
Conicting Instructions!
Instructions li and lj of transactions Ti and Tj respectively, conict
if and only if there exists some item Q accessed by both li and lj,
and at least one of these instructions wrote Q.!
! 1. li = read(Q), lj = read(Q).
2. li = read(Q), lj = write(Q).
3. li = write(Q), lj = read(Q).
4. li = write(Q), lj = write(Q).
9.19!
Conict Serializability!
If a schedule S can be transformed into a schedule S by a series of
9.20!
schedule where T2 follows T1, by series of swaps of nonconicting instructions. Therefore Schedule 3 is conict
serializable.!
T1
T2
T1
read (A)
write (A)
read (A)
write (A)
read (B)
write (B)
read (A)
write (A)
read (A)
write (A)
read (B)
write (B)
read (B)
write (B)
read (B)
write (B)
Schedule 3!
T2
Schedule 6!
9.21!
T3
T4
read (Q)
write (Q)
write (Q)
obtain either the serial schedule < T3, T4 >, or the serial
schedule < T4, T3 >.!
9.22!
View Serializability!
Let S and S be two schedules with the same set of transactions. S
and S are view equivalent if the following three conditions are met,
for each data item Q, !
1.
2.
3.
The transaction (if any) that performs the nal write(Q) operation
in schedule S must also perform the nal write(Q) operation in
schedule S.!
9.23!
schedule.!
Every conict serializable schedule is also view serializable.!
Below is a schedule which is view-serializable but not conict
serializable.
!
!
T!!27
T28
T29
read (Q)
write (Q)
write (Q)
write (Q)
What serial schedule is above equivalent to?!
Every view serializable schedule that is not conict serializable has
blind writes.!
9.24!
!!
T1
T5
read (A)
A := A 50
write (A)
read (B)
B := B 10
write (B)
read (B)
B := B + 50
write (B)
!
!
read (A)
A := A + 10
write (A)
9.25!
T1
T2
9.26!
Ti
Tm
there others?!
9.27!
Tk
Tj
(a)
Ti
Ti
Tj
Tk
Tk
Tj
Tm
Tm
(b)
(c)
Silberschatz, Korth and Sudarshan!
9.28!
Recoverable Schedules!
Need to address the effect of transaction failures on concurrently
running transactions.!
Recoverable schedule if a transaction Tj reads a data item
T8
T9
read (A)
write (A)
read (A)
commit
read (B)
If T8 should abort, T9 would have read (and possibly shown to the user)
9.29!
Cascading Rollbacks!
Cascading rollback a single transaction failure leads to a
T10
T11
T12
read (A)
read (B)
write (A)
read (A)
write (A)
read (A)
abort
9.30!
Cascadeless Schedules!
Cascadeless schedules cascading rollbacks cannot occur; for
9.31!
Concurrency Control!
A database must provide a mechanism that will ensure that all possible
schedules are !
late!!
Goal to develop concurrency control protocols that will assure
serializability.!
9.32!
9.33!
protocol is correct. !
9.34!
9.35!
schedules by default!
9.36!
in JDBC,
connection.setAutoCommit(false);!
9.37!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Recap!
Transactions!
ACID Properties!
Schedules!
Serial!
Equivalence!
! Conict-equivalent!
! View-equivalent!
Serializability!
! =
Recoverable!
Cascading Aborts!
Transactions in SQL!
9.39!
Figure 14.01!
partially
commi!ed
commi!ed
failed
aborted
active
9.40!
Figure 14.02!
T1
T2
read (A)
A := A 50
write (A)
read (B)
B := B + 50
write (B)
commit
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + temp
write (B)
commit
9.41!
Figure 14.03!
T1
T2
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + temp
write (B)
commit
read (A)
A := A 50
write (A)
read (B)
B := B + 50
write (B)
commit
9.42!
Figure 14.04!
T1
T2
read (A)
A := A 50
write (A)
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B + 50
write (B)
commit
read (B)
B := B + temp
write (B)
commit
9.43!
Figure 14.05!
T1
T2
read (A)
A := A 50
read (A)
temp := A * 0.1
A := A temp
write (A)
read (B)
write (A)
read (B)
B := B + 50
write (B)
commit
B := B + temp
write (B)
commit
9.44!
Figure 14.06!
T1
T2
read (A)
write (A)
read (A)
write (A)
read (B)
write (B)
read (B)
write (B)
9.45!
Figure 14.07!
T1
T2
read (A)
write (A)
read (A)
read (B)
write (A)
write (B)
read (B)
write (B)
9.46!
Figure 14.08!
T1
T2
read (A)
write (A)
read (B)
write (B)
read (A)
write (A)
read (B)
write (B)
9.47!
Figure 14.09!
T3
T4
read (Q)
write (Q)
write (Q)
9.48!
Figure 14.10!
T1
T2
T2
(a)
T1
(b)
9.49!
Figure 14.11!
T1
T2
9.50!
Figure 14.12!
Ti
Tk
Tj
Tm
(a)
Ti
Ti
Tj
Tk
Tk
Tj
Tm
Tm
(b)
(c)
9.51!
Figure 14.13!
T1
T5
read (A)
A := A 50
write (A)
read (B)
B := B 10
write (B)
read (B)
B := B + 50
write (B)
read (A)
A := A + 10
write (A)
9.52!
Figure 14.14!
T8
T9
read (A)
write (A)
read (A)
commit
read (B)
9.53!
Figure 14.15!
T10
T11
T12
read (A)
read (B)
write (A)
read (A)
write (A)
read (A)
abort
9.54!
Figure 14.16!
T1
T2
T4
T3
T5
9.55!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
10.2!
10.3!
Lock-Based Protocols!
A lock is a mechanism to control concurrent access to a data item!
Data items can be locked in two modes :!
Transactions release their locks on a data item only after they have
accessed a data item!
10.4!
true
false
false
false
!
A transaction may be granted a lock on an item if the requested lock is
10.5!
T2: lock-S(A);!
read (A);!
unlock(A);!
lock-S(B);!
read (B);!
unlock(B);!
display(A+B)!
Locking as above is not sufcient to guarantee serializability if A and B
get updated in-between the read of A and B, the displayed sum would be
wrong.!
A locking protocol is a set of rules followed by all transactions while
10.6!
!
Neither T3 nor T4 can make progress executing lock-S(B) causes T4
10.7!
10.8!
10.9!
10.10!
10.11!
Lock Conversions!
Two-phase locking with lock conversions:!
First Phase:
Second Phase:!
10.12!
if Ti has a lock on D!
then!
read(D) !
else begin !
if necessary wait until no other !
transaction has a lock-X on D!
grant Ti a lock-S on D;!
read(D)!
end!
10.13!
if Ti has a lock-X on D !
then !
write(D)!
else begin!
if necessary wait until no other trans. has any lock on D,!
if Ti has a lock-S on D!
then!
upgrade lock on D to lock-X!
else!
grant Ti a lock-X on D!
write(D)!
end;!
All locks are released after commit or abort!
10.14!
Implementation of Locking!
A lock manager can be implemented as a separate process to which
10.15!
Lock Table!
17
123
T1
T8
T2
granted or requested!
New request is added to the end of the
1912
T23
14
T23
144
granted
waiting
T8
CS425 Fall 2013 Boris Glavic!
10.16!
Graph-Based Protocols!
Graph-based protocols are an alternative to two-phase locking!
Impose a partial ordering on the set D = {d1, d2 ,..., dh} of all data
items.!
10.17!
Tree Protocol!
A
C
B
F
D
G
E
H
subsequently be relocked by Ti !
CS425 Fall 2013 Boris Glavic!
10.18!
deadlock.!
Unlocking may occur earlier in the tree-locking protocol than in the twophase locking protocol.!
shorter waiting times, and increase in concurrency!
protocol is deadlock-free, no rollbacks are required!
Drawbacks!
Protocol does not guarantee recoverability or cascade freedom!
! Need
10.19!
Deadlock Handling!
Consider the following two transactions:!
T1:
write (X)
write(Y)
T2:
write(Y)!
write(X)!
10.20!
Deadlock Handling!
System is deadlocked if there is a set of transactions such that every
Require that each transaction locks all its data items before it
begins execution (predeclaration).!
10.21!
prevention alone.!
wait-die scheme non-preemptive!
older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.!
10.22!
10.23!
Deadlock Detection!
Deadlocks can be described as a wait-for graph, which consists of a
pair G = (V,E), !
10.24!
T18
T20
T18
T17
T20
T17
T19
T19
Wait-for graph with a cycle!
10.25!
Deadlock Recovery!
When deadlock is detected :!
! More
10.26!
Multiple Granularity!
Allow data items to be of various sizes and dene a hierarchy of data
locking protocol)!
When a transaction locks a node in the tree explicitly, it implicitly locks
10.27!
Fa
ra 1
ra2
ran
A1
A2
Fb
Fc
rb1
rb k
rc1
rc
le!
record !
10.28!
10.29!
IS
IX
IS
true
true
true
true
false
IX
true
true
false
false
false
true
false
true
false
false
SIX
true
false
false
false
false
false
false
false
false
false
10.30!
SIX
2.
The root of the tree must be locked rst, and may be locked in any
mode.!
5.
Ti can lock a node only if it has not previously unlocked any node
(that is, Ti is two-phase).!
10.31!
Timestamp-Based Protocols!
Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned timestamp TS(Tj) such that TS(Ti) <TS(Tj). !
The protocol manages concurrent execution such that the time-stamps
timestamp values:!
10.32!
2.
10.33!
2.
3.
10.34!
10.35!
10.36!
This can lead to cascading rollback --- that is, a chain of rollbacks !
Solution 1:!
A transaction is structured such that its writes are all performed at
the end of its processing!
All writes of a transaction form an atomic action; no transaction may
execute while a transaction is being written!
10.37!
protocol.!
Thomas' Write Rule allows greater potential concurrency. !
10.38!
Validation-Based Protocol!
Execution of transaction Ti is done in three phases.!
Assume for simplicity that the validation and write phase occur
together, atomically and serially!
! I.e.,
executes fully in the hope that all will go well during validation!
10.39!
10.40!
holds:!
start(Tj) < nish(Ti) < validation(Tj) and the set of data items
written by Ti does not intersect with the set of data items read by
Tj. !
10.41!
10.42!
Multiversion Schemes!
Multiversion schemes keep old versions of data item to increase
concurrency.!
immediately.!
10.43!
10.44!
2.
2.
3.
Observe that!
10.45!
to the end of the transaction. That is, update transactions follow rigorous
two-phase locking.!
10.46!
it obtains X lock on; it then creates a new version of the item and
sets this version's timestamp to .!
Ti increments ts-counter by 1!
10.47!
Extra tuples!
E.g. if Q has two versions Q5 and Q9, and the oldest active
transaction has timestamp > 9, than Q5 will never be required
again!
10.48!
Snapshot Isolation!
Motivation: Decision support queries that read large amounts of data
! Variants
10.49!
Snapshot Isolation!
A transaction T1 executing with Snapshot
Isolation!
T1!
T2!
T3!
W(Y := 1)!
Commit!
Start!
R(Y) 1!
W(X:=2)!
First-committer-wins rule:!
W(Z:=3)!
10.50!
R(X) 0!
Commit!
R(Z) 0!
R(Y) 1!
W(X:=3)!
Commit-Req!
Abort!
Snapshot Read
Concurrent updates invisible to snapshot read!
10.51!
Variant: First-updater-wins !
! Check for concurrent updates when write occurs by locking item!
But lock should be held till all concurrent transactions have nished!
! (Oracle uses this plus some extra features)!
! Differs only in when abort occurs, otherwise equivalent !
10.52!
Benets of SI!
Reading is never blocked, !
10.53!
Snapshot Isolation!
E.g. of problem with SI!
T1: x:=y!
T2: y:= x!
! if
E.g:!
! Find
! Create
10.54!
when txns conict due to modifying different data, there is usually also
a shared item they both modify too (like a total quantity) so SI will abort
one of them!
We omit details!
inconsistency!
10.55!
10.56!
and PostgreSQL!
E.g., !
1.
2.
3.
Select for update (SFU) treats all data read by the query as if it were
also updated, preventing concurrent updates!
In PostgreSQL versions < 9.1, SFU locks the data item, but releases locks
Not quite same as SFU in Oracle, which keeps locks until all!
10.57!
10.58!
One solution: !
10.59!
A transaction can access tuples only after nding them through one or
more indices on the relation!
A transaction Ti that performs a lookup must lock all the index leaf
nodes that it accesses, in S-mode!
! Even
if the leaf node does not contain any tuple satisfying the index
lookup (e.g. for a range query, no tuple in a leaf is in the range)!
! must
10.60!
Next-Key Locking!
Index-locking protocol to prevent phantoms required locking entire leaf!
Lock all values that satisfy index lookup (match lookup value, or
fall in lookup range)!
10.61!
accessing data.!
Index-structures are typically accessed very often, much more than
10.62!
After locking all required children of a node in shared mode, release the lock
on the node.!
Searches coming down the tree deadlock with updates going up the tree!
Better protocols are available; see Section 16.9 for one such protocol, the B-link
tree protocol!
And deal with changes that may have happened between lock release
and acquire!
10.63!
may be released at any time, and locks may be acquired at any time!
Cursor stability: !
10.64!
! However,
! set
10.65!
snapshot isolation!
Unlike SI, reads are not guaranteed to be from a single snapshot!
10.66!
End of Chapter!
Thanks to Alan Fekete and Sudhir Jorwekar for Snapshot
Isolation examples!
modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Figure 15.01!
true
false
false
false
10.68!
Figure 15.04!
10.69!
Figure 15.07!
10.70!
Figure 15.08!
10.71!
Figure 15.09!
10.72!
Figure 15.10!
17
123
T23
T1
T8
T2
1912
T23
14
T1
T23
144
granted
waiting
T8
CS425 Fall 2013 Boris Glavic!
10.73!
Figure 15.11!
A
C
B
F
D
G
E
H
10.74!
Figure 15.12!
10.75!
Figure 15.13!
T18
T20
T17
T19
10.76!
Figure 15.14!
T18
T20
T17
T19
10.77!
Figure 15.15!
DB
Fa
ra 1
ra2
ran
A1
A2
Fb
Fc
rb1
rb k
10.78!
rc1
rc
Figure 15.16!
IS
IX
IS
true
true
true
true
false
IX
true
true
false
false
false
true
false
true
false
false
SIX
true
false
false
false
false
false
false
false
false
false
10.79!
SIX
Figure 15.17!
10.80!
Figure 15.18!
10.81!
Figure 15.19!
10.82!
Figure 15.20!
10.83!
Figure 15.21!
History
Music
Elec. Eng.
Biology
Comp. Sci.
Elec. Eng.
History
Finance
10.84!
Music
Physics
Figure 15.22!
History
Comp. Sci.
Biology
Chemistry
Comp. Sci.
Music
Elec. Eng.
Elec. Eng.
Finance
10.85!
History
Music
Physics
Figure 15.23!
true
false
false
false
false
false
false
false
true
10.86!
Figure in-15.1!
T27
T28
T29
read (Q)
write (Q)
write (Q)
write (Q)
10.87!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Memory hierarchy!
File Organization!
Buffering!
Indexing!
Basic Concepts!
B+-Trees!
Static Hashing!
Multiple-Key Access!
11.2!
Memory Hierarchy!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
DBMS Storage!
Modern Computers have different types of memory!
Size!
types effectively!
shutdown!
! Need
11.4!
Storage Hierarchy!
Persistent!
storage!
cache
flash memory
magnetic disk
Speed!
Size!
main memory
optical disk
magnetic tapes
CS425 Fall 2013 Boris Glavic!
11.5!
11.6!
track t
arm assembly
sector s
readwrite
head
cylinder c
platter
arm
rotation
NOTE: Diagram is schematic, and simplies the structure of actual disk drives!
CS425 Fall 2013 Boris Glavic!
11.7!
11.8!
Random Access!
Need to wait until the right sector is under the arm (on avg time
for one rotation) (rotational delay)!
Sequential Access!
11.9!
File Organization!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
File Organization!
The database is stored as a collection of les. Each le stores
(random access)!
One approach:!
assume
each
different
11.11!
Fixed-Length Records!
Simple approach:!
!
Deletion of record i:
alternatives:"
move records i + 1, . . ., n
to i, . . . , n 1!
move record n to i!
record 0
record 1
record 2
record 3
record 4
record 5
record 6
record 7
record 8
record 9
record 10
record 11
11.12!
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
65000
90000
40000
95000
60000
87000
75000
62000
80000
72000
92000
80000
Free Lists!
Store the address of the rst deleted record in the le header.!
Use this rst record to store the address of the second deleted record,
and so on!
Can think of these stored addresses as pointers since they point to
header
record 0
record 1
record 2
record 3
record 4
record 5
record 6
record 7
record 8
record 9
record 10
record 11
CS425 Fall 2013 Boris Glavic!
10101
Srinivasan
Comp. Sci.
65000
15151
22222
Mozart
Einstein
Music
Physics
40000
95000
33456
Gold
Physics
87000
58583
76543
76766
83821
98345
Califieri
Singh
Crick
Brandt
Kim
History
Finance
Biology
Comp. Sci.
Elec. Eng.
62000
80000
72000
92000
80000
11.13!
Variable-Length Records!
Variable-length records arise in database systems in several ways:!
Record types that allow variable lengths for one or more elds such as
strings (varchar)!
Record types that allow repeating elds (used in some older data
models).!
Records
Free Space
11.15!
is space!
Deletion efcient!
Insertion efcient!
Search is expensive!
! Example:
11.16!
Buffering!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Buffer Manager!
Buffer Manager!
Handling blocks!
1.
2.
2.
Reads the block from the disk to the buffer, and returns
the address of the block in main memory to requester. !
11.18!
Buffer-Replacement Policies!
Most operating systems replace the block least recently used
(LRU strategy)!
Idea behind LRU use past pattern of block references as a
11.19!
block currently being processed. After the nal tuple of that block
has been processed, the block is unpinned, and it becomes the
most recently used block.!
Buffer manager can use statistical information regarding the
11.20!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Basic Concepts!
Indexing mechanisms used to speed up access to desired data.!
le.!
An index le consists of records (called index entries) of the form
search-key!
pointer!
11.22!
Access time!
Insertion time!
Deletion time!
Space overhead!
11.23!
Ordered Indices!
In an ordered index, index entries are stored sorted on the search key
The search key of a primary index is usually but not necessarily the
primary key.!
11.24!
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
65000
90000
40000
95000
60000
87000
75000
62000
80000
72000
92000
80000
11.25!
11.26!
Multilevel Index!
If primary index does not t in memory, access becomes
expensive.!
Solution: treat primary index kept on disk as a sequential le
11.27!
data
block 0
data
block 1
outer index
index
block 1
11.28!
inner index
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
65000
90000
40000
95000
60000
87000
75000
62000
80000
72000
92000
80000
Sparse indices !
!
! If
11.29!
11.30!
Secondary Indices!
Frequently, one wants to nd all the records whose values in
11.31!
B+-Tree Index!
B+-tree indices are an alternative to indexed-sequential les.!
Disadvantage of indexed-sequential les!
11.32!
Example of B+-Tree!
Root node
Mozart
Einstein
Internal nodes
Srinivasan
Gold
Leaf nodes
Brandt Califieri
Crick
Einstein
El Said
Gold
Katz
Kim
Mozart
Singh
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
11.33!
Srinivasan
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Wu
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
65000
90000
40000
95000
80000
87000
75000
60000
80000
72000
92000
80000
n children.!
A leaf node has between (n1)/2 and n1 values!
Special cases: !
11.34!
P1
K1
P2
Pn-1
Kn-1
Pn
11.35!
Brandt
Califieri
Crick
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
CS425 Fall 2013 Boris Glavic!
11.36!
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
65000
90000
40000
95000
80000
87000
75000
60000
80000
72000
92000
80000
P1
K1
P2
11.37!
Pn-1
Kn-1
Pn
Example of B+-tree!
Brandt
Califieri
Crick
Einstein
El Said
Mozart
El Said
Gold
Katz
Kim
Mozart
Singh
Srinivasan
Wu
11.38!
indices.!
The B+-tree contains a relatively small number of levels!
! Level
! Next
! ..
etc.!
11.39!
Queries on B+-Trees!
Find record with search-key value V."
1.
2.
3.
4.
5.
C=root"
While C is not a leaf node {!
1. Let i be least value s.t. V Ki.!
2. If no such exists, set C = last non-null pointer in C !
3. Else { if (V= Ki ) Set C = Pi +1 else set C = Pi}!
}!
Let i be least value s.t. Ki = V"
If there is such a value i, follow pointer Pi to the desired record.!
Else no record with search-key value k exists.!
Mozart
Adams
Brandt
Califieri
Crick
Srinivasan
Einstein
El Said
Gold
11.40!
Katz
Kim
Mozart
Singh
Srinivasan Wu
Handling Duplicates!
With duplicate search keys!
11.41!
Handling Duplicates!
We modify nd procedure as follows !
traverse
Pi even if V = Ki!
As
Procedure printAll!
uses
Traverse
11.42!
kilobytes!
Contrast this with a balanced binary tree with 1 million search key
11.43!
2.
2.
3.
11.44!
let the new node be p, and let k be the least key value in p. Insert
(k,p) in the parent of the node being split. !
If the parent is full, split it and propagate the split further up.!
Splitting of nodes proceeds upwards till a node that is not full is found. !
In the worst case the root node may be split increasing the height
of the tree by 1. !
Adams Brandt
Califieri
Crick
Result of splitting node containing Brandt, Calieri and Crick on inserting Adams!
Next step: insert entry with (Calieri,pointer-to-new-node) into parent!
CS425 Fall 2013 Boris Glavic!
11.45!
B+-Tree Insertion!
Root node
Mozart
Einstein
Internal nodes
Srinivasan
Gold
Leaf nodes
Brandt Califieri
Crick
Einstein
Gold
El Said
Katz
Kim
Mozart
Singh
Srinivasan
Wu
Mozart
Adams
Brandt
Califieri
Crick
Srinivasan
Einstein
El Said
Gold
Katz
Kim
Mozart
Singh
Srinivasan Wu
11.46!
B+-Tree Insertion!
Mozart
Adams
Brandt
Califieri
Crick
Srinivasan
Einstein
El Said
Gold
Califieri
Adams
Brandt
Califieri
Crick
Einstein
Einstein
Gold
Katz
Kim
Gold
Singh
Srinivasan Wu
Mozart
Srinivasan
Kim
El Said
Mozart
Katz
Kim
Lamport
Mozart
Singh
Srinivasan
Wu
11.47!
internal node N!
Calieri!
Adams Brandt!
11.48!
Crick!
Adams
Brandt
Califieri
Crick
Srinivasan
Einstein
El Said
Gold
Katz
Kim
Mozart
Singh
Srinivasan Wu
Califieri
Adams
Brandt
Califieri
Einstein
Crick
Mozart
Einstein
El Said
Gold
Katz
Kim
Mozart
Singh
Wu
11.49!
Califieri
Adams
Brandt
Califieri
Einstein
Crick
Kim
Einstein
El Said
Gold
Katz
Kim
Mozart
11.50!
Califieri
Adams
Brandt
Califieri
Einstein
Kim
Crick
Einstein
Califieri
Adams
Brandt
Califieri
El Said
Gold
Katz
Kim
Mozart
Einstein Gold
Einstein
Crick
El Said
Katz
Kim Mozart
Value separating two nodes (at the parent) is pulled down when merging!
Root node then has only one child, and is deleted!
11.51!
the node and a sibling t into a single node, then merge siblings:!
Insert all the search-key values in the two nodes into a single node
(the one on the left), and delete the other node.!
Delete the pair (Ki1, Pi), where Pi is the pointer to the deleted
node, from its parent, recursively using the above procedure.!
11.52!
entries in the node and a sibling do not t into a single node, then
redistribute pointers:!
Redistribute the pointers between the node and a sibling such that
both have more than the minimum number of entries.!
The node deletions may cascade upwards till a node which has n/2
11.53!
! Deletion
! Low
! Simpler
! Widely
used!
11.54!
Organization.!
The leaf nodes in a B+-tree le organization store records, instead of
pointers.!
Leaf nodes are still required to be half full!
Insertion and deletion are handled in the same way as insertion and
11.55!
pointers. !
To improve space utilization, involve more sibling nodes in redistribution
!
CS425 Fall 2013 Boris Glavic!
11.56!
Hashing!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Static Hashing!
A bucket is a unit of storage containing one or more records (a
as deletion.!
Records with different search-key values may be mapped to the
11.58!
integer i.!
The hash function returns the sum of the binary representations of
E.g. h(Music) = 1
h(History) = 2
h(Physics) = 3 h(Elec. Eng.) = 3!
11.59!
bucket 4
12121 Wu
76543 Singh
bucket 1
15151 Mozart
Music
40000
History
80000
58583 Califieri
History
60000
98345 Kim
Finance
90000
80000
Biology
72000
bucket 5
bucket 2
32343 El Said
bucket 3
22222 Einstein
33456 Gold
Finance
76766 Crick
bucket 6
10101 Srinivasan Comp. Sci. 65000
45565 Katz
Comp. Sci. 75000
83821 Brandt
Comp. Sci. 92000
bucket 7
Physics 95000
Physics 87000
Elec. Eng. 80000
11.60!
Hash Functions!
Worst hash function maps all search-key values to the same bucket;
same number of search-key values from the set of all possible values.!
Ideal hash function is random, so each bucket will have the same
11.61!
Insufcient buckets !
! chosen
values!
Although the probability of bucket overow can be reduced, it cannot
11.62!
bucket 1
bucket 3
11.63!
Hash Indices!
Hashing can be used not only for le organization, but also for index-
structure creation. !
A hash index organizes the search keys, with their associated record
11.64!
bucket 5
15151
33456
58583
98345
76766
10101
45565
83821
98345
12121
76543
32343
58583
15151
22222
33465
Crick
Srinivasan
Katz
Brandt
Kim
Wu
Singh
El Said
Califieri
Mozart
Einstein
Gold
Biology
Comp. Sci.
Comp. Sci.
Comp. Sci.
Elec. Eng.
Finance
Finance
History
History
Music
Physics
Physics
72000
65000
75000
92000
80000
90000
80000
60000
62000
40000
95000
87000
bucket 6
83821
11.65!
function!
11.66!
To drop an index !
clustering.!
11.67!
End of Chapter!
Modied from:!
Database System Concepts, 6th Ed.!
Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use !
Figure 11.01!
10101
12121
15151
22222
32343
33456
45565
58583
76543
76766
83821
98345
Srinivasan
Wu
Mozart
Einstein
El Said
Gold
Katz
Califieri
Singh
Crick
Brandt
Kim
Comp. Sci.
Finance
Music
Physics
History
Physics
Comp. Sci.
History
Finance
Biology
Comp. Sci.
Elec. Eng.
11.69!
65000
90000
40000
95000
60000
87000
75000
62000
80000
72000
92000
80000
Figure 11.15!
11.70!
Partitioned Hashing!
Hash values are split into segments that depend on each
(customer-street, customer-city)!
!
!search-key value
"(Main, Harrison)
!(Main, Brooklyn)
!(Park, Palo Alto)
!(Spring, Brooklyn)
!(Alma, Palo Alto)
"hash value
!101 111
!101 001
!010 010
!001 001
!110 010!
11.71!
Grid Files!
Structure used to speed the processing of general multiple search-
11.72!
11.73!
(a1 A a2)!
(b1 B b2)!
(a1 A a2 b1 B b2),.!
corresponding candidate grid array cells, and look up all the buckets
pointed to from those cells.!
11.74!
cells. !
11.75!