概念數據建模：如何讀取多對多的遞歸關係

Question

我知道像下面這樣簡單的二元關係會從左到右讀取：用戶「可能」有一個或多個圖片。此外，如果您從右向左閱讀，則會是......圖像「必須」屬於一個且只有一個用戶。

但是，當我看到以下內容時，我有點困惑。有誰能告訴我你是如何閱讀這種關係的？另外，在右下方的圖片中，他們說的是相同的東西嗎？

終於，在這個遞歸關係，其中一個用戶可以是另一個用戶的好友是否有意義的是兩端被指定爲一個可選的多，還是一個應該是必須的，很多？

我看到的方式是，如果用戶可以有零個或多個朋友而不是另一端，則應該有一個或多個朋友，因爲如果用戶A是用戶B的朋友，則用戶B不再有選項零的朋友。這個假設是正確的還是我錯了？

任何想法都會幫助我閱讀一本關於概念數據建模的書，並且在我繼續並在實際表上進行練習之前，真的很想理解這一點。

Answer 1

是的，這兩個圖表顯示了同樣的事情。

有些人選擇留下概念圖中未解決的多對多關係。一些描述這種關係的文字可能會有所幫助（我建議像「是朋友一樣」）。然後，我會將其讀爲「用戶可能與其他用戶成爲朋友」。

第二個圖表顯示瞭如果您決定解決多對多關係時要繪製的內容。有些人直到邏輯建模時纔會這樣做，當你閱讀它的時候你會遇到同樣的結構（在學習了概念建模之後，我會推薦它作爲下一步）。我會閱讀用戶和友誼之間的關係，就像「用戶可能有友誼」。

這些關係總是可選的，因爲您正在對整個圖片進行建模，而不是一個特定的實例。在右邊顯示它是非可選的，就是說每個用戶必須在的數據庫中的友誼表的第二列至少有一個條目，你最終通過這個模型創建 - 這是不正確的。順便說一下，我認爲你真的很高興看到這篇文章（太多的人建立數據庫而沒有嘗試去掌握概念或邏輯建模！）。儘管如此，在你嘗試瞭解你正在學習的東西之前，我並不擔心等到你覺得你已經完全理解了它;一旦你將這些想法付諸實踐，那麼一些想法可能會更有意義。如果你還沒有學習，可以嘗試在學習的同時根據自己的數據繪製概念圖。

Answer 2

這裏有很多東西需要解壓。喬·道格拉斯的回答涵蓋了很多理由。

我相信你的一部分困惑來自人們用ER圖來描繪兩種截然不同的模型。首先是實體關係模型，更好地稱爲ER模型。其次是關係模型。表面上看，這兩個模型看起來幾乎完全相同。但是它們有不同的特徵，它們是爲不同的目的而建造的。

ER模型可以促進數據庫設計人員和主題專家之間的溝通。主題專家可能對數據有深刻的理解：它看起來像什麼，它的含義，爲什麼它很重要，以及如何使用它。同一主題專家可能對外鍵，參照完整性或數據標準化等技術主題很少或根本沒有興趣。

關係模型對於想要在流行的SQL數據庫之一（如SQL Server，Oracle或其他許多數據庫）中設計和構建數據庫的設計師來說是一個很好的初步結果。

你最後的圖表，只有標有User的框，非常簡潔明瞭。它突出了這種關係的多對多性質。它在ER模型中是完全有效的，但關係建模者會告訴你它不合法，並且需要接線盒。

它的確如此，但缺乏關係的名稱，即友誼。如果您可能有兩個相同的關係，則命名關係非常有用。它還爲您提供一個名稱來掛起屬性。在某些情況下，你可能會對特定友誼開始的日期感興趣。

關係是強制還是可選取決於您是在分析主題還是設計解決方案。如果這是第一個，那麼你會看看這個主題，看看它是否是強制性的。這裏的技術專家無法回答你的問題，因爲我們不知道你的主題，即使我們認爲我們這樣做。

如果您正在設計解決方案，您可能需要從不同的角度來看待它。你是否過度約束數據？你受不約束？

我希望這解決了一些你正在摔跤。數據庫設計並不複雜。但它是抽象的。