Modelo relacional - Quick BI: Central de Documentação do Alibaba Cloud

Visão geral

A lógica de cálculo de um modelo relacional segue dois princípios fundamentais:

O cálculo utiliza apenas os campos da consulta atual e os campos associados. (Se uma consulta contiver campos de apenas uma tabela lógica, as outras tabelas lógicas do modelo relacional não serão incluídas no cálculo.)
O modelo preserva a integridade dos dados dos campos de medida.

Este diagrama ilustra o fluxo geral de processamento. Em comparação com joins físicos diretos, o modelo relacional evita eficazmente a expansão de dados:

Esta visão geral simplifica a lógica de processamento do modelo relacional. Na prática, fatores como cardinalidade, taxas de correspondência de dados e tipos de campo acionam diferentes métodos de processamento. Consulte os exemplos a seguir para obter detalhes.

Exemplos

Configuração do modelo

Campos das tabelas de dados

Tabela primária: Cases	Tabela secundária: Population

Estrutura do modelo relacional

Em que:

Chave de junção: Medical Institution = Medical Institution
Relacionamento de junção: N:N
Taxa de correspondência de dados: Partial Match: Partial Match

Configuração de gráfico e métodos de cálculo

Consulta de tabela única

Configuração do gráfico

Dimensão	Medical Institution (tabela Population), Year (tabela Population)
Medida	Sum of Population (tabela Population)

Dados resultantes

Consulta multitabelas (apenas dimensões)

Configuração do gráfico

Dimensão	Month (tabela Cases), Year (tabela Population)
Medida	-

Dados resultantes

Lógica de inner join

Ao usar um INNER JOIN: quando um gráfico contém apenas dimensões, somente os dados correspondentes são considerados significativos. Dados não correspondentes, como os das instituições médicas D e E, são ignorados.

O sistema une as duas tabelas pelo campo "Medical Institution" usando um INNER JOIN para criar uma tabela intermediária. Após a deduplicação, o sistema exibe os dados resultantes.

Institution (Cases)	Month (Cases)	Institution (Population)	Year (Population)
A	1	A	2020
A	1	A	2019
B	1	B	2020
B	1	B	2019
C	1	C	2020
C	1	C	2019
A	2	A	2020
A	2	A	2019
B	2	B	2020
B	2	B	2019
C	2	C	2020
C	2	C	2019
A	1	A	2020
A	1	A	2019

Consulta multitabelas (apenas medidas)

Configuração do gráfico

Dimensão	-
Medida	Sum of Number of Cases (tabela Cases), Sum of Population (tabela Population)

Dados resultantes

Lógica de cálculo

Quando uma consulta contém apenas medidas e nenhuma dimensão, a agregação produz uma única linha de dados.
Nesse cenário, o sistema agrega as medidas da Cases table e da Population table separadamente e depois anexa os resultados.

Consulta multitabelas (dimensões e medidas)

Exemplo 1: Dimensão da tabela esquerda, medida da tabela direita

Configuração do gráfico

Dimensão	Medical Institution (tabela Cases)
Medida	Sum of Population (tabela Population)

Dados resultantes

Etapas de cálculo

Etapa 1: A combinação de dimensões é calculada a partir do campo de dimensão no gráfico, Medical Institution (Cases table), e da chave de junção da tabela da medida, Medical Institution (Population table).

Como esta consulta inclui uma medida da Population table, esta etapa preserva todos os valores de dimensão dessa tabela. Isso garante a integridade da medida durante os cálculos subsequentes.

Institution (Population)	Institution (Cases)
A	A
B	B
C	C
E	-

Etapa 2: A combinação de dimensões é então unida à Population table para criar uma tabela intermediária. Como apenas a combinação de dimensões é unida e cada instituição médica é única dentro dela, não ocorre explosão de dados.

Institution (Population)	Institution (Cases)	Population (Population)
A	A	100
B	B	80
C	C	70
A	A	110
B	B	75
C	C	90
-	E	60
-	E	60

Etapa 3: Agrege a tabela intermediária pela dimensão usada no gráfico para obter o resultado final.

Como "Medical Institution E" da Population table não pôde ser correspondida a uma entrada na Cases table, o resultado contém uma linha em que a dimensão Medical Institution apresenta valor nulo.

Exemplo 2: Dimensão da tabela esquerda, medida da tabela direita (incorreto)

Configuração do gráfico

Dimensão	Year (tabela Cases)
Medida	Sum of Population (tabela Population)

Dados resultantes

Etapas de cálculo

Etapa 1: A combinação de dimensões é calculada a partir do campo de dimensão no gráfico, Year (Cases table), e da chave de junção da tabela da medida, Medical Institution (Population table). Para maior clareza, Medical Institution (Cases table) também aparece aqui.

Como esta consulta inclui uma medida da Population table, esta etapa preserva todos os valores de dimensão dessa tabela. Isso garante a integridade da medida durante os cálculos subsequentes.

Institution (Population)	Institution (Cases)	Year (Cases)
A	A	2019
A	A	2020
B	B	2020
C	C	2020
E	-	-

Nota

Na Cases table, "Medical Institution A" possui registros tanto para 2019 quanto para 2020. Como resultado, a combinação de dimensões contém duas linhas para "A" no campo Medical Institution (Population table).

Etapa 2: A combinação de dimensões é então unida à Population table para criar uma tabela intermediária.

Year (Cases)	Institution (Population)	Population (Population)
2019	A	100
2020	A	100
2020	B	80
2020	C	70
2019	A	110
2020	A	110
2020	B	75
2020	C	90
-	E	60
-	E	60

Nota

Unir as duas linhas duplicadas "A" na combinação de dimensões à Population table duplica os dados populacionais para "Medical Institution A", causando uma explosão de dados.

Etapa 3: A tabela intermediária é então agregada pela dimensão usada no gráfico para produzir o resultado final.

Nota

Neste cenário, ocorre uma explosão de dados mesmo ao usar um modelo relacional. Para evitar tais problemas, recomendamos o seguinte:

Configure as chaves de junção corretamente: Neste exemplo, defina tanto Medical Institution quanto Year como chave de junção composta. Isso evita a explosão de dados quando a tabela intermediária é gerada na Etapa 2.
Use dimensões e medidas da mesma tabela lógica quando consultas entre tabelas não forem necessárias: Neste exemplo, consultar Medical Institution e Population apenas da Population table produzirá os resultados corretos.

Exemplo 3: Dimensão da tabela direita, medida da tabela esquerda (incorreto)

Configuração do gráfico

Dimensão	Year (tabela Population)
Medida	Sum of Number of Covered Areas (tabela Cases)

Dados resultantes

Etapas de cálculo

Etapa 1: A combinação de dimensões é calculada a partir do campo de dimensão no gráfico, Year (Population table), e da chave de junção da tabela da medida, Medical Institution (Cases table). Para maior clareza, Medical Institution (Population table) também aparece aqui.

Como esta consulta inclui uma medida da Cases table, esta etapa preserva todos os valores de dimensão dessa tabela. Isso garante a integridade da medida durante os cálculos subsequentes.

Institution (Cases)	Institution (Population)	Year (Population)
A	A	2020
A	A	2019
B	B	2020
B	B	2019
C	C	2020
C	C	2019
D	-	-

Nota

Na Population table, as instituições médicas A, B e C possuem registros tanto para 2019 quanto para 2020. Isso faz com que duas linhas para "A", duas para "B" e duas para "C" apareçam na combinação de dimensões no campo Medical Institution (Cases table). A Instituição Médica E da tabela populacional não tem correspondência.

Etapa 2: A combinação de dimensões é então unida à Cases table para criar uma tabela intermediária.

Institution (Cases)	Year (Population)	Covered areas (Cases)
A	2020	1
A	2019	1
B	2020	1
B	2019	1
C	2020	2
C	2019	2
A	2020	1
A	2019	1
B	2020	1
B	2019	1
C	2020	2
C	2019	2
D	-	1
A	2020	1
A	2019	1

Nota

Unir as linhas duplicadas para as instituições médicas A, B e C na combinação de dimensões à Cases table duplica os dados de Number of Covered Areas, causando uma explosão de dados.

Etapa 3: A tabela intermediária é então agregada pela dimensão usada no gráfico para produzir o resultado final.

Nota

Esta consulta calcula incorretamente a soma de Number of Covered Areas para as instituições médicas A, B e C devido à duplicação. A causa e as recomendações são as mesmas do Exemplo 2.

Configure as chaves de junção corretamente: Defina Medical Institution e Year como chave de junção composta.
Use dimensões e medidas da mesma tabela lógica quando consultas entre tabelas não forem necessárias: Consulte Year e Number of Covered Areas apenas da Cases table.

Comparação com modelagem física

Em versões anteriores, o Quick BI usava modelagem física para conjuntos de dados. Essa abordagem fornece uma interface visual para configurar joins e mesclar várias tabelas em uma única tabela ampla.

Com a modelagem física, você deve definir explicitamente o tipo de junção, como left join, inner join ou full join. Isso exige compreensão profunda dos dados e pré-processamento para garantir integridade e unicidade. Caso contrário, há risco de problemas graves, como explosão de dados.

Um exemplo detalhado

Configuração do modelo

Campos das tabelas de dados

Tabela Cases	Tabela Population

Estrutura do modelo físico

Tabela ampla do modelo físico

Como o campo 'Medical Institution' contém valores não únicos, ocorre uma grave explosão de dados após a modelagem física. Por exemplo, na figura abaixo, a 'Population (Population table)' para 'Medical Institution' 'A' e 'Year (Population table)' '2019' é contada incorretamente três vezes.

Configuração e cálculo do gráfico

Exemplo 1

Configuração do gráfico

Dimensão	Medical Institution (tabela Cases)
Medida	Sum of Population (tabela Population)

Dados resultantes

Resultado correto

Exemplo 2

Configuração do gráfico

Dimensão	Year (tabela Cases)
Medida	Sum of Population (tabela Population)

Dados resultantes

Resultado correto

Desvantagens da modelagem física

Com a modelagem física, você deve validar a precisão do modelo. Quando os dados contêm valores não únicos ou estão ausentes, tome medidas extras para evitar erros de dados, tais como:

Use SQL para agregar dados não únicos antes de criar uma junção.
Use uma função LOD para especificar a granularidade de agregação e evitar cálculos incorretos.
Use SQL para complementar dados ausentes ou ajuste o tipo de junção para considerar lacunas nos dados e evitar perda de informações.

Essas operações exigem conhecimento em SQL, o que as torna difíceis para usuários de negócios não técnicos. O processo de modelagem física também é tedioso e complexo, exigindo verificação repetida dos resultados.

Na modelagem física, unir mais tabelas aumenta o risco de explosão de dados e dificulta a solução de problemas. Para minimizar as junções, geralmente se cria um modelo separado para cada cenário de análise. No entanto, isso leva à proliferação de conjuntos de dados à medida que os cenários aumentam, dificultando a governança e a manutenção ao longo do tempo.

Modelo relacional: casos especiais

Tratamento de campos entre tabelas

Um campo entre tabelas é um campo calculado que usa campos de várias tabelas lógicas. Ele não pertence a nenhuma tabela lógica individual e é categorizado separadamente no conjunto de dados.

Os cálculos de campos entre tabelas sempre envolvem múltiplas tabelas lógicas, e o resultado depende dos relacionamentos de junção determinados pelas medidas e dimensões da consulta. Devido a essa dependência, esses campos só podem ser calculados em um contexto de consulta específico, e seus dados no nível de detalhe não estão disponíveis para visualização prévia.

Campos entre tabelas pós-agregação

Crie um campo entre tabelas pós-agregação agregando primeiro os campos de tabelas únicas e, em seguida, usando-os em um cálculo aritmético entre tabelas (como adição, subtração, multiplicação ou divisão).

Por exemplo:

Para calcular este campo, o Quick BI primeiro calcula SUM([Number of people(Table of Numbers)]) da tabela de contagem de pessoas e SUM([Coverage Area(Medical institution)]) da tabela de casos, gerando as duas tabelas intermediárias a seguir:

Medical institution (case table)	SUM(Number of people (people count table))
A	210
B	155
C	160
-	120

Medical institution (case table)	SUM(Number of covered areas (case table))
A	3
B	2
C	4
D	1

O Quick BI então une essas duas tabelas intermediárias e realiza a divisão para calcular o resultado final.

Campos entre tabelas no nível de detalhe

Crie um campo entre tabelas no nível de detalhe usando campos de tabelas únicas em um cálculo entre tabelas no nível de detalhe antes de qualquer agregação.

Por exemplo:

Para calcular este campo, o Quick BI primeiro une a "tabela de casos" e a "tabela de contagem de pessoas" por suas chaves de junção para criar a seguinte tabela intermediária:

Medical institution (case table)	Number of covered areas (case table)	Medical institution (people count table)	Number of people (people count table)
A	1	A	110
A	1	A	100
B	1	B	75
B	1	B	80
C	2	C	90
C	2	C	70
A	1	A	110
A	1	A	100
B	1	B	75
B	1	B	80
C	2	C	90
C	2	C	70
A	1	A	110
A	1	A	100

O Quick BI então executa a divisão nesta tabela intermediária e agrega os resultados com base nas dimensões do gráfico para produzir o resultado final:

Tratamento de constantes

Em um modelo relacional, o Quick BI trata constantes (como texto simples ou literais numéricos) como campos entre tabelas, mas as calcula de forma diferente de outros campos entre tabelas.

Por exemplo, se você criar uma constante '1' em um conjunto de dados de modelo relacional, o campo aparecerá na categoria "Cross-Table Fields":

Constantes em cálculos de tabela única

Neste caso, o Quick BI trata a constante como um campo dentro daquela tabela lógica. O cálculo segue então o caminho de consulta de tabela única, conforme mostrado abaixo:

Constantes em cálculos multitabelas

Neste cenário, o tratamento da constante torna-se ambíguo. Associar a constante a diferentes tabelas produziria resultados de cálculo diferentes e poderia levar a resultados inesperados.

Nesta situação, o Quick BI trata a constante como um campo entre tabelas. A constante perde sua associação com dimensões em todas as tabelas e não participa da agregação. O efeito é mostrado abaixo: