Oi! Seja bem-vindo!

Hoje vamos ver o que é data warehouse, porque interessa a você saber mais sobre essa tecnologia e porque as empresas investem milhões nisso…

Fato é, o DW (data warehouse ou armazém de dados), que antes era restrito a grandes empresas, realmente chegou para ficar no mercado das empresas médias, e você pode abocanhar uma fatia dos milhões investidos nessa área, se ficar antenado no mercado.

Mas pra começar, “o que é data warehouse” ou armazém de dados em português?

Nesse artigo vou te apresentar uma definição COMPLETA, PRÁTICA e SIMPLES sobre esse conceito, e te ajudar a decidir se interessa ou não a você ter um DW na sua empresa. Meu foco é que esse artigo seja o mais completo e ao mesmo tempo enxuto que você encontre por ai. 🙂

#1: Porque alguém precisa de um Data Warehouse (DW)?

Veja esse breve exemplo e você entenderá DW.

Imagine que você tem um banco SQL com 1 bilhão de linhas (por exemplo, 1 bilhão de vendas).

Quando uma empresa atinge um volume desses, normalmente existirão dois grupos de pessoas trabalhando com as informações:

== Frontend: Departamentos operacionais como o atendimento a clientes, que fazem a manutenção de dados (ex: inclusão, alteração e exclusão de novos produtos, clientes e vendas);

== Backend: Departamentos de controle, por exemplo o RH, que trabalham com informações sintetizadas (ou sumarizadas) para tomada de decisões e operação gerencial da empresa (ex: pagamento de comissões, recolhimento de impostos, etc).

No dia a dia, o frontend insere as informações “uma a uma” (ex: atendimento a clientes inserindo vendas), porém o backend (ex: RH) precisa “da soma das vendas de um colaborador” para poder calcular a folha de pagamento (ex: comissões). Isso cria uma divergência do “modelo ideal” de como as informações deveriam ser guardadas, concorda? Porque: As áreas de backend precisam das informações sintéticas (agrupadas), enquanto que as áreas de frontend, responsáveis pela inserção dos dados, trabalham com informações analíticas (uma a uma).

Quando temos um banco de dados único em nossa empresa, fazemos a transformação das informações analíticas para sintéticas através de relatórios que, de forma online, leem o nosso bilhão de vendas e agrupam as informações conforme a necessidade de cada área, certo?

Agora imagine o “tamanho da encrenca”, quando várias áreas de backend (ex: RH, financeiro, contabilidade, etc…) ficarem tirando relatórios “pesados” durante o dia, ao mesmo que as pessoas do frontend tentam “todas o dia a dia da empresa”…

A probabilidade é que o servidor vai “arriar” e o pessoal que está lá no caixa, por exemplo, e precisa que o servidor seja rápido para atender aos clientes, vai ficar com “uma raiva tremenda” de quem estiver tirando relatórios pesados lá no escritório… eu mesmo já ouvi muitas vezes pessoas falando “o sistema está uma carroça em???? No mínimo é o fulano tirando as porcarias de relatório dele”… 🙂

 

#2: Como atender a todos com performance:

Então como atender as áreas de frontend e backend de nossa empresa com performance satisfatória para todos?

Existem várias abordagens, as 4 principais seriam essas:

1) Melhorar o hardware do servidor de banco: Para converter as informações unitárias (analíticas) em totalizadas (sintéticas) é preciso poder de processamento. Então se melhorarmos o servidor de banco de dados, a tendência é que melhore a performance. Para uma empresa de pequeno e médio porte, essa solução é ótima, pois é rápida e prática. Para empresas de grande porte em geral já não serve, porque o hardware necessário para atender ficando muito caro ou simplesmente inviável.

 

2) Duplicar o banco de dados: Muitas empresas optam por fazer diariamente uma ou mais cópias do banco de produção e disponibilizar essas cópias apenas para consulta para as áreas de backend. Essa base naturalmente não vai conter os dados das transações de hoje, porém em geral, relatórios gerenciais não necessitam dos dados de hoje, o que eles precisam é do fechamento de ontem ou do mês passado, por exemplo. Nessa modalidade, o máximo que ocorre é um usuário tirando um relatório pesado ficar com raiva do outro que também está tirando um relatório pesado…kkkkk Mas ao menos a operação diária da empresa não é afetada.

= Vantagens:

– Solução fácil e barata de implementar comparado ao nível 3;

– Exige gerenciamento simples.

= Desvantagens:

– A montagem de relatórios ainda depende de alguém especializado que conheça bem SQL e a estrutura do banco de dados relacional, que a essa altura da sua empresa possivelmente seja complexa;

– Cada vez que alguém gera um relatório é feito um esforço computacional que não é reaproveitado. Em última análise gera custos de desgaste de equipamentos e energia elétrica.

 

3) Implantar um DW: Para resolver as 2 desvantagens do modelo 2, podemos implementar um DW, que nada mais é que uma base de dados com as informações salvas em um formato sumarizado, como as áreas de backend necessitam em seus relatórios e interfaces. Por exemplo: Ao invés de ter os valores de comissão espalhados em cada registro de vendas (como é na base de produção), o DW conterá uma tabela com os totais de comissão de cada vendedor. Veja no exemplo abaixo como faríamos isso de forma bem simplificada:

Banco de dados de produção – Tabela de vendas:

id	dt_venda	id_produto	id_vendedor	id_cliente	qtd
1	2014-06-01	3	10	1	5
2	2014-06-02	4	9	3	2
3	2014-06-02	3	7	5	1
4	2014-06-03	1	2	6	9

DW – Tabela de controle de metas:

mes_referencia	Produto	Meta	Vendas	%meta
Jan/2017	CPU Nasa 10Ghz	R$ 1.000.000,00	R$ 1.034.000,00	103.40%
Jan/2017	HD SSD 1TB	R$ 1.000.000,00	R$ 1.012.000,00	101.20%
Jan/2017	Monitor 32 pol full HD	R$ 500.000,00	R$ 537.000,00	107.40%

Observe que na tabela do DW os dados de venda estão sumarizados por mês, mas dependendo da necessidade da área, poderiam ser sintetizadas por dia, quinzena, semana, etc… Nesse exemplo você já pode ver que a estrutura da tabela ficou bem mais simples e é ai que os usuários passam a poder montar seus próprios relatórios usando SELECTs simples ao invés de complexos com inúmeros JOINS e agrupamentos.

 

4) Multiplos DWs: Naturalmente que para empresas grandes um só DW as vezes não atende por questões geográficas ou de performance… nesses casos nós da TI temos 3 alternativas:

a) Ampliar os servidores: Lembra da solução 1? Se melhorarmos o servidor do DW, melhora a performance.

b) Criar cópias do DW: Lembra da solução 2? Também é prática comum criar várias cópias do DW e disponibilizar um DW para cada área. Então nosso RH poderia ter uma cópia e nosso comercial outra…

c) Criar “sub-dws”: Se o seu DW for muito grande, ai o armazenamento ou transferência de dados pode ser um problema… Eita dores do crescimento… kkkkk Então temos uma terceira alternativa, que é “dividir” o nosso DW em DWs menores. Simplificando: você cria vários bancos de dados e distribui as tabelas de acordo com a necessidade de cada área. Por exemplo: A tabela de comissões pode não interessar ao comercial, então colocaremos ela somente no sub-DW do RH. Assim como a tabela de metas, se não interessar a contabilidade, podemos deixar só no sub-DW do comercial. O nome bonito para chamar um sub-DW no mundo de business intelligence é “data-mart”.

 

#3: Diferenças entre banco de produção e data warehouse (DW)

Um mito a desmitificar… Quase sempre, do ponto de vista administrativo, um DW não é mais ou menos complexo que um banco de dados normal, não tem nada de especial ou misterioso, se você trabalha com bancos normais você trabalha com DW!

Existem parâmetros de performance e configuração que mudam de um ambiente para outro, porém para quem está começando agora, isso não é relevante.

Entretanto, é importante saber que existem tipos de DW (ex: ROLAP, MOLAP, HOLAP), os quais defino abaixo.

 

#4: Termos bonitos para Impressionar e fazer PowerPoints 🙂

– Operational data store (ODS): Sua base de produção. O banco de dados que guarda as informações do dia a dia. Em geral é organizado na estrutura relacional, que prioriza a manutenção de dados (insert, update, delete).

– Data warehouse (DW): Seu banco de dados de consultas e analises gerenciais. Guarda as informações do dia a dia sumarizadas e/ou organizadas para priorizar a extração e analise de informações (select). Pode ser organizado de forma relacional ou dimensional.

– Data mart: Sub-divisão do DW. Conjunto de tabelas que fazem sentido ficar juntas em um banco de dados especializado para determinada área de negócios.

– OLTP: Online Transactional Processing. Nome chique para os processos que ocorrem em sua base de produção. Exemplo: inserção, alteração e exclusão de vendas, produtos e clientes.

– OLAP: Online Analytical Processing. Nome chique para os processos que ocorrem no seu DW. Exemplo: Comparar quanto nossa empresa vendeu no ano passado comparado com esse ano.

– Banco relacional (relational database): É um banco de dados organizado para favorecer a manipulação de dados através de INSERTs, UPDATEs e DELETEs.

– Banco dimencional (domentinal database): É um banco de dados organizado para favorecer a extração de informações através de SELECTs.

– ROLAP: Relational Online Analytical Processing. É um banco relacional, porém com tabelas organizadas (ou normalizadas na nomenclatura de banco de dados) de forma a favorecer a extração de dados (SELECTS).

– MOLAP: Multidimensional Online Analytical Processing. É um banco de dados dimensional, que por natureza favorece SELECTs. No mundo do SQL trata-se do SSAS (ver abaixo). Além da extração direta de informações, o legal dos MOLAPs é que possibilitam guardar “consultas” pré-processadas o que obviamente aumenta a performance. O legal dessas consultas é que elas podem ser armazenadas fora do banco de dados, inclusive na máquina do usuário, o que reduz trafego de rede e consumo de recursos compartilhados. O nome bonito para chamar os dados que vem dessas consultas pré-processadas é o tal de “cubo de dados”.

– HOLAP: Hybrid Online Analytical Processing: Um banco de dados que possui benefícios dos dois mundos: MOLAP e ROLAP.

– Mineração de dados (Data mining): Nome bonito para quem está procurando informações “minerando dados”.

– Metadados: Dados que dão informações sobre o que está armazenado em nosso banco. Por exemplo, os nomes e tipos de dados das colunas de uma tabela, são metadados (dados sobre os dados).

– ETL: Extract, transform and Load: Nome chique para levar os dados analíticos de sua produção para o seu DW, onde os dados estão organizados sinteticamente. Processo de extrair dados de um lugar, eventualmente converte-los de alguma forma e carrega-los em outro. Quando você extrai dados de seu banco de dados de produção e carrega uma cópia no seu DW você está fazendo um ETL. Quando você retira dados das tabelas e salva em um arquivo texto também é ETL.

– SSIS: SQL Server Integration Services: Software de ETL da Microsoft.

– SSAS: SQL Server Analises Service: MOLAP/HOLAP da Microsoft.

 

#5: O que é data warehouse

Após essa breve dissertação, apresento-lhe a definição mais direta que já encontrei: É um banco de dados especializado em consultas e analises gerenciais.

Enquanto que os bancos de dados transacionais são projetados para alta performance em operações de insert, update e delete, os data warehouses são projetados para select.

 

CONCLUSÃO

Pronto! Agora você já sabe o que precisa para começar um projeto de DW (ou talvez não começar, pois você viu nem todas as empresas precisam de um armazém de dados).

Agora falta só ir para a internet e procurar umas figuras bonitas para colocar no seu powerpoint…. kkkkk

Abraço do seu amigo Josué 🙂