Relacionamentos do Dashboard
Visualização
Este recurso está em Pré-lançamento público.
Os relacionamentos do dashboard permitem definir um modelo semântico com escopo para um AI/BI dashboard. Com os relacionamentos do dashboard, é possível criar modelos de dados complexos que abrangem várias tabelas de fatos e dimensões, especificando como os datasets do dashboard se relacionam entre si. Eles também permitem criar medidas reutilizáveis que abrangem várias tabelas de fatos ou outros datasets. Por exemplo, é possível fazer o join de tabelas de fatos de Pedidos, Remessas e Devoluções por meio de dimensões conformadas e definir medidas entre fatos no nível do modelo.
Em vez de fazer a pré-junção de dados em SQL ou duplicar a lógica de *join* entre *datasets*, os relacionamentos são modelados uma vez e utilizados em todas as visualizações no painel. Como os relacionamentos do painel criam um **gráfico** percorrível entre seus *datasets*, eles permitem fatiar campos e medidas com flexibilidade em qualquer *dataset* conectado.
Os relacionamentos do dashboard têm escopo de dashboard e não criam um objeto do Unity Catalog. Use-os para prototipagem, análise específica de dashboard ou quando você quiser iterar antes de promover a lógica para o Unity Catalog. Para métricas que devem ser governadas e compartilhadas entre dashboards, Genie Agents ou outras ferramentas, use views de métricas do Unity Catalog. Veja as visualizações de métricas do Unity Catalog. Para comparar os relacionamentos do dashboard com as outras opções de modelagem de dados nos dashboards de AI/BI, consulte Escolha a abordagem correta.
Para criar relacionamentos e medidas de dataset, consulte Criar relacionamentos de dashboard.
Quais problemas os relacionamentos resolvem?
Os relacionamentos do painel permitem análise multifato e multigranular sem junção prévia manual de dados. Antes dos relacionamentos, um autor que quisesse mostrar a receita de pedidos e o custo de remessas lado a lado, agrupados por região, tinha que pré-join ambas as tabelas de fatos à dimensão de região e agregar cuidadosamente para evitar a expansão. Essa lógica vivia em SQL, duplicada em cada dataset que precisava dela. Com os relacionamentos, o autor define a join uma vez. O mecanismo de consulta decide o que join em runtime, com base nos campos na visualização. Não há expansão, contagem dupla ou SQL duplicado.
Modelos de dados compatíveis
Os relacionamentos do dashboard realizam join em tempo de consulta entre tabelas com base na cardinalidade especificada do relacionamento. É possível fazer join de tabelas de fatos através de uma dimensão conformada, mas não diretamente umas às outras através de joins de muitos para muitos.
Os padrões suportados incluem esquemas Snowflake, em que uma tabela de fatos join uma cadeia de dimensões, e dimensões compartilhadas, em que duas tabelas de fatos join a mesma dimensão conformada. Caminhos de join ambíguos, em que uma tabela de fatos pode alcançar a mesma dimensão por mais de um caminho, e relacionamentos cíclicos não são suportados. Você pode resolver ambos ao atribuir um alias a uma dimensão ou tabela para que cada caminho de join seja distinto.
Por que a ordem dos campos é importante
O primeiro campo que você adiciona ancora a raiz do gráfico de query, e cada campo depois disso é resolvido em relação a essa raiz. O mecanismo de query percorre as arestas de muitos para um a partir da raiz e oferece apenas o que é acessível. Pode-se segmentar por qualquer dimensão em uma cadeia de relacionamentos de muitos para um, e pode-se obter medidas de qualquer tabela de fatos (cada tabela de fatos agrega-se independentemente e faz join nas dimensões compartilhadas). Qualquer coisa não acessível dessa forma está indisponível.
O caso mais comum é fatiar a medida de uma tabela de fatos pela coluna de outra tabela de fatos. As duas tabelas de fatos só se encontram na dimensão compartilhada, então o campo selecionado primeiro decide qual tabela de fatos é a raiz e, portanto, se as colunas da outra tabela de fatos são alcançáveis. A mesma coluna pode estar disponível ou indisponível dependendo de qual campo foi selecionado primeiro. Por exemplo, o modo de envio está indisponível quando se começa com a receita de pedidos, mas é um campo de agrupamento válido quando se começa com o modo de envio.