data-schema-knowledge-modeling

データスキーマとナレッジモデリング

目次

• 概要
• ワークフロー
• スキーマの種類
• 一般的なパターン
• ガードレール
• クイックリファレンス

概要

このスキルでは、エンティティ、属性、リレーションシップ、制約、カーディナリティを正式に定義し、曖昧さのないデータモデルを作成します。これにより、不整合を防ぎ、正しい実装を可能にします。

簡単な例： E コマースのスキーマ：

• エンティティ：ユーザー、商品、注文、カート、決済
• リレーションシップ：ユーザーは複数の注文を持ち、注文には複数の商品が含まれます（OrderItems 経由）。ユーザーは 1 つのカートを持ちます。
• 制約：メールアドレスは一意であること、注文合計が 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：エンティティと属性を特定する

要件から名詞を抽出します（これらがエンティティの候補です）。各エンティティについて、属性、型、NULL 許容性を列挙します。体系的にエンティティを特定するには、resources/template.mdを使用してください。各エンティティが、独立したライフサイクルを持つ個別の概念を表していることを確認します。エンティティの目的と例を記録します。

ステップ 3：リレーションシップとカーディナリティを定義する

エンティティ間のつながり（一対一、一対多、多対多）をマッピングします。多対多の場合は、中間テーブルまたは中間エンティティを特定します。リレーションシップの方向性と任意性（Y がなくても X は存在できますか？）を指定します。階層、ポリモーフィックな関連付け、時間的リレーションシップなど、複雑なリレーションシップのパターンについては、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 トランザクション
• ユースケースの例： E コマースの注文、銀行取引、人事システム
• 重要な判断事項： 正規化のレベル（一貫性を重視する 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）同じ DB 内でスキーマを分ける（バランス型）があります。共有する場合は、すべてのクエリに tenantId を追加します。

パターン：階層構造 ツリーやネストされた構造をモデル化します。方法には、（1）隣接リスト（parentId）、（2）入れ子集合（left/right の値）、（3）パス列挙（マテリアライズドパス）、（4）クロージャーテーブル（すべての祖先と子孫のペア）があります。読み取り性能と書き込み性能の間でトレードオフがあります。

ガードレール

✓ 推奨事項：

• ユースケースから始めます。スキーマはクエリや操作に役立つものです
• まず正規化し、特定のパフォーマンス要件に応じて非正規化します
• すべての制約と不変条件を明示的に文書化します
• 意味が明確で一貫性のある命名規則を使用します
• 将来の拡張を考慮し、拡張性を備えた設計にします
• すべての必須ユースケースに照らしてモデルを検証します
• テクノロジーに無理に合わせず、現実世界を正確にモデル化します

✗ 避けるべき事項：

• ユースケースと切り離してスキーマを設計しないでください
• 早すぎる最適化を避けます（測定する前に非正規化しないでください）
• 制約定義を省略しないでください（データ破損につながります）
• 汎用的な名前（data、value、thing）ではなく、具体的な名前を使います
• 多重度と NULL 許容性を無視しないでください
• ドメインエンティティに実装の詳細を含めないでください
• 既存システムからのデータ移行経路を忘れないでください
• エンティティ間に循環依存関係を作らないでください

クイックリファレンス

リソース：

• resources/template.md - エンティティの特定、関係のマッピング、制約の定義を行うための構造化されたプロセス
• resources/methodology.md - 高度なパターン：時間モデリング、グラフオントロジー、スキーマの進化、正規化戦略
• resources/examples/ - 検証を含む完全なスキーマ設計の作成例
• resources/evaluators/rubric_data_schema_knowledge_modeling.json - 提供前の品質評価

リソースの選び方：

• シンプルなドメイン（エンティティが10未満）→ テンプレートから始めます
• 複雑なドメイン、またはグラフ／オントロジーを扱う場合 → 高度なパターンについて方法論を確認します
• 例を見たい場合 → examples フォルダーを確認します
• ユーザーに提供する前 → 必ずルーブリックで検証します

成果物の要件： data-schema-knowledge-modeling.md ファイルに、ドメインの説明、属性と型を含む完全なエンティティ定義、多重度を含む関係のマッピング、制約の仕様、図（ERD／グラフの可視化）、ユースケースに対する検証、実装メモを含めます。

一般的なスキーマ表記法：

• ERD（エンティティ関係図）：エンティティと関係の視覚的表現
• UML クラス図：継承と関連を含むオブジェクト指向のビュー
• グラフ図：グラフデータベースのノードとエッジ
• JSON Schema：検証ルールを含む API／ドキュメント構造
• SQL DDL：実行可能な CREATE TABLE 文
• オントロジー（OWL/RDF）：セマンティックウェブの知識表現