mz-ontology-design について
mz-ontology-design は、共有セマンティックレイヤーと用途別データ面を設計するチーム向けの Materialize データモデリングスキルです。raw、core、用途別データベースの境界を定め、粒度、識別子、時間、関係レジストリ、検証を扱います。
主な機能
- 01raw、core、用途別データベースの分離
- 02セマンティックオブジェクトの粒度と識別子の定義
- 03イベント時刻と有効時刻の区別
- 04関係の登録と検証
- 05契約の文書化とテスト作成
活用シーン
- 01共有セマンティックグラフの設計
- 02属性を公開層か用途別層に配置
- 03ソース横断の識別子解決の設計
- 04関係の整合性とレイヤー依存の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ materializeinc/ agent-skills --skill mz-ontology-designインストール後、Claude Code で/mz-ontology-designを入力して読み込まれたか確認します。
同梱ファイルreferences/relationships.sql
詳細
Materialize オントロジー設計
ソースの形を保ったデータと、利用者ごとに異なる出力との間に、単一の正規セマンティックグラフを構築します。共有される意味はオントロジーに、表示方法やワークフローのポリシーは境界部分に置きます。
アーキテクチャ
共有の raw データベースと共有の core データベースを使用し、ユースケースごとにデータベースを1つ用意します。依存関係の方向は次のとおりにします。
raw.<source_system> -> core.<source_system> -> core.internal
|
v
core.public
|
v
<use_case>.<schema>
rawには、ソースの形を保った取り込みオブジェクトを格納します。ソーステーブルの識別情報を保持します。ソーステーブルを再作成すると、上流システムのスナップショットを再取得できます。core.<source_system>には、ソース内に限定された非公開の型付け、クリーンアップ、重複排除、命名を格納します。core.internalには、ソースをまたぐ非公開の統合と ID 解決を格納します。core.publicは文書化されたオントロジーであり、コンシューマーが読み取れる唯一のcoreスキーマです。- ユースケースごとに専用のデータベースを所有します。そのスキーマには、対象のアプリケーションやワークロード向けのプロジェクション、集計、スコア、フィルター、インデックスが含まれます。ユースケース間でデータベースを共有することはありません。
raw を読み取れるのは core だけです。各ユースケースのデータベースは core.public だけを読み取ります。命名規則だけに頼らず、権限付与と依存関係の検証によってこの境界を徹底します。
セマンティックオブジェクト
セマンティックオブジェクトとは、行の粒度、永続的な識別規則、明示的な時間の意味が文書化され、どのコンシューマーにも依存しない意味を持つ正規のリレーションです。次のいずれかを表します。
- エンティティ:識別情報を持つ永続的なもの。
- イベント:イベント ID とイベント時刻を持つ発生事象。
- 測定値:対象、メトリック、観測時刻における観測値。
- 関係オブジェクト:属性、根拠、履歴、または多対多の意味を持つ関連付け。
集計値、スコア、表示カテゴリ、レポート行、ソースのレプリカ、1対1のプロジェクションは、コンシューマーが必要としているというだけでセマンティックオブジェクトになるわけではありません。
公開オブジェクトを追加する前に、以下のすべてを満たす必要があります。
- 粒度と識別方法を曖昧さなく説明できます。
- 特定のダッシュボード、アラート、モデル、ワークフローに依存しない意味を持ちます。
- 複数のコンシューマーにとって有用であるか、別の公開オブジェクトの基盤となります。
- 属性は同じ粒度に属し、明確な出所があり、公開境界を通じて安全に公開できます。
ユースケースで不足しているデータが必要な場合は、まず既存オブジェクトに属性を追加するか、イベント、測定値、関係オブジェクトを追加するか、コンシューマー固有の派生データとして境界部分に残すかを判断します。非公開の境界を決して迂回してはいけません。
識別情報と時間
グローバルに意味を持つ場合は、不変の上流識別子を優先します。識別情報が親にスコープされる場合は、明示的な複合キーを使用します。ソースをまたぐ識別情報の解決は core.internal で一度だけ行い、データの系譜を追跡できるようソース識別子を保持します。永続的なキーが存在しない場合に限り、決定的な合成識別子を使用し、その入力と安定性の境界を文書化します。
ウェアハウスのセンチネルメンバーや、キーが符号化する内容と重複する代理ハッシュは公開しないでください。未解決、不一致、曖昧、解決済みの状態が重要な場合は、それぞれを明示的に表現します。
すべての公開オブジェクトで、現在の状態、不変のイベント、特定時点の測定値、有効期間付きの履歴のいずれを表すかを宣言します。解釈に複数の時刻が影響する場合は、イベント時刻、有効時刻、取り込み時刻を区別します。
パブリックオブジェクトとユースケースオブジェクト
各 core.public セマンティックオブジェクトは一度だけ定義し、ドメインを表す名詞で命名したうえで、変換コンピューティング上のマテリアライズドビューとして公開します。これにより、サービングクラスターはセマンティックグラフを再構築せずに、維持管理された結果を利用できます。
共有される意味を正規化します。各事実には正規の所有者を一つだけ設定します。非正規化されたコピーは、その導出が正規のものであり、関係のドキュメントで非正規化されていることが明示されている場合に限り許容されます。
ユースケースデータベースでは、1つ以上のスキーマにサーフェスを整理し、オントロジーをスター、ワイドテーブル、コホート、ランキング、スコア、アラート状態などに再構成できます。ただし、IDを再定義したり、共有概念の独立したバージョンを維持したりしてはなりません。変換コンピューティングとサービングコンピューティングは分離したままにします。所有権、分離、サイジング、可用性の要件に互換性がある場合、サービングワークロードはクラスターを共有できます。
リレーションシップ
次の2種類のリレーションシップを使用します。
- 参照エッジは、あるパブリックオブジェクトの列で表し、別のパブリックオブジェクトの1行を特定します。参照元側から見たカーディナリティは
many_to_oneまたはone_to_oneです。 - 関連付けに属性、時刻、根拠、信頼度、または多対多の意味がある場合、リレーションシップオブジェクトをパブリックセマンティックオブジェクトとします。関与するエンティティへの参照は、通常の参照エッジです。
ヒューリスティックな照合結果を外部キーのようなエッジとして公開しないでください。照合方法、ステータス、根拠、信頼度、有効時刻を持つリレーションシップオブジェクトとしてモデル化します。
core.public.relationships は、すべての参照エッジを機械可読形式で登録するレジストリです。作成時またはレビュー時には references/relationships.sql を参照してください。複合参照では列を位置順に記載し、オプションの場合はすべての列が NULL であるか、すべてが NULL 以外である必要があります。
コンパイル済みスキーマと照らし合わせてレジストリを検証します。リレーションシップ名が一意であること、オブジェクトと列が存在すること、列数と型が一致すること、参照先の列が一意キーを構成していること、必須参照に NULL や孤立行がないこと、one-to-one 参照が参照元側で一意であること、列挙値が有効であること、すべてのパブリック参照が登録されていることを確認します。
ドキュメントとテスト
コンシューマー向けの契約には comment on を使用します。各パブリックオブジェクトには、粒度、ID、時間的な振る舞い、意味、重要な除外事項を記載します。キー、タイムスタンプ、単位、状態フィールド、NULL 許容のリレーションシップ、機密フィールド、自明でない導出についてコメントします。解釈に影響する場合はセマンティックな来歴を含め、ソースの仕組み、結合の実装、パフォーマンスに関する注記は除外します。
実装に関する注記は SQL コメントに残します。パブリックキーの一意性と非 NULL 性、許容される状態、リレーションシップの整合性、粒度の維持、自明でないセマンティックルールをテストします。CI ではさらに、逆方向のレイヤー依存、ユースケースデータベースによるプライベートスキーマへのアクセス、ドキュメントのないパブリックオブジェクト、変換コンピューティング上のコンシューマーインデックスを拒否します。