1.2.4　数据建模

我们使用的是关系型数据库，数据建模就是设计数据库的表结构，这项工作可以在功能设计之前，也可以在功能设计之后，也可以同时进行，不同的团队有不同的工作方式。一般来说，越是复杂、大型的系统，数据建模工作越重要，也越应该尽早进行。良好的数据库结构可以让数据流清晰，可以降低功能设计与开发的难度，特别是一旦发生了需求变更，可以灵活应对。对软件开发有点儿经验的人都知道，一旦软件投入使用，修改数据库结构是非常致命的。

1．实体关系

所谓实体，可以理解为可以看得见摸得着的事物的种类，如员工、供应商、原料等。注意，数据库设计所说的实体是事物的种类，不是个体，“员工”是一种实体，而“张三”只是这种实体下的一个实例。每一种实体都有若干属性信息，如“员工”实体，包含工号、身份证号码、生日等各种属性。

在进行数据库设计之前，首先要分析好本系统需要管理哪些实体，这些实体的关系如何。相信大部分读者都知道实体关系图（E-R图），这个工具就是用来分析实体关系的，本书以实战为宗旨，不会在这方面说得太多，但并不表示这方面的知识不重要，相反，在进行数据库设计时，它应该始终在脑中盘旋。

现实世界中实体之间的关系一般有三种：一对一、一对多、多对多。

一对一的关系：如果实体A与实体B是一对一的关系，那么表示实体A中的一个实例，在实体B中或者没有实例，或者只有唯一一个实例可以与之对应，并且，实体B中的一个实例，在实体A中也是或者没有实例，或者只有唯一一个实例可以与之对应。

一对多的关系：如果实体A与实体B是一对多的关系，那么表示实体A中的一个实例，在实体B中可以对应多个实例，而实体B中的一个实例，在实体A中只能对应一个实例。

多对多的关系：如果实体A与实体B是多对多的关系，那么表示实体A中的一个实例，在实体B中可以对应多个实例，而实体B中的一个实例，在实体A中也可以对应多个实例。

在现实业务中，一对一的关系其实非常少，一对多的关系也不多见，大部分情况下都是多对多的关系。

2．范式

所谓范式，是指数据库中的表满足的准则。

第一范式，所有表的属性（在数据库中，属性就是字段，这两者是同义词）不可分。这个大概是历史遗留问题，对于关系型数据库管理系统来说，表的属性都是不可分的。

第二范式，所有表的非主属性依赖于主属性。这个可以理解成所有表都需要有个关键字，只要有关键字自然就满足了第二范式。

第三范式，所有表的非主属性只依赖于主属性。这个可以理解成，所有非主属性不会依赖于其他非主属性。假设有个订单表管理销售订单，在这个表里面存储客户信息时（订单号为主属性，客户依赖于订单号），只要存储客户代号就可以了，不要把客户名称也存储在这里。

BC范式，这是第三范式的补充，针对那种主属性有多个字段的表，所有非主属性依赖于主属性，但不能只依赖于主属性的一部分字段。

在设计数据库时，一个重要的思想是，不能违反范式，如果违反范式，那么要有这么做的充足理由，并且对后果有清醒的认识。

3．数据库设计

数据库设计就是设计本软件在数据库中需要哪些表，这些表有什么关系，每个表包括哪些字段等。

表：表是根据实体设计的，但要知道，数据库中的表跟实体之间是有本质区别的，现实世界中的同一实体，在数据库设计时可能会根据业务要求设计多个表来表达它，因为在不同的业务场景中，需要处理、保存的属性信息区别很大；也有可能在现实世界中的多个实体，在数据库设计时只设计一个表来表达它，因为虽然这些实体牵涉到不同的业务场景，但需要处理、保存的属性信息相同。

表的关系：数据库中表的关系有两种，一对一与一对多。数据库中的表是没有多对多的直接关系的，一般情况下，现实业务中一个多对多的关系会被转换成数据库中的两个一对多的关系。数据库中表跟表之间的关系绝大部分都是一对多的关系，在数据库中通过在“多”表中建立外键（Foreign Key）来建立这种关系。一对一关系在数据库设计中出现得不多。

字段：对字段的处理比对表、关系的处理要简单得多，无非就是根据业务上需要处理的信息决定在表中设计哪些字段，根据信息的内容决定使用什么数据类型、需要的字段长度等。另外，即使字段设计出了问题，对未来工作的影响也小得多，一般不会像表与表关系出问题那样伤筋动骨。

数据字典：数据建模完成后，需要有文档对这个数据模型进行详细说明，这就是数据字典应该充当的角色。数据字典需要描述的内容主要包括：这个数据模型中有哪些表，每个表包括哪些字段，每个字段的类型、长度、取值范围是什么，哪些字段是外键关联字段，对字段值有没有什么特殊要求，等等。