Data Base Lesson 2

Chapter 2: Relational Model
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.dbbook.com for conditions on reuse
Chapter 2: Relational Model
■ Structure of Relational Databases
■ Fundamental RelationalAlgebraOperations
■ Additional RelationalAlgebraOperations
■ Extended RelationalAlgebraOperations
■ Null Values
■ Modification of the Database
Database System Concepts 5th Edition, Oct 5, 2006 2.2 ©Silberschatz, Korth and Sudarshan

Example of a Relation

Basic Structure
■ Formally, given sets D1, D2, …. Dn a relation r is a subset of
D1 x D2 x … x Dn
Thus, a relation is a set of ntuples (a1, a2, …, an) where each ai ∈ Di
■ Example: If
● customer_name = {Jones, Smith, Curry, Lindsay, …}
/* Set of all customer names */
● customer_street = {Main, North, Park, …} /* set of all street names*/
● customer_city = {Harrison, Rye, Pittsfield, …} /* set of all city names */
Then r = { (Jones, Main, Harrison),
(Smith, North, Rye),
(Curry, North, Rye),
(Lindsay, Park, Pittsfield) }
is a relation over
customer_name x customer_street x customer_city
Attribute Types
■ Each attribute of a relation has a name
■ The set of allowed values for each attribute is called the domain of the
attribute
■ Attribute values are (normally) required to be atomic; that is, indivisible
● E.g. the value of an attribute can be an account number,
but cannot be a set of account numbers
■ Domain is said to be atomic if all its members are atomic
■ The special value null is a member of every domain
■ The null value causes complications in the definition of many operations
● We shall ignore the effect of null values in our main presentation and
consider their effect later

Relation Schema
■ A1, A2, …, An are attributes
■ R = (A1, A2, …, An ) is a relation schema
Example:
Customer_schema = (customer_name, customer_street, customer_city)
■ r(R) denotes a relation r on the relation schema R
Example:
customer (Customer_schema)

Relation Instance
■ The current values (relation instance) of a relation are specified by a
table
■ An element t of r is a tuple, represented by a row in a table
attributes
(or columns)
customer_name customer_street customer_city
Jones Main Harrison

Smith North Rye tuples
Curry North Rye (or rows)
Lindsay Park Pittsfield
customer

Relations are Unordered
■ Order of tuples is irrelevant (tuples may be stored in an arbitrary order)
■ Example: account relation with unordered tuples

Database
■ A database consists of multiple relations
■ Information about an enterprise is broken up into parts, with each relation
storing one part of the information
account : stores information about accounts
depositor : stores information about which customer
owns which account
customer : stores information about customers
■ Storing all information as a single relation such as
bank(account_number, balance, customer_name, ..)
results in
● repetition of information
 e.g.,if two customers own an account (What gets repeated?)
● the need for null values
 e.g., to represent a customer without an account
■ Normalization theory (Chapter 7) deals with how to design relational schemas

The customer Relation

The depositor Relation

Keys
■ Let K ⊆ R
■ K is a superkey of R if values for K are sufficient to identify a unique tuple of
each possible relation r(R)
● by “possible r ” we mean a relation r that could exist in the enterprise we
are modeling.
● Example: {customer_name, customer_street} and
{customer_name}
are both superkeys of Customer, if no two customers can possibly have
the same name
 In real life, an attribute such as customer_id would be used instead of
customer_name to uniquely identify customers, but we omit it to keep
our examples small, and instead assume customer names are unique.

Keys (Cont.)
■ K is a candidate key if K is minimal
Example: {customer_name} is a candidate key for Customer, since it
is a superkey and no subset of it is a superkey.
■ Primary key: a candidate key chosen as the principal means of
identifying tuples within a relation
● Should choose an attribute whose value never, or very rarely,
changes.
● E.g. email address is unique, but may change

Foreign Keys
■ A relation schema may have an attribute that corresponds to the primary
key of another relation. The attribute is called a foreign key.
● E.g. customer_name and account_number attributes of depositor are
foreign keys to customer and account respectively.
● Only values occurring in the primary key attribute of the referenced
relation may occur in the foreign key attribute of the referencing
relation.
■ Schema diagram

Query Languages
■ Language in which user requests information from the database.
■ Categories of languages
● Procedural
● Nonprocedural, or declarative
■ “Pure” languages:
● Relational algebra
● Tuple relational calculus
● Domain relational calculus
■ Pure languages form underlying basis of query languages that people
use.

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.

Select Operation – Example
■ Relation r
A B C D
α α 1 7
α β 5 7
β β 12 3
β β 23 10
σA=B ^ D > 5 (r)
A B C D
α α 1 7
β β 23 10

Select Operation
■ Notation: σ p(r)
■ p is called the selection predicate
■ Defined as:
σp(r) = {t | t ∈ r and p(t)}
Where p is a formula in propositional calculus consisting of terms
connected by : ∧ (and), ∨ (or), ¬ (not)
Each term is one of:
<attribute> op <attribute> or <constant>
where op is one of: =, ≠, >, ≥. <. ≤
■ Example of selection:
σ branch_name=“Perryridge”(account)

Project Operation – Example
■ Relation r: A B C
α 10 1
α 20 1
β 30 1
β 40 2
∏A,C (r) A C A C
α 1 α 1
α 1 = β 1
β 1 β 2
β 2

Project Operation
■ Notation:
∏ A1 , A2 ,, Ak (r )
where A1, A2 are attribute names and r is a relation name.
■ The result is defined as the relation of k columns obtained by erasing
the columns that are not listed
■ Duplicate rows removed from result, since relations are sets
■ Example: To eliminate the branch_name attribute of account
∏account_number, balance (account)

Union Operation – Example
■ Relations r, s:
A B A B
α 1 α 2
α 2 β 3
β 1 s
r
A B
■ r ∪ s: α 1
α 2
β 1
β 3

Union Operation
■ Notation: r ∪ s
■ Defined as:
r ∪ s = {t | t ∈ r or t ∈ s}
■ For r ∪ s to be valid.
1. r, s must have the same arity (same number of attributes)
2. The attribute domains must be compatible (example: 2nd column
of r deals with the same type of values as does the 2nd
column of s)
■ Example: to find all customers with either an account or a loan
∏customer_name (depositor) ∪ ∏customer_name (borrower)

Set Difference Operation – Example
■ Relations r, s:
A B A B
α 1 α 2
α 2 β 3
β 1 s
r
■ r – s:
A B
α 1
β 1

Set Difference Operation
■ Notation r – s
■ Defined as:
r – s = {t | t ∈ r and t ∉ s}
■ Set differences must be taken between compatible
relations.
● r and s must have the same arity
● attribute domains of r and s must be compatible

CartesianProduct Operation – Example
■ Relations r, s:
A B C D E
α 1 α 10 a
β 10 a
β 2 β 20 b
r γ 10 b
s
■ r x s:
A B C D E
α 1 α 10 a
α 1 β 10 a
α 1 β 20 b
α 1 γ 10 b
β 2 α 10 a
β 2 β 10 a
β 2 β 20 b
β 2 γ 10 b

CartesianProduct Operation
■ Notation r x s
■ Defined as:
r x s = {t q | t ∈ r and q ∈ s}
■ Assume that attributes of r(R) and s(S) are disjoint. (That is, R ∩ S = ∅).
■ If attributes of r(R) and s(S) are not disjoint, then renaming must be
used.

Composition of Operations
■ Can build expressions using multiple operations
■ Example: σA=C(r x s)
■ r x s
A B C D E
α 1 α 10 a
α 1 β 10 a
α 1 β 20 b
α 1 γ 10 b
β 2 α 10 a
β 2 β 10 a
β 2 β 20 b
β 2 γ 10 b
■ σA=C(r x s)
A B C D E
α 1 α 10 a
β 2 β 10 a
β 2 β 20 b

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 (E)
returns the expression E under the name X
■ If a relationalalgebra expression E has arity n, then

ρ (E )
x ( A1 , A2 ,..., An )
returns the result of expression E under the name X, and with the
attributes renamed to A1 , A2 , …., An .

Banking Example
branch (branch_name, branch_city, assets)
customer (customer_name, customer_street, customer_city)
account (account_number, branch_name, balance)
loan (loan_number, branch_name, amount)
depositor (customer_name, account_number)
borrower (customer_name, loan_number)

Example Queries
■ Find all loans of over $1200

σamount > 1200 (loan)
■ Find the loan number for each loan of an amount greater than
$1200

∏loan_number (σamount > 1200 (loan))
■ Find the names of all customers who have a loan, an account, or both,
from the bank
∏customer_name (borrower) ∪ ∏customer_name (depositor)

Example Queries
■ Find the names of all customers who have a loan at the Perryridge
branch.
∏customer_name (σbranch_name=“Perryridge”
(σborrower.loan_number = loan.loan_number(borrower x loan)))
■ Find the names of all customers who have a loan at the
Perryridge branch but do not have an account at any branch of
the bank.
∏customer_name (σbranch_name = “Perryridge”
(σborrower.loan_number = loan.loan_number(borrower x loan))) –
∏customer_name(depositor)

Example Queries
■ Find the names of all customers who have a loan at the Perryridge branch.
● Query 1
∏customer_name (σbranch_name = “Perryridge” (
σborrower.loan_number = loan.loan_number (borrower x loan)))
● Query 2
∏customer_name(σloan.loan_number = borrower.loan_number (
(σbranch_name = “Perryridge” (loan)) x borrower))

Example Queries
■ Find the largest account balance
● Strategy:
 Find those balances that are not the largest
– Rename account relation as d so that we can compare each
account balance with all others
 Use set difference to find those account balances that were not found
in the earlier step.
● The query is:

∏balance(account) ∏account.balance
(σaccount.balance < d.balance (account x ρd (account)))

Formal Definition
■ A basic expression in the relational algebra consists of either one of the
following:
● A relation in the database
● A constant relation
■ Let E1 and E2 be relationalalgebra expressions; the following are all
relationalalgebra expressions:
● E1 ∪ E2
● E1 – E2
● E1 x E2
● σp (E1), P is a predicate on attributes in E1
● ∏s(E1), S is a list consisting of some of the attributes in E1
● ρ (E ), x is the new name for the result of E
x th Edition, Oct 5, 2006
Database System Concepts 5 1 2.34 1 ©Silberschatz, Korth and Sudarshan
Additional Operations
We define additional operations that do not add any power to the
relational algebra, but that simplify common queries.
■ Set intersection
■ Natural join
■ Division
■ Assignment

SetIntersection Operation
■ Notation: r ∩ s
■ Defined as:
■ r ∩ s = { t | t ∈ r and t ∈ s }
■ Assume:
● r, s have the same arity
● attributes of r and s are compatible
■ Note: r ∩ s = r – (r – s)

SetIntersection Operation – Example
■ Relation r, s:
A B A B
α 1 α 2
α 2 β 3
β 1
r s
■ r ∩ s
A B
α 2

NaturalJoin Operation
■ Notation: r s
■ Let r and s be relations on schemas R and S respectively.
Then, r s is a relation on schema R ∪ S obtained as follows:
● Consider each pair of tuples tr from r and ts from s.
● If tr and ts have the same value on each of the attributes in R ∩ S, add a
tuple t to the result, where
 t has the same value as tr on r
 t has the same value as ts on s
■ Example:
R = (A, B, C, D)
S = (E, B, D)
● Result schema = (A, B, C, D, E)
● r s is defined as:
Natural Join Operation – Example
■ Relations r, s:
A B C D B D E
α 1 α a 1 a α
β 2 γ a 3 a β
γ 4 β b 1 a γ
α 1 γ a 2 b δ
δ 2 β b 3 b ∈
r s
■ r s
A B C D E
α 1 α a α
α 1 α a γ
α 1 γ a α
α 1 γ a γ
δ 2 β b δ

Division Operation
■ Notation: r÷s
■ Suited to queries that include the phrase “for all”.
■ Let r and s be relations on schemas R and S respectively
where
● R = (A1, …, Am , B1, …, Bn )
● S = (B1, …, Bn)
The result of r ÷ s is a relation on schema
R – S = (A1, …, Am)
r ÷ s = { t | t ∈ ∏ RS (r) ∧ ∀ u ∈ s ( tu ∈ r ) }
Where tu means the concatenation of tuples t and u to
produce a single tuple

Division Operation – Example
■ Relations r, s:
A B B
α 1
1
α 2
α 3 2
β 1 s
γ 1
δ 1
δ 3
δ 4
∈ 6
∈ 1
β 2
■ r ÷ s: A r
α
β

Another Division Example
■ Relations r, s:
A B C D E D E
α a α a 1 a 1
α a γ a 1 b 1
α a γ b 1 s
β a γ a 1
β a γ b 3
γ a γ a 1
γ a γ b 1
γ a β b 1
r
■ r ÷ s:
A B C
α a γ
γ a γ

Division Operation (Cont.)
■ Property
● Let q = r ÷ s
● Then q is the largest relation satisfying q x s ⊆ r
■ Definition in terms of the basic algebra operation
Let r(R) and s(S) be relations, and let S ⊆ R
r ÷ s = ∏RS (r ) – ∏RS ( ( ∏RS (r ) x s ) – ∏RS,S(r ))
To see why
● ∏RS,S (r) simply reorders attributes of r
● ∏RS (∏RS (r ) x s ) – ∏RS,S(r) ) gives those tuples t in
∏RS (r ) such that for some tuple u ∈ s, tu ∉ r.

Assignment Operation
■ The assignment operation (←) provides a convenient way to express
complex queries.
● Write query as a sequential program consisting of
 a series of assignments
 followed by an expression whose value is displayed as a result of
the query.
● Assignment must always be made to a temporary relation variable.
■ Example: Write r ÷ s as
temp1 ← ∏RS (r )
temp2 ← ∏RS ((temp1 x s ) – ∏RS,S (r ))
result = temp1 – temp2
● The result to the right of the ← is assigned to the relation variable on
the left of the ←.
● May use variable in subsequent expressions.

Bank Example Queries
■ Find the names of all customers who have a loan and an account at
bank.
∏customer_name (borrower) ∩ ∏customer_name (depositor)
■ Find the name of all customers who have a loan at the bank and the
loan amount
∏customer_name, loan_number, amount (borrower loan)

■ Find all customers who have an account from at least the “Downtown”
and the Uptown” branches.
● Query 1
∏customer_name (σbranch_name = “Downtown” (depositor account )) ∩
∏customer_name (σbranch_name = “Uptown” (depositor account))
● Query 2
∏customer_name, branch_name (depositor account)
÷ ρtemp(branch_name) ({(“Downtown” ), (“Uptown” )})
Note that Query 2 uses a constant relation.

■ Find all customers who have an account at all branches located in
Brooklyn city.
∏customer_name, branch_name (depositor account)
÷ ∏branch_name (σbranch_city = “Brooklyn” (branch))

Extended RelationalAlgebraOperations
■ Generalized Projection
■ Aggregate Functions
■ Outer Join

Generalized Projection
■ Extends the projection operation by allowing arithmetic functions to be
used in the projection list.
∏ F1 ,F2 ,..., Fn (E )
■ E is any relationalalgebra expression
■ Each of F1, F2, …, Fn are are arithmetic expressions involving constants
and attributes in the schema of E.
■ Given relation credit_info(customer_name, limit, credit_balance), find
how much more each person can spend:
∏customer_name, limit – credit_balance (credit_info)

Aggregate Functions and Operations
■ Aggregation function takes a collection of values and returns a single
value as a result.
avg: average value
min: minimum value
max: maximum value
sum: sum of values
count: number of values
■ Aggregate operation in relational algebra
G1,G2 ,,Gn
ϑF ( A ),F ( A ,,F ( A ) (E )
1 1 2 2 n n
E is any relationalalgebra expression
● G1, G2 …, Gn is a list of attributes on which to group (can be empty)
● Each Fi is an aggregate function
● Each Ai is an attribute name

Aggregate Operation – Example
■ Relation r:
A B C
α α 7
α β 7
β β 3
β β 10
■ g sum(c) (r) sum(c )
27

Aggregate Operation – Example
■ Relation account grouped by branchname:
branch_name account_number balance

Perryridge A102 400
Perryridge A201 900
Brighton A217 750
Brighton A215 750
Redwood A222 700
branch_name g sum(balance) (account)

branch_name sum(balance)
Perryridge 1300
Brighton 1500
Redwood 700

Aggregate Functions (Cont.)
■ Result of aggregation does not have a name
● Can use rename operation to give it a name
● For convenience, we permit renaming as part of aggregate
operation
branch_name g sum(balance) as sum_balance (account)

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:
● null signifies that the value is unknown or does not exist
● All comparisons involving null are (roughly speaking) false by
definition.
 We shall study precise meaning of comparisons with nulls later

Outer Join – Example
■ Relation loan
loan_number branch_name amount

L170 Downtown 3000
L230 Redwood 4000
L260 Perryridge 1700
■ Relation borrower
customer_name loan_number
Jones L170
Smith L230
Hayes L155

■ Join
loan borrower
loan_number branch_name amount customer_name

L170 Downtown 3000 Jones
L230 Redwood 4000 Smith
■ Left Outer Join
loan borrower
L260 Perryridge 1700 null

■ Right Outer Join
loan borrower

L155 null null Hayes
■ Full Outer Join
loan borrower
L260 Perryridge 1700 null
L155 null null Hayes

Null Values
■ It is possible for tuples to have a null value, denoted by null, for some
of their attributes
■ null signifies 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)

Null Values
■ Comparisons with null values return the special truth value: unknown
● If false was used instead of unknown, then not (A < 5)
would not be equivalent to A >= 5
■ Threevalued logic using the truth value unknown:
● OR: (unknown or true) = true,
(unknown or false) = unknown
(unknown or unknown) = unknown
● AND: (true and unknown) = unknown,
(false and unknown) = false,
(unknown and unknown) = unknown
● NOT: (not unknown) = unknown
● In SQL “P is unknown” evaluates to true if predicate P evaluates to
unknown
■ Result of select predicate is treated as false if it evaluates to unknown

Modification of the Database
■ The content of the database may be modified using the following
operations:
● Deletion
● Insertion
● Updating
■ All these operations are expressed using the assignment
operator.

Deletion
■ A delete request is expressed similarly to a query, except
instead of displaying tuples to the user, the selected tuples are
removed from the database.
■ Can delete only whole tuples; cannot delete values on only
particular attributes
■ A deletion is expressed in relational algebra by:
r ← r – E
where r is a relation and E is a relational algebra query.

Deletion Examples
■ Delete all account records in the Perryridge branch.
account ← account – σ branch_name = “Perryridge” (account )
■ Delete all loan records with amount in the range of 0 to 50
loan ← loan – σ amount ≥ 0 and amount ≤ 50 (loan)
■ Delete all accounts at branches located in Needham.
r1 ← σ branch_city = “Needham” (account branch )
r2 ← ∏ account_number, branch_name, balance (r1)
r3 ← ∏ customer_name, account_number (r2 depositor)
account ← account – r2
depositor ← depositor – r3

Insertion
■ To insert data into a relation, we either:
● specify a tuple to be inserted
● write a query whose result is a set of tuples to be inserted
■ in relational algebra, an insertion is expressed by:
r ← r ∪ E
where r is a relation and E is a relational algebra expression.
■ The insertion of a single tuple is expressed by letting E be a constant
relation containing one tuple.

Insertion Examples
■ Insert information in the database specifying that Smith has $1200 in
account A973 at the Perryridge branch.
account ← account ∪ {(“A973”, “Perryridge”, 1200)}
depositor ← depositor ∪ {(“Smith”, “A973”)}
■ Provide as a gift for all loan customers in the Perryridge
branch, a $200 savings account. Let the loan number serve
as the account number for the new savings account.
r1 ← (σbranch_name = “Perryridge” (borrower loan))
account ← account ∪ ∏loan_number, branch_name, 200 (r1)
depositor ← depositor ∪ ∏customer_name, loan_number (r1)

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 2 l
■ Each F is either
i
● the I th attribute of r, if the I th attribute is not updated, or,
● if the attribute is to be updated Fi is an expression, involving only
constants and the attributes of r, which gives the new value for the
attribute

Update Examples
■ Make interest payments by increasing all balances by 5 percent.
account ← ∏ account_number, branch_name, balance * 1.05 (account)
■ Pay all accounts with balances over $10,000 6 percent interest
and pay all others 5 percent
account ← ∏ account_number, branch_name, balance * 1.06 (σ BAL > 10000 (account ))
∪ ∏ account_number, branch_name, balance * 1.05 (σBAL ≤ 10000 (account))

End of Chapter 2
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.dbbook.com for conditions on reuse
Figure 2.3. The branch relation

Figure 2.6: The loan relation

Figure 2.7: The borrower relation

Figure 2.9
Result of σ
Result of branch_name = “Perryridge” (loan)

Figure 2.10:
Loan number and the amount of the loan

Figure 2.11: Names of all customers who
have either an account or an loan

Figure 2.12:
Customers with an account but no loan

Figure 2.13: Result of borrower |X| loan

Figure 2.14

Figure 2.15

Figure 2.16

Figure 2.17
Largest account balance in the bank

Figure 2.18: Customers who live on the
same street and in the same city as
Smith

Figure 2.19: Customers with both an
account and a loan at the bank

Figure 2.20

Figure 2.21

Figure 2.22

Figure 2.23

Figure 2.24: The credit_info relation

Figure 2.25

Figure 2.26: The pt_works relation

Figure 2.27
The pt_works relation after regrouping

Figure 2.28

Figure 2.29

Figure 2.30
The employee and ft_works relations

Figure 2.31

Figure 2.32

Figure 2.33

Figure 2.34

Data Base Lesson 2

Uploaded by

Copyright:

Available Formats

Data Base Lesson 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Base Lesson 2

Uploaded by

Copyright:

Available Formats

Chapter 2: Relational Model

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.2 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.3 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.5 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.6 ©Silberschatz, Korth and Sudarshan

Jones Main Harrison

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.7 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.8 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.9 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.10 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.11 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.12 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.13 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.14 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.15 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.16 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.17 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.18 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.19 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.20 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.21 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.22 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.23 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.24 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.25 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.26 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.27 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.28 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.29 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.30 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.31 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.32 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.33 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.35 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.36 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.37 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.39 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.40 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.41 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.42 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.43 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.44 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.45 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.46 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.47 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.48 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.49 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.50 ©Silberschatz, Korth and Sudarshan

■ g sum(c) (r) sum(c )

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.51 ©Silberschatz, Korth and Sudarshan

branch_name account_number balance

branch_name g sum(balance) (account)

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.52 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.53 ©Silberschatz, Korth and Sudarshan

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.54 ©Silberschatz, Korth and Sudarshan

loan_number branch_name amount

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.55 ©Silberschatz, Korth and Sudarshan

loan_number branch_name amount customer_name

Database System Concepts ­ 5th Edition, Oct 5, 2006 2.56 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.2 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.3 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.5 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.6 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.7 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.8 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.9 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.10 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.11 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.12 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.13 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.14 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.15 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.16 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.17 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.18 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.19 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.20 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.21 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.22 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.23 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.24 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.25 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.26 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.27 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.28 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.29 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.30 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.31 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.32 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.33 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.35 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.36 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.37 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.39 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.40 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.41 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.42 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.43 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.44 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.45 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.46 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.47 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.48 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.49 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.50 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.51 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.52 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.53 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.54 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.55 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.56 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.57 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.58 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.59 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.60 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.61 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.62 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.63 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.64 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.65 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.66 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.68 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.69 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.70 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.71 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.72 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.73 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.74 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.75 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.76 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.77 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.78 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.79 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.80 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.81 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.82 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.83 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.84 ©Silberschatz, Korth and Sudarshan

Database System Concepts 5th Edition, Oct 5, 2006 2.85 ©Silberschatz, Korth and Sudarshan