软件项目实训及课程设计指导——系统概要设计中的实体类结构和关系的设计示例
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）的工作——也就是将关系型数据库表和面向对象设计中的对象关系之间相关联。
如下示图是根据某个软件应用系统中各个实体的属性及各个实体之间的关系，软件应用系统的设计人员在设计阶段设计出对应的数据库表结构和表关系的局部截图。
来源：与杨先生共同进步
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！