数据库设计和路由设计

1.ER图

• 实体型：用矩形表示，矩形框内写明实体名
• 属性：用椭圆形或圆角矩形表示，并用无向边将其与相应的实体连接
• 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型,在E-R图中要明确表明1对多关系，1对1关系和多对多关系。
• 1对1关系在两个实体连线方向写1
• 1对多关系在1的一方写1，多的一方写N
• 多对多关系则是在两个实体连线方向各写N,M
• 小结：ER图可以更直观的反映出模型的属性和关联关系，为我们设计数据库提供了清晰的思维，需要多看，多动手实践。

2.UML-用例图

• 统一建模语言（UML是 Unified Modeling Language的缩写）是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
• 用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图。用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
• 用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
• 用例是参与者想要系统做的事情，用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
• 用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
• 元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
• 由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

2.1 用例之间的关系

• 包含关系：基本用例的行为包含了另一个用例的行为。
• 泛化关系：代表一般与特殊的关系。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
• 扩展关系：基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。
• 小结：用例图也是需要多看多练习才能更快更准确的理解清楚到底用户需要执行哪些操作。

3.数据库三范式

3.1 第一范式（1NF）

• 所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
• 在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

3.2 第二范式（2NF）

• 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。
• 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

3.3 第三范式（3NF）

• 第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。
• 小结：在数据库设计过程中，要严格按照 ER 图上给出的实体图结合数据库设计的三范式来设计数据库，然后进一步分析用户层面和系统层面的需要来添加指定的字段。

4.url设计

• 目录化：即/a/b/c则层级尽量明确，最好不超过三层
• 参数化，即index.php?a=1&b=2&c=3，参数不要太多
• 静态化，即index-2-3-4.html，则文件名不要太长
• 自定义，即/blog/url-design.html，则看文件名尽量做到看URL可预测网页的内容
• 设计 url 时可以将完整的链接写出来，是否能做到一目了然不会让人混乱。

总结：经过上周设计作品的数据库和路由有了深刻的认识：必须严格遵守 ER 图上的实体属性和关系图来设计，不可随意更改，然后就是路由的设计，如果不能很清晰的让人知道这个路由的左右是什么就需要调整，层次目录一定要清晰，各个功能点分开。