私は次のデータベース設計を持っています：
そして、EReportReqに主キーeReportReqIdとして列が必要なのか、それともeReportIdとrequirementIdを主キーとして使用できるのか疑問に思っています。
要件テーブルにはシステム情報とEReportテーブル（ここには表示されていません）が含まれ、EReportReqとEReportReqImgにはユーザーデータが含まれます。
EReportReqは、EReportの一部である要件を表します。要件は、複数のEReportの一部である可能性があります。
また、 EReportReqImgは、EReportの一部である要件の画像（1つ以上）を表します。
主キーとしてeReportReqIdが必要ですか？
が同じものに複数回EReport接続できないと仮定すると、どのような場合でもキーになります。唯一の質問は、追加の代理キー（）が必要ですか？決定に役立つ可能性のあるいくつかの基準を次に示します。 Requirement{eReportId, requirementId}eReportReqId
私の個人的な勘は、その質問に対する答えは「いいえ」であるということです。そのため、最終的には次のようなモデルになります。
このモデルでは、場合によっては参加を減らすことができます。たとえば、指定されたすべての画像を取得するには、 -EReportをスキャンするだけで満足できます。-はすでに存在するため、データを直接フィルタリングするために使用できます（を取得するためだけに参加する必要はありません）。EReportReqImgeReportIdEReportReqeReportId
また、インデックス内のデータ（およびDBMSがサポートしている場合はテーブル全体）を適切にクラスター化し、特定の範囲スキャンを非常に効率的にします（上記のものを含む）。
テーブルの主キーとしてeReportReqIdは必要ありませんが、場合によっては、独自の主キーが必要になることもあります。
これは、EReportReqのFKによって異なります。FKのeReportIdとrequirementIdの組み合わせがEReportReqで一意である必要がある場合は、もちろん、それを一般化して、FKをEReportReqの主キーとして使用できます。それ以外の場合は、主キー用に別の列（eReportReqIdなど）が必要になります。
補足として、それを一般化し、FKを主キーとして使用する場合は、EReportReqImgテーブルをEReportReqに正規化することも検討する必要があります。