data-modeling

数据建模

何时使用此技能

在以下情况下使用此技能：

• 数据建模任务 - 使用实体关系图（ERD）、数据字典以及概念/逻辑/物理模型进行数据建模。记录数据结构、关系和属性
• 规划或设计 - 需要数据建模方法方面的指导
• 最佳实践 - 希望遵循既定模式和标准

概述

使用实体关系图（ERD）、数据字典和结构化数据模型创建并记录数据结构。支持数据库设计和数据架构的概念、逻辑和物理建模层级。

什么是数据建模？

数据建模会创建数据元素及其关系的可视化和结构化表示。它记录：

• 实体：存储其相关数据的事物
• 属性：实体的特性
• 关系：实体之间的连接方式
• 约束：管理数据的规则

建模层级

层级	用途	受众	细节
概念	业务概念	业务用户	实体、高层级关系
逻辑	数据结构	分析师、设计人员	实体、属性、所有关系
物理	实现	开发人员、DBA	表、列、类型、索引

概念模型

业务概念的高层级视图：

• 仅包含主要实体
• 关键关系
• 不包含属性（或仅包含少量属性）
• 不包含技术细节

逻辑模型

与技术无关的数据结构：

• 所有实体和属性
• 主键和外键
• 包含基数的所有关系
• 已应用规范化
• 不包含物理实现细节

物理模型

针对特定数据库的实现：

• 表名（物理命名）
• 列名和数据类型
• 索引和约束
• 视图和存储过程
• 数据库特定功能

ERD 符号

实体（矩形）

实体表示存储其相关数据的事物。

┌─────────────────┐
│    CUSTOMER     │
├─────────────────┤
│ customer_id PK  │
│ name            │
│ email           │
│ created_at      │
└─────────────────┘

实体类型：

类型	描述	示例
强实体	独立存在	Customer、Product
弱实体	依赖于另一个实体	Order Line（依赖于 Order）
关联实体	解决 M:N 关系	Enrollment（Student-Course）

属性

类型	符号	描述
主键（PK）	带下划线/PK	唯一标识符
外键（FK）	FK	对另一个实体的引用
必填	* 或 NOT NULL	必须有值
可选	○ 或 NULL	可以为空
派生	/	根据其他属性计算得出
复合	{attrs}	由子属性组成
多值	[attr]	可以有多个值

关系（连线）

符号风格：

风格	使用场景
Chen	学术、概念建模
Crow's Foot	行业标准
UML	软件设计
IDEF1X	政府、结构化建模

Crow's Foot 符号：

符号	含义
──	一个（必需）
──○	零个或一个（可选）
──<	多个
──○<	零个或多个

基数

符号	含义	示例
1:1	一对一	Employee → Workstation
1:M	一对多	Customer → Orders
M:N	多对多	Students ↔ Courses

解读基数：

“一个[实体 A]有[min]..[max]个[实体 B]”

示例：“一个 Customer 有 0..多个 Orders”

工作流

阶段 1：识别实体

步骤 1：从需求中提取名词

根据业务需求，识别：

• 业务跟踪的事物
• 业务规则涉及的对象
• 数据的来源和目标

步骤 2：筛选候选项

保留	排除
独立概念	属性（实体的特征）
有多个实例的事物	同义词（同一概念的不同名称）
需要存储数据的事物	操作（动词，而非名词）

步骤 3：记录实体

## Entities

| Entity | Description | Example |
|--------|-------------|---------|
| Customer | Person or organization that purchases | John Smith, Acme Corp |
| Order | Purchase transaction | Order #12345 |
| Product | Item available for sale | Widget, Gadget |

阶段 2：定义属性

步骤 1：列出每个实体的属性

对于每个实体，确定：

• 我们需要了解该实体的哪些信息？
• 哪些信息可以唯一标识它？
• 业务会引用哪些数据？

步骤 2：对属性分类

属性	类型	必填	备注
customer_id	PK	是	代理键
email	唯一	是	业务键
name	字符串	是
phone	字符串	否	可选

步骤 3：识别键

• 主键（PK）：唯一标识符
• 自然键：具有业务意义的标识符
• 代理键：由系统生成的标识符
• 复合键：由多个属性组合而成

阶段 3：定义关系

步骤 1：识别关联

对于每一对实体：

• 它们之间是否存在业务关联？
• 这种关系的性质是什么？
• 基数是多少？

步骤 2：记录关系

## Relationships

| Relationship | From | To | Cardinality | Description |
|--------------|------|-----|-------------|-------------|
| places | Customer | Order | 1:M | Customer places orders |
| contains | Order | Product | M:N | Order contains products |

步骤 3：解决多对多关系

M:N 关系需要关联实体：

Student ──M:N── Course

Becomes:

Student ──1:M── Enrollment ──M:1── Course

阶段 4：规范化（逻辑模型）

范式：

范式	规则	违反示例
1NF	值原子化，不存在重复组	Phone1、Phone2、Phone3
2NF	不存在部分依赖	非键属性依赖于复合键的一部分
3NF	不存在传递依赖	非键属性依赖于非键属性
BCNF	每个决定因素都是候选键	候选键之间存在重叠

何时反规范化：

• 读取性能至关重要
• 报告/分析用例
• 数据仓库设计
• 经清晰的权衡分析证明合理

阶段 5：创建物理模型

步骤 1：映射到物理类型

逻辑类型	物理类型（PostgreSQL）	物理类型（SQL Server）
String(50)	VARCHAR(50)	NVARCHAR(50)
Integer	INTEGER	INT
Decimal(10,2)	NUMERIC(10,2)	DECIMAL(10,2)
Date	DATE	DATE
Timestamp	TIMESTAMP	DATETIME2
Boolean	BOOLEAN	BIT

步骤 2：定义约束

• 主键约束
• 外键约束
• 唯一约束
• 检查约束
• 默认值

步骤 3：规划索引

• 主键（自动创建）
• 外键（用于连接）
• 经常查询的列
• 用于提升性能的覆盖索引

输出格式

Mermaid ERD

erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : includes

    CUSTOMER {
        int customer_id PK
        string name
        string email UK
        date created_at
    }

    ORDER {
        int order_id PK
        int customer_id FK
        date order_date
        decimal total
        string status
    }

    ORDER_LINE {
        int order_id PK,FK
        int product_id PK,FK
        int quantity
        decimal unit_price
    }

    PRODUCT {
        int product_id PK
        string name
        string sku UK
        decimal price
        int stock_qty
    }

数据字典

## Data Dictionary

### CUSTOMER

| Column | Type | Null | Key | Default | Description |
|--------|------|------|-----|---------|-------------|
| customer_id | INT | No | PK | AUTO | Unique identifier |
| name | VARCHAR(100) | No | | | Customer full name |
| email | VARCHAR(255) | No | UK | | Contact email |
| phone | VARCHAR(20) | Yes | | NULL | Contact phone |
| created_at | TIMESTAMP | No | | NOW() | Record creation |

**Indexes:**
- `pk_customer` (customer_id) - Primary
- `uk_customer_email` (email) - Unique
- `ix_customer_name` (name) - Search

**Constraints:**
- Email format validation (CHECK)
- Name length minimum 2 characters

结构化数据（YAML）

data_model:
  name: "E-Commerce"
  version: "1.0"
  date: "2025-01-15"
  level: "logical"  # conceptual, logical, physical
  analyst: "data-modeler"

  entities:
    - name: "Customer"
      type: "strong"
      description: "Person or organization that makes purchases"
      attributes:
        - name: "customer_id"
          type: "integer"
          key: "primary"
          required: true
          generated: true

        - name: "email"
          type: "string"
          length: 255
          key: "unique"
          required: true

        - name: "name"
          type: "string"
          length: 100
          required: true

    - name: "Order"
      type: "strong"
      description: "Purchase transaction"
      attributes:
        - name: "order_id"
          type: "integer"
          key: "primary"
          required: true

        - name: "customer_id"
          type: "integer"
          key: "foreign"
          references: "Customer.customer_id"
          required: true

  relationships:
    - name: "places"
      from: "Customer"
      to: "Order"
      cardinality: "1:M"
      from_participation: "optional"  # 0..1
      to_participation: "mandatory"   # 1..M
      description: "Customer places orders"

  constraints:
    - entity: "Customer"
      type: "check"
      expression: "LENGTH(name) >= 2"
      description: "Name minimum length"

  indexes:
    - entity: "Order"
      name: "ix_order_date"
      columns: ["order_date"]
      purpose: "Date range queries"

叙述性摘要

## Data Model: E-Commerce

**Version:** 1.0
**Date:** [ISO Date]
**Level:** Logical

### Entity Summary

| Entity | Description | Key Relationships |
|--------|-------------|-------------------|
| Customer | Purchasers | Places Orders |
| Order | Transactions | Belongs to Customer, Contains Products |
| Product | Items for sale | Included in Orders |
| Order Line | Order details | Links Order to Product |

### Key Relationships

1. **Customer → Order (1:M)**
   - One customer can place many orders
   - Each order belongs to exactly one customer

2. **Order ↔ Product (M:N via Order Line)**
   - An order can contain many products
   - A product can appear in many orders

### Data Integrity Rules

1. Orders cannot exist without a customer
2. Order lines must reference valid order and product
3. Stock quantity cannot be negative
4. Email must be unique per customer

### Notes

- Consider partitioning Orders by date for large volumes
- Product price stored in Order Line for historical accuracy

常见模式

继承（子类型/超类型）

erDiagram
    PERSON ||--o| EMPLOYEE : "is a"
    PERSON ||--o| CUSTOMER : "is a"

    PERSON {
        int person_id PK
        string name
        string email
    }

    EMPLOYEE {
        int person_id PK,FK
        date hire_date
        decimal salary
    }

    CUSTOMER {
        int person_id PK,FK
        string company
        decimal credit_limit
    }

自引用

erDiagram
    EMPLOYEE ||--o{ EMPLOYEE : "manages"

    EMPLOYEE {
        int employee_id PK
        string name
        int manager_id FK
    }

审计跟踪

erDiagram
    ENTITY ||--o{ ENTITY_HISTORY : "has history"

    ENTITY {
        int id PK
        string data
        timestamp updated_at
    }

    ENTITY_HISTORY {
        int history_id PK
        int entity_id FK
        string data
        timestamp valid_from
        timestamp valid_to
        string changed_by
    }

集成

上游

• Requirements - 数据需求来源
• domain-storytelling - 领域概念
• process-modeling - 流程中的数据

下游

• Database design - 物理实现
• API design - 数据契约
• Integration - 数据交换

相关技能

• process-modeling - 数据的流程上下文
• journey-mapping - 客户数据触点
• decision-analysis - 数据驱动的决策
• capability-mapping - 支持能力的数据

版本历史

• v1.0.0（2025-12-26）：首次发布