snowflake-semanticview
作成者: github
Snowflake CLIを使用してSnowflakeのセマンティックビューを構築・検証し、DDL作成とテストをガイドします。セマンティックビューのライフサイクル全体(DDLの草案作成、Snowflakeテーブルメタデータからのシノニムとコメントの入力、CLIを介したSnowflakeでの検証、最終的なCREATEまたはALTER文の実行)を処理します。Snowflake CLIのインストールと接続設定は一度だけ必要で、検証を進める前に前提条件を確認します。一時ビューを使用して、すべてのDDLをSnowflakeに対して検証します...
npx skills add https://github.com/github/awesome-copilot --skill snowflake-semanticviewSnowflake Semantic Views
One-Time Setup
- Verify Snowflake CLI installation by opening a new terminal and running
snow --help. - If Snowflake CLI is missing or the user cannot install it, direct them to https://docs.snowflake.com/en/developer-guide/snowflake-cli/installation/installation.
- Configure a Snowflake connection with
snow connection addper https://docs.snowflake.com/en/developer-guide/snowflake-cli/connecting/configure-connections#add-a-connection. - Use the configured connection for all validation and execution steps.
Workflow For Each Semantic View Request
- Confirm the target database, schema, role, warehouse, and final semantic view name.
- Confirm the model follows a star schema (facts with conformed dimensions).
- Draft the semantic view DDL using the official syntax:
- Populate synonyms and comments for each dimension, fact, and metric:
- Read Snowflake table/view/column comments first (preferred source):
- If comments or synonyms are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval.
- Use SELECT statements with DISTINCT and LIMIT (maximum 1000 rows) to discover relationships between fact and dimension tables, identify column data types, and create more meaningful comments and synonyms for columns.
- Create a temporary validation name (for example, append
__tmp_validate) while keeping the same database and schema. - Always validate by sending the DDL to Snowflake via Snowflake CLI before finalizing:
- Use
snow sqlto execute the statement with the configured connection. - If flags differ by version, check
snow sql --helpand use the connection option shown there.
- Use
- If validation fails, iterate on the DDL and re-run the validation step until it succeeds.
- Apply the final DDL (create or alter) using the real semantic view name.
- Run a sample query against the final semantic view to confirm it works as expected. It has a different SQL syntax as can be seen here: https://docs.snowflake.com/en/user-guide/views-semantic/querying#querying-a-semantic-view Example:
SELECT * FROM SEMANTIC_VIEW(
my_semview_name
DIMENSIONS customer.customer_market_segment
METRICS orders.order_average_value
)
ORDER BY customer_market_segment;
- Clean up any temporary semantic view created during validation.
Synonyms And Comments (Required)
- Use the semantic view syntax for synonyms and comments:
WITH SYNONYMS [ = ] ( 'synonym' [ , ... ] )
COMMENT = 'comment_about_dim_fact_or_metric'
- Treat synonyms as informational only; do not use them to reference dimensions, facts, or metrics elsewhere.
- Use Snowflake comments as the preferred and first source for synonyms and comments:
- If Snowflake comments are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval.
- Do not invent synonyms or comments without user approval.
Validation Pattern (Required)
- Never skip validation. Always execute the DDL against Snowflake with Snowflake CLI before presenting it as final.
- Prefer a temporary name for validation to avoid clobbering the real view.
Example CLI Validation (Template)
# Replace placeholders with real values.
snow sql -q "<CREATE OR ALTER SEMANTIC VIEW ...>" --connection <connection_name>
If the CLI uses a different connection flag in your version, run:
snow sql --help
Notes
- Treat installation and connection setup as one-time steps, but confirm they are done before the first validation.
- Keep the final semantic view definition identical to the validated temporary definition except for the name.
- Do not omit synonyms or comments; consider them required for completeness even if optional in syntax.
githubのその他のスキル
console-rendering
github
Goにおける構造体タグベースのコンソールレンダリングシステムの使用手順
official
acquire-codebase-knowledge
github
ユーザーが既存のコードベースのマッピング、ドキュメント化、またはオンボーディングを明示的に依頼した場合にこのスキルを使用します。「このコードベースをマッピングして」「ドキュメント化して…」といったプロンプトで起動します。
official
acreadiness-assess
github
Run the AgentRC readiness assessment on the current repository and produce a static HTML dashboard at reports/index.html. Wraps `npx github:microsoft/agentrc…
official
acreadiness-generate-instructions
github
AgentRCのinstructionsコマンドを使用して、カスタマイズされたAIエージェント指示ファイルを生成します。.github/copilot-instructions.md(デフォルト、VS CodeのCopilotに推奨)を出力します…
official
acreadiness-policy
github
ユーザーがAgentRCポリシーを選択、作成、または適用するのを支援します。ポリシーは、関連性のないチェックを無効にしたり、影響度/レベルを上書きしたり、設定することで、レディネススコアリングをカスタマイズします。
official
add-educational-comments
github
コードファイルに教育的なコメントを追加し、効果的な学習リソースに変換します。説明の深さとトーンを、設定可能な3つの知識レベル(初心者、中級、上級)に適応させます。ファイルが提供されない場合は自動的にリクエストし、番号付きリストで素早く選択できます。教育的なコメントのみを使用してファイルを最大125%拡張します(ハードリミット:新しい行400行、1,000行を超えるファイルは300行)。ファイルのエンコーディング、インデントスタイル、構文の正確性を保持し、...
official
adobe-illustrator-scripting
github
ExtendScript(JavaScript/JSX)を使用して、Adobe Illustratorの自動化スクリプトの作成、デバッグ、最適化を行います。スクリプトを作成または修正して操作する際に使用します…
official
agent-governance
github
宣言的なポリシー、意図分類、および監査証跡により、AIエージェントのツールアクセスと動作を制御します。構成可能なガバナンスポリシーは、許可/ブロックされたツール、コンテンツフィルター、レート制限、承認要件を定義し、コードではなく設定として保存されます。セマンティック意図分類は、パターンベースのシグナルを使用して、ツール実行前に危険なプロンプト(データ流出、権限昇格、プロンプトインジェクション)を検出します。ツールレベルのガバナンスデコレーターは、関数にポリシーを適用します...
official