相關概念
關注上圖中的兩個部分：
概念結構設計
設計E-R圖，也即實體-聯系圖。
工作步驟：選擇局部應用、逐一設計分E-R圖、E-R圖合并。進行合并時，它們之間存在的沖突主要有以下3類：
- 屬性沖突。同一屬性可能會存在于不同的分E-R圖中。
- 命名沖突。相同意義的屬性，在不同的分E-R圖上有著不同的命名，或是名稱相同的屬性在不同的分E-R圖中代表著不同的意義。
- 結構沖突。同一實體在不同的分E-R圖中有不同的屬性，同一對象在某一分E-R圖中被抽象為實體而在另一分E-R圖中又被抽象為屬性。
邏輯結構設計
將E-R圖，轉換成關系模式。
工作步驟：確定數據模型、將E-R圖轉換成為指定的數據模型、確定完整性約束和確定用戶視圖。
實體：客觀存在并可相互區分的事物。
- 實體集：具有相同類型和共享相同屬性的實體的集合。如學生、課程。
- 弱實體和強實體：弱實體依賴于強實體的存在而存在。
屬性：實體所具有的特性。
- 屬性分類：簡單屬性和復合屬性；單值屬性和多值屬性；NULL屬性；派生屬性（可以通過其它屬性運算出來）
- 域：屬性的取值范圍稱為屬性的域。
- 碼（key）：唯一標識實體的屬性集。
聯系：實體內部的聯系和實體之間的聯系。
- 一對一（M：1)
- 一對多（1：N)?? ?如部門和員工
- 多對多（M：N)? ?如學生和所選課程
例題
某社區蔬菜團購網站，為規范商品收發流程，便于查詢客戶訂單情況，需要開發一個信息系統。請根據下述需求描述完成該系統的數據庫設計。
【需求分析結果】
(1)記錄蔬菜供應商的信息，包括供應商編號、地址和一個電話。(2)記錄社區團購點的信息，包括團購點編號、地址和一個電話。(3)記錄客戶信息，包括客戶姓名和一個電話。客戶可以在不同的社區團購點
下訂單，不直接與蔬菜供應商發生聯系。
(4)記錄客戶訂單信息，包括訂單編號、團購點編號、客戶電話、訂單內容和日期。
【概念模型設計】
根據需求階段收集的信息，設計的實體聯系圖(不完整)如圖 2-1 所示
【邏輯結構設計】
根據概念模型設計階段完成的實體聯系圖，得出如下關系模式(不完整)蔬菜供貨商(供貨商編號，地址，電話)
社區團購點(團購點編號，地址，電話)
供貨(供貨商編號，(a))
客戶(姓名，客戶電話)
訂單(訂單編號，團購點編號，訂單內容，日期，(b））、
【問題 1】(6 分)
根據問題描述，補充圖 2-1 的實體聯系圖。
【問題 2】(4 分)
補充邏輯結構設計結果中的(a)、（b）兩處空缺及完整性約束關系。
【問題 3】(5 分)
若社區蔬菜團購網站還兼有代收快遞的業務，請增加新的“快遞”實體，并給出客戶實體和快遞實體之間的“收取聯系。“快遞”關系模式包括快遞編號、客戶電論和日期。客戶電話和日期。聯系，對圖 2-1 進行補充。
解析：
（1）由需求分析（3）客戶與社區團購點為多對多的關系。另外，要對訂單添加兩個屬性“訂單內容”和“日期”。多對多的關系模式，應該有另外兩張主表作為外鍵，即客戶表和社區團購點，“團購點編號”和“客戶電話”應該直接作為關系模式帶進來，而不是訂單自己擁有的屬性。
（2）（a）：供貨應該有蔬菜供應商和社區團購點的主鍵作為外鍵。現在已經有了前者的供貨商編號，還需要社區團購點的主鍵，即團購點編號。主鍵：（供貨商編號、團購點編號）（b）客戶電話。
（3）
2. 某汽車維修公司為了便于管理車輛的維修情況，擬開發一套汽車維修管理系統，請根據下述需求描述完成該系統的數據庫設計。
【需求分析結果】
（1）客戶信息包括：客戶名、客戶性質、折扣率、聯系人、客戶號聯系電話。客戶性質有個人或單位。客戶號唯一標識客戶關系中的每一個元組。
（2）車輛信息包括:車牌號、車型、產一個客戶至少顏色和車輛類別。有一輛車，一輛車只屬于一個客戶,
（3）員工信息包括:賢工號、員工名、崗位電話、家庭住址。其中員工號唯一標識員工關系中的每一個元組。崗位有業務員、維修工主管。業務員根據車輛的故障情況填寫維修單。
（4）部門信息包括:部門號、名稱、主管和電話。其中，部門號唯一確定部門關系的每一個元組。每個部門只有一名主管，但每個部門有多名員工，每名員工只屬于一個部門。
（5）維修單信息包括:維修單號、車牌號、維修內容、工時。其中維修單號唯一標識維修單關系中的每一個元組。一個維修工可以接多張維修單，但一張維修單只對應一個維修工。
【概念模型設計】
根據需求階段收集的信息，設計的實體聯系圖(不完整)如圖 2-1 所示：
【邏輯結構設計】
根據概念模型設計階段完成的實體聯系圖，得出如下關系模式(不完整)客戶(客戶號，客戶名，（a），折扣率，聯系人，聯系電話)
車輛(車牌號，(b)，車型，顏色，車輛類別)
員工(員工號，員工名，崗位，(c)，電話，家庭住址)
部門(部門號，名稱，主管，電話)
維修單(維修單號(d，)維修內容，工時)
【問題 1】(6 分)
根據問題描述，補充3個聯系，完善圖 2-1的實體聯系圖。聯系名可以用聯系 1、聯系2 和聯系3代替，聯系的類型為 1:1、1:n 和 m:n(或 1:1、1:*和*:*)
【問題 2】(4 分)
根據題意，將關系模式中的空(a)、(d)的屬性補充完整，并填入答題紙對應的位置上
【問題 3】(2 分)
分別給出車輛關系和維修單關系的主鍵和外鍵。
【問題 4】(3 分)
如果一張維修單涉及多項維修內容，需要多個維修工來處理，那么這個聯系類型會發生何種變化?你認為應該如何解決這一問題?
解析：
回答1：補充車輛與客戶的聯系，部門與員工的聯系，維修單與維修工的聯系
回答2：（a）為客戶性質；（b）車輛信息的屬性都在邏輯結構模型中，再填一個，代表天的是外鍵。車輛和客戶是多對一的聯系，再多對一的關系中，多有一的主鍵作為外鍵，因此(b)為客戶表中的主鍵，即客戶號。（c)：應填外鍵，擁有部門號的主鍵作為外鍵，因此（c）為部門號。（d）：車牌號。維修單與維修工有關系，作為“多”，應有維修工的主鍵作為外鍵，維修工為員工的弱實體，因此還應有維修工員工號。維修單與業務員也是多對一的關系，因此也應該擁有業務員的員工號。
回答3：車輛關系的主鍵是車牌號，外鍵為客戶號。維修單關系中的主鍵那為維修單號，外鍵為維修工和業務員的員工工號。
回答4：將維修單和維修工的關系由多對一改為多對多。那么維修單不需要把維修工的主鍵作為外鍵。新的關系模型有自己的主鍵、以及維修單和維修工的編號。
