Guia para mineração de dados econômica

Ao contrário da programação de aplicativos tradicional, onde as funções da API mudam todos os dias, a programação de banco de dados basicamente permanece a mesma. A primeira versão do Microsoft Visual Studio .NET foi lançada em fevereiro de 2002, com uma nova versão lançada a cada dois anos, sem incluir os lançamentos do Service Pack. Esse ritmo acelerado de mudança força o pessoal de TI a avaliar os aplicativos de sua corporação a cada dois anos, deixando a funcionalidade de seu aplicativo intacta, mas com um código-fonte completamente diferente para se manter atualizado com as mais recentes técnicas e tecnologias.

O mesmo não pode ser dito sobre o código-fonte do seu banco de dados. Uma consulta padrão de SELECT / FROM / WHERE / GROUP BY , escrita nos primeiros dias do SQL, ainda funciona hoje. Claro, isso não significa que não houve avanços na programação de banco de dados relacional; houve, e eles foram mais lógicos do que técnicos .

Desde os dias em que Bill Inmon e Ralph Kimball publicaram suas teorias sobre design de data warehouse, os avanços na programação de banco de dados se concentraram na prevenção da perda de informações valiosas e na extração de todas as informações valiosas dos dados. Uma vez que Inmon e Kimball introduziram o mundo do banco de dados ao data warehousing, grandes mudanças foram feitas nas ferramentas ETL (Extract/Transform/Load) que deram aos desenvolvedores de banco de dados fácil acesso a metadados e dados de fontes de banco de dados não relacionais, o que era difícil de trabalhar. no passado. Isso aumentou a quantidade de dados disponíveis para extrair informações valiosas, e esse aumento nos dados disponíveis levou a avanços no processamento de dados por meio de cubos OLAP e algoritmos de mineração de dados.

Adicionar um data warehouse, cubos OLAP e algoritmos de mineração de dados à arquitetura de seu banco de dados pode agilizar drasticamente os processos de negócios e iluminar padrões em seus dados que, de outra forma, você nunca saberia que existiam. A automação também pode ter um impacto profundo nos recursos de inteligência de negócios.

No entanto, antes de começar a adicionar novas ferramentas e tecnologias, você deve certificar-se de que o banco de dados de transações foi construído corretamente.

Banco de dados de transações

O banco de dados de transações é a base e, se o banco de dados de transações não for confiável e preciso, adicionar qualquer coisa no topo é uma receita para o desastre.

Um ponto importante a ter em mente ao adicionar camadas adicionais ao seu banco de dados é que todos os projetos precisam mostrar um retorno sobre o investimento , e é por isso que é melhor aproveitar ao máximo sua arquitetura atual antes de adicionar mais camadas. Todas essas camadas utilizam dados provenientes de um banco de dados de transações. Em muitas situações, você pode obter a mesma saída simplesmente consultando seu banco de dados de transações. É claro que ter todos os seus relatórios lidos de um data warehouse ou cubo OLAP é o método ideal, mas quando uma organização não está pronta para esse nível de complexidade, é mais importante que suas necessidades de relatórios sejam atendidas primeiro. Assim que as necessidades básicas de relatórios forem atendidas, é muito mais fácil iniciar uma discussão sobre como um data warehouse adequado e possivelmente um cubo OLAP podem beneficiar seus negócios.

Quase todo programador conhece as três regras de normalização de banco de dados. Os procedimentos armazenados lidos no banco de dados de transações são o caminho para a otimização. Os problemas a serem observados são legibilidade, várias chamadas para a mesma tabela de banco de dados e uso desnecessário de variáveis.

Todos os programadores de banco de dados de elite são exigentes quanto à legibilidade de seus procedimentos armazenados. Existem alguns pontos em comum na forma como os profissionais de banco de dados formatam suas consultas, o que é diferente de um desenvolvedor de aplicativos. Normalmente, palavras-chave e funções agregadas estão em maiúsculas, enquanto nomes de tabelas e campos usam camelcase ou sublinhados. Os aliases de tabela têm alguma correlação com o nome real da tabela. O alinhamento das seções do procedimento armazenado possui algum tipo de padrão de bloco.

Abaixo está um exemplo de uma consulta que utiliza um formato legível.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

A próxima coisa a procurar é se uma consulta atinge uma tabela mais de uma vez. Na maioria das consultas, uma tabela só precisa ser acessada uma vez, excluindo as raras vezes em que você precisa agregar outra função de agregação. Esse é outro erro que alguns programadores de aplicativos cometem, talvez porque um programador de aplicativos pensa em termos de design orientado a objetos.

O design orientado a objetos cria objetos separados para cada elemento de dados exclusivo, mas um programador de banco de dados precisa pensar em termos de lógica de conjunto. Só porque uma consulta acessa uma tabela mais vezes do que o necessário não significa que a consulta está produzindo dados imprecisos, porém o desempenho da consulta é afetado.

Outra preocupação é descartar ou duplicar registros toda vez que você fizer uma junção, comprometendo a precisão de sua consulta. O uso desnecessário de variáveis ​​é mais um sinal de que uma consulta foi desenvolvida por um desenvolvedor de aplicativos. Os desenvolvedores de aplicativos usam variáveis ​​em todo o código, enquanto uma consulta raramente precisa usar variáveis, exceto quando declarada como um parâmetro para o procedimento armazenado. Mais uma vez é um sinal de que o desenvolvedor não estava pensando em termos de lógica de conjunto.

ETL (Extract Transform Load) e relatórios

Uma vez que o banco de dados de transações de um cliente tenha consultas funcionando corretamente, a próxima etapa é agilizar os processos de negócios.

A maneira mais fácil de identificar a necessidade de uma empresa por processos de ETL ou relatórios automatizados é descobrir quem está lendo dados de um banco de dados de transações e depois manipulando os dados usando uma planilha. Uma planilha é a mesma estrutura que uma tabela de banco de dados. Ambos contêm linhas e colunas. Se você tem usuários finais manipulando dados por conta própria, você deve se perguntar: “Por que esse processo não pode ser automatizado?”

A automatização de processos de negócios proporciona um retorno imediato sobre o investimento e deve sempre ser considerada antes de passar para projetos mais caros, como data warehousing. Identificar usuários finais manipulando dados por meio de uma planilha pode parecer simples, mas há uma ressalva nesse processo.

Os desenvolvedores gostam de automatizar processos; é o que eles fazem. Os usuários finais não necessariamente gostam de processos automatizados, especialmente se eles ameaçam seu trabalho. Portanto, não seja ingênuo e pense que os usuários finais vão correr até você e identificar tarefas diárias que podem ser automatizadas. Você realmente precisa assumir a liderança na identificação de oportunidades de racionalização.

Um sistema ETL bem construído também deve fornecer a capacidade de retroceder todos os dados carregados em um banco de dados de transações de volta ao arquivo de origem original. Essa é uma parte crítica da arquitetura do banco de dados. Se você não souber a data/hora exata de quando cada registro foi adicionado, juntamente com o nome da fonte (nome de usuário ou nome de arquivo) que adicionou os registros, você não está preparado para lidar com dados incorretos carregados em seu banco de dados de transações. Você deve se perguntar: “E se alguém nos enviar um arquivo ruim?” Quanto tempo você levaria para identificar os registros que vieram dele?

Armazém de dados

Existem duas teorias para o projeto de data warehouse. A diferença entre as teorias de Inmon e Kimball pode ser resumida da seguinte forma:

A teoria de Inmon é primeiro desenvolver um data warehouse e, em seguida, construir data marts dimensionais para relatórios do data warehouse. A teoria de Kimball é primeiro desenvolver data marts dimensionais para relatórios e depois mesclá-los para criar o data warehouse.

Você sempre deseja fornecer aos clientes o retorno mais rápido do investimento. Construir data marts é um processo simples. Você começa pegando as consultas por trás de seus relatórios e as altera de retornar conjuntos de resultados para armazenar os conjuntos de resultados em tabelas permanentes. Você simplesmente adiciona TRUNCATE TABLE tablename ; INSERT INTO tablename antes da palavra-chave SELECT original. Assim que você tiver algumas tabelas de data marts funcionais, a identificação de oportunidades para mesclar os data marts deve se encaixar; procure por consultas de relatório que usem a mesma lista de tabelas e, em seguida, mescle a lista de campos. Isso requer uma consulta mais complicada, especialmente quando a lista de tabelas aumenta. No entanto, desde que você esteja testando exaustivamente a consulta, cada alteração incremental pode ser feita sem interromper os processos normais de negócios.

Cada vez que você faz um aprimoramento em um projeto de data warehouse da Kimball, você tem a oportunidade de mostrar um ROI ao cliente. Isso ocorre porque o data warehouse é criado primeiro e os data marts de relatórios são criados a partir de um data warehouse estático. Portanto, você incorre na maioria de seus custos no início do projeto de data warehouse.

Cubo OLAP

Um cubo OLAP pode beneficiar uma organização fornecendo dados agregados com um tempo de resposta rápido, recursos de detalhamento ad-hoc para usuários finais e mineração de dados. Quando você tem um cubo OLAP adequado, pode extrair cada bit de valor de seus dados. Um cubo OLAP é construído sobre um data warehouse, mas usa uma linguagem diferente, MDX, de um banco de dados SQL padrão. Também requer um esforço de configuração mais complexo do que um servidor de banco de dados. Essa complexidade torna um projeto OLAP caro, além de ser difícil encontrar desenvolvedores MDX experientes.

Os arquitetos de dados às vezes veem os cubos OLAP existentes com nada mais do que um painel simples utilizando o cubo, sem um único processo que não possa ser substituído por uma consulta SQL, data warehouse ou relatório enlatado. Um cubo OLAP pode fornecer um tempo de resposta mais rápido do que um relatório pronto, mas na maioria das situações a diferença é insignificante. Você também pode se beneficiar dos recursos de detalhamento, no entanto, antes de fornecer recursos de detalhamento aos usuários finais, é uma boa ideia usar relatórios predefinidos que fornecem uma interface ad hoc semelhante.

Isso permite que você registre as consultas ad hoc que os usuários finais estão executando e, em seguida, pode identificar novos relatórios predefinidos que os usuários finais não perceberam que poderiam ser criados. Como as melhorias de tempo de resposta e de detalhamento geralmente são mínimas ao desenvolver um cubo OLAP, não é necessário sugerir isso a um cliente até que ele precise de uma arquitetura de banco de dados que possa lidar com a mineração de dados envolvida. É quando você pode realmente impressionar os clientes e mostrar a eles algo sobre seus negócios que eles talvez nunca soubessem sem uma arquitetura de banco de dados robusta.

Como mencionado anteriormente, construir um cubo OLAP pode ser um desafio. É uma boa política considerar um cubo OLAP híbrido. O PowerPivot do Microsoft Excel fornece ferramentas de mineração de dados fáceis de usar sem a complexidade de um cubo OLAP completo. A principal desvantagem de um híbrido é que ele não tem o mesmo tempo de resposta. No entanto, uma grande vantagem é que é mais fácil criar relatórios de mineração de dados usando o Excel em comparação com o MDX. Na mineração de dados, há três relatórios úteis. Podemos ver alguns exemplos do mundo real e como interpretá-los.

Todos esses relatórios são de um aplicativo automatizado de day trading construído pelo autor.

Relatórios visuais

Relatório de gráfico de dispersão

Um relatório de gráfico de dispersão é um relatório de nível de detalhe que compara duas variáveis. Adicionar cor e tamanho aos pontos reais ajuda a visualizar os resultados reais em relação a essas variáveis.

Relatório de caixa e bigodes

Este relatório resume os valores xey do relatório do gráfico de dispersão. Os valores do eixo x são discretizados em um conjunto de buckets.

As extremidades de cada bigode (linha) representam os outliers. As barras amarelas e azuis claras representam as faixas de desvio padrão superior e inferior.

Modelo de regressão linear

Este relatório mostra a correlação entre os valores dos eixos xey, juntamente com uma suavização da linha, que pode ser representada por uma fórmula matemática. O valor de R ao quadrado é incluído para mostrar quão confiável é a correlação.

Conclusão

À medida que sua empresa cresce, normalmente seu banco de dados também cresce.

A maioria das organizações não precisa inicialmente de um profissional de banco de dados ou empresa dedicada à ciência de dados para lidar com suas necessidades. Em vez disso, eles têm sua equipe de TI lidando com múltiplas responsabilidades ou, como diz o ditado, “usam muitos chapéus”. Isso funciona até certo ponto, mas, eventualmente, você precisa trazer especialistas.

Os itens listados neste documento são uma maneira rápida e fácil de identificar problemas de banco de dados dos quais você pode não estar ciente. Felizmente, também cobriu como você pode criar ferramentas de mineração de dados de alto nível sem gastar muito em licenças de software caras. Dessa forma, você terá uma ideia melhor de quanto sua organização pode se beneficiar ao adicionar um profissional de banco de dados à sua equipe de TI.