Relacionamentos do Dashboard
Visualização
Este recurso está em Pré-lançamento público.
Os relacionamentos de dashboard permitem modelar a lógica de join entre seus conjuntos de dados em dashboards AI/BI, para que você possa criar modelos de dados multi-fato, multi-granularidade e medidas reutilizáveis entre conjuntos de dados sem pré-unir os dados em SQL. Você modela o relacionamento uma vez e depois o usa em cada visualização no dashboard.
Quais problemas os relacionamentos resolvem?
Antes dos relacionamentos, um autor que desejava unir métricas de várias tabelas de fatos (por exemplo, orders.revenue e shipments.cost), agrupadas por região, tinha que pré-unir ambas as tabelas de fatos à dimensão da região e agregar cuidadosamente para evitar o fan-out, a duplicação de linhas que ocorre quando um join multiplica linhas em vez de correspondê-las um para um. Essa lógica de join estava no SQL, duplicada em cada dataset que precisava dela.
Com relacionamentos, o autor define o join uma vez. O engine de query decide o que fazer join em runtime, com base nos campos na visualização. Não há fan-out, dupla contagem, ou SQL duplicado.
Como funcionam os relacionamentos de dashboard?
É possível definir um relacionamento entre dois datasets de dashboard escolhendo um campo de join em cada um e definindo a cardinalidade, como muitos-para-um de uma tabela de fatos para uma dimensão. Os datasets relacionados então formam um gráfico navegável, e o mecanismo de query resolve os joins que cada visualização precisa no momento da query, de modo que filtros e medidas fluem pelos datasets conectados sem a pré-junção de dados em SQL.
Um modelo pode abranger várias tabelas de fatos que se encontram em dimensões compartilhadas, e uma dimensão pode se desdobrar em outras dimensões. A Figura 1 mostra um modelo com três tabelas de fatos unidas por quatro dimensões compartilhadas, duas das quais se desdobram em mais um nível.
Figura 1. Um modelo de relacionamento de dashboard abrange várias tabelas de fatos unidas por dimensões compartilhadas, com algumas dimensões em floco de neve um nível mais adiante. Mesmo uma dimensão em floco de neve como Geografia permanece acessível de cada tabela de fatos conectada.
Para criar relacionamentos e medidas de dataset, consulte Criar relacionamentos de dashboard.
Quais modelos de dados são compatíveis?
Os relacionamentos do painel realizam junções em tempo de query entre tabelas com base na cardinalidade especificada do relacionamento. É possível unir tabelas de fatos por meio de uma dimensão conforme (uma dimensão compartilhada por mais de uma tabela de fatos), mas não diretamente entre si por meio de junções de muitos para muitos.
A tabela a seguir descreve os padrões compatíveis e incompatíveis e como resolver padrões incompatíveis quando eles ocorrem:
Padrão | Suportado | Como é | Resolução |
|---|---|---|---|
Esquema Snowflake | ✅ Sim | Uma tabela de fatos une uma cadeia de dimensões, por exemplo | Não é necessário. |
Dimensões compartilhadas | ✅ Sim | Duas tabelas de fatos fazem o join na mesma dimensão conformada, por exemplo | Não é necessário. |
Caminho de join ambíguo | ❌ Não | Uma dimensão alcançável de uma tabela de fatos por mais de uma rota, por exemplo, | Crie um alias para uma rota, por exemplo |
Relacionamento cíclico | ❌ Não | Um loop fechado de joins sem um único caminho inequívoco, por exemplo | Crie um alias para uma tabela no loop para quebrar o ciclo. |
Como resolvo caminhos de join ambíguos e cíclicos?
O aliasing funciona porque cada cópia com alias de uma tabela é um nó distinto no gráfico, então cada caminho de join leva a exatamente um destino. Os dois padrões não suportados criam cada um um tipo diferente de caminho duplicado, e o aliasing o remove.
Um caminho de join ambíguo ocorre quando uma tabela de fatos pode alcançar a mesma dimensão por mais de uma rota. Por exemplo, Orders alcança Country tanto por Regions quanto por Customers, portanto, uma query que agrupa pedidos por país tem dois joins candidatos e nenhuma maneira de escolher entre eles. Para resolvê-lo, crie um alias para a dimensão uma vez por rota, como Country (region) e Country (customer). Cada rota, então, aponta para sua própria cópia, de modo que um campo como país do cliente é resolvido para exatamente um caminho.
Figura 2. A criação de alias para a dimensão compartilhada atribui a cada rota seu próprio destino, de modo que o caminho de join seja inequívoco.
Um relacionamento cíclico é um loop fechado de joins. Se Orders se une a Regions, Regions se une a Customers, e Customers se une novamente a Orders, o loop não oferece ao engine de query um local inequívoco para começar ou parar, portanto, não consegue resolver os joins. Para resolvê-lo, crie um alias para uma tabela no loop para dividi-lo em um único caminho que o engine de query possa seguir de ponta a ponta. Na Figura 3, A, B e C representam quaisquer três tabelas em tal loop, e A′ é o alias que o interrompe.
Figura 3. O aliasing de uma tabela no loop quebra o ciclo em um único caminho percorrível.
Como as medidas entre datasets funcionam?
Quando as tabelas de fatos compartilham uma dimensão conformada, é possível definir uma medida uma vez no nível do modelo e fazer com que ela se baseie em mais de uma tabela de fatos. O mecanismo de query agrega cada tabela de fatos independentemente e combina os resultados na dimensão compartilhada, de modo que a medida permanece correta, independentemente dos campos que um visualizador adicione à visualização.
Por exemplo, com Orders, Shipments e Returns unidos através de dimensões compartilhadas, seria possível definir medidas entre datasets como estas no nível do modelo:
Net Revenue = SUM(Orders.revenue) - SUM(Returns.refund)
Fulfillment Rate = SUM(Shipments.units) / SUM(Orders.units)
Return Rate = SUM(Returns.units) / SUM(Orders.units)
Cada um deles se baseia em duas tabelas de fatos simultaneamente, sem fan-out ou dupla contagem. A Figura 1 mostra as dimensões compartilhadas nas quais ele se baseia, onde três tabelas de fatos se encontram em quatro dimensões conformadas.
Por que a ordem dos campos é importante
O primeiro campo adicionado define a raiz, a tabela contra a qual todos os outros campos são resolvidos. A partir dessa raiz, três tipos de campos se comportam de maneira diferente:
Tipo de campo | Atingível a partir de uma tabela não raiz? |
|---|---|
Campo (dimensão) | Sim, por meio de qualquer cadeia de muitos para um, independentemente do número de saltos. |
Medida (agregação) | Sim, ele agrega independentemente e, em seguida, se une à dimensão compartilhada. |
Coluna nativa (não agregada) | Não, a menos que essa tabela de fatos seja a raiz. |
Assim, começar de orders revenue torna customer region e shipments cost ambos disponíveis, mas não ship mode: uma coluna bruta em Shipments, inatingível porque Shipments não é a raiz. Comece em ship mode em vez disso, e a raiz inverte, então agora as colunas de Shipments também estão disponíveis.
Como os relacionamentos de painéis se comparam às métricas de view?
Ambos podem modelar o mesmo join gráfico, mas resolvem problemas diferentes:
- As view de métricas têm granularidade fixa. Pode-se fazer querys diretamente com SQL, e elas são adequadas para esquemas estrela e floco de neve.
- As relações do dashboard são de granularidade dinâmica. Eles permitem misturar e combinar campos e medidas de qualquer tabela no gráfico semântico, portanto, são mais adequados para modelagem em várias tabelas de fatos.
Um gráfico de relacionamento de dashboard pode incluir views de métricas como nós, com relacionamentos como as arestas que os conectam. A view de métricas lida com a lógica de grão único, e os relacionamentos lidam com a camada multi-fato por cima.
Aspecto | Relacionamentos do Dashboard | view de métricas |
|---|---|---|
Escopo | Um único dashboard | Unity Catalog, compartilhado entre dashboards, Genie Agents e outras ferramentas |
Melhor para | Prototipagem, análise específica de painéis, iteração rápida | Métricas que precisam ser governadas e reutilizadas consistentemente. |
Cria um objeto UC | Não | Sim |
Se você começar com um relacionamento de dashboard e mais tarde precisar que o mesmo modelo seja governado e compartilhado, poderá promovê-lo para uma view de métrica. Consulte views de métricas do Unity Catalog e Exportar para uma view de métricas do Unity Catalog. Para uma comparação mais ampla de todas as opções de modelagem de dados disponíveis em dashboards de AI/BI, consulte Escolha a abordagem correta.
Qual é a diferença entre granularidade fixa e granularidade dinâmica?
A granularidade afeta quais campos podem ser selecionados e o nível de detalhe em que são expressos. Uma view de métricas bloqueia uma tabela em uma granularidade fixa, como em nível de cliente, enquanto os relacionamentos são dinâmicos, com base nos campos usados no painel, como em nível de cliente, de pedido ou de remessa.
A diferença se resume à raiz. Uma view de métricas incorpora a raiz na dimensão no momento da definição: Customer é sempre a raiz, então cada query agrupa por Customer, e o seletor de campo sempre oferece apenas Customer como campo de agrupamento, mesmo que ainda extraia medidas de qualquer tabela de fatos conectada. Os relacionamentos do painel escolhem a raiz por query, em vez disso: Orders ou Shipments podem servir como raiz, dependendo de qual campo for adicionado primeiro, então o seletor de campo permite agrupar por qualquer uma das tabelas conectadas, em vez de apenas pela dimensão.
Figura 4. A raiz é fixa em uma view de métrica, mas escolhida por query em um relacionamento de dashboard.
Apesar dessa diferença, ambos compartilham o mesmo limite subjacente: você ainda não pode agrupar a medida de uma tabela de fatos diretamente pela coluna de outra tabela de fatos, porque as duas só se encontram na dimensão compartilhada.
Por que os relacionamentos do dashboard são delimitados a um dashboard?
O suporte para relacionamentos no Unity Catalog está em andamento.