16

動作しないコードを修正するのではなく、概念を理解しようとしています。

フォーム（親テーブル）とフォームフィールド（子テーブル）の一般的な例を取り上げます。論理的には、フォームフィールドはフォームなしでは存在できないため、これは識別関係になります。

formおよびform_fieldテーブル

これにより、論理的な関係を技術的NOT NULLな関係に変換するには、form_fieldテーブルのform_idフィールドを単純化するだけで十分だと思います。（上のスクリーンショットの左側を参照してください。）

ただし、MySQL Workbenchを使用して識別関係を追加すると、form_idはNOT NULL主キーの一部であるだけでなく、その一部でもあります。（上のスクリーンショットの右側を参照してください。）そして、非識別関係を追加してNOT NULLも、論理的に適用されるので、実際には識別関係にもなります。

これは私を少し混乱させると思います。また、これまで私は常にidフィールドを主キーとして使用していたという事実もあります。

したがって、識別関係と非識別関係の論理的な概念は理解していますが、技術的な部分は理解していません。

この回答が述べているように、なぜ「外部キーを子の主キーの一部にする「正しい」方法」なのですか？

これらの複合主キーの利点は何ですか？

4

2 に答える 2

7

フォームフィールドはフォームなしでは存在できないため、論理的には、これは識別関係になります。

いいえ、識別関係は識別に関するものであり、存在ではありません。

X> = 1であるX：Y関係は、識別するかどうかに関係なく、左側の存在を保証します。あなたの場合、1：Nの関係はform、任意のの存在を保証しますform_field。あなたはそれを識別または非識別にすることができ、それでも同じことを保証します。

備考：

  • キーの一部を作成することにより、識別関係をモデル化form_field.form_idします。たとえば、form_fieldPKは次のようになります{form_id, label}。これは、データの適切なクラスタリングに非常に役立ちます（InnoDBテーブルは常にクラスター化されます）。
  • このスーパーキーは候補キーではないため、PKを作成するだけ{id, form_id}では正しくありません（つまり、最小ではありません。削除form_idしても一意性を維持できます）。
  • NULL可能にすることで0..1：N関係をモデル化しform_field.form_idます（ただし、それを識別させることもできなくなります-以下を参照してください）。

「識別関係」には2つの定義があります。

  • 厳密な定義：親キーを子主キー1に移行する関係。
  • 緩い定義：親キーを子キーに移行する関係。

言い換えると、緩い定義により、（プライマリだけでなく）代替キーへの移行も可能になります。

ただし、ほとんどのツール2は厳密な定義を使用しているようです。したがって、関係を識別としてマークすると、移行された属性が自動的に子PKの一部になり、PK属性をNULLにすることはできません。

1これは、移行された属性から完全に構成されるか、移行された属性といくつかの追加の属性の組み合わせです。

2ERwinとVisioはそうします。私はまだモデリングにMySQLWorkbenchを使用していませんが、あなたの説明はそれが同じように動作することを示唆しているようです。

于 2012-11-08T18:22:55.900 に答える
2

識別関係は、主キーに外部キー属性が含まれている関係であると想定されています。そのため、投稿された外部キーを識別するものとして関係を指定すると、主キーの一部と見なされます。

「識別」関係と非識別関係の違いは、同じキー制約とnull可能性制約がそれぞれの場合に適用される場合、純粋に情報提供または図式です。この概念は、「主」キーを指定することに類似しており、その結果です。テーブルに複数の候補キーがある場合、他のすべての条件が同じであれば、論理的な観点から、どのキーがプライマリキーとして指定されているかは重要ではありません。つまり、テーブルの形式、機能、および（おそらく）ビジネス上の意味は同じです。

ただし、この例では、2つのテーブルのキーは同じではありません。前者の場合、IDはform_fieldテーブルで一意ですが、後者の場合、明らかにそうではありません。それはあなたが意図したものではないと思います。

于 2012-11-08T18:01:30.970 に答える