data-schema-knowledge-modeling

数据架构与知识建模

目录

• 概述
• 工作流
• 架构类型
• 常见模式
• 防护措施
• 快速参考

概述

本技能正式定义实体、属性、关系、约束和基数，以生成明确无歧义的数据模型，防止不一致并支持正确实现。

**快速示例：**电商架构：

• 实体：用户、产品、订单、购物车、支付
• 关系：用户拥有多个订单；订单包含多个产品（通过 OrderItems）；用户拥有一个购物车
• 约束：电子邮箱必须唯一；订单总额必须等于 OrderItems 的总和；支付金额必须等于订单总额
• 结果：明确无歧义的模型，可防止数据不一致

工作流

复制此清单并跟踪进度：

Data Schema & Knowledge Modeling Progress:
- [ ] Step 1: Gather domain requirements and scope
- [ ] Step 2: Identify entities and attributes
- [ ] Step 3: Define relationships and cardinality
- [ ] Step 4: Specify constraints and invariants
- [ ] Step 5: Validate and document the model

步骤 1：收集领域需求并确定范围

请用户提供领域描述、核心用例（此模型将支持哪些查询／操作）、现有数据（用于迁移／集成时）、性能／规模要求，以及技术约束（SQL、NoSQL 还是图数据库）。了解用例有助于确定模型设计方向——OLTP、OLAP 和图遍历需要不同的设计。请参阅架构类型获取指导。

步骤 2：识别实体和属性

从需求中提取名词（这些是候选实体）。为每个实体列出属性、类型和是否可为空。使用 resources/template.md 系统地识别实体。确认每个实体都代表具有独立生命周期的独立概念。记录实体的用途和示例。

步骤 3：定义关系和基数

映射实体之间的联系（一对一、一对多、多对多）。对于多对多关系，识别关联表／实体。指定关系的方向性和可选性（X 是否可以脱离 Y 存在？）。对于层次结构、多态关联和时态关系等复杂关系模式，请使用 resources/methodology.md。

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

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

步骤 5：验证并记录模型

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

架构类型

根据使用场景和技术选择：

关系型（SQL）架构

• 最适用于： 事务型系统（OLTP）、强一致性、包含联接的复杂查询
• 模式： 规范化表、外键、ACID 事务
• 使用场景示例： 电商订单、银行交易、人力资源系统
• 关键决策： 规范化程度（为保持一致性采用 3NF，或为提升读取性能采用反规范化）

文档型/NoSQL 架构

• 最适用于： 结构灵活或不断演变、高写入吞吐量、反规范化读取
• 模式： 嵌套文档、内嵌关系、不使用联接
• 使用场景示例： 内容管理、用户资料、事件日志
• 关键决策： 内嵌还是引用（1 对少量时内嵌，1 对多时引用）

图架构（本体）

• 最适用于： 复杂关系、遍历查询、语义推理、知识图谱
• 模式： 节点（实体）、边（关系），两者均可带属性
• 使用场景示例： 社交网络、欺诈检测、推荐引擎、科学研究
• 关键决策： 属性图还是 RDF 三元组

事件/时序架构

• 最适用于： 审计日志、指标、IoT 数据、仅追加数据
• 模式： 不可变事件、按时间分区、聚合表
• 使用场景示例： 用户活动跟踪、监控、金融交易
• 关键决策： 原始事件还是预聚合摘要

维度（数据仓库）架构

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

常见模式

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

模式：软删除 绝不物理删除记录，而是添加 deletedAt 时间戳。这样可以恢复数据、满足审计合规要求并维护引用完整性。在查询中使用 WHERE deletedAt IS NULL 进行筛选。

模式：多态关联 实体与多种类型相关联。示例：评论可以属于帖子或照片。可选方案：（1）单独的外键（commentableType + commentableId）；（2）为每种类型设置联结表；（3）单表继承。

模式：时态/历史数据 跟踪随时间发生的变化。可选方案：（1）为每条记录设置生效/过期日期；（2）使用单独的历史表；（3）事件溯源（将所有更改存储为事件）。根据查询模式选择。

模式：多租户 按客户隔离数据。可选方案：（1）使用单独的数据库（隔离性强）；（2）使用带 tenantId 列的共享架构（效率高）；（3）在同一数据库中使用单独的架构（折中方案）。如果采用共享方式，所有查询都应添加 tenantId。

模式：层级结构 对树形/嵌套结构进行建模。可选方案：（1）邻接表（parentId）；（2）嵌套集（左/右值）；（3）路径枚举（物化路径）；（4）闭包表（所有祖先-后代对）。这些方案在读写性能方面各有取舍。

设计准则

✓ 应该：

• 从用例入手——架构应服务于查询和操作
• 先规范化，再针对特定性能需求进行反规范化
• 明确记录所有约束和不变量
• 使用有意义且一致的命名约定
• 考虑未来演进——设计时应考虑可扩展性
• 根据所有必需用例验证模型
• 准确建模现实世界（不要强行套用技术）

✗ 不应该：

• 脱离用例单独设计架构
• 过早优化（未经测量就进行反规范化）
• 跳过约束定义（这会导致数据损坏）
• 使用通用名称（data、value、thing）——应使用具体名称
• 忽略基数和可空性
• 在领域实体中建模实现细节
• 忘记规划从现有系统迁移数据的路径
• 在实体之间创建循环依赖

快速参考

资源：

• 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 Schema：包含验证规则的 API／文档结构
• SQL DDL：可执行的 CREATE TABLE 语句
• 本体（OWL/RDF）：语义网知识表示