# 在 DynamoDB 中为关系数据建模的初始步骤
<a name="bp-modeling-nosql"></a>

**注意**  
NoSQL 设计需要不同于 RDBMS 设计的思维模式。对于 RDBMS，可以创建规范化数据模型，不考虑访问模式。以后出现新问题和查询要求后进行扩展。而在 Amazon DynamoDB 中，应先了解需要解决的问题，再开始设计架构。预先了解业务问题和应用程序使用案例是至关重要的。

要开始设计能够高效扩展的 DynamoDB 表，必须先采取几个措施，确定其需要的支持的运营和业务支持系统 (OSS/BSS) 所需的访问模式。
+ 对于新应用程序，查看有关活动和目标的用户案例。记录确定的各种使用案例，然后分析这些案例需要的访问模式。
+ 对于现有应用程序，分析查询日志以了解人们目前使用该系统的方式，以及键访问模式。

完成此过程后，应获得一个可能如下所示的列表。


**订单条目应用程序的访问模式**  

| 模式编号 | 访问模式说明 | 
| --- | --- | 
| 1 | 按员工 ID 查找员工详细信息 | 
| 2 | 按员工姓名查询员工详细信息 | 
| 3 | 查找员工电话号码 | 
| 4 | 查找客户电话号码 | 
| 5 | 获取客户在日期范围内的订单 | 
| 6 | 显示日期范围内的所有未结订单 | 
| 7 | 查看最近聘用的所有员工 | 
| 8 | 查找某个仓库中的所有员工 | 
| 9 | 获取某个产品在订单上的所有项目 | 
| 10 | 获取某个产品在所有仓库中的库存 | 
| 11 | 按客户代表获取客户 | 
| 12 | 按客户代表获取订单 | 
| 13 | 获取担任某个职位的员工 | 
| 14 | 按产品和仓库获取库存 | 
| 15 | 获取总产品库存 | 

实际应用程序的列表可能更长。这个列表代表生产环境中可能出现的查询模式复杂性的范围。

DynamoDB 架构设计的现代化方法使用面向聚合的原则，根据访问模式而不是严格的实体边界对数据进行分组。此方法考虑多种设计模式：
+ *单个表设计*：使用复合排序键、重载的全局二级索引以及相邻列表模式，在一个表中存储多种实体类型
+ *多表设计*：为具有独立操作特征和低访问相关性的实体使用单独的表，使用策略性 GSI 进行跨实体查询
+ *聚合设计*：在相关的数据始终一起访问时嵌入相关数据（订单 \$1 订单项目），或者为标识关系使用项目集合（产品 \$1 库存）

您应根据具体的访问模式、数据特征和运行要求来选择这些方法。可以使用这些元素构造数据，使得应用程序可以在表或索引上使用单个查询，检索对于给定访问模式所需的任何内容。

**注意**  
究竟是选择单表设计还是多表设计应视您的特定要求而定。当多个实体具有高访问相关性和相似的操作特征时，适合使用单表设计。当实体具有独立的操作要求、不同的访问模式或需要明确的操作边界时，则首选使用多表设计。本指南中的示例演示的是多表方法，其中采用了策略性聚合和逆规范化。

要使用 NoSQL Workbench for DynamoDB 来帮助可视化您的分区键设计，请参阅[使用 NoSQL Workbench 构建数据模型](workbench.Modeler.md)。