Dicas para uma implementação bem-sucedida do LuckyTemplates

Continuaremos nossa série sobre planejamento e implementação de projetos do LuckyTemplates. Desta vez, discutiremos sobre design de conjunto de dados , criação de perfis e modos . Confira a primeira parte de nossa série de planejamento de projeto que trata dos modos de implantação e a segunda parte que fala sobre descoberta e ingestão .

Índice

• Design de conjunto de dados para implementação de projetos do LuckyTemplates
  • 4 etapas para o design do conjunto de dados
  • Selecione o processo de negócios.
    • O antipadrão a ser evitado na implementação do LuckyTemplates
  • Declare o grão.
  • Identifique as dimensões.
  • Defina os fatos.
• Matriz de barramento de dados para implementação de projetos de LuckyTemplates
• Criação de perfil de dados para implementação do LuckyTemplates
  • Serviços de Integração do SQL Server
  • Estúdio DAX
  • Área de Trabalho do LuckyTemplates
• Planejamento de conjunto de dados para implementação do LuckyTemplates
  • Escolhendo um modo de conjunto de dados
  • Algumas perguntas a serem feitas ao escolher os modos de conjunto de dados
• Conclusão

Design de conjunto de dados para implementação de projetos do LuckyTemplates

Vamos falar sobre o processo de design do conjunto de dados e discutir a matriz de barramento do data warehouse , que é uma ferramenta que já existe há algum tempo.

Projetar conjuntos de dados do LuckyTemplates é semelhante a projetar data warehouses. Portanto, os conjuntos de dados e os armazéns de dados têm conceitos semelhantes, como tabelas de fatos e dimensões, esquemas em estrela, dimensões que mudam lentamente, granularidade da tabela de fatos e chaves informadas locais para construir relacionamentos entre tabelas.

4 etapas para o design do conjunto de dados

Há quatro etapas no processo de design do conjunto de dados: selecionar o processo de negócios , declarar a granulação de suas tabelas de fatos, identificar as dimensões e, em seguida, definir os fatos .

Selecione o processo de negócios.

Para a primeira etapa, cada processo de negócios é representado por uma tabela de fatos com um esquema em estrela de muitos para um relacionamento com as dimensões.

Durante um processo de descoberta ou coleta de requisitos, é difícil focar em um único processo de negócios isoladamente, já que os usuários analisam regularmente vários processos de negócios simultaneamente.

O antipadrão a ser evitado na implementação do LuckyTemplates

O antipadrão comum (que é uma resposta a um problema recorrente que geralmente é ineficaz e potencialmente contraproducente) que você deseja evitar em projetos do LuckyTemplates é o desenvolvimento de conjuntos de dados para projetos ou equipes específicas, e não para os processos de negócios .

Por exemplo, desenvolver um conjunto de dados exclusivamente para a equipe de marketing e outro conjunto de dados para a organização de vendas. Essa abordagem naturalmente leva ao desperdício de recursos porque os mesmos dados de vendas são consultados e atualizados duas vezes em ambos os conjuntos de dados. Eles também consumirão recursos de armazenamento no serviço do LuckyTemplates.

essas são algumas das razões pelas quais você deseja passar por um bom processo de design de conjunto de dados. Uma abordagem isolada leva a problemas de gerenciamento e controle de versão porque os conjuntos de dados podem conter variações e transformações.

Embora as necessidades analíticas dos usuários ou equipes sejam a prioridade dos projetos do LuckyTemplates, também é importante planejar soluções sustentáveis ​​que possam ser compartilhadas entre as equipes.

Declare o grão.

A granularidade das tabelas de fatos abrange, em última análise, o nível de detalhe disponível para consultas analíticas, bem como a quantidade de dados que podem ser acessados.

Portanto, grãos mais altos significam mais detalhes, enquanto grãos mais baixos significam menos detalhes. Um exemplo disso é quando você deseja obter o nível da linha do pedido de venda ou se deseja que o projeto contenha apenas o nível resumido de cada pedido de venda e não vá até os produtos específicos que foram solicitados como parte dessa venda.

Às vezes, esse grão pode variar dependendo do seu período de tempo. Encontrei vários clientes que desejam tabelas de fatos muito refinadas para o trimestre atual, mas para os trimestres anteriores, eles só precisavam saber qual foi o total de vendas do trimestre.

Durante esta etapa, você deseja determinar o que representa cada linha dos diferentes processos de negócios . Por exemplo, cada linha da tabela de fatos de vendas de nosso data warehouse representa a linha de um pedido de vendas de um cliente.

Por outro lado, as linhas de um plano de vendas e margem serão agregadas em um mês civil, subcategoria de produto e região do território de vendas. então, neste caso, você tem duas tabelas de fatos diferentes e dois grãos diferentes. se você quiser comparar os dois, haverá algum trabalho de modelagem de dados envolvido.

Identifique as dimensões.

As dimensões são apenas o subproduto natural do grão escolhido na etapa anterior do projeto.

Portanto, uma única linha de amostra da tabela de fatos deve indicar claramente as dimensões da entidade de negócios associadas ao determinado processo, como o cliente que comprou um projeto individual, o produto em uma determinada data e em um determinado horário. As tabelas de fatos que representam granulações inferiores têm menos dimensões.

Por exemplo, uma tabela de fatos que representa o nível do cabeçalho de uma ordem de compra pode identificar o fornecedor, mas não a compra individual do produto do fornecedor. portanto, nesse caso, você não precisaria incluir uma categoria de produto ou uma dimensão de subcategoria de produto.

Defina os fatos.

Os fatos representam as colunas numéricas incluídas nas tabelas de fatos. Portanto, enquanto as colunas de dimensão da etapa 3 são usadas para relacionamentos, as colunas de fatos são usadas em medidas que contêm lógica de agregação, como a soma de uma coluna de quantidade ou a média de uma coluna de preço.

Matriz de barramento de dados para implementação de projetos de LuckyTemplates

A matriz de barramento do data warehouse é um elemento básico da arquitetura do data warehouse Ralph Kimball, que fornece uma abordagem incremental e integrada para o design do data warehouse.

A arquitetura que você vê aqui é do The Data Warehouse Toolkit , 3ª edição de Ralph Kimball. Ele permite modelos de dados escalonáveis ​​que várias equipes ou funções de negócios geralmente exigem para acessar os mesmos processos e dimensões de negócios.

Manter uma matriz de barramento de data warehouse por perto é útil. ao preenchê-lo, você saberá se existem outros conjuntos de dados que contenham tabelas de fatos e tabelas de dimensões da Internet semelhantes. isso promove a reutilização do projeto e melhora a comunicação do projeto.

Portanto, cada linha reflete um processo de negócios importante e recorrente, como o fechamento mensal do razão geral. cada coluna representa uma entidade de negócios, que pode estar relacionada a um ou vários processos de negócios, enquanto as linhas sombreadas representam o processo de negócios que está sendo incluído no projeto.

Criação de perfil de dados para implementação do LuckyTemplates

depois de identificar a granulação e concluir o processo de design do conjunto de dados em quatro etapas, deve ser imediatamente seguida por uma análise técnica dos dados de origem das tabelas de fatos e dimensões .

Os metadados técnicos, incluindo diagramas de banco de dados e resultados de perfis de dados, são essenciais para o estágio de planejamento do projeto.

Essas informações são usadas para garantir que o conjunto de dados do LuckyTemplates reflita as definições de negócios pretendidas e seja criado em uma fonte sólida e confiável.

Portanto, três são três maneiras diferentes de coletar essas informações de perfil, que deve ser a primeira etapa que as pessoas farão quando saírem do processo de design.

Serviços de Integração do SQL Server

Existem algumas maneiras de fazer isso. Um método é usar uma tarefa de criação de perfil de dados em um pacote SQL Server Integration Services (SSIS).

A tarefa de criação de perfil de dados requer uma conexão ADO.NET e pode gravar sua saída em um arquivo XML ou uma variável SSIS.

Neste exemplo, os dados de origem ADO.NET são um data warehouse, banco de dados e servidor SQL da AdventureWorks, e o destino é um arquivo XML.

Assim que a tarefa é executada, o arquivo XML pode ser lido por meio de um visualizador de perfil de dados do servidor SQL. Você pode ver os resultados em termos de contagem nula e porcentagens de contagem nula.

Estúdio DAX

Outra forma de criação de perfil de dados é por meio do DAX Studio. você realmente precisa ingerir os dados em um conjunto de dados do LuckyTemplates acessando o DAX Studio, vá para a guia Avançado e execute o VertiPaq Analyzer .

Ele mostrará o mesmo tipo de informação sobre a cardinalidade de suas colunas para que você saiba quais estão ocupando mais espaço em seu modelo de dados. inclui todas as várias estatísticas em torno dos dados.

Área de Trabalho do LuckyTemplates

a criação de perfil de dados também está disponível na consulta de energia na área de trabalho do LuckyTemplates. se você for para a guia Exibir , poderá ativar itens como qualidade da coluna, distribuição da coluna e perfil da coluna. Pelo menos para as primeiras mil linhas, você pode ver informações como erros, nulos, médias e desvios padrão.

Planejamento de conjunto de dados para implementação do LuckyTemplates

Depois que os dados de origem são perfilados e avaliados em relação aos requisitos identificados no processo de design do conjunto de dados de quatro etapas, a equipe de BI pode analisar ainda mais as opções de implementação para o conjunto de dados.

Em quase todos os projetos de LuckyTemplates, mesmo aqueles com investimentos significativos em dados corporativos, warehouse, arquitetura e ferramentas e processos de ETL, algum nível de lógica, integração ou transformação adicional é necessário para aprimorar a qualidade e o valor dos dados de origem.

O estágio de planejamento do conjunto de dados determina como os problemas de transformação de dados identificados são tratados para dar suporte ao conjunto de dados. Além disso, a equipe do projeto deve determinar se deve desenvolver um conjunto de dados no modo de importação , um conjunto de dados de consulta direta ou um conjunto de dados composto .

Para esclarecer o processo de planejamento do conjunto de dados, este diagrama identifica as diferentes camadas do data warehouse e do conjunto de dados do LuckyTemplates onde a transformação e a lógica de negócios podem ser implementadas.

em alguns projetos, é necessária uma transformação mínima e pode ser facilmente incluída no conjunto de dados do LuckyTemplates. Por exemplo, se apenas algumas colunas adicionais forem necessárias para uma tabela de dimensão e houver orientação direta sobre como essas colunas serão calculadas, a organização de TI pode optar por implementar essas transformações nas consultas de poder M em vez de revisar o data warehouse.

Se a lacuna substancial entre as necessidades de BI e o data warehouse corporativo persistir, os conjuntos de dados do LuckyTemplates se tornarão mais complexos para criar e manter.

Os designers de conjuntos de dados devem analisar e comunicar regularmente as implicações dos conjuntos de dados se houver níveis maiores de complexidade.

No entanto, se a lógica de transformação necessária for complexa ou extensa com várias operações conjuntas, filtros de linha e alterações de tipo de dados, a organização de TI pode optar por implementar alterações essenciais no data warehouse para dar suporte ao novo conjunto de dados e futuros projetos de BI.

Por exemplo, uma tabela de preparação e um procedimento de armazenamento SQL podem ser necessários para dar suporte, revisar e atualizar o processo, ou a criação de um índice pode ser necessária para melhorar o desempenho da consulta para conjuntos de dados DirectQuery.

Escolhendo um modo de conjunto de dados

Uma etapa subsequente, mas intimamente relacionada ao planejamento do conjunto de dados, é escolher entre o modo de importação padrão, modo DirectQuery/ao vivo ou modo composto.

Em alguns projetos, esta é uma decisão simples onde apenas uma opção é viável ou realista, dados os requisitos conhecidos, enquanto outros projetos implicarão em uma análise significativa dos prós e contras de cada projeto.

Portanto, se uma fonte de dados for considerada lenta ou mal equipada para lidar com um alto volume de consultas analíticas, um conjunto de dados no modo de importação provavelmente será a opção preferencial.

Da mesma forma, se a visibilidade quase em tempo real de uma fonte de dados for essencial, DirectQuery ou modo ao vivo é a única opção para conseguir isso. os modos DirectQuery e ao vivo são muito semelhantes entre si. Ambos os métodos não armazenam dados dentro do próprio conjunto de dados e ambos consultam os sistemas de origem diretamente para recuperar dados com base na ação do usuário. Agora temos conjuntos de dados DirectQuery para LuckyTemplates e DirectQuery para Analysis Services.

Algumas perguntas a serem feitas ao escolher os modos de conjunto de dados

Aqui estão algumas perguntas a serem feitas ao decidir qual modo usar. existe uma única fonte para o nosso conjunto de dados? Se não houver uma única fonte, você não poderia usar a fonte DirectQuery/Live no passado.

Embora agora tenhamos conjuntos de dados no modo composto, ainda é uma boa pergunta fazer no início porque, se não houver uma fonte única, ela será importada ou composta.

Se a fonte DirectQuery/Live for uma opção, a fonte é capaz de oferecer suporte a consultas analíticas? Se você estiver trabalhando com bilhões ou trilhões de linhas, talvez um conjunto de dados no modo de importação não seja viável e você terá que ir para o modo DirectQuery ou composto para garantir que o conjunto de dados seja utilizável.

Se a fonte DirectQuery/Live é capaz de suportar a carga de trabalho, a conexão DirectQuery/Live é mais valiosa do que o desempenho e a flexibilidade fornecidos por um modelo de importação?

Conclusão

Esta postagem encerra esta série sobre o planejamento de projetos do LuckyTemplates. acho que essas são as etapas essenciais para todos os projetos de LuckyTemplates nos quais você trabalha. Essas etapas são importantes ao fazer a devida diligência, especialmente em um ambiente de business intelligence corporativo.

Tudo de bom,

Greg Deckler