web-dev-qa-db-ja.com

bad循環依存の定義は何ですか？

循環依存関係がよく説明されている優れたリソースを探している間、残念ながら優れたリソースは見つかりませんでした。したがって、回避すべき循環依存の種類を正確に理解しようとしました。問題は、矛盾する方法で説明するリソースを見つけたことです。誰かがどのタイプの循環依存関係を避けるべきかを正確に説明できますか？

これらの関係を例にとると：

enter image description here

ソース

この関係は、ここではbadと記載されています（理由はわかりません）。

ただし、同じ関係が問題ではない（そして[〜＃〜] not [〜＃〜]循環）ここに：

Models <--------------------------- SuperSets
   ^                                    ^
   |                                    |
   |                                    |
Tasks  <---------------------------- Sets

ソース

別の例はこれです：

enter image description here

ソース

また、なぜこれが循環関係にあるのかわかりません。

以前の関係はすべて、曲線的ではないように見えます（矢印の方向が同じ点に戻ることはありません）。循環従属項の理解に問題があると思います。誰かが私に一般的に、特に前の例についても説明してくれませんか？

database-designrelations
3
Mohammed Noureldin

これらのケースのいずれにも循環はありません。 「循環参照」シナリオでは、「鶏と卵の問題」があります。次のように、他のテーブルへの参照が常に欠落しているため、テーブルに行を挿入できません。

 user {user_id、address_id、...} 
 PK {user_id} 
 
 FOREIGN KEY {address_id} REFERENCES address 
 
-
-
 address {address_id、user_id、...} 
 PK {address_id} 
 
 FOREIGN KEY {user_id}リファレンスユーザー

その記事の作成者が抱えている唯一の問題は、データベースの設計を理解していないことです。彼の例の問題は、単一列のPK（ID）に対する主張から生じた単純な設計であり、ビジネスロジックがDB制約にどのように関連しているかを理解していません。

2番目の例では、彼のデザインは、実際の購入ではなく、ユーザーと製品に基づいてリセラーのコミッションを割り当てます。最初の例では、プロジェクトスコープ外のタスクにユーザーを割り当てることができます。ここでも「循環」とは関係ありませんが、制約の実装方法がわかりません。

2番目の例では、次のようなものを検討します。

製品{ProductID} 
 PK {ProductID} 
 
 Customer {CustomerID} 
 PK {CustomerID} 
 
 Reseller {ResellerID} 
 PK {ResellerID} 
 
-
-
 Purchase {PurchaseID、CustomerID、ProductID、ResellerID、.. 。} 
 PK {PurchaseID} 
 
 FOREIGN KEY {CustomerID} REFERENCES Customer 
 FOREIGN KEY {ProductID} REFERENCES Product 
 FOREIGN KEY {ResellerID}リファレンスリセラー

また、Commissionテーブルを主張する場合は、すべての購入にリセラーが含まれるとは限らないことを伝えます。

製品{ProductID} 
 PK {ProductID} 
 
 Customer {CustomerID} 
 PK {CustomerID} 
 
 Reseller {ResellerID} 
 PK {ResellerID} 
 
-
-
 Purchase {PurchaseID、CustomerID、Product_ID、...} 
 PK {PurchaseID} 
 
 FOREIGN KEY {CustomerID} REFERENCES Customer 
 FOREIGN KEY {ProductID} REFERENCES Product 
 
 
-
-
 Commission {PurchaseID、ResellerID、...} 
 PK {PurchaseID} 
 
 FOREIGN KEY {PurchaseID } REFERENCES Purchase 
 FOREIGN KEY {ResellerID} REFERENCES Reseller

そして最初の例では：

プロジェクト{ProjectID、...} 
 PK {ProjectID} 
 
ユーザー{UserID、...} 
 PK {UserID} 
 
 TaskType {TypeID、...} 
 PK {TypeID} 
 
 ProjectRole {RoleID、...} 
 PK {RoleID} 
 
-
-
 Task {TaskID、ProjectID、TypeID、...} 
 PK {TaskID} 
 AK {TaskID、ProjectID} 
 
 FOREIGN KEY {ProjectID} REFERENCES Project 
 FOREIGN KEY {TypeID} REFERENCES TaskType 
 
- 
-
 ProjectTeam {UserID、ProjectID、RoleID、...} 
 PK {UserID、ProjectID} 
 
 FOREIGN KEY {UserID} REFERENCESユーザー
 FOREIGN KEY {ProjectID} REFERENCESプロジェクト
 FOREIGN KEY {RoleID} REFERENCES ProjectRole 
 
-
-
 ProjectAssignment {UserID、ProjectID、TaskID、...} 
 PK {UserID、ProjectID、TaskID} 
 
 FOREIGN KEY {UserID、ProjectID} REFERENCES ProjectTeam 
 FOREIGN KEY {TaskID、Pro jectID} REFERENCESタスク

単一列PKsを使用する場合は、それらをProjectAssignmentおよびProjectTeamテーブルに追加できますが、既存のものをAKsとして保持する必要があります（一意）そして、該当する場合は外部キーでそれらを参照します。

注PK =主キー
 AK =代替キー（一意）
すべての属性（列）NOT NULL
4
Damir Sudarevic