1

この質問はスレッドに基づいています。

1 対多のデー​​タ構造の場合、たとえば 1 人の電話番号を格納するための「ヘルプ テーブル」が必要です。多くの人が同じ電話番号を持つことはできません。

多対多の関係の間に 2 つの「ヘルプ テーブル」が必要な理由の説明を楽しみにしています。この例は、多くのユーザーが同じタグを追加できる質問サイトです。

代替テキスト http://files.getdropbox.com/u/175564/db/db-55.png

なぜテーブルQuestion-Tag-xrefとテーブルが必要なのQuestion-Tagsですか?

次のように、タグ用のテーブルを 1 つだけ持つことができないのはなぜですか?

   Question_id   |    tag
   1                  C 
   1                  C++
   2                  Java
   2                  C

2 つの異なる質問に同じタグが付けられているという事実が、コンピューターにとって問題になるのはなぜですか?

4

7 に答える 7

4

それは「余分な」テーブルの 1 つだけです。

これは、同じ質問に多くのタグが含まれている可能性があるためです。

また、同じタグが多くの質問で使用される可能性があるためです。

(questionId、tagId) を保存し、その重複がないことを確認する場所が必要です。

このトピックに関するあなたの質問には従いませんでしたが、ここには悪い設計があるようです。合理的な構造をしていると思っていたので、追加のテーブルが1つしかないと思いました。そうしない。

Question-Tags にタグ文字列とタグ ID の両方があるのはなぜですか? それは私にはあまり意味がありません。

一連の質問に戻りたくありません。それでも、私が話していることを説明したかったのです。そこで、 NORMAツールを使用して、StackOverflow のこの部分の非常に単純なオブジェクト ロール モデリング モデルを作成しました。

StackOverflow の単純なモデル

これにより、次のER図が生成されました。

ER図

タグについて保持する必要があるのは「余分な」テーブルだけであることに注意してください。これは、タグに関する追加情報が保持されていないためです。また、タグ名はすでに一意であるため、タグ テーブルへの外部キーであるタグ ID を格納する必要はありません。タグに関する追加データを保持すると、別のタグ テーブルが存在し、主キーはタグ名のままになります。パフォーマンスの問題が発生した場合は、整数 ID を使用するように変更できます。その場合、タグ名は引き続き一意のインデックスを取得します。

于 2009-07-26T21:42:19.250 に答える
4

ノーマライゼーションの問題です。このテーマに関する最高の本の 1 つは、Joe Celko の SQL for Smartiesです。基本的に、いわゆる「異常」を回避します。あなたの例では、「Java」タグが付いたすべての質問を削除すると、「Java」というタグがあったことを知ることができなくなります（異常の削除）。プリンシパル間の関係のプロパティを記述するには外部参照テーブルが必要なので、テーブルをクラックアウトすることも重要です。

于 2009-07-26T21:44:46.280 に答える
1

リレーショナル データベースでは、多対多の関係は 2 つの相互の 1 対多の関係として実装されます。各関係には、(エンティティを直接表すテーブル以外に) 追加のテーブルが必要です。

  • まず、最初のテーブルの行と 2 番目のテーブルの多くの行の間の一対多の関係。
  • 2 つ目は、2 番目のテーブルの行と最初のテーブルの多くの行との間のもう 1 つの一対多の関係です。

その理由は、リレーショナル データベース モデルに関係しています。

于 2009-07-26T21:56:17.553 に答える
1

他の人が言ったことに追加するだけです（私は彼らのコメントを繰り返しません）

私の経験では、通常はヘルプ テーブルではなく、結合テーブルと呼ばれます。通常、単純なキーワードよりも複雑なものを扱っています。「追加」テーブルは、他の 2 つのエンティティ間の関係をモデル化します。

もう 1 つの例は、多くの受信者の連絡先に向けたマーケティング キャンペーンを行っている場合です。これら 2 つのエンティティは、どちらも他方に依存していません。特定のキャンペーンには多くの連絡先があり、連絡先には複数のキャンペーンが送信される場合があります。この場合の結合テーブルは、誰がどのキャンペーンを送信したかの履歴をモデル化します。

Campaign 
 - CampaignID (PK)
 - other columns

Contact 
 - ContactID (PK)
 - other columns

CampaignContact
 - CampaignContactID (PK)
 - CampaignID (FK)
 - ContactID (FK)

これは、1 対多の関係 (主従関係と呼ばれることもあります) とはまったく異なります。ここでの標準的な例は Invoice -> InvoiceItems です。請求書項目は、1 つの親請求書のみに明確にリンクします。

Invoice
 - InvoiceID (PK)
 - other columns

InvoiceItem
 - InvoiceItemID (PK)
 - InvoiceID (FK)
 - other columns
于 2009-07-26T22:03:29.817 に答える
1

http://en.wikipedia.org/wiki/Database_normalization

コンピュータにとっては問題ではありませんが、RDBMS の理論によると、db は情報の重複を減らすために正規化する必要があります。正常化の必要性について Codd 博士は次のように述べています。

  1. リレーションのコレクションを望ましくない挿入、更新、および削除の依存関係から解放する。
  2. 新しいタイプのデータが導入されたときに関係のコレクションを再構築する必要性を減らし、アプリケーション プログラムの寿命を延ばす。
  3. リレーショナル モデルをユーザーにとってより有益なものにするため。
  4. リレーションのコレクションをクエリ統計に対してニュートラルにするため。これらの統計は時間の経過とともに変化する可能性があります。

EF コッド、「データベース リレーショナル モデルのさらなる正規化」

于 2009-07-26T21:45:52.097 に答える
1

問題は、テーブル構造をどの程度正規化するかです。通常、情報を複数の場所に保存することは望ましくありません。そのために、データが多くのアイテムで繰り返される可能性がある場合は、データを正規化します。そのデータを別のテーブルに移動し、データ自体ではなくデータのキーを格納することで、他のテーブルの複数の行がデータを参照できるようにします。同じデータを共有する多くの行があり、それを正規化したい場合は、テーブル間の関係 (参照ペア) を格納する中間テーブルが必要です。

于 2009-07-26T21:46:03.830 に答える
0

通常、これは単なるタグ列よりも多くの情報です。したがって、それが大量の情報である場合は、冗長なデータがあります (例には 2 つの「C」値があります)。次に、同じ値が複数の場所に存在する場合、更新が問題になります。そのため、データは 1 つの場所に存在し、その ID は他の場所で参照するために使用されるという規則があります。その後、更新するときは、1 か所で行うだけで済みます。

于 2009-07-26T21:47:53.857 に答える