リレーショナルデータベーススキーマ - リレーションシップと外部キー

Question

次のケース内のエンティティ間の関係を持っているとき、私は理解に苦労しています：

私は外部キーを持っているいくつかのエンティティを持っている場合、フィールドは名前のNODE_IDを言いますこれはノートのIDとNotesエンティティを表していますが、それらのエンティティ間に関係が必要ですか？ここで

はあなたが外部キーとしてフィールドを設定する場合は、すでにデータベース内に2つのテーブル間の関係を設定しているので、私はあなたの質問があると仮定し

Answer 1

より明示的であるかもしれない私のスキーマのサブセットですスキーマ表現についてのみ説明します。

答えははいです。テーブルAからテーブルBへの外部キーがある場合、テーブルAの行はテーブルBとの接続を持ち、スキーマではこの接続を指定して視覚化する必要があります。

スキーマはデータベース構造の迅速かつ正確な説明を提供するので便利です。リレーションシップを省略すると、スキームを読んでいる人がフィールドがある理由を理解できないか、必要なクエリを作成する最良の方法が見つからないその関係。

間違ったスキーマまたは不完全なスキーマは、あなたは、エンティティ、リレーションシップ、図、表およびFKSについて混乱しているようだ

Answer 2

本当に無意味です。

ER図（オリジナル）のこのスタイルでは、ボックスはエンティティタイプ用で、ダイヤモンドはリレーションシップ/アソシエーションタイプ用です。 （ERの "R"は関連の意味での "関係"を意味します）。各タイプはテーブルを取得します。ダイヤモンドからボックスへの線は、関連する被参照エンティティの参加を表します。それらは、エンティティテーブルを参照する関連テーブルからのFKに対応します。

注意：情報モデリング方法やその提示方法によっては、「関係」は時には「関連」を意味することもあります。時には「外部キー」を意味することもあります。ダイアグラムスタイル。

（いくつかのダイアグラム方法では、「関連エンティティ」が許可されています）関連エンティティは、関連付けの参加者のリストから形成されたものです。これは、関連エンティティを構成するエンティティが後続の関連付けに参加する必要があるだけでなく、元の関連付けにも参加しなければならないということを意味します。関連団体の更なる関連への参加には、その関連団体のさらなる関連への直接参加を明示する必要もなく、対応する直接FKもありません。

Answer 3

エンティティ・リレーションシップ・モデルでは、外部キー制約により、リレーションシップ内のエンティティ・セットのタイプが強制されます。したがって、あなたがFKを持っているなら、それは関係もあることを意味します。この2つを混同しないでください.FKは1つのエンティティセットを強制するバイナリサブセットリレーションです。リレーションシップは複数の異なるエンティティセット（および複数のFK制約）を含むことができるn元関係です。

この例では、図に示されるNotesとの明示的な関係について説明しています。