开始，数据库设计

2016-05-27 本文已影响1096人 ed407c8602e0

前言

还记得刚毕业时去面试，面试官问我，为什么要有数据库？感觉从刚开始接触开发时就开始接触数据库，从来没想过这个问题，突然被问到竟有点灯下黑的感觉。今天来回答这个问题，我可能会说：数据库是按照数据结构来组织、存储和管理数据的仓库。数据库具有高度的物理独立性和一定程度上的逻辑独立性，数据使用数据模型来描述，整体结构化。并且提供了数据安全性、完整性、并发控制、恢复等高级功能。由于马上要开始设计召唤猫项目（文章最后有介绍）的数据库表，我准备将数据库设计的东西再梳理下。本文主要针对的是关系型数据库，nosql数据库的扩展性超级爽，大家有空也可以看下。先介绍点必要的知识，然后开始设计数据库。

基础概念

只有了解了一些行话，才能更好的增进了解。下面解释一下一些基本概念。

实体懂面向对象的童鞋可以理解成对象，不懂的童鞋去学面向对象。值得注意的是实体也可以是指的一些抽象的东西，如友情，爱情，思维
属性实体的一些特征，如实体狗有眼睛，鼻子之类的属性。其实就是表的列
元组其实就是表的行, 即每条记录
码/键 可以唯一标识实体的属性，如身份证号标识一个人。不止一个，都叫候选码。如工号，身份证都可以标识一个人
主码/键 在候选码中任选一个
外码/键 属性不是本表的码，是其他表的码

范式

范式是数据设计的一些规范，越高的范式，冗余越小。范式如下

第一范式（1NF）
第二范式（2NF）
第三范式（3NF）
巴斯-科德范式（BCNF）
第四范式 ( 4NF）
第五范式（5NF）

第五范式已经被称为完美范式了，他冗余最小。那么是不是已经完美了呢？不然，其实就像我们对待冗余的态度，冗余越高，查询效率越高，冗余越低，插入和更新的效率越高。所以我们要根据实际业务来平衡，一般我们只需要满足第三范式即可。

第一范式

数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项

数据库设计起码要满足第一范式。每个属性都要是描述实体的最小原子。

第二范式

数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。

满足第二范式必须先满足第一范式。第二范式简单了说就是表中要有一个以上的码，设计表的时候加个主键吧，如果没有合适的属性，可以添加一个自增长的id。

第三范式

一个关系中不包含已在其它关系已包含的非主关键字信息

满足第三范式必须先满足第二范式。如同学和班级两张表，同学的id是同学表的主键。班级中可以有同学的id，但是不应该出现同学的名称，同学的眼睛等。

开始设计

基础的知识了解的差不多了，就可以开始设计数据库了。大致分为六个阶段

需求分析
概念设计
逻辑设计
物理设计
实施
维护

我需求采集的依据是项目的功能文档，数据库选型是Mysql。项目的前期主要工作集中在概念设计和逻辑设计。

概念设计&E-R图

概念设计阶段通过E-R图来描述你业务中所涉及的业务模型。掌握E-R图基本只要了解以下几点即可，要熟练需要自己试试。

矩形框：表示实体，在框中记入实体名
菱形框：表示联系，在框中记入联系名
椭圆形框：表示实体或联系的属性，将属性名记入框中。对于主属性名，则在其名称下划一下划线。
连线：实体与属性之间；实体与联系之间；联系与属性之间用直线相连，并在直线上标注联系的类型。

实体之间存在三种联系：一对一，一对多，多对多。这些需要在连线上标明。放个E-R图大家感受下。

这是个课程与教师之间的多对多关系。

逻辑设计

逻辑设计就是要把E-R图中的东西变成数据库中支持的数据模型，最后能变成数据库中的表就算大功告成。之前逻辑设计我会用Power Designer等工具，但是看过我文章的都知道我是懒惰的程序猿，我现在直接用Navicat中的建模工具，少下个软件，爽。

注意看红色的部分。表就是你的实体，属性就是你的列名，类型你得按照Mysql认识的来如：CHAR，INT。。。数据模型构建完毕，导出sql语句，执行sql，你就可以在你的数据库中看到你建的表了。好吧，说的好轻松，其实建表并不是那么轻松。

小技巧

如果你不是那么熟悉外键，可以不用外键
表名建议统一用大写或者小写
制定命名规范
字段最好不要可空
.....

小伙伴的智慧-召唤猫-拾壹月

关于召唤猫

召唤猫是一个参与&分享的项目，现在有一些小伙伴了。如果想做点有趣的产品的Android，iOS，服务端，前端，产品&设计（最爱）的小伙伴可以加入我们。由于我们的项目需要一定的参与度，伸手党请勿入。

项目代号：summoncat（召唤猫）
开发群：159443478