0

次の例を考えてみましょう。「is-a」と書くときは、1 対 1 の関係を形成するために、そのテーブルの主キーであり、別のテーブルへの外部キーでもある列を意味します。「has-a」と書くときは、通常の外部キー列を意味し、1 対多の関係を形成します。

  • フルーツバスケットテーブル.
  • リンゴかごのテーブル、「is-a」フルーツバスケット。
  • オレンジ色のバスケット テーブル、「is-a」フルーツバスケット。
  • フルーツテーブル「has-a」フルーツバスケット。
  • りんごの食卓、「is-a」フルーツ。
  • オレンジ色のテーブル、"is-a" フルーツ。

当分の間、null 許容列または型列挙で親テーブルを乱雑にする代わりに、そのテーブルの存在を保証するのに十分なコンテキスト固有の列が applebasket、orangebasket、apple、および orange にあると仮定します。

質問:

  • fruit と fruitbasket を関連付けるのと、apple と applebasket + orange と orangebasket を関連付けるのとでは、どちらがより適切でしょうか? 前者は冗長性が低いように見えますが、潜在的に無効な関係を持つ可能性があります (たとえば、リンゴ -> 果物 -> 果物かご -> オレンジかご)。後者はリレーションを強制的に有効にしますが、より冗長であり、他の継承するフルーツ テーブルは独自のバスケット外部キーを宣言する必要があります。
  • 具体的には PostgreSQL の場合、最初の選択肢 (フルーツ バスケットに関連するもの) を考えると、関係の妥当性をチェックする最も簡単な方法は何ですか? 3 つの結合を実行する必要があります。
  • これをきれいに実装するための他の提案はありますか?

ありがとう...

4

1 に答える 1

1

あなたはこれを少し間違っていると思います。リレーショナル データ モデリングはデータに関するものであり、オブジェクト モデリングは動作に関するものです。 これらは異なる分野であり、オブジェクト リレーショナル データ モデリングが好きなのと同じくらい、データベースに属するものではありません。代わりに、機能の依存関係を調べて、そのようにモデル化してください。そうしないと、複数のアプリが同じデータに異なる方法でアクセスしようとすると、問題が発生する可能性があります。

たとえば、2 つのアプリケーションがあるとします。データを引き出して操作し、動作をモデル化します。2 つ目は、データを引き出して静的データとして扱い、情報を導き出します。LSP で「正方形は長方形です」と言うことができる場合は、自分のように。最初のケースでは、いいえ。2 番目のケースでは、はい。最初のケースでは has-a "rectangular_area" を使用したいかもしれませんし、2 番目のケースでは "is-arectangle" が完全に有効です。

これで 2 番目のポイントになります。この種の複雑な関係を見ている場合、マッピングを行う方法は、データで何をしているかに依存する可能性があります。一般に、行動要素ではなく定義要素に基づいてデータを制約する方が適切です。したがって、この場合、必要な場所にマッピングがあります。次に、次のことを提案します。

  1. 果物（リンゴ、ナシ、オレンジなどを保存）。
  2. これに必要な補足テーブル。
  3. フルーツバスケット
  4. フルーツ バスケットに入っている果物の種類を示す多対多マッピング テーブル。

これは特にあなたの質問に私をもたらします：

fruit と fruitbasket を関連付けるのと、apple と applebasket + orange と orangebasket を関連付けるのとでは、どちらがより適切でしょうか?

両方。同時に。上記を参照。

具体的には PostgreSQL の場合、最初の選択肢 (フルーツ バスケットに関連するもの) を考えると、関係の妥当性をチェックする最も簡単な方法は何ですか?

宣言的な参照整合性は、あなたをそこまで連れて行ってくれます。片側が DEFERRABLE INITIALLY DEFERRED に設定された双方向外部キーを使用することを恐れないでください。

于 2012-09-17T06:46:10.647 に答える