案例分析 2 ：系统建模或数据库设计

21

【Q1】 在系统初步运行后，发现系统数据访问性能较差。经过分析，刘工认为原来数据库规范化设计后，关系表过于细分,造成了大量的多表关联查询,影响了性能。例如当用户查询商品信息时，需要同时显示该药品的信息、供应商的信息、当前库存等信息。
为此,刘工认为可以采用反规范化设计来改造药品关系的结构，以提高查询性能。修改后的药品关系结构为;药品(药品ID,药品名称,药品型号，药品价格,供应商ID,供应商名称，当前库存数量);
请用200字以内的文字说明常见的反规范化设计方法，并说明用户查询商品信息应该采用哪种反规范化设计方法。

常见的反规范化技术包括：
（1）增加冗余列：增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。
（2）增加派生列：增加派生列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。
（3）重新组表：重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。
（4）分割表：有时对表做分割可以提高性能。
用户查询商品信息应该采用：增加冗余列。
用户查询商品信息时，需要显示药品信息（药品表中），供应商信息（供应商表），库存信息（库存表中），此时查询的是药品表，
但表中缺了供应商信息和库存信息，可以通过增加冗余列的方式把这些信息并过来。以避免连接操作带来的查询性能下降。

【Q2】 王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用20O字以内的文字说明在反规范化”计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。

针对反规范化数据不一致问题，可采用的解决方案包括：
1、触发器数据同步。
2、应用程序数据同步。
3、物化视图。

【Q3】 该系统采用了Redis来实现某些特定功能(如当前热销药品排名等)，同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成Redis和MySQL的数据实时同步问题。
(1)Redis的数据类型包括String、 Hash、List、Set和ZSet等,请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。
(2请用200字以内的文字解释说明解决Redis和MySQL数据实时同步问题的常见方案。

A (1),热销药品排行榜应选用有序集合Zset,原因是排行榜既要去重，也要排序，用这种结果最为合适。

A (2),要实现Redis和MySQL之间的同步，常见方法包括：
1、实时同步方案，先查缓存，查不到再从DB查询，并保存缓存；更新缓存时，先更新数据库，在将缓存设置过期时间。
2、异步队列方式同步，可采用消息中间件处理。
3、通过数据库插件完成数据同步。
4、利用触发器进行缓存同步。

【Q3 扩展】 Redis中的数据类型的特点及示例
String(字符串) ：特点–存储二进制，任何类型数据，最大512M；示例–缓存，计数，共享Session。
Hash(字典）：特点–无序字典，数组+链表，适合存对象，Key对应一个HashMap。针对一组数据； 示例–存储、读取、修改用户属性。
List(列表)：特点–双向链表，有序，增删快，查询慢；示例–消息队列，文章列表，记录前N个最新登录的用户ID列表。
Set(集合)：特点–键值对无序，唯一，增删查复杂度均为O（1），支持交/并/差集操作。示例–独立IP，标签。
Zset(Sorted set 有序集合)：特点：键值对有序，唯一，自带按权重排序效果； 示例–排行榜。

20

【Q1】请说明关系型数据库开发中，逻辑数据模型设计过程包含哪些任务?该包裹单的逻辑数据模型中应该包含哪些实体?并指出每个关系模式的主键属性。

逻辑数据模型设计过程包含的任务：
（1）构建系统上下文数据模型，包含实体与实体之间的联系；
（2）绘制基于主键的数据模型，为每个实体添加主键属性；
（3）构建全属性数据模型，为每个实体添加非主键属性；
（4）利用规范化技术建立系统规范化数据模型。

包裹单的逻辑数据模型中包含的实体：
（1）收件人（主键：电话）
（2）寄件人（主键：电话）
（3）包裹单（主键：编号）

【Q2】 请说明什么是超类实体?结合图中包裹单信息，试设计一种超类实体，给出完整的属性列表。

超类实体是将多个实体中相同的属性组合起来构造出的新实体。
用户（姓名、电话、单位名称、详细地址）

【Q3】 请说明什么是派生属性?结合图2-1中包裹单信息说明哪个属性是派生属性。

派生属性是指某个实体的非主键属性有该实体其他非主键属性决定的。

包裹单中的总计是有资费、挂号费、保价费、回执费计算得出的，所以总计是派生属性。

【延伸】

数据库设计分为概念结构设计、逻辑结构设计、物理结构设计:
概念设计也称为概念结构设计，其任务是在需求分析阶段产生的需求说明书的基础上，按照特定的方法将它们抽象为一个不依赖于任何DBMS的数据模型，即概念模型。概念模型的表现形式即ER模型。
逻辑设计也称为逻辑结构设计，其主要任务是将概念设计阶段设计好的E-R图转换为与选用的具体机器上的DBMS所支持的数据模型相符合的逻辑结构(如:关系模式)。
物理设计也称为物理结构设计，其任务是对给定的逻辑模型选取一个最适合应用环境的物理结构，所谓数据库的物理结构,主要是指数据库在物理设备上的存储结构和存取方法。
【2】
当较低层次上实体类型表达了与之联系的较高层次上的实体类型的特殊情况时，就称较高层次上实体类型为超类型,反之为子类型。子类到超类的过程为概化，超类到子类的过程为特化。
①子类与超类之间具有继承特点,即子类包含了超类的所有属性，并且可以比超类拥有更多的属性。②这种继承性是通过子类实体和超类实体有相同的实体标识符实现的。
【3】
可以从其它属性得来的属性就叫派生属性。包裹图中的“总计"属性是派生属性。可以从资费、挂号费、保价费、回执费累加计算出来。

19

【Q1】 根据订餐管理系统功能说明，请在图2-1所示数据流图中始出外部实体E1_{E4和加工P1}P4的具体名称。

略
【Q2】根据数据流图规范和订餐管理系统功能说明，请说明在图2-1中需要补充哪些数据流可以构造出完整的0层数据流图。

【Q2 延伸】数据流图中常见错误包括黑洞、灰洞和奇迹三种类型的逻辑错误和部分语法错误。

1、黑洞：加工中只有输入没有输出。
2、奇迹：加工中没有输入却有输出。
3、灰洞：加工中输入不足以产生输出。

另外，常见的错误还有：

4、实体与实体之间有数据流

5、实体与数据存储之间有数据流

6、输入流和输出流的名字相同

本题答案：
P1只有输出没有输入为无输入错误，需要增加E1到P1数据流"餐品订单";
P2同样为无输入错误，需要增加P1到P2数据流"餐品订单";
根据P3生成报表要求输入中有订单信息和食材信息，所以需要增加D1到P3数据流°订单汇总"”;
P3只有输入没有输出存在黑洞错误,需要增加P3到E3数据流“统计报表"。

【Q3】 根据数据流图的含义,请说明数据流图和系统流程图之间有哪些方面的区别。

（1）数据流图中的处理过程可并行，系统流程图在某个时间点只能处于一个处理过程。
（2）数据流图展现系统的数据流，系统流程图展现系统的控制流。
（3）数据流图展现全局的处理过程，过程之间遵循不同的计时标准；系统流程图中处理过程遵循一致的计时标准。
【Q3 扩展】
数据流图和流程图是结构化建模中使用的重要工具，能够帮助开发人员更好地分析和设计系统，增强系统开发人员之间交流的准确性和有效性。
数据流图作为一种图形化工具用来说明业务处理过程、系统边界内所包含的功能和系统中的数据流，适用于系统分析中的逻辑建模阶段。
流程图以图形化的方式展示应用程序从数据输入开始到获得输出为止的逻辑过程，描述处理过程的控制流，往往涉及具体的技术和环境，适用于系统设计中的物理建模阶段。
数据流图和流程图是为了达到不同的目的而产生的，其所采用的标准和符号集合也不相同。在实际应用中，区别主要包括是否可以描述处理过程的并发性;描述内容是数据流还是控制流;所描述过程的计时标准不同三个方面。

18

【Q3】 (1)信息工程方法中的“实体(entity)"与面向对象方法中的“类(class)“之间有哪些不同之处?
(2）在面向对象方法中通常采用用例(Use Case)来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的Essential Use Cases和Real Use Cases有哪些区别?
请用100字以内文字解释说明上述两个问题。

（1）实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
（2）Essential Use Cases 可翻译为抽象用例，RealUse Cases 可翻译为基础用例。
二者的区别在于：
Essential Use Cases用于分析阶段，Real Use Cases用于设计阶段
Essential Use Cases描述用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

17

【Q1】 请用300字以内的文字分别说明数据库程序在线访问方式和ORM方式的优缺点，说明该软件企业采用ORM的原因。

数据库程序在线访问参考：https://www.freesion.com/article/73801170993/

数据库程序在线访问方式的优点：
1、性能比ORM好
2、可以处理复杂查询语句
数据库程序在线访问方式缺点：
1、要求程序员懂SQL语句
2、修改与维护相对困难

ORM优点：
1、使用ORM可以大大降低学习和开发成本。
2、程序员只需要写少量、简单的SQL即可进行数据库操作
3、减少程序的代码量。
4、降低由SQL代码质量差而带来的影响
ORM的缺点：
1、不太容易处理复杂查询语句
2、性能较直接使用SQL差

本题中的场景之所以选择ORM，主要考虑的是程序员缺乏数据库开发经验，这样SQL语句的质量有很大风险。
同时，学习成本很高。此外，应用简单，不必担心ORM对性能的影响。

【Q1 延伸】
ORM,即Object-Relationl Mapping，它在关系型数据库和对象之间作一个映射，这样，我们在具体的操作数据库的时候,就不需要再去和复杂的SQL语句打交道，只要像平时操作对象一样操作即可。
当你开发一个应用程序的时候(不使用OR Mapping)，可能会涉及许多数据访问层的代码，用来从数据库保存、删除、读取对象信息等等,然而这些代码写起来总是重复的。
一个更好的办法就是引入OR Mapping。实质上，一个OR Mapping会为你生成DAL。与其自己写DAL代码，不如用OR Mapping，你只需要关心对象就好。
使用ORM可以大大降低学习和开发成本。而在实际的开发中，真正对客户有价值的是其独特的业务功能,而不应该把大量时间花费在编写数据访问、CRUD方法、后期的Bug查找和维护上。在使用ORM之后，ORM框架已经把数据库转变成了我们熟悉的对象，我们将只需要了解面向对象开发就可以实现数据库应用程序的开发，不需要浪费时间在SQL上。同时也可减少代码量,减少数据层出错机会。
通过Cache的实现，能够对性能进行调优，实现了ORM区隔了实际数据存储和业务层之间的关系，能够对每一层进行单独跟踪，增加了性能优化的可能。

【Q2】 请用100宇以内的文字说明新体系架构中增加数据访问层的原因。请根据图4-1所示,填写图中空白处(1)-(3).

增加数据访问层的原因：
（1）由于涉及到多种异构数据库平台，数据访问复杂性增加，不宜与业务逻辑混合在一起。
（2）数据管理变复杂之后，需要使用的代码量增加，分单独层次有利于让逻辑更清晰。
（3）业务逻辑应以相同的方式应对异构的数据库，此时需要单独的数据访问层屏蔽差异性。

【Q2 延伸】
数据在线访问模式提高了数据访问的性能，但同时导致了业务逻辑层与数据访问的职责混乱，一旦要求支持的数据库发生变化，或者需要修改数据访问的逻辑，由于没有清晰的分层，会导致项目做大的修改。而随着硬件系统性能的提高,以及充分利用缓存、异步处理等机制,分层式结构所带来的性能影响可以忽略不计。
根据题干说明，新的电子商务平台业务复杂，而且需要访问异构的数据源，也就是说需要访问不同类型的数据库。因此，需要增加新的数据库访问层来封装对数据库的访问，使得在应用程序设计时，不会因为数据库种类的不同而受到影响,尽量做到数据库无关。

【Q3】 应用程序设计中，数据库访问需要良好的封装性和可维护性，因此经常使用工厂设计模式来实现对数据库访问的封装。请解释工厂设计模式,并说明其优点和应用场景;请解释说明工厂模式在数据访问层中的应用。

工厂模式分抽象工厂与工厂方法，题目中的场景适合采用抽象工厂设计模式。
抽象工厂设计模式提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。
优点：可以非常方便地创建一系列的对象，其使用场景也是创建系列对象的情况。在本题中，可以针对Oracle、MySQL、SQLServer分别建立抽象工厂，若指定当前工厂为Oracle工厂，
则创建出来的数据库连接，数据集等一系列的对象都是符合Oracle操作要求的。这样便于数据库之间的切换。

【Q3 延伸】
在应用程序设计中,需要对数据库访问进行良好的封装，使其具有良好的可维护性，尽量使得应用程序与数据库无关。本题中，应用系统需要访问异构数据源，在应用程序中会存在多种数据访问接口。因此在实际开发中，需要对这些访问接口再做一次封装，这样可以减少操作数据库的步骤,减少代码编写量。工厂设计模式是使用的主要方法。工厂设计模式定义了创建对象的接口，允许子类决定实例化哪个类，而且允许请求者无须知道要被实例化的特定类，这样可以在不修改代码的情况下引入新类。优点是:没有了将应用程序类绑定到代码中的要求,可以使用任何实现了接口的类;允许子类提供对象的扩展版本。工厂设计模式的应用场景有:类不能预料它必须创建的对象的类，类希望其子类指定它要创建的对象。在数据访问层定义采用工厂模式，定义统一的操纵数据库的接口，然后根据数据库的不同，由类工厂来决定实例化哪个类。在具体类中实现特定的数据库访问类。这样，就可以实现主客户端指定或根据配置文来选择访问不同的数据库,从而实现应用程序与数据库无关。

16

【Q1】用例建模用来描述待开发系统的功能需求，主要元素是用例和参与者。请根据题目所述需求，说明教学服务系统中有哪些参与者。

管理员 、学生 、教师 、打印机 及 时间

【Q1 延伸】
参与者是指系统以外的，需要使用系统或与系统交互的事物，包括：人或组织、设备、外部系统等。在本题中，较为容易识别的参与者包括：学生、教师、管理员、
比较隐晦的参与者包括：时间、打印机

【Q2】 用例是对系统行为的动态描述，用例获取是需求分析阶段的主要任务之一。请指出在面向对象系统建模中，用例之间的关系有哪几种类型?对题目所述教学服务系统的需求建模时，“登录系统"用例与注册课程"用例之间、“参加考试"用例与“参加补考”用例之间的关系分别属于哪种类型?

用例之间的关系包括：包含、扩展、泛化、以及依赖 ，参考：https://www.cnblogs.com/lcword/p/10472040.html
“登录系统”用例与“注册课程”用例之间 是包含关系
“参加考试”用例与“参加补考”用例之间 是扩展关系

【Q2 扩展】
用例之间的关系主要有泛化(Generalization)、包含 (Include)和扩展(Extend).
(1)当可以从两个或多个用例中提取公共行为时,可以使用包含关系来表示。
(2)如果一个用例混合了两种或两种以上不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例。
(3)当多个用例共同拥有一个类似的结构和行为的时候，可以将它们的共性抽象成父用例，其他的用例作为泛化关系中的子用例。
在题目要求中，用例“登录系统°是用例"注册课程"和其他用例执行的公共行为，两者是包含(Include)关系。用例“参加补考"是用例参加考试”的一种分支和特殊场景，两者之间的关系是扩展(Extend）关系。

【Q3】类图主要用来描述系统的静态结构，是组件图和配置图的基础。请指出在面向对象系统建模中，类之间的关系有哪几种类型?对题目所述教学服务系统的需求建模时，类University与类Student之间、类University和类Department之间、类Student和类Course之间的关系分别属于哪种类型?

类之间的关系类型有：实现、继承（泛化）、聚合、组合、关联、依赖。 参考：https://blog.csdn.net/qq_29025955/article/details/120139172
类University与类Student之间的关系属于聚合关系。
类University与类Department之间的关系属于组合关系。
类Student与类Course之间的关系属于关联关系。

【Q3 扩展】
依赖关系:一个事物发生变化影响另一个事物。泛化关系:特殊/一般关系。关联关系:描述了—组链,链是对象之间的连接。
聚合关系:整体与部分生命周期不同。
组合关系:整体与部分生命周期相同。实现关系:接与类之间的关系。
在题目要求中，类UJniversity与类Student之间的关系是整体与部分关系，而且具有不同的生存周期，所以是聚合关系。
类University和类Department之间的关系是整体与部分的关系，两者具有相同的生存周期，所以是组合关系。
类Student和类Course之间为连接关系,所以属于关联关系。

15

【Q1】 请从设计难度、数据冗余程度、数据架构、应用扩展性等4个方面对关系型数据库管理系统和文件系统两种数据存储方式进行比较,填写表4-1中(1)~(4).

设计难度：
关系型数据库-- 数据结构需要符合关系模式，设计难度较大。
文件系统-- 针对特定应用系统设计，难度较小。

数据冗余程度：
关系型数据库-- 遵守数据库范式，数据冗余较少。
文件系统-- 可能在多个文件中复制相同的数据属性，数据冗余较多。

数据架构：
关系型数据库-- 以数据库为中心组织、管理数据
文件系统-- 以应用系统为中心管理数据

应用扩展性：
关系型数据库-- 数据独立于应用系统，数据库系统接口标准化，易于在不同应用之间共享数据。
文件系统-- 符合特定应用系统要求的文件数据很难在不同的应用系统之间共享。

【Q2】对系统的核心业务需求进行认真分析后，公司的资深架构师张工提出一种内存数据库和关系数据库的混合存储架构，其核心思想是将需要频繁读写的数据存入内存数据库，而将相对固定不变的数据存入关系数据库。请首先分析比较内存数据库和关系数据库在数据模型、读写性能、存储容量、可靠性等方面的差异，填写表4-2中(1)～(4)的空白，并根据张工的思路指定各种业务数据的存储方式,填写表4-3中(5) ~(9)中的空白。

主要数据模型：
内存数据库-- 键值对/Key-Value模式
关系数据库-- 关系模式

读写性能：
内存数据库-- 内存直接读写，性能相对较高。
关系数据库-- 需要先将外存中的数据加载到内存，才能进行读写，性能相对较低。

存储容量：
内存数据库-- 存储大小受限于系统分配的内存，存储容量小。
关系数据库-- 基于磁盘存储，存储容量大。

可靠性：
内存数据库-- 虽然也有恢复机制，但数据存于内存中，一旦发生故障，恢复难度较大。
关系数据库-- 内建恢复机制，可靠性较高。

（5）内存
（6）内存
（7）关系
（8）内存
（9）内存

【Q3 延伸】
SQL语句设计时，影响查询效率的设计原则是：
1、查询时尽量不要返回不需要的行、列；
2、需要进行多表连接查询时，尽量使用连接查询，避免使用子查询结构；
3、尽量避免采用 NOT IN/ NOT EXIST / LIKE等使用全表查询的操作；
4、尽量避免使用DISTINCT关键字

15 second

【Q1】 状态图和活动图是软件系统设计建模中常用的两种手段，请用200字以内文字简要说明状态图和活动图的含义及其区别。

状态图：主要用于描述一个对象在起生存周期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件，
以及因状态转移而伴随的动作。
活动图：可以用于描述系统的工作流程和并发行为。活动图其实可以看做状态图的特殊形式，
活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。

两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可以描述并发行为，而状态图不能。

【Q1 延伸】

状态图用来描述一个特定对象的所有可能状态以及其引起状态转移的事件，一个状态图包括一系列的状态以及状态之间的转移，状态图通常用于表示单个对象在其生命周期中的行为。活动图用来描述操作的行为，也用于描述用例和对象内部的工作过程。状态图和活动图都是用来描述系统的动态行为特征的，主要用于描述事物的状态变化和处理过程。
但是两者还是有本质区别:
状态图和活动图用于不同的目的，状态图着重描述—系列的状态及状态间的转移，状态间的变迁需要外部事件的触发。活动图用于捕获动作（将要执行的工作或活动)及动作的结果，活动图中一个活动结束将立即进入下一个活动,是内部处理驱动的流程。

14

【Q1】请用300以内文字说明数据流图(Data Flow Diagram）的基本元素及其作用。

外部实体：定义位于项目之外，但与正在被研发的系统有交互关系的人、部门、外部系统或组织；
数据流：描述运动中的数据，表示到一个过程的数据输入，或者来自一个过程的数据输出；
加工：加工是对数据进行处理的单元，他接收一定的数据输入，对其进行处理，并产生输出；
数据存储：表示信息的静态存储，可以是文件、文件的一部分、数据库的元素等；

【Q1 延伸】
数据流图通过外部代理(实体)描述系统与外界之间的数据交互关系，内部的活动通过处理(加工）表示，用数据流描述系统中不同活动之间的数据传输内容和方向，需要持久化存储的数据用数据存储表示，一般用文件系统或者数据库表存储数据。

【Q2】 数据流图在绘制过程中可能出现多种语法错误，请分析图2-1所示数据流图中哪些地方有错误，并分别说明错误的类型。

数据流图中的错误包括两大类：
第一大类是逻辑错误：加工节点输入输出不平衡， 包括黑洞（有输入没有输出）、灰洞（输入不足以支撑输出）、奇迹（无输入却有输出）三种类型。

本题中 P5.3只有输入没有输出 属于黑洞
P5.4没有输入却有输出 属于奇迹

第二大类是语法错误：比如数据存储不完整、在数据存储与外部代理之间或者各自之间没有经过加工之间发生数据流等。

本题中 数据存储D2 没有输出数据流，属于语法错误。 分析：题目描述中有“如果查询到该供应商有待付款记录。。。”说明数据存储D2应该是要有数据流的输出的。
数据存储D1没有经过加工直接到了外部实体A2，属于典型的语法错误。

12

【Q1】 设计模式按照其应用模式可以分为三类:创建型、结构型和行为型，请用200字以内文字说明三者的作用。

创建型模式主要用于创建对象，为设计类实例化新对象提供指南。
结构型模式主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。
行为型模式主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。

【Q2】 请将项目组已经掌握的设计模式按照其作用分别归类到创建型、结构型和行为型模式中。

创建型：构造器 原型模式
结构型：适配器 外观模式 代理模式
行为型：命令 中介模式 状态模式 策略模式

【Q3】 针对题目中所提出的设计要求(1)和(2)，项目组应该分别选择何种设计模式?请分别用200字以内文字说明具体的解决方案。

（1） 策略模式
解决方案：在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类，它们从同一个超类继承。每个类都有相同名称的标准接口方法，用于根据订单编号计算将要折扣的金额总数。计算每个促销的内部代码对促销类来说完全不同。
（2） 适配器模式
解决方案：增加一个类作为适配器，转换类的接口到客户端类期望的另一接口。实现一个适配器类，这个类为系统的其他部分提供了一个不变的方法供调用，为了集成不同商品供应商提供的税率计算类，编写一个适配器类的子类，包含调用购买类所
需的代码。该子类将系统的调用映射到某个供应商的税率计算类，如果要更换供应商，那么只需要写一个新的适配器子类，其他保持不变。