データモデルにループを入れるのは悪い設計だと誰かが私に言いました。私はこれを数回前に聞いたことがありますが、あまり注意を払いませんでした。たとえば、ユーザー、プロジェクト、アクティビティなどのエンティティがあります。プロジェクトはユーザーが所有するため、ユーザーからプロジェクトへは 1 対多の関係があります。アクティビティは、ユーザーからアクティビティへの別の 1 対多の関係である、1 人のユーザーに割り当てることができます。もちろん、プロジェクトは一連の活動によって定義されます。これは、プロジェクトから活動へのもう 1 つの一対多の関係です。このようにループが形成されます。
私はこの男になぜ悪いデザインなのか尋ねましたが、彼はどちらも知らないと言いました。彼もそう言われました。
検索してみましたが、適切な言葉を使用していなかったようですが、これはDBを設計しようとしている人にとって基本的なことのように思えます。
では、er/db ダイアグラムのループ/サイクルに関する有用な情報を誰かに教えてもらえますか?
このホワイト ペーパー( archive.org )の第 3 章に、リレーションシップ ループの非常に優れた処理があります。
ただし、一般に、ループに関する最も一般的な問題は、冗長情報の一貫性です。
親が多くの子供を持っている場合を（紙から）考えてみましょう。各子供は学校に通っています。親と学校の間には 3 番目の関係があります (「親は学校に子供を持っています」)。ただし、3 番目の関係を明示的にモデル化する必要はありません。それは他の2つから完全に派生可能です。明示的にキャプチャした場合は、ループが常に一貫していることを確認する必要があります。
その場合、ループを避けたいと思うでしょう。ただし、ループは普遍的に悪いわけではありません。上記の例をもう一度取り上げて、親が学校の知事である場合をモデル化することを検討してください。これもループを作成します。この場合は有効ですが、「親が学校の知事である」という関係を他の 2 つの関係から導き出すことはできません。
要約すると、1 つの関係が他の関係を組み合わせて完全に導出できる場合は、ループをモデル化しないでください。ただし、導出できない場合は、ループを作成してもかまいません。
ただし、紙をお勧めします。ここで説明できるよりもはるかに優れた説明を提供します。