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.

    Suponha que a tabela lógica table_1 identifique col_1 como uma chave primária:

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

    Quando você define um relacionamento como table_2 (col_2) REFERENCES table_1 (col_1), col_1 deve ser uma chave primária e col_2 deve servir como chave estrangeira:

    • Se várias linhas em table_2 usam o mesmo valor em col_2, você está criando um relacionamento muitos para um de table_2 para 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).

    • Se cada linha em table_2 tiver um valor único em col_2, você vai criar um relacionamento um para um de table_2 para table_1.

      Por exemplo, customer_details_extended (e_custkey) REFERENCES customer_details (c_custkey) cria um relacionamento um para um de customer_details_extended para customer_details (uma linha de detalhes estendidos para um cliente pertence a uma linha de detalhes do cliente com a chave 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.

      Por exemplo, customer_details e customer_details_extended têm um relacionamento um para um, em que uma linha em customer_details está relacionada a uma linha em customer_details_extended. Uma expressão de nível de linha em cada uma dessas tabelas se refere a um cliente específico. Cada uma pode se referir diretamente à outra em expressões de nível de linha porque as expressões de nível de linha estão na mesma granularidade.

      Como corolário, uma expressão de nível de linha em customer_details não pode fazer referência a uma métrica ou agregação de uma expressão de nível de linha em customer_details_extended (e vice-versa).

    • Expressões de nível de agregado devem se referir a expressões de nível de linha na mesma granularidade usando um único agregado.

      Por exemplo, expressões de nível agregado em customer_details ou customer_details_extended devem usar um único agregado ao fazer referência à outra entidade. Além disso, as métricas em customer_details e customer_details_extended devem se referir a outras métricas nas duas entidades diretamente, sem qualquer agregação.

    Essas regras se aplicam independentemente de o relacionamento entre as entidades ser definido como customer_details REFERENCES customer_details_extended ou 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.

    Observe que os relacionamentos um para um respeitam a transitividade ao interagir com outros relacionamentos um para um e muitos para um:

    • Se as tabelas lógicas customers e customer_details têm um relacionamento um para um e as tabelas lógicas customer_details e customer_details_extended têm um relacionamento um para um, presume-se automaticamente que as tabelas lógicas customers e customer_details_extended têm um relacionamento um para um e são tratadas como tal durante a validação.

    • Se as tabelas lógicas customers e customer_details têm um relacionamento um para um e as tabelas lógicas customer_details e regions têm um relacionamento muitos para um, presume-se que customers tem um relacionamento muitos para um transitivo com regions, o que confere a customers uma granularidade maior do que regions durante a validação da expressão.

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

  • Basic aggregation: A metric that is not a derived metric must use an aggregate function.

    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