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

必須要素： セマンティック・ビューでは、少なくとも 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 は使用しないでください）。

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

Many-to-one relationships and one-to-one relationships: Relationships work like foreign key constraints.

論理テーブル 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の関係が作成されます。

  For example, orders (o_custkey) REFERENCES customers (c_custkey) creates a many-to-one relationship from orders to customers (many orders can belong to one customer with the key c_custkey).

• 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行に属します）。

Validations performed on one-to-one relationships:

• Row-level expressions can refer to other row-level expressions at the same (or lower) granularity.

  例えば、 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 に関連している場合、これらのテーブルはお互いの意味式を参照することはできません。