Wie Snowflake semantische Ansichten validiert

Wenn Sie eine semantische Ansicht definieren, prüft Snowflake, ob sie einer Reihe von Validierungsregeln entspricht. Diese Regeln stellen sicher, dass Ihr semantisches Modell wohlgeformt ist und korrekt funktioniert.

Diese Regeln werden in den nächsten Abschnitten erläutert:

Allgemeine Validierungsregeln

Die folgenden Regeln gelten für semantische Ansichten im Allgemeinen:

  • 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.

Validierungsregeln für Beziehungen

Die folgenden Regeln gelten für Beziehungen in semantischen Ansichten:

  • Viele-zu-eins-Beziehungen: Beziehungen funktionieren wie Fremdschlüsseleinschränkungen.

    Wenn Sie z. B. eine Beziehung als orders (o_custkey) REFERENCES customers (c_custkey) definieren, erstellen Sie eine Viele-zu-eins-Beziehung von orders zu customers (viele Bestellungen können zu einem Kunden gehören), wobei c_custkey ein Primärschlüssel sein muss.

  • 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.

  • 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.

  • Einschränkungen für Eins-zu-eins-Beziehungen: Eins-zu-eins-Beziehungen haben Beschränkungen.

    Nehmen Sie beispielsweise an, dass Sie eine Beziehung orders(id) REFERENCES order_summary definieren, bei der id ein Primärschlüssel ist oder eindeutige Werte in orders hat. order_summary kann sich nicht auf semantische Ausdrücke in orders beziehen, orders kann sich jedoch auf semantische Ausdrücke in order_summary beziehen.

Ausdrucks-Validierungsregeln

Die folgenden Regeln gelten für semantische Ausdrücke in Fakten, Dimensionen und Metriken:

Allgemeine Regeln für Ausdrücke

Die folgenden Regeln gelten für semantische Ausdrücke im Allgemeinen:

  • 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.

  • Verwendung von Funktionen: Sie können skalare Funktionen wie YEAR* / DAY* / WEEK* / MONTH / QUARTER in Dimensionen verwenden, aber Tabellenfunktionen sind nicht erlaubt. Fensterfunktionen sind in Dimensionen und Fakten erlaubt, aber nicht in Metriken.

Regeln für Ausdrücke auf Zeilenebene (Dimensionen und Fakten)

Die folgenden Regeln gelten für Ausdrücke auf Zeilenebene in Dimensionen und Fakten:

  • 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.

Regeln für Ausdrücke auf Aggregatebene (Metriken)

Die folgenden Regeln gelten für Ausdrücke auf Aggregatebene in Metriken:

  • 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.

Sprache: Deutsch