Data Modeling

数据建模技能

目的

创建清晰的数据模型，记录数据结构、关系和业务规则，为系统设计与开发提供依据。

使用场景

• 设计新的数据库结构
• 记录现有数据以供分析
• 在 FRS 中定义数据需求
• 设计系统间集成
• 规划数据迁移

数据建模概念

实体关系图（ERD）

实体：存储其数据的对象或事物（例如，客户、订单、产品） 属性：实体的特性（例如，customer_name、order_date） 关系：实体之间的关联方式

关系类型

一对一（1:1） 示例：用户 ↔ 用户资料

• 一个用户恰好有一份资料
• 一份资料恰好属于一个用户

一对多（1:N） 示例：客户 → 订单

• 一个客户可以有多个订单
• 一个订单属于一个客户

多对多（M:N） 示例：产品 ↔ 类别

• 一个产品可以属于多个类别
• 一个类别可以包含多个产品
• 需要关联表／桥接表

基数表示法（乌鸦脚表示法）

||──────|| : One and only one (1:1)
||──────<  : One-to-Many (1:N)
>──────<   : Many-to-Many (M:N)
o|──────<  : Zero or one to Many
||──────o< : One to Zero or Many

ERD 示例

电商 ERD（Mermaid）

erDiagram
    CUSTOMER ||--o{ ORDER : places
    CUSTOMER {
        uuid customer_id PK
        string email UK
        string first_name
        string last_name
        string phone
        datetime created_at
    }
    ORDER ||--|{ ORDER_ITEM : contains
    ORDER {
        uuid order_id PK
        uuid customer_id FK
        string order_number UK
        decimal subtotal
        decimal tax
        decimal shipping
        decimal total
        string status
        datetime order_date
    }
    ORDER_ITEM {
        uuid item_id PK
        uuid order_id FK
        uuid product_id FK
        int quantity
        decimal unit_price
        decimal total_price
    }
    PRODUCT ||--o{ ORDER_ITEM : "included in"
    PRODUCT {
        uuid product_id PK
        string sku UK
        string name
        text description
        decimal price
        int stock_quantity
        string status
    }
    PRODUCT }|--|| CATEGORY : "belongs to"
    CATEGORY {
        uuid category_id PK
        string name
        uuid parent_id FK
    }

CRM ERD

erDiagram
    ACCOUNT ||--o{ CONTACT : has
    ACCOUNT ||--o{ OPPORTUNITY : has
    ACCOUNT {
        uuid account_id PK
        string name
        string industry
        string website
        int employee_count
        decimal annual_revenue
        uuid owner_id FK
    }
    CONTACT {
        uuid contact_id PK
        uuid account_id FK
        string first_name
        string last_name
        string email UK
        string phone
        string title
    }
    OPPORTUNITY }o--|| CONTACT : "primary contact"
    OPPORTUNITY {
        uuid opportunity_id PK
        uuid account_id FK
        uuid contact_id FK
        string name
        string stage
        decimal amount
        date close_date
        int probability
        uuid owner_id FK
    }
    LEAD {
        uuid lead_id PK
        string first_name
        string last_name
        string email
        string company
        string source
        int score
        string status
    }

数据字典

模板

属性	数据类型	大小	必填	默认值	描述	验证
customer_id	UUID	-	是	Auto-gen	唯一标识符	UUID 格式
email	VARCHAR	255	是	-	客户邮箱	有效邮箱
status	ENUM	-	是	'active'	账户状态	active、inactive、suspended

示例：订单实体

属性	类型	大小	必填	默认值	描述	规则
order_id	UUID	-	是	Auto	主键	唯一
order_number	VARCHAR	20	是	Generated	显示编号	格式：ORD-YYYYMMDD-XXXX
customer_id	UUID	-	是	-	Customer 的外键	必须存在
order_date	DATETIME	-	是	NOW()	下单时间	不能是未来时间
status	ENUM	-	是	'pending'	订单状态	pending、processing、shipped、delivered、cancelled
subtotal	DECIMAL	10,2	是	0.00	商品金额合计	>= 0
tax	DECIMAL	10,2	是	0.00	计算所得税额	>= 0
shipping_cost	DECIMAL	10,2	是	0.00	运费	>= 0
total	DECIMAL	10,2	是	-	最终总额	= subtotal + tax + shipping
shipping_address	JSON	-	是	-	收货地址	有效地址
billing_address	JSON	-	是	-	账单地址	有效地址
notes	TEXT	-	否	NULL	订单备注	最多 2000 个字符
created_at	DATETIME	-	是	NOW()	记录创建时间	不可变
updated_at	DATETIME	-	是	NOW()	最后修改时间	自动更新

规范化

第一范式（1NF）

• 消除重复组
• 每个单元格只包含一个值
• 每条记录都唯一

❌ 不佳：customer_phones = "123-456, 789-012" ✅ 良好：单独建立电话表，并包含 customer_id 外键

第二范式（2NF）

• 满足 1NF
• 不存在部分依赖（所有非键属性都依赖于整个主键）

第三范式（3NF）

• 满足 2NF
• 不存在传递依赖（非键属性不依赖其他非键属性）

❌ 不佳：订单包含 customer_email（它依赖 customer_id，而非订单） ✅ 良好：通过联接 Customer 表获取 customer_email

特定领域的数据模式

电商

• 带有变体的产品（每个变体对应一个 SKU）
• 层级化类别
• 购物车 → 订单转换
• 地址规范化
• 价格历史跟踪

ERP

• 会计科目表结构
• 多公司数据隔离
• 主数据（客户、供应商、产品）
• 带有日记账的交易表
• 审计追踪

CRM

• 潜在客户 → 联系人 → 客户账户转换
• 活动记录（电话、邮件、会议）
• 商机 → 报价 → 订单流程
• 营销活动 → 成员 → 响应跟踪

CDP

• 客户身份解析
• 事件／行为数据（时间序列）
• 用户画像属性（统一）
• 细分群体归属
• 同意状态跟踪

最佳实践

✅ 建议：

• 使用一致的命名约定（snake_case）
• 包含审计字段（created_at、updated_at、created_by）
• 明确定义主键
• 记录外键关系
• 包含数据类型和约束
• 考虑软删除与硬删除
• 为数据增长做好规划

❌ 不建议：

• 存储计算得出的值（性能需要时除外）
• 使用含义模糊的名称
• 不编写文档
• 忽略数据校验规则
• 忘记处理 NULL

工具

• Figma：可视化 ERD 设计
• Mermaid：在文档中创建基于代码的图表
• dbdiagram.io：快速创建 ERD
• Lucidchart：专业图表

后续步骤

完成数据建模后：

1. 与技术团队审查
2. 纳入 FRS 文档
3. 创建迁移脚本
4. 规划数据校验规则
5. 根据数据模型设计 API 契约

参考资料

• 数据库规范化（1NF、2NF、3NF）
• 实体关系建模
• 数据字典标准