3. 数据建模基础与AWS映射

数据建模不是一次性画图，而是把业务语义逐层收敛为可落地的存储结构。在 AWS 上做数据建模，最容易犯的错误是跳过中间层：拿到需求就直接建 Redshift 表或 Glue 表，结果业务口径、粒度、主键关系全混在物理 DDL 里，后续变更代价极高。本节按“概念模型 → 逻辑模型 → 物理模型”三层推进，并说明关系型、维度、Data Vault 三种建模风格分别落在哪些 AWS 服务上。

三层模型各自回答什么问题

概念模型回答“业务里有哪些核心对象、它们之间是什么关系”。它不关心字段类型、不关心主键，只关心实体与联系。例如零售场景中，概念模型只出现“客户、订单、商品、门店”以及“客户下订单、订单含商品”这类关系。产出物通常是实体关系草图或业务术语表，用于和业务方对齐口径。

逻辑模型回答“每个实体有哪些属性、用什么键唯一标识、实体间是一对多还是多对多”。此时要确定主键、外键、基数与可选性，但仍不绑定具体数据库。例如订单与商品是多对多，逻辑层就必须引入“订单明细”这个关联实体，并明确其主键为（订单号，商品号）。逻辑模型是评审的重点，因为它决定了后续能否正确聚合。

物理模型回答“在具体引擎上怎么建表、怎么分区、怎么分布、怎么排序”。同一份逻辑模型，落到 Amazon Redshift、Amazon RDS 或 AWS Glue 表上，物理设计完全不同：Redshift 要考虑 DISTKEY、SORTKEY，RDS 要考虑索引与范式，Glue/Athena 要考虑分区列与文件格式。

关系型建模在 AWS 的落地

关系型建模以第三范式（3NF）为目标，核心是消除传递依赖。以订单为例，逻辑模型会拆成客户表、订单表、订单明细表、商品表，商品表再关联品类表。落到 Amazon RDS for PostgreSQL 时，直接写标准 DDL 并加外键约束即可：

CREATE TABLE orders (
  order_id     BIGSERIAL PRIMARY KEY,
  cust_id      BIGINT NOT NULL REFERENCES customers(cust_id),
  order_date   DATE   NOT NULL,
  amount       NUMERIC(12,2) NOT NULL
);
CREATE INDEX idx_orders_cust ON orders(cust_id);
CREATE INDEX idx_orders_date ON orders(order_date);

如果换成 DynamoDB，关系型思路要转成单表设计：用分区键 PK 和排序键 SK 表达一对多。例如 PK=CUST#1001、SK=ORDER#2024-05-01#A001，同一客户的所有订单物理上聚在一起，查询时用 Query 而非 Scan。这里的关键判断是：访问模式先于表结构确定，而不是先建表再想怎么查。

维度建模在 AWS 的落地

维度建模面向分析，典型结构是“事实表 + 维度表”。事实表存度量与维度外键，维度表存描述性属性。以销售分析为例，逻辑模型为：

• 事实表 fact_sales：order_id、date_key、product_key、store_key、quantity、sales_amount
• 维度表 dim_date：date_key、年、季、月、周、是否节假日
• 维度表 dim_product：product_key、sku、品类、品牌
• 维度表 dim_store：store_key、门店名、城市、区域

落到 Amazon Redshift 时，物理设计要显式指定分布与排序。事实表通常按 date_key 做 SORTKEY（时间范围过滤多），按 product_key 做 DISTKEY（与商品维度共置，减少重分布）：

CREATE TABLE fact_sales (
  order_id     BIGINT,
  date_key     INT,
  product_key  INT,
  store_key    INT,
  quantity     INT,
  sales_amount NUMERIC(12,2)
)
DISTSTYLE KEY
DISTKEY (product_key)
SORTKEY (date_key);

如果数据先落在 S3，用 Athena 查询，则物理模型体现为分区与列式格式：按 dt=2024-05-01/ 分区，文件用 Parquet，Glue Crawler 自动识别分区并注册到 Glue Data Catalog。此时“物理模型”就是分区键、文件格式和 SerDe 的组合。

Data Vault 在 AWS 的落地

Data Vault 2.0 把数据拆成三类组件：Hub 存业务键，Link 存实体间关系，Satellite 存描述属性与历史。它的优势是加载可并行、源系统变化时只需新增 Satellite，不必改 Hub。以客户与订单为例：

• hub_customer：customer_hash_key（业务键的哈希）、customer_bk、load_date、record_source
• hub_order：order_hash_key、order_bk、load_date、record_source
• link_cust_order：link_hash_key、customer_hash_key、order_hash_key、load_date
• sat_customer：customer_hash_key、load_date、hash_diff、name、phone、city

在 AWS 上，典型链路是：源库经 AWS DMS 或 Glue 抽取到 S3 原始区，Glue 作业计算业务键哈希并写入 Hub/Link/Satellite（Parquet 格式），再用 Redshift Spectrum 或 Glue 作业加载到 Redshift 供 BI 使用。判断加载是否正确，可以检查三点：同一业务键在 Hub 中是否只出现一次；Satellite 的 hash_diff 变化时是否新增一行而非覆盖；Link 是否完整记录了每次关系建立。

如何选择建模风格

实际项目中三者常组合使用：用关系型承载交易系统，用 Data Vault 做原始整合层，再在其上构建维度模型供 BI 消费。理解每一层回答的问题，才能在 AWS 上把模型放对位置。