Chapter 14: Indexing

Database System Concepts, 7th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Outline
 Basic Concepts
 Ordered Indices
 B+-Tree Index Files
 B-Tree Index Files
 Hashing
 Write-optimized indices
 Spatio-Temporal Indexing
Database System Concepts - 7th Edition 14.2 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 7th Edition 14.3 ©Silberschatz, Korth and Sudarshan
 Basic Concepts
 Indexing mechanisms used to speed up access to desired
data.
 E.g., author catalog in library
 Search Key - attribute to set of attributes used to look up
records in a file.
 An index file consists of records (called index entries) of the
form
search-key pointer

 Index files are typically much smaller than the original file
 Two basic kinds of indices:
 Ordered indices: search keys are stored in sorted order
 Hash indices: search keys are distributed uniformly
across “buckets” using a “hash function”.

Database System Concepts - 7th Edition 14.4 ©Silberschatz, Korth and Sudarshan
 Index Evaluation Metrics
 Access types supported efficiently.
E.g.,
 Records with a specified value in the
attribute
 Records with an attribute value falling in a
specified range of values.
 Access time
 Insertion time
 Deletion time
 Space overhead
Database System Concepts - 7th Edition 14.5 ©Silberschatz, Korth and Sudarshan
 Ordered Indices
 In an ordered index, index entries are stored sorted on
the search key value.
 Clustering index: in a sequentially ordered file, the index
whose search key specifies the sequential order of the
file.
 Also called primary index
 The search key of a primary index is usually but not
necessarily the primary key.
 Secondary index: an index whose search key specifies
an order different from the sequential order of the file.
Also called nonclustering index.
 Index-sequential file: sequential file ordered on a search
key, with a clustering index on the search key.

Database System Concepts - 7th Edition 14.6 ©Silberschatz, Korth and Sudarshan
Index-Sequential File Organization
• A structured approach to storing and
indexing sequential data.
• Data is stored sequentially based on
a search key
• An index is created to allow faster
access
• Uses a clustering index to improve
search efficiency
14.7
 Example: Student Relation
• Consider a database storing student records
ordered by Student ID:
Student ID Name Department CGPA
1001 Arjun CSE 8.5
1005 Bhishma ECE 7.8
1010 Charlie CSE 9
1015 Dravid ME 8.3
1020 Irshad CSE 8.8
14.8
How Index-Sequential Files Work?
• Data is stored in sequential order of
the search key
• An index file maintains a subset of
keys pointing to disk blocks
• Searching involves looking up the
index and scanning records in the
block
14.9
 Index Table Example
Student ID (Search Key) Pointer to Disk Block
1001 Block 1
1010 Block 2
1020 Block 3

• Example: To search for Student ID 1015, look

at the index, fetch Block 2, and scan
sequentially.

14.10
 Advantages of Index-Sequential Files

• Faster searches due to indexed access

• Efficient range queries since data is
sorted
• Reduced storage overhead as only a
subset of keys is indexed
• Supports sequential access for batch
processing

14.11
Disadvantages of Index-Sequential Files

• Insertion overhead: Reorganization

needed to maintain order
• Index maintenance: Updates are
required for insertions and deletions
• Slower updates: Keeping sorted
order is costly

14.12
 Real-World Examples
• Student databases (ordered by Student ID)
• Employee records (ordered by Employee ID)
• Bank transactions (ordered by Account
Number)
• Inventory management (ordered by
Product ID)

14.13
 Dense Index Files
 Dense index — Index record appears for every search-key
value in the file.
 E.g. index on ID attribute of instructor relation

Database System Concepts - 7th Edition 14.14 ©Silberschatz, Korth and Sudarshan
 Dense Index Files (Cont.)
 Dense index on dept_name, with instructor file sorted
on dept_name

Database System Concepts - 7th Edition 14.15 ©Silberschatz, Korth and Sudarshan
 Sparse Index Files

 Sparse Index: contains index records for

only some search-key values.
 Applicable when records are sequentially
ordered on search-key
 To locate a record with search-key value K
we:
 Find index record with largest search-key
value < K
 Search file sequentially starting at the
record to which the index record points

Database System Concepts - 7th Edition 14.16 ©Silberschatz, Korth and Sudarshan
 Sparse Index Files

Database System Concepts - 7th Edition 14.17 ©Silberschatz, Korth and Sudarshan
 Sparse Index Files (Cont.)
 Compared to dense indices:
 Less space and less maintenance overhead for insertions and deletions.
 Generally slower than dense index for locating records.
 Good tradeoff:
 for clustered index: sparse index with an index entry for every block in
file, corresponding to least search-key value in the block.

 For unclustered index: sparse index on top of dense index (multilevel

index)

Database System Concepts - 7th Edition 14.18 ©Silberschatz, Korth and Sudarshan
 Secondary Indices Example
 Secondary index on salary field of instructor

 Index record points to a bucket that contains pointers to all the actual
records with that particular search-key value.
 Secondary indices have to be dense

Database System Concepts - 7th Edition 14.19 ©Silberschatz, Korth and Sudarshan
 Clustering vs Nonclustering Indices
 Indices offer substantial benefits when searching for
records.
 BUT: indices imposes overhead on database
modification
 when a record is inserted or deleted, every index on
the relation must be updated
 When a record is updated, any index on an updated
attribute must be updated
 Sequential scan using clustering index is efficient, but a
sequential scan using a secondary (non clustering) index
is expensive on magnetic disk
 Each record access may fetch a new block from disk
 Each block fetch on magnetic disk requires about 5 to
10 milliseconds

Database System Concepts - 7th Edition 14.20 ©Silberschatz, Korth and Sudarshan
 Multilevel Index
 If index does not fit in memory, access
becomes expensive.
 Solution: treat index kept on disk as a sequential
file and construct a sparse index on it.
 outer index – a sparse index of the basic index
 inner index – the basic index file
 If even outer index is too large to fit in main
memory, yet another level of index can be created,
and so on.
 Indices at all levels must be updated on insertion
or deletion from the file.

Database System Concepts - 7th Edition 14.21 ©Silberschatz, Korth and Sudarshan
 Multilevel Index (Cont.)

Database System Concepts - 7th Edition 14.22 ©Silberschatz, Korth and Sudarshan
 Multilevel Index Example
• Suppose Employee table has 100,000 tuples. Each
disk block can store 100 tuples.
• So, the data file requires 1,000 blocks (100,000 / 100).
Now, let’s build an index on emp_id.
• First-Level Index (Primary Index) Each index entry
points to a block of records. If one block holds 100
records, we’ll have 1,000 entries in the index.
• Assume each index block holds 100 entries:1,000
entries require 10 index blocks → too large for
memory.
• So we create a second-level index.

14.23
 Multilevel Index Example
• Level 2 (Top Level Index)
– 1 block → points to 10 blocks
of the first-level index.
• Level 1 (Index to Data)
– 10 blocks → each has 100 entries
pointing to actual data blocks.
• Data Blocks1,000 blocks → contain the actual records.
• To search for emp_id = 54321:
– Search Level 2 index → find the correct Level 1 index
block.
– Search Level 1 index → find the correct data block.
– Search the data block for the actual record.
– Only 3 disk accesses (if index levels aren't in memory) vs
potentially 1000 without indexing!
14.24
 Index Update: Deletion

 If deleted record was the

only record in the file with
its particular search-key
value, the search-key is
deleted from the index
also.

 Single-level index entry deletion:

 Dense indices – deletion of search-key is similar to file record
deletion.
 Sparse indices –
 if an entry for the search key exists in the index, it is deleted
by replacing the entry in the index with the next search-key
value in the file (in search-key order).
 If the next search-key value already has an index entry, the
entry is deleted instead of being replaced.

Database System Concepts - 7th Edition 14.25 ©Silberschatz, Korth and Sudarshan
 Index Update: Insertion
 Single-level index insertion:
• Perform a lookup using the search-key value of the record to be
inserted.
• Dense indices – if the search-key value does not appear in the
index, insert it
 Indices are maintained as sequential files
 Need to create space for new entry, overflow blocks may be
required
• Sparse indices – if index stores an entry for each block of the
file, no change needs to be made to the index unless a new
block is created.
 If a new block is created, the first search-key value appearing
in the new block is inserted into the index.
 Multilevel insertion and deletion: algorithms are simple
extensions of the single-level algorithms

Database System Concepts - 7th Edition 14.26 ©Silberschatz, Korth and Sudarshan
 Indices on Multiple Keys

 Composite search key

• E.g., index on instructor relation on
attributes (name, ID)
• Values are sorted lexicographically
 E.g. (John, 12121) < (John, 13514)
and
(John, 13514) < (Peter, 11223)
• Can query on just name, or on (name, ID)

Database System Concepts - 7th Edition 14.27 ©Silberschatz, Korth and Sudarshan
 Which Data Structure is it?

Database System Concepts - 7th Edition 14.28 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files
 Disadvantage of indexed-sequential files
 Performance degrades as file grows, since many
overflow blocks get created.
 Periodic reorganization of entire file is required.
 Advantage of B+-tree index files:
 Automatically reorganizes itself with small, local,
changes, in the face of insertions and deletions.
 Reorganization of entire file is not required to maintain
performance.
 (Minor) disadvantage of B +-trees:
 Extra insertion and deletion overhead, space
overhead.
 Advantages of B+-trees outweigh disadvantages
 B+-trees are used extensively

Database System Concepts - 7th Edition 14.29 ©Silberschatz, Korth and Sudarshan
 Example of B+-Tree

Database System Concepts - 7th Edition 14.30 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files (Cont.)

B+-tree is a rooted tree satisfying the following properties:

 All paths from root to leaf are of the same length

 Each node that is not a root or a leaf has between
n/2 and n children.
 A leaf node has between (n–1)/2 and n–1 values
 Special cases:
 If the root is not a leaf, it has at least 2 children.
 If the root is a leaf (that is, there are no other
nodes in the tree), it can have between 0 and (n–
1) values.

Database System Concepts - 7th Edition 14.31 ©Silberschatz, Korth and Sudarshan
 B+-Tree Node Structure

 Typical node

 Ki are the search-key values

 Pi are pointers to children (for non-leaf nodes) or
pointers to records or buckets of records (for leaf
nodes).
 The search-keys in a node are ordered
K1 < K2 < K3 < . . . < Kn–1
(Initially assume no duplicate keys, address
duplicates later)

Database System Concepts - 7th Edition 14.32 ©Silberschatz, Korth and Sudarshan
 Leaf Nodes in B+-Trees
Properties of a leaf node:
Pn

 For i = 1, 2, . . ., n–1, pointer Pi points to a file record with search-

key value Ki,
 If Li, Lj are leaf nodes and i < j, Li’s search-key values are less
than or equal to Lj’s search-key values
 Pn points to next leaf node in search-key order
Database System Concepts - 7th Edition 14.33 ©Silberschatz, Korth and Sudarshan
 Non-Leaf Nodes in B+-Trees

P1 K1 Pn

 Non leaf nodes form a multi-level sparse index on the leaf nodes. For a
non-leaf node with m pointers:
 All the search-keys in the subtree to which P1 points are less than K1
 For 2  i  n – 1, all the search-keys in the subtree to which Pi points
have values greater than or equal to Ki–1 and less than Ki
 All the search-keys in the subtree to which Pn points have values greater
than or equal to Kn–1
 General structure

Database System Concepts - 7th Edition 14.34 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree

 B+-tree for instructor file (n = 6)

 Leaf nodes must have between 3 and 5 values

((n–1)/2 and n –1, with n = 6).
 Non-leaf nodes other than root must have between 3 and 6
children ((n/2 and n with n =6).
 Root must have at least 2 children.

Database System Concepts - 7th Edition 14.35 ©Silberschatz, Korth and Sudarshan
 Observations about B+-trees

 Since the inter-node connections are done by pointers, “logically”

close blocks need not be “physically” close.
 The non-leaf levels of the B+-tree form a hierarchy of sparse
indices.
 The B+-tree contains a relatively small number of levels
 Level below root has at least 2* n/2 values
 Next level has at least 2* n/2 * n/2 values
 .. etc.
 If there are K search-key values in the file, the tree height is no
more than  logn/2(K)
 thus searches can be conducted efficiently.
 Insertions and deletions to the main file can be handled efficiently,
as the index can be restructured in logarithmic time.

Database System Concepts - 7th Edition 14.36 ©Silberschatz, Korth and Sudarshan
 Queries on B+-Trees
function find(v)
/* Assumes no duplicate keys, and returns pointer to the record with search key
value V if such a record exists, and null otherwise */
1. C = root
2. while (C is not a leaf node)
1. Let i be least number such that V  Ki.
2. if there is no such number i then
3. Set C = last non-null pointer in C
4. else if (V = C.Ki ) Set C = Pi +1
5. else set C = C.Pi
3. if for some i, Ki = V then return C.Pi
4. else return null /* no record with search-key value V exists. */

Database System Concepts - 7th Edition 14.37 ©Silberschatz, Korth and Sudarshan
 Queries on B+-Trees (Cont.)

 Range queries find all records with search key values in a given
range
• See book for details of function findRange(lb, ub) which
returns set of all such records
• Real implementations usually provide an iterator interface to
fetch matching records one at a time, using a next() function

Database System Concepts - 7th Edition 14.38 ©Silberschatz, Korth and Sudarshan
 Queries on B+-Trees (Cont.)

 If there are K search-key values in the file, the height of the

tree is no more than logn/2(K).
 A node is generally the same size as a disk block, typically 4
kilobytes
• and n is typically around 100 (40 bytes per index entry).
 With 1 million search key values and n = 100
• at most log50(1,000,000) = 4 nodes are accessed in a
lookup traversal from root to leaf.
 Contrast this with a balanced binary tree with 1 million
search key values — around 20 nodes are accessed in a
lookup
• above difference is significant since every node access
may need a disk I/O, costing around 20 milliseconds

Database System Concepts - 7th Edition 14.39 ©Silberschatz, Korth and Sudarshan
 Non-Unique Keys

 If a search key ai is not unique, create instead an index on a

composite key (ai , Ap), which is unique

• Ap could be a primary key, record ID, or any other attribute

that guarantees uniqueness
 Search for ai = v can be implemented by a range search on
composite key, with range (v, - ∞) to (v, + ∞)
 But more I/O operations are needed to fetch the actual records
• If the index is clustering, all accesses are sequential
• If the index is non-clustering, each record access may need
an I/O operation

Database System Concepts - 7th Edition 14.40 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Insertion

Assume record already added to the file. Let

 pr be pointer to the record, and let
 v be the search key value of the record
1. Find the leaf node in which the search-key
value would appear
1. If there is room in the leaf node, insert (v,
pr) pair in the leaf node
2. Otherwise, split the node ( along with the
new (v, pr) entry ) and propagate updates
to parent nodes.

Database System Concepts - 7th Edition 14.41 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Insertion (Cont.)
 Splitting a leaf node:
 take the n (search-key value, pointer) pairs (including the
one being inserted) in sorted order. Place the first n/2 in
the original node, and the rest in a new node.
 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.

Splitting node containing Brandt, Califieri and Crick on inserting Adams

Next step: insert entry with (Califieri, pointer-to-new-node) into parent

Database System Concepts - 7th Edition 14.42 ©Silberschatz, Korth and Sudarshan
 B+-Tree Insertion
B+-Tree before insertion of “Adams”

B+-Tree after insertion of “Adams”

Affected nodes

Database System Concepts - 7th Edition 14.43 ©Silberschatz, Korth and Sudarshan
 B+-Tree Insertion

Given B+ Tree before insertion

Insert Lamport
Database System Concepts - 7th Edition 14.44 ©Silberschatz, Korth and Sudarshan
 Insert Lamport

Database System Concepts - 7th Edition 14.45 ©Silberschatz, Korth and Sudarshan
 B+-Tree Insertion
B+-Tree before insertion of “Lamport”

B+-Tree after insertion of “Lamport” Affected nodes

Affected nodes
Database System Concepts - 7th Edition 14.46 ©Silberschatz, Korth and Sudarshan
 Insertion in B+-Trees (Cont.)
 Splitting a non-leaf node: when inserting (k,p) into an already full
internal node N
 Copy N to an in-memory area M with space for n+1 pointers and n
keys
 Insert (k,p) into M
 Copy P1,K1, …, K n/2-1,P n/2 from M back into node N
 Copy Pn/2+1,K n/2+1,…,Kn,Pn+1 from M into newly allocated
node N'
 Insert (K n/2,N') into parent N
 Example

 Read pseudocode in book!

Database System Concepts - 7th Edition 14.47 ©Silberschatz, Korth and Sudarshan
 Examples of B+-Tree Deletion
Before deleting “Srinivasan”

After deleting “Srinivasan”

Affected nodes

 Deleting “Srinivasan” causes merging of under-full leaves

Database System Concepts - 7th Edition 14.48 ©Silberschatz, Korth and Sudarshan
 Examples of B+-Tree Deletion (Cont.)

Before deleting “Singh” and “Wu”

 Leaf containing Singh and Wu became underfull, and borrowed a value Kim from
its left sibling
 Search-key value in the parent changes as a result

After deleting “Singh” and “Wu”

Affected nodes

Database System Concepts - 7th Edition 14.49 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 7th Edition 14.50 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree Deletion (Cont.)

Delete “Gold”

Database System Concepts - 7th Edition 14.51 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree Deletion (Cont.)

Before deletion of “Gold”

 Node with Gold and Katz became underfull, and was merged with its sibling
 Parent node becomes underfull, and is merged with its sibling
• Value separating two nodes (at the parent) is pulled down when merging
 Root node then has only one child, and is deleted
Affected nodes

After deletion of “Gold”

Database System Concepts - 7th Edition 14.52 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree Deletion (Cont.)

Is it the Correct one?

Katz

Database System Concepts - 7th Edition 14.53 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Deletion

Assume record already deleted from file. Let V be the

search key value of the record, and Pr be the pointer to the
record.
 Remove (Pr, V) from the leaf node
 If the node has too few entries due to the removal, and
the entries in the node and a sibling can fit 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 (Ki–1, Pi), where Pi is the pointer to the
deleted node, from its parent, recursively using the
above procedure.

Database System Concepts - 7th Edition 14.54 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Deletion

 Otherwise, if the node has too few entries due to the

removal, but the entries in the node and a sibling do
not fit 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.
 Update the corresponding search-key value in the
parent of the node.
 The node deletions may cascade upwards till a node
which has n/2 or more pointers is found.
 If the root node has only one pointer after deletion, it
is deleted and the sole child becomes the root.

Database System Concepts - 7th Edition 14.55 ©Silberschatz, Korth and Sudarshan
 Complexity of Updates

 Cost (in terms of number of I/O operations) of insertion and

deletion of a single entry proportional to height of the tree
• With K entries and maximum fanout of n, worst case
complexity of insert/delete of an entry is O(logn/2(K))
 In practice, number of I/O operations is less:
• Internal nodes tend to be in buffer
• Splits/merges are rare, most insert/delete operations only
affect a leaf node
 Average node occupancy depends on insertion order
• 2/3rds with random, ½ with insertion in sorted order.
In a B+ Tree, the fanout of a node refers to the maximum number of children (or
pointers) that a node can have.
It's a key factor that affects the height and performance of the tree.

Database System Concepts - 7th Edition 14.56 ©Silberschatz, Korth and Sudarshan
 B+-Tree File Organization

 B+-Tree File Organization:

• Leaf nodes in a B+-tree file organization store
records, instead of pointers
• Helps keep data records clustered even when there
are insertions/deletions/updates
 Leaf nodes are still required to be half full
• Since records are larger than pointers, the
maximum number of records that can be stored in a
leaf node is less than the number of pointers in a
nonleaf node.
 Insertion and deletion are handled in the same way as
insertion and deletion of entries in a B +-tree index.

Database System Concepts - 7th Edition 14.58 ©Silberschatz, Korth and Sudarshan
 B+-Tree File Organization (Cont.)

 Example of B+-tree File Organization

 Good space utilization important since records use more space than pointers.

 To improve space utilization, involve more sibling nodes in redistribution

during splits and merges
 Involving 2 siblings in redistribution (to avoid split / merge where
possible) results in each node having at least entries
 2n / 3

Database System Concepts - 7th Edition 14.59 ©Silberschatz, Korth and Sudarshan
 Indexing on Flash
 Random I/O cost much lower on flash
• 20 to 100 microseconds for read/write
 Writes are not in-place, and (eventually) require a more expensive erase
 Optimum page size therefore much smaller
 Bulk-loading still useful since it minimizes page erases
 Write-optimized tree structures (discussed later) have been adapted to
minimize page writes for flash-optimized search trees

Database System Concepts - 7th Edition 14.66 ©Silberschatz, Korth and Sudarshan
 Indexing in Main Memory
 Random access in memory
• Much cheaper than on disk/flash
• But still expensive compared to cache read
• Data structures that make best use of cache
preferable
• Binary search for a key value within a large B+-
tree node results in many cache misses
 B+- trees with small nodes that fit in cache line are
preferable to reduce cache misses
 Key idea: use large node size to optimize disk
access, but structure data within a node using a tree
with small node size, instead of using an array.

Database System Concepts - 7th Edition 14.67 ©Silberschatz, Korth and Sudarshan
 Hashing
Database System Concepts - 7th Edition 14.68 ©Silberschatz, Korth and Sudarshan
 Why do we need hashing?
• Many applications deal with lots of
data
• Ex. Search engines and web pages
• The look ups are time critical.
• Typical data structures like arrays
and lists, may not be sufficient to
handle efficient lookups
• In general: When look-ups need to
occur in near constant time. O(1)

Database System Concepts - 7th Edition 14.69 ©Silberschatz, Korth and Sudarshan
 Why do we need hashing?
• We need something that can do better than a
binary search, O(log N).
• We want, O(1).

Solution: Hashing

Hashing is used in :

Web searches Spell checkers

Compilers Passwords
Databases and Many others
Database System Concepts - 7th Edition 14.70 ©Silberschatz, Korth and Sudarshan
 Hashing
 Hashing is the process of mapping a
key value to a position in a table.
 A hash table(HT) is an array that holds
the records.
 HT has M slots, indexed form 0 to M−1.
 The index is called the hash value of
the key
 Key must be converted to an index.
 A hash function maps key values to
index.

Database System Concepts - 7th Edition 14.71 ©Silberschatz, Korth and Sudarshan
 Hash function
[0] [1] [2] [3] [4] [5] [ 185 ] [ 700]
281942902 233667136 506643548 155778322

 How to map Key to index?

 Key 580625685 0 to 700

 Typical way to create a hash value is
( Key mod maximum index )
 (580625685 mod 700) is 185

Database System Concepts - 7th Edition 14.72 ©Silberschatz, Korth and Sudarshan
 Static Hashing
 A bucket is a unit of storage containing one or more
entries (a bucket is typically a disk block).
 we obtain the bucket of an entry from its search-key
value using a hash function
 Hash function h is a function from the set of all search-key
values K to the set of all bucket addresses B.
 Hash function is used to locate entries for access,
insertion and deletion.
 Entries with different search-key values may be mapped
to the same bucket; thus entire bucket has to be
searched sequentially to locate an entry.
 In a hash index, buckets store entries with pointers to
records
 In a hash file-organization buckets store records

Database System Concepts - 7th Edition 14.73 ©Silberschatz, Korth and Sudarshan
 Handling of Bucket Overflows
 Bucket overflow can occur because of
 Insufficient buckets
 Skew in distribution of records. This can
occur due to two reasons:
multiple records have same search-key
value
chosen hash function produces non-
uniform distribution of key values
 Although the probability of bucket overflow can
be reduced, it cannot be eliminated; it is
handled by using overflow buckets.

Database System Concepts - 7th Edition 14.74 ©Silberschatz, Korth and Sudarshan
 Handling of Bucket Overflows (Cont.)
 Overflow chaining – the overflow buckets of a given bucket are chained
together in a linked list.
 Above scheme is called closed addressing (also called closed hashing)
 An alternative, called open addressing (also called open hashing) which
does not use over flow buckets, is not suitable for database applications.

Database System Concepts - 7th Edition 14.75 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization
Hash file organization of instructor file, using
dept_name as key (See figure in next slide.)

 There are 10 buckets,

 The binary representation of the I th
character is assumed to be the integer i.
 The hash function returns the sum of the
binary representations of the characters
modulo 10
 E.g. h(Music) = 1 h(History) = 2
h(Physics) = 3 h(Elec. Eng.) = 3

Database System Concepts - 7th Edition 14.76 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization
Hash file organization of instructor file, using dept_name as key.

Database System Concepts - 7th Edition 14.77 ©Silberschatz, Korth and Sudarshan
 Deficiencies of Static Hashing
 In static hashing, function h maps search-key values to a
fixed set of B of bucket addresses. Databases grow or
shrink with time.
 If initial number of buckets is too small, and file grows,
performance will degrade due to too much overflows.
 If space is allocated for anticipated growth, a significant
amount of space will be wasted initially (and buckets will
be underfull).
 If database shrinks, again space will be wasted.
 One solution: periodic re-organization of the file with a new
hash function
 Expensive, disrupts normal operations
 Better solution: allow the number of buckets to be modified
dynamically.
Database System Concepts - 7th Edition 14.78 ©Silberschatz, Korth and Sudarshan
 Dynamic Hashing
 Periodic rehashing
• If number of entries in a hash table becomes (say) 1.5
times size of hash table,
 create new hash table of size (say) 2 times the size
of the previous hash table
 Rehash all entries to new table
 Linear Hashing
• Do rehashing in an incremental manner
 Extendable Hashing
• Tailored to disk based hashing, with buckets shared by
multiple hash values
• Doubling of # of entries in hash table, without doubling
# of buckets

Database System Concepts - 7th Edition 14.79 ©Silberschatz, Korth and Sudarshan
 Comparison of Ordered Indexing and Hashing
 Cost of periodic re-organization
 Relative frequency of insertions and deletions
 Is it desirable to optimize average access time at the expense of
worst-case access time?
 Expected type of queries:
 Hashing is generally better at retrieving records having a
specified value of the key.
 If range queries are common, ordered indices are to be
preferred
 In practice:
 PostgreSQL supports hash indices, but discourages use due to
poor performance
 Oracle supports static hash organization, but not hash indices
 SQLServer supports only B+-trees

Database System Concepts - 7th Edition 14.80 ©Silberschatz, Korth and Sudarshan
 Multiple-Key Access
 Use multiple indices for certain types of queries.
 Example:
select ID from instructor
where dept_name = “Finance” and salary = 80000
 Possible strategies for processing query using indices
on single attributes:
1. Use index on dept_name to find instructors with
department name Finance; test salary = 80000
2. Use index on salary to find instructors with a salary
of ₹80,000; test dept_name = “Finance”.
3. Use dept_name index to find pointers to all records
pertaining to the “Finance” department. Similarly
use index on salary. Take intersection of both sets
of pointers obtained.

Database System Concepts - 7th Edition 14.81 ©Silberschatz, Korth and Sudarshan
 Indices on Multiple Keys

 Composite search keys are search

keys containing more than one attribute
E.g., (dept_name, salary)
 Lexicographic ordering: (a1, a2) < (b1,
b2) if either
a1 < b1, or
a1=b1 and a2 < b2

Database System Concepts - 7th Edition 14.82 ©Silberschatz, Korth and Sudarshan
 Indices on Multiple Attributes
Suppose we have an index on combined search-key
(dept_name, salary).
 With the where clause
where dept_name = “Finance” and salary = 80000
the index on (dept_name, salary) can be used to fetch only
records that satisfy both conditions.
 Using separate indices in less efficient — we may fetch many
records (or pointers) that satisfy only one of the conditions.
 Can also efficiently handle
where dept_name = “Finance” and salary < 80000
 But cannot efficiently handle
where dept_name < “Finance” and balance = 80000
 May fetch many records that satisfy the first but not the
second condition

Database System Concepts - 7th Edition 14.83 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 7th Edition 14.85 ©Silberschatz, Korth and Sudarshan
 Creation of Indices
 Example
create index takes_pk on takes (ID,course_ID, year, semester,
section)
drop index takes_pk
 Most database systems allow specification of type of index, and
clustering.
 Indices on primary key created automatically by all databases
• Why?
 Some database also create indices on foreign key attributes
• Why might such an index be useful for this query:
 takes ⨝ σname='Shankar' (student)
 Indices can greatly speed up lookups, but impose cost on updates
• Index tuning assistants/wizards supported on several
databases to help choose indices, based on query and update
workload

Database System Concepts - 7th Edition 14.86 ©Silberschatz, Korth and Sudarshan
 Index Definition in SQL
 Create an index
create index <index-name> on <relation-
name>
(<attribute-list>)
E.g.,: create index b-index on branch(branch_name)
 Use create unique index to indirectly specify and enforce
the condition that the search key is a candidate key.
 Not really required if SQL unique integrity constraint is
supported
 To drop an index
drop index <index-name>
 Most database systems allow specification of type of
index, and clustering.

Database System Concepts - 7th Edition 14.87 ©Silberschatz, Korth and Sudarshan
 Bitmap Indices

 Bitmap indices are a special type of index designed for efficient

querying on multiple keys
 Records in a relation are assumed to be numbered sequentially
from, say, 0
 Given a number n it must be easy to retrieve record n
 Particularly easy if records are of fixed size
 Applicable on attributes that take on a relatively small number of
distinct values
 E.g., gender, country, state, …
 E.g., income-level (income broken up into a small number of
levels such as 0-9999, 10000-19999, 20000-49999, 50000-
infinity)
 A bitmap is simply an array of bits

Database System Concepts - 7th Edition 14.93 ©Silberschatz, Korth and Sudarshan
 Bitmap Indices (Cont.)
 In its simplest form a bitmap index on an attribute has a
bitmap for each value of the attribute
 Bitmap has as many bits as records
 In a bitmap for value v, the bit for a record is 1 if the
record has the value v for the attribute, and is 0 otherwise
 Example

Database System Concepts - 7th Edition 14.94 ©Silberschatz, Korth and Sudarshan
 Bitmap Indices (Cont.)
 Bitmap indices are useful for queries on multiple attributes
 not particularly useful for single attribute queries
 Queries are answered using bitmap operations
 Intersection (and)
 Union (or)
 Each operation takes two bitmaps of the same size and applies
the operation on corresponding bits to get the result bitmap
 E.g., 100110 AND 110011 = 100010
100110 OR 110011 = 110111
NOT 100110 = 011001
 Males with income level L1: 10010 AND 10100 = 10000
 Can then retrieve required tuples.
 Counting number of matching tuples is even faster

Database System Concepts - 7th Edition 14.95 ©Silberschatz, Korth and Sudarshan
 Bitmap Indices (Cont.)

 Bitmap indices generally very small

compared with relation size
 E.g., if record is 100 bytes, space for a
single bitmap is 1/800 of space used by
relation.
If number of distinct attribute values is
8, bitmap is only 1% of relation size

Database System Concepts - 7th Edition 14.96 ©Silberschatz, Korth and Sudarshan
 End of Chapter 14

Database System Concepts - 7th Edition 14.107 ©Silberschatz, Korth and Sudarshan