重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
data-schema-knowledge-modeling by lyndonkl/claude
npx skills add https://github.com/lyndonkl/claude --skill data-schema-knowledge-modeling创建严谨、经过验证的实体、关系和约束模型,以实现正确的系统实现、知识表示和语义推理。
在以下场景中调用此技能:
常见触发短语:
数据模式与知识建模 是正式定义以下内容的过程:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
快速示例: 电子商务模式:
复制此清单并跟踪进度:
数据模式与知识建模进度:
- [ ] 步骤 1:收集领域需求和范围
- [ ] 步骤 2:识别实体和属性
- [ ] 步骤 3:定义关系和基数
- [ ] 步骤 4:指定约束和不变式
- [ ] 步骤 5:验证并记录模型
步骤 1:收集领域需求和范围
向用户询问领域描述、核心用例(此模式将支持哪些查询/操作)、现有数据(如果是迁移/集成)、性能/规模要求以及技术约束(SQL vs NoSQL vs 图数据库)。理解用例会塑造模型——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)模式
文档/NoSQL 模式
图模式(本体)
事件/时间序列模式
维度(数据仓库)模式
模式:实体生命周期建模 明确跟踪实体状态变化。示例:订单(草稿 → 待处理 → 已确认 → 已发货 → 已送达 → 已完成/已取消)。包含状态字段、每个状态的时间戳,如果需要历史记录,则包含转换表。
模式:软删除 从不物理删除记录——添加 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 - 交付前的质量评估何时选择哪种资源:
预期交付物: data-schema-knowledge-modeling.md 文件,包含:领域描述、包含属性和类型的完整实体定义、包含基数的关系映射、约束规范、图表(ERD/图可视化)、针对用例的验证以及实现说明。
常见模式表示法:
每周安装次数
45
代码仓库
GitHub 星标数
45
首次出现
Jan 24, 2026
安全审计
安装于
gemini-cli40
opencode40
cursor39
codex38
github-copilot37
claude-code36
Create rigorous, validated models of entities, relationships, and constraints that enable correct system implementation, knowledge representation, and semantic reasoning.
Invoke this skill when you need to:
Common trigger phrases:
Data schema & knowledge modeling is the process of formally defining:
Quick example: E-commerce schema:
Copy this checklist and track your progress:
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
Step 1: Gather domain requirements and scope
Ask user for domain description, core use cases (what queries/operations will this support), existing data (if migration/integration), performance/scale requirements, and technology constraints (SQL vs NoSQL vs graph database). Understanding use cases shapes the model - OLTP vs OLAP vs graph traversal require different designs. See Schema Types for guidance.
Step 2: Identify entities and attributes
Extract nouns from requirements (those are candidate entities). For each entity, list attributes with types and nullability. Use resources/template.md for systematic entity identification. Verify each entity represents a distinct concept with independent lifecycle. Document entity purpose and examples.
Step 3: Define relationships and cardinality
Map connections between entities (one-to-one, one-to-many, many-to-many). For many-to-many, identify junction tables/entities. Specify relationship directionality and optionality (can X exist without Y?). Use resources/methodology.md for complex relationship patterns like hierarchies, polymorphic associations, and temporal relationships.
Step 4: Specify constraints and invariants
Define uniqueness constraints, foreign key relationships, check constraints, and business rules. Document domain invariants (rules that must ALWAYS be true). Identify derived/computed attributes vs stored. Use resources/methodology.md for advanced constraint patterns and validation strategies.
Step 5: Validate and document the model
Create data-schema-knowledge-modeling.md file with complete schema definition. Validate against use cases - can the schema support required queries/operations? Check for normalization (eliminate redundancy) or denormalization (optimize for specific queries). Self-assess using resources/evaluators/rubric_data_schema_knowledge_modeling.json. Minimum standard: Average score ≥ 3.5.
Choose based on use case and technology:
Relational (SQL) Schema
Document/NoSQL Schema
Graph Schema (Ontology)
Event/Time-Series Schema
Dimensional (Data Warehouse) Schema
Pattern: Entity Lifecycle Modeling Track entity state changes explicitly. Example: Order (draft → pending → confirmed → shipped → delivered → completed/cancelled). Include status field, timestamps for each state, and transitions table if history needed.
Pattern: Soft Deletes Never physically delete records - add deletedAt timestamp. Allows data recovery, audit compliance, and referential integrity. Filter WHERE deletedAt IS NULL in queries.
Pattern: Polymorphic Associations Entity relates to multiple types. Example: Comment can be on Post or Photo. Options: (1) separate foreign keys (commentableType + commentableId), (2) junction tables per type, (3) single table inheritance.
Pattern: Temporal/Historical Data Track changes over time. Options: (1) Effective/expiry dates per record, (2) separate history table, (3) event sourcing (store all changes as events). Choose based on query patterns.
Pattern: Multi-tenancy Isolate data per customer. Options: (1) Separate databases (strong isolation), (2) Shared schema with tenantId column (efficient), (3) Separate schemas in same DB (balance). Add tenantId to all queries if shared.
Pattern: Hierarchies Model trees/nested structures. Options: (1) Adjacency list (parentId), (2) Nested sets (left/right values), (3) Path enumeration (materialized path), (4) Closure table (all ancestor-descendant pairs). Trade-offs between read/write performance.
✓ Do:
✗ Don't:
Resources:
resources/template.md - Structured process for entity identification, relationship mapping, and constraint definitionresources/methodology.md - Advanced patterns: temporal modeling, graph ontologies, schema evolution, normalization strategiesresources/examples/ - Worked examples showing complete schema designs with validationresources/evaluators/rubric_data_schema_knowledge_modeling.json - Quality assessment before deliveryWhen to choose which resource:
Expected deliverable: data-schema-knowledge-modeling.md file containing: domain description, complete entity definitions with attributes and types, relationship mappings with cardinality, constraint specifications, diagram (ERD/graph visualization), validation against use cases, and implementation notes.
Common schema notations:
Weekly Installs
45
Repository
GitHub Stars
45
First Seen
Jan 24, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli40
opencode40
cursor39
codex38
github-copilot37
claude-code36