Como o Snowflake valida as exibições semânticas

O Snowflake verifica a conformidade com um conjunto de regras de validação quando você define uma exibição semântica. Essas regras garantem que seu modelo semântico seja bem formado e funcione corretamente.

Essas regras são explicadas nas próximas seções:

Regras gerais de validação

As regras a seguir se aplicam às exibições semânticas em geral:

  • Elementos obrigatórios: uma exibição semântica deve definir pelo menos uma dimensão ou métrica.

    Por exemplo, sua exibição semântica TPC-H precisa de pelo menos uma dimensão (como customer_name) ou uma métrica (como order_average_value).

  • Chaves primárias e estrangeiras: nas definições de chave primária e estrangeira, você deve usar colunas físicas da tabela base ou expressões definidas em tabelas lógicas que se referem diretamente a uma coluna da tabela base (por exemplo, t1.fact AS t1.col).

    Por exemplo, no esquema TPC-H, você pode usar c_custkey como chave primária para a tabela customer e o_custkey como chave estrangeira na tabela orders. c_custkey e o_custkey são colunas nas tabelas base físicas.

  • Referências de alias de tabela: ao se referir a tabelas em relações ou expressões, você deve usar os aliases definidos.

    Por exemplo, se você definir o alias de tabela orders AS snowflake_sample_data.tpch.orders_table, deverá usar o alias de tabela orders (e não orders_table) nas definições de suas métricas.

    Se você não especificar um alias para uma tabela lógica, deverá usar o nome da tabela lógica em todas as expressões.

Regras de validação para relações

As regras a seguir se aplicam a relações em exibições semânticas:

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

  • Relações transitivas: o Snowflake deriva automaticamente as relações indiretas.

    Por exemplo, se você definir uma relação entre line_items e orders e outra relação entre orders e customer, o Snowflake entenderá que há também uma relação entre line_items e customer.

    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.

  • Nenhuma relação circular: você não pode definir relações circulares, mesmo por meio de caminhos transitivos.

    Por exemplo, você não pode definir uma relação de orders para customer e outra relação de customer para orders.

  • Nenhuma autorreferência: atualmente, uma tabela não pode fazer referência a si mesma (como uma hierarquia de gerentes de funcionários em que os funcionários podem fazer referência a outros funcionários como seus gerentes).

  • Restrições de relações de vários caminhos: você pode definir várias relações entre duas tabelas, mas há limitações.

    Por exemplo, se line_items estiver relacionado a orders por meio de order_key e de outra coluna, essas tabelas não poderão se referir às expressões semânticas uma da outra.

    Nota

    Se houver vários caminhos que possam ser usados para unir duas tabelas, defina tabelas lógicas e relacionamentos separados para cada caminho. Para obter mais informações, consulte Definição de tabelas lógicas diferentes para caminhos distintos que unem duas tabelas.

Regras de validação de expressões

As regras a seguir se aplicam a expressões semânticas em fatos, dimensões e métricas:

Regras gerais sobre expressões

As regras a seguir se aplicam às expressões semânticas em geral:

  • Tipos de expressão: dimensões e fatos são expressões em nível de linha (não agregadas), enquanto as métricas são expressões em nível de agregação.

    Por exemplo, customer_name é uma dimensão (nível de linha), enquanto order_average_value é uma métrica (nível de agregação).

  • Associação de tabelas: toda expressão semântica deve ser associada a uma tabela.

    Por exemplo, customer_name deve ser definido como customer.customer_name, e order_average_value como orders.order_average_value.

  • Referências à mesma tabela: as expressões podem se referir a colunas da tabela base ou a outras expressões na mesma tabela lógica usando nomes qualificados ou não qualificados.

    Por exemplo, na tabela orders, você poderia definir orders.shipping_month como

    • MONTH(o_shipdate) (usando o nome da coluna não qualificado)

    • MONTH(orders.o_shipdate) (usando o nome qualificado)

  • Limitações entre tabelas: as expressões não podem se referir a colunas da tabela base de outras tabelas ou expressões de tabelas lógicas não relacionadas.

    Por exemplo, customer.customer_name não pode fazer referência direta a uma expressão da tabela orders, a menos que haja uma relação entre elas. Para trabalhar com dados entre tabelas, você deve:

    1. Definir relações entre tabelas lógicas (por exemplo, entre customer e orders por meio de c_custkey).

    2. Definir um fato na tabela de origem (por exemplo, orders.total_value).

    3. Fazer referência a essas expressões a partir de uma tabela lógica conectada (por exemplo, customer.order_value pode fazer referência a orders.total_value).

  • Resolução de nomes: se tanto uma expressão semântica quanto uma coluna tiverem o mesmo nome, as referências a esse nome serão resolvidas para a expressão semântica.

    Por exemplo, se você definir uma dimensão region e houver também uma coluna region, region em expressões será resolvido para a dimensão, não para a coluna. Uma exceção acontece quando uma expressão se refere ao mesmo nome em sua definição (por exemplo, customer.c_name AS customers.c_name). A referência é resolvida para a coluna, e não para a própria expressão de definição.

  • Ciclos de referência de expressões: você não pode criar referências circulares entre expressões.

    Por exemplo, você não pode definir customer.total_value com base em orders.customer_value e, em seguida, definir orders.customer_value com base em customer.total_value.

  • Ciclos de referência de tabela: você não pode criar referências circulares entre tabelas lógicas em definições de expressão.

    Por exemplo, você não pode definir customer.total_value com base em orders.customer_value e, em seguida, definir orders.customer_count com base em customer.c_custkey.

  • Uso de funções: você pode usar funções escalares, como YEAR* / DAY* / WEEK* / MONTH / QUARTER, nas dimensões, mas as funções de tabela não são permitidas.

Regras para expressões em nível de linha (dimensões e fatos)

As regras a seguir se aplicam a expressões em nível de linha em dimensões e fatos:

  • Referências à mesma tabela: uma expressão em nível de linha pode se referir diretamente a colunas de sua própria tabela.

    Por exemplo, customers.customer_name pode ser definido diretamente como customers.c_name.

  • Granularidade igual ou inferior: uma expressão em nível de linha pode se referir diretamente a outras expressões em nível de linha com granularidade igual ou inferior.

    Por exemplo, orders.order_details pode se referir a customer.customer_name porque customer está em uma granularidade menor do que orders (um cliente pode ter muitos pedidos).

  • Referências de granularidade superior: ao fazer referência a expressões em nível de linha em uma granularidade superior, uma expressão em nível de linha deve usar agregação.

    Por exemplo, customer.total_orders deve usar COUNT(orders.o_orderkey) porque orders está em uma granularidade maior do que customer (um cliente pode ter muitos pedidos).

  • Referências agregadas: uma dimensão como orders.order_type não pode se referir a uma métrica como orders.order_average_value, mas customer.customer_segment pode se referir a orders.order_average_value porque customer está em uma granularidade menor do que orders (pedidos).

Regras para expressões em nível de agregação (métricas)

As regras a seguir se aplicam a expressões em nível de agregação nas métricas:

  • Agregação básica: uma métrica deve usar uma função de agregação.

    Por exemplo, orders.order_average_value deve usar AVG(orders.o_totalprice).

  • Granularidade igual ou inferior: ao se referir a expressões em nível de linha com granularidade igual ou inferior, uma métrica deve usar uma única agregação.

    Por exemplo, orders.total_value pode usar SUM(line_items.discounted_price) porque line_items está em uma granularidade menor do que orders (pedidos).

  • Referências de granularidade superior: ao fazer referência a expressões em nível de linha em uma granularidade superior, uma métrica deve usar a agregação aninhada.

    Por exemplo, customer.average_order_value deve usar AVG(SUM(orders.o_totalprice)) porque orders está em uma granularidade mais alta do que customer.

  • Outras referências agregadas: uma métrica pode se referir diretamente a outras métricas com granularidade igual ou inferior sem agregação.

    Por exemplo, orders.profit_margin pode ser definido como orders.total_revenue / orders.total_cost sem agregação adicional. No entanto, ao se referir a métricas de granularidade superior, é necessária uma agregação.

Regras para métricas de função de janela

Essas regras se aplicam a métricas de função de janela:

  • As métricas de função de janela não podem ser usadas por cálculos no nível da linha (fatos e dimensões).

  • As métricas de função de janela não podem ser usadas nas definições de outras métricas.

Linguagem: Português