5

リレーショナル モデルとデータ モデリングを学んでいます。
そして、サブタイプに関して頭の中に混乱があります。

データ モデリングは反復プロセスであり、モデル化にはさまざまな方法があることを私は知っています。
しかし、さまざまなオプションから選択する方法がわかりません。

粒子(分子、原子、陽子、中性子、電子など)をモデル化するとします。
簡単にするために、クォークやその他の粒子は無視しましょう。

同じタイプの粒子はすべて同じように動作するため、個々の粒子をモデル化するつもりはありません。
別の言い方をすれば、すべての水素原子を保存するつもりはありません。
代わりに、水素、酸素、およびその他の原子タイプを保存します。
モデル化しようとしているのは、実際には粒子の種類とそれらの間の関係です。

「タイプ」という言葉をうっかり使っています。
水素原子はインスタンスです。水素はタイプです。水素も原子の一種です。
はい、関連する型の階層があります。そして、最低レベル (個々の粒子) を無視しています。

アプローチ

それらをモデル化するためのいくつかのアプローチを考えることができます。

1. モノのタイプ (粒子タイプ) ごとに 1 つのテーブル (関係、エンティティ)。

1.1 頭に浮かんだ最初のアプローチ。

陽子(陽子)
中性子(中性子)
電子(電子)

Atom (原子)
Atom_Proton (原子、陽子、数量)
Atom_Neutron (原子、中性子、数量)
Atom_Electron (原子、電子、数量)

Molecule (分子)
Molecule_Atom (分子、原子、量)

1.2 陽子/中性子/電子は 1 種類しかないので、簡略化できます。

Atom (原子、陽子量、中性子量、電子量)
Molecule (分子)
Molecule_Atom (分子、原子、量)

この単純化されたモデルでは、プロトンに関する事実は失われています。

2. すべてのものを 1 つのテーブルにまとめ、関連テーブルがそれらの間の関係を表します。

2.1 リレーションシップごとに 1 つの連想テーブル

粒子(粒子)

Atom_Proton (粒子、粒子、陽子量)
Atom_Neutron (粒子、粒子、中性子量)
Atom_Electron (粒子、粒子、電子量)
Molecule_Atom (粒子、粒子、原子量)

2.2 単一連想テーブル

Particle (粒子)
ParticleComposition (粒子、粒子、量)

この単純化によって何も失われることはありません。私はそれが良いと思います。しかし、 Atom_Proton / Atom_Neutron / Atom_Electron
に固有の事実がある場合は、2.1 の方が優れている可能性があります。

2.3 2.1 と 2.2 を組み合わせる

粒子(粒子)

Atom_Proton (粒子、粒子、その他の属性)
Atom_Neutron (粒子、粒子、その他の属性)
Atom_Electron (粒子、粒子、その他の属性) Molecule_Atom (粒子、粒子、その他の属性)

ParticleComposition (粒子、粒子、量、その他の属性)

このアプローチでは、粒子組成に関する一般的な属性はParticleCompositionに入り、
粒子組成に関する特別な属性は特別なテーブルに入ります。

3. サブタイプ テーブルを使用します。

3.1 基本タイプParticleの表と、サブタイプ ( AtomMoleculeなど) の追加表。

粒子(粒子)

Proton (粒子、その他の属性)
Neutron (粒子、その他の属性)
Electron (粒子、その他の属性)
Atom (粒子、その他の属性)
Molecule (粒子、その他の属性)

Atom_Proton (粒子、粒子、陽子量)
Atom_Neutron (粒子、粒子、中性子量)
Atom_Electron (粒子、粒子、電子量)
Molecule_Atom (粒子、粒子、原子量)

3.2 Atom のAtom_XXXQuantityテーブルを組み合わせて、 Pronton / Neutron / Electronを削除することもできます。

粒子(粒子)

原子(粒子、陽子量、中性子量、電子量)
分子(粒子、その他の属性)

Molecule_Atom (粒子、粒子、原子量)

より単純ですが、1.2 のように陽子/中性子/電子に関する情報が失われます。

3.3 Molecule_Atomの名前をより一般的なものに変更できます。

粒子(粒子)

原子(粒子、陽子量、中性子量、電子量)
分子(粒子、その他の属性)

ParticleComposition (粒子、粒子、数量)

これは 2.2 のように見えますが、サブタイプ ( AtomMolecule ) のテーブルが追加されています。
2.2 は 3.3 の特殊なケースのようです。

3.4 上記のすべてのアプローチを組み合わせて、一般的なモデルを取得できます。

粒子(粒子)

Proton (粒子、その他の属性)
Neutron (粒子、その他の属性)
Electron (粒子、その他の属性)
Atom (粒子、その他の属性)
Molecule (粒子、その他の属性)

ParticleComposition (粒子、粒子、量、その他の属性)

Atom_Proton (粒子、粒子、その他の属性)
Atom_Neutron (粒子、粒子、その他の属性)
Atom_Electron (粒子、粒子、その他の属性)
Molecule_Atom (粒子、粒子、その他の属性)

Atom_Proton 、Atom_NeutronAtom_ElectronMolecule_AtomParticleCompositionのサブタイプと考えることができるようです

このアプローチは最も複雑なもので、多くのテーブルが含まれていますが、各テーブルにはそれぞれの役割があります。

質問

  1. 上記の設計のいずれかがリレーショナル モデルのルールを破っていますか?
  2. どのアプローチが最適ですか? それは、データに対する考え方に依存しますか? それは要件に依存しますか?
  3. 要件に依存する場合は、最初に最も単純な設計を選択し、新しい要件に対応するためにそれをより一般的なものにしますか?
    結果として得られるデータ モデルには多くの類似点がありますが、最初の設計がテーブル/列の命名に影響する可能性があり、キーのドメインが異なります。

    • 物事の種類ごとに 1 つのテーブルを使用することを選択した場合、Atom の原子量と Molecule の分子名など、Atom と Molecule に互換性ないキー選択する可能性あります
    • 一般的なアプローチを使用する場合は、すべてのパーティクルに共通のキーを選択できます。
      キーを変更すると、システムへの影響が大きくなる可能性があるため、単純な設計から一般的な設計に進化させるのは容易ではない可能性があります。
      どう思いますか?

PS:これは適切な例ではない可能性があり、解決策には問題がある可能性があり、アプローチにはさらにバリエーションがある可能性がありますが、うまくいけば要点を理解できます。
より良いデザインがあれば、私と共有してください。


更新 1

モデル化するデータは何ですか?

最初は、粒子をモデル化しようとしていました。

  • それらの間にサブタイピング関係があると思います。これはまさに私が探しているものです。
  • 彼らは人々によく理解されています(?)。
  • これは、人々が世界をどのように理解しているかを示す良い例です。

ここに私の心の絵があります。 粒子階層

私が何をモデル化しようとしているのかについてもあまり明確ではなかったので、私はこれを明確に述べませんでした.
最初に、Atom は Proton/Neutron/Electron の親であり、Molecule は Atom の親であると考えました。次に、これはコンポジションに関するものであり、サブタイピングに関するものではなく、 Type Hierarchy
に関するものではないことに気付きました。

種類

しばらくの間、タイプ、およびグループ化と分類について考えてきました。

以下は " SQL and Relational Theory "からの引用です:

では、タイプとは正確には何ですか?本質的に、これは名前付きの有限の値のセットです─ 特定の種類の可能なすべての値: たとえば、可能なすべての整数、可能なすべての文字列、可能なすべてのサプライヤー番号、すべての可能な XML ドキュメント、または可能なすべての関係特定の見出し (など)。

整数のセットを表すために「整数」という名前が付けられました。
実際、人々は物事を識別するために概念と名前を作り出し、世界を理解/モデル化できるように物事をグループ化しました。

陽子は実際の陽子の集合、水素は水素原子の集合などです。
この意味で、実際のパーティクルは型階層の最下位レベルにとどまります。
最初はすべての粒子をモデル化しようとしていましたが、行き詰まってしまいました。

  • それぞれの実際の粒子を識別するための適切なキーを思いつきませんでした。
  • それらが多すぎてデータベースに保存できません。

そこで、実際の粒子を無視して、代わりに型をモデル化することにしました。

「分子は原子で構成されている」と言うとき、それは「実際の H2O 分子は 2 つの実際の水素原子と 1 つの酸素原子で構成されている」ことを意味し、「任意の (タイプの) 分子が (いくつかのタイプの) で構成されている」ことも意味します。アトム」。

実際の粒子に関するすべての事実を述べる代わりに、粒子の種類に関する事実を述べることができます。
それが、モノや造語(タイプ)をグループ化することで得られるメリットです。

セットとしての粒子タイプ階層

階層はセット定義に変換できます。

第 2 レベル - 実際の粒子の上のタイプ:

S_proton = { p | p satisfied the definition of a proton }  
S_neutron = { n | n satisfied the definition of a neutron }  
S_electron = { e | e satisfied the definition of an electron }  
S_hydrogen = { h | h satisfied the definition of a hydrogen }  
S_oxygen = { o | o satisfied the definition of an oxygen }  
S_h2o = { w | w satisfied the definition of a h2o }  
S_o2 = { o | o satisfied the definition of a o2 }

より高いレベル

集合論の用語を使用すると、A が B のサブセットである場合、タイプ A は B のサブタイプです。

Atom 型を次のように定義できると最初に考えました。

S_atom = S_hydrogen union S_oxygen union ...

ただし、セットはリレーションで要素はタプルであるため、リレーション内のタプルに互換性がない場合、結合は機能しません。

サブタイプ テーブルを使用するアプローチは、問題を解決し、サブセットの関係をモデル化します。

しかし、サブタイピング アプローチでは、Atom はまだ2 番目のレベルにあります。

ここに画像の説明を入力

より高いレベルのタイプは、セットのセットとして定義されます。

S_atom = { S_hydrogen, S_oxygen, ... }
S_molecule = { S_h2o, S_o2, ... }
S_particle = { S_proton, S_neutron, S_electron, S_atom, S_molecule }

つまり、粒子は原子のタイプであり、原子は水素のタイプです。

このようにして、粒子間の関係を高いレベルで表現できます。

新しいデータモデル

4. 型を型の階層として扱う

ParticleType (ParticleType, Name)
ParticleTypeHierarchy (ParticleType, ParentType)
ParticleComposition (PartileType, SubParticleType, Quantity)

サンプルデータ:

粒子タイプ

| | 粒子タイプ | 名前 |
|------+----------|
| | 粒子 | 粒子 |
| | 陽子 | 陽子 |
| | 中性子 | 中性子 |
| | 電子 | 電子 | 電子 | 電子 |
| | アトム | アトム |
| | 分子 | 分子 |
| | ひ | 水素 |
| | お | 酸素 |
| | H2O | 水 | 水 |
| | O2 | 酸素 |

ParticleTypeHierarchy

| | 粒子タイプ | 親タイプ |
| --------------+------------ |
| | 陽子 | 粒子 |
| | 中性子 | 粒子 |
| | 電子 | 電子 | 粒子 |
| | アトム | 粒子 |
| | 分子 | 粒子 |
| | 水素 | アトム |
| | 酸素 | アトム |
| | H2O | 分子 |
| | O2 | 分子 |

粒子組成

| | 粒子タイプ | サブパーティクル タイプ | 数量 |
|-------------+-----------------+----------|
| | ひ | 陽子 | 1 |
| | ひ | 電子 | 電子 | 1 |
| | 彼 | 彼 | 陽子 | 2 |
| | 彼 | 彼 | 中性子 | 2 |
| | 彼 | 彼 | 電子 | 電子 | 2 |
| | H2O | ひ | 2 |
| | H2O | ひ | 2 |
| | H2O | お | 1 |
| | CO2 | シー | 1 |
| | CO2 | お | 2 |

比較のために、これはサブタイプ テーブル アプローチのサンプル データです。

粒子

| | パーティクル ID | パーティクル名 |
|------------+----------------|
| | ひ | 水素 |
| | 彼 | 彼 | ヘリウム |
| | 李 | リチウム |
| | | なる | ベリリウム |
| | H2O | 水 | 水 |
| | O2 | 酸素 |
| | CO2 | 二酸化炭素 |

分子

| | 分子 ID | some_attribute |
|------------+----------------|
| | H2O | ... |
| | O2 | ... |
| | CO2 | ... |

原子

| | AtomId | 陽子量 | 中性子量 | 電子量 |
|--------+----------------+-----------------+----- -------------|
| | ひ | 1 | 0 | 1 |
| | 彼 | 彼 | 2 | 2 | 2 |
| | 李 | 3 | 4 | 3 |
| | | なる | 4 | 5 | 4 |

粒子組成

| | パーティクル ID | コンポーネント ID | 数量 |
|------------+-------------+----------|
| | H2O | ひ | 2 |
| | H2O | お | 1 |
| | CO2 | シー | 1 |
| | CO2 | お | 2 |
| | O2 | お | 2 |

サブアトム

これらの粒子タイプは人々によって定義され、人々は現実の新しい側面をモデル化するために新しい概念を定義し続けています。
「サブアトム」を定義すると、階層は次のようになります。

サブアトムによる粒子タイプの階層

アプローチ 4 は、この型階層の変更により簡単に対応できます。


更新 2

記録する事実

  1. 世界には、陽子、中性子、電子、原子、分子など、さまざまな種類の粒子があります。
  2. 原子は、陽子、中性子、および電子で構成されています。
  3. 分子は原子で構成されています。
  4. 原子には、水素、酸素など、さまざまな種類があります。
  5. 分子には、H2O、O2 など、さまざまな種類があります。
  6. 水素原子は、1 つの陽子と 1 つの電子で構成されています。...
  7. H2O 分子は、2 つの水素原子と 1 つの酸素原子で構成されています。...
  8. 異なるタイプの粒子には特別な特性があります。たとえば、原子には原子の重さがあります。
  9. ...
4

3 に答える 3

6

予備

良い質問です。学習者にとって非常に思慮深いものです。あなたが本当に求めているのは、明確にするための議論だと思います。これはデータ モデリングの演習です。

  • 3.3までのあなたの進歩を理解しています。何をどのように 3.4 にしますか (段階的に 3.3 に進んだ後) ? 私にとって、上記のすべてを組み合わせることはGenericとは異なります。

  • あなたの進歩をたどり、各ステップのモデルを構築するのではなく、あなたの議論に従って、関連するステップの TRD で応答させてください。

  • キーによって識別されるTRDのみのテーブルと関係は、この段階で関連しています。属性がある場合は、属性と、それらがどのキーで展開されるかをよく知っていると思います。安定した TRD を達成したら、それを完全な DM に拡張できます。

  • モデルを組み立てた後、前のモデルからの進行を評価し、情報が失われていることが明らかな場合は、安全に破棄できます。そのようなモデルを検討している価値があるので、そのステップは間違っていません。しかし、それについての継続的な議論は無駄です。前の質問でそれを実証したと思います。

この一連のテーブル関係図について考えてみましょう。

1.x

私の見解では、A Firstは検討に値する最初の妥当な TRD です。

  • Proton/Neutron/Electron が独立したテーブルである方法や理由がわかりません。それらは単独では存在しません。などを修正しています。それらは Atom のコンテキストでのみ存在します。

  • すべてのアトムは少なくとも 1 つの陽子/中性子/電子で構成されているため、陽子/中性子/電子の列をアトムに配置できます。描かれていません。後で。

2.x

1 つの明らかなエラーを除いて、進行状況は問題ありません。

粒子組成に関する一般的な属性は ParticleComposition に入れられ、粒子組成に関する特別な属性は特別なテーブルに入れられます。

いいえ。パーティクルに関する一般的な属性はパーティクルに入ります。関係に固有の (つまり、一般的ではない) 属性は、ParticleComposition に入ります。そして、「粒子組成に関する特別な属性」も「特別なテーブル」もありません。

3.x

B サブタイプを検討してください。あなたの[3.1]は、次を除いてほとんど正しいです。

  • Particle に Proton/Neutron/Electron などの子がどのように存在するかわかりません。それを持っているのはアトムだけです。

  • 粒子が他の粒子とどのように関連しているかわかりません (つまり、それは何ですか?)。説明したデータの場合、分子は原子で構成されています。原子は陽子/中性子/電子で構成されています。Particle は Molecule xor Atom (Exclusive Subtype) のいずれかです。

  • それが正しくない場合は修正してください。

  • その件名の完全な詳細については、サブタイプ ドキュメントを参照してください。

あなたが述べたように、それはC Reducedである可能性があります。これは、陽子/中性子/電子情報が Atom ごとに固定されているという概念を保持しています。つまり、それぞれに 1 つのエントリがあるということです。例えば。各シェル/エネルギーレベルは区別されません。中性子には (Null の代わりに) ゼロを使用できます。

  • Predicates の優れた価値については、以前に説明しました。ここでの要点は、モデルが述語を識別するということです。述語はモデルを検証します。これは素晴らしいフィードバック ループです。自分で評価して、モデルの妥当性を確認できるように、述語を与えました。

3.3

完全にD 正規化されている場合: Atom には常に少なくとも Proton エントリがあります。Neutron エントリはオプションです。各シェル/エネルギー レベルは区別されます。

  • 述語の違いに注意してください。

  • リダクションは有効な手法ですが、正規化と同等ではないことに注意してください。

3.4

それは、フラットにレイアウトされた、またはフラット化されたビュー (派生リレーション、パースペクティブ、結果セット) のすべての合計のように見えます。理解のために、それで結構です。しかし、それを一連のテーブルとして提案した場合、さまざまな正規化エラーのために、それはひどく不正確です。これを修正すると、[3.3] と [D Normalized] に進みます。

質問

上記の設計のいずれかがリレーショナル モデルのルールを破っていますか?

[3.3] を除くそれらはすべて、多くの規則に違反しています。ほとんどの場合、正規化エラーのカテゴリに属します。完全なモデルまたは CREATE TABLE ステートメントを指定した場合、関連する識別エラーが発生します。

ただし、理解のために、コンテキストがデータ モデリングの演習であるかどうかは問題ではありません。この演習が深刻である場合、上記の段落は有効です。

このセクションは、SO ガイドラインに従って提示されています。件名の投稿にコメントしましたが、消え続けています。というわけでここに載せました。

Erwin Smout:
本質に切り詰めると、データのリレーショナル モデルには「ルール」が 1 つしかありません。データベース内のすべての情報は、リレーションのタプルの属性の値として表現する必要があります。

はい、それはルールの 1 つですが、同封のステートメントは明らかに誤りです。

第 1 に、リレーショナル モデルには多くの重要なルールまたは一次ルールがあります。記憶から、私は約40と言うでしょう。

第二に、多くの二次規則、つまり一次規則によって論理的に暗示されるものがあります。

  • 技術的な資格と経験を持ち、RMを理解できる人、その精神と意思を貫く人は全員フォローする。

  • 他の人は、一次ルールの一部、または暗黙のルールのほとんどを認識しない場合があります。

  • そして、 RMに関するものであると主張する書籍からも明らかなように、RMを積極的に覆し、縮小する人々もいます。彼らは二次規則を無視し、さらに悪いことに、ファリサイ的「論理」を使用して一次規則を弱体化させます。

  • ここで、 comp.databases.theory と TTMに関するRMに関する取り組みで有名な Erwin は、 RMを 1 つの簡潔なルールに減らし、ルールの完全なセットとRM自体を弱体化させています。具体的には、あなたの質問への回答です。私の回答がなければ、読者はRMが彼の考えているものであると信じるようになります.1つのルール、リレーショナルと非リレーショナルのすべてが「満たす」.

  • リレーショナル モデルは無料で入手でき、自分で読むことができます。コピーをご希望の場合はお知らせください。警告は、用語が時代遅れであり、説明する必要があることです。

第二に、それを 1 つのルール (不可能、還元主義的すぎる) または最も重要なルール (可能だが侮辱的) に要約したとしても、そのルールはそれではありません。これは 40 ほどの 1 次ルールの 1 つですが、上位にランク付けされているわけではありません。

  • ただし、他の人が自分の目的に合わせて異なるランキングを持っている可能性があることを認めます.

  • RMとその前任者との主な違い (ルールではない) として、RM を理解している人々が議論していることは次のとおりです。

    • それは完全な数学的定義 (その基礎を形成し、その中のすべてがそこから流れ出る) を持つ最初のものでした。

    • 前任者は物理レコード ID を使用してレコードを関連付けていましたが、RMは (a) データから作成された論理キー、および (b) それらの論理キーによって行 (レコードではない) を関連付けることを要求します。

これは、「主キー」として宣言されたすべてのファイルのレコード ID によって特徴付けられるシステムが、完全に非リレーショナルであり、1970 年以前の ISAM レコード ファイリング システムへの回帰であるという根拠であることに言及する必要があります。RMが時代遅れになったこと。また、統合失調症の「論理」によって、これらの原始システムが「リレーショナル」に見えるようにする方法にも注意してください。正直な論理は、そのようなナンセンスを破壊します。

このようなレコード ID ベースのシステムは、正確に誤った情報が原因で、業界のローエンドで標準になっています。したがって、それを修正する私の意欲。

誤報訂正セクションを終了します。

どのアプローチが最適ですか?

リレーショナル正規化を含む正式なデータ モデリング。NF 定義の断片ではなく、方法、科学、原理です。

私は提案が異なるアプローチであるとは認識していません。むしろ、1 つのモデリング演習ですべての考えをレイアウトしています。そして、モデルが本格的で実現可能な形になり始めるポイントは [3.3] です。

それは、データに対する考え方に依存しますか?

もちろん。あなたの結婚が成功するか失敗するかは、妻に対するあなたの認識に基づいています。モデルは、データに対する認識に基づいて成功するか失敗します。

リレーショナル モデルの優れた点の 1 つは、データをデータとして見る (認識し、考え、モデル化する) ことを教えてくれることです。まず、これが論理キーの概念を形成します。

それは要件に依存しますか?

最初の答えは、いいえ、要件に依存するべきではないということです。対象範囲が企業に限定されているデータ (要件はありますが、機能要件ではない) と、データのみを考慮する必要があります。

そしてもちろん、別の場所で詳述した理由により、データ モデルは現実の世界と一致する必要があり、データに対する機能の必要性を制限するべきではありません。

OO/ORM モデルの失敗の一般的な理由である大規模なエラーは、OO/ORM モデルの小さなレンズからデータを認識しているためです。データとプロセスを分離できず、データをオブジェクトの単なる「永続化」スレーブとして扱います。そのモデルには他にも多くのエラーがありますが、ここでは列挙しませんが、要点は、それらは要件の位置から始まり、データを無視するということです。

2 番目の答えは、要件が設定されるまでプロジェクトは委託されないということです。資金が要件ベースである場合の現実です。したがって、成熟したプロジェクト リーダーは、機能とは別に、データをデータとして分析およびモデル化するための十分な正当性が要件に含まれていることを確認します。

要件に依存する場合は、最初に最も単純な設計を選択し、新しい要件に対応するためにそれをより一般的なものにしますか?

できますが、それには莫大な費用がかかります。成熟した手順は、データ モデルをできるだけ早く正しく取得することです。

データモデルが現実世界と一致していれば、変更や追加が発生した場合でも簡単に拡張できます。逆に言えば、データモデルが機能要件に対して最低限のものであった場合、または現実世界と一致しない場合、変更は困難でコストがかかります。

結果として得られるデータ モデルには多くの類似点がありますが、初期設計がテーブル/列の命名に影響する可能性があり、キーのドメインが異なります。

もちろん。

物事の種類ごとに 1 つのテーブルを使用することを選択した場合、Atom の原子量と Molecule の分子名など、Atom と Molecule に互換性のないキーを選択する可能性があります。

それは恐ろしいエラーになります。ラベルと一致しない容器に物を入れないでください。1 つの容器 (ラベルは 1 つ) に 2 つの異なるものを入れないでください。正しい方法は、共通の識別子名 (原子名、分子名、または粒子名) を使用し、サブタイプを使用することです。

一般的なアプローチを使用する場合は、すべてのパーティクルに共通のキーを選択できます。

ある場合のみ。存在しない場合は、エンティティが同じではないこと、一般的なモデルを使用できないことを示しています。

キーを変更すると、システムへの影響が大きくなる可能性があるため、単純な設計から一般的な設計に進化させるのは容易ではない可能性があります。

アイデアは、キーを形成するために安定した (静的ではない) データ項目を選択することです。はい、キー デザインはモデリング作業の重要な側面です。リレーショナル モデルに従う場合、キーはデータベースの論理構造を形成します。ドメインは非常に重要です (お気づきだと思います)。そして、はい、変更するには費用がかかります。

これで要点に戻ります。これがまさに、各テーブルとそのすべての子に対して、キーをモデル化し、正しく選択する必要がある理由です。

アップデート 1 & 2

たった今、あなたの 2 つの更新に気付きました。これは完全な回答ではなく、今のところ非常に短い回答です。

  • これまで、粒子は原子の集合と分子の集合であると理解していました。それが私がD Normalizedでモデル化したものです。どちらも共通のキーである名前を持っています。サブタイプです。

しかし今、あなたの階層図とサンプル データ (ありがとう) を考えると、私があなたが意味していると思っていたことと、あなたが意味していたことは 2 つの異なるものであることがわかりました。更新された TRD & Hierarchyを検討してください。

  1. あなたの粒子は、分子のセットと原子のセットと素粒子のセットです。

    • それは間違っている

    • はい、階層がありますが、これまでのところ、1 つのテーブル内の階層としてではなく、一連のテーブルに存在します。

    • 別の言い方をすれば、2 つのセット (原子、分子) は離散的であり、それぞれが独自の構成要素のセットを持ち、それらは異なります。すべてを含む集合はありません (理論上の普遍集合を除く)。

    更新されたテーブル リレーション モデルはE Normalized • Update 2です。Subtypes は Particle とともに削除されました。Update 2 に記載されているすべての要件を提供します。更新された Predicate に注意してください。

  2. 階層図が正しくありません。

    • エラーは、分類子の階層 (構造、コンテナー) をデータ (分類子のインスタンス、コンテンツ) と組み合わせたことです。そんなことはできません。コンテナ用とコンテンツ用の 2 つの個別の図が必要です。

    • これは、OO/ORM の考え方の典型的な誤りです。データとプロセスを分離するという科学的原則の遵守の失敗。前の質問の、Hidders への回答で説明したのとまったく同じエラーです。結果は複雑なオブジェクトであり、実際には機能しません。

    • したがって、あなたの階層図は違法です。2 つの完全に異なる図を 1 つに結合したものです。

    F 階層 (分類)は、それだけを示しています。

    G Hierarchy (Sample Data)はそれを示しています。

    あなたが階層を描写する方法 (組織図) と私が階層を描写する方法 (Explorer) にはスタイルの違いがあります。1 つは非常に広くなり、もう 1 つはよりコンパクトになります。私はあなたがそれを理解できると思います

  3. 前の質問の最後で、ある程度明確になりました。その有毒な本のタイプの斬新な概念は、あなたを完全に混乱させました. この問題、これらの問題は、タイプとは何の関係もありません。

より多くの言葉が求められます。時間が許す限り、より完全に対応します。

于 2015-06-02T12:41:06.570 に答える
1

私は Fowler の Class Table Inheritance と Single Table Inheritance の扱いが好きです。ここでは、これらのデザインの両方に触れました。それぞれに用途と欠点があります。これらを検索語として使用すると、たくさん読むことができます。それのいくつかは価値があります。ここSOには、これらの名前のタグがいくつかあります。

今日のことはわかりませんが、約 20 年前のデータベース 101 コースではサブタイプが省略されることが多く、すべてのデータベース ビルダーが「現実の世界」に入るとすぐにこれに遭遇しました。

于 2015-06-01T09:24:03.517 に答える