Modelagem QlikView - Performance e Usabilidade

“As fontes e os dados terão de ser manipulados dentro do script para entregar o modelo de dados que melhor se adapte, para ambos performance e usabilidade importam.

Concatenar ou usar Tabela de Links?

  Para a maioria dos cenários a Concatenação é a melhor solução. É fácil de gerenciar, fácil de entender e demanda pouco esforço de desenvolvimento para pôr em prática.

• Concatenação vem com uma chave de restrição.

   Ela não garante a completa  rastreabilidade da transação .

   Selecionando SalesID, não serão correlacionados os registros da tabela Budget. Isto não é rigorosamente verdade, mas pode ser verdade em muitos cenários, e, portanto, poderia ser destacada como uma restrição.

• Tabelas de Link são um modelo mais tradicional, onde uma tabela de fatos substituto (link) é posto em prática para resolver todas as associações entre as tabelas de fatos e tabelas de dimensões
• Isso pode parecer à primeira vista como uma solução à prova de bala para utilizar sempre - não é verdade.
• O positivo das tabelas de link é resolver os relacionamentos como qualquer outra tabela faria. Isso dá a rastreabilidade completa à transação, mesmo dados implicitamente associados via outra tabela fato ficam rastreáveis (ao selecionar a tabela SalesCustomer - você verá os registros da tabela Orçamento associados).

   Inerentemente complexo de construir. Gerar a tabela no link não é tarefa fácil. Há consideravelmente mais verificações a introduzir no código para produzir o modelo.

   A tabela de link funciona como uma tabela desnormalizada, ou seja, que representa as associações de alto nível como a tabela Budget no Mês, ao nível de Grupo exigiria desnormalização para o menor denominador comum com outras fatos. Tabela Sales de Products e Data. Isto dá origem a um potencial grande volume de ligações na tabela de link necessário para resolver o mês e no Grupo correlacionando dados e produtos.

   Outra desvantagem não é exclusivo das Tabelas de Link – é igualmente um desafio ao concatenar tabelas de fatos.

• Esquemas Estrelas & Snow Flake funcionam melhor no QlikView. Tabelas relacionais tendem a ter ciclos (referências circulares) e, portanto, não funcionam corretamente quando colocados em QlikView.
• Os quatro principais diretrizes para a modelagem são:

1. Apontar para um esquema em estrela. Quebrar as tabelas é bom, mas tente mantê-lo ao mínimo, pois pode prejudicar o desempenho por ter muitas tabelas penduradas.
2. Quando desnormalizar dados (roll up) a fim de reduzir a quebra, pare de desnormalizar quando isto significar replicar registro em milhões de vezes - os ponteiros de memória necessária para armazenar o mesmo valor de uma enorme quantidade se torna significativa
3. Para soluções de multi-fato, analise os requisitos para ver se uma solução de tabelas concatenadas atende às necessidades. Se o registro de rastreabilidade transação é crucial, ao invés de análise por meio de associação de dimensões comuns, ai sim, analisar se a tabela de ligação serviria. Se nenhum modelo é uma boa opção, um modelo de dados personalizado deve ser montado através de uma análise cuidadosa das necessidades. Ele pode incorporar elementos de ambos link e tabelas concatenadas.
4. Em ambientes maiores seja com mais volume de dados ou maior complexidade ou a quantidade de usuários concorrentes, o design eficiente num documento QlikView se torna cada vez mais importante. Para este objetivo, por favor utilize as ferramentas à sua disposição de teste de desempenho.

Observações

• NÃO existe uma melhor arquitetura.
• A Arquitetura dependente totalmente dos Requisitos

Sistemas, habilidades, segurança, funcionalidade, flexibilidade, tempo, dinheiro e acima de tudo, Requisitos de Negócio!

• Da mesma forma Melhores Práticas não são Universais
• Aplicar as melhores práticas de acordo com cada situação

Considerações Finais…

• Se os usuários finais rejeitarem o seu aplicativo então você falhou, independentemente da sua execução técnica.
• As necessidades dos usuários finais e a experiência do usuário final deve sempre ditar a sua abordagem para o desenvolvimento de aplicações QlikView, incluindo modelagem de dados.
• Muitas técnicas de data warehousing são diretamente aplicáveis a modelagem de dados QlikView.
• Modelagem de dados está em curso há muitos anos e muitas mentes brilhantes têm contribuído para o campo, não precisamos reinventar a roda.

Modelagem - Esquema Estrela e Tabela de Link

O esquema em estrela (algumas vezes referenciado como esquema junção estrela) é o estilo simples de esquema do data warehouse. O esquema em estrela consiste de algumas tabelas de fatos (possivelmente apenas um, o que justifica o nome) referenciando qualquer número de tabelas de dimensão. O esquema em estrela é considerado um importante caso especial do esquema floco de neve.

(Source, Wikipedia - http://en.wikipedia.org/wiki/Star_schema)

• Este modelo funciona bem em um cenário de um evento único simplista. Mas, como o QlikView pode lidar com múltiplas fontes de dados a partir de muitas fontes de diferentes sistemas e arquivos, temos que trabalhar com vários cenários de eventos, ou muitas tabelas de fatos. 

• No caso de várias tabelas de fatos o QlikView permite-nos criar uma tabela de link central que contém apenas as combinações de dados existentes
• Em vez de juntar (Join) as tabelas, as dimensões da fato podem ser CONCATENADAS para uma tabela de link central
• Esta tabela de link pode então ser ligada de volta as metricas da fato de um lado, e as tabelas de dimensão do outro

TABELA DE LINK

Quando eu uso uma tabela de ligação?

    Quando existem campos comuns em várias tabelas (há uma chave sintética) mas a maioria dos campos de cada quadro NÃO são compartilhadas.

•Neste exemplo, uma concatenação de tabelas fato seria a solução preferível, embora uma solução básica tabela de ligação também é válido.

A maioria dos campos de cada tabela de fatos não são compartilhados

Como faço para criar uma tabela de link?

1. Criar um campo chave com os campos comuns

2. Coloque todos os outros campos com o campo chave de #1

3. Crie uma nova tabela com a mesma chave (key link) e os campos comuns separadamente

        Usando DISTINCT

• Se todas as tabelas não compartilham os mesmos campos exatos, crie chaves separadas para cada tabela na tabela de ligação

TABELAS

Sales:

Load

Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as SalesKey,

 [Customer Number],

 [Invoice Number],

 [Order Number],

 [Salesman Number],

 [Invoice Date],

 [Sales Amount],

 [Sales Qty],

 [Cost Amount],

 [Margin Amount],

 [Unit of Measure]

 FROM Sales;

 Inventory:

 Load 

 Branch & ‘_’ & [Item Number] as InvKey,

 [On Hand Qty]

 FROM Inventory;

 Purchasing:

 Load

 Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as POKey,

 [PO Number],

 [Req Delv Date],

 [PO Amount],

 [Ordered Qty]

  FROM Sales;

TABELA DE LIGAÇÃO ou TABELA DE LINK

LinkTable:

Load DISTINCT

Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as SalesKey,

Branch & ‘_’ & [Item Number] as InvKey,

Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as POKey,

Year,

Month,

[Branch],

[Item Number]

FROM Sales;

LinkTable:

Load DISTINCT

Null() & ‘_’ & Null() & Branch & ‘_’ & [Item Number] as SalesKey,

Branch & ‘_’ & [Item Number] as InvKey,

Null() & ‘_’ & Null() & Branch & ‘_’ & [Item Number] as POKey,

Null() as Year, Null() as Month,

[Branch],

[Item Number]

FROM Inventory;

LinkTable:

Load DISTINCT

Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as SalesKey,

Branch & ‘_’ & [Item Number] as InvKey,

Year & ‘_’ & Month & ‘_’ & Branch & ‘_’ & [Item Number] as POKey,

Year,

Month,

[Branch],

[Item Number]

FROM Purchasing;

Resultado

O que é uma tabela de ligação (link)? 

        É uma tabela que armazena todas as combinações possíveis de valores 

Quando eu uso uma tabela de ligação (link)?

        Quando existe mais do que um campo em comum entre as tabelas. 

Qual é o benefício? 

        Manter a integridade de sua aplicação.

Modelagem - Referências Circulares

Sempre que uma área é fechada no visualizador de tabelas você vai encontrar uma referência circular, por exemplo, se você tem duas tabelas de fatos que compartilham uma tabela de dimensão comum.

• Referências circulares são comuns em QlikView, porque você tem apenas um conjunto de relacionamentos por arquivo QlikView.
• Quando você tem uma referência circular veja se você pode viver sem uma instância do campo que está causando a associação adicional (como um campo duplicado). Se puder, renomeie ou remova.
• Caso contrário, você pode ter que recorrer a concatenação ou uma tabela de ligação(link table) para remover a referência circular
• Não se mate com tabelas de ligação, se você não precisa!

Como você pode resolver esta referência circular?

• Na maioria dos casos depende da regra de negócios
• Em nosso exemplo, a pergunta a fazer é ainda mais básica:

–É possível a CompanyName apenas ser renomeada para referenciá-la de forma independente, a fim de remover a referência circular?

                                 

Continua...

Modelagem QlikView - Chaves Sintéticas

Desafios típicos

• Quais os desafios que você encontrou na modelagem de dados básico em QlikView?
• Os mais comuns são:

                 –Chave sintética

                 –Referência circular

CHAVES SINTÉTICAS

•Quando existe mais do que um campo em comum entre tabelas

Se carregar como está, então…

 QlikView criará chaves sintéticas

O que é uma chave sintética?

• É um campo que contém todas as combinações possíveis de campos comuns entre as tabelas

A chave sintética é ruim?

• Não, mas tente evitá-lo. Ela é gerada pelo QlikView. Isso significa que você pode perder o controle sobre ele quando você tem muitas delas.

Quantas maneiras existem de resolver uma chave sintética?

1. Um ANSI JOIN
2. Uma chave concatenada
3. Tabelas Concatenadas
4. Uma tabela de Link

Como evitar as chaves sintéticas?

• Juntar as tabelas pelos campos comuns

Usando o nosso exemplo:

Sales:

Load

Year,

Month,

[Customer Number],

[Sales Amount]

FROM Sales;

LEFT JOIN Load 

Year,

Month,

[Customer Number],

[Budget Amount]

FROM Budget;

Customer:

Load

[Customer Number],

[Customer Name]

FROM Customer;

Problema!

• Não obtendo todos os dados da tabela do Budget de resultando em que faltam meses para o resto do ano
• Mesmo se juntar a tabela de vendas à tabela do Budget, ainda faltam atividades dos clientes que não estão orçados
• Pode se tornar um problema se as tabelas não tem um "um-para-um".

Como evitar as chaves sintéticas?

• Crie uma chave própria concatenando os campos comuns

Year & '_' & Month & '_' & [Customer Number] as Key

Mesmo problema de antes!

Como evitar as chaves sintéticas?

• Combinar (concatenar) as tabelas para ter todos os valores possíveis

Sales:

Load

Year,

Month,

[Customer Number],

[Sales Amount],

Null() as [Budget Amount]

FROM Sales;

Budget:

Load

Year,

Month,

[Customer Number],

Null() as [Sales Amount],

[Budget Amount]

FROM Budget;

Nota:

• Quando QlikView encontra várias tabelas com exatamente os mesmos campos, ele os combina em uma tabela automaticamente.
• Criar campos vazios (campos fictícios) usando a função null() para que faltam em cada tabela

O que é Forced Concatenate?

• QlikView cria campos vazios automaticamente portanto não há necessidade de criar campos fictícios manualmente

Sales:

Load 

Year, 

Month, 

[Customer Number],

[Sales Amount]

FROM Sales;

Budget:

CONCATENATE Load 

Year,

Month,

[Customer Number],

[Budget Amount]

FROM Budget;

Nota:

• Este script vai acabar com duas tabelas. É a mesma estrutura do método Auto-Concatenate

Qual é o benefício de combinar as tabelas em ums?

• Garantia de manter todos os dados em uma tabela.

Qual é o benefício de usar Auto-Concatenate?

• Quando alguns campos são erros ortográficos, ou quando alguns campos são deixados de fora por engano, então eles poderiam ser facilmente identificados (chaves sintéticas irão aparecer).

Usamos o método de concatenação com frequencia?

• Sim. É o método QlikView mais utilizado para resolver as chaves sintéticas.

Existe uma maneira de evitar a concatenação automática?

• Sim. Use a sintaxe "Load Noconcatenate" em vez de "Load". Permite melhor controle.

Continua...

Modelagem QlikView

O que é modelo de dados?

Definição tradicional:

•    Um modelo de dados tradicional é uma representação visual das pessoas, lugares e coisas de interesse para um negócio e é composta por símbolos que representam os conceitos e as suas regras de negócios.
•    Como um arquiteto de construção, que cria uma série de diagramas ou projetos a partir do qual a casa pode ser construída, um modelador de dados ou arquiteto cria diagramas a partir do qual um banco de dados podem ser construídos.

Definição QlikView:

     Um Modelo de dados no QlikView é a representação dos dados carregados.

•   Quando você carrega seus dados no aplicativo QlikView, um modelo de dados será criado com base nas tabelas e colunas que você tem em seu script e também os nomes das colunas e as cargas residentes e joins que você já tiver definido.
•   Você vai, naturalmente, ser conduzido pelo tipo e estrutura de suas fontes de dados.
•   Essas fontes e os dados dentro dela terá de ser manipulado dentro do script para entregar o modelo de dados que melhor se adapte às suas dados para o desempenho e a usabilidade.

QlikView não é SQL

• SQL toma um grande esquema e consulta (query) um subconjunto de tabelas

• Cada consulta (query) cria um “Esquema” temporário de poucas tabelas

• Os resultados das consultas (query) são independentes.

• QlikView constrói um esquema menor e mais amigável a relatórios a partir do banco de dados transacional

• O esquema é consistente e reage como um todo para as consultas (“queries”) do usuário.

• Uma seleção afeta todo o esquema.

• QlikView permite que você veja os resultados de uma seleção em todo o esquema e não apenas um subconjunto limitado de tabelas
• QlikView vai agregar com o menor nível de granularidade na expressão não o menor nível de granularidade no esquema (query) como SQL
• Isto significa que o QlikView irá permitir a um usuário interagir com uma ampla gama de dados que nunca será possível no SQL!
• Várias consultas SQL podem se juntar diferentes tabelas em conjunto completamente diferentes maneiras.
• No QlikView, há sempre apenas uma forma de juntar tabelas em qualquer arquivo QlikView
• Isto significa que o desenho do esquema é muito mais importante no QlikView!

Continua...