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

Snowflake verifies that a semantic view complies with a set of validation rules when you define it. These rules ensure your semantic model is well-formed and will function correctly.

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:

  • Relacionamentos muitos para um e relacionamentos um para um: os relacionamentos funcionam como restrições de chave estrangeira.

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

    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.

      Por exemplo, orders (o_custkey) REFERENCES customers (c_custkey) cria um relacionamento muitos para um de orders para customers (vários pedidos podem pertencer a um cliente com a chave 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).

  • Validações realizadas em relacionamentos um para um:

    • Expressões de nível de linha podem se referir a outras expressões de nível de linha na mesma granularidade (ou em uma granularidade inferior).

      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

    If there are multiple paths that can be used to join two tables, you should define these relationships and specify which path to use when defining a metric. For information, see Especificando o relacionamento de uma métrica quando há vários caminhos de relacionamento.

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.

    For example, you cannot define customer.total_value based on orders.customer_value and then define orders.customer_count based on 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 que não é uma métrica derivada 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.