k -d ツリーに適合する B+ ツリーを実装する必要があります。これを簡単に説明すると、k -d 木は二分木に似ていますが、ノードに多値キー (複数の値を持つキー) がある点が異なります。また、内部ノードはキーの値の 1 つだけを格納するためのものであり、実際のデータはリーフ ノードに格納されるため、B+ ツリーにもなります。これを図で簡単に説明すると、次のようになります。
リーフ ノードには 2 つの要素用のスペースがあります。最初の 2 つを追加すると、すべて正常に動作しますが、3 つ目を追加して分割する必要があります。そのために、キーの最初の値を順序を定義するものとして選択するため、3 つの要素すべての中央値を取得すると、結果は 27 になるため、27 未満のすべての要素は左に移動し、それよりも大きい要素は左に移動します。右に行くよりも等しい。
4 番目の要素を追加すると、Tom と Linda の年齢は 27 歳未満であるため、すでに葉ノードを完成させています。息子が Dom を追加すると、ノードが再び分割されますが、今回は、Social である順序を定義するキーの値を切り替える必要があります。セキュリティ番号。再び中央値を取ると、結果は 530 なので、SS 番号が 530 未満のものはすべて左に移動します。
最終的なk -d ツリーが生成され、キーの特定の値が内部ノードのインデックスとして使用され、完全なキーがリーフ ノードに含まれます。
ここで私の質問は、コンテキストを説明した後、リーフ ノードに完全なキーを格納する必要があることを考えると、キーのソリューションをどのように実装できるかということですが、内部ノードではキーの値の 1 つだけを使用します。 .
値を持つ複数のフィールドがあるデータベースとの類似性に気付くことができます。また、異なるフィールドで同時に情報を並べ替えることができます。
上記の例では、すべての値を保持する属性を使用して、名前付きまたはその他の名前classを作成することを考えました。これは、年齢、SSNumber、および名前の場合があります。しかし、私の問題は、クライアントがより多くの値を追加したいと判断した場合、私のクラスはどんどん大きくなっていくということです。これは良い OO の決定ですか? これを別の方法で実装しても OO のままにすることはできますか? 私の想像力が貧弱であることは承知していますが、クライアントがより多くの値を望んでいると想定できるので、私の値を保持するある種のリストを作成することができます。オブジェクト指向のアプローチのようには聞こえません。何か案は？Keyintintstring
また、ツリーのアルゴリズムのある時点で、ツリーのインデックスとして使用するキーの 1 つの属性を取得する必要があるため、これもサポートする必要があることを追加したいと思います。
オブジェクト指向のアプローチに従ってこれを解決する方法を教えていただければ幸いです。