Partilhar via


Boas práticas para criar um modelo dimensional usando fluxos de dados

Desenhar um modelo dimensional é uma das tarefas mais comuns que pode realizar com um fluxo de dados. Este artigo destaca algumas das melhores práticas para criar um modelo dimensional usando um fluxo de dados.

Fluxos de dados de preparação

Um dos pontos-chave em qualquer sistema de integração de dados é reduzir o número de leituras do sistema operacional de origem. Na arquitetura tradicional de integração de dados, esta redução é feita através da criação de uma nova base de dados chamada base de dados de staging. O objetivo da base de dados de staging é carregar os dados tal como estão da fonte de dados para a base de dados de staging com uma regularidade definida.

O restante da integração de dados utiliza então a base de dados de staging como fonte para transformações adicionais e converte-a para a estrutura do modelo dimensional.

Recomendamos que siga a mesma abordagem usando fluxos de dados. Cria um conjunto de fluxos de dados responsáveis apenas por carregar os dados as-is do sistema de origem (e apenas para as tabelas de que precisas). O resultado é então armazenado na estrutura de armazenamento do fluxo de dados (Azure Data Lake Storage ou Dataverse). Esta alteração assegura que a operação de leitura do sistema de origem é mínima.

De seguida, pode criar outros fluxos de dados que obtenham os seus dados a partir de fluxos de dados de staging. Os benefícios desta abordagem incluem:

  • Reduzindo o número de operações de leitura do sistema de origem e, como resultado, diminuindo a carga sobre o sistema de origem.
  • Reduzir a carga nos gateways de dados se for usada uma fonte de dados local.
  • Ter uma cópia intermédia dos dados para fins de conciliação, caso os dados do sistema de origem alterem.
  • Tornando os fluxos de dados da transformação independentes da fonte.

Diagrama que mostra o fluxo quando se preparam fluxos de dados.

Diagrama que enfatiza os fluxos de dados e armazenamento em etapas. O diagrama mostra o acesso aos dados a partir da fonte de dados pelo fluxo de dados de preparação, e as tabelas armazenadas em Cadavers ou Azure Data Lake Storage. As tabelas são então mostradas a serem transformadas juntamente com outros fluxos de dados, que são depois enviados como consultas.

Fluxos de dados de transformação

Quando separa os fluxos de dados de transformação dos fluxos de dados de staging, a transformação é independente da fonte. Esta separação ajuda se estiveres a migrar o sistema fonte para um novo sistema. Tudo o que precisas de fazer nesse caso é alterar os fluxos de dados intermediários. Os fluxos de dados de transformação provavelmente funcionarão sem qualquer problema porque são obtidos apenas dos fluxos de dados de staging.

Esta separação também ajuda caso a ligação ao sistema de origem seja lenta. O fluxo de dados de transformação não precisa de esperar muito tempo para receber registos através de uma ligação lenta ao sistema de origem. O fluxo de dados de staging já fez essa parte, e os dados estão prontos para a camada de transformação.

Diagrama semelhante à imagem anterior, exceto que as transformações são enfatizadas, e os dados são enviados para o data warehouse.

Arquitetura em Camadas

Uma arquitetura em camadas é uma arquitetura em que realizas ações em camadas separadas. Os fluxos de dados de staging e transformação podem ser duas camadas de uma arquitetura de fluxo de dados multicamada. Tentar realizar ações em camadas garante a manutenção mínima necessária. Quando quiseres mudar algo, só tens de o alterar na camada onde está localizado. As outras camadas devem continuar a funcionar bem.

A imagem seguinte mostra uma arquitetura multilayer para fluxos de dados em que as suas tabelas são depois usadas em modelos semânticos do Power BI.

Diagrama que mostra uma arquitetura multicamada, onde fluxos de dados de staging e de transformação estão em camadas separadas.

Use uma tabela computada tanto quanto possível

Quando usas o resultado de um fluxo de dados noutro fluxo de dados, estás a usar o conceito de tabela computada, que significa obter dados de uma tabela "já processada e armazenada". O mesmo pode acontecer dentro de um fluxo de dados. Quando referencias uma tabela a partir de outra tabela, podes usar a tabela computada. Este método é útil quando se tem um conjunto de transformações que precisam de ser feitas em múltiplas tabelas, chamadas transformações comuns.

Diagrama que mostra a tabela computada proveniente de uma fonte de dados usada para processar transformações comuns.

Na imagem anterior, a tabela calculada obtém os dados diretamente da fonte. No entanto, na arquitetura dos fluxos de dados de staging e transformação, é provável que as tabelas computadas sejam provenientes dos fluxos de dados de staging.

Diagrama mostrando uma tabela computada proveniente de fluxos de dados usados para processar transformações comuns.

Construir um esquema estrela

O melhor modelo dimensional é um modelo de esquema em estrela que tem tabelas de dimensões e factos desenhadas de forma a minimizar o tempo necessário para consultar os dados do modelo. Um modelo de esquema em estrela também facilita a compreensão para o visualizador de dados.

Não é ideal trazer dados no mesmo layout do sistema operacional para um sistema BI. As tabelas de dados devem ser remodeladas. Algumas das tabelas devem assumir a forma de uma tabela de dimensões, que mantém a informação descritiva. Algumas das tabelas devem assumir a forma de uma tabela de factos, para manter os dados agregados. O melhor layout para formar tabelas de factos e tabelas de dimensões é um esquema em estrela. Para mais informações, consulte Compreender o esquema estrela e a importância do Power BI.

Diagrama de um esquema de estrela mostrando uma tabela de factos rodeada por tabelas de dimensões, em forma de estrela de cinco pontas.

Use um valor-chave único para as dimensões

Ao construir tabelas de dimensões, certifique-se de que tem uma chave para cada uma. Esta chave garante que não existem relações muitos-para-muitos (ou, por outras palavras, "fracas") entre dimensões. Podes criar a chave aplicando alguma transformação para garantir que uma coluna ou uma combinação de colunas está a devolver linhas únicas na dimensão. Depois, essa combinação de colunas pode ser marcada como uma chave na tabela do fluxo de dados.

Captura de ecrã do separador de transformação do Power Query, com a opção Marcar como chave, e o ícone de chave na coluna de data da tabela destacado.

Faça uma atualização incremental para tabelas de factos grandes

As tabelas de factos são sempre as maiores tabelas no modelo dimensional. Recomendamos que diminua o número de linhas transferidas para estas tabelas. Se tiver uma tabela de factos muito grande, certifique-se de usar atualização incremental para essa tabela. Pode ser feita uma atualização incremental no modelo semântico do Power BI, bem como nas tabelas de fluxo de dados.

Podes usar a atualização incremental para atualizar apenas parte dos dados, a parte que mudou. Existem várias opções para escolher que parte dos dados deve ser atualizada e qual parte deve ser mantida. Para mais informações, consulte Utilizar a atualização incremental com fluxos de dados do Power BI.

Captura de ecrã do diálogo de atualização incremental para fluxos de dados.

Referência para a criação de tabelas de dimensões e factos

No sistema de origem, muitas vezes tens uma tabela que usas para gerar tabelas de factos e de dimensões no data warehouse. Estas tabelas são boas candidatas para tabelas computadas e também para fluxos de dados intermédios. A parte comum do processo — como a limpeza de dados e a remoção de linhas e colunas extra — pode ser feita uma vez. Ao usar uma referência da saída dessas ações, é possível produzir as tabelas de dimensão e fatos. Esta abordagem utiliza a tabela calculada para as transformações comuns.

Captura de ecrã mostrando uma consulta de Pedidos com a opção de referência a ser usada para criar uma nova consulta chamada Pedidos agregados.