第五讲：毕业设计的框架设计
本讲我们来理清思路，如何把大数据思维融入毕业设计里面。
首先，前提是你已经知道了一个软件项目的制作，比如“基于分布式存储的学生档案管理系统”、“基于分布式计算的图书管理系统”、“基于网络爬虫的个性化新闻推荐系统”，首先你要理解了学生档案管理系统、图书馆管理系统、新闻推荐系统怎么写，然后才是如何加入大数据相关的技术点。
下的内容的视频版本可以看腾讯课堂上的，地址：https://ke.qq.com/course/2962343
一、毕业设计项目分类
所以，根据我们的毕业设计题目，主要分三个方向：
1、基于分布式存储的XXX系统；
2、基于分布式计算的XXX系统；
3、基于网络爬虫的XXX系统。
二、系统架构
首先，什么是系统架构，系统构架是对已确定的需求的技术实现构架,抽象来说，它是某个系统的体系结构，它确定一个系统的硬件或软件之间的连接。
系统架构设计模型主要有逻辑架构、功能架构、数据架构、物理架构和运行架构等模型图。系统架构就是一些模型图，模型图是人们用来理解系统和沟通的工具。这些模型图需要提供给与这个系统相关的人来理解系统，系统相关的人有项目经理、产品经理、开发人员、系统运营维护人员、客户、项目投资人等。这些人有不同的知识背景，对同一架构模型图也会有不同的认知和理解：如果把开发架构模型图给产品经理或客户看，他们定然看不懂也不能理解；同样的道理，如果只把逻辑架构图给开发人员看，就不能正确地指导开发人员构建开发环境。
因此我们（此时我们就是架构设计师）在进行系统架构设计时，需要从系统的不同维度进行设计，以满足系统相关人理解系统架构的需求。其中数据架构模型一般放在数据库中进行设计，运行架构和物理架构基本相近，只是在物理架构中加了数据的流向，因此一些系统设计使用物理架构代替了运行架构。
我们在论文里面只需要些物理架构（物理设计）或者逻辑架构（逻辑设计）、功能架构（功能设计）、数据架构（数据设计）即可。
2.1逻辑架构
逻辑架构是系统（程序）的运行模式，如：层次结构，调用关系。比如下面的分层：
2.2物理架构
物理架构就是基础架构的设计规划，例如：OS，硬件，网络，各种应用服务器之间的规划。如下面这个图：
2.2.1常见物理架构
所以，最简单的物理架构包括有：用户端-网络-服务器端（应用服务器-数据库服务器）。如下所示：
如上所示，常见的系统服务器端里面都是应用服务器和数据库服务器分开，通过局域网连在一起，最终数据经过防火墙。用户端可以简单的是web端，如果有安卓端的也可以写上APP。
2.2.2基于分布式存储的物理架构
如果在基于分布式存储的，就是多了一个分布式存储的服务器，这个服务器可以是采用伪分布式的，也可以采用完全分布式的，如下图所示则为伪分布式的：
如下图所示则为完全分布式的（HDFS由一个NameNode和2个DataNode组成）：
当然，论文的这个“系统架构”有了图还是不行的，还需要相对详细的文件描述。比如上一个图片，那么可以这样简单描述：
本系统的架构如上图所示，采用的是B/S框架，客户端支持电脑端及安卓手机端。服务器端由应用服务器、数据库服务器、分布式存储的HDFS集群组成，其中，HDFS集群包括一个NameNode节点，两个DataNode节点。数据库服务器用于存储结构化数据，HDFS集群用于存储非结构化数据，如图片、音视频、文件等。
2.2.3基于分布式计算的物理架构
基于分布式的计算也是一样，可以是伪分布式的，也可以是完全分布式的，如下图所示就是伪分布式的,可以看到在服务器端多了一个伪分布式的MapReduce服务器，用于给系统提供算力：
如下图所示是采用完全分布式的计算模式，当然模式是MapReduce1.0版本的，有条件的也可以使用YARN或Spark框架：
2.2.4基于网络爬虫的物理架构
基于网络爬虫的系统，其实网络爬虫也只是一个数据采集方式，可以规划如下，也就是把网络爬虫单独出来形成一个数据服务器。
2.3功能架构
功能框架，就是我们对于模块的功能进行一层一层框架化的搭建。如果没有功能框架，那么就会有以下的风险：
1. 系统功能分布零散，关联性和衔接性差；
2. 容易遗漏功能。
常见的功能框架有采用框图的，如下所示：
最近几年随着思维导图的兴起，越来越多的人也采用思维导图的模式里设计功能框图，如下所示：
无论是哪一种模式，都是将系统从上到下进行功能的细分。如何设计一个优秀的功能架构，功能架构设计不同于编写代码，代码需要遵循严格的语法和编程规范。功能框架没有规范可遵循，存在即合理，适合系统开发和运行的架构就是最合理的架构。
功能架构设计是在业务需求已经清晰的前提下进行的，假定在系统需求分析阶段已经确定了系统的功能和业务范围，也明确了系统运营需求。在上述需求还没有确定的情况下，不适宜开展系统的架构设计，所以各位同学要想清楚自己为什么要做这个系统？这个系统的意义是什么？这个系统是为了解决什么样的问题？只有需求分析阶段完善了，功能架构设计中我们自然知道这个系统有哪些功能，还有功能之间的层次。
2.4数据框架
当然，这个部分也可以写在论文的“数据设计”内容里。
2.4.1数据库范式
数据库设计常见的准则就是要满足数据库范式，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。
目前关系数据库有：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。
2.4.1.1第一范式（1NF）
第一范式是指在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
2.4.1.2第二范式（2NF）
第二范式是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER设计时添加，不是建库时随意添加）
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
2.4.1.3第三范式（3NF）
第三范式是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
2.4.2科德十二定律
关系数据库之父 埃德加·弗兰克·科德 的 12 条法则，也称“科德十二定律”，作为数据库设计的指导性方针：
一个关系形的关系数据库系统必须能完全通过它的关系能力来管理数据库。
1、信息法则
关系数据库中的所有信息都用唯一的一种方式表示：表中的值。
2、保证访问法则
依靠表名、主键值和列名的组合，保证能访问每个数据项。
3、空值的系统化处理
支持空值（NULL），以系统化的方式处理空值，空值不依赖于数据类型。
4、基于关系模型的动态联机目录
数据库的描述应该是自描述的，在逻辑级别上和普通数据采用同样的表示方式，即数据库必须含有描述该数据库结构的系统表或者数据库描述信息应该包含在用户可以访问的表中。
5、统一的数据子语言法则
一个关系数据库系统可以支持几种语言和多种终端使用方式，但必须至少有一种语言，它的语句能够一某种定义良好的语法表示为字符串，并能全面地支持以下所有规则：数据定义、视图定义、数据操作、约束、授权以及事务。（这种语言就是 SQL)。
6、视图更新法则
所有理论上可以更新的视图也可以由系统更新。
7、高级的插入、更新和删除操作
把一个基础关系或派生关系作为单个操作对象处理的能力不仅适应于数据的检索，还适用于数据的插入、修改个删除，即在插入、修改和删除操作中数据行被视作集合。
8、数据的物理独立性
不管数据库的数据在存储表示或访问方式上怎么变化，应用程序和终端活动都保持着逻辑上的不变性。
9、数据的逻辑独立性
当对表做了理论上不会损害信息的改变时，应用程序和终端活动都会保持逻辑上的不变性。
10、数据完整性的独立性
专用于某个关系型数据库的完整性约束必须可以用关系数据库子语言定义，而且可以存储在数据目录中，而非程序中。
11、分布独立性
不管数据在物理是否分布式存储，或者任何时候改变分布策略，RDBMS 的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。
12、非破坏性法则
如果一个关系数据库系统支持某种低级（一次处理单个记录）语言，那么这个低级语言不能违反或绕过更高级语言（一次处理多个记录）规定的完整性法则或约束，即用户不能以任何方式违反数据库的约束。
2.4.3还需要思考
我们设计数据库的时候，还可以思考一下几点：
1、如何降低对数据库功能的依赖
以往系统设计的时候，我们经常在数据库端设置很多的函数、存储过程、触发器等等。但是近年来随着计算机算力的提升，内存变得越来越廉价等因素，越来越多的功能慢慢有由程序端实现，而非数据库端来实现。原因在于，如果功能由数据库来实现时，一旦更换的一个数据库管理系统，比如从sqlserver换成mysql，如果新的系统不如之前的系统强大，不能实现某些功能，这时我们将不得不去修改代码。所以，为了杜绝此类情况的发生，功能应该由程序来实现，数据库仅仅负责数据的存储，以达到最低的耦合。什么是系统的耦合？软件工程中的耦合是指各个模块依赖程度，为了便于维护，自然希望耦合越低越好，你想想，如果你要改一个模块，结果连带你其它模块也要改，那你岂不头大。特别有些系统是以集群方式合作的，耦合度高的系统很容易牵一发而动全身。
2、定义实体关系的原则
当定义一个实体与其他实体之间的关系时，需要考量如下：
（1）牵涉到的实体识别出关系所涉及的所有实体。
（2）所有权考虑一个实体“拥有”另一个实体的情况。
（3）基数考量一个实体的实例和另一个实体实例关联的数量。
3、关系与表数量
描述 1:1 关系最少需要 1 张表。
描述 1:n 关系最少需要 2 张表。
描述 n:n 关系最少需要 3 张表。
4、列意味着唯一的值
如果表示坐标（0,0），应该使用两列表示，而不是将“0,0”放在 1 个列中。
5、列的顺序
列的顺序对于表来说无关紧要，但是从习惯上来说，采用“主键 + 外键 + 实体数据 + 非实体数据”这样的顺序对列进行排序显然能得到比较好的可读性。
6、定义主键和外键
数据表必须定义主键和外键（如果有外键）。定义主键和外键不仅是关系数据库管理系统的要求，同时也是开发的要求。几乎所有的代码生成器都需要这些信息来生成常用方法的代码（包括 SQL 文和引用），所以，定义主键和外键在开发阶段是必须的。之所以说在开发阶段是必须的是因为，有不少团队出于性能考虑会在进行大量测试后，在保证参照完整性不会出现大的缺陷后，会删除掉数据库的的所有外键，以达到最优性能。当然，很多人建议在性能没有出现问题时应该保留外键，而即便性能真的出现问题，也应该对 SQL 文进行优化，而非放弃外键约束。