Chapter 12: Indexing and Hashing

Rev. Sep 17, 2008

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 12: Indexing and Hashing
 Basic Concepts
 Ordered Indices
 B+-Tree Index Files
 B-Tree Index Files
 Static Hashing
 Dynamic Hashing
 Comparison of Ordered Indexing and Hashing
 Index Definition in SQL
 Multiple-Key Access

Database System Concepts - 5th Edition. 12.2 ©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 - 5th Edition. 12.3 ©Silberschatz, Korth and Sudarshan
 Index Evaluation Metrics
 Access types supported efficiently. E.g.,
 records with a specified value in the attribute
 or records with an attribute value falling in a specified range
of values (e.g. 10000 < salary < 40000)
 Access time
 Insertion time
 Deletion time
 Space overhead

Database System Concepts - 5th Edition. 12.4 ©Silberschatz, Korth and Sudarshan
 Ordered Indices

 In an ordered index, index entries are stored sorted on the

search key value. E.g., author catalog in library.
 Primary index: in a sequentially ordered file, the index whose
search key specifies the sequential order of the file.
 Also called clustering 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
non-clustering index.
 Index-sequential file: ordered sequential file with a primary
index.

Database System Concepts - 5th Edition. 12.5 ©Silberschatz, Korth and Sudarshan
 Dense Index Files
 Dense index — Index record appears for every search-key
value in the file.

Database System Concepts - 5th Edition. 12.6 ©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 - 5th Edition. 12.7 ©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: sparse index with an index entry for every block in
file, corresponding to least search-key value in the block.

Database System Concepts - 5th Edition. 12.8 ©Silberschatz, Korth and Sudarshan
 Multilevel Index
 If primary index does not fit in memory, access becomes
expensive.
 Solution: treat primary index kept on disk as a sequential file
and construct a sparse index on it.
 outer index – a sparse index of primary index
 inner index – the primary 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 - 5th Edition. 12.9 ©Silberschatz, Korth and Sudarshan
 Multilevel Index (Cont.)

Database System Concepts - 5th Edition. 12.10 ©Silberschatz, Korth and Sudarshan
 Index Update: Record 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 deletion:
 Dense indices – deletion of search-key: similar to file record deletion.
 Sparse indices –
 if deleted key value exists in the index, the value is replaced by
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 - 5th Edition. 12.11 ©Silberschatz, Korth and Sudarshan
 Index Update: Record Insertion
 Single-level index insertion:
 Perform a lookup using the key value from inserted record
 Dense indices – if the search-key value does not appear in
the index, insert it.
 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 (as well as deletion) algorithms are simple
extensions of the single-level algorithms

Database System Concepts - 5th Edition. 12.12 ©Silberschatz, Korth and Sudarshan
 Secondary Indices Example

Secondary index on balance field of account

 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 - 5th Edition. 12.13 ©Silberschatz, Korth and Sudarshan
 Primary and Secondary Indices
 Indices offer substantial benefits when searching for records.
 BUT: Updating indices imposes overhead on database
modification --when a file is modified, every index on the file
must be updated,
 Sequential scan using primary index is efficient, but a
sequential scan using a secondary index is expensive
 Each record access may fetch a new block from disk
 Block fetch requires about 5 to 10 micro seconds, versus
about 100 nanoseconds for memory access

Database System Concepts - 5th Edition. 12.14 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files

B+-tree indices are an alternative to indexed-sequential 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 - 5th Edition. 12.15 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files (Cont.)
A 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 - 5th Edition. 12.16 ©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

Database System Concepts - 5th Edition. 12.17 ©Silberschatz, Korth and Sudarshan
 Leaf Nodes in B+-Trees
Properties of a leaf node:
 For i = 1, 2, . . ., n–1, pointer Pi either points to a file record with
search-key value Ki, or to a bucket of pointers to file records,
each record having search-key value Ki. Only need bucket
structure if search-key does not form a primary key.
 If Li, Lj are leaf nodes and i < j, Li’s search-key values are less
than Lj’s search-key values
 Pn points to next leaf node in search-key order

Database System Concepts - 5th Edition. 12.18 ©Silberschatz, Korth and Sudarshan
 Non-Leaf Nodes in B+-Trees
 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

Database System Concepts - 5th Edition. 12.19 ©Silberschatz, Korth and Sudarshan
 Example of a B+-tree

B+-tree for account file (n = 3)

Database System Concepts - 5th Edition. 12.20 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree

B+-tree for account file (n = 5)

 Leaf nodes must have between 2 and 4 values

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

Database System Concepts - 5th Edition. 12.21 ©Silberschatz, Korth and Sudarshan
 Indexing Strings
 Variable length strings as keys
 Variable fanout
 Use space utilization as criterion for splitting, not number of
pointers
 Prefix compression
 Key values at internal nodes can be prefixes of full key
 Keep enough characters to distinguish entries in the
subtrees separated by the key value
– E.g. “Silas” and “Silberschatz” can be separated by
“Silb”
 Keys in leaf node can be compressed by sharing common
prefixes

Database System Concepts - 5th Edition. 12.22 ©Silberschatz, Korth and Sudarshan
 B-Tree Index Files
 Similar to B+-tree, but B-tree allows search-key values
to appear only once; eliminates redundant storage of
search keys.
 Search keys in nonleaf nodes appear nowhere else in
the B-tree; an additional pointer field for each search
key in a nonleaf node must be included.
 Generalized B-tree leaf node

 Nonleaf node – pointers Bi are the bucket or file record

pointers.

Database System Concepts - 5th Edition. 12.23 ©Silberschatz, Korth and Sudarshan
 B-Tree Index File Example

B-tree (above) and B+-tree (below) on same data

Database System Concepts - 5th Edition. 12.24 ©Silberschatz, Korth and Sudarshan
 B-Tree Index Files (Cont.)
 Advantages of B-Tree indices:
 May use less tree nodes than a corresponding B+-Tree.
 Sometimes possible to find search-key value before reaching
leaf node.
 Disadvantages of B-Tree indices:
 Only small fraction of all search-key values are found early
 Non-leaf nodes are larger, so fan-out is reduced. Thus, B-
Trees typically have greater depth than corresponding B +-Tree
 Insertion and deletion more complicated than in B+-Trees
 Implementation is harder than B+-Trees.
 Typically, advantages of B-Trees do not out weigh disadvantages.

Database System Concepts - 5th Edition. 12.25 ©Silberschatz, Korth and Sudarshan
 Multiple-Key Access
 Use multiple indices for certain types of queries.
 Example:
select account_number
from account
where branch_name = “Perryridge” and balance = 1000
 Possible strategies for processing query using indices on single
attributes:
1. Use index on branch_name to find accounts with branch
name Perryridge; test balance = 1000
2. Use index on balance to find accounts with balances of
$1000; test branch_name = “Perryridge”.
3. Use branch_name index to find pointers to all records
pertaining to the Perryridge branch. Similarly use index on
balance. Take intersection of both sets of pointers obtained.

Database System Concepts - 5th Edition. 12.26 ©Silberschatz, Korth and Sudarshan
 Indices on Multiple Keys
 Composite search keys are search keys containing more
than one attribute
 E.g. (branch_name, balance)
 Lexicographic ordering: (a1, a2) < (b1, b2) if either
 a1 < b1, or
 a1=b1 and a2 < b2

Database System Concepts - 5th Edition. 12.27 ©Silberschatz, Korth and Sudarshan
 Indices on Multiple Attributes

Suppose we have an index on combined search-key

(branch_name, balance).
 For
where branch_name = “Perryridge” and balance = 1000
the index on (branch_name, balance) 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 branch_name = “Perryridge” and balance < 1000
 But cannot efficiently handle
where branch_name < “Perryridge” and balance = 1000
 May fetch many records that satisfy the first but not the
second condition

Database System Concepts - 5th Edition. 12.28 ©Silberschatz, Korth and Sudarshan
 Hashing

Database System Concepts, 5th 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

bucket is typically a disk block).
 In a hash file organization we obtain the bucket of a record directly
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 records for access, insertion as well
as deletion.
 Records with different search-key values may be mapped to the
same bucket; thus entire bucket has to be searched sequentially to
locate a record.

Database System Concepts - 5th Edition. 12.30 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization

Hash file organization of account file, using branch_name as key

(See figure in next slide.)

 There are 10 buckets,

 The binary representation of the ith 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(Perryridge) = 5 h(Round Hill) = 3 h(Brighton) = 3

Database System Concepts - 5th Edition. 12.31 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization

Hash file organization

of account file, using
branch_name as key
(see previous slide for
details).

Database System Concepts - 5th Edition. 12.32 ©Silberschatz, Korth and Sudarshan
 Hash Functions
 Worst hash function maps all search-key values to the same bucket;
this makes access time proportional to the number of search-key
values in the file.
 An ideal hash function is uniform, i.e., each bucket is assigned the
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
number of records assigned to it irrespective of the actual distribution of
search-key values in the file.
 Typical hash functions perform computation on the internal binary
representation of the search-key.
 For example, for a string search-key, the binary representations of
all the characters in the string could be added and the sum modulo
the number of buckets could be returned. .

Database System Concepts - 5th Edition. 12.33 ©Silberschatz, Korth and Sudarshan
 Hash Indices
 Hashing can be used not only for file organization, but also for index-
structure creation.
 A hash index organizes the search keys, with their associated record
pointers, into a hash file structure.
 Strictly speaking, hash indices are always secondary indices
 if the file itself is organized using hashing, a separate primary hash
index on it using the same search-key is unnecessary.
 However, we use the term hash index to refer to both secondary
index structures and hash organized files.

Database System Concepts - 5th Edition. 12.34 ©Silberschatz, Korth and Sudarshan
 Example of Hash Index

Database System Concepts - 5th Edition. 12.35 ©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 - 5th Edition. 12.36 ©Silberschatz, Korth and Sudarshan
 Dynamic Hashing
 Good for database that grows and shrinks in size
 Allows the hash function to be modified dynamically
 Extendable hashing – one form of dynamic hashing
 Hash function generates values over a large range — typically b-bit
integers, with b = 32.
 At any time use only a prefix of the hash function to index into a
table of bucket addresses.
 Let the length of the prefix be i bits, 0  i  32.

 Bucket address table size = 2i. Initially i = 0

Value of i grows and shrinks as the size of the database grows

and shrinks.
 Multiple entries in the bucket address table may point to a bucket
(why?)
 Thus, actual number of buckets is < 2i
 The number of buckets also changes dynamically due to
coalescing and splitting of buckets.

Database System Concepts - 5th Edition. 12.37 ©Silberschatz, Korth and Sudarshan
 General Extendable Hash Structure

In this structure, i2 = i3 = i, whereas i1 = i – 1 (see next

slide for details)

Database System Concepts - 5th Edition. 12.38 ©Silberschatz, Korth and Sudarshan
 Use of Extendable Hash Structure
 Each bucket j stores a value ij
 All the entries that point to the same bucket have the same values on
the first ij bits.
 To locate the bucket containing search-key Kj:
1. Compute h(Kj) = X
2. Use the first i high order bits of X as a displacement into bucket
address table, and follow the pointer to appropriate bucket
 To insert a record with search-key value Kj
 follow same procedure as look-up and locate the bucket, say j.
 If there is room in the bucket j insert record in the bucket.
 Else the bucket must be split and insertion re-attempted (next slide.)
 Overflow buckets used instead in some cases (will see shortly)

Database System Concepts - 5th Edition. 12.39 ©Silberschatz, Korth and Sudarshan
 Insertion in Extendable Hash Structure (Cont)
To split a bucket j when inserting record with search-key value Kj:
 If i > ij (more than one pointer to bucket j)
 allocate a new bucket z, and set ij = iz = (ij + 1)
 Update the second half of the bucket address table entries originally
pointing to j, to point to z
 remove each record in bucket j and reinsert (in j or z)
 recompute new bucket for Kj and insert record in the bucket (further
splitting is required if the bucket is still full)
 If i = ij (only one pointer to bucket j)
 If i reaches some limit b, or too many splits have happened in this
insertion, create an overflow bucket
 Else
 increment i and double the size of the bucket address table.
 replace each entry in the table by two entries that point to the
same bucket.
 recompute new bucket address table entry for Kj
Now i > ij so use the first case above.
Database System Concepts - 5th Edition. 12.40 ©Silberschatz, Korth and Sudarshan
 Deletion in Extendable Hash Structure
 To delete a key value,
 locate it in its bucket and remove it.
 The bucket itself can be removed if it becomes empty (with
appropriate updates to the bucket address table).
 Coalescing of buckets can be done (can coalesce only with a
“buddy” bucket having same value of ij and same ij –1 prefix, if it is
present)
 Decreasing bucket address table size is also possible
 Note: decreasing bucket address table size is an expensive
operation and should be done only if number of buckets becomes
much smaller than the size of the table

Database System Concepts - 5th Edition. 12.41 ©Silberschatz, Korth and Sudarshan
 Use of Extendable Hash Structure:
Example

Initial Hash structure, bucket size = 2

Database System Concepts - 5th Edition. 12.42 ©Silberschatz, Korth and Sudarshan
 Example (Cont.)
 Hash structure after insertion of one Brighton and two Downtown
records

Database System Concepts - 5th Edition. 12.43 ©Silberschatz, Korth and Sudarshan
 Example (Cont.)
Hash structure after insertion of Mianus record

Database System Concepts - 5th Edition. 12.44 ©Silberschatz, Korth and Sudarshan
 Example (Cont.)

Hash structure after insertion of three Perryridge records

Database System Concepts - 5th Edition. 12.45 ©Silberschatz, Korth and Sudarshan
 Example (Cont.)
 Hash structure after insertion of Redwood and Round Hill records

Database System Concepts - 5th Edition. 12.46 ©Silberschatz, Korth and Sudarshan
 Extendable Hashing vs. Other Schemes
 Benefits of extendable hashing:
 Hash performance does not degrade with growth of file
 Minimal space overhead
 Disadvantages of extendable hashing
 Extra level of indirection to find desired record
 Bucket address table may itself become very big (larger than
memory)
 Cannot allocate very large contiguous areas on disk either
 Solution: B+-tree file organization to store bucket address table
 Changing size of bucket address table is an expensive operation
 Linear hashing is an alternative mechanism
 Allows incremental growth of its directory (equivalent to bucket
address table)
 At the cost of more bucket overflows

Database System Concepts - 5th Edition. 12.47 ©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 - 5th Edition. 12.48 ©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-50000, 50000- infinity)
 A bitmap is simply an array of bits

Database System Concepts - 5th Edition. 12.49 ©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

Database System Concepts - 5th Edition. 12.50 ©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)
 Complementation (not)
 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 - 5th Edition. 12.51 ©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
 Deletion needs to be handled properly
 Existence bitmap to note if there is a valid record at a record location
 Needed for complementation
 not(A=v): (NOT bitmap-A-v) AND ExistenceBitmap
 Should keep bitmaps for all values, even null value
 To correctly handle SQL null semantics for NOT(A=v):
 intersect above result with (NOT bitmap-A-Null)

Database System Concepts - 5th Edition. 12.52 ©Silberschatz, Korth and Sudarshan
 Efficient Implementation of Bitmap Operations

 Bitmaps are packed into words; a single word and (a basic CPU
instruction) computes and of 32 or 64 bits at once
 E.g. 1-million-bit maps can be and-ed with just 31,250 instruction
 Counting number of 1s can be done fast by a trick:
 Use each byte to index into a precomputed array of 256 elements
each storing the count of 1s in the binary representation
 Can use pairs of bytes to speed up further at a higher memory
cost
 Add up the retrieved counts
 Bitmaps can be used instead of Tuple-ID lists at leaf levels of
B+-trees, for values that have a large number of matching records
 Worthwhile if > 1/64 of the records have that value, assuming a
tuple-id is 64 bits
 Above technique merges benefits of bitmap and B+-tree indices

Database System Concepts - 5th Edition. 12.53 ©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 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 - 5th Edition. 12.54 ©Silberschatz, Korth and Sudarshan
 End of Chapter

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Partitioned Hashing
 Hash values are split into segments that depend on each
attribute of the search-key.
(A1, A2, . . . , An) for n attribute search-key
 Example: n = 2, for customer, search-key being
(customer-street, customer-city)
search-key value hash value
(Main, Harrison) 101 111
(Main, Brooklyn) 101 001
(Park, Palo Alto) 010 010
(Spring, Brooklyn)001 001
(Alma, Palo Alto) 110 010
 To answer equality query on single attribute, need to look up
multiple buckets. Similar in effect to grid files.

Database System Concepts - 5th Edition. 12.56 ©Silberschatz, Korth and Sudarshan
 Sequential File For account Records

Database System Concepts - 5th Edition. 12.57 ©Silberschatz, Korth and Sudarshan
 Sample account File

Database System Concepts - 5th Edition. 12.58 ©Silberschatz, Korth and Sudarshan
 Figure 12.2

Database System Concepts - 5th Edition. 12.59 ©Silberschatz, Korth and Sudarshan
 Figure 12.14

Database System Concepts - 5th Edition. 12.60 ©Silberschatz, Korth and Sudarshan
 Figure 12.25

Database System Concepts - 5th Edition. 12.61 ©Silberschatz, Korth and Sudarshan
 Grid Files
 Structure used to speed the processing of general multiple search-
key queries involving one or more comparison operators.
 The grid file has a single grid array and one linear scale for each
search-key attribute. The grid array has number of dimensions
equal to number of search-key attributes.
 Multiple cells of grid array can point to same bucket
 To find the bucket for a search-key value, locate the row and column
of its cell using the linear scales and follow pointer

Database System Concepts - 5th Edition. 12.62 ©Silberschatz, Korth and Sudarshan
 Example Grid File for account

Database System Concepts - 5th Edition. 12.63 ©Silberschatz, Korth and Sudarshan
 Queries on a Grid File
 A grid file on two attributes A and B can handle queries of all following
forms with reasonable efficiency
 (a1  A  a2)
 (b1  B  b2)
 (a1  A  a2  b1  B  b2),.
 E.g., to answer (a1  A  a2  b1  B  b2), use linear scales to find
corresponding candidate grid array cells, and look up all the buckets
pointed to from those cells.

Database System Concepts - 5th Edition. 12.64 ©Silberschatz, Korth and Sudarshan
 Grid Files (Cont.)
 During insertion, if a bucket becomes full, new bucket can be created
if more than one cell points to it.
 Idea similar to extendable hashing, but on multiple dimensions
 If only one cell points to it, either an overflow bucket must be
created or the grid size must be increased
 Linear scales must be chosen to uniformly distribute records across
cells.
 Otherwise there will be too many overflow buckets.
 Periodic re-organization to increase grid size will help.
 But reorganization can be very expensive.
 Space overhead of grid array can be high.
 R-trees (Chapter 23) are an alternative

Database System Concepts - 5th Edition. 12.65 ©Silberschatz, Korth and Sudarshan