Professional Documents
Culture Documents
11.1 Basic Concepts: Every
11.1 Basic Concepts: Every
Chapter 11
2
Brighton
217
750
Downtown
101
110
500
Downtown
Mianus
215
Perriridge
Perriridge
102
201
400
900
Perriridge
218
700
Redwood
222
700
Round Hill
305
600
700
350
Dense Index:
An index record appears for every search key value in le.
This record contains search key value and a pointer to the actual record.
Sparse Index:
Index records are created only for some of the records.
To locate a record, we nd the index record with the largest search key value less than or equal to the
Brighton
Downtown
Brighton
Mianus
Downtown
217
Green
750
500
Downtown
101
110
Johnson
Perriridge
Redwood
Mianus
215
Peterson
Smith
600
700
Round Hill
Perriridge
Perriridge
102
201
Hayes
Williams
400
900
Perriridge
218
Lyle
700
Redwood
222
305
Lindsay
700
Turner
350
Round Hill
Brighton
Mianus
Redwood
Brighton
Downtown
Downtown
Mianus
Perriridge
Perriridge
Perriridge
Redwood
Round Hill
217
101
110
215
102
201
218
222
305
Green
Johnson
750
Peterson
Smith
600
700
Hayes
Williams
Lyle
Lindsay
Turner
500
400
900
700
700
350
4
index block 0
Data block 0
index block 1
data
block 1
outer index
inner index
Multi-Level Indices
1. Even with a sparse index, index size may still grow too large. For 100,000 records, 10 per block, at one index
record per block, that's 10,000 index records! Even if we can t 100 index records per block, this is 100
blocks.
2. If index is too large to be kept in main memory, a search results in several disk reads.
If there are no over
ow blocks in the index, we can use binary search.
This will read as many as 1 + log2(b) blocks (as many as 7 for our 100 blocks).
If index has over
ow blocks, then sequential search typically used, reading all b index blocks.
3. Solution: Construct a sparse index on the index (Figure 11.4).
4. Use binary search on outer index. Scan index block found until correct index record found. Use index
record as before - scan block pointed to for desired record.
5. For very large les, additional levels of indexing may be required.
6. Indices must be updated at all levels when insertions or deletions require it.
7. Frequently, each level of index corresponds to a unit of physical storage (e.g. indices at the level of track,
cylinder and disk).
Green
Lindsay
Brighton
Smith
Downtown
217
Green
750
500
Downtown
101
110
Johnson
Mianus
215
Peterson
Smith
600
700
Perriridge
Perriridge
102
201
Hayes
Williams
400
900
Perriridge
218
Lyle
700
Redwood
222
Lindsay
700
Round Hill
305
Turner
350
Index Update
Regardless of what form of index is used, every index must be updated whenever a record is either inserted into
or deleted from the le.
1. Deletion:
Find (look up) the record
If the last record with a particular search key value, delete that search key value from index.
For dense indices, this is like deleting a record in a le.
For sparse indices, delete a key value by replacing key value's entry in index by next search key value.
If that value already has an index entry, delete the entry.
2. Insertion:
Find place to insert.
Dense index: insert search key value if not present.
Sparse index: no change unless new block is created. (In this case, the rst search key value appearing
in the new block is inserted into the index).
3. Secondary indices must be dense, with an index entry for every search-key value, and a pointer to every
record in the le.
7
Perriridge
Mianus
Brighton
Downtown
Redwood
Mianus
Perriridge
Redwood
Round Hill
9
P1 K1 P2 Pn,1 Kn,1 Pn
(a)
K1 P2 B2 K2 Pn,1 Bn,1 Kn,1 Pn
(b)
P1 B1
Dierence is that B-tree eliminates the redundant storage of search key values.
In B+ -tree of Figure 11.11, some search key values appear twice.
A corresponding B-tree of Figure 11.18 allows search key values to appear only once.
Thus we can store the index in less space.
2. Advantages:
1. Hashing involves computing the address of a data item by computing a function on the search key value.
2. A hash function h is a function from the set of all search key values K to the set of all bucket addresses B.
We choose a number of buckets to correspond to the number of search key values we will have stored in
the database.
To perform a lookup on a search key value Ki , we compute h(Ki ), and search the bucket with that
address.
If two search keys i and j map to the same address, because h(Ki ) = h(Kj ), then the bucket at the
address obtained will contain records with both search key values.
In this case we will have to check the search key value of every record in the bucket to get the ones we
want.
Insertion and deletion are simple.
10
Hash Functions
1. A good hash function gives an average-case lookup that is a small constant, independent of the number of
search keys.
2. We hope records are distributed uniformly among the buckets.
3. The worst hash function maps all keys to the same bucket.
4. The best hash function maps all keys to distinct addresses.
5. Ideally, distribution of keys to addresses is uniform and random.
6. Suppose we have 26 buckets, and map names beginning with ith letter of the alphabet to the ith bucket.
Problem: this does not give uniform distribution.
Many more names will be mapped to \A" than to \X".
Typical hash functions perform some operation on the internal binary machine representations of characters in a key.
For example, compute the sum, modulo # of buckets, of the binary representations of characters of the
search key.
See Figure 11.18, using this method for 10 buckets (assuming the ith character in the alphabet is
represented by integer i).
11
i1
hash prefix
i
00
01
10
11
bucket 1
i2
i3
bucket 2
bucket 3
Periodically re-organize hash structure as le grows. Requires selecting new hash function, recomputing
all addresses and generating new bucket assignments. Costly, and shuts down database.
2. Some hashing techniques allow the hash function to be modied dynamically to accommodate the growth or
shrinking of the database. These are called dynamic hash functions.
Extendable hashing is one form of dynamic hashing.
Extendable hashing splits and coalesces buckets as database size changes.
This imposes some performance overhead, but space eciency is maintained.
As reorganization is on one bucket at a time, overhead is acceptably low.
3. How does it work?
We choose a hash function that is uniform and random that generates values over a relatively large
range.
Range is b-bit binary integers (typically b=32).
232 is over 4 billion, so we don't generate that many buckets!
Instead we create buckets on demand, and do not use all b bits of the hash initially.
At any point we use i bits where 0 i b.
The i bits are used as an oset into a table of bucket addresses.
Value of i grows and shrinks with the database.
Figure 11.19 shows an extendable hash structure.
Note that the i appearing over the bucket address table tells how many bits are required to determine
the correct bucket.
It may be the case that several entries point to the same bucket.
All such entries will have a common hash prex, but the length of this prex may be less than i.
So we give each bucket an integer giving the length of the common hash prex.
This is shown in Figure 11.9 (textbook 11.19) as ij .
Number of bucket entries pointing to bucket j is then 2(i,i ) .
4. To nd the bucket containing search key value Kl :
Compute h(Kl ).
j
12
13
As we insert the Perryridge and Round Hill records, this rst bucket becomes full.
When we insert the next record (Downtown), we must split the bucket.
Since i = i0 , we need to increase the number of bits we use from the hash.
We now use 1 bit, allowing us 21 = 2 buckets.
This makes us double the size of the bucket address table to two entries.
We split the bucket, placing the records whose search key hash begins with 1 in the new bucket, and
those with a 0 in the old bucket (Figure 11.23).
Next we attempt to insert the Redwood record, and nd it hashes to 1.
That bucket is full, and i = i1 .
So we must split that bucket, increasing the number of bits we must use to 2.
This necessitates doubling the bucket address table again to four entries (Figure 11.24).
We rehash the entries in the old bucket.
We continue on for the deposit records of Figure 11.20, obtaining the extendable hash structure of Figure
11.25.
10. Advantages:
Extendable hashing provides performance that does not degrade as the le grows.
Minimal space overhead - no buckets need be reserved for future use. Bucket address table only contains
one pointer for each hash value of current prex length.
11. Disadvantages:
Extra level of indirection in the bucket address table
Added complexity
12. Summary: A highly attractive technique, provided we accept added complexity.
14
Using an index structure, we can nd the bucket for value c1, and then follow the pointer chain to read
An index is created by
create index <index-name>
on r (<attribute-list>)
The attribute list is the list of attributes in relation r that form the search key for the index.
To create an index on bname for the branch relation:
create index b-index
on branch (bname)
If the search key is a candidate key, we add the word unique to the denition:
create unique index b-index
on branch (bname)
If bname is not a candidate key, an error message will appear.
If the index creation succeeds, any attempt to insert a tuple violating this requirement will fail.
The unique keyword is redundant if primary keys have been dened with integrity constraints already.
2. To remove an index, the command is
drop index <index-name>
15
Brighton
Downtown Mianus
Perriridge
Green
Hayes
Johnson
Lyle
Peterson
Smith
Turner
Williams
select balance
from deposit
where bname = \Perryridge" and balance = 1000
16