database-design - 三項関係を二項関係に分解する

Question

私は、次の関係と制約を持つユーザー、アカウント、およびプロジェクトを処理するデータベースを設計しています。

• アカウントには多くのユーザーがいます
• ユーザーは多くのアカウントに属しています
• アカウントには多くのプロジェクトがあります
• プロジェクトは1つのアカウントにのみ属します
• ユーザーは多くのプロジェクトで共同作業を行います（冗長な注意：各プロジェクトは独自のアカウントに属しています）。

つまり、ユーザーは同じアカウントの多くのプロジェクトで共同作業を行うことができます。ただし、ユーザーは複数のアカウントに属することができるため、ユーザーは複数のアカウントの多くのプロジェクトで共同作業を行うことができます。これは私を三元の協力関係に導きます：

三項関係を二項関係に変換することについてのいくつかの論文を読んだ後、私は次の同等の関係を思いついた：

ここで2つの質問が発生します。

1. この変換は正しいですか？挿入を処理するには、アプリケーションレベルでチェックを追加する必要があることがわかりました。たとえば、新しい(User,Project)ものを追加する前に、ユーザーがプロジェクトと同じアカウントに属していることを確認する必要があります。

2. との関係を確立することは本当に必要AccountですUserか？Userとの関係Projectが追加されたら、プロジェクトにアクセスして、ユーザーが属しているアカウントを知ることができませんでしたか？

ありがとう！！

Answer 1

この変換は正しいですか？

「正しい」とは「同等」を意味する場合は、いいえ。

ユーザー（など）を接続せずにプロジェクトとアカウントを接続することを止めるものは何もありません。これは、実際の三項関係では不可能です。

アカウントとユーザーの関係を確立することは本当に必要ですか？...プロジェクトにアクセスして、ユーザーが属しているアカウントを知ることができませんでしたか？

実際には、どのアカウントがユーザーに接続するための「候補」であるかしかわかりませんが、1つを選択する良い方法はありません。

このスキームの本当の問題は、ユーザーのプロジェクトに関係のないアカウントにユーザーを接続できることです。

---

私の意見では、三項関係が必要な場合は、先に進んで物理モデルで直接表現してください。私があなたの要件を正しく理解している場合、これは次のようになります。

PKAccountIdの外側に注意してください。Collaborationつまり、すべてのプロジェクトとユーザーの組み合わせは、正確に1つのアカウントに接続する必要があります（別の組み合わせを別のアカウントに接続することもできます）。