Wie Snowflake semantische Ansichten validiert¶

Erforderliche Elemente: Eine semantische Ansicht muss mindestens eine Dimension oder Metrik definieren.

Zum Beispiel benötigt Ihre semantische Ansicht TPC-H mindestens eine Dimension (wie customer_name) oder eine Metrik (wie order_average_value).

Primär- und Fremdschlüssel: In den Primär- und Fremdschlüsseldefinitionen müssen Sie physische Basistabellenspalten oder in logischen Tabellen definierte Ausdrücke verwenden, die sich direkt auf eine Basistabellenspalte beziehen (z. B. t1.fact AS t1.col).

Im Schema TPC-H können Sie zum Beispiel c_custkey als Primärschlüssel für die Tabelle customer und o_custkey als Fremdschlüssel in der Tabelle orders verwenden. c_custkey und o_custkey sind Spalten in den physischen Basistabellen.

Tabellenalias-Referenzen: Wenn Sie in Beziehungen oder Ausdrücken auf Tabellen verweisen, müssen Sie deren definierte Aliasnamen verwenden.

Wenn Sie zum Beispiel den Tabellenalias orders AS snowflake_sample_data.tpch.orders_table definieren, müssen Sie den Tabellenalias orders (nicht orders_table) in den Definitionen Ihrer Metriken verwenden.

Wenn Sie keinen Alias für eine logische Tabelle angeben, müssen Sie den Namen der logischen Tabelle in allen Ausdrücken verwenden.

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

Angenommen, die logische Tabelle table_1 identifiziert col_1 als Primärschlüssel:

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

Wenn Sie eine Beziehung als table_2 (col_2) REFERENCES table_1 (col_1) definieren, muss col_1 ein Primärschlüssel sein und col_2 als Fremdschlüssel dienen:

• Wenn mehrere Zeilen in table_2 denselben Wert in col_2 aufweisen, erstellen Sie eine n:1-Beziehung zwischen table_2 und table_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).

• Wenn jede Zeile in table_2 einen eindeutigen Wert in col_2 hat, erstellen Sie eine 1:1-Beziehung zwischen table_2 und table_1.

  Beispiel: customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) erstellt eine 1:1-Beziehung zwischen customer_details_extended und customer_details (eine Zeile mit ausführlichen Details zu einem Kunden gehört zu einer Zeile mit Kundendetails mit dem Schlüssel c_custkey).

Validations performed on one-to-one relationships:

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

  Beispiel: customer_details und customer_details_extended haben eine 1:1-Beziehung, wobei sich eine Zeile in customer_details auf eine Zeile in customer_details_extended bezieht. Ein Ausdruck auf Zeilenebene in jeder dieser Tabellen bezieht sich auf einen bestimmten Kunden. Jede kann sich in Ausdrücken auf Zeilenebene direkt auf den anderen beziehen, da die Ausdrücke auf Zeilenebene die gleiche Granularität aufweisen.

  Entsprechend kann sich ein Ausdruck auf Zeilenebene zu customer_details nicht auf eine Kennzahl oder Aggregation eines Ausdrucks auf Zeilenebene zu customer_details_extended beziehen (und umgekehrt).

• Ausdrücke auf Aggregatebene - müssen sich auf Ausdrücke auf Zeilenebene mit derselben Granularität (bei einem einzigen Aggregat) beziehen.

  Zum Beispiel müssen Ausdrücke auf Aggregatebene zu customer_details oder customer_details_extended ein einziges Aggregat verwenden, wenn sie auf die andere Entität verweisen. Darüber hinaus sollten sich Kennzahlen für customer_details und customer_details_extended direkt auf andere Kennzahlen zu den beiden Entitäten beziehen, ohne eine Aggregation.

Diese Regeln gelten unabhängig davon, ob die Beziehung zwischen den Entitäten als customer_details REFERENCES customer_details_extended oder customer_details_extended REFERENCES customer_details definiert ist.

Transitive Beziehungen: Snowflake leitet automatisch indirekte Beziehungen ab.

Wenn Sie zum Beispiel eine Beziehung zwischen line_items und orders und eine weitere Beziehung zwischen orders und customer definieren, versteht Snowflake, dass es auch eine Beziehung zwischen line_items und customer gibt.

Beachten Sie, dass 1:1-Beziehungen die Transitivität respektieren, wenn Sie mit anderen 1:1- und n:1-Beziehungen interagieren:

• Wenn die logischen Tabellen customers und customer_details eine 1:1-Beziehung und die logischen Tabellen customer_details und customer_details_extended eine 1:1-Beziehung haben, wird für die logischen Tabellen customers und customer_details_extended automatisch eine 1:1-Beziehung abgeleitet, und sie werden bei der Validierung auch so behandelt.

• Wenn die logischen Tabellen customers und customer_details eine 1:1-Beziehung und die logische Tabellen customer_details und regions eine n:1-Beziehung aufweisen, leitet sich daraus ab, dass customers eine transitiv n:1-Beziehung zu regions aufweist, wodurch customers bei der Validierung von Ausdrücken eine höhere Granularität als regions erhält.

Keine zirkulären Beziehungen: Sie können keine zirkulären Beziehungen definieren, auch nicht durch transitive Pfade.

Sie können zum Beispiel nicht eine Beziehung von orders zu customer und eine andere Beziehung von customer zu orders definieren.

Keine Selbstreferenzen: Derzeit kann eine Tabelle nicht auf sich selbst verweisen (wie bei einer Hierarchie von Angestellten und Managern, bei der Angestellte auf andere Angestellte als ihren Manager verweisen können).

Einschränkungen für Mehrweg-Beziehungen: Sie können mehrere Beziehungen zwischen zwei Tabellen definieren, aber es gibt Beschränkungen.

Wenn zum Beispiel line_items sowohl über order_key als auch über eine andere Spalte mit orders verbunden ist, können diese Tabellen nicht auf die semantischen Ausdrücke der jeweils anderen Tabelle verweisen.