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:

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

    Por exemplo, quando você define uma relação como orders (o_custkey) REFERENCES customers (c_custkey), está criando uma relação de muitos para um de orders para customers (muitos pedidos podem pertencer a um cliente), em que c_custkey deve ser uma chave primária.

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

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

  • Restrições de relações um para um: os relacionamentos individuais têm limitações.

    Por exemplo, suponha que você defina uma relação orders(id) REFERENCES order_summary, em que id é uma chave primária ou tem valores exclusivos em orders. order_summary não pode se referir a expressões semânticas em orders, embora orders possa se referir a expressões semânticas em order_summary.

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. As funções de janela são permitidas em dimensões e fatos, mas não em métricas.

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.

Linguagem: Português