Wie Snowflake semantische Ansichten validiert¶

Ausdrucksarten: Dimensionen und Fakten sind Ausdrücke auf Zeilenebene (unaggregiert), während Metriken Ausdrücke auf Aggregatebene sind.

Zum Beispiel ist customer_name eine Dimension (Zeilenebene), während order_average_value eine Metrik (Aggregatebene) ist.

Tabellenzuordnung: Jeder semantische Ausdruck muss mit einer Tabelle verknüpft sein.

Zum Beispiel muss customer_name als customer.customer_name und order_average_value als orders.order_average_value definiert werden.

Referenzen auf dieselbe Tabelle: Ausdrücke können sich auf Spalten der Basistabelle oder andere Ausdrücke derselben logischen Tabelle beziehen, indem sie entweder qualifizierte oder unqualifizierte Namen verwenden.

In der Tabelle orders könnten Sie zum Beispiel orders.shipping_month definieren als

• MONTH(o_shipdate) (unter Verwendung des unqualifizierten Spaltennamens)

• MONTH(orders.o_shipdate) (unter Verwendung des qualifizierten Namens)

Tabellenübergreifende Beschränkungen: Ausdrücke können sich nicht auf Basistabellenspalten aus anderen Tabellen oder Ausdrücke aus nicht verwandten logischen Tabellen beziehen.

Zum Beispiel kann customer.customer_name nicht direkt auf einen Ausdruck aus der Tabelle orders verweisen, es sei denn, es besteht eine Beziehung zwischen ihnen. Um mit tabellenübergreifenden Daten zu arbeiten, müssen Sie:

1. Beziehungen zwischen logischen Tabellen definieren (z. B. zwischen customer und orders bis c_custkey).

2. Einen Fakt in der Quelltabelle definieren (z. B. orders.total_value).

3. Sich auf diese Ausdrücke aus einer zusammenhängenden logischen Tabelle beziehen (zum Beispiel kann sich customer.order_value auf orders.total_value beziehen).

Namensauflösung: Wenn sowohl ein semantischer Ausdruck als auch eine Spalte denselben Namen haben, werden Referenzen auf diesen Namen in den semantischen Ausdruck aufgelöst.

Wenn Sie zum Beispiel eine Dimension region definieren und es auch eine Spalte region gibt, wird region in Ausdrücken auf die Dimension aufgelöst, nicht auf die Spalte. Eine Ausnahme ist, wenn ein Ausdruck in seiner Definition auf denselben Namen verweist (zum Beispiel customer.c_name AS customers.c_name). Der Verweis wird auf die Spalte aufgelöst und nicht auf den definierenden Ausdruck selbst.

Ausdrucksreferenzzyklen: Sie können keine zirkulären Referenzen zwischen Ausdrücken erstellen.

Sie können zum Beispiel nicht customer.total_value auf der Grundlage von orders.customer_value und dann orders.customer_value auf der Grundlage von customer.total_value definieren.

Tabellenreferenz-Zyklen: Sie können keine zirkulären Referenzen zwischen logischen Tabellen in Ausdrucksdefinitionen erstellen.

Sie können zum Beispiel nicht customer.total_value auf der Grundlage von orders.customer_value definieren und dann orders.customer_count auf der Grundlage von customer.c_custkey.

Funktionsnutzung: Sie können skalare Funktionen wie YEAR* / DAY* / WEEK* / MONTH / QUARTER in Dimensionen verwenden, aber Tabellenfunktionen sind nicht erlaubt.

Referenzen auf dieselbe Tabelle: Ein Ausdruck auf Zeilenebene kann direkt auf Spalten aus seiner eigenen Tabelle verweisen.

Zum Beispiel kann customers.customer_name direkt als customers.c_name definiert werden.

Gleiche oder niedrigere Granularität: Ein Ausdruck auf Zeilenebene kann direkt auf andere Ausdrücke auf Zeilenebene mit der gleichen oder einer niedrigeren Granularität verweisen.

Zum Beispiel kann orders.order_details auf customer.customer_name verweisen, weil customer eine geringere Granularität hat als orders (ein Kunde kann viele Bestellungen haben).

Referenzen mit höherer Granularität: Wenn Sie Ausdrücke auf Zeilenebene mit höherer Granularität referenzieren, muss ein Ausdruck auf Zeilenebene eine Aggregation verwenden.

Zum Beispiel muss customer.total_orders COUNT(orders.o_orderkey) verwenden, weil orders eine höhere Granularität hat als customer (ein Kunde kann viele Bestellungen haben).

Aggregierte Referenzen: Eine Dimension wie orders.order_type kann sich nicht auf eine Metrik wie orders.order_average_value beziehen, aber customer.customer_segment kann sich auf orders.order_average_value beziehen, da customer eine niedrigere Granularität als Ordnungen hat.

Grundlegende Aggregation: Eine Metrik muss eine Aggregatfunktion verwenden.

Zum Beispiel muss orders.order_average_value AVG(orders.o_totalprice) verwenden.

Gleiche oder niedrigere Granularität: Wenn Sie sich auf Ausdrücke auf Zeilenebene mit gleicher oder niedrigerer Granularität beziehen, muss eine Metrik ein einzelnes Aggregat verwenden.

Zum Beispiel kann orders.total_value SUM(line_items.discounted_price) verwenden, weil line_items eine geringere Granularität als Aufträge hat.

Referenzen mit höherer Granularität: Wenn Sie sich auf Ausdrücke auf Zeilenebene mit höherer Granularität beziehen, muss eine Metrik eine verschachtelte Aggregation verwenden.

Zum Beispiel muss customer.average_order_value AVG(SUM(orders.o_totalprice)) verwenden, weil orders eine höhere Granularität hat als customer.

Andere aggregierte Referenzen: Eine Metrik kann ohne Aggregation direkt auf andere Metriken mit gleicher oder niedrigerer Granularität verweisen.

Zum Beispiel kann orders.profit_margin als orders.total_revenue / orders.total_cost ohne zusätzliche Aggregation definiert werden. Wenn Sie sich jedoch auf Metriken mit höherer Granularität beziehen, ist eine Aggregation erforderlich.