前言
ER建模環節完成後，需求就被描述成了ER圖。之後，便可根據這個ER圖設計相應的關係表了。
但從ER圖到具體關係表的建立還需要經過兩個步驟：1. 邏輯模型設計 2. 物理模型設計。其中前者將ER圖對映為邏輯意義上的關係表，後者則對映為物理意義上的關係表。邏輯意義上的關係表可以理解為單純意義上的關係表，它不涉及到表中欄位資料型別，索引資訊，觸發器等等細節資訊。
本文將詳細介紹前者。確切來說，也就是ER模型到邏輯關係表的對映是如何完成的。
基本概念
在開始進行ER模型到邏輯關係表的具體對映之前，首先來學習一下邏輯模型中所涉及到的一些概念。
1. 關係(relation)
關係就是在資料庫中存在的，包含行和列的一張表。也常被稱為關係表，或者表。注意只有在確保不會引起混亂的時候使用最後一種稱呼，因為關係表和一般意義上的表有很大區別(下文會分析)。
2. 列(column)
列就是字面意義上表的列。但是它也有時被稱作屬性，或者域。
3. 行(row)
行就是字面意義上表的行。但是它也有時被稱作元祖，或者記錄。
4. 關係表 VS 一般的表
關係表有以下幾個基本約束：
a. 一個列只能有一個名稱；
b. 不能出現完全一樣的行；
c. 表中每個值都必須為單值；
d. 同一列中的所有值都必須屬於同一個域；
e. 行/列順序無關
5. 主碼(primary key)
每個關係必須要有一個主碼(可含多列)，用來唯一標識表中各行記錄。
6. 實體完整性約束(entity integrity constraint)
指所有主碼必須非空。
6. 外碼(foreign key)
外碼是某關係中的一列，而這一列恰恰又是另一個關係的主碼。
7. 參照完整性約束(reference integrity constraints)
外碼取值要麼為空，要麼為其參照關係中的主碼取值。
ER模型到關係表的對映
1. 將常規實體對映為關係
對常規實體來說，每個常規屬性對應到關係表中的一列，而某單值且唯一的列則對映為主碼，標記下劃線。
如下實體：
將對映為關係：
2. 將具有複合屬性的實體對映為關係
這類對映中，複合屬性的各子屬性會對映到的新的關係中，但是複合屬性名本身不會。
如下實體：
將對映為關係：
雖然關係中沒有出現符合屬性名了，但資料庫上層的前端應用可能會利用到複合屬性名。也就是ER圖在各個階段都有可能用到，不是說對映為關係後就沒啥事了。
3. 將具有唯一複合屬性的實體對映為關係
這類對映中，將會形成一個複合主碼，其成員為複合屬性的各子屬性。
如下實體：
將對映為關係：
4. 將具有可選屬性的實體對映為關係
這類對映中，需要將可選屬性對應的列標記一個(O)。
如下實體：
將對映為關係：
5. 一對多(1：M)聯絡的對映
這類對映的規則為：在由1：M聯絡中屬於M側的實體所對映得到的關係中設定一個外碼，這個外碼對應於由1側的實體對映得到的關係中的主碼。
如下ER模型：
將對映為關係：
注意，外碼命名不一定要和它對應的主碼一致，應根據實際情況決定。
6. 多對多(M：N)聯絡對映
這類對映的規則為：除了具有多對多聯絡的兩個實體之外，聯絡本身也需要對映為關係。聯絡對應的關係中將有兩個外碼，分別對應兩個實體的主碼，同時這兩個外碼構成新關係的主碼。
比如下面這個ER模型：
將對映為關係：
7. 一對一(1：1)聯絡的對映
這類對映和1：M的很相似。原則上外來鍵設在任何一個實體的關係中都OK，但如果一對一聯絡中的基數約束是強制單個和可選單個這種型別，則最好將外來鍵設定在可選多的一側。因為這樣可以保證關係中不會出現太多空值。
比如下面這個ER模型：
將對映為關係：
8. 將具有若干候選碼的實體對映為關係
這類對映中，主碼依然標記劃線，而非主碼唯一屬性則標記(U)。
如下實體：
將對映為關係：
9. 將具有多值屬性的實體對映為關係
這類對映中，需要為多值屬性建立一個新的關係。新的關係中包含一個外碼，對應到主實體的主碼。同時屬性值和外碼構成新的關係的複合主碼。
如下實體：
將對映為關係：
10. 將具有派生屬性的實體對映為關係
派生屬性不需要做什麼特別處理，那是前端的事情，哈哈。
11. 一對多(1：M)一元聯絡的對映
這類對映的規則為：實體對映得到的關係中包含一個外碼，對應到關係自身的主碼。
如下ER模型：
將對映為關係：
需要注意的是，該對映中外來鍵名和主鍵名是不同的，以區分它和主碼。事實上關係中也不允許出現名稱相同的兩列。
12. 多對多(M：N)一元聯絡的對映
這類對映的規則為：除了實體本身需要對映為關係之外，多對多聯絡需要對映為另一個關係。新的關係中將有兩個外碼，它們均對應到實體主碼。且這兩個外碼又組合為新關係的複合主碼。
如下ER模型：
將對映為關係：
這裡同樣要注意外來鍵名要避免和主鍵名重複。
13. 一對一(1：1)一元聯絡的對映
和上面第11條講的一對多的一元聯絡對映規則完全相同，此處不再舉例說明。
14. 將弱實體對映為關係
弱實體對映和常規一對多聯絡對映一樣需要在弱實體(M側實體)中建立一個對應到屬主實體(1側實體)的外碼。然而區別是弱實體中的主碼是弱實體自身的部分碼+外碼構成的複合主碼，而後者的主碼僅是M側實體自己的主碼。
如下ER模型：
將對映為關係：
當然，如果聯絡是一對一，則弱實體的主碼就是那個對應到其屬主實體的外碼而沒有部分碼了。
如下ER模型：
將對映為關係：
15. 將關聯實體對映為關係
關聯實體本身就是聯絡，因此它的對映規則和聯絡是一樣的。聯絡的對映在前文已經完成講解，此處不再累述了。
16. 三元聯絡的對映
這類對映和多對多聯絡的對映比較相似。如下ER模型：
可對映為：
這裡提示下，三元聯絡的情況，聯絡肯定是多對多對多的。因為如果這三元中有一個為一，那麼三元聯絡就應轉成兩個二元的一對多聯絡。
概念模型 VS 邏輯模型
想必有不少人還不大清楚概念模型，邏輯模型，物理模型的區別。這裡先來探討下概念模型和邏輯模型，有關物理模型的討論則將放到第四篇。
我們首先可以認為概念模型建模和ER建模，需求視覺化表達的是一個意思。在這個環節中，資料開發人員繪製ER圖，並和專案各方人員協同需求，達成一致。由於這部分的工作涉及到的人員開發能力比較薄弱，甚至不懂開發，因此ER圖必須清晰明瞭，不能涉及到過多的技術細節。在ER圖繪製完畢之後，才開始將它對映為關係表。這個對映的過程，就叫做邏輯模型建模或者關係建模。
有人會說，ER圖不是可以直接對映到關係嗎，而且已經有了相應的對映工具了，為什麼還要繪製ER圖多此一舉呢？針對這個問題前文已經回答了。ER圖是拿出去和別人談需求的，要求各方人員都能看得懂。而關係表設計到了過多實現細節，比如：要給多對多聯絡/多值屬性等多建一張表，要設定外碼，各種複合主碼等。這些東西不應該在談需求的時候出現，它們應當對非開發人員透明。而且ER圖中每個屬性只會出現一次，減少了蘊含的資訊量，是更好的交流和文件化工具。
還有，ER模型所蘊含的資訊，也沒有全部被邏輯模型包含。比如聯絡的自定義基數約束，比如實體的複合屬性，派生屬性，使用者的自定義約束等等。因此ER模型在整個開發流程(如物理模型建模，甚至前端開發)中是都會用到的，不能認為ER模型轉換到邏輯模型後就可以扔一邊了。
小結
本文的邏輯關係表都是利用建模工具直接由ER圖生成的。這確實很方便，但那些系統自動增加的欄位和表的命名則需要根據實際情況進行調整。
邏輯模型設計好後，就可以開始著手資料庫的物理實現了。資料庫的物理實現也被稱為物理模型建模，這個階段不但需要參照邏輯模型，還應當參照ER圖。