幹軟體這一行這麼多年，發現好的程式設計師也更加的好學。

大學時代，舍友放過一個影片，對其中的六度理論印象很深刻。

*六度人脈關係理論（Six Degrees of Separation），是指地球上所有的人都可以通過六層以內的熟人鏈和
任何其他人聯絡起來。通俗地講：“你和任何一個陌生人之間所間隔的人不會超過六個，也就是說，最多通過六個人你就能夠認識任何一個陌生人。”*

我們很容易明白，六度理論的數學基礎是級數。m^n是一個很大的數字，幾乎能夠快速到達每一個人。
圖片來自網路

從中也可以看出，越是複雜的關係軟體系統的複雜度越高。這裡複雜度包括了資料庫關係、程式碼結構。因此前輩們才會整理出資料庫設計理論、設計模式理論等。而這其中 M:N（多對多）、1：M(一對多）、1:1(一對一）的複雜度是由高到低的。這裡說的多對多等就是今天要講的實體表之間的關係。

軟體開發在開始的時候，專案經理們喜歡用建築工程的理論來思考軟體系統。因此也衍生出瀑布開發模式，瀑布開發模式將系統開發分為可行性分析、概要設計、詳細設計等諸多階段，許多公司沒有嚴格參照這個流程設計開發系統，但是資料庫設計都會有一個設計稽核的過程。它屬於詳細設計的一個階段，這個時候系統的需求已經明晰（暫且不要提敏捷先生，他在另外一個房間喝茶，正在思索是否要邀請瀑布閣下過去呢）。

資料庫設計中一個重要的過程就是畫ER圖的過程，ER圖(Entity Relationship Diagram)即實體-聯絡圖，其中的E已經在前面說過，只要滿足第三正規化就可以了。而且中的R就是今天要探討的話題。

摘自網路

在上圖中，直角矩形代表實體，菱形代表關係。而圓角矩形代表的則是實體與關係的屬性。在實際設計過程中，一般先只畫直角矩形與菱形，在細化的過程中再畫上圓角矩形。也就是說先摸清枝幹，再抓葉子。

有一個規律性的小技巧，一般來說實體表示某一個相對固定的物件，比如講師、學生、課程，以及商品、訂單等。而關係則表示某一個活動或者隸屬關係，比如就職於、學習、教授等相對抽象的活動。

那麼怎樣判斷某對實體之間的關係屬於多對多、一對多、一對一呢？是這樣一個過程，想想一下：
A實體與B實體，在這個活動或者隸屬關係中，之間的位置關係數目。
如上圖中：

講師在教授活動中，一位講師教授幾門課程呢？答案是多門，因此這一方是1：M關係，那麼反過來一門課程由幾位講師教授呢？在此，答案是一位講師。因此是1：1的關係，那麼他們相互之間的關係就是1：M（一對多）。如果這裡，某些門課程難度很大，請了多位講師講解，這時第二個問題，答案就是多位講師，因此是1：N的關係，那麼這裡就會程式設計M：N（多對多的關係）。

同樣，學生學習課程的關係中。首先發問，一位學生學習幾門課程呢？答案是N門，因此是1：N關係。同時反過來一門課程被幾位同學學習呢？答案是多位同學。因此是1：M的關係，因此他們交叉後關係就是M:N（多對多）。如果這裡架設是古代的貴族私塾制度，一門課程只有一位學生，那麼上述第二個問題，答案就是一位同學學習，就變成了1：1關係，那麼交叉後就是1：N（一對多關係）了。

這裡，小結一下：

在某個活動中，A與B之間關係。假設A為主語地位，首先發問，在這個活動中A為主導時，一個A要操作幾個B呢？再發問如果B為主語地位，一個B被幾個A操作呢？
**上述答案畫一個表格：

那麼怎樣在資料表中用欄位表示這種關係呢？

如果是M:N關係，只能獨立一個關係表表示這種關係，並且這次活動中如果有額外屬性直接寫在關係中。

如圖中，學生學習課程這個活動中，用學習關係表來表示之間的M:N（多對多）關係，因為有成績這個額外屬性，因此在這裡放在學習這個關係表中：

這時候學習關係表的表結構如下：

如果是1：M活動關係：

如果這種關係恆定，並且沒有額外的活動屬性的，那麼將1端的Id可以放在M端表示這種關係。比如，某一個小學，這位老師打算一直在這裡從教，教授這些孩子們做人的道理。改變他們的命運，那麼課程與教師這種關係很穩定，而且大多數軟體系統比人類的壽命要短暫。那麼這裡可以在課程這裡加上教師的id表示這種教授活動關係：

如果課程所屬的教師經常變動，如經常性的教師離職等造成這種教授活動不恆定。這種情況下還是獨立一個關係表更加靈活些：

最後，如果是1：1關係，那麼可以在任意一段放置對方的id表示這種關係。

這個時候，上述的id都被稱為外來鍵。

值得一提的是，這些外來鍵經常被作為索引的候選欄位，後續課程中講解索引的時候會探討這個專題。

感謝您的耐心閱讀，今天是週末，出去走走吧。畢竟多走路，不僅對健康、事業有利，也能找到更加靠譜的物件呀，您說呢？