2.2 個體關聯模型概念

開發資訊系統把資料建構在資料庫時，為什麼需要先建立模型。不就是看系統需要用到什麼欄位，直接開立資料表在資料庫中不就好了。當然是可以，反正系統能動就好了。問題在於，系統需要更新，開發人員會異動，往往這時候就需要經驗傳承，否則就是「打掉重練」。
建模的目的是希望透過圖形化的呈現方式，表達系統內部所存在的元素，以及相互之間的互動關係。藉由模型化的技術作為系統需求者與系統發展者之間的溝通工具。也可以利用建模技術背後影響的理論邏輯，使的系統發展能夠比較正確。有句諺語說「圖勝於文」，就是這道理。

抽象過程

利用資訊科技來取代實體的業務流程，其實是一項困難工程。因為兩者的思維是不盡相同的，他是實體─抽象─實體切換的抽象過程。 在真實世界裡，企業每天，甚至每分每秒都有業務在進行。未電腦化前，當然是以手工表單為作業模式。隨著業務繁重或作業流程遭遇瓶頸，企業主大都期望透過電腦化來改善業務流程。電腦化的問題核心，就是如何從實際紙本作業流程，轉變到由人操作電腦完成作業流程。此過程就是一個從真實世界轉化到電腦世界的過程。從資訊發展的產出角度來說，過程中間產出的有「需求書」、「規格書」、「程式碼」。
其實，電腦並不如大家所想像這麼聰明，因為電腦只懂"0"與"1"。是聰明的人類，在0與1之上，又定義了機械碼、組合語言、程式語言、應用程式等等，一層又一層的包裝電腦笨拙的樣子，使人類能夠很容易的操作電腦。但是，畢竟真實世界的流程與電腦世界裡的流程思考邏輯是太一樣的。要如何轉換呢，就是靠抽象過程，這個過程也就是模型化的過程。另一種說法是切割成Logical view與Physical View這兩個觀點。Logical view 強調的是人看得懂的；Physical view則是讓電腦看得懂。
眾所皆知，蓋一棟大樓絕對需要藍圖；生產一個產品也是需要產品設計圖。相對地，發展一套資訊系統仍然需要藍圖。不管藍圖還是設計圖，都是遵循業界標準規範所設計，並抽象後的結果。有了這些藍圖與設計圖，可以讓實際的製造過程降低風險，避免不必要的浪費。有了藍圖，就可勾勒出產品樣子，拿此設計圖與使用者溝通，總要比用比手劃腳的方式來得精準多了。更重要的是，在溝通過程，若有任何需求的變動，只要改改藍圖就好，不需要把成品報廢掉重新製造，這樣子可以省去很多成本。
發展資訊系統所需要的藍圖，廣為所知的是UML分析技術，他是以物件導向為目標的方法論。若從分析技術發展的角度，大致可以分成三大主流。

• 結構化分析與設計(Structured systems analysis and design)
• 資訊工程(Information engineering, IE)
• 物件導向分析與設計(Object-oriented analysis and design, OOAD)

結構化分析與設計強調的是以流程(Process)角度，把實體的問題抽象出來。資訊工程則強調以資料(Data)角度，把實體的問題抽象出來。至於物件導向分析與設計則是把流程與資料合併起來視作一個物件概念，把實體世界的元素抽離出來。本書強調的是關聯式資料庫，是強調資料庫的實做，所以會鎖定在資訊工程的技術與方法。

何謂ER Model

ER Model的英文全名為Entity-Relational Model。他從資料角度看真實世界，把存在真實世界裡，我們所關心的事實予以抽象出來，並以圖形表示之。更重要的是，他可作為後續對應到資料庫的實作部分。根據圖形的畫法不同，又可以分成IDEF1X與Martin兩種。其實其理論是一樣的，只是圖形不同而已。
Entity其實就是指資料庫裡的資料表，但是從資訊系統發展之初，是不考慮資料庫的種類。所以，建構ER-Model時，可分成Logical view與Physical view兩階段。

• Logical view強調的是從真實世界裡的觀點來看會有哪些個體存在，也就是人所能理解的方式來描述資訊系統會有哪些我們所關心的事實。
• Physical view就會因為採用不同廠牌的資料庫系統而改變。因為，不同廠商的資料庫系統會使用到不同的資料型態定義。

現階段，未觸碰到選用何種資料庫系統的問題。所以，都是以Logical View為敘述重點。 ER-Model包含有幾個重要成員：

• ER-Diagram：以圖形方式表達個體以及個體間的關聯。
• Domain Dictionary：描述與限定此系統可能包含的資料類型。
• Entity Report：描述個體的定義與說明。
• Attribute Report：描述個體之屬性說明。

本書著重在ER-Diagram的建立，其他的部分就不予討論。

定義ER Diagram

使用方形圖示來代表個體，方形上方為此個體名稱。方形內所列的內容，是此個體所能攜帶的屬性。方形內部分成上下兩部分，上半部是指主鍵值，下半部指的是一般的屬性。個體跟個體之間若有關聯，則有線連接，這部分會在後面章節中再詳細說明。下圖是範例。

上一章提到，能夠辨識出不同個體之屬性，稱之為鍵值，且會選擇一個當作主鍵值(PK)。當有關聯發生時，一定是兩個個體的某個屬性值內容相同，才能夠辨識出彼此具有關聯性。如果這個屬性在某個體已經被拿來當作主鍵值時，則另一個個體則為此屬性，給一個特別名稱「外來鍵」(Foreign Key, FK)。在上圖中，"公司代碼"作為連接「公司」與「客戶」的屬性，表示客戶可能會來自同一家公司。因為"公司代碼"在「公司」已為主鍵值了，在「客戶」就是外來鍵了。

尋找個體與關聯

大致知道ED Diagram的畫法時，接著的問題是如何知道資訊系統內會有哪些個體，要如何找出個體，以及個體與個體之間的關係。這是本節重點。

找尋個體

資訊系統裡的可能存在的個體非常多，很多情況並不容易馬上感受他的存在。除非知識領域(Knowledge Domain)非常熟悉才有可能得心應手。例如，要開發進銷存系統，則對企業流程要熟悉；要開發選課系統，則對學校的選課流程要瞭解；要開發基金下單系統，也必須到基金的作業流程知識要清楚。這部份無法一概而論，本節僅能提供一些思考方向，還是需要配合知識領域，才能夠設計出正確的藍圖(ER Diagram)。

(1) 思考方向

設計資訊系統仍是解決實體社會中所發生的問題與需求。所以，抽象過程，還是可以從實體社會中找尋。下列是幾個方向提供參考。

• 人(Persons):
  -「人物」這類的個體是資訊系統中最常出現的。是具有操作系統能力者。
  -常見者有：代理商、合約人、客戶、部門、員工、主管、學生、供應商。
• 地(Places):
  -「地點」類的的個體一般是以參考用途為主。
  -常見者有：銷售區域、建築物、辦公室、分公司、學校、教室、倉庫。
• 物(Objects):
  -「物件」也是資訊系統中最常出現的，而且數量最多。是被管理的對象。
  -常見者有：書、機器、零件、產品、原料、軟體、工具、交通工具。
• 事(Events):
  -「事件」類主要思考方向是企業流程中有關交易的部分。
  -常見者有：申請表格、獎勵、飛行記錄表、發票、採購單、註冊單、銷售表、需求書。
• 觀念(Concepts):
  -「觀念」類與「事件」類的個體有點類似，但是主要差別是，「事件」類的個體能夠看得到實體的東西。而「觀念」類的就偏一種約定成俗的名詞。
  -常見者有：帳戶、債券、課程、基金、股票、授權。

(2) 個體相聚性

以功能面來看，個體間隱約存在某種關聯性，可劃分出一些群組出來。以下圖為例，「老師」、「學生」與「課程」內聚效果強，大致可以猜說這是有關選課資訊系統會存在的個體。而「醫院」、「病床」、「醫生」與「病人」就會是醫院管理資訊系統會存在的個體。相同的，「客戶」、「供應商」、「產品」、「出貨單」與「進貨單」就偏向進銷存系統會存在的個體。這只是概略性的分類，基於業務規範(Business Rule)，兩個個體間會有關聯存在，這也是關聯式資料庫的特性。

確認關聯

個體間應該要存在某種關聯性，這是關聯是資料庫的特性，否則，就會變成像是EXCEL的工作表。要如何找出關聯性呢？先來認識會有哪幾種關聯性。

(1) 關聯模型

個體間所存在的關係可以分成四種類型。如下表。

項目	圖形	說明
A		任何一個A只能找到唯一的B
B		任何一個A可以找到多個B
C		任何一個A可能找到零個或者一個B
D		任何一個A可能找到零個或多個B

上表只看B這邊的關聯類型，若把A的變化也納入考慮，就可以變化出很多種組合。雖然有許多種組合，一般簡化成一對一(One-to-One)，一對多(One-to-Many)與多對多( Many-to-Many)這三種關係。

(2) 確認關聯

現在就利用下圖，所謂醫院管理系統關聯圖（非完整正式）來解釋病床、病人、醫生與醫院的關係。剛好符合上述三種關係。

針對醫院管理系統所作的初步分析。首先找到了幾個所關心的個體，再根據業務規範(Business rule)來設定彼此的關係。接著來檢驗這些關聯是否符合實際情形。

病人與病床關聯性

首先檢驗「病人」與「病床」的關聯性。一個病人只能分配到一張病床，而一張病床在某一時間內，也只能分配給一個病人，這樣的關係就是「一對一」。無論是，同一個病人躺在兩張床上，或者是一張病床上躺了兩個人，都算是不合理的事情。所以病人與病床之間是「一對一」的關係是合理，可被接受。
在實做資訊系統時，對於「一對一」的關係要特別注意。基本上，真正到資料庫的設計時，「一對一」只是「一對多」的一種特例。有時常用欄位與不常用的欄位，或者目的不同的欄位予以切割成不同資料表方便管理。

病人與醫院關聯性

接著看「病人」和「醫院」的關係。在某一時間點上，一個病人只能住在一家醫院裡面，但同一時間，一家醫院可以住有零個、一個或多個病人，是「一對多」的關係。
「一對多」的關係，正是資訊系統要追求的關聯模型。也就是說，對電腦而言，這種關係才是正常關係。我們可以從兩個角度來向這個關聯模型問問題，若從病人的個體下手，可以問某病人住哪間醫院。因為，從病人對到醫院是一對一的關係。所以，只要給定病人資料，就可以找到此病人住哪家醫院。若從醫院著手，可以問這家醫院住了哪些病人。因為，從醫院到病人是一對多的關係，所以，給定醫院，可以找到零筆、一筆或者多筆病人資料。

病人與醫師關聯性

再來看「病人」和「醫生」的關係。我們知道一個醫生可以照顧很多個病人，而一個病人可以有多個醫生來照顧，例如會診。所以，這兩者就屬於「多對多」的關係了。
多對多的關係在logical view是可以存在的，但在Physical View卻無法存在，因為無法透過指令找到確切的資料。 無論是多對多還是其他的關聯模式，若設計完直接就到資料庫系統建立資料表，常會出現一些可怕的問題。例如資料在新增、刪除、修改資料時，是否會發生資料不一致性或者資料存放有多餘性的狀況發生。不過，學者們已經發展了正規化技術，來解決這類型的問題。