Some terminology:
Basic picture of a dense, secondary index:
Slightly different picture of a dense, secondary index:
=> In RedBase you will implement dense, secondary indexes
Trees | Hashing | ||
---|---|---|---|
Instances . . | ....................................................................................... | ....................................................................................... | |
Search (A=v) over N records . | ....................................................................................... | ....................................................................................... | |
Insert or delete record . | ....................................................................................... | ....................................................................................... | |
Search (A<v) over N records . | ....................................................................................... | ....................................................................................... |
(1) (2)Basic structure of a B+ tree:
Each B+ tree has a predefined maximum node capacity N (fanout <= N+1).
Structure of an internal node:
Structure of a leaf node:
Alternate structure for leaf nodes:
Search (A < v)
Search (v1 < A < v2)
Search (A > v)
Insert (v, RID)
Delete (v, RID)
Update R Set R.A = R.A + 5 Where R.A > 10Suppose a B+ tree is used to find tuples with R.A > 10:
loop fetch next RID from index for R.A > 10 find record, update R.A delete old R.A index entry for RID add new R.A index entry for RID end loopQuestion: What's wrong with this algorithm?
Question: Do we have the same problem with hash indexes?
Basic setup of relations and indexes:
Architecture:
IX_Manager:: CreateIndex (file, index#, attr-info) DestroyIndex OpenIndex -> initialized index handle CloseIndex
IX_IndexHandle:: InsertEntry (value, RID) DeleteEntry (value, RID) Also ForcePages
IX_IndexScan:: OpenScan (index, comp, value, pin-hint) GetNextEntry -> returns RID CloseScan
Alternative 1 (full credit): lazy deletion
Alternative 2 (not quite full credit): tombstones
Question: What global assumption about database behavior makes above schemes okay?
=> May assume no inserts or deletes during scan
=> May assume no inserts or deletes during scan
=> May prohibit index scans when scanned attribute is also update attribute (Halloween problem and implementation complexity)
=> Must work correctly