# How to handle duplicates in Binary Search Tree?

Introduction

Binary Search Trees (BSTs) are strong data structures used in computer science to perform efficient searching, addition, and deletion operations. However, when working with datasets that may include duplicate values, it is critical to manage these duplicates efficiently.

Understanding Binary Search Trees:

Before we get into addressing duplicates, let's go over the fundamentals of Binary Search Trees. A BST is a sort of hierarchical data structure composed of nodes. Each node has at most two children: a left and a right subtree. A BST's distinguishing property is that for any given node, all nodes in its left subtree have values lower than its value, while all nodes in its right subtree have values higher than its value. This structure enables quick searching, with an average time complexity of O(log n).

### Handling Duplicates:

In a standard BST, every node is expected to have a novel key. Nonetheless, copy keys might be available in the information. There are a few ways to deal with handle duplicates in a BST:

1. Count based approach
• One basic methodology is to expand every node of the BST with a counter to monitor the number of events of a specific key.
• While embedding a duplicate key, rather than making another node, we increase the counter of the current node.
• During search tasks, we want to, as need be, think about the count of duplicates and navigate.

Consider a Binary Search Tree (BST) where every node is expanded with a counter to monitor the number of events of a specific key.

We should embed the accompanying keys into the BST: [5, 3, 7, 5, 3, 7, 5, 8].

• At first, the BST is empty:
• Embedding the key 5:

Since the tree is unfilled, we make another hub with key 5 and set its counter to 1:

• Embedding the key 3:

We navigate the tree and observe that 3 is under 5, so we go to one side subtree, which is unfilled. We embed another hub with key 3 and set its counter to 1:

• Embedding the key 7:

7 is more prominent than 5, so we go to one side subtree. Since it's vacant, we embed another hub with key 7 and set its counter to 1:

• Embedding the key 5 once more:

We experience a hub with key 5. Rather than making another hub, we increase the counter of the current hub:

Additionally, embedding the keys 3, 7, and 5 again brings about increasing the counters of the individual hubs.

• At last, embedding the key 8:

During search tasks:

• While looking for a key, we consider the count of copies and cross likewise.
• For instance, while looking for key 5, we would experience the hub with a count of 3 and visit it multiple times to represent all events of the key 5.

2. Node modification:

• Another methodology is to change the construction of every node to permit duplicates.
• As opposed to having quite recently left and right children, every node might contain numerous children, each addressing a duplicate key.
• This approach requires cautious treatment of node inclusion, erasure, and crossing to keep up with the BST properties.

Consider a Binary Search Tree (BST) where every node is changed to permit copies. Rather than having quite recently a left and right child, every node might contain various children, each addressing a duplicate key.

We should embed the accompanying keys into the BST: [5, 3, 7, 5, 3, 7, 5, 8].

• At first, the BST is empty:

Embedding the key 5:

Since the tree is vacant, we make another node with key 5:

• Embedding the key 3:

We navigate the tree and observe that 3 is under 5, so we go to the left subtree, which is unfilled. We embed another node with key 3:

• Embedding the key 7:

7 is more noteworthy than 5, so we go to the left subtree. Since it's unfilled, we embed another node with key 7:

• Embedding the key 5 once more:

We experience a node with key 5. Rather than making another node, we add one more child to the current node to address the duplicate key:

Essentially, embedding the keys 3, 7, and 5 again brings about adding children to the separate nodes.

At long last, embedding the key 8:

During crossing:

• During the all-together crossing, we visit nodes in non-diminishing requests. Hence, we want to guarantee that all events of a key are visited as needed.

This approach requires cautious treatment of node inclusion, cancellation, and crossing to keep up with the BST properties while taking into account numerous events of keys inside every node.

3. Handling during insertion:

• While embedding another node with a duplicate key, we can decide to put it either to the left or right of the current node.
• One normal system is to put copies to the right of the current node, guaranteeing that the left subtree contains just keys, not exactly the ongoing node's vital.
• On the other hand, copies can be set to one side, making a reflected design.

Consider a Binary Search Tree (BST) where we handle copy keys during inclusion by picking whether to put copies to the left or right of the current hub.

We should embed the accompanying keys into the BST: [5, 3, 7, 5, 3, 7, 5, 8].

• At first, the BST is vacant:
• Embedding the key 5:

Since the tree is vacant, we make another node with key 5:

• Embedding the key 3:

We navigate the tree and observe that 3 is under 5, so we go to the left subtree. We embed another node with key 3:

• Embedding the key 7:

7 is more noteworthy than 5, so we go to the right subtree. We embed another node with key 7:

• Embedding the key 5 once more:

We experience a node with key 5. By deciding to put duplicates to the right, we embed the copy key 5 to the right of the current node:

Also, embedding the keys 3, 7, and 5 again brings about setting duplicates to one side of the current nodes.

• At long last, embedding the key 8:

During traversal:

• Since we decided to put copies to the right, the left subtree contains just keys, not exactly the ongoing hub's critical, guaranteeing the BST property.

On the other hand, copies can be set to one side, making a reflected construction. This approach keeps up with the BST property while taking care of duplicate keys but with an alternate plan of nodes.

4. Traversal and removal

• During traversal (in-order, pre-order, post-order), we want to guarantee that all events of a copy key are visited.
• We should change the tree structure while eliminating a node with duplicate keys while keeping up with the BST properties.

Consider a Binary Search Tree (BST) where we want to guarantee that all events of a duplicate key are visited during traversal. Furthermore, while eliminating a node with duplicate keys, we should cautiously change the tree structure while keeping up with the BST properties.

How about we work with the accompanying BST containing copy keys: [5, 3, 7, 5, 3, 7, 5, 8]?

Traversal:

• During in-order traversal, we visit nodes in non-diminishing requests. In this manner, we want to guarantee that all events of a key are visited.
• For instance, during in-order traversal, we would visit the nodes in the accompanying request: [3, 3, 5, 5, 5, 7, 7, 8].

Removal:

• Assume we need to eliminate the node with key 5.
• We find the node with key 5 and eliminate it from the tree.
• Since the node has duplicate keys, we should cautiously change the tree structure while keeping up with the BST properties.
• One normal methodology is to supplant the node with its replacement or ancestor in the BST.
• Suppose we supplant it with its replacement, which is the base key in its right subtree (in-order successor).
• The in-order successor of 5 is 7.

We eliminate the node with key 5 and supplant it with the node with key 7.

• Presently, the tree keeps up with the BST properties, and all events of the duplicate key 5 have been taken out.

This approach guarantees that during traversal, all events of duplicate keys are visited, and during the evacuation, the tree structure is painstakingly changed while keeping up with the BST properties.

For Videos Join Our Youtube Channel: Join Now