在做需求分析时，实体是抽象的笼统的概念，比如例子中的订单和商品是多对多，一个订单对应多个商品，一个商品可在多个订单中，这里的商品不是确定的某个商品（没有实例化），就是个笼统概念。

到了后面er图建模阶段，一个订单还是对应多个商品，但是一个确定的商品，只能属于一个订单（意思是我的这个订单里的某一个商品，不可能同时出现在其他的订单里），因此多对多变成了一对多关系。

1. 识别实体的属性。

2. 唯一标识

3. 存储特点。对增量大，不可能删数据的表，考虑分库分表存储。

需求分析

需求分析示例

1，我们接到一个项目：
首先要去分析这个项目有哪些模块--->然后针对具体模块分析有哪些属性--->针对属性分析哪个属性或哪几个属性的集合可以用来标识这个属性[唯一标识]------->分析这个模块数据是否永久存储，是否数据增长很快，是否经常查询---->如果是就要考虑分库分表了。如果不是，那么这些数据是否只会存储一定时间，是否需要永久记录--->如果是我们就定期归档及数据的迁移操作了。
如：注册用户表：
属性：用户名，密码，电话，邮箱，地址，昵称，头像，……
唯一标识： 邮箱？ 用户名+邮箱->md5加密来标识？……
存储特点：随系统上线时间逐渐增加，需要永久存储。 ---> 必须分库分表操作了。
如拟定2亿用户 可以分4个库，每个库100张表，每张表50w条记录。

2，分析这些模块之间的关联性：
1对1？ 1对多？ 多对多？ ---->画ER图。

比如，电子商务网站系统包括几个模块：用户模块，商品模块，订单模块，购物车模块，供应商模块。
记录注册用户信息
属性：用户名、密码、电话、邮箱、身份证号、地址、姓名、昵称。。。
可选唯一标识属性：用户名、身份证号、电话
存储特点：随系统上线时间逐渐增加，需要永久存储

实例关系举例：

举例：

实体：购物车信息

包括属性：用户名、商品编码、商品名称、数量、价格、加入世界

可选唯一标识属性：（用户名、商品编码、加入时间）、购物车编码

存储特点：不用永久存储（设置归档、清理规则）

举例：

实体：订单信息

包括属性：订单号、用户姓名、用户电话、收货地址、商品编码、商品名称、数量、价格、订单状态、支付状态、订单类型

可选唯一标识属性：订单号

存储特点：永久存储（分表、分库存储）

举例：

实体：商品信息

包括属性：商品编码、商品名称、商品描述、商品品类、供应商名称、重量、有效期、价格

可选唯一标识属性：商品名称、商品编码

存储特点：对于下线商品可以归档存储

举例：

实体：用户信息表

属性：用户名、密码、电话、邮箱、身份证号码、地址、姓名、昵称

可选唯一标识属性：用户名、身份证、电话

存储特点：随系统运行逐增，需永久存储

实例演示-用户模块

电子商务网站关系图

归档、清理

分表、分库

数据迁移，但不能删除

1. 属性

2. 唯一标识属性

3. 存储特点
   

分析实体之间的关系

分析模块的实体信息：

* 包括的属性

* 可选唯一标识属性

* 存储特点

电子商务网站关系

需求分析过程：（电子商务举例）

1. 模块划分：用户、商品、订单、购物车、供应商

2. 模块分析

   具体属性，可选唯一标识属性[组]，存储特点（永久、归档、分表分库）
   

3. 模块关系：一对一，一对多，多对多

存储特点：1.随系统上线时间逐渐增加，需要永久存储。

                 2.对下线商品可以归档存储。

                 3.永久存储（分表、分库存储）。

                 4.不用永久存储（设置归档、清理规则）。

设计表前的需求分析可以让我们知道:

1. 实体与实体之间的关系(1对1,1对多,多对多);

2. 实体的属性;

3. 实体属性中的唯一标识有哪些

4. 哪些数据不是核心的数据,有效的进行归档和删除;
   

电商网站逻辑模型图

分析：

• 模块

• 属性：字段

• 唯一标识：一个属性或者多个属性组合

• 存储特点：是否需要永久存储，是否要归档清理

• 关系
  

电子商务网站