多次元Mtreeツリー

プログラミングにおけるデータの編成は非常に重要です。 データを整理する方法は多くありません。 さまざまなデータ構造の中で、ツリーの形でデータの編成に特別な場所が与えられています。



これは最も一般的なデータ構成であり、他のすべてのデータ構造は簡単にモデル化できます。 配列、キュー、スタックはツリーに簡単に実装できます。 情報システムの作成における長年の経験により、このデータ構造の汎用性が確認されました。 ただし、ツリーの主な利点は、エンティティ間の関係のモデリングに現れます。 もちろん、ツリーはこれを行う唯一の方法でも、最も一般的な方法でもありません。 SQLモデルでは、これはテーブルの形式で実行されます。 この方法は、最も一般的ですが、最適ではありません。 この場合、データ操作言語の効率が犠牲になります。 これは、異常なデータ編成のためのさまざまな通常のフォームにつながります。 一連のテーブルと比較して、ツリーの方が多く勝ちます。 もちろん、ツリーはデータを保存する方法ではありませんが、データにアクセスするときの効率の観点から決定的なものですが、データにアクセスする方法です。 ツリーには、ツリーノードの子孫を列挙するイテレータが必要です。このレベルで次の子孫を見つけ、このノードの親を見つけることができます。 これらのアクセス方法を持つ単純なシーケンシャルファイルでさえ、あらゆるデータ構造をツリーのように扱うことができます。 完全な幸福のために他に何が必要なのでしょうか？ しかし、場合によってはこの構造では十分ではないことが判明しました。これは私にとっては啓示でした。 ツリー拡張を考え出さなければなりませんでした。 この拡張をN次Mtreeツリーと呼びます。 これはそのようなツリーであり、その各ノードには、データと直接の子孫に加えて、N-ブランチも含まれます。 2次Mtreeツリーノードには、メインと代替の2つのブランチが含まれます。 このような構造は、メインブランチがエンティティの関係を反映し、エンティティ自体が階層オブジェクトである場合に必要です。



mtreeツリーは、btreeツリーと同様に構築できます。 Btreeツリーは、多くのITプロジェクトで広く使用されている非常に効率的な構造です。 特に、この構造はMUMPSシステムでデータを実装します。その利点は、 以前の投稿で書きました。 このデータ構成がMUMPSに与える影響を過大評価することは困難です。 この言語の主な特性は、正確にBtreeツリーの形式のデータの階層構造によるものです。 そして、データの木製組織のために、言語データ宣言の欠如のためにプログラミングコミュニティによって最も非難されます。 ツリーのさまざまなノードでデータを宣言する方法はほとんどわかりません。 そして、ツリーのすべてのノードが同じタイプを持つと仮定することは非常に奇妙です。 他の言語では、言語とその中のデータの組織との間にそのような密接な関係はありません。



しかし、階層構造は理想的ではありませんでした。 データ構造をそれにマッピングすることは非常に便利ですが、そのようなツリーのノードに格納できるのは単純な変数のみです。 そして、オブジェクトのプロパティを保存する必要がある場合は？ また、オブジェクト自体がオブジェクトになり、新しい階層が作成されます。 そのため、新しいデータ構造が必要です。 2次のMtreeツリー。



MUMPSを展開してオブジェクトを保存しようとすると、2次のMtreeデータツリーを作成することになりました。 そして、このツリーに基づいて、 以前の別の投稿で書いたMSH言語を作成します。



このようなツリーは、オブジェクトとそのプロパティをツリーノードに格納する問題を解決します。 メイン階層はオブジェクト間の関係を反映し、代替ブランチにはオブジェクトのプロパティが含まれます。 これは、多次元ツリーの唯一の用途ではありません。 このような構造でファイルシステムを構築するのは簡単です。 ディレクトリ名をメイン階層に保存し、ファイル名と代替ブランチの占有ブロックへのリンクを保存できます。 DOMブラウザもこの構造に簡単に当てはまります。 多次元ツリーに適用する方法は他にもあると思います。



構造と言語を考え出すことがすべてではありません。 これらのアイデアの実装が必要です。 私がした2次のMtreeツリーの実装の最初の段階。 全体としてのプログラミングが完了し、基本的なデバッグが行われますが、ベースのより包括的なテストが必要です。 プログラミングは、Linux NetBeans IDEシステムのC言語で行われます。 誰でも助けたいという願望があれば、メールに書いてください。