名称: 数据模式与知识建模描述: 在需要设计数据库模式、明确建模领域实体和关系、构建知识图谱或本体、创建API数据模型、定义系统边界和不变量、迁移数据模型、建立分类或层次结构时使用，当用户提到“模式”、“数据模型”、“实体”、“关系”、“本体”、“知识图谱”，或当需要形式化分散/不一致的数据结构时。

数据模式与知识建模

目的

创建严谨、验证的实体、关系和约束模型，以实现正确的系统实施、知识表示和语义推理。

何时使用

在需要时调用此技能：

为新应用程序设计数据库模式（SQL、NoSQL、图）
建模具有许多实体和关系的复杂领域
构建用于语义搜索/推理的知识图谱或本体
定义API数据模型和契约
创建分类或层次结构
建立数据治理和规范模型
迁移传统模式到现代架构
解决领域概念和关系中的歧义
实现跨系统的数据集成
记录系统不变量和业务规则

常见触发短语：

“为…设计一个模式”
“建模实体和关系”
“创建一个知识图谱”
“数据模型是什么？”
“定义本体”
“我们应该如何结构化这些数据？”
“映射…之间的关系”
“设计API数据模型”

它是什么

数据模式与知识建模是正式定义的过程：

实体 - 存在的事物（用户、产品、订单、组织）
属性 - 实体的特性（名称、价格、状态、创建时间）
关系 - 实体之间的连接（用户拥有订单、产品属于类别）
约束 - 规则和不变量（唯一电子邮件、价格>0、一个主地址）
基数 - 每种的数量（一对多、多对多）

快速示例： 电子商务模式：

实体：用户、产品、订单、购物车、支付
关系：用户有许多订单，订单包含许多产品（通过订单项），用户有一个购物车
约束：电子邮件必须唯一，订单总计匹配订单项总和，支付金额等于订单总计
结果：防止数据不一致的明确模型

工作流程

复制此检查清单并跟踪进度：

数据模式与知识建模进度：
- [ ] 步骤1：收集领域需求和范围
- [ ] 步骤2：识别实体和属性
- [ ] 步骤3：定义关系和基数
- [ ] 步骤4：指定约束和不变量
- [ ] 步骤5：验证和文档化模型

步骤1：收集领域需求和范围

向用户询问领域描述、核心用例（这将支持哪些查询/操作）、现有数据（如果迁移/集成）、性能/扩展要求和技术约束（SQL vs NoSQL vs 图数据库）。理解用例塑造模型 - OLTP vs OLAP vs 图遍历需要不同的设计。参见模式类型获取指导。

步骤2：识别实体和属性

从需求中提取名词（那些是候选实体）。为每个实体列出属性及类型和可空性。使用resources/template.md进行系统性实体识别。验证每个实体代表具有独立生命周期的独特概念。记录实体目的和示例。

步骤3：定义关系和基数

映射实体之间的连接（一对一、一对多、多对多）。对于多对多，识别连接表/实体。指定关系方向和可选性（X 能否在无 Y 时存在？）。使用resources/methodology.md获取复杂关系模式，如层次结构、多态关联和时间关系。

步骤4：指定约束和不变量

定义唯一约束、外键关系、检查约束和业务规则。记录领域不变量（必须始终为真的规则）。识别派生/计算属性 vs 存储属性。使用resources/methodology.md获取高级约束模式和验证策略。

步骤5：验证和文档化模型

创建 data-schema-knowledge-modeling.md 文件，包含完整的模式定义。根据用例验证 - 模式是否支持所需查询/操作？检查规范化（消除冗余）或反规范化（优化特定查询）。使用resources/evaluators/rubric_data_schema_knowledge_modeling.json进行自评估。最低标准：平均分 ≥ 3.5。

模式类型

根据用例和技术选择：

关系型（SQL）模式

最适合： 事务系统（OLTP）、强一致性、带连接的复杂查询
模式： 规范化表、外键、ACID事务
示例用例： 电子商务订单、银行交易、人力资源系统
关键决策： 规范化级别（3NF 用于一致性 vs 反规范化用于读取性能）

文档/NoSQL模式

最适合： 灵活/演进结构、高写入吞吐量、反规范化读取
模式： 嵌套文档、嵌入关系、无连接
示例用例： 内容管理、用户配置文件、事件日志
关键决策： 嵌入 vs 引用（嵌入用于一到少，引用用于一到多）

图模式（本体）

最适合： 复杂关系、遍历查询、语义推理、知识图谱
模式： 节点（实体）、边（关系）、两者上的属性
示例用例： 社交网络、欺诈检测、推荐引擎、科学研究
关键决策： 属性图 vs RDF三元组

事件/时间序列模式

最适合： 审计日志、指标、物联网数据、追加数据
模式： 不可变事件、基于时间的分区、聚合表
示例用例： 用户活动跟踪、监控、金融交易
关键决策： 原始事件 vs 预聚合摘要

维度型（数据仓库）模式

最适合： 分析（OLAP）、聚合、历史报告
模式： 事实表 + 维度表（星型/雪花模式）
示例用例： 商业智能、销售分析、客户360
关键决策： 星型模式（反规范化） vs 雪花模式（规范化维度）

常见模式

模式：实体生命周期建模 明确跟踪实体状态变化。示例：订单（草稿 → 待处理 → 已确认 → 已发货 → 已送达 → 已完成/已取消）。包括状态字段、每个状态的时间戳，如果需要历史，则包含转换表。

模式：软删除 从不物理删除记录 - 添加 deletedAt 时间戳。允许数据恢复、审计合规和引用完整性。在查询中过滤 WHERE deletedAt IS NULL。

模式：多态关联 实体关联到多种类型。示例：评论可以针对帖子或照片。选项：（1）单独的外键（commentableType + commentableId），（2）每种类型的连接表，（3）单表继承。

模式：时间/历史数据 随时间跟踪变化。选项：（1）每条记录的有效/到期日期，（2）单独的历史表，（3）事件溯源（将所有更改存储为事件）。根据查询模式选择。

模式：多租户 隔离每个客户的数据。选项：（1）单独数据库（强隔离），（2）共享模式带 tenantId 列（高效），（3）同一数据库中的单独模式（平衡）。如果共享，在所有查询中添加 tenantId。

模式：层次结构 建模树/嵌套结构。选项：（1）邻接表（parentId），（2）嵌套集（左/右值），（3）路径枚举（物化路径），（4）闭包表（所有祖先-后代对）。读/写性能权衡。

防护措施

✓ 做：

从用例开始 - 模式服务于查询/操作
首先规范化，然后为特定性能需求反规范化
显式文档化所有约束和不变量
使用有意义、一致的命名约定
考虑未来演进 - 为可扩展性设计
根据所有所需用例验证模型
准确建模真实世界（不要强迫适应技术）

✗ 不做：

脱离用例设计模式
过早优化（在测量前反规范化）
跳过约束定义（导致数据损坏）
使用通用名称（数据、值、东西） - 要具体
忽略基数和可空性
在领域实体中建模实现细节
忘记从现有系统的数据迁移路径
创建实体间的循环依赖

快速参考

资源：

resources/template.md - 实体识别、关系映射和约束定义的结构化过程
resources/methodology.md - 高级模式：时间建模、图本体、模式演进、规范化策略
resources/examples/ - 完整模式设计的示例，带有验证
resources/evaluators/rubric_data_schema_knowledge_modeling.json - 交付前质量评估

何时选择哪个资源：

简单领域（< 10 个实体） → 从模板开始
复杂领域或图/本体 → 学习方法论中的高级模式
需要查看示例 → 查看示例文件夹
交付给用户前 → 始终使用评分标准验证

预期交付物： data-schema-knowledge-modeling.md 文件，包含：领域描述、完整的实体定义（带属性和类型）、关系映射（带基数）、约束规范、图表（ERD/图可视化）、用例验证、和实施备注。

常见模式符号：

ERD（实体-关系图）：实体和关系的可视化表示
UML类图：面向对象的视图，带继承和关联
图图：用于图数据库的节点和边
JSON模式：带验证规则的API/文档结构
SQL DDL：可执行的 CREATE TABLE 语句
本体（OWL/RDF）：语义网知识表示

数据模式与知识建模Skill data-schema-knowledge-modeling