Académique Documents
Professionnel Documents
Culture Documents
table. Indices can be created using one or more columns of a database table, providing the
basis for both rapid random lookups and efficient access of ordered records.
The disk space required to store the index is typically less than that required by the table
(since indices usually contain only the key-fields according to which the table is to be
arranged, and excludes all the other details in the table), yielding the possibility to store
indices in memory that might be too small for the entire table.
In a relational database an index is a copy of part of a table. Some databases extend the
power of indexing by allowing indices to be created on functions or expressions. For
example, an index could be created on upper(last_name), which would only store the
upper case versions of the last_name field in the index. Another option sometimes
supported is the use of "filtered" indices, where index entries are created only for those
records that satisfy some conditional expression. A further aspect of flexibility is to
permit indexing on user-defined functions, as well as expressions formed from an
assortment of built-in functions. All of these indexing refinements are supported in Visual
FoxPro, for example.[1]
Indices may be defined as unique or non-unique. A unique index acts as a constraint on
the table by preventing identical rows in the index and thus, the original columns.
Contents
[hide]
1 Architecture
2 Column order
3 Applications and limitations
4 Types
o 4.1 Bitmap index
o 4.2 Dense index
o 4.3 Sparse index
5 References
6 External links
[edit] Architecture
Index architectures can be classified as clustered or non-clustered. A non-clustered index
normally contains a reference to a block that contains the row data for which the
particular index item has been constructed. This block will hold several other rows
depending on the row size. For each index lookup on a non-clustered index, a data block
that houses the row sought after must also be retrieved.
Clustering re-orders the data block in the same order as the index, hence it is also an
operation on the data storage blocks as well as on the index. Exact operation of database
systems vary, but because the row data can only be stored in one order physically, only
one clustered index may be created on a given database table. Clustered indices can
greatly increase access speed, but usually only where the data is accessed sequentially in
the same or reverse order of the clustered index, or when a range of items are selected.
Since the physical records are in this sort order on disk the next row item in the sequence
is immediately before or after the last one, and so fewer data block reads are required.
The primary feature of a clustered index is therefore the ordering of the physical data
rows in accordance with the index blocks that point to them. Some databases separate the
data and index blocks into separate files, while others intermix the two different types of
data blocks within the same physical file(s). Databases that use the latter scheme may be
said to store the actual data in the leaf node of the index, whereas, in fact there is still a
distinction between the index and the data block, and the data blocks can be traversed
without using the index by way of a link list that links the data blocks in order.
In Microsoft SQL Server, the leaf node of the clustered index corresponds to the actual
data, not simply a pointer to data that resides elsewhere, as is the case with a nonclustered index. [2] Each relation can have a single clustered index and many unclustered
indices. [3].
Indices can be implemented using a variety of data structures. Popular indices include
balanced trees, B+ trees and hashes.[4]
an index the database simply follows the b-tree data structure until the Smith entry has
been found; this is much less computationally expensive than a full table scan.
Consider this SQL statement: SELECT email_address FROM customers WHERE
email_address LIKE '%@yahoo.com';. This query would yield an email address for
every customer whose email address ends with "@yahoo.com", but even if the
email_address column has been indexed the database still must perform a full table scan.
This is because the index is built with the assumption that words go from left to right.
With a wildcard at the beginning of the search-term the database software is unable to use
the underlying b-tree data structure. This problem can be solved through the addition of
another index created on reverse(email_address) and a SQL query like this: SELECT
email_address FROM customers WHERE reverse(email_address) LIKE
reverse('%@yahoo.com');. This puts the wild-card at the right-most part of the query
[edit] Types
[edit] Bitmap index
Main article: Bitmap index
A bitmap index is a special kind of index that stores the bulk of its data as bitmaps and
answers most queries by performing bitwise logical operations on these bitmaps. The
most commonly used index, such as B+trees, are most effective if the values it indices do
not repeat or repeat a relatively smaller number of times. In contrast, the bitmap index is
designed for cases where the values of a variable repeat very frequently. For example, the
gender field in a customer database usually contains two distinct values, male or female.
For such variables, the bitmap index can have a significant performance advantage over
the commonly used trees.