たとえば、クラスを格納するテーブルと、class_attributes を格納するテーブルがあります。class_attributes には class_attribute_id と class_id があり、classes には class_id があります。
データセットが「の唯一の子」または「のみに属している」または「のみが所有している」場合、親を識別するために FK が必要だと思います。class_attributes テーブルに class_id がないと、この属性がどのクラスに属しているかを見つけることができませんでした。
たぶん、これに役立つ回答マトリックスがありますか?
答えのマトリックスはありませんが、明確にするために、データベースの正規化について話しています。
http://en.wikipedia.org/wiki/Database_normalization
そして、ある程度の非正規化:
ウィキペディアは役に立ちます。
リレーショナル データベースのコンテキストでは、外部キーは 2 つのテーブル間の参照制約です。1外部キーは、別の (参照される) テーブルの列または列のセットを参照する、1 つの (参照する) テーブルの列または列のセットを識別します。参照テーブルの列は、参照テーブルの主キーまたは他の候補キーである必要があります。
（そして、それはますます詳細に進みます）
class_attributes の各行がクラスの 1 行だけに適用されるという制約を適用する場合は、外部キーが必要です。これを強制することに関心がない場合 (つまり、存在しないクラスの属性を使用しても問題ない場合)、FK は必要ありません。
私が言うには、それは逆です。まず、必要なオブジェクトの種類を設計します。それらのためにテーブルを作成します。
このフェーズの一部は、オブジェクトを一意に識別する属性 (列) の組み合わせであるキーの設計です。便宜上またはパフォーマンス上の理由から、人工キーまたは代理キーを追加する場合と追加しない場合があります。通常、これらのキーから 1 つの正規キー (主キー) を選択します。これは、そのテーブル内のオブジェクトを識別するために一貫して使用しようとします (他のキーも保持します。それらはビジネス ルールとしての単一性を確保するのに役立ちますが、識別のためではありません)。目的。）
次に、オブジェクト間にどのような関係が存在するかを考えます。別のオブジェクトによって「所有」されているオブジェクト、または別のオブジェクトを参照するオブジェクトには、関連するオブジェクトを識別する何らかの方法が必要です。対応するテーブル (子テーブル) に列を追加して、参照されるテーブルの主キーを指す外部キーを作成します。
これにより、すべての 1 対多の関係が処理されます。
場合によっては、オブジェクトが別のオブジェクトに複数回関連付けられることがあります。たとえば、1 つの注文を使用して複数の製品を注文できますが、1 つの製品を複数の注文に表示することもできます。これらの関係については、別のテーブル (交差テーブル - この例では order_items) を設計します。このテーブルには、2 つの外部キーから作成された一意のキーがあります。ここでも、これらの外部キーを作成するために必要な交差テーブルに列を追加します。
つまり、最初にキーと外部キーを設計してから、それらを実装するための列を追加し始めます。
リレーションシップの種類は気にしないでください。それはリレーションシップのカーディナリティと関係があります。
1 対多の関係がある場合は、主キーを小さい方のテーブルに割り当て、それを大きい方のテーブルに外部キーとして格納します。
1 対 1 の関係でもそれを行いますが、避けるべきだと主張する人もいます。
多対多の関係の場合、結合テーブルを作成し、元の各テーブルに結合テーブルへの外部キーを持たせます。