• Fact: a merge operation decrease the number of entries in an internal node

• Look carefully at the merge operation:

• remove(6):

• Perform left merge:

• Result:

Observation:

 The parent node has one entry fewer !!! (The parent node has 2 entries (5,8) before the merge operation, and it has only one entry (8) after the merge operation)

• Underflow at the parent node of the delete target node

• Facts:

• A delete operation will first reduce the number of entries in a leaf node

 This is because deleting a entry stored in an internal node will result in moving its successor entry (that is stored in a leaf node into the internal node

• When a leaf node is empty (underflow), we may need to use a merge operation to resolve the underflow condition

• The merge operation will "remove" one entry from the parent node of the underflow node

 If the parentnode has only one entry, then the parent node itself will become empty (i.e., underflow) !!!!

• Example:

• Delete key entry 7:

• Perform a merge operation:

• Important note:

• The underflow situation in the internal node is identical to the underflow situation in the leaf node:

• The underflow in the leaf node (which we have learned how to resolve with a merge operation):

• The underflow in the internal node:

• How to handle a underflow condition in an internal node:

• Use the same technique that you learned:

1. If the node has a immediate sibling with ≥ 2 entries, then:

 Use a transfer operation (and you are done)

2. If the node has only immediate sibling nodes with 1 entry, then:

 Use a merge operation

In this case, the parent node may become empty and you may need to repeat the procedure again !

(Can you smell recursion ???)

• Example cascaded underflow 1: cascaded underflow handled by a transfer operation

• Example:

• Delete key entry 7:

• After the merge operation:

• This underflow can be solved with a transfer operation:

Notice that:

• The left most subtree link of the right sibling is also transferred !!!

 This left most subtree link will occupy the second slot in the entry

• The parent reference of that subtree must be updated !!!

• Note: transfer with the left sibling

• When you perform a transfer operation with your left sibling, you will also transfer the right most subtree link into the sibling node

• The right most subtree link will occupy the first slot in the entry

• Example:

• Example cascaded underflow 2: cascaded underflow handled by a merge operation

• Example:

• Delete key entry 7:

• After a merge operation:

• This underflow must be resolved with another merge operation:

• Result of the cascaded deletion:

 The second merge operation again "removes" one entry from the grand parent node of the target delete node The grand parent node can also suffer a underflow condition.... This cascaded underflow/merge sequence will eventually end when an entry is removed from the root node If the root node has one (1) entry, the removal will can the root node to become empty An empty root node is discarded (and the previously merged node becomes the new root !)

• Example: underflow at the root node

• An example where a deletion causes the root node to underflow (and then removed):

• Delete key entry 7:

There is an underflow....

• The sibling node has 1 entry we must use a merge operation:

There is another underflow....

This time, the sibling node has only one entry (15)

So we must perform another merge operation....

• We perform a merge operation:

There is another underflow....

Again, the sibling node has only one entry (70), and we must perform another merge operation....

But now, we have reached the root node !!!

 The merge operation that merges with the root node will reduce the height of the 2,4-tree !!!

• Observe the merge operation with the root node:

• There is no more parent node, so we replace the root node:

DONE !!!