Indexing

INDEXING

Indexing mechanisms used to speed up access to desired data. 

o E.g., author catalog in library Search-key Pointer

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. Index files are typically much smaller than the original file.

Two basic kinds of indices:

o Ordered indices: search keys are stored in sorted order.

o Hash indices: search keys are distributed uniformly across ―buckets‖ using a ―hash function‖. Index Evaluation Metrics

o Access types supported efficiently. E.g.,

o records with a specified value in the attribute

o or records with an attribute value falling in a specified range of values. o Access time o Insertion time

o Deletion time o Space overhead

Ordered Indices

o Indexing techniques evaluated on basis of:

In an ordered index, index entries are stored, sorted on the search key value. E.g., author catalogin library.

Primary index: in a sequentially ordered file, the index whose search key specifies the sequentialorder 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.

 Dense Index File s

o Dense index — Index record appears for every search key value in the file.

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. 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.

Example of Sparse Index Files

Multilevel Index

 If primary index does not fit in memory, access becomes expensive .  To reducen umber of disk accesses to index records, treat primary index kept on disk as a sequential file and construct a sparse index

on it. o outer index – a sparse index of primary index o inner index – the primary index file

  If even the outer index is too large to fit in main memory, yet another level of index can be created, and so on.

  Indices at alllevels must be updated on insertion or deletion from the file.

Index Update: Deletion

If deleted record was the only record in the file with its particular search-key value, the searchkey

is deleted from the index also. Single-level index deletion:

o Dense indices – deletion of search-key is similar to file record deletion.

o 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.

  Index Update: Insertion o Single-level index insertion:

o Perform a lookup using the search-key value appearing in the record to be inserted.

o Dense indices – if the search-key value does not appear in the index, insert it.

o 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. In this case, the first search-key value appearing in the new block is inserted into the index.

o Multilevel insertion (as well as deletion) algorithms are simple extensions of the single-level algorithms.

Secondary Indices

o Frequently, one wants to find all the records whose

values in a certain field (which is not the search-key of the primary index satisfy some condition. o Example 1: In the account database stored sequentially by account number, we may want to find all accounts in a particular branch.

o Example 2: as above, but where we want to find all accounts with a specified balance or range of balances

o We can have a secondary index with an index record for each search-key value; index record points to a bucket that contains pointers to all the actual records with that particular search-key value.

Secondary Index on balance field of account

   Primary and Secondary Indice s Secondary indices have to be dense.

Indices offer substantial benefits when searching for records.

When a file is modified, every index on the file must be updated, Updating indices imposes overhead on database modification.

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 Bitmap Indices

n Bitmap indices are a special type of index designed for efficient querying on multiple keys. n 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

n 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)

n A bitmap is simply an array of bits.

n 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.

 Bitmap indices are useful for queries on multiple attributes

Not particularly useful for single attribute queries n 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

Males with income level L1: 10010 AND 10100 = 10000

If number of distinct attribute values is 8, bitmap is only 1% of relation size n Deletion needs to be handled properly

Existence bitmap to note if there is a valid record at a record location Needed for complementation 

Should keep bitmaps for all values, even null value.