Chapter 10: Storage and File

Structure

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 10: Storage and File
Structure
 Overview of Physical Storage Media
 Magnetic Disks
 RAID
 Tertiary Storage
 Storage Access
 File Organization
 Organization of Records in Files
 Data-Dictionary Storage

Database System Concepts - 6th Edition 10.2 ©Silberschatz, Korth and Sudarshan
 Classification of Physical Storage
Media
 Speed with which data can be accessed
 Cost per unit of data
 Reliability
 data loss on power failure or system crash
 physical failure of the storage device
 Can differentiate storage into:
 volatile storage: loses contents when power is
switched off
 non-volatile storage:
 Contents persist even when power is switched off.
 Includes secondary and tertiary storage, as well
as batter- backed up main-memory.

Database System Concepts - 6th Edition 10.3 ©Silberschatz, Korth and Sudarshan
 Physical Storage Media

 Cache – fastest and most costly form of storage;

volatile; managed by the computer system hardware.
 Main memory:
 fast access (10s to 100s of nanoseconds; 1
nanosecond = 10 –9 seconds)
 generally too small (or too expensive) to store the
entire database
 capacities of up to a few Gigabytes widely used
currently
 Capacities have gone up and per-byte costs
have decreased steadily and rapidly (roughly
factor of 2 every 2 to 3 years)
 Volatile — contents of main memory are usually
lost if a power failure or system crash occurs.

Database System Concepts - 6th Edition 10.4 ©Silberschatz, Korth and Sudarshan
 Physical Storage Media (Cont.)
 Flash memory
 Data survives power failure
 Data can be written at a location only once, but
location can be erased and written to again
 Can support only a limited number (10K – 1M) of
write/erase cycles.
 Erasing of memory has to be done to an entire
bank of memory
 Reads are roughly as fast as main memory
 But writes are slow (few microseconds), erase is
slower
 Widely used in embedded devices such as digital
cameras, phones, and USB keys

Database System Concepts - 6th Edition 10.5 ©Silberschatz, Korth and Sudarshan
 Physical Storage Media (Cont.)

 Magnetic-disk
 Data is stored on spinning disk, and read/written magnetically
 Primary medium for the long-term storage of data; typically
stores entire database.
 Data must be moved from disk to main memory for access,
and written back for storage
 Much slower access than main memory (more on this
later)
 direct-access – possible to read data on disk in any order,
unlike magnetic tape
 Capacities range up to roughly 1.5 TB as of 2009
 Much larger capacity and cost/byte than main
memory/flash memory
 Growing constantly and rapidly with technology
improvements (factor of 2 to 3 every 2 years)
 Survives power failures and system crashes
 disk failure can destroy data, but is rare

Database System Concepts - 6th Edition 10.6 ©Silberschatz, Korth and Sudarshan
 Physical Storage Media (Cont.)
 Optical storage
 non-volatile, data is read optically from a spinning
disk using a laser
 CD-ROM (640 MB) and DVD (4.7 to 17 GB) most
popular forms
 Blu-ray disks: 27 GB to 54 GB
 Write-one, read-many (WORM) optical disks used
for archival storage (CD-R, DVD-R, DVD+R)
 Multiple write versions also available (CD-RW, DVD-
RW, DVD+RW, and DVD-RAM)
 Reads and writes are slower than with magnetic
disk
 Juke-box systems, with large numbers of
removable disks, a few drives, and a mechanism
for automatic loading/unloading of disks available
for storing large volumes of data

Database System Concepts - 6th Edition 10.7 ©Silberschatz, Korth and Sudarshan
 Physical Storage Media (Cont.)
 Tape storage
 non-volatile, used primarily for backup (to
recover from disk failure), and for archival data
 sequential-access – much slower than disk
 very high capacity (40 to 300 GB tapes available)
 tape can be removed from drive  storage costs
much cheaper than disk, but drives are
expensive
 Tape jukeboxes available for storing massive
amounts of data
 hundreds of terabytes (1 terabyte = 10 9 bytes)
to even multiple petabytes (1 petabyte = 10 12
bytes)

Database System Concepts - 6th Edition 10.8 ©Silberschatz, Korth and Sudarshan
 Storage Hierarchy

Database System Concepts - 6th Edition 10.9 ©Silberschatz, Korth and Sudarshan
 Storage Hierarchy (Cont.)

 primary storage: Fastest media but volatile (cache,

main memory).
 secondary storage: next level in hierarchy, non-
volatile, moderately fast access time
 also called on-line storage
 E.g. flash memory, magnetic disks
 tertiary storage: lowest level in hierarchy, non-
volatile, slow access time
 also called off-line storage
 E.g. magnetic tape, optical storage

Database System Concepts - 6th Edition 10.10 ©Silberschatz, Korth and Sudarshan
 RAID
 RAID: Redundant Arrays of Independent Disks
 disk organization techniques that manage a large numbers of
disks, providing a view of a single disk of
 high capacity and high speed by using multiple disks in
parallel,
 high reliability by storing data redundantly, so that data can be
recovered even if a disk fails
 The chance that some disk out of a set of N disks will fail is much
higher than the chance that a specific single disk will fail.
 E.g., a system with 100 disks, each with MTTF of 100,000 hours
(approx. 11 years), will have a system MTTF of 1000 hours
(approx. 41 days)
 Techniques for using redundancy to avoid data loss are critical
with large numbers of disks
 Originally a cost-effective alternative to large, expensive disks
 I in RAID originally stood for ``inexpensive’’
 Today RAIDs are used for their higher reliability and bandwidth.
 The “I” is interpreted as independent
Database System Concepts - 6th Edition 10.11 ©Silberschatz, Korth and Sudarshan
 Improvement of Reliability via Redundancy

 Redundancy – store extra information that can be used to

rebuild information lost in a disk failure
 E.g., Mirroring (or shadowing)
 Duplicate every disk. Logical disk consists of two physical
disks.
 Every write is carried out on both disks
 Reads can take place from either disk
 If one disk in a pair fails, data still available in the other
 Data loss would occur only if a disk fails, and its mirror
disk also fails before the system is repaired
– Probability of combined event is very small
» Except for dependent failure modes such as fire or
building collapse or electrical power surges
 Mean time to data loss depends on mean time to failure,
and mean time to repair
 E.g. MTTF of 100,000 hours, mean time to repair of 10
hours gives mean time to data loss of 500*10 6 hours (or
57,000 years) for a mirrored pair of disks (ignoring
dependent failure modes)
Database System Concepts - 6th Edition 10.12 ©Silberschatz, Korth and Sudarshan
 Improvement in Performance via Parallelism

 Two main goals of parallelism in a disk system:

1. Load balance multiple small accesses to increase throughput
2. Parallelize large accesses to reduce response time.
 Improve transfer rate by striping data across multiple disks.
 Bit-level striping – split the bits of each byte across multiple disks
 In an array of eight disks, write bit i of each byte to disk i.
 Each access can read data at eight times the rate of a single
disk.
 But seek/access time worse than for a single disk
 Bit level striping is not used much any more
 Block-level striping – with n disks, block i of a file goes to disk (i
mod n) + 1
 Requests for different blocks can run in parallel if the blocks
reside on different disks
 A request for a long sequence of blocks can utilize all disks in
parallel

Database System Concepts - 6th Edition 10.13 ©Silberschatz, Korth and Sudarshan
 RAID Levels
 Schemes to provide redundancy at lower cost by
using disk striping combined with parity bits
Different RAID organizations, or RAID levels, have

differing cost, performance and reliability
characteristics
 RAID Level 0: Block striping; non-redundant.
Used in high-performance applications where data loss

is not
 RAID critical
Level .
1: Mirrored disks with block striping
 Offers best write performance.
 Popular for applications such as storing log files in a
database system.

Database System Concepts - 6th Edition 10.14 ©Silberschatz, Korth and Sudarshan
 RAID Levels (Cont.)
 RAID Level 2: Memory-Style Error-Correcting-Codes
(ECC) with bit striping.
 RAID Level 3: Bit-Interleaved Parity
 a single parity bit is enough for error correction,
not just detection, since we know which disk has
failed
 When writing data, corresponding parity bits
must also be computed and written to a parity bit
disk
 To recover data in a damaged disk, compute XOR
of bits from other disks (including parity bit disk)

Database System Concepts - 6th Edition 10.15 ©Silberschatz, Korth and Sudarshan
 RAID Levels (Cont.)
 RAID Level 3 (Cont.)
 Faster data transfer than with a single disk, but fewer I/Os
per second since every disk has to participate in every
I/O.
 Subsumes Level 2 (provides all its benefits, at lower cost).
 RAID Level 4: Block-Interleaved Parity; uses block-level
striping, and keeps a parity block on a separate disk for
corresponding blocks from N other disks.
 When writing data block, corresponding block of parity
bits must also be computed and written to parity disk
 To find value of a damaged block, compute XOR of bits
from corresponding blocks (including parity block) from
other disks.

Database System Concepts - 6th Edition 10.16 ©Silberschatz, Korth and Sudarshan
 RAID Levels (Cont.)
 RAID Level 4 (Cont.)
 Provides higher I/O rates for independent block reads than
Level 3
 block read goes to a single disk, so blocks stored on
different disks can be read in parallel
 Provides high transfer rates for reads of multiple blocks than
no-striping
 Before writing a block, parity data must be computed
 Can be done by using old parity block, old value of current
block and new value of current block (2 block reads + 2
block writes)
 Or by recomputing the parity value using the new values of
blocks corresponding to the parity block
– More efficient for writing large amounts of data
sequentially
 Parity block becomes a bottleneck for independent block
writes since every block write also writes to parity disk

Database System Concepts - 6th Edition 10.17 ©Silberschatz, Korth and Sudarshan
 RAID Levels (Cont.)
 RAID Level 5: Block-Interleaved Distributed Parity; partitions data and
parity among all N + 1 disks, rather than storing data in N disks and
parity in 1 disk.
 E.g., with 5 disks, parity block for nth set of blocks is stored on
disk (n mod 5) + 1, with the data blocks stored on the other 4 disks.

Database System Concepts - 6th Edition 10.18 ©Silberschatz, Korth and Sudarshan
 RAID Levels (Cont.)
 RAID Level 5 (Cont.)
 Higher I/O rates than Level 4.
 Block writes occur in parallel if the blocks and
their parity blocks are on different disks.
 Subsumes Level 4: provides same benefits, but
avoids bottleneck of parity disk.
 RAID Level 6: P+Q Redundancy scheme; similar to Level
5, but stores extra redundant information to guard
against multiple disk failures.
 Better reliability than Level 5 at a higher cost; not
used as widely.

Database System Concepts - 6th Edition 10.19 ©Silberschatz, Korth and Sudarshan
 Choice of RAID Level
 Factors in choosing RAID level
 Monetary cost
 Performance: Number of I/O operations per second,
and bandwidth during normal operation
 Performance during failure
 Performance during rebuild of failed disk
 Including time taken to rebuild failed disk
 RAID 0 is used only when data safety is not important
 E.g. data can be recovered quickly from other
sources
 Level 2 and 4 never used since they are subsumed by 3
and 5
 Level 3 is not used anymore since bit-striping forces
single block reads to access all disks, wasting disk arm
movement, which block striping (level 5) avoids
 Level 6 is rarely used since levels 1 and 5 offer
adequate safety for most applications

Database System Concepts - 6th Edition 10.20 ©Silberschatz, Korth and Sudarshan
 Choice of RAID Level (Cont.)
 Level 1 provides much better write performance than level 5
 Level 5 requires at least 2 block reads and 2 block writes
to write a single block, whereas Level 1 only requires 2
block writes
 Level 1 preferred for high update environments such as log
disks
 Level 1 had higher storage cost than level 5
 disk drive capacities increasing rapidly (50%/year) whereas
disk access times have decreased much less (x 3 in 10
years)
 I/O requirements have increased greatly, e.g. for Web
servers
 When enough disks have been bought to satisfy required
rate of I/O, they often have spare storage capacity
 so there is often no extra monetary cost for Level 1!
 Level 5 is preferred for applications with low update rate,
and large amounts of data
 Level 1 is preferred for all other applications

Database System Concepts - 6th Edition 10.21 ©Silberschatz, Korth and Sudarshan
 File Organization, Record
Organization and Storage Access

Database System Concepts - 6th Edition 10.22 ©Silberschatz, Korth and Sudarshan
 File Organization

 The database is stored as a collection of files. Each

file is a sequence of records. A record is a sequence
of fields.
 One approach:
assume record size is fixed
each file has records of one particular type only
different files are used for different relations
This case is easiest to implement; will consider
variable length records later.

Database System Concepts - 6th Edition 10.23 ©Silberschatz, Korth and Sudarshan
 Fixed-Length Records
 Simple approach:
 Store record i starting from byte n  (i – 1), where n is
the size of each record.
 Record access is simple but records may cross blocks
 Modification: do not allow records to cross block
boundaries

 Deletion of record i:
alternatives:
 move records i + 1, . . ., n
to i, . . . , n – 1
 move record n to i
 do not move records, but
link all free records on a
free list

Database System Concepts - 6th Edition 10.24 ©Silberschatz, Korth and Sudarshan
 Deleting record 3 and compacting

Database System Concepts - 6th Edition 10.25 ©Silberschatz, Korth and Sudarshan
 Deleting record 3 and moving last
record

Database System Concepts - 6th Edition 10.26 ©Silberschatz, Korth and Sudarshan
 Free Lists
 Store the address of the first deleted record in the file header.
 Use this first record to store the address of the second
deleted record, and so on
 Can think of these stored addresses as pointers since they
“point” to the location of a record.
 More space efficient representation: reuse space for normal
attributes of free records to store pointers. (No pointers
stored in in-use records.)

Database System Concepts - 6th Edition 10.27 ©Silberschatz, Korth and Sudarshan
 Variable-Length Records

 Variable-length records arise in database systems in

several ways:
 Storage of multiple record types in a file.
 Record types that allow variable lengths for one or more
fields such as strings (varchar)
 Record types that allow repeating fields (used in some
older data models).
 Attributes are stored in order
 Variable length attributes represented by fixed size (offset,
length), with actual data stored after all fixed length
attributes
 Null values represented by null-value bitmap

Database System Concepts - 6th Edition 10.28 ©Silberschatz, Korth and Sudarshan
 Variable-Length Records: Slotted Page
Structure

 Slotted page header contains:

 number of record entries
 end of free space in the block
 location and size of each record
 Records can be moved around within a page to keep
them contiguous with no empty space between them;
entry in the header must be updated.
 Pointers should not point directly to record — instead
they should point to the entry for the record in header.

Database System Concepts - 6th Edition 10.29 ©Silberschatz, Korth and Sudarshan
 Organization of Records in Files

 Heap – a record can be placed anywhere in the file

where there is space
 Sequential – store records in sequential order,
based on the value of the search key of each
record
 Hashing – a hash function computed on some
attribute of each record; the result specifies in
which block of the file the record should be placed
 Records of each relation may be stored in a
separate file. In a multitable clustering file
organization records of several different relations
can be stored in the same file
 Motivation: store related records on the same
block to minimize I/O

Database System Concepts - 6th Edition 10.30 ©Silberschatz, Korth and Sudarshan
 Sequential File Organization
 Suitable for applications that require sequential
processing of the entire file
 The records in the file are ordered by a search-
key

Database System Concepts - 6th Edition 10.31 ©Silberschatz, Korth and Sudarshan
 Sequential File Organization
(Cont.)
 Deletion – use pointer chains
 Insertion –locate the position where the record is to be
inserted
 if there is free space insert there
 if no free space, insert the record in an overflow block
 In either case, pointer chain must be updated
 Need to reorganize the file
from time to time to restore
sequential order

Database System Concepts - 6th Edition 10.32 ©Silberschatz, Korth and Sudarshan
Chapter 11: Indexing and Hashing

Database System Concepts, 6th 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
 Static Hashing
 Dynamic Hashing
 Briefly
 Comparison of Ordered Indexing and Hashing
 Index Definition in SQL
 Multiple-Key Access

Database System Concepts - 6th Edition 10.34 ©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 - 6th Edition 10.35 ©Silberschatz, Korth and Sudarshan
 Index Evaluation Metrics
 Access types supported efficiently.
 records with a specified value in the
attribute, or
 records with an attribute value falling in
a specified range of values.
 Access time
 Insertion time
 Deletion time
 Space overhead

Database System Concepts - 6th Edition 10.36 ©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 to avoid confusion with
Primary Key.
 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 - 6th Edition 10.37 ©Silberschatz, Korth and Sudarshan
 Dense Index Files
 Dense index — Index record appears for every
search-key value in the file.
 E.g. index on ID attribute of instructor relation

Database System Concepts - 6th Edition 10.38 ©Silberschatz, Korth and Sudarshan
 Dense Index Files (Cont.)
 Dense index on dept_name, with instructor file
sorted on dept_name

Database System Concepts - 6th Edition 10.39 ©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
Ordered by ID

Database System Concepts - 6th Edition 10.40 ©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 - 6th Edition 10.41 ©Silberschatz, Korth and Sudarshan
 Secondary Indices Example

Secondary index on salary field of instructor

 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 - 6th Edition 10.42 ©Silberschatz, Korth and Sudarshan
 Hashing

Database System Concepts, 6th 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;
bucket thus entire bucket has
to be searched sequentially to locate a record.

Database System Concepts - 6th Edition 10.44 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization

Hash file organization of instructor file, using dept_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(Music) = 1 h(History) = 2
h(Physics) = 3 h(Elec. Eng.) = 3

Database System Concepts - 6th Edition 10.45 ©Silberschatz, Korth and Sudarshan
 Example of Hash File Organization

Hash file organization of instructor file, using

dept_name as key (see previous slide for details).
Database System Concepts - 6th Edition 10.46 ©Silberschatz, Korth and Sudarshan
 Hash Functions
 Worst hash function maps all search-key values to
the same bucket;
 The access is 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 - 6th Edition 10.47 ©Silberschatz, Korth and Sudarshan
 Handling of Bucket Overflows
 Bucket overflow can occur because of
 Insufficient buckets
 Skew in distribution of records. This can occur
due to two reasons:
 multiple records have same search-key value
 chosen hash function produces non-uniform
distribution of key values
 Although the probability of bucket overflow can be
reduced, it cannot be eliminated; it is handled by
using overflow buckets.

Database System Concepts - 6th Edition 10.48 ©Silberschatz, Korth and Sudarshan
 Handling of Bucket Overflows
(Cont.)

 Overflow chaining – the overflow buckets of a given

bucket are chained together in a linked list.
 Above scheme is called closed hashing.
 An alternative, called open hashing, which does not
use overflow buckets, is not suitable for database
applications.

Database System Concepts - 6th Edition 10.49 ©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 - 6th Edition 10.50 ©Silberschatz, Korth and Sudarshan
 Example of Hash Index

hash index on instructor, on attribute ID

Database System Concepts - 6th Edition 10.51 ©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 - 6th Edition 10.52 ©Silberschatz, Korth and Sudarshan
 Dynamic Hashing
 Good for database that grows and shrinks in size
 Allows the hash function to be modified
dynamically

Database System Concepts - 6th Edition 10.53 ©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 - 6th Edition 10.54 ©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 - 6th Edition 10.55 ©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 - 6th Edition 10.56 ©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 - 6th Edition 10.57 ©Silberschatz, Korth and Sudarshan
 Bitmap Indices (Cont.)
 Bitmap indices generally are 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 the number of distinct attribute values is 8, bitmap
is only 1% of relation size

Database System Concepts - 6th Edition 10.58 ©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 - 6th Edition 10.59 ©Silberschatz, Korth and Sudarshan
 End of Chapter

Database System Concepts, 6th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use