Tutorial On B+Tree & Hash Indexing: Index

CSD Univ.
of Crete Fall 2005
TUTORIAL ON
B+TREE & HASH INDEXING
CSD Univ. of Crete Fall 2005
Index
l An index is a data structure that supports efficient access to data (i.e.,
row(s)) without having to scan entire table
l Based on a search key: rows having a particular value for the search key
attributes can be quickly located
Matching
Condition Set of records
on index Records
attribute
value
(search key)
2
Index Search Keys
l Candidate key vs search key:

u Candidate key: set of attributes; guarantees uniqueness
u Search key: sequence of attributes; does not guarantee
uniqueness
l Types of (search) keys

u Sequential: the value of the key is monotonic with the insertion
order (e.g., counter or timestamp)
u Non sequential: the value of the key is unrelated to the insertion
order (e.g., social security number)
Index Structure
l Index entries
u The row itself (index and table are integrated in this case), or
u Search key value and a pointer to a row having that value (table is
stored separately in this case)
l Location mechanism
u Algorithm + data structure for locating an index entry with a given
search key value
u Various data structures can serve as indexes, e.g.,
· simple indexes on sorted (sequential) files
· secondary indexes on unsorted (heap) files
· hierarchical index structures (B-trees)
· hash tables
l Index entries are stored in accordance with the search key value
u Entries with the same search key value are stored together (hash,
B+- tree)
u Entries may be sorted on search key value (B+- tree)
4
Index Structure
Search key S
value
Location Mechanism
Location mechanism
makes it easy to find
index entry for S
S Index entries
Once index entry

is found the row can
S, …….
be directly accessed
Storage Structure
l Structure of file containing a table
u Heap file (no index, not integrated)
u Sorted file (no index, not integrated)
u Integrated file containing index and rows (index entries contain rows
in this case) e.g.,
· ISAM
· B+ tree
· Hash
l The simplest of cases: given a sorted file (data file), create another file
(index file) consisting of key-pointer pairs:
u a search key K is associated with a pointer pointing to a record of the
data file that has the search key K 6
Integrated Storage Structure
Contains table
and (main) index
Index File With Separate Storage Structure
Location mechanism
Index entries
Index file
(secondary index)
Storage
structure
l In this case, the storage structure might
be a heap or sorted file, but is generally
an integrated file with a main index
8
Indices: The Down Side

l An index is itself an ordered file
u The index file is physically ordered on disk by the key field
u The index file has records of fixed length, containing: key field, pointer
to data <ki, pi>
l Additional I/O to access index pages (except if index is small enough to

fit in main memory)
l Index must be updated when table is modified
l SQL-92 does not provide for creation or deletion of indices

u Indexon primary key generally created automatically
u Vendor specific statements:
· CREATE INDEX ind ON Student (Code)
· DROP INDEX ind 9
Clustered Index
l Clustered index: index entries and rows are ordered in the same way
u An integrated storage structure is always clustered (since rows and
index entries are the same)
u The particular index structure (e.g., hash, tree) dictates how the rows
are organized in the storage structure
· There can be at most one clustered index on a table
u CREATE TABLE generally generally creates an integrated, clustered
(main) index
l Good for range searches when a range of search key values is requested
u Use location mechanism to locate index entry at start of range
· This locates first row
u Subsequent rows are stored in successive locations if index is
clustered (not so if unclustered)
u Minimizes page transfers and maximizes likelihood of cache hits 10
Clustered Main Index
Storage structure
contains table
and (main) index;
rows are contained
in index entries
11
Clustered Secondary Index
12
Unclustered Index
l Unclustered (secondary) index: index entries and rows are not ordered
in the same way
l A secondary index might be clustered or unclustered with respect to

the storage structure it references
u It is generally unclustered (since the organization of rows in the
storage structure depends on main index)
u There can be many secondary indices on a table
u Index created by CREATE INDEX is generally an unclustered,

secondary index
13
Unclustered Secondary Index
14
Example - Cost of Range Search
l Data file has 10.000 pages, 100 rows in range
l Page transfers for rows (assuming 20 rows/page):

u Heap: 10.000 (entire file must be scanned)
u File sorted on search key: log2 10.000 + (5 or 6) » 19
u Unclustered index: £ 100
u Clustered index: 5 or 6
l Page transfers for index entries (assuming 200 entries/page)

u Heap and sorted: 0
u Unclustered secondary index: 1 or 2 (all entries must be read)
u Clustered secondary index: 1 (only first entry must be read)
15
Sparse vs Dense Index

l Dense index: every record in the data file is in the index
u index entry for each data record (faster to locate a record)
· Unclustered index must be dense
· Secondary clustered index need not be dense
l Sparse index: not every record in the data file is in the index
u index entry for each page of data file
· index indicates the block of records
l A good compromise
u Sparse index with one index entry per block
u Tradeoff between access time and space overhead
16
Sparse vs Dense Index
Id Name Dept
Sparse,
clustered
index sorted
on Id
Dense,
data file sorted
unclustered
on Id
index sorted
on Name 17
Sparse Index
Search key should

be candidate key of
data file (else additional
measures required)
18
Multiple Attribute Search Key

l CREATE INDEX Inx ON Tbl (att1, att2)
l Search key is a sequence of attributes; index entries are lexically

ordered
l Supports finer granularity equality search:

u “Find row with value (A1, A2) ”
l Supports range search (tree index only):

u “Find rows with values between (A1, A2) and (A1¢, A2¢) ”
l Supports partial key searches (tree index only):

u Find rows with values of att1 between A1 and A1¢
u But not “Find rows with values of att2 between A2 and A2¢ ”
19
Locating an Index Entry
l Use scan (index entries not sorted)
l Use binary search (index entries sorted)

· If Q pages of index entries, then log2Q page transfers (which is
a big improvement over binary search of the data pages of a F
page data file since F >>Q)
l Use multilevel index: Sparse index on sorted list of index entries
20
Indexes on Sequential Files

l Sequential files: data file is sorted on the search key of the index
u useful when the search key is the primary key of the relation
u we can build a dense index, i.e., a sequence of blocks holding record
keys and pointers to the records
u index records are sorted in the same order as the resp. data records
l Index file is expected to occupy fewer blocks than data file
l Such an indexing scheme is particularly useful when the index file can fit
in main memory:
u given a search key, we can find any record with only one disk I/O
l Since keys are sorted, binary search can be used to find a key value in
the index file
l Example: relation R with 1.000.000 tuples of 400 bytes each; key: 30
bytes; pointer: 8 bytes; B = 4.096 (10 tuples in a block)
u ~100 key-pointer pairs in a block
u dense index requires 10.000 blocks (40 MB)
u need to access log2(10.000) » 13 blocks with binary search + 1 I/O
operation to find the data record 21
Indexes on Sequential Files

l Sparse Indexes
u if a dense index is too large, a sparse index uses less space (but
more time to locate a record given its key)
· for instance, a sparse index with one key-pointer pair per block
contains records that point to the first record of each data block
u sparse indexes require fewer blocks than dense indexes
l Example: need 1.000 index blocks (4MB) for the 100.000 data blocks
l A dense index can answer the query “Does there exist a record with key
value K?” without retrieving the block containing the record
l A sparse index needs a disk I/O to retrieve the block on which the record
with key K might be found
l To find a record with key K, we search the index for the largest key that
is < = K and follow the pointer to the data block; then we search the
block for the record
22
Multiple Index Levels

l Since index files can be large, an index on an index file may be built
u Not
all levels needs to be equally dense or sparse
l A sparse index may be built on a dense 1st-level index (otherwise the
2nd-level index would have as many records as the 1st-level index)
l Example 1: Sparse index occupies 1.000 blocks; a 2nd-level sparse index
would need only 10 blocks
u then to locate a record with a given key value, we need two I/Os
l Example 2: Consider 5.000.000 ordered records, 100 records/block, thus
50.000 blocks
u Sequential search: average of 50.000 / 2 blocks read
u Binary search: log 2 50.000 = 16
u Sparse 3nd-level index: 4 50,000 blocks
1 block 5 blocks 500 blocks
23
Two-Level Index
˜ Separator level is a sparse index over pages of index entries

˜ Leaf level contains index entries
˜ Cost of searching the separator level << cost of searching index level
since separator level is sparse
˜ Cost or retrieving row once index entry is found is 0 (if integrated) or 1 (if
not)
24
Multilevel Index
˜Search cost = number of levels in tree

˜If F is the fanout of a separator page, cost is logF Q + 1
˜Example: if F = 100 and Q = 10.000, cost = 3 (reduced to 2 if root is kept
in main memory)
25
Secondary Indices
l Must be dense
u Since the records are not physically stored in the search key order
l Can use multiple levels
u A sequential scan of the records in the search key of a secondary
index is often very slow
· Require many block accesses
l Updates of the data lead to updates of both indices
u A likely significant overhead on modification of the database 26
Secondary Indices
File not sorted on

secondary search key 30
50
20
70
80
40
100
10
90
60
27
Secondary Indices
Sequence
• Sparse index field
30
30 50
20
80 20
100 70
90 80
... 40
100
10
does not make sense! 90
60
28
Secondary Indices
10 30
20 50
10 30
40 20
50 70
90
... 50
60 80
70 40
sparse
high ... 100
level 10
90
Lowest level has to be dense 60
29
Indexes with Duplicate Search Keys

l If indexes are built on non-key attributes, then more than one record
may have a given key value
l Assume that the order of records with identical search key values does
not matter
l A dense index can be built with one entry with key K for each record that
has search key K
l Searching: look for the first record with key K in the index file and find all
the other records with the same value (they must immediately follow)
30
Duplicate Keys
l Different records can have

the same key value 10
10
l How to design the indexing
structure?
10
20
20
30
30
30
Index ???? 40
45
31
Duplicate Keys & Dense Index
Dense Index
10
10 10
10
10 10
20 20
20 20
30 30
30 30
30 30
40
Record pointer 45
32
Duplicate Keys & Better Dense Index
Dense Index
10
10 10
20
30 10
40 20
20
Record pointer 30
30
30
40
45
33
Duplicate Keys and Sparse Index
Sparse Index
10
10 10
10
20 10
30 20
Be careful
20
when searching 30
for 20 or 30! block pointer
30
30
40
45
34
Duplicate Keys and Better Sparse Index
– place first new key from block

10
10 10
20
30 10
30 20
20
30
block pointer
30
30
40
45
35
Duplicate Values & Secondary Indices
one option...
10 20
10 10
10
20 20
Problem: 40
20
excess overhead! 30 10
• disk space 40 40
• search time 40
10
40 40
40
... 30
40
36
another option: lists of pointers

10 20
10
20
Problem: 20 40
variable size
records in 10
40
index! 30
40 10
40
30
40
37
20 l
10 10
20
30 20
40 40
50 10
60 40
... 10 l
40
Yet another idea :
Chain records with same key? 30 l
40 l
Problems:
• Need to add fields to records, messes up maintenance
• Need to follow chain to know records 38
20
10 10
20
30 20
40 40
50 10
60 40
...
10
40
30
40
buckets
39
Why Bucket Idea is Useful?

Emp(name, dept, floor, …)
l Indexes:
u Name: primary
u Dept: secondary
u Floor: secondary
40
“Get employees in (Toy Dept) Ù (2nd floor)”
Dept. index EMP Floor index
Toy 2nd
Intersect toy bucket and 2nd Floor bucket to get set of matching EMP’s!!!
41
Index Update: Insertion
l Single-level index insertion

u Perform a lookup using the search-key value appearing in the record
to be inserted
u Dense indices – if the search-key value does not appear in the index,
insert it
u Sparse indices – if the 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
· In the case of a new block is created, the first search-key value
appearing in the new block is inserted into the index
l Multilevel insertion and deletion algorithms are simple extensions of the

single-level algorithms
42
Index Update: Deletion
l If deleted record was the only record in the file with its particular search-
key value, the search-key is deleted from the index
l Single-level index deletion

u Dense indices – deletion of the search-key is similar to file record
deletion
u 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
43
Index Reorganization for Data Modifications
l As data evolve, index structures need to be modified

u create overflow blocks if extra space is needed or delete overflow
blocks if records have been deleted
u overflow blocks do not have entries in a sparse index (they are
regarded as extensions of the primary blocks)
u instead of overflow blocks, we may insert blocks sequentially; then
new entries in the sparse index are needed
u If blocks are full, tuples may be inserted in adjacent blocks
u If adjacent blocks become too empty, they can be combined
l In general, changing an index file creates the same problems that
changes to the data file create
l Changes to be made depend on whether the index is dense or sparse
44
Index Reorganization for Data Modifications

l The following table summarizes how actions on a sequential data file
affect index files:
Action Dense Index Sparse Index

Create empty overflow block none none
Delete empty overflow block none none
Create empty sequential block none insert
Delete empty sequential block none delete
Insert record insert possibly update
Delete record delete possibly update
Slide record update possibly update
45
Index Data Structures

l Most index data structures can be viewed
as trees
l In general, the root of this tree will always
be in main memory, while the leaves will
be located on disk
u The performance of a data structure
depends on the number of nodes in
the average path from the root to the
B tree
leaf
u Data structure with high fan-out
(maximum number of children of an
internal node) are thus preferred Sequential Set
l B+-Tree: Amendment to B tree
u addresses for data records are in the
leaves and no where else
u a key value is stored once, with the
46
address of the associated data record
B+ Tree Properties
l A B+-Tree is a balanced tree whose leaves contain a sequence of key-
pointer pairs
u Same height for paths from root to leaf
u Given a search-key K, nearly same access time for different K values
l B+ Tree is constructed by parameter n, the maximum key capacity of a

node
u Each Node (except root) has é(n+1)/2ù to n+1 pointers
u Each Node (except root) has é(n+1)/2ù-1 to n search-key values
Case for n=2 General case for n

K1 K2 K1 K2 Kn
P1 P2 P3 P1 P2 Pn Pn+1
47
B+ Tree Properties
l Search keys are sorted in order
K1 K2
u K1 < K2 < … <Kn
P1 P2 P3
l Non-leaf Node S1 S2 S3
u Each key-search value in subtree Si pointed by Pi are < Ki and >=
Ki-1
u Key values in S1 < K1
u K1 <= Key values in S2 < K2
P3
P1 K1 K2 …
P2
l Leaf Node Record of K1 Record of K2
u Pi points record or bucket with Record of K2

search key value Ki …
u Pn+1 points to the neighbor leaf node
48
B+-Tree Order (Fan-out) n+1

l B+-Tree Order n+1:
u at least é(n+1)/2ù-1 and at most n key values at each internal node
and leaf
· internal nodes and leaves must always be at least half full (or half
empty)
u the root must contain at least one key and 2 pointers (thus 2 child
nodes) unless its a leaf
· can’t have an empty start point for a non-null tree
u for k key values at a node, there will be k+1 pointers to child nodes
· a node must have between é(n+1)/2ù and n+1 tree pointers

(child nodes)
49
B+ Tree Searching
l Given a search-value k
u Startfrom the root, look for the largest search-key value (Kl) in the
node which is <= k
u Follow pointer Pl+1 to next level, until reach a leaf node
Kl <= k < Kl+1
K1 K2 … Kl Kl+1 Kn
P1 P2 P3 Pl+1 Pn Pn+1
u If k is found to be equal to Kl in the leaf, follow Pl to search the
record or bucket
Kl Kl+1
Record of Kl Pl k = Kl
Record of Kl
… 50
B+ Tree Insertion
l Overflow
u When number of search-key values exceed n
Insert 8
7 9 13 15
l Leaf Node
u Split into two nodes:
· 1st node contains é(n+1)/2ù values
· 2nd node contains remaining values
· Copy the smallest search-key value of the 2nd node to parent node
7 8 9 13 15
51
B+ Tree Insertion (cont.)

l Non-Leaf Node
u Split into two nodes:
· 1st node contains é(n+1)/2ù-1 values
· Move the smallest of the remaining values, together with pointer, to
the parent
· 2nd node contains the remaining values
7 8 13 15
52
B+ Tree Deletion
l Underflow Delete 10
u When number of search-key values < é(n+1)/2ù-1 9 10
l Leaf Node 13 18
u Redistributeto sibling
9 10 13 14 16
· Right node not less than left node
· Replace the between-value in parent by their
smallest value of the right node 14 18
u Merge (contain too few entries)

9 13 14 16
· Move all values, pointers to left node
· Remove the between-value in parent
13 18 22 18 22
9 10 13 14 9 13 14 53
B+ Tree Deletion (cont.)

l Non-Leaf Node
13 18
u Redistribute to sibling
9 10 14 15 16
· Through parent
· Right node not less than left node
14 18
u Merge (contain too few entries) 9 13 15 16

· Bring down parent
· Move all values, pointers to left node
· Delete the right node, and pointers
in parent
13 18 22 18 22
9 10 14 16 9 13 14 16
54
Example on B+ Tree
l Construct a B+ tree
u Assume the tree is initially empty
u All paths from root to leaf are of the same length
u The number of pointers that will fit in one node is four (n=3)
u Leaf nodes must have between 2 and 3 values (ë(n+1)/2û and n)
u Non-leaf nodes other than root must have between 2 and 4 children
(é(n+1)/2ù and n+1)
u Root must have at least 2 children
55
Insertions
l Insert 2, 3, 5 2 3 5
l Insert 7, 11
2 3 5 7 11
Next: Insert 17 56
Insert 17
5 11
2 3 5 7 11 17
Next: Insert 19 57
Insert 19
5 11
2 3 5 7 11 17 19
Next: Insert 23 58
Insert 23
5 11 19
2 3 5 7 11 17 19 23
Next: Insert 29 59
Insert 29
5 11 19
2 3 5 7 11 17 19 23 29
Next: Insert 31 60
Insert 31
11
5 19 29
2 3 5 7 11 17 19 23 29 31
Next: Insert 9 61
Insert 9
11
5 19 29
2 3 5 7 9 11 17 19 23 29 31
Next: Insert 10 62
Insert 10
11
5 9 19 29
2 3 5 7 9 10 11 17 19 23 29 31
Next: Insert 8 63
Insert 8
11
19 29
5 9
2 3 5 7 8 9 10 11 17 19 23 29 31
Next: Delete 23 64
Delete 23
11
5 9 19
2 3 5 7 8 9 10 11 17 19 29 31
Next: Delete 19 65
Delete 19
11
5 9 19
2 3 5 7 8 9 10 11 17 29 31
Next: Delete 17 66
Delete 17
5 11
2 3 5 7 8 9 10 11 29 31
Next: Delete 10 67
Delete 10
5 29
2 3 5 7 8 9 11 29 31
Next: Delete 11 68
Delete 11
5 9
2 3 5 7 8 9 29 31
69
B+- Trees: Second Example

l Assume a student table: Student(name, age, gpa, major)
tuples(Student) = 16
pages(Student) = 4
Bob, 21, 3.7, CS Kane, 19, 3.8, ME Louis, 32, 4, LS Chris, 22, 3.9, CS
Mary, 24, 3, ECE Lam, 22, 2.8, ME Martha, 29, 3.8, CS Chad, 28, 2.3, LS
Tom, 20, 3.2, EE Chang, 18, 2.5, CS James, 24, 3.1, ME Leila, 20, 3.5, LS
Kathy, 18, 3.8, LS Vera, 17, 3.9, EE Pat, 19, 2.8, EE Shideh, 16, 4, CS
70
Non-Clustered Secondary B+-Tree

l A non-clustered secondary B+-tree on the gpa attribute
3.6
(2.3, (4, 2)) (3, (1,2)) (3.7, (1, 1)) (3.9, (4,1))
(2.5, (2,3)) (3.1, (3,3)) (3.8, (3,2)) (3.9, (2,4))
(2.8, (2,2)) (3.2, (1,3) (3.8, (2,1)) (4, (3,1))
(2.8, (3,4)) (3.5, (4,3)) (3.8, (1,4)) (4, (4,4))
71
Non-Clustered Primary B+-Tree

l A non-clustered primary B+-tree on the gpa attribute
3.6
(2.3, (1, 1)) (3, (2,1)) (3.7, (3, 1)) (3.9, (4,1))
(2.5, (1,2)) (3.1, (2,2)) (3.8, (3,2)) (3.9, (4,2))
(2.8, (1,3)) (3.2, (2,3) (3.8, (3,3)) (4, (4,3))
(2.8, (1,4)) (3.5, (2,4)) (3.8, (3,4)) (4, (4,4))
Chad, 28, 2.3, LS Mary, 24, 3, ECE Bob, 21, 3.7, CS Chris, 22, 3.9, CS
Chang, 18, 2.5, CS James, 24, 3.1, ME Kathy, 18, 3.8, LS Vera, 17, 3.9, EE
Lam, 22, 2.8, ME Tom, 20, 3.2, EE Kane, 19, 3.8, ME Louis, 32, 4, LS
Pat, 19, 2.8, EE Leila, 20, 3.5, LS Martha, 29, 3.8, CS Shideh, 16, 4, CS 72
Clustered B+-Tree
l A clustered B+-tree on the gpa attribute
2.9 3.6 3.8
Chad, 28, 2.3, LS Mary, 24, 3, ECE Bob, 21, 3.7, CS Chris, 22, 3.9, CS
Chang, 18, 2.5, CS James, 24, 3.1, ME Kathy, 18, 3.8, LS Vera, 17, 3.9, EE
Lam, 22, 2.8, ME Tom, 20, 3.2, EE Kane, 19, 3.8, ME Louis, 32, 4, LS
Pat, 19, 2.8, EE Leila, 20, 3.5, LS Martha, 29, 3.8, CS Shideh, 16, 4, CS
l It is impossible to have a clustered secondary B+-tree on an attribute

73
Clarifications on B+ Trees
l B+ trees can be used to store relations as well as index structures
l In the drawn B+ trees we assume (this is not the only scheme) that an
internal node with q pointers stores the maximum keys of each of the
first q-1 subtrees it is pointing to; that is, it contains q-1 keys
l Before B+-tree can be generated the following parameters have to be
chosen (based on the available block size; it is assumed one node is
stored in one block):
u the order p (n+1, so far) of the tree (p is the maximum number of
pointers an intermediate node might have; if it is not a root it must
have between ((p+1)/2) and p pointers; ‘/’ is integer division)
u the maximum number m of entries in the leaf node can hold (in
general leaf nodes (except the root) must hold between (m+1)/2 and
m entries)
l Internal nodes usually store more entries than leaf nodes
74
Why is the minimum number of pointers in an

intermediate node (p+1)/2 and not p/2 + 1??
l (p+1)/2: Assume p=10; then p is between 5 and 10; in the case of
underflow without borrowing, 4 pointers have to be merged with 5
pointer yielding a node with 9 pointers
l p/2 + 1: Assume p=10; then p is between 6 and 10; in the case of
underflow without borrowing, 5 pointers have to be merged with 6
pointer yielding 11 pointers which is one too many
l If p is odd: Assume p=11, then p is between 6 and 11; in the case of an
underflow without borrowing a 5 pointer node has to be merged with a 6
pointer node yielding an 11 pointer node
l Conclusion: We infer from the discussion that the minimum vs.
maximum numbers of entries for a tree
u of height 2 is: 2*((p+1)/2)*((m+1)/2) vs. p*p*m
u of height 3 is: 2* ((p+1)/2)* ((p+1)/2)* ((m+1/2) vs. p*p*p*m

n n+1
u of height n+1 is: 2*((p+1)/2) *((m+1)/2) vs p *m
75
Choosing Order p and Leaf Entry Maximum m

l Idea: One B+-tree node is stored in one block; choose maximal m and p
without exceeding block size!!
l Example1: Want to store tuples of a relation E(ssn,name,salary) in
a B+-tree using ssn as the search key (alternative u); ssn, and salary
take 4 Byte; name takes 12 byte. B+-pointers take 2 Byte; the block size
is 2.048 bytes and the available space inside a block for B+-tree entries
is 2.000 byte. Choose p and m!!
u p*2 + (p-1)*4 ≤2.000 àp ≤ 2.004/6=334
u m ≤ 2000/(4+12+4) = 2000/20
u Answer: Choose p=334 and m=100!
B+-tree Block Meta Data B+-tree Block Meta Data:

Block Storage for Neighbor pointers, #entries,
B+-tree node entries Parent pointer, sibling bits,…
76
Choosing Order p and Leaf Entry Maximum m

l Example2: Want to store an index for a relation E(ssn,name,salary)
in a B+-tree using ssn as the search key; storing ssn’s takes 4 Bytes;
index pointers take 4 Bytes; the block size is 2.048 byte and the available
space inside the block for B+-tree entries is 2.000 byte. Choose p and m!!
u p*4 + (p-1)*4 ≤ 2.000 àp ≤ 2.004/8=250
u m ≤ 2.000/(4 + 4) = 2.000/8 = 250
u Answer: Choose p=250 and m=250
77
Coping with Duplicate Keys in B+ Trees

l Possible Approaches:
u Just allow duplicate keys
Consequences:
· Search is still efficient
· Insertion is still efficient (but could create “hot spots”)
· Deletion faces a lot of problems: We have to follow the leaf
pointers to find the entry to be deleted, and then updating the
intermediate nodes might get quite complicated (can partially be
solved by creating two-way node pointers)
v Just create unique keys by using key+data (key*)
Consequences:
· Deletion is no longer a problem
· p (because of the larger key size) is significantly lower, and
therefore the height of the tree is likely higher 78
Duplicate Keys in B+ Trees (first approach)
l In a non-leaf node, Ki is the smallest new value appearing in subtree

pointed to by (i+1) pointer. If there is no new value, Ki = NULL.
79
Duplicate Keys in B+ Trees (first approach)

l Search algorithm the same but if you reach a leaf, you must be prepared
to search the sibling if last value of leaf = search value
l Insertion algorithm is the same, but attention must be kept when an old
value is inserted in a leaf and we must split
u The parent might get a NULL key value pointing to the second leaf of
the split
l Deletion algorithm is the same, but attention must be kept when there is
underflow, because in this case parent node must be updated
80
Duplicate Key Insertion in a B+Tree
l Initial B+Tree as below. Insertion of 13 two times.
81
Duplicate Key Insertion in a B+Tree
82
B+-Tree Performance
l Tree levels
u Tree Fanout
· Size of key
· Page utilization
l Tree maintenance
u Online
· On inserts
· On deletes
u Offline
l Tree locking
l Tree root in main memory

83
B+-Tree Performance
l Key length influences fanout

u Choose small key when creating an index
u Key compression
· Prefix compression (Oracle 8, MySQL): only store that part of the
key that is needed to distinguish it from its neighbors: Smi, Smo,
Smy for Smith, Smoot, Smythe.
· Front compression (Oracle 5): adjacent keys have their front
portion factored out: Smi, (2)o, (2)y. There are problems with this
approach:
· Processor overhead for maintenance
· Locking Smoot requires locking Smith too
84
B+-Tree Locking
l Tree Traversal
u Update, Read
u Insert, Delete
· phantom problem: need for range locking
l ARIES KVL (implemented in DB2)

· Tree Traversal (next page)
· Lock on tuples
· Lock on key values
· Range locking: 2 4 4
· Next key lock
85
B+-Tree Locking
T1 lock
A
B C
T1 lock T1 lock
D
E F
86
Using Indexes: First Example

l Executives(ename, title, dname, address)
l Each attribute is 25 bytes, page size is 1.000 bytes; i.e., we store 10
records per page (record size = 100 bytes)
l Relation contains 100.000 records, 10.000 pages
l Consider query: SELECT E.title, E.ename
FROM Executives E
WHERE E.title = ‘MANAGER’
l Assume only 10% of tuples meet the selection condition
u Selectivity S = 0,1
l Pointer size = 5 bytes; index entry size = 30 (5+25); index entries per
page = 33
l Assume that there are 1.000 job titles. Index on job title contains only
two levels (assuming that all index nodes are full)
87
Using Indexes: First Example (cont.)
l Sequential scan of files

u Cost = File size = 10.000
l Binary search for file (sorted on title)
u Cost = log2(File size) + # file pages containing qualifying records =
log2(10.000) + 1.000= 1.013
u Here we could also say log2(10.000) + 999, since the first page
containing Manager records is retrieved by binary search
l Clustered B+ tree index on title (file sorted on title)
u Cost = index lookup + (File size) *S = 2 + (10.000)*0.1=1.002
u We use the index to retrieve the first record - since the file is clustered,
the remaining Manager records are stored sequentially after the first one
l Clustered B+ tree index on ename
u No use of index. File Scan
88
Using Indexes: First Example (cont.)

l Unclustered B+ tree index on title
u Cost = index lookup + # of records * S + size of block of pointers
u Cost = 2 + 100.000*0,1 + 10.000/200 = 2+10.000+50 =10052 (we can
put 200 pointers per block i.e., 1.000/5)
l Clustered B+ tree index on <title, ename>

u Cost = index lookup + # of index entries * 0,1 (The index now has
larger size, since each entry is 55 bytes)
l Clustered B+ tree index on <ename, title>

u Index only scan, Cost = # of index entries
89
Using Indexes: Second Example

l Assume that relation R(A,B,C) has the following properties:
u R has 54.000 tuples
u 20 tuples of r can fit in 1 block
u Attribute A is an integer with range from 1 to 270
u Attribute values are uniformly distributed in the relation
u Tuples with the same attribute value of A are put in the same block
and blocks with the same attribute value of A are chained by pointers
u There is a B+ Tree indexing on A, which stores 10 pointers per node
l What is the minimum Height of the B+ Tree? How many block accesses
for the following query using B+ Tree with min. height?
SELECT A
FROM r
WHERE A = 150
90
Using Indexes: Second Example (cont.)

l The height of tree would be minimum when space of each node is fully
occupied
=> Each node has 10 pointers to the next level node
=> Height = log10(270) = 2,43
=> Minimum Height is 3
l Number of data blocks = 54.000 tuples / 20 = 2.700
l Number of data blocks for each value of A = 2.700 / 270 = 10
l To implement the query, we give A=150 as the search-key value to the

B+ Tree and we need to access 3 level (3 index block) to find out the
blocking storing tuples with A=150
l Total no. of block access = index block access + data block access = 13 91
B+ trees Summary
l Sequential and direct access

l Straightforward insertion and deletion maintaining ordering
l Grows as required—only as big as needs to be
l Predictable scanning pattern
l Predictable and constant search time
but ..…
l maintenance overhead
l overkill for small static files
l duplicate keys?
l relies on random distribution of key values for efficient insertion
92
Simple Hashing Algorithm

l Hash function: a function h(K) transforms a key K into an address
l Example: Take first two characters of the name, multiply their ASCII
representations
l Difference between hashing/indexing:
u Addresses generated appear to be random
u Two different keys may be transformed to the same address
l Ideal: Should spread out records as uniformly as possible over the
range of addresses
l Does the previous sample ensure this? Let’s improve it
l Step 1: Represent the key in numerical form
L O W E L L < BLANKS >
76 79 87 69 76 76 32 32 32 32 32 32
u Using more parts of a key – key differences cause hash value
differences
u Extra processing time: significant? 93
Simple Hashing Algorithm

Step 2 : Fold & Add
l Chop off with two ASCII numbers each:
76 | 79 | 87 | 69 | 76 | 76 | 32 | 32 | 32
Need to care: overflow. Define a ceiling value
Decide a prime number < 32767. Eg: 19937
7679 + 8769 à 16448 à 16448 mod 19 937
16448 + 7676 à 24124 à 24124 mod 19 937
4187 + 3232 à 7419 à 7419 mod 19 937
7419 + 3232 à 10651 à 10651 mod 19 937
10651 + 3232 à 13883 à 13883 mod 19 937
Division by a prime number usually produces more random distribution
Step 3: Divide by the Size of the Address Space:
l Shrink the size of the number within the range of address records
l a = s mod n
l s = 13883 , File size 100
l a will be 83. Advice : Decide file size as 101. Why? 94
Hashing
l Buckets:
u Set up an area to keep the records: Primary area
u Divide primary area into buckets
u Issue: Non-uniform distribution of the records
u More than one key may give same key number: Collision
l Separate Chaining:
u New record with the same hash function value has been added:
How to solve?
u Add the address of a new bucket in a special area called overflow
area
u Keep some overflow area in each cylinder
95
Static Hashing
l Static Hashing
uA hash function h maps a search-key value K to an address of a
bucket
u Commonly used hash function hash value mod nB where nB is the no.
of buckets
u E.g. h(Brighton) = (2+18+9+7+8+20+15+14) mod 10 = 93 mod 10 = 3
No. of buckets = 10
Brighton A-217 750

Hash function h Round Hill A-305 350
. .
. . 96
Static Hashing
l Assume 2 data entries per bucket and we have 5 buckets

l Insert key values a,b,c,d,e,f,g where h(a)=1,h(b)=2,h(c)=3,…h(g)=7
Insert z,x where Insert p,q,r where h(p)=1,
h(z)=1 and h(x)=5 h(q)=5, and h(r)=1
97
Static Hashing
l Clustered Hash Index :
u The index structure and its buckets are represented as a file (say
file.hash)
u The relation is stored in file.hash (I.e., each entry in file.hash
corresponds to a record in relation)
u Assuming no duplicates: the record can be accessed in 1 I/O
l Non-clustered Hash Index:

u The index structure and its buckets are represented as a file (say
file.hash)
u The relation remains intact
u Each entry in file.hash has the following format: (search-key value,

RID)
u Assuming no duplicates: the record can be accessed in 2 I/O 98
Static Hashing Example

l Assume a student table: Student(name, age, gpa, major)
tuples(Student) = 16
pages(Student) = 4
99
Non-Clustered Hash Index Example

l A non-clustered hash index on the age attribute with 4 buckets,
l h(age) = age mod B
(24, (1, 2)) (20, (4,3)) (18, (1, 4))
(32, (3,1)) (16, (4,4)) (22, (2,2))
(20, (1,3)) (24, (3,3)) (22, (4,1))
0
1 (28, (4,2)) (18, (2,3))
2 (21, (1, 1)) (19, (2, 1))
3 (17, (2,4)) (19, (3, 4))
(29, (3,2))
Kathy, 18, 3.8, LS Vera, 17, 3.9, EE Pat, 19, 2.8, EE Shideh, 16, 4, CS100
Clustered Hash Index Example

l A clustered hash index on the age attribute with 4 buckets,
l h(age) = age mod B Kathy, 18, 3.8, LS
Lam, 22, 2.8, ME
Mary, 24, 3, ECE Chris, 22, 3.9, CS
Louis, 32, 4, LS Chang, 18, 2.5, CS
Tom, 20, 3.2, EE
Chad, 28, 2.3, LS
0 Shideh, 16, 4, CS
1 Bob, 21, 3.7, CS
Leila, 20, 3.5, LS
2 Vera, 17, 3.9, EE
3 James, 24, 3.1, ME
Martha, 29, 3.8, CS
Kane, 19, 3.8, ME

Pat, 19, 2.8, EE
101
Non-Clustered Hash Index Example

l A non-clustered hash index on the age attribute with 4 buckets,
1001 500
l h(age) = age mod B
(21, (1, 1)) (24, (1, 2)) (20, (4,3))
l Pointers are page-ids (32, (3,1)) (16, (4,4))
(17, (2,4))
(29, (3,2)) (20, (1,3)) (24, (3,3))
0 500
1 1001 (28, (4,2))
2 706 101 706
3 101 (18, (1, 4))
(19, (2, 1))
(19, (3, 4)) (22, (2,2))
(22, (4,1))
(18, (2,3))
Kathy, 18, 3.8, LS Vera, 17, 3.9, EE Pat, 19, 2.8, EE Shideh, 16, 4, CS102

(SEQUENTIAL LAYOUT)
l h(age) = age mod 4
l When the number of buckets are known in advance, the system may
assume a sequentially laid file to eliminate the need for the hash directory
Shideh, 16, 4, CS
Leila, 20, 3.5, LS
James, 24, 3.1, ME
Mary, 24, 3, ECE Bob, 21, 3.7, CS Kathy, 18, 3.8, LS Kane, 19, 3.8, ME
Louis, 32, 4, LS Vera, 17, 3.9, EE Lam, 22, 2.8, ME Pat, 19, 2.8, EE
Tom, 20, 3.2, EE Martha, 29, 3.8, CS Chris, 22, 3.9, CS
Chad, 28, 2.3, LS Chang, 18, 2.5, CS 103

(SEQUENTIAL LAYOUT)
l h(age) = age mod 4
l When the number of buckets are known in advance, the system may
assume a sequentially laid file to eliminate the need for the hash directory
Offset (bucket-id –1)
Shideh, 16, 4, CS
times page size is for
Leila, 20, 3.5, LS
bucket-id
James, 24, 3.1, ME
Offset 0 is for bucket 0
Offset Page Size is for bucket 1
Mary, 24, 3, ECE Bob, 21, 3.7, CS Kathy, 18, 3.8, LS Kane, 19, 3.8, ME
Louis, 32, 4, LS Vera, 17, 3.9, EE Lam, 22, 2.8, ME Pat, 19, 2.8, EE
Tom, 20, 3.2, EE Martha, 29, 3.8, CS Chris, 22, 3.9, CS
Chad, 28, 2.3, LS Chang, 18, 2.5, CS 104
Deficiencies of Static Hashing

l In static hashing, function h maps search-key values to a fixed set of B
of bucket addresses
u Databases grow with time. If initial number of buckets is too small,
performance will degrade due to too much overflows
u If file size at some point in the future is anticipated and number of
buckets allocated accordingly, significant amount of space will be
wasted initially
u If database shrinks, again space will be wasted
u One option is periodic re-organization of the file with a new hash

function, but it is very expensive
l These problems can be avoided by using techniques that allow the

number of buckets to be modified dynamically
105
Load Factor
l The Load Factor:
u Lf: The number of records in the file divided by the number of places for
the records in the primary area
u Primary area should be 70 % to 90 % full
l Lf = R / (B * c)
u Lf à Load factor
u R à # of records in the file
u c à # of records which one bucket can hold
u B à # of buckets (blocks) in the primary area
l How the choice of Lf & c can affect time for fetching a record?
Fetching Using Buckets & Chains
As long as there is no overflow,
Tf = s + r + dtt
s à average seek time
r à average rotational latency
dtt à time to transfer the data in one bucket 106
Fetching using Buckets & Chains
l Result: If the distribution of values is even, and original areas are

chosen big enough, hashing is very efficient
u Contradiction: Larger bucket factor also means a larger dtt!
u Each access to a bucket takes longer
l Handling overflow buckets: Same size as primary buckets or smaller
l To sum up:
u Performance can be enhanced by the choice of bucket size and of
load factor
u Space utilization: Policy for handling overflow
u If the file size does not grow so much, hashing can give excellent
performance & space utilization
107
Database Growth
l Consider a database grows too much. Will buckets suffice?
l x à average chain length on the overflow
l Tf (successful) = s + r + dtt + (x/2) * (s + r + dtt)
u One access to get to the first record in the chain
u Traverse half of the chain?
l Tf (unsuccessful) = s + r + dtt + x * (s + r + dtt)
u One access to get to the first record in the chain
u Traverse the whole part of the chain
l Deletion:
u Merely mark the deleted record; when the whole hash table is
reorganized, marked records are not copied to the new table
u Replace the deleted record with the last record; de-allocate empty
buckets
· Cost : Td = Tf (unsucessful) + 2r
108
Database Growth
l Insertion:
u New insertions are at the end of the chain
u Assume, no new buckets are necessary
· Ti = Tf (unsuccessful) + 2r (A fetch and a rotation of the disk)
l Sequential Operations:
u Hashing is useless for Sequential operations. Why?
u Given than n sequential reads are to processed: Tx = n * Tf
l If the growth of a file can be predicted, hashing with buckets is excellent
u Range queries? No!
u Mixture of sequential operations, range searches, and individual
searches: Prefer B+ trees
l File grows considerably: Reorganization is necessary
u Linear hashing
u Bounded Index Extensible Hashing
u No file reorganization is required 109
Extensible Hashing
l Extensible Hashing
u Hash function returns b bits
u Only the prefix i bits are used to hash the item
u There are 2i entries in the bucket address table
u Let ij be the length of the common hash prefix for data bucket j, there
are 2(i-ij) entries in bucket address table points to j
Bucket address table Data bucket
Hash prefix i i1 Length of common hash prefix

bucket1
i2
bucket2
i3
bucket3
110
Splitting
l Splitting - Case 1: ij=i
u Only one entry in bucket address table points to data bucket j
u i++; Split data bucket j to j, z; ij=iz=i; Rehash all items previously in j;
2 3 3
000
00 2 001
01
010 2
10
011
11
100
1 101
110 1
111
111
Splitting (cont.)
l Splitting - Case 2: ij< i

u More than one entry in bucket address table point to data bucket j
u Split data bucket j to j, z; ij = iz = ij +1; Adjust the pointers
previously point to j to j and z; Rehash all items previously in j;
2
3 2 3
000 000 2
001 001
010 010
2
011 011
100 100 2
101 101
110 1 110
111 111
2
112
Extensible Hashing: First Example
l Show the extensible hash structure if the hash function is h(x)=x mod 8
and buckets can hold three records
l Insert 2, 3, 5
0 0
0… 2, 3, 5
Next: Insert 7 113
Insert 7
1
2, 3
1
0…
1
1…
5, 7
Next: Insert 11 114

Insert 11
1
2, 3, 11
1
0…
1
1…
5, 7
Next: Insert 17 115
Insert 17
2
17
2
2
00…
2, 3, 11
01…
10…
1
11… 5, 7
Next: Insert 19 116

Insert 19
2
3
17
000
001 3
010 2
011
3
100
3, 11, 19
101
110 1
111 5, 7
Next: Insert 23 117
Insert 23
2
3
17
000
001 3
010 2
011
3
100
3, 11, 19
101
110 1
111 5, 7, 23
Next: Insert 29 118
Insert 29
2
3 17
000
001 3
010 2
011 3
100 3, 11, 19
101
2
110
5, 29
111
2
Next: Insert 31 7, 23 119
Insert 31
2
3 17
000
001 3
010 2
011 3
100 3, 11, 19
101
2
110
5, 29
111
2
Next: Delete 17 7, 23,31 120
Delete 17
2
3
000
001 3
010 2
011
3
100
3, 11, 19
101
2
110
111 5, 29
2
Next: Insert 17, 27 7, 23,31 121
Insert 17, 27
2
3
17
000
001 3 Overflow bucket
.vs. dir doubling
010 2 Why?
011
3 3
100
3, 11, 19 27
101
2
110
111 5, 29
Next: Delete 27, 19, 11, 3 7, 23,31 122

Delete 27, 19, 11, 3 (reduce to 2 level)
2
17
2
2
00
01 2
10
2
11
5, 29
2
7, 23,31
123
Extensible Hashing: Second Example
v h(v)
pete 11010
mary 00000
jane 11110
bill 00000
john 01001
vince 10101
Location
karen 10111
mechanism
˜Extensible hashing uses a directory (level of indirection) to accommodate

family of hash functions
˜Suppose next action is to insert sol, where h(sol) = 10001
˜Problem: This causes overflow in B1
124

Solution:
1. Switch to h3
2. Concatenate copy of old
directory to new directory
3. Split overflowed bucket, B,
into B and B¢, dividing
entries in B between the
two using h3
4. Pointer to B in directory
copy replaced by pointer
to B¢
˜Note: Except for B¢ , pointers in directory copy refer to original buckets

¿current_hash identifies current hash function
125
Next action: Insert judy,

where h(judy)=00110
B2 overflows, but directory
need not be extended
˜Problem: When Bi overflows, we need a mechanism for deciding

whether the directory has to be doubled
˜Solution: bucket_level[i] records the number of times Bi has been split
¿If current_hash > bucket_level[i], do not enlarge directory
126
127
Linear Hashing (LH)

l Proposed by Litwin in 1981, linear hashing can, just like extendible hashing,
adapt its underlying data structure to record insertions and deletions:
u Linear hashing does not need a hash directory in addition to the actual
hash table buckets,
u Maintains a constant load factor; Incrementally add new buckets to the
primary area; Lf = R / (B * c) B à # of buckets c à #records per block
u . . . but linear hashing may perform bad if the key distribution in the data
file is skewed
l The core idea behind linear hashing is to use an ordered family of hash
functions, h0, h1, h2, . . . (traditionally the subscript is called the hash
function’s level);
u Calculate a hash number for a given level
u Calculate boundary value: c * Lf
u Place the record according to its last k digits
u In case an expand required, split an existing bucket using its k+1 last
digits of the hash number
l Note: Boundary value & current value of k should be kept on the file header 128
Linear Hashing (LH): Hash Function Family

l We design the family so that the range of hlevel+1 is twice as large as the
range of hlevel (for level = 0,1,2, ... ) as depicted below
u Here, hlevel has range [0 . . . B − 1]
(i.e., a range of size B)
l Given an initial hash function h and an initial hash
table size B, one approach to define such a family
of hash functions h0, h1, h2, . . .would be
u hlevel(k)=h(k)mod(2level×B)for level=0,1,2,…
B
B
B
B
B
B 129
Linear Hashing (LH): Basic Scheme

l Start with level = 0, next = 0
l The current hash function in use for searches
(insertions /deletions) is hlevel, active hash
table buckets are those in hlevel’s range: B
[0 . . . 2level×B − 1] B
l Whenever we realize that the current hash table overflows, e.g.,
u insertions filled a primary bucket beyond c % capacity,
u or the overflow chain of a bucket grew longer than p pages, or . . .
we split the bucket at hash table position next (in general, this is not the
bucket which triggered the split!)
uAllocate a new bucket, append to it the hash table (its position will be
2level×B+next),
vRedistribute the entries in bucket next by rehashing them via hlevel+1
(some entries remain in bucket next, some go to bucket 2levelB
+next),
wIncrement next by 1 130
Linear Hashing (LH): First Example

l Linear hash table: primary bucket capacity of 4, initial hash table size N =
4, level = 0, next = 0
u Split criterion: allocation of a page in an overflow chain
Next: Insert 43
131

l Insert record with key k such that h0(k) = 43 = 1010112:
Next: Insert 37
132

00
Next: Insert 29
133

00
01
Next: Insert 22, 66, 34
134

l Insert 3 records with keys k such that h0(k) = 22 = 101102 (66 =
10000102, 34 = 1000102):
00
01
Next: Insert 50
10
135

136
Insertion into Linear Hash Tables

l To insert record with key K (alternative algorithm):
u Compute h(K) and determine the i-bit rightmost (most significant)
sequence of h(K) to use as the bucket number
· for a record with key K we have h(K)=b=a1a2…ai, then if b<B the
bucket with number b exists and the record is placed there
· If B£b<2i, then the bucket does not exist and we have to place
the record in bucket b–2i-1 (this is the bucket we would obtain if
a1 changed to 0)
l Each time an insertion needs to be performed, we examine the ratio R/B
and if it is too high, we increase B by 1 (R the # of records in hash table)
l If the bucket we add has number 1a2…ai, then we split the bucket
numbered 0a2…ai and divide the records depending on their last I bits
l If B>2i then i is incremented by 1 (leading 0 is added)
137
Linear Hashing: Second Example

l Example: 2 keys/block, R=3, B=2, Level =1 assume h produces 4-bit
sequences (k=4)
•insert 0101
0000 0101 •now R=4 >1.7B (R/B = 2) Rule
1010 1111 à B++ Level++
à get new bucket 10 and distribute
00 01 keys between buckets 00 and 10
Rule If h(k)[i] = (a1 … ai)2 < B, then

look at bucket h(k)[i];
else
look at bucket h(k)[i] - 2i-1 = (0a2 … ai)2
138

-> R=4, B=3, Level =2;
distribute keys between buckets 00 and 10:
0000 0101 1010

1010 1111
00 01 10
•now R=4 >1.7B (R/B = 1.33) !
139

R=4, B=3, Level =2; insert 0001:
0001 • can have overflow chains!

• now R/B becomes 5/3 < 1.7
0000 0101 1010

1111
00 01 10
140

R=5, B=3, Level =2 • insert
0111
0001 • bucket 11 not in use
0111
à redirect to 01
• now R=6 > 1.7B

0000 0101 1010 à get new bucket 11
1111
00 01 10
Rule If h(k)[i] = (a1 … ai)2 < B, then

look at bucket h(k)[i];
else
look at bucket h(k)[i] - 2i-1 = (0a2 … ai)2
141

R=6, B=4, Level =2; distribute keys between 01 and 11
0001
0111
0000 0101 1010 1111

1111
0001 0111
00 01 10 11
Overflow block no longer needed !

142

Example Continued: How to grow beyond this?
B++
Level++ ( 2) 3
0000 0101 1010 1111 0101

0101 0101
000 010 10 0 11 0 100 101
...
101 110 111
m = 11 (max used block)
100
101
143
Linear Hashing: Third Example

l Calculate hash function
l Look at the last k digits
of the hash function
u If k digit is less than
boundary value,
then k+1
u Follow overflow
chains, as with
traditional hashing boundary value
l If k=3 & boundary value
is 011
l 1000=8; use 4 digits
l 1101=13; use 3 digits
l Comment: Some buckets
used twice as others;
fetch time decreases 144

l Search for the correct bucket in which to place
uIf the bucket is full, allocate a new overflow bucket, address it &
insert record
u If there are Lf * c records more than needed add more bucket to the
primary area
u Distribute the records relating to new bucket
u For each insertion, add 1 to the boundary value
l Example:
u Initially 8 primary areas
u Load factor of 70 %
u Bucket factor of 10
u Initially 56 records
u Add a bucket for each 0,7 * 10 = 7 record insertion

145
146

l Bucket factor is 3
l Load factor is 67 %
l Started with 4 buckets
l Make eight insertions
l See figure on the next slide:
l Overflow and table expansions are independent events
l Overflow doesn’t trigger table expansion. Neither does the opposite!
l Last words:
l Ti= Tf(unsuccessful) + 2r + (1/c * (s+r+dtt))
147

l A sample problem in
linear hashing: We
begin with 8 records
in 4 primary area
buckets
l The load factor is
67% (2/3), and the
bucket factor is 3
l After the initial
loading, whenever
we insert 2 records,
we expand the table
by 1 bucket
148
l Replace the deleted record with the last record in the chain
l If the last overflow is empty, de-allocate it
l When c * Lf is less than # needed, decrement primary area by
one bucket
l Exactly opposite of Insertion

l Occasionally, last bucket in the chain is de-allocated
l Td = Tf(unsuccessful) + 2r
149
Deletion
l Linear hashing table
contraction: To keep
the load factor constant,
the hash table can be
contracted by 1 bucket
every time there are
Lf*c records less than
are needed for the fixed
Now delete 4 records from 010, deallocating the chain. Also delete 2 records from load factor desired. On
011 to 1 from 1000. Then contract the table.
the right, where the
load factor is 70% and
the bucket factor is 10,
a bucket is removed
from the primary area
whenever there are 7
records less than
needed for a Lf of 70%
150
Constructing a Hash Table for given data
l There exists a file, we want to set up hashing

l Construction time is high:
l R * (r + s + dtt + 2r )
uOne access fetch and a modify for each record
l Option 1:
u Read in the file and calculate hash values for each record
u Sort by hash value
l Option 2:
u Partition the space of hash values
u Load some partition of the file, do hashing, write back disk…
151
Hash-Index Summary
l Extendible Hashing avoids overflow pages by splitting a full bucket when a
new data entry is to be added to it (duplicates may require overflow pages)
u If directory fits in memory, equality search answered with one disk
access; else two
u Directory grows in spurts, can become large for skewed hash
distributions
· Collisions, or multiple entries with same hash value cause problems!
l Linear Hashing avoids directory by splitting buckets round-robin, and using
overflow pages
u Overflow pages not likely to be long
u Duplicates handled easily
u Space utilization could be lower than Extendible Hashing, since splits
not concentrated on “dense” data areas
· Can tune criterion for triggering splits to trade-off slightly longer
chains for better space utilization
l For hash-based indexes, a skewed data distribution is one in which the
hash values of data entries are not uniformly distributed! 152
Hash-Index Summary
l Hashing is the best file structure for single-record fetches (e.g., ATM,
airline reservations):
u Insertion & deletions are very fast
u There are more insertions than deletions
u Reorganization schemes: Linear & Bounded Extensible Hashing
l Linear Hashing:
l As new records are added, new buckets are appended to the primary
area
l Load factor is kept constant
l Bounded Extensible Hashing:
l After index reaches a predetermined size, primary area buckets
double in size
l First few digits of the hash number give the location of the index entry
in memory
l Next few determine the address of the data bucket
l Subsequent digits yield the offset of the block 153
Hash-Index Summary
l No hashing method is convenient for sequential operations or for range

searches
u B+ trees are recommended especially for range searches
l Formulas:
u Load factor is calculated by: Lf = R / (B * c)
u Single record fetch without overflow: Tf = s + r + dtt
u If there are overflows with an average # of chains x:
· Tf(successful) = ( 1 + x/2 ) * ( s + r + dtt )
· Tf(unsuccessful) = ( 1 + x ) * ( s + r + dtt )
u For insertion and deletion we use
· TI = TD = TF(unsuccessful) + 2r
154
Overall Summary
l Tree-structured indexes
l ISAM
l Static structure
l Only leaf pages modified
l Overflow pages needed
l B+ tree
l Dynamic structure
l Inserts/deletes leave tree height-balanced, cost = logFN
l High fanout(F), depth rarely more than 3 or 4
l Hash-based indexes
l Static Hashing
l Long overflow chains
l Extensible Hashing
l Directory to keep track of buckets, doubles periodically
l Avoids overflow pages by splitting a full bucket when a new data entry
is to be added to it
l Linear Hashing
l Avoids directory by splitting buckets round-robin, and using overflow 155
pages
Extensible Hashing
156

Tutorial On B+Tree & Hash Indexing: Index

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tutorial On B+Tree & Hash Indexing: Index

Încărcat de

Drepturi de autor:

Formate disponibile

CSD Univ.

of Crete Fall 2005

CSD Univ. of Crete Fall 2005

Index Search Keys

l Candidate key vs search key:

l Types of (search) keys

CSD Univ. of Crete Fall 2005

Once index entry

CSD Univ. of Crete Fall 2005

Integrated Storage Structure

CSD Univ. of Crete Fall 2005

Index File With Separate Storage Structure

Indices: The Down Side

l Additional I/O to access index pages (except if index is small enough to

l Index must be updated when table is modified

l SQL-92 does not provide for creation or deletion of indices

CSD Univ. of Crete Fall 2005

Clustered Main Index

CSD Univ. of Crete Fall 2005

Clustered Secondary Index

l A secondary index might be clustered or unclustered with respect to

u Index created by CREATE INDEX is generally an unclustered,

CSD Univ. of Crete Fall 2005

Unclustered Secondary Index

Example - Cost of Range Search

l Data file has 10.000 pages, 100 rows in range

l Page transfers for rows (assuming 20 rows/page):

l Page transfers for index entries (assuming 200 entries/page)

CSD Univ. of Crete Fall 2005

Sparse vs Dense Index

Sparse vs Dense Index

CSD Univ. of Crete Fall 2005

Search key should

Multiple Attribute Search Key

l Search key is a sequence of attributes; index entries are lexically

l Supports finer granularity equality search:

l Supports range search (tree index only):

l Supports partial key searches (tree index only):

CSD Univ. of Crete Fall 2005

Locating an Index Entry

l Use scan (index entries not sorted)

l Use binary search (index entries sorted)

l Use multilevel index: Sparse index on sorted list of index entries

Indexes on Sequential Files

CSD Univ. of Crete Fall 2005

Indexes on Sequential Files

Multiple Index Levels

CSD Univ. of Crete Fall 2005

˜ Separator level is a sparse index over pages of index entries

˜Search cost = number of levels in tree

CSD Univ. of Crete Fall 2005

File not sorted on

CSD Univ. of Crete Fall 2005

CSD Univ. of Crete Fall 2005

Indexes with Duplicate Search Keys

l Different records can have

CSD Univ. of Crete Fall 2005

Duplicate Keys & Dense Index

Duplicate Keys & Better Dense Index

CSD Univ. of Crete Fall 2005

Duplicate Keys and Sparse Index

Duplicate Keys and Better Sparse Index

u of height 3 is: 2* ((p+1)/2)* ((p+1)/2)* ((m+1/2) vs. ppp*m