軟體項目實訓及課程設計指導——系統概要設計中的實體類結構和關係的設計示例
1、軟體應用系統中的實體類及主要的作用
軟體應用系統中的實體類主要是指軟體系統中代表人、地點、事物或概念等方面的數據對象。通常把業務領域中的各種名詞——例如客戶、訂單、商品等信息可以作為應用系統中的實體域對象。在如下示圖中的各個資料庫表所體現出的數據對象都可以設計為對應的實體類，然後在數據訪問邏輯組件中訪問和操作這些實體類的對象實例。
在銀行帳戶信息管理系統中，主要有代表帳戶信息的AccountInfoPO實體類、代表銀行卡信息的BankCardPO實體類、代表儲戶信息的UserInfoPO實體類和代表管理人員信息的AdminUserInfoPO實體類等。
如下示圖為銀行帳戶信息管理系統中的各個實體類結構和關係的設計結果，作者在此示圖中隱藏了每個實體類中的各個成員屬性（沒有顯示）。
而如下示圖為體現某個軟體應用系統中的數據訪問操作組件、資料庫連接組件和數據實體類組件之間關係的UML類圖的局部截圖。
2、軟體應用系統中的實體類對象實例的持久化及技術實現
所謂實體類對象的實例的持久化也就是將實體類對象的實例永久保存到磁碟文件（如資料庫）中的過程。
為什麼要進行實體類對象實例的持久化過程？因為當實體類對象實例在內存中被創建後，它們不可能永遠地存在——計算機中的內存是無法永久地保存數據的，因此必須對這些實體類對象實例進行持久化操作。否則，如果這些對象實例沒有被持久化，則該實體類對象實例的信息將在軟體應用系統結束運行後隨之也將被消失掉。
目前在J2EE技術平臺中，提供有下面幾種常用的實現實體類對象實例持久化的技術實現方式：
（1）標準的JDBC技術
直接採用JDBC API並在數據訪問對象中直接嵌入標準的SQL語句，並實現對目標資料庫表中的數據訪問操作--增、刪、改和查功能操作；
（2）CMP（Container-Managed Persistence）
由J2EE EJB容器來管理各個實體EJB組件的持久化功能實現；
（3）ORM（Object/Relational Mapping）
也就是採用對象/關係映射技術實現實體類對象實例持久化功能；
（4）JDO（Java Data Objects）
由SUN 公司制定的描述對象實例持久化語義的標準API，它支持把對象實例持久化到任意一種存儲系統中--包括關係型資料庫、面向對象的資料庫、基於XML的資料庫以及其他專用的存儲系統等。
3、體現實體類之間關係的實體關係圖的主要作用
（1）實體關係圖ERD（Entity Relationship Diagram）
實體關係圖是指以實體、關係、屬性三個基本概念來概括和描述軟體系統中的各個實體類對象實例的基本結構，從而描述出實體的靜態數據結構的一種概念模式。當然，不同的UML類圖的實現工具軟體在表現實體關係圖ERD時可能會存在不同的形式，下圖示例為在Rose工具中創建出的某個軟體應用系統的實體關係圖ERD的局部截圖。
而下圖示例圖為在MyEclipse開發工具中應用 Database Explorer ER-Designer設計工具創建出的某個軟體應用系統的實體關係圖ERD的局部截圖。
（2）實體關係圖的主要作用
實體關係圖用於描述軟體應用系統中實體之間的對應關係，在軟體應用系統的需求分析階段使用實體關係圖則可以描述軟體應用系統中實體之間的邏輯關係，而在軟體應用系統的設計階段則使用實體關係圖描述出軟體應用系統中的資料庫表之間的關係（比如「一對一」、「一對多」和「多對多」等關係），如上示圖所示的各個實體之間的對應關係其實就代表對應的資料庫表之間的關係。
採用實體關係圖描述軟體應用系統中的數據模型，能夠幫助軟體應用系統的設計人員預先精確定義出軟體應用系統中的各種數據需求，使軟體應用系統的設計人員能夠對以後的系統改進和軟體應用系統可能的需求變化做出有效的設計規劃——能夠隨著軟體應用系統的開發實現的進展，不斷地改進和完善軟體應用系統的規劃、設計和重構。
（3）實體關係圖所可能存在的不足之處
由於實體關係圖只關注於軟體應用系統中數據之間的關係，而缺乏對軟體應用系統功能的描述。如果將實體關係圖與數據流圖DFD（Data Flow Diagram尤其適用於MIS資料庫管理系統的表述，但是從DFD圖中無法表達活動中的各個實體間的關係）兩種方法相結合，則可以更準確地描述軟體應用系統中的數據需求。
數據流圖DFD是一種最常用的結構化分析工具，主要實現從數據傳遞和加工角度，以圖形的方式刻畫和描述出系統內的數據運動情況（數據的來龍去脈和實際流程----數據在對象間流動），從而實現對系統中信息運動的抽象，是MIS資料庫管理系統中的系統數據建模的主要形式。下面為一個在Excel中設計出的人員管理系統中的DFD示例。
因此，讀者在課程設計中的項目設計中應該要充分地應用實體關係圖ERD和數據流圖DFD以準確地描述出本軟體應用系統項目中系統的數據需求。
4、系統概要設計中的實體類結構和關係的設計
銀行帳戶信息管理系統中的各個實體類結構和關係的設計結果請見下圖所示，為了節省本文章的篇幅，作者在此圖中隱藏了每個實體類中的各個成員屬性（沒有顯示）。
5、依據實體關係圖進行資料庫表的邏輯結構設計時必須要遵循資料庫表結構的範式
在設計軟體應用系統中的各個資料庫表邏輯結構之前，軟體應用系統的設計人員首先要進行軟體應用系統中存在哪些實體和它們之間存在什麼關係的識別與確定；然後再根據各個實體的屬性及各個實體之間的關係，在軟體應用系統的概要設計階段中設計出對應的資料庫表結構和資料庫表之間的關係。
當然，資料庫表邏輯結構的設計工作必須要遵循一定的設計規則。在關係型資料庫表結構設計中，這種設計規則就是資料庫表結構的範式——範式是符合某一種級別的關係模式的集合。
（1）第一範式（1NF）
是指資料庫表的每一列都是不可分割的基本數據項。簡而言之，第一範式就是資料庫表中無重複的列。
（2）第二範式（2NF）
要求資料庫表中的每個實例或行必須可以被唯一地區分，這個唯一屬性列被稱為主關鍵字或主鍵。
（3）第三範式（3NF）
要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息，也即屬性不依賴於其它非主屬性。
下圖所示為銀行帳戶信息管理系統中的資料庫表的定義及代表帳戶信息的資料庫表account表的結構定義的圖示。
6、依據實體關係圖進行資料庫表的邏輯結構設計
根據實體類中的成員屬性獲得資料庫表結構中的各個欄位的類型的主要工作過程如下。（1）首先，根據對每個實體類中的數據的抽象結果獲得對應的成員屬性，據此作為資料庫表結構設計的基本依據；
（2）然後，再建立出目標資料庫表結構，並進行數據內部以及外在關係的分析，從而有效地建立出整個軟體應用系統的數據結構——在關係型資料庫系統中通常稱為資料庫表結構；（3）最後，把各種數據信息用不同的資料庫表來存儲。
當然，在資料庫表的主鍵欄位的設計方面儘可能不要使用業務本身的數據作為資料庫表的主鍵——比如身份證號碼、公司編號、學生的學號等；並且主鍵與外鍵相互配對，表示實體之間的連接關係（也就是對應的類之間的關聯關係等）。
但讀者需要注意的問題，由於面向對象設計的機制與目前的關係型資料庫管理系統中所支持的各種關係模型存在不同和差異，造成了面向對象設計與關係型資料庫表設計之間在體現關係方面的不匹配——因為面向對象設計是基於如耦合、聚合、封裝等理論，而關係模型則是基於數學原理；此外，面向對象設計中提供有「繼承」、「組合」、「聚合」和「依賴」等關係的支持，而在關係模型中則不存在這些關係。
因此，軟體應用系統在依據實體關係圖設計出對應的資料庫表結構關係時需要進行「對象/關係映射」（O/R Mapping）的工作——也就是將關係型資料庫表和面向對象設計中的對象關係之間相關聯。
如下示圖是根據某個軟體應用系統中各個實體的屬性及各個實體之間的關係，軟體應用系統的設計人員在設計階段設計出對應的資料庫表結構和表關係的局部截圖。