基本的には、ユーザーが階層モデルを定義できるようにしたいが、ユーザーが定義したモデル内にデータを格納できるようにする必要がある。これは理にかなっていますか？したがって、ユーザーは新しい「ユニットタイプ」を作成して階層的に編成することができ、これらのタイプのユニットの編成方法を決めることができます。簡単な例：私の仮説的なインターフェースでは、ユーザーは3つのユニットタイプ、トランク、ブランチ、リーフを作成します。ユーザーは、それらの間の関係を定義します。リーフは階層内の任意のポイントに存在することができ、ブランチには親としてトランクが必要です。ユーザーは、これらのユニットタイプのインスタンスを（ユニットとして）作成し、そのモデルで定義されたルールに従ってそれらを整理することができます。データベースでこれを行うには良い方法がありますか？データベースでユーザー定義の階層関係をモデル化する最適な方法は何ですか？
これは非常に幅広い質問ですが、正しい方向に指摘することがあります。リレーションシップルールはデータベースにのみ保存できることに注意してください。それらを強制することはあなたのクライアントコードに依存します。あなたはその後、
unit idが、それは説明していますユニットに関する..次のようにあなたのユニットの関係テーブルを使用することができます
unit:
unit id,
name,
unit relationship:
unit id,
foreign unit id
..サイズのためにこれをしてみてください。 foreign unit idはnull可能である必要があります。
unit関係レコードは、階層のルートにのみ存在できます。foreign unit idを有するunitは、その親として他の任意のunitを有することができる。そうでない場合、unitは親として別のunitを持たなければならず、そのタイプは関係レコードに定義されているタイプの1つでなければなりません。単純明快であるべき自分自身のインスタンスを格納するよう
..
instance:
instance id,
unit id,
parent instance_id
私はあなたが（例えば、名前を）必要があると思い、他のフィールドが存在することになると確信しているが、私はあなたが得ると仮定ドリフト。
：あなたは3つのコンセプトを実装する必要が
モデルでは独立していますが、一緒に働きます。
create table unittype
(
id int;
name varchar(20);
)
create table unitrelationship
(
id int;
parent_id int;
)
あなたは自己参照テーブルとして階層構造をモデル化することができます：
create table hierarchy
(
id int;
parent_id int;
unit_type_id int;
unit_id int;
)
あなたはその後、1つまたは複数のテーブルにあなたのユニットのインスタンスを持っていて、説明したものを彼らと行うことができます。
create table unit
{
id int;
....
}
良いニュースは、あなたが許可されたタイプのすべての既存のユニットのリストから親を選ぶことにより、例えば簡単にユーザーインターフェイスに強制することができる唯一の許可親タイプを、制約されていることです。
複数の階層（1組の子、複数の階層ビュー）をサポートする必要がありますが、私は同様の問題に取り組んでいます。私はジョーCelkoの "スマイリーのためのSQLの木と階層"（ISBN：1558609202）が便利であることを発見しました。私はまだこの問題に取り組んでいますが、このトピックについて議論するときには、それが言及するのが適切であるように思われることがよくあります。
これは「隣接リスト」と呼ばれるものですか？ – ninesided
いいえ、これは下から上に向かって定義されたツリー構造です（言い換えれば、親に子のリストを示すのではなく、子を親に示すことによって子を定義します）。隣接関係リストは周期的な接続を可能にしますが、ツリーは循環接続を許可しません。 –
そのようなツリーを構築するには、各ノードに親を決定するためのクエリは必要ありませんか？それともRDBMSに依存するでしょうか？私は、ツリーウォーキングのためにOracleでCONNECT_BY_PRIORが使用されていると思っています。 – ninesided