データモデルにループがあるのは悪い設計だと誰かが言っていました。私はこれを何度か聞いたことがありましたが、あまり気にしていませんでした。たとえば、User、Project、Activity というエンティティがあるとします。プロジェクトは User が所有しているため、User から Project への 1 対多の関係があります。アクティビティは単一の User に割り当てることができ、User から Activity への別の 1 対多の関係があります。もちろん、プロジェクトは一連のアクティビティによって定義され、Project から Activity への別の 1 対多の関係があります。このようにして、ループが形成されます。
私はこの人に、なぜそれが悪いデザインなのか尋ねましたが、彼も知らない、彼もそう言われた、まさに猿の学習そのものだと言いました。
検索してみましたが、適切な言葉を使っていなかったようです。しかし、これは DB を設計しようとする人にとっては基本的なことであるように思えます。
では、ER/DB 図のループ/サイクルは避けるべきなのか、それに関する役立つ情報を教えていただけませんか?
ベストアンサー1
第3章では、人間関係のループについて非常によく説明されています。この紙（アーカイブ）。
ただし、一般的に、ループに関する最も一般的な問題は、冗長な情報の一貫性です。
親に多くの子供がいて、それぞれの子供が学校に通っているケース（論文より）を考えてみましょう。親と学校の間には 3 番目の関係があります（「親には学校に通う子供がいる」）。ただし、3 番目の関係を明示的にモデル化する必要はありません。これは他の 2 つの関係から完全に派生可能です。明示的にキャプチャする場合は、ループが常に一貫していることを確認する必要があります。
したがって、その場合はループを避ける必要があります。ただし、ループは必ずしも悪いわけではありません。上記の例をもう一度取り上げて、親が学校の理事である場合をモデル化することを検討してください。これもループを作成します。ただし、この場合は有効です。他の 2 つの関係から「親が学校の理事である」関係を導き出すことはできません。
まとめると、1 つの関係が他の関係の組み合わせから完全に導出可能な場合は、ループをモデル化しないでください。ただし、導出不可能な場合はループを作成しても問題ありません。
ただし、この論文をお勧めします。ここで私が説明するよりもはるかに優れた説明が書かれています。