データベースの関係を設計するときにループを回避する必要があるのはなぜですか？
データモデルにループがあるのは悪い設計だと誰かが私に言った。私はこれを数回前に聞いたことがありますが、あまり注意を払っていませんでした。たとえば、エンティティUser、Project、Activityがあるとします。プロジェクトはユーザーが所有するため、ユーザーからプロジェクトへの1対多の関係があります。アクティビティは単一のユーザーに割り当てることができ、ユーザーからアクティビティへのもう1対多の関係です。もちろん、プロジェクトは一連のアクティビティ、つまりプロジェクトからアクティビティへの1対多の関係で定義されます。したがって、ループが形成されます。
私はこの男になぜデザインが悪いのかと尋ねましたが、彼はどちらも知らないと教えてくれました。
検索してみましたが、適切な言葉を使っていなかったようですが、DBを設計しようとしている人にとって、これは基本的なことのようです。
それで、誰かがer/dbダイアグラムのループ/サイクルに関するいくつかの有用な情報を私に示すことができますか、それらは避けられるべきですか？
この論文 の第3章で、関係ループの本当に良い扱いがあります。
ただし、一般に、ループに関する最も一般的な問題は、冗長な情報の一貫性です。
親が多くの子供を持っている場合（論文から）を考えてみましょう。各子供は学校に通っています。親と学校の間に3番目の関係があります（「親には学校に子供がいる」）。ただし、3番目の関係を明示的にモデル化する必要はありません。他の2つから完全に導出できます。明示的にキャプチャした場合は、ループが常に一貫していることを確認する必要があります。
したがって、その場合はループを回避する必要があります。ただし、ループは一般的に悪いわけではありません。上記の例をもう一度取り上げて、親が学校のガバナーであるケースをモデル化することを検討してください。それもループを作成します。この場合は有効ですが、他の2つの関係から「親は学校のガバナー」という関係を導き出すことはできません。
したがって、要約すると、ある関係が他の関係から完全に導き出せる場合はループをモデル化しないでください。ただし、ループが導出可能でない場合は、ループを作成しても問題ありません。
この論文をお勧めしますが、ここで説明するよりもはるかに優れた説明を提供します。
hth。