Benefícios de uma Solução MDM

Por conta da transformação digital, as maiorias das empresas estão cada vez mais conscientes que seus dados são um dos ativos mais importantes, a cada dia que passa o volume de dados aumentam exponencialmente e através da aplicação da metodologia Data-Driven, que basicamente é a utilização de dados para orientação de ações que geram novos dados que geram novas ações, logo se tornou essencial o gerenciamento de dados como um dos focos principais das organizações. Por conta dessa importância, podemos entender o quanto é vital para qualquer empresa, independentemente de seu tamanho,  um processo que envolva a coleta, sanitização, normatização, garantia de qualidade, governança e principalmente a transmissão dos dados entre todas as partes interessadas.

E é nesta solução desse problema que se encaixa perfeitamente um MDM, Master Data Management, em tradução livre ficaria, Gerenciamento de Dados Mestres. Essa solução fornecerá todos os requisitos mencionados anteriormente, como também a consolidação da oferta de dados em uma única fonte, que ofertará os benefícios: 

Qualidade dos Dados

No processo de coleta dos dados para transferência para o MDM é possível garantir através de regras de aceitação e da eliminação de dados inválidos. Como resultado os usuários poderão trabalhar com dados consistentes, uniformes e de melhor qualidade, o que tornará os processos de negócios mais eficientes e confiáveis.

Duplicação de Dados

Eliminando qualquer chance de conter dados duplicados, o que nos cenários atuais sem a centralização de dados é extremamente comum e leva a dúvidas em relação qual dados é mais confiável, o MDM irá construir uma única fonte de dados altamente confiável e proverá aumento na eficiência do negócio.

Precisão dos Dados

Sem dados inválidos ou duplicados, as discrepâncias no dados não existiram e aumentaram o nível de precisão dos mesmos, reduzindo os riscos de processamento de informações incorretas, como também o fator de normalização das estrutura facilitando a recuperação e entendimentos dos dados.

Redução de Custos

Uma vez que teremos uma solução gerenciando todos os dados mestres da empresa, automaticamente iremos reduzir os locais que precisam estar processando os dados, monitoramento da utilização,  sem contar a eliminação do impacto negativo ao negócio quando um dado impreciso é compartilhado.

Conformidade dos Dados Verídicos

Cada dia que passa os regulamentos e as políticas sobre dados estão ficando cada vez mais rígidos, com isso é fundamental que qualquer negócio tenha total controle (gerenciamento) sobre os dados, pois a não conformidade pode acarretar multas pesadas, como regulamentadas pela LGPD. A aplicação de um gerenciamento dos dados diminui as chances de violações de segurança e possibilita a conformidade regulamentar.

Tomada de Decisão em Dados

Já sabemos como as empresas estão aumentando a utilização dos dados para tomadas de decisões, informações incompletas e incorretas possibilitando à administração tomar decisões mal direcionadas que impactam o crescimento da empresa a curto e longo prazo. O simples fato de ter acesso a dados com qualidade, ajudará todos os gestores a desenvolverem estratégias eficazes.

Estamos num bom momento para considerar uma abordagem de MDM para gerenciamento de dados nas empresas. Já existem algumas ferramentas no mercado despontando com maturidade para oferecer um bom pacote de serviços, como também é possível implementar uma solução interna totalmente adaptada para o contexto do negócio. O que eu sei é, o gerenciamento de dados é um caminho inevitável para qualquer organização que queria estar no futuro entregando valores para seus clientes.

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Enviando o Resultado de uma Consulta SQL em formato HTML via Logic App

É um requisito bem simples, você precisa que um resultado de consulta ao banco de dados, ou seja, uma saída direta de uma tabela ou um resultado retornado de procedimento precisa ser enviado por email. Esse e-mail pode ser um retrato do momento da execução, algumas verificação diária de um processamento ou simplesmente uma notificação de algo que não deveria ter acontecido. E para facilitar o entendimento enviaremos o resultado formatado em HTML.

Existem inúmeras maneiras mais ou menos eficazes de realizar essa atividade, essa é uma forma de exemplificar um processo simples e rápido de ser implementado.

Consulta SQL

Suponhamos que precisamos enviar uma listagem dos produtos mais vendidos nos últimos sete dias e para isso criamos a consulta abaixo:

Abaixo fazemos pequenas adaptações na consulta, para formatar o resultado para que seja enviado por email e tenha um visual mais legível.

1. Aplicamos a tag <li> a tag para listar todos os registros de conjunto de dados

2. Em seguida, envolvemos a lista de itens com a tag HTML <ul>.

O resultado da consulta não é visualmente bonito, já o resultado em HTML :-)

Azure Logic App

Agora vamos criar o nosso Logic App com um gatilho recorrência, a execução da consulta e uma ação "Enviar um e-mail"

Gatilho

Vamos programar para que o aplicativo execute diariamente às 20h.

Ação

Para facilitar vamos executar diretamente o comando SQL, entretanto poderíamos optar por executar um procedimento. Importante configurar o método de autenticação.

Resultado

Agora basta selecionarmos a plataforma que irá efetuar o disparo do email, neste caso está configurado o disparo por uma conta do Gmail. Além da possibilidade de adicionar texto extra ao corpo do email, podemos ainda utilizar fórmulas para coletar outras informações.

Importante, como o resultado de uma consulta pode ser mais de uma linha, essa ação criará um laço que será executado para cada linha, entretanto nossa consulta sempre irá retornar somente uma linha, logo somente um email será disparado.

Execução 

Após a execução podemos verificar se as etapas foram concluídas com êxito e tempo de execução.

Checando o Email

E podemos ver o e-mail que será entregue todo dia, uma forma simples para atingir um objetivo. 

Até a próxima! :-)

Marcelo Goberto de Azevedo 

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Dicas para melhorar o entendimento das SQL Querys

Consultas em SQL são basicamente códigos no final, logo é importantíssimo termos a preocupação de oferecer um código claro e objetivo para aumentar a manutenibilidade dele por outros desenvolvedores. Comandos mal formatados e/ou com escritas confusas podem aumentar mais erros e uma falta geral de motivação para revisar seu trabalho. Para quem simplesmente escreve a consulta pode fazer sentido e até funcionar, porém é fundamental que o código esteja num melhor formato possível para aumentar sua qualidade, vamos a alguma regras que podem ajudar.

Seja consistente e corente com a formatação

SELECT primeiroNome, count(*) from
Usuários WHERE ultimo_nome = 'silva' Group by primeiroNome

Vamos analisar alguns pontos:

• Veja que algumas partes estão em maiúsculas e outras não, procure manter um padrão único, por exemplo todas as palavras reservadas.
• É confuso identificar o que é coluna ou o que é comando
• A coluna do SELECT está em "camelCase", a usada no WHERE está "snake_case" e o nome da tabela em "PascalCase", crie um padrão geral, se começou errado, conserte.
• A utilização de caracter especial em definição de nomes, como na tabela Usuários

Veja um exemplo como deveria ser:

SELECT primeiro_nome, COUNT(*) from
usuarios WHERE ultimo_nome = 'silva' GROUP BY by primeiro_nome 

Use e Abuse da Identação 

SELECT g.id, COUNT(u.id) FROM usuarios u JOIN gruopos g on u.grupo_chave
= g.chave WHERE u.nome = 'Marcelo' AND  u.sobrenome
= 'Silva'  GROUP BY g.chave ORDER BY COUNT(u.chave) desc 

Para uma consulta pequena pode não fazer diferença para leitura quando tudo está sem um padrão de separação, agora imagine aquelas longas procedures com todos os comandos encavalados, não é mesmo?

Veja se o resultado fica melhor para o entendimento: 

SELECT 
	  g.id
	, COUNT(u.id) 
FROM usuarios u 
	JOIN gruopos g on u.grupo_chave = g.chave 
WHERE 
	    u.nome = 'Marcelo' 
	AND u.sobrenome = 'Silva'
GROUP BY 
	g.chave 
ORDER BY 
	COUNT(u.chave) desc

Dica: A utilização da virgula (,)antes de cada campo no SELECT, ou das conjunções AND / OR no WHERE, GROUP BY, ORDER BY facilita a identificação visual onde se inicia ou termina o grupo de campo, além de fornecer uma forma agíl de comentar um campo 

Se você utilizar 2 ou 4 espaços não surti efeito considerável, o importante é só manter o padrão em toda a codificação, a simplesmente utilização dessa formatação farão seu colegas adorarem ver suas consultas quase como obras de arte. 😃

Utilize sempre "Aliases" 

SELECT
    u.chave
    , u.nome
    , t.chave
    , t.nome
    , (SELECT COUNT(*) FROM titulos where nome = t.nome)
FROM usuarios u
    JOIN titulos t on u.titulo_chave = t.chave 

O resultado dessa consulta será: 

chave	nome	chave	nome	count
1	Marcelo Goberto	4	Arquiteto	6

Novamente num cenário minimalista é possível identificar o que é cada conteúdo, agora imagine isso num longo resultado com várias colunas, por isso é fundamental que você nomeie cada coluna para que possa facilitar o entendimento.

Veja como fica o resultado da mesma consulta acima com ajustes 

SELECT
   u.chave AS usuario_chave   
   , u.nome AS usuario_nome
   , t.chave AS titulo_chave
   , t.nome AS titulo_nome
   , (SELECT COUNT(*) FROM titulos where nome = t.nome) AS qtde_titulos
FROM usuarios u
   JOIN titulos t on u.titulo_chave = t.chave

O resultado dessa consulta será 

usuario_chave	usuario_nome	titulo_chave	titulo_nome	qtde_titulos
1	Marcelo Goberto	4	Arquiteto	6

Utilize números nas clausulas GROUP BY e ORDER BY 

Neste caso essa é uma preferência pessoal que acredito que auxilia muito no organização de uma consulta, veja um exemplo com essa aplicação 

SELECT
   nome
    , sobrenome
    , COUNT(*) AS total
FROM usuarios
GROUP BY 1, 2
ORDER BY 3 desc 

Algumas vantagens na adoção desse formato são:

• Economia de linhas: a utilização de muitas colunas em GROUP ou ORDER não aumentará sua consulta, pois todos estarão enfileiradas
• Manutenção: Se desejar trocar o agrupamento ou a ordenação, basta trocar as colunas de lugar dentro da clausula SELECT

Esses foram alguns pontos que sempre considero na hora de escrever uma consulta, não existe um melhor padrão ou formato único para SQL, mas com certeza existe o desafio que procurar fazer um ótimo trabalho que possa ter sua manutenção facilitada para os próximos e quem sabe para nós mesmo, porque se todos tivermos um consenso que garantir sempre um excelente padrão de código, todos se sairão ganhando.

Marcelo Goberto de Azevedo

Arquiteto na GFT Brasil

//marcelogoberto.com.br

Principais Razões para uma Péssima Performance no SQL

Esses são os principais pontos que devem ser observados quando da construção de uma base de dados, porque alguns erros podem simplesmente transformar a performance numa verdadeira carroça, e acelerar uma carroça pode até funcionar, mas nãos será por muito tempo que ela vai aguentar o tranco. Vamos ver algumas ações que devemos evitar para garantir um bom desempenho de nossa base de dados.

#1: Desenho de Estrutura Ruim

Boa parte do sucesso de uma aplicação se sustenta nos dados que serão providos e nas velocidades em que eles estarão disponíveis. Por isso é importantíssimo a excelente na construção de uma estrutura do banco de dados, porque ela será a espinha dorsal para tudo que for construído em volta, listamos alguns erros que devem ser evitados para garantir um desenho funcional.

• Normalização Baixa

• Redundância de informações no banco de dados

• Baixa integridade de referência entre tabelas (chaves primárias e estrangeiras)

• Chaves primárias complexas demais (muitos campos)

• Falta de teste de stress no desenho (cenários de crescimento dos dados)

     

#2: Queries e Códigos Ineficientes

Se você tem uma base sólida e bem construída, agora chegou a parte de criar as principais estruturas que transportaram e transformarão os dados, essas partes são muito importantes, porque será através delas que os dados serão coletados e entregues nas pontas, esses erros devem ser evitados:

• Utilizar [NOT IN] ou [IN] em vez de [NOT EXISTS] ou [EXISTS]

• Usar cursores ou loop fakes em vez de [INSERT… SELECT] ou [SELECT… INTO TABLE]

• Usar [SELECT *] em vez de apenas os nomes de coluna necessários

• Esquecendo de usar parênteses ao usar operadores lógicos [OR] ou [AND]

• Alinhamento de subconsultas criando um plano de execução complexo

• Usando funções na coluna indexada na cláusula [WHERE]

• Uso excessivo de funções escalares definidas pelo usuário

• Uso desnecessário de [DISTINCT] em qualquer lugar

• SQL dinâmico

#3: Estratégia de Indicies Pobre

Os índices podem ser considerados aceleradores de um banco de dados, porém a criação, definição e utilização deve ser estudada e mensurada para que eles possam oferecer ganhos, porque indicies mal dimensionados à revelia podem acabar tendo um efeito contrário, por isso esses erros devem ser evitados:

• Indexar todas chaves estrangeiras

• Indexar todas as colunas de uma tabela

• Muitos índices para uma simples coluna

• Preferir tabelas sem índice clusterizado

• Subindexiar suas tabelas

• Não efetuar manutenção dos índices      

#4: Baixo Provisionamento de Equipamento

Mesmo que você utilize todas as boas práticas para a construção do seu banco de dados, nada disso surtirá efeito caso você não tenha recursos suficientes para as estruturas sejam utilizadas com uma folga no servidor, ou seja, é importante a metrificação do tamanho do equipamento ou instância que rodará o banco de dados, entre as principais métricas CPU, Memória, Espaço em Disco. Os erros listados devem ser evitados a qualquer custo:

• CPU funcionando mais de 90% constantemente

• 95% da memória sendo utilizadas

• Leitura e escrita (I/O) em disco muito alta

#Conhecimento

A palavra chave para criação de um banco de dados performático é conhecimento.

Um profissional de TI, deve continuar aprendendo e se desenvolvendo para ficar à frente de todos os novos desafios futuros, e através dessas informações poderá aplicar mais práticas relevantes para melhorar a qualidade final de seu trabalho.

A cada novo dia, novas ferramentas, metodologias e ferramentas são criadas, sendo disponibilizadas para auxiliar na criação de melhores soluções.

Mantenha-se atualizado sempre.

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
https://marcelogoberto.blogspot.com/

COMPREENDENDO INNER JOIN, LEFT JOIN, RIGHT JOIN e FULL OUTER JOIN

O conceito é bem simples, todos nós aprendemos na escola a teoria dos conjuntos, logo a extração de informação com interseção no SQL é simplesmente gerar um subconjunto do conjunto universo.

Digamos que tenhamos duas tabelas, sendo uma de CLIENTE e outra de PEDIDO, conforme a estrutura abaixo:

CLI_CLIENTE

CLI_N_CODIGO	CLI_C_RAZAO	CLI_C_PAIS
1	Acne Ltda	Brasil
2	Limofer Industria	China
4	Kimber Partner S/A	EUA

PED_PEDIDO

PED_C_CODIGO	PED_CLI_N_CODIGO	PED_D_DATA	PED_N_VALOR
100/2019	1	2019-05-01	300,00
101/2019	1	2019-09-12	550,00
102/2019	4	2019-09-24	1000,00
100/2020	5	2020-01-01	600,00

INNER JOIN

Forma clássica de retorno do subconjunto somente com o que é comum na ligação (ON) entre as tabelas.

SELECT CLI_N_CODIGO, CLI_C_RAZAO, PED_C_CODIGO, PED_D_DATA, PED_N_VALOR

       FROM CLI_CLIENTE

              INNER JOIN PED_PEDIDO

                    ON CLI_N_CODIGO = PED_CLI_N_CODIGO

CLI_N_CODIGO	CLI_C_RAZAO	PED_C_CODIGO	PED_D_DATA	PED_N_VALOR
1	Acne Ltda	100/2019	2019-05-01	300,00
1	Acne Ltda	101/2019	2019-09-12	550,00
4	Kimber Partner S/A	102/2019	2019-09-24	1000,00

LEFT E RIGHT JOIN

Retorna somente a partir da tabela que e direção que está sendo usado, no caso do LEFT (a primeira tabela) e RIGHT (a segunda tabela) do JOIN.

SELECT CLI_N_CODIGO, CLI_C_RAZAO, PED_C_CODIGO, PED_D_DATA, PED_N_VALOR

       FROM CLI_CLIENTE

              LEFT JOIN PED_PEDIDO

                    ON CLI_N_CODIGO = PED_CLI_N_CODIGO

CLI_N_CODIGO	CLI_C_RAZAO	PED_C_CODIGO	PED_D_DATA	PED_N_VALOR
1	Acne Ltda	100/2019	2019-05-01	300,00
1	Acne Ltda	101/2019	2019-09-12	550,00
2	Limofer Industria	NULL	NULL	NULL
4	Kimber Partner S/A	102/2019	2019-09-24	1000,00

SELECT CLI_N_CODIGO, CLI_C_RAZAO, PED_C_CODIGO, PED_D_DATA, PED_N_VALOR

       FROM CLI_CLIENTE

              RIGHT JOIN PED_PEDIDO

                    ON CLI_N_CODIGO = PED_CLI_N_CODIGO

CLI_N_CODIGO	CLI_C_RAZAO	PED_C_CODIGO	PED_D_DATA	PED_N_VALOR
1	Acne Ltda	100/2019	2019-05-01	300,00
1	Acne Ltda	101/2019	2019-09-12	550,00
NULL	NULL	100/2020	2020-01-01	600,00
4	Kimber Partner S/A	102/2019	2019-09-24	1000,00

FULL OUTER JOIN

Retorna todo o conjunto relacionando os dados que existem  entre a ligação (ON) e para os casos que não haja ligação carregados os dados nullos.

 SELECT CLI_N_CODIGO, CLI_C_RAZAO, PED_C_CODIGO, PED_D_DATA, PED_N_VALOR

       FROM CLI_CLIENTE

              FULL OUTER JOIN PED_PEDIDO

                    ON CLI_N_CODIGO = PED_CLI_N_CODIGO

CLI_N_CODIGO	CLI_C_RAZAO	PED_C_CODIGO	PED_D_DATA	PED_N_VALOR
1	Acne Ltda	100/2019	2019-05-01	300,00
1	Acne Ltda	101/2019	2019-09-12	550,00
2	Limofer Industria	NULL	NULL	NULL
4	Kimber Partner S/A	102/2019	2019-09-24	1000,00
NULL	NULL	100/2020	2020-01-01	600,00

Segue um infográfico que ajuda no entendimento de cada tipo de ligação.

Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil
https://marcelogoberto.blogspot.com/