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:

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

    Suppose that the logical table table_1 identifies col_1 as a primary key:

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

    When you define a relationship as table_2 (col_2) REFERENCES table_1 (col_1), col_1 must be a primary key, and col_2 must serve as a foreign key:

    • If multiple rows in table_2 use the same value in col_2, you’re creating a many-to-one relationship from table_2 to 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).

    • If each row in table_2 has a unique value in col_2, you’re creating a one-to-one relationship from table_2 to table_1.

      For example, customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) creates a one-to-one relationship from customer_details_extended to customer_details (one row of extended details for a customer belongs to one row of customer details with the key 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.

      For example, customer_details and customer_details_extended have a one-to-one relationship, where one row in customer_details is related to one row in customer_details_extended. A row-level expression on each of these tables refers to one specific customer. Each can refer directly to the other in row-level expressions because the row-level expressions are at the same granularity.

      As a corollary, a row-level expression on customer_details cannot reference a metric or aggregation of a row-level expression on customer_details_extended (and vice versa).

    • Aggregate-level expressions must refer to row-level expressions at the same granularity using a single aggregate.

      For example, aggregate-level expressions on customer_details or customer_details_extended must use a single aggregate when referencing the other entity. In addition, metrics on customer_details and customer_details_extended should refer to other metrics on the two entities directly, without any aggregation.

    These rules apply whether the relationship between the entities is defined as customer_details REFERENCES customer_details_extended or customer_details_extended REFERENCES customer_details.

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

    Note that one-to-one relationships respect transitivity when interacting with other one-to-one and many-to-one relationships:

    • If logical tables customers and customer_details have a one-to-one relationship and logical tables customer_details and customer_details_extended have a one-to-one relationship, logical tables customers and customer_details_extended are automatically inferred to have a one-to-one relationship and are treated as such during validation.

    • If logical tables customers and customer_details have a one-to-one relationship and logical tables customer_details and regions have a many-to-one relationship, customers is inferred to be transitively many-to-one to regions, which gives customers a higher granularity than regions during expression validation.

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

    Bemerkung

    Wenn es mehrere Pfade gibt, die zum Verknüpfen von zwei Tabellen verwendet werden können, sollten Sie für jeden Pfad eigene logische Tabellen und Beziehungen definieren. Weitere Informationen dazu finden Sie unter Definieren verschiedener logischer Tabellen für verschiedene Pfade, die zwei Tabellen verbinden.

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.

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

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.

Regeln für Metriken der Fensterfunktion

Diese Regeln gelten für Metriken der Fensterfunktion:

  • Metriken der Fensterfunktion können nicht für Berechnungen auf Zeilenebene (Fakten und Dimensionen) verwendet werden.

  • Metriken der Fensterfunktion können nicht in den Definitionen anderer Metriken verwendet werden.

Sprache: Deutsch