一、 针对前期作业中选定的业务背景，请完成如下数据库应用系统规划训练
1） 给你所规划的数据库应用系统起一个系统名称
答：知乎论坛业务模型

2） 尝试调研分析或自主规划设计该系统的业主企业或组织机构的组织架构图，并说明该系统涉及企业或组织机构中哪些相关业务部门。
答：该系统涉及到知乎调整后的组织架构中前端的社区内容、会员和商业广告三大事业部，中端的社区业务平台和技术中台，后端的财务、市场等职能支持部门。

3） 调研分析企业相关部门中的跟该系统有关的各种用户或企业外的用户，用文字描述用户使用系统开展业务的场景（例如，租车客户将在特定手机上打开APP，用户在界面上点击….）。
答：

A.在系统上发布问题

a. 用户打开对应的网页或者手机APP，输入账号密码登录
b. 如果输入正确，进入主界面，输入错误则返回登陆页面并显示输入错误并提供找回密码服务
c.在主页点击提问，在页面弹出的文本框中输入自己的问题。
d.调整绑定话题和问题背景。
e.等待一段时间后审核通过，问题成功发布

B.在系统上回答问题

a.在主页点击热度较高问题或搜索关键词查找部分问题
b.进入问题后点击写回答
c.在弹出的文本框中输入答案
d.点击发布回答后回答成功

C.在系统上发布文章

a.在主页点击创作中心写文章部分
b.输入文章的标题内容
c.点击发布，一段时间审核通过后发布成功

D.在系统上购买电子书

a.进入电子书购买界面
b.输入信息检索电子书
c.确定购买，启动付费系统
d.确认付费完成后可以再本地实现下载和在线阅读

4） 规划系统的性能指标，如并发用户数、用户数、核心业务响应时间等。
答：（1）对核心业务进行操作，即对数据库信息进行检索或者增删减改的时间消耗。例如模糊查询一个标题有“数据库”的文章，在这一内容文章数量较大的情况下能否快速并且直观地展示所有搜索结果。
（2）并发用户数。该类系统一个具有挑战性的问题是面对多个用户同时对数据库操作，应对该种并发操作的结果如何。这里的用户交互我们定义为进行一次数据表的查询操作。
（3）平均故障响应时间（TAT）。即从出现故障到该故障得到确认修复前的这段时间。该指标反应的是服务水平。平均故障响应时间越短，对用户系统的影响越小。
（4）兼容性，是否大多数浏览器都能使得系统信息正常显示。保证大多数用户的体验。
（5）高存储：长期存储历史数据，确保内容积累且不影响前面的性能

5） 说明你所规划的系统的战略地位，例如系统服务于公司以什么方式赢得客户、获得直接或间接收益，获得市场地位。
答： 类似知乎的平台问答平台在网络上还有很多，知乎能够赢得客户有两个方面的主要优势，其一是高质量用户带来的高质量回答，在用户回答审核方面严加把关，其二是自身系统的性能优势，在高吞吐，大存储量的情况下依旧做到了毫秒级的查询搜索速度，给用户带来了良好的使用体验。

6） 尝试说明建设该系统可能涉及的投资和运营成本，分析可能获得的收益。
答：投资和运营成本：
对于运营成本来说，最主要的两点就是服务器的购买与维护以及在进行内容审查时的人工成本。
因为类似知乎这样的问答平台自身的数据量相对较大，同时又需要维持快速的查询回复，所以对于服务器以及系统的需求往往比较高。同时对于一个问答平台，往往内容的审查是很关键的，所以在审查方面的投入也会比较高。
另外还有就是网站，APP的创建成本，吸引各个领域的专业人士进入完成高质量内容积累的成本，系统完成后的推广成本等等。
获得的收益：
（1）广告盈利
参考目前知乎的广告主要分为三个部分：打开知乎前的开屏广告、问答之间的插入的软广告、回答结尾答主选择是否插入广告。
这三个本质上是利用平台流量进行广告盈利。
（2）付费会员
用户付费，知乎以图文、视频形式提供优质海量为用户内容，涉及内容广泛小说、财经、科学、讲座、杂志等
（3）在线教育
有一些出版物图书以及电子书，比如知乎周刊，盐系列等书籍。
7） 结合系统业务功能与性能规划，确定初步的技术选型规划，大致分析该系统在技术上的可行性。
答：以python作为开发语言，MYSQL作为信息存储方式建立系统，HTML5编写web前段网站，sublime text作为开发工具，采用用户层，逻辑层，数据层的分层逻辑。整个方案体系结构框架合理，层次分析合理，有可持续的盈利方式和良好前景。并且技术方面具备一定的可行性。

二、 数据库应用系统需求分析
自学统一建模语言(Unified Modeling Language, UML)，在作业中解释UML、用例(Use Case)、用况(Use Case Scenario)、用例图(Use Case Diagram)、泳道图和数据流图（Data Flow Diagram，DFD）的概念及其VISIO中的画法，针对前述作业中选定的业务场景，开展如下系统需求分析：
概念说明：
1.UML：统一建模语言（Unified Modeling Language，UML）是用来设计软件蓝图的可视化建模语言。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。
2.用例：从用户角度描述系统功能，并指各功能的操作者。或者说在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。他包括了名称、描述、主要事件流、扩展流、异常流、前置条件和后置条件等等元素。
在Visio中，用例使用椭圆进行表示。如下图所示。

3.用况：通过查询，感觉用况和用例其实描述的类似，都是描述系统在一定场景下的系统功能，在Visio中也是同样用椭圆形进行表示。目前看到的比较明确区分两者的是说用况说明的是用户使用的情况、场景，是唯一的。而用例不唯一。
4.用例图：用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图中涉及的关系有：关联、泛化、包含、扩展。

a. 关联(Association)
　　表示参与者与用例之间的通信，任何一方都可发送或接受消息。
b. 泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
c. 包含(Include)
　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
d. 扩展(Extend)
　　扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

5.泳道图：泳道图，一种UML活动图，能够清晰体现出某个动作发生在哪个部门。泳道图在纵向上是部门职能，横向是岗位（有时候横向上不区分岗位）。绘图元素与传统流程图类似，但在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位。

6.数据流图：数据流图是用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反应系统必须完成的逻辑功能，因此它是一种功能模型。对于它在Visio中的表示方法，数据流图有四种基本图形符号：
箭头：表示数据流；
圆或椭圆或圆角矩形：表示加工；
双杠：表示数据存储；
方框：表示数据的源点或终点。

1） 分析系统业务需求，标识出用户(Actor或User)，进行系统功能划分，画出用例图；
答：本系统用例图如下：

2） 分析系统业务场景，针对涉及多个用户(Actor或用户)的业务场景，分析业务流程，画出泳道图（至少一个）。
答：本系统泳道图如下：

3） 结合前面作业设计结果，补充分析完善系统的数据项，数据结构（可以用类图表示），数据的存储（持久化）需求，形成数据字典。
答：对于系统的数据项，主要来自于数据库中各个表的属性。
对于answer（存储回答信息的表），它的数据项包括如下内容。相比与之前的设计，这里为回答ID增加了自增方法。便于查看

对于ebook（存储电子书信息的表），它的数据项包括如下内容。相比与之前的设计，这里为价格增加了不得小于等于0约束。

对于essay（存储文章信息的表），它的数据项包括如下内容。

对于question（存储问题信息的表），它的数据项包括如下内容。相比与之前的设计，这里为回答数增加了不得小于0约束。

对于user（存储用户信息的表），它的数据项包括如下内容。相比与之前的设计，这里为性别设置了域，只能在男或女中进行选择输入。

对于vip_member（存储会员信息的表），它的数据项包括如下内容。

关于系统的数据结构，这里按照数据项的种类进行类的划分。其中user和question，answer，essay都是一对多的关系，一个用户可以提出多个问题，写多个回答，发多篇文章。虽然存在用户不是会员的情况，但是因为一对一联系中可以没有实体对应联系，所以user和vip_member是一对一的关系，同时也是继承关系，因为会员本质上也还是用户，所以他应该继承user的所有属性。User和ebook是多对多得关系，因为一个用户可以购买多本电子书同时一本电子书也可以被多个用户购买。question和answer之间是组合关系，一个question内会存在多个answer，但是answer不能单独存在，会依赖于question，换言之，如果删除了问题，回答单独存在就没有意义，所以是组合关系。对于每个类里都会存在一个Init的函数，用来对类内变量进行初始化，方便其它类内函数的调用。表示的类图如下，类图中的函数因为不能引用中文变量，对于上面提到的属性进行英文调整：

对于数据的存储需求，首先对于数据量大小，为了让数据能够正常存储，磁盘容量往往都需要足够大。而对于数据的物理存储方式，由于essay和question是有频繁查找需求的表，并且涉及到相对过多的数据插入操作以及较大量的数据，所以不适合添加聚簇索引，而ebook 作为有频繁查找需求的表，自身插入操作较少，可以添加聚簇索引。User，vip_member和answer因为自身属性原因，随机存取方式即可。

4） 分析系统的数据处理需求，画出系统主要的数据流图，建议包含两个层级的DFD。
答：顶层图如下：

第0层如下：

5） 分析系统的非功能性需求，给出系统业务处理性能、安全性、完整性等需求。
将以上内容形成系统的需求规格说明书。
答： 对于业务处理性能，系统要采取集群方式提供服务，有异常检查系统，及时识别有问题的节点和重启，保证服务的高可用性。
对于业务处理的安全性，作为一个知识问答平台，自身没有过多的隐私信息存储，不过由于存在电子书购买业务，所以也要保障顾客的隐私信息不会泄漏。另外，平台的操作权限只能由登陆用户拥有，网站要对用户的密码进行保护。
对于业务处理的完整性需求，用户在平台对数据信息的修改要符合数据库表的三种完整性要求，否则会给用户提供无法执行的信息反馈。

三、 数据库应用系统设计—概念与逻辑设计
基于以上需求规格说明书，完成如下任务：
1） 结合新补充的需求，完善ER图，形成完整的实体关系模型。

因为用户和电子书之间为多对多得关系，所以添加购买实体型：
（用户ID，书籍ID，购买时间，价格）
其余实体关系不变。
2） 结合前面几次作业设计的数据模式，在函数依赖的范畴判定原有模式的规范化程度，并根据需要补充新关系模式。并对不属于3NF的模式进行分解，使其达到3NF的要求。
答：经过检查，发现所有实体型均满足了3NF。非主属性之间不存在函数依赖关系。
以上内容形成第一版的系统设计规格说明，以后持续完善。

补充作业：
完成教材（数据库系统概论第五版）P.241 7,8两题
第7题的ER图如下：

第八题的ER图如下

其中下划线为主键，斜体为外键。

经过分析以上两个关系模式均都有唯一的码，且都是唯一的决定因素，为BCNF，不会产生更新异常现象。