Slideshow:
Delete example 1: easy case
Delete the search key 17 from the B+-tree index
Delete example 1: easy case
Find the search key 17 in a leaf node
Delete example 1: easy case
Remove the search key 17 and its record pointer
Delete example 1: easy case
Check for underflow condition: no overflow - done !! (notice anything in the internal nodes ?)
Delete example 1: easy case
Note: search keys in internal nodes are used to access the (actual) index file stored in the leaf nodes !
Example 2: deletion solved by a transfer
Delete the search key 7 from the B+-tree index (I will skip the search step)...
Example 2: deletion solved by a transfer
After deletion, we check for underflow: max = 3 keys, min occupancy: 2 keys - underflow !!
Example 2: deletion solved by a transfer
The left sibling has 3 keys -- sibling has a key to spare: transfer the last key (=5)
Example 2: deletion solved by a transfer
We must update the search key in the parent node !!! (B+-tree is wrong if you omit update - next)
Example 2: deletion solved by a transfer
If key update is omitted, the search key 5 is in the wrong branch of the B+-tree !!!
Example 3: deletion solved by a merge
operation
Delete the search key 11
Example 3: deletion solved by a merge
operation
Resulting node has < 2 search keys: underflow
Example 3: deletion solved by a merge
operation
Sibling nodes have no key to spare....
Example 3: deletion solved by a merge
operation
Merge the underflow node with its left sibling and call DeleteInternal(... parent(L)) to delete empty node ...
Example 3: deletion solved by a merge
operation
DeleteInternal(... parent(L)) will delete search key 5 and its right tree pointer...
Example 3: deletion solved by a merge
operation
After deletion, we check for underflow condition -- no underflow: done !!!
Example 4: deletion solved by a merge
and then a transfer
Delete the search key 11
Example 4: deletion solved by a merge
and then a transfer
Sibbling node can not spare any keys - so we cannot use transfer to resolve underflow
Example 4: deletion solved by a merge
and then a transfer
As last resort, we merge the underflow node with its (left) sibling
Example 4: deletion solved by a merge
and then a transfer
Merge will result in a empty (right) node: call DeleteInternal( 2, 5, parent(L) )
Example 4: deletion solved by a merge
and then a transfer
After DeleteInternal( 2, 5, parent(L) ), the resulting node has 1 pointer (and must have ≥ 2) -- underflow
Example 4: deletion solved by a merge
and then a transfer
The right sibling node has 1 pointer to spare: use transfer - which is like a tree rotation
Example 4: deletion solved by a merge
and then a transfer
Transfer will: (1) copy 13 from parent + left most link from sibling and (2) replace 13 with the left most key in sibling
Example 4: deletion solved by a merge
and then a transfer
Tree is redrawn - you can see that there are no underflow nodes - done !!
Example 5: how a B+-tree decrees in # levels
Delete the search key 11
Example 5: how a B+-tree decrees in # levels
Result node is underflow - must use merge to resolve underflow
Example 5: how a B+-tree decrees in # levels
After merging, we proceed to delete the empty node from tree
Example 5: how a B+-tree decrees in # levels
Empty node is removed by deleting (key, rightTreePtr) from parent node
Example 5: how a B+-tree decrees in # levels
Resulting node is underflow that must be resolved with a merge operation
Example 5: how a B+-tree decrees in # levels
Figure denotes the movement of keys and pointers in merge operation - always merged into the left node
Example 5: how a B+-tree decrees in # levels
After merging, we must remove the empty node from the B+-tree
Example 5: how a B+-tree decrees in # levels
This is done by deleting a (key, rightTreePtr) from parent node
Example 5: how a B+-tree decrees in # levels
Resulting (root) node has only 1 pointer - underflow
Example 5: how a B+-tree decrees in # levels
We simply remove a root node that has 1 pointer and make the child node the new root !!
- Delete the
index entry
for the
search key 31
from the following
B+-tree:
- Delete key 31
(and its record pointer)
from a leaf node:
- Find the
leaf node L that would
contain
search key
31:
- Delete
the index entry for
(31, recordPtr(31)) from
the node:
Result:
- Find the
leaf node L that would
contain
search key
31:
- Notice that:
- The
deleted
search key 31
can still in
the
inner nodes of the
B+-tree:
Comment:
- The inner nodes of a
B+-tree
is only an auxilary structure
to help you
locate an
index
- The actual index file is (only) stored in the leaf nodes of the B+-tree !!
- The inner nodes of a
B+-tree
is only an auxilary structure
to help you
locate an
index
- The
deleted
search key 31
can still in
the
inner nodes of the
B+-tree:
- Delete the search key 7
from the following
B+-tree:
- Delete
key 7 (and its record pointer)
from a leaf node:
- (I skipped the
step to
find the node
that would contain the
search key 7
This step should be known to you by now....)
- After deleting
(7, recordPtr(7)) from
the node:
We solve the underflow condition using a leaf transfer from the left sibling node.
- After
the leaf transfer
operation:
Note:
- We
must update
the
parent's node key to
reflect an
updated range
If you do not update the parent's node key, the B+-tree will have an error:
You cannot find the index entry for search key 5 with the B+-tree !!!
- We
must update
the
parent's node key to
reflect an
updated range
- (I skipped the
step to
find the node
that would contain the
search key 7
- Delete the search key 11
from the following
B+-tree:
- Delete
key 11 (and its record pointer)
from a leaf node:
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- After deleting
(11, recordPtr(11)) from
the node:
Underflow !!!
First check if transfer is possible:
- Transfer a
key from its
left sibling:
- Not possible: the left sibling is a minimal B-tree node
- Transfer a
key from its
right sibling:
- Not possible: the right sibling is a minimal B-tree node
We cannot use transfer from either siblings to solve the underflow condition
We have to use merge.....
- Transfer a
key from its
left sibling:
- Merge the
node into its
left sibling node:
Initial state:
Merge the underflow node with its left sibling node:
Delete (5, rightTree(5)) from the parent node:
- Delete
(5, rightTree(5)) from
an internal node:
The node is not underflow, because 2 (= at least half) of the 4 pointers are used:
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- Delete the seearch key 11
from the following
B+-tree:
- Delete
key 11 (and its record pointer)
from a leaf node:
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- After deleting
(11, recordPtr(11)) from
the node:
Transfer options:
- Transfer a
key from its
left sibling:
- Not possible: the left sibling is a minimal B-tree node
- Transfer a
key from its
right sibling:
- Not possible: there is no right sibling node !!!
We cannot use transfer from either siblings to solve the underflow condition
We have to use merge.....
- Transfer a
key from its
left sibling:
- Merge the
node into its
left sibling node:
Initial state:
Result of the merge operation:
The delete algorithm will call InternalNode_Delete( (5, rightTree(5) ) to delete (5, rightTree(5)) from parent node:
The InternalNode_Delete( (5, rightTree(5) ) call will solve the deletion using a transfer operation...
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- Processing
InternalNode_Delete( (5, rightTree(5) ):
- Initial state:
- After
deleting the
search key
(5, rightTree(5):
- Recall the transfer operation
for internal nodes:
In this case:
Result:
Done !
- Initial state:
- Delete the seearch key 11
from the following
B+-tree:
- Delete
key 11 (and its record pointer)
from a leaf node:
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- After deleting
(11, recordPtr(11)) from
the node:
Underflow !!!
Transfer options:
- Transfer a
key from its
left sibling:
- Not possible: the left sibling is a minimal B-tree node
- Transfer a
key from its
right sibling:
- Not possible: there is no right sibling node !!!
We cannot use transfer from siblings to solve the underflow condition
We have to use merge.....
- Transfer a
key from its
left sibling:
- Merge the
node into its
left sibling node:
Initial state:
Result of the merge operation:
The (leaf node) delete algorithm will call InternalNode_Delete( (5, rightTree(5) ) to delete (5, rightTree(5)) from parent node:
We will see that the InternalNode_Delete( ) algorithm will need to use merge in this case
- (I skipped the
step to
find the node
that would contain the
search key 11 )
- Processing
InternalNode_Delete(5, rightTree(5))
:
- After
deleting the search key
(5, rightTree(5)):
Underflow !!!
Transfer options:
- Transfer a
key from its
left sibling:
- No possible: there is no left sibling node !!!
- Transfer a
key from its
right sibling:
- Not possible: right sibling node is a minimal node !!!
We cannot use transfer from siblings to solve the underflow condition
We have to use merge.....
- Transfer a
key from its
left sibling:
- Recall the merge operation
for internal nodes:
We must "sandwich" the key 15 between the 2 merged node....
In this case:
Result of the merge operation:
The merge is followed by a delete operation in the parent node: InternalNode_Delete( (13, (rightTree(13) ) :
-
Initial state:
- After
deleting the search key
(5, rightTree(5)):
- Processing
InternalNode_Delete(13, rightTree(13))
:
- Initial state:
After deleting (13, rightTree(13)):
An empty root node can be removed:
Done !
- Initial state:
-
Comment:
- The root deletion part of
the delete algorithm is
not given in the
lecture notes
(nor in the text book
- As a home work exercise, you will fix the delete algorithm so it can delete the root node when it's empty
- The root deletion part of
the delete algorithm is
not given in the
lecture notes
(nor in the text book