0

これは簡単な質問ですが、私はいつも間違った方法を使っていたと思います。

Page -> Tag -> Attributeという 3 つのテーブルがあります。Tag テーブルは Page_Id (外部キー) を受け取り、Attribute テーブルは Tag_Id (外部キー) を受け取ります。

属性テーブルも Page_Id を受け取る必要がありますか?

私はこれをしたことはありませんが、これを行うデータベース SQL ジェネレーターを見たので、これによりすべての作業が簡単になることに気付きましたが、これも正しい方法ですか?

テーブルの詳細を編集:ページ テーブルには、HTML ページと、コンテンツ、タイトル、Doctype、および HTML ページの他のすべての単一要素などの属性が含まれています。

タグ テーブルには、タグ (a、p、br、h1、タイトルなど) やタグ全体などの情報を含む html ページの HTML タグが含まれています。

属性テーブルにはタグのすべての属性が含まれており、各エントリが属性と値であるキーと値を持つマップのようなものです。

ページには複数のタグ (1:N) が含まれ、タグには複数の属性 (1:N) が含まれます。各テーブルには一意の ID が含まれています。

4

3 に答える 3

2

これは、「場合による」状況の 1 つです。に結合することでこの情報を取得できるため、論理的に に値を格納する必要はありません。AttributeTag

ただし、状況によっては、に参加しなくてもから に「ジャンプ」できると便利な場合があります。このような状況では、 に含めることができますが、に格納されている値と矛盾しないように、制約を追加する必要があります。AttributePageTagPage_IdAttributeTag

この一貫性を強制するには、Tag定義する通常のキー (例: Tag_Id) と、 および のスーパーキーの 2 つのキーを宣言Tag_IdしますPage_Id。次に、両方の列Attributeを含む外部キー制約を宣言し、このスーパーキーを参照します。の外部キー制約の代わりに、またはそれに加えてそれを行うかどうかは、好み/スタイルの問題でもあります。Tag_Id

Tags が s を変更する可能性が高い場合Pageは、通常、スーパーキーへの外部キーを がUPDATE CASCADE発生するものとして宣言します。このようにして、テーブルに変更があった場合、Page_IdそのTag変更はテーブルに自動的に適用されAttributeます。

于 2012-04-19T12:22:28.623 に答える
1

必須ではありません。厳密に正規化する場合、答えは「page_id をテーブル属性に含めないでください」である必要があります。ただし、テーブルを非正規化するために（レポートまたは単にいくつかのアクションを高速化するために）必要になることがよくあります。たとえば、単純なクエリで取得できるテーブルにフィールドを追加する（例のように）。

于 2012-04-19T12:24:01.770 に答える
1

私はあなたのテーブル構造を見たことがないので、あなたの説明に行かなければなりません. それは常に危険です。

ページとタグの間に 1:M の関係があり、タグと属性の間に 1:M の関係があることを説明が意味する場合、開始関係のサンプル データは次の表のようになります。(開始リレーションには、常にすべてのテーブルのすべての属性が含まれます。)

  • page_id はページを識別するためのものですが、
  • tag_id はタグを識別するためのものであり、

  • タグの属性は、そのタグが表示されるページによって異なります。(したがって、タグと属性の間に複数値の依存関係はありません。)

    Table_A
page_id  page_name  tag_id  tag_name  attr_id
--
1        page1      1       tag1      attr1
1        page1      1       tag1      attr2
1        page1      2       tag2      attr1
1        page1      2       tag2      attr3
2        page2      1       tag1      attr1
2        page2      1       tag1      attr2
2        page2      2       tag2      attr1
2        page2      2       tag2      attr2

あなたの説明から、page_id -> page_name、および tag_id -> tag_name は既にわかっています。(自分を傷つけようとしているのでない限り、page_name -> page_id と tag_name -> tag_id も同様です。) それでは、その知識に基づいて新しいテーブルを射影しましょう。

Table_C
tag_id  tag_name
--
1       tag1
2       tag2

Table_B
page_id  page_name
--
1        page1
2        page2

Table_A
page_id  tag_id  attr_id
--
1        1       attr1
1        1       attr2
1        2       attr1
1        2       attr3
2        1       attr1
2        1       attr2
2        2       attr1
2        2       attr2

Table_A に残っている関数依存、複数値依存、または結合依存は? ありません。唯一の候補キーは {page_id, tag_id, attr_id} です。これらのテーブルの 3 つすべてが少なくとも 5NF にあると確信しています。

したがって、開始テーブルを正規化すると、「最後の」テーブルに page_id が含まれます。(ちなみに、これはもはや属性テーブルではありませんよね?)

于 2012-04-22T03:25:53.230 に答える