ISAM Quiz Solutions
-
What does ISAM stand for?
- A) Indexed Sequential Access Method
- B) Internal Storage Allocation Model
- C) Iterative Search and Match
- D) Indexed Static Array Mapping
Answer: A) Indexed Sequential Access Method
Explanation: ISAM stands for Indexed Sequential Access Method โ a file organization technique that combines sequential storage of records with a static index for faster lookups.
-
What is the core idea behind ISAM's file organization?
- A) Records are stored in random order with no index at all
- B) Records are stored sequentially (sorted by key), with a separate static index pointing to blocks of records for faster access
- C) Records are stored using a hash function exclusively
- D) Records are duplicated across multiple unrelated files
Answer: B) Records are stored sequentially (sorted by key), with a separate static index pointing to blocks of records for faster access
Explanation: ISAM keeps the main data file sorted by key and builds a static index (often multi-level) that maps key ranges to block addresses, allowing the system to jump near the target block instead of scanning the entire file.
-
What is an 'Overflow Page' in ISAM?
- A) A page that stores the index itself
- B) A separate area used to hold new records that no longer fit in their original primary data block after the index was built
- C) A backup copy of the entire database
- D) A page that stores only deleted records
Answer: B) A separate area used to hold new records that no longer fit in their original primary data block after the index was built
Explanation: Since ISAM's index is static (built once for the original data), new insertions that don't fit in their designated primary block are placed in overflow pages, linked to the primary block via pointers.
-
Why is ISAM's index described as 'static'?
- A) Because it changes automatically with every single insertion or deletion
- B) Because it is built once based on the initial data distribution and does not automatically reorganize itself as records are inserted or deleted
- C) Because it has no structure at all
- D) Because it only supports read-only databases
Answer: B) Because it is built once based on the initial data distribution and does not automatically reorganize itself as records are inserted or deleted
Explanation: Unlike a B-Tree's dynamically self-balancing index, the ISAM index is constructed once and remains fixed. Subsequent insertions are diverted to overflow pages rather than triggering an index restructure, which is why performance degrades over time.
-
What is a primary disadvantage of ISAM compared to dynamic structures like B-Trees?
- A) ISAM cannot store more than 100 records
- B) As more records are added to overflow pages, search performance gradually degrades since overflow chains must be traversed linearly
- C) ISAM requires significantly more disk space than any other structure
- D) ISAM cannot support sequential access at all
Answer: B) As more records are added to overflow pages, search performance gradually degrades since overflow chains must be traversed linearly
Explanation: Because the index isn't rebuilt as data grows, overflow chains lengthen over time. Searching for a record that has been pushed into an overflow chain requires scanning that chain sequentially, degrading what should be a fast indexed lookup.
-
In a typical multi-level ISAM structure, what are the usual levels of indexing from top to bottom?
- A) Leaf index โ Root index โ Data file
- B) Master (cylinder) index โ Track (or block) index โ Primary data area โ Overflow area
- C) Hash index โ Primary data area only
- D) There is only ever a single flat index level in ISAM
Answer: B) Master (cylinder) index โ Track (or block) index โ Primary data area โ Overflow area
Explanation: Classic ISAM implementations often use a hierarchical index: a master index narrows the search to a cylinder/region, a track index narrows further to a specific block, and then the primary data area (with associated overflow chains) holds the actual records.
-
How does search performance in ISAM typically compare to B-Trees as the dataset grows significantly larger than its original size?
- A) ISAM always remains faster than B-Trees regardless of growth
- B) ISAM's performance worsens due to growing overflow chains, while B-Trees maintain logarithmic search time through automatic rebalancing
- C) Both structures degrade at exactly the same rate
- D) Neither structure is affected by data growth
Answer: B) ISAM's performance worsens due to growing overflow chains, while B-Trees maintain logarithmic search time through automatic rebalancing
Explanation: B-Trees dynamically split and rebalance nodes on insertion, keeping search time at O(log n) regardless of growth. ISAM's static index does not adapt, so heavy insertion activity causes overflow chains to grow, degrading search performance toward linear time within those chains.
-
What operational practice is commonly required to restore ISAM's performance after significant overflow accumulation?
- A) Nothing; ISAM self-heals automatically
- B) Periodic reorganization (rebuilding) of the file and index from scratch to merge overflow records back into sorted primary blocks
- C) Deleting all overflow records permanently with no migration
- D) Converting the file to a hash table automatically
Answer: B) Periodic reorganization (rebuilding) of the file and index from scratch to merge overflow records back into sorted primary blocks
Explanation: Because ISAM doesn't self-balance, database administrators periodically reorganize (rebuild) the ISAM file โ merging overflow records into the main sorted sequence and rebuilding the static index โ to restore fast lookup performance.
-
Why is ISAM well-suited for read-heavy workloads with infrequent updates, but less ideal for write-heavy workloads?
- A) ISAM cannot perform reads efficiently at all
- B) Its static index gives fast, predictable lookups when the data distribution matches the original index, but frequent writes accumulate in overflow chains and degrade performance over time
- C) ISAM is equally suited for all workload types with no trade-offs
- D) Write operations in ISAM are always faster than read operations
Answer: B) Its static index gives fast, predictable lookups when the data distribution matches the original index, but frequent writes accumulate in overflow chains and degrade performance over time
Explanation: ISAM shines in scenarios where the data is loaded once (or rarely changed) and then queried heavily โ the static index provides fast, low-overhead lookups. But continuous insertions push records into overflow chains, steadily eroding performance, making it a poor fit for write-intensive systems.
-
How does the 'static' nature of ISAM's index fundamentally trade off against the 'dynamic' rebalancing of B-Trees in terms of system design philosophy?
- A) ISAM trades long-term scalability for simpler, lower-overhead index maintenance and excellent performance on largely static datasets; B-Trees trade slightly higher per-operation overhead for sustained, predictable performance as data changes over time
- B) Both structures have identical design philosophies with no meaningful trade-offs
- C) B-Trees are always slower than ISAM in every scenario, with no exceptions
- D) ISAM dynamically rebalances just like B-Trees, making the two structurally identical
Answer: A) ISAM trades long-term scalability for simpler, lower-overhead index maintenance and excellent performance on largely static datasets; B-Trees trade slightly higher per-operation overhead for sustained, predictable performance as data changes over time
Explanation: ISAM's design assumes data is relatively static after the initial load โ this simplicity yields excellent performance until significant write activity accumulates. B-Trees pay a small constant overhead on every insert/delete to maintain balance, but this investment pays off by sustaining O(log n) performance indefinitely, regardless of how much the data changes โ a classic trade-off between upfront simplicity and long-term adaptability.
- In what scenario might ISAM still be preferred over a B-Tree-based index in a modern system, despite B-Trees' superior write scalability?
- A) Never; B-Trees are unconditionally superior in every possible scenario
- B) In archival or read-mostly systems with infrequent bulk-loaded data (e.g., periodic batch reporting datasets), where ISAM's simpler structure and predictable sequential access pattern can outperform a B-Tree's additional indirection for read-heavy access patterns
- C) ISAM is always faster than B-Trees for every type of insert-heavy workload
- D) ISAM should be used only when no indexing is required at all
Answer: B) In archival or read-mostly systems with infrequent bulk-loaded data (e.g., periodic batch reporting datasets), where ISAM's simpler structure and predictable sequential access pattern can outperform a B-Tree's additional indirection for read-heavy access patterns
Explanation: When data is loaded in bulk and rarely modified afterward โ common in archival, reporting, or read-mostly analytical systems โ ISAM's static structure imposes no ongoing rebalancing overhead and offers very predictable access patterns, which can be advantageous compared to the slightly higher per-access overhead of traversing a dynamically balanced B-Tree.
- How does the concept of 'overflow chains' in ISAM conceptually relate to 'separate chaining' used for collision handling in hash tables?
- A) They are entirely unrelated concepts with no structural similarity
- B) Both involve linking additional records to a primary location (a block in ISAM, a bucket in hashing) when that location cannot directly accommodate a new entry, degrading lookup speed as the chain grows
- C) Overflow chains and separate chaining both guarantee O(1) lookup time regardless of chain length
- D) Separate chaining is only used in ISAM, never in hash tables
Answer: B) Both involve linking additional records to a primary location (a block in ISAM, a bucket in hashing) when that location cannot directly accommodate a new entry, degrading lookup speed as the chain grows
Explanation: Conceptually, ISAM's overflow pages and hash table separate chaining solve a similar problem: when a primary storage location (block or bucket) is full, additional entries are linked off it. In both cases, as these chains grow long (due to many additions or poor distribution), the lookup degrades from near-constant/logarithmic time toward linear time within the chain โ illustrating a recurring trade-off in fixed-capacity storage structures.