Snowflakeによるセマンティックビューの検証方法

Snowflake verifies that a semantic view complies with a set of validation rules when you define it. These rules ensure your semantic model is well-formed and will function correctly.

これらのルールについては、次のセクションで説明します。

一般的な検証ルール

以下のルールはセマンティックビュー全般に適用されます。

  • 必須要素： セマンティック・ビューでは、少なくとも 1 つのディメンジョンまたはメトリクスを定義する必要があります。

    例えば、 TPC-H セマンティックビューは、少なくとも1つのディメンジョン（customer_name のような）またはメトリクス（order_average_value のような）が必要です。

  • プライマリキーと外部キー： プライマリキーおよび外部キーの定義では、物理的なベーステーブル列、またはベーステーブル列を直接参照する論理テーブルで定義された式を使用する必要があります (例えば、 t1.fact AS t1.col)。

    たとえば、 TPC-H スキーマでは、 customer テーブルのプライマリキーとして c_custkey を、 orders テーブルの外部キーとして o_custkey を使用できます。c_custkey と o_custkey は物理ベーステーブルの列です。

  • テーブル・エイリアス参照： リレーションシップや式でテーブルを参照する場合は、定義されたエイリアスを使用する必要があります。

    例えば、テーブル・エイリアス orders AS snowflake_sample_data.tpch.orders_table を定義する場合、メトリクスの定義ではテーブル・エイリアス orders を使用する必要があります（orders_table は使用しないでください）。

    論理テーブルにエイリアスを指定しない場合、論理テーブル名を式で使用する必要があります。

リレーションシップの検証ルール

セマンティックビューのリレーションシップには以下のルールが適用されます。

  • 多対1の関係および1対1の関係: 関係は外部キー制約のように機能します。

    論理テーブル table_1 が col_1 を主キーとして識別しているとします。

    TABLES (
  table_1 AS my_table_1 PRIMARY KEY (col_1)
  ...

    table_2 (col_2) REFERENCES table_1 (col_1) として関係を定義する場合、 col_1 は主キーである必要があり、 col_2 は外部キーとして機能する必要があります。

    • table_2 の複数の行が col_2 の同じ値を使用する場合、 table_2 から table_1 への多対1の関係が作成されます。

      例えば、 orders (o_custkey) REFERENCES customers (c_custkey) は orders から customers への多対1の関係を作成します（キー c_custkey を持つ1人のカスタマーに複数の注文が属することができます）。

    • table_2 の各行が col_2 内に一意の値を持つ場合、 table_2 から table_1 への1対1の関係が作成されます。

      例えば、 customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) は customer_details_extended から customer_details への1対1の関係を作成します（カスタマーの拡張詳細の1行は、キー c_custkey を持つカスタマー詳細の1行に属します）。

  • 1対1の関係で実行される検証:

    • 行レベルの式 は、同じ（またはそれ以下の）粒度で他の行レベルの式を参照できます。

      例えば、 customer_details および customer_details_extended には1対1の関係があり、 customer_details の1行は customer_details_extended の1行に関連しています。これらの各テーブルの行レベルの式は、1人の特定のカスタマーを参照します。行レベルの式は同じ粒度にあるため、行レベルの式ではそれぞれが他方を直接参照できます。

      結果として、 customer_details の行レベルの式は、 customer_details_extended の行レベルの式のメトリックまたは集約を参照 できません （その逆も同様です）。

    • 集約レベルの式 は、単一の集約を使用して、同じ粒度で行レベルの式を参照する必要があります。

      例えば、 customer_details または customer_details_extended の集約レベルの式は他のエンティティを参照する場合、単一の集約を使用する必要があります。さらに、 customer_details および customer_details_extended のメトリックは集約されることなく、2つのエンティティの他のメトリックを直接参照する必要があります。

    これらのルールは、エンティティ間の関係が customer_details REFERENCES customer_details_extended または customer_details_extended REFERENCES customer_details として定義されているかどうかに関係なく適用されます。

  • 推移的リレーションシップ： Snowflakeは間接的なリレーションシップを自動的に導き出します。

    たとえば、 line_items と orders の間のリレーションシップと、 orders と customer の間のリレーションシップを定義した場合、Snowflake は line_items と customer の間のリレーションシップも理解します。

    1対1の関係は、他の1対1および多対1の関係と相互作用する場合に遷移性を尊重することに注意してください。

    • 論理テーブル customers および customer_details の間に1対1の関係があり、論理テーブル customer_details および customer_details_extended の間に1対1の関係がある場合、論理テーブル customers および customer_details_extended は自動的に1対1の関係を持つと推測され、検証中はそのように扱われます。

    • 論理テーブル customers および customer_details の間に1対1の関係があり、論理テーブル customer_details および regions の間に多対1の関係がある場合、 customers は regions に対して遷移的に多対1であると推測され、式の検証中に customers の粒度は regions よりも高くなります。

  • 循環的なリレーションシップの禁止: たとえ他動パスであっても、循環的なリレーションシップを定義することはできません。

    たとえば、 orders から customer へのリレーションシップと、 customer から orders へのリレーションシップを定義することはできません。

  • 自己参照の禁止: 現在、テーブルが自分自身をリファレンスすることはできません (従業員が他の従業員をマネージャーとして参照できる従業員マネージャーの階層のように)。

  • マルチパスのリレーションシップの制限: 2つのテーブル間に複数のリレーションシップを定義できますが、制限があります。

    例えば、 line_items が order_key と別の列の両方を通して orders に関連している場合、これらのテーブルはお互いの意味式を参照することはできません。

    注釈

    If there are multiple paths that can be used to join two tables, you should define these relationships and specify which path to use when defining a metric. For information, see 複数の関係パスが存在する場合における、メトリックの関係の指定.

式の検証ルール

以下のルールは、ファクト、ディメンジョン、およびメトリクスの意味式に適用されます。

式に関する一般規則

意味式全般には以下のルールが適用されます。

  • 式のタイプ： ディメンジョンとファクトは行レベル式 (未集約)、メトリクスは集約レベル式です。

    例えば、 customer_name はディメンジョン（行レベル）ですが、 order_average_value はメトリクス（集約レベル）です。

  • テーブルの関連付け: すべての意味式はテーブルに関連付けられなければなりません。

    例えば、 customer_name は customer.customer_name として、 order_average_value は orders.order_average_value として定義されなければなりません。

  • 同じテーブルのリファレンス: リファレンス式は、修飾名または非修飾名を使用して、ベーステーブル列または同じ論理テーブル上の他の式を参照できます。

    例えば、 orders テーブルで、 orders.shipping_month を次のように定義します。

    • MONTH(o_shipdate) (修飾されていない列名を使用)

    • MONTH(orders.o_shipdate) (修飾名を使用)

  • テーブル間の制限: 式は、他のテーブルのベーステーブル列や、リレーションシップのない論理テーブルの式を参照することはできません。

    例えば、 customer.customer_name は、両者の間にリレーションシップがない限り、 orders テーブルの式を直接リファレンスすることはできません。テーブルをまたいでデータを扱うには、次のことが必要です。

    1. 論理テーブル間のリレーションシップを定義します（たとえば、 c_custkey を通した customer と orders）。

    2. ソース・テーブルのファクトを定義します (例えば、 orders.total_value)。

    3. 接続論理表からこれらの式を参照します（例えば、 customer.order_value は orders.total_value を参照できます）。

  • 名前解決: 意味式と列が同じ名前の場合、その名前へのリファレンスは意味式に解決されます。

    例えば、 region ディメンジョンを定義し、 region 列もある場合、式の region は列ではなくディメンジョンに解決されます。例外は、式の定義で同じ名前を参照している場合です（例えば、 customer.c_name AS customers.c_name）。リファレンスは、定義式そのものではなく、列に解決されます。

  • 式のリファレンス・サイクル: 式間の循環リファレンスは作成できません。

    例えば、 orders.customer_value に基づいて customer.total_value を定義し、 customer.total_value に基づいて orders.customer_value を定義することはできません。

  • テーブル参照のサイクル: 式定義で論理テーブル間の循環リファレンスを作成することはできません。

    For example, you cannot define customer.total_value based on orders.customer_value and then define orders.customer_count based on customer.c_custkey.

  • 関数の使用: ディメンションでは YEAR* / DAY* / WEEK* / MONTH / QUARTER のようなスカラー関数を使用できますが、テーブル関数は許可されていません。

行レベル式 (ディメンジョンおよびファクト) のルール

以下のルールは、ディメンジョンおよびファクトの行レベル式に適用されます。

  • 同じテーブルのリファレンス: 行レベル式は、そのテーブルの列を直接参照することができます。

    例えば、 customers.customer_name は、 customers.c_name と直接定義することができます。

  • 同じ粒度またはそれ以下の粒度: 行レベル式は、同じかそれ以下の粒度の他の行レベル式を直接参照することができます。

    例えば、 customer は orders よりも粒度が小さいので、 orders.order_details は customer.customer_name をリファレンスすることができます（一人の顧客が多くの注文を持つことができます）。

  • より高い粒度のリファレンス: より高い粒度で行レベル式を参照する場合、行レベル式は集約を使用する必要があります。

    例えば、 orders は customer よりも粒度が高いので、 customer.total_orders は COUNT(orders.o_orderkey) を使わなければなりません（一人の顧客が多くの注文を持つことができます）。

  • 集約リファレンス: orders.order_type のようなディメンジョンは、 orders.order_average_value のようなメトリクスを参照できませんが、 customer はオーダーよりも粒度が低いため、 customer.customer_segment は orders.order_average_value を参照できます。

集約レベル式（メトリクス）のルール

以下のルールは、メトリクスの集約レベル式に適用されます。

  • 基本的な集約: 派生メトリックでないメトリックは、集約関数を使用する必要があります。

    例えば、 orders.order_average_value は AVG(orders.o_totalprice) を使わなければなりません。

  • 同等以下の粒度: 同等以下の粒度で行レベル式をリファレンスする場合、メトリクスは単一の集約を使用しなければなりません。

    例えば、 line_items はオーダーより粒度が低いので、 orders.total_value は SUM(line_items.discounted_price) を使うことができます。

  • より高い粒度のリファレンス: より高い粒度で行レベルの式をリファレンスする場合、メトリクスはネストされた集約を使用する必要があります。

    例えば、 orders は customer よりも粒度が高いので、 customer.average_order_value は AVG(SUM(orders.o_totalprice)) を使わなければなりません。

  • 他の集約リファレンス: メトリクスは、集約することなく、同じ粒度またはそれ以下の粒度の他のメトリクスを直接参照できます。

    例えば、 orders.profit_margin は、追加集約なしで orders.total_revenue / orders.total_cost と定義できます。ただし、より高い粒度のメトリクスをリファレンスする場合は、集計が必要です。

ウィンドウ関数メトリックのルール

これらのルールは :ref:`ウィンドウ関数メトリック <label-semantic_views_querying_window>`に適用されます。

  • ウィンドウ関数メトリックは、行レベルの計算（ファクトとディメンション）では使用できません。

  • ウィンドウ関数メトリックは、他のメトリックの定義では使用できません。