10

問題のあるドメイン

私は、階層データモデルを使用するかなり大きなアプリケーションに取り組んでいます。画像を取得し、画像の特徴を抽出し、これらの上に分析オブジェクトを作成します。したがって、基本モデルはObject-（1：N）-Image_features-（1：1）-Imageのようなものです。ただし、同じ画像セットを使用して、複数の分析オブジェクトを作成できます（オプションが異なります）。

次に、オブジェクトと画像に他の多くの接続されたオブジェクトを含めることができます。たとえば、分析オブジェクトを追加のデータで洗練したり、分析オブジェクトや他のデータに基づいて複雑な結論（ソリューション）を作成したりできます。

現在のソリューション

これはソリューションのスケッチです。スタックはオブジェクトのセットを表し、矢印はポインタを表します（つまり、画像機能はそれらの画像にリンクしますが、その逆はありません）。一部の部分：画像、画像の特徴、追加データは、複数の分析オブジェクトに含まれる場合があります（ユーザーが異なるオブジェクトのセットを異なる方法で組み合わせて分析したいため）。

現在のソリューションの簡略化されたスケッチ

画像、特徴、追加データ、分析オブジェクトはグローバルストレージ（神オブジェクト）に保存されます。ソリューションは、コンポジションによって分析オブジェクト内に保存されます（そしてソリューション機能が順番に含まれます）。

すべてのエンティティ（画像、画像機能、分析オブジェクト、ソリューション、追加データ）は、対応するクラス（IImageなど）のインスタンスです。ほとんどすべてのパーツはオプションです（つまり、解決策が見つかった後で画像を破棄したい場合があります）。

現在のソリューションの欠点

  1. スケッチの点線のような接続が必要な場合、この構造をナビゲートするのは面倒です。いくつかのソリューション機能を上部に持つ画像を表示する必要がある場合は、最初に分析オブジェクトを反復処理して、この画像に基づいているものを見つけてから、ソリューションを反復処理して表示する必要があります。
  2. 1.を解決する場合、点線のリンクを明示的に保存することを選択します（つまり、画像クラスには、それに関連するソリューション機能へのポインターがあります）。これらのポインターの一貫性を維持し、何かが変更されたときにリンクを常に更新することに多大な労力を費やします。 。

私の考え

より拡張性のある（2）柔軟な（1）データモデルを構築したいと思います。最初のアイデアは、オブジェクトとその関係を分離するリレーショナルモデルを使用することでした。そして、ここでRDBMSを使用してみませんか？sqliteは私にとって適切なエンジンのようです。したがって、複雑な関係には、データベース上の単純な（左）JOIN：疑似コード " images JOIN images_to_image_features JOIN image_features JOIN image_features_to_objects JOIN objects JOIN solutions JOIN solution_features"）を使用してアクセスし、IDによってグローバルストレージからソリューション機能の実際のC++オブジェクトをフェッチします。

質問

だから私の主な質問は

  • RDBMSを使用することは、私が説明した問題の適切な解決策ですか、それとも価値がなく、アプリで情報を整理するためのより良い方法がありますか？

RDBMSに問題がない場合は、RDBMSとリレーショナルアプローチを使用してC++オブジェクトの関係を格納する方法についてアドバイスをいただければ幸いです。

4

4 に答える 4

4

RDF、RDFS、OWLなど、世界をモデル化するための代替の拡張可能な方法を提供するセマンティックWebテクノロジーを検討することをお勧めします。いくつかのオープンソースのトリプルストアが利用可能であり、主流のRDBMSのいくつかにはトリプルストア機能もあります。

特に、マンチェスター大学のProtege / OWLチュートリアルをご覧ください：http：//owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/

そして、この方向性をさらに検討する価値があると判断した場合は、「作業中のオントロジストのためのセマンティックWeb」をお勧めします。

于 2012-08-27T11:04:56.527 に答える
3

図に基づいて、RDBMSソリューションが実際に機能することをお勧めします。私がRDMS（もちろん、RDMと呼ばれます！）の開発者であったのは何年も前のことですが、すばらしいものを読むことで、知識を更新し、データ構造とレイアウトについて非常に多くの貴重な洞察を得ることができました。 StephaneFaroultによる本「TheArtofSQL」。彼の本はあなたの質問に答えるのに大いに役立つでしょう。

正確さを確保するために、Amazonにリンクを含めました：http：//www.amazon.com/The-Art-SQL-Stephane-Faroult/dp/0596008945

たとえそれがあなたの問題を完全に解決しなくても、それを読んでも間違いはありません。なぜなら、著者は明確な言葉で関係を分解し、エレガントな解決策を提示するという素晴らしい仕事をしているからです。この本はSQLのマニュアルではありませんが、データについての考え方とデータの相互関係についての詳細な分析です。見てみな！

RDBMSを使用してデータ間のリンクを追跡することは、探している分析を保存して考えるための効率的な方法であり、リンクは「ソフト」です。つまり、リンクしているハードオブジェクトが削除されると消えます。これにより、データの整合性が保証されます。そしてMssrFauroultは、それが真実であり続けることを確実にするために何をすべきかについて答えることができます。

于 2012-08-24T16:26:59.210 に答える
1

http://www.boost.org/doc/libs/1_51_0/libs/multi_index/doc/index.html

「これらのポインタの一貫性を維持し、何かが変更されたときにリンクを絶えず更新することに多大な労力を費やします。」

Boost.MultiIndexの助けを借りて、「テーブル」上にほぼすべての種類のインデックスを作成できます。引用された問題はそれほど深刻ではないと思うので、元の解決策は管理可能です。

于 2012-08-25T06:26:15.657 に答える
1

拡張可能で柔軟なモデルの要件に基づいて、RDBMSをお勧めしません。

  1. データモデルを変更するときはいつでも、DBスキーマを変更する必要があり、コードの変更よりも多くの作業が必要になる可能性があります。
  2. DBクエリに関する問題は、実行時にのみ検出されます。これは、メンテナンスのコストに大きな違いをもたらす可能性があります。

STLで標準のC++OOプログラミングを使用することを強くお勧めします。

  1. カプセル化を利用して、関連するオブジェクトとインデックスを更新し、データの変更が適切に行われるようにすることができます。
  2. STLを使用して、データに非常に効率的なインデックスを作成できます
  3. 複数のオブジェクト/コレクションに移動するのではなく、ファサードを作成して情報を簡単に取得できます。これは1回限りの作業になります
  4. ユニットテストケースを作成して、正確性を確認できます（データベースを使用したユニットテストと比較して、はるかに複雑ではありません）。
  5. ポリモーフィズムを利用して、さまざまな種類のオブジェクト、さまざまな種類の分析などを構築できます。

すべての非常に基本的なポイントですが、DBベースのソリューションを探すよりも、現在のソリューションを改善する場合に、あなたの努力が最も有効に活用されると思います。

于 2012-08-29T05:32:46.787 に答える