Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

Quer saber o segredo para, ao invés de demorar 6 meses na entrega de um Data Warehouse, levar 1 mês só?

O Agile Data Warehouse Design é uma metodologia de desenvolvimento ágil para criação de Data Warehouse.

A ideia é diminuir as horas e horas de reuniões improdutivas e focar no que realmente precisamos levantar para desenhar o Data Warehouse.

Mas vamos por partes.

Hoje em dia mais ninguém tem tempo para esperar. E se para nós é assim, imagina para o cliente que precisa tomar uma decisão e não tem os benditos dados que precisa?

Isso nos deixa com 2 problemas:

  1. O cara não está disposto a esperar 1 ano até o Data Warehouse estar pronto
  2. Ele não vai ter tempo para fazer todas as milhares de reuniões que você precisa

 

E como eu resolvo isso?

Vou apresentar aqui o 5W3H. Se você teve algum contato com a área de administração, já deve ter ouvido falar no 5W2H. A ideia é parecida, mas fiz uma adaptação nela para metodologias ágeis de desenvolvimento de Data Warehouse.

Para isso eu monto um mapa mental. Obviamente, você pode utilizar outro tipo de ferramenta. Eu utilizo o mapa mental porque fica organizado e fácil de visualizar, o que é bom tanto pra você como para o cliente.

Fica assim:

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

A aparência é amigável e com perguntas que os Key Users estão acostumados a ver no dia a dia.

Lembra sempre que a obrigação da tomada de decisão correta é sua. Embora o cliente deva saber o que ele quer, você, como consultor, tem que saber extrair as melhores respostas.

Por mais que a criação de um Data Warehouse pareça simples ou cotidiana para você, para o cliente não é, então ele nem sempre vai saber te dar as melhores respostas.

 

Tá, mas como eu uso isso?

Eu sempre compartilho o próprio mapa mental online com o cliente, assim não precisa estar todo mundo junto naquelas benditas reuniões que é sempre difícil de colocar todo mundo no mesmo lugar no mesmo horário.

A sacada é que as pessoas recebam esse mapa primeiro, antes da reunião, para começar a entender o que você precisa. Assim, elas mesmas já podem começar a preencher algumas informações direto no mapa mental.

Vai tentar pegar o tempo do VP, diretor financeiro ou gerentes, os caras estão sempre correndo. Aí você compartilha uma ferramenta assim, bem simples. Já peguei vários clientes que entre uma reunião e outra abriam o aplicativo, davam uma olhada, comentavam alguma coisa e viam o que o resto do time já tinha colocado.

Então todo mundo estava olhando a mesma coisa e sem nenhuma reunião até agora.

Quando você finalmente for fazer a reunião, pode abrir esse mesmo mapa mental que já está com as respostas do pessoal e começar a bater as perguntas. E mesmo que não dê tempo de todos preencherem tudo, pelo menos já vão saber do que se trata, não vão estar tão confusos na reunião. A gente trabalha com pessoas, precisamos entender isso. Aí na reunião você começa a passar as perguntas uma a uma.

Eu coloquei as perguntas na ordem que eu prefiro fazer, porque foi a ordem que identifiquei ser a melhor nos projetos que usei essa estratégia. Mas é claro, você pode trocar para como fizer mais sentido no seu projeto.

Algumas perguntas não fazem sentido para determinados tipos de negócio e vai ter outras que o cliente realmente não quer porque não interessa para ele, então tem coisas que você pode pular sem problema nenhum.

 

Agora, o passo a passo

A primeira pergunta que você deve fazer é a do centro.

Qual fato aconteceu?

Vou usar um exemplo aqui de venda.

Qual é o fato que aconteceu? Uma venda.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

E aí isso já é a tabela fato? Pois é, a tabela fato se chama fato porque aconteceu um fato.

Depois, você vai seguindo de acordo com os números.

 

#1 – What – o quê / do quê?

Aqui você pode usar um template para completar e deixar mais fácil de entender a frase:

Template: Aconteceu _________. Do quê?

Vai ficar como?

Aconteceu uma venda. Do quê? De Coca-cola.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

Aí já respondemos a primeira pergunta.

É só isso? É só isso.

Depois é só ir aplicando o mesmo estilo de template para todas as perguntas.

 

#2 When – quando?

Template: Aconteceu _________. Quando?

Aconteceu uma venda. Quando? 31/02/2017.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

#3 Where – onde?

Template: Aconteceu _________. Onde?

Aconteceu uma venda. Onde? Na loja de São Paulo.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

#4 Who – quem?

Nesse podemos ter várias interpretações. Você precisa entender o conceito e então ir colocando de acordo com o negócio em questão. “Quem” é a pessoa envolvida, e ela pode estar envolvida com o fato em papéis diferentes.
Alguns exemplos:

Template:
Aconteceu _________. Para quem?
Aconteceu _________. Quem fez?
Aconteceu _________. Quem entregou?

Para quem foi a venda? Pro Rafael Piton.
Quem fez a venda? Vendedora Joana.
Quem entregou? TNT Transportadora Mercúrio.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

#5 How – como?

Template: Aconteceu _________. Como?

Aconteceu uma venda. Como? Através do site.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

#6 Why – por quê?

Template: Aconteceu _________. Por quê?

Aconteceu uma venda. Por quê? Por causa de uma promoção de natal.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

#7 How often – com que frequência?

Template: Aconteceu _________. Com que frequência?

Aconteceu uma venda. Com que frequência? 2x por mês.

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

Aqui a frequência é diferente da data, porque a data é quando cada uma das vendas aconteceu, e a frequência mostra o espaço de tempo entre elas.

Com a frequência, a gente consegue saber qual a periodicidade da carga, com que frequência vai precisar carregar os dados.

 

#8 How many – quanto / quantas vezes?

Aqui é onde você vai identificar as métricas.

Template: Aconteceu _________. Quantas Vezes?

Aconteceu uma venda. Quantas Vezes? 200 (vendas).

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

Só com essas perguntas você já tem uns 80% do seu modelo dimensional pronto.

 

E os outros 20%?

Agora você precisa definir as dimensões e seus atributos.

Mas é muito simples fazer isso já tendo o mapa preenchido dessa forma. É diferente de quando você começa um projeto e vai pensando em dimensão por dimensão e perdendo um baita tempo em entrevistas.

Agora imagina que você já tem todas essas informações e os envolvidos do fato que aconteceu presentes.

Quando aconteceu uma venda, quem são os envolvidos na venda? O time de marketing, time de vendas, talvez o time financeiro também faça alguma parte.

Agora, sua missão é: depois que toda essa galera estiver reunida e entender o conceito desse mapa mental, cada um pode colocar o que entende disso para então chegar em um consenso.

 

Mas na prática como é?

Aqui você começa a fazer as perguntas para saber o que os Key User esperam de uma dimensão, por exemplo, de produtos (que você identificou lá na pergunta #1).

Você nem precisa falar em dimensão para não complicar a conversa.

Pergunta assim: Nessa primeira pergunta você respondeu “Coca-cola”, que é um produto. O que você gostaria de analisar do produto?

Você vai pegar informações como:

  • Coca-cola é o nome do produto
  • Você vai precisar também do código daquele produto para fazer algum relatório
  • Aí vem o cara lá do marketing e diz que eles precisam saber a marca desse produto
  • O cara da logística vai dizer que precisa saber qual o peso do produto para planejar o caminhão, para saber se tem espaço em armazenagem, e inclusive precisa ter a unidade de medida daquele produto
  • Depois vem o financeiro, que quer saber qual o preço unitário do produto

 

Imagem: Rafael Piton – Data Warehouse – Passo a Passo para Modelar um Data Warehouse

 

Fazendo as perguntas certas fica fácil de entender o que o negócio precisa. É claro que você sabe que essa dimensão depois vai ter uma Surrogate Key e uma Natural Key, mas não é o momento de pensar nisso, por enquanto você está falando com o Key User, que é o cara de negócio, e essa é a abordagem mais simples e rápida possível.

 

Alertas: 2 coisas que podem estragar seu projeto
  1. Às vezes algum diretor ou gerente não vai poder estar na reunião ou participar do levantamento de requisitos e vai mandar alguém para representar ele. Esse diretor ou gerente que não foi é um Key User, e é muito importante que a pessoa que estiver no lugar dele tenha conhecimento o suficiente do negócio para responder essas perguntas. Se não, você vai acabar com informações capengas.
  2. Projeto de Data Warehouse não é projeto de TI. Projeto de Data Warehouse é projeto de negócio. Já to careca de ver projeto de Data Warehouse/BI em que a equipe fica socada junto com a TI dentro de um porão achando que é só pegar dados e jogar em um banco de dados. Erro total.

 

Esse planejamento é extremamente importante. Empresas grandes e mais maduras já entendem o poder disso. Várias das empresas grandes pelas quais eu passei têm essa ideia de business first, então é sempre o negócio que está em foco, e não a TI. O importante agora não é saber se o cara já tem o dado coletado, se o banco aceita select ou se é MDX, isso é para outra hora.

Eu usei o mapa mental como exemplo porque é como eu gosto de usar, mas você precisa entender mesmo é a ideia para poder aplicar da forma que for melhor para você e o cliente.

Se entender a estratégia, vai poder aplicar ela da forma que for, porque é muito simples, basta seguir esse passo a passo e você vai conseguir entregar um Data Warehouse muito mais rápido e menos suscetível a falhas do que está acostumado.

 

Artigo e imagens publicados originalmente no blog Rafael Piton. Data Warehouse – Passo a Passo para Modelar um Data Warehouse; autor: Rafael Piton, publicado em 25/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – O Que É?
Data Warehouse – Para Que Serve?
Data Warehouse – Por Que Você Deve Aprender?
Data Warehouse – Modelagem Dimensional
Data Warehouse – O Que É Star Schema?

Read More

Data Warehouse – O Que É Star Schema?

Imagem: Rafael Piton – Data Warehouse – O Que É Star Schema?

 

A modelagem dimensional é utilizada para melhorar a performance de sistemas voltados para consulta. E o modelo mais utilizado para isso é o Star Schema ou Modelo Estrela, que foi idealizado por Ralph Kimball para dar suporte à tomada de decisão.

O modelo estrela é composto no centro por uma tabela fato que é rodeada por tabelas de dimensão, ficando parecido com a forma de uma estrela (que é de onde vem o nome do modelo).

A ideia do Kimball é propor uma visão para modelagem de base de dados para sistemas de apoio à decisão, que é o caso do Data Warehouse.

As metodologias usadas para criação de Data Warehouse são Star Schema e Snowflake, que é defendido pelo Bill Inmon.

O Snowflake também é projetado para suportar tomada de decisão, mas economizando espaço em disco. Para o Star Schema, o Snowflake é apenas mais um tipo de dimensão.

Embora o Star Schema ocupe mais espaço em disco, ele é mais fácil de implementar e acabou sendo mais utilizado porque além de hoje em dia o espaço ser muito barato, ele permite entregar projetos por pedacinhos. Você pode criar um assunto ou departamento em uma estrela para só depois projetar outro, e assim por diante.

Na maioria esmagadora dos projetos, Star Schema é uma excelente escolha.

 

Onde isso entra no Data Warehouse?

O Data Warehouse é um conjunto de modelos, vários modelos estrelas.

Embora os Star Schemas sejam feitos pensando em um modelo de entrega rápido, o foco é sempre no Data Warehouse, para depois conectar as dimensões, porque você não pode ter dimensões iguais.

No modelo de Star Schema você pode entender que o Data Mart é uma coisa mais processual, focado em um assunto só.

 

E o que vai em um Star Schema?
Tabela Fato

A tabela fato armazena o que ocorreu, é o fato propriamente dito, por isso ela tem esse nome, porque é o fato ocorrido. A tabela fato está sempre ligada a duas ou mais dimensões, não existe tabela fato com menos de duas dimensões.

A fato é a principal tabela do Data Warehouse, e você pode ter uma ou mais tabelas fato.

 

Imagem: Rafael Piton – Tabela Fato (Data Warehouse – O Que É Star Schema?)

 

Essa tabela armazena 2 coisas:

  • Os fatos ocorridos, ou seja, as métricas
  • As chaves para as dimensões

 

Ou seja, a fato é composta por alguma métrica e os códigos das dimensões.

 

E o que é métrica?

Métrica é também chamada de quantificador ou medida. Alguns chamam de KPI, mas KPI também pode ser considerado um cálculo entre duas métricas.

Elas são utilizadas para metrificar algo e sempre são números, porque precisam ser contáveis. Esses números são provenientes de transações da empresa.

Por exemplo:
Hoje eu tomei 5 cafés
Métrica: quantidade de cafés bebidos (5 nesse caso)

Dá para fazer uma análise com ela, por exemplo, no tempo: nos últimos 30 dias, que dias eu tomei mais café?

Tudo que a empresa for mensurar é uma métrica. Na maioria das vezes, a métrica vai ser o que o usuário quer medir.

Pergunta para o usuário: o que tu quer medir, que informação quer ver na tela?

Normalmente o cara vai responder: quero ver as vendas, meus seguidores no twitter, quanto que a gente tem de fluxo de caixa, etc…

Você identifica muito fácil quais são as métricas só com essas perguntas.

 

Então qual que é a diferença de uma métrica para um KPI?

O KPI na sua essência são duas métricas relacionadas entre si, pode ter sido uma dividida ou multiplicada pela outra, e geralmente precisa ter meta.

Por exemplo:
a quantidade de café que eu tomo por dia dividido pela quantidade de horas que eu durmo.
Porque quanto mais café eu tomo, menos eu durmo.
Dá para criar um KPI do meu sono de acordo com a quantidade de café que eu tomo.

 

Tabela dimensão

Dimensão, também chamado de qualificador, descreve o fato ocorrido, ela contém as características do evento.

Por exemplo, quando eu faço uma venda, quero saber por onde a venda foi feita, que produto foi vendido ou para quem.

Elas vão qualificar, classificar ou descrever os dados que estão nas fatos, ou seja, as métricas.

Para identificar as dimensões, normalmente perguntamos pelo que o usuário quer mensurar uma informação. Elas vão ser toda e qualquer informação que qualifique uma métrica ou medida.

Por exemplo:
Preciso medir as vendas.
Ótimo, mas pelo quê?
Pela empresa / pelo produto / pelas filiais / por dia

Você também pode usar a pergunta de quais filtros o usuário gostaria de ter naquela visão.

Por que filtros?

Imagina que você tem uma tela com um menuzinho e o usuário pode escolher: eu quero um relatório por produto.

Aí ele clica naquela setinha e tem a lista de todos os produtos. Ele seleciona um deles e mostra um gráfico com as vendas só de tênis, por exemplo.

Esses filtros na maioria dos casos vão ser as dimensões. E embora nem todo filtro seja uma dimensão, podem ser dimensões candidatas, que ainda não foram colocadas no modelo mas são candidatas a se tornar dimensões.

As dimensões armazenam 3 coisas:

  • A Surrogate Key
  • A Natural Key
  • Os atributos

 

Imagem: Rafael Piton – Tabela-Dimensão (Data Warehouse – O Que É Star Schema?)

 

O quê?

Para ser rápida, a fato só armazena os número brutos. O atributo é o que qualifica as métricas, porque elas jogadas lá na fato sozinhas não servem de nada, não dá para tomar decisão nenhuma.

Os atributos podem ser campos como cidade, estado, país, etc.

Quanto às chaves, a Surrogate Key é uma Primary Key na dimensão. É uma chave artificial auto incremental, ou seja, toda vez que ela é chamada, adiciona um número e vai somando.

Já a Natural Key é a Primary Key daquele dado na origem ou legado, é o que você vai usar para identificar de onde aquele dado veio.

 

E o que você precisa saber antes de poder criar essas tabelas

Hierarquia

Hierarquia é o conjunto de atributos que possui uma ordem lógica do maior ao menor nível.

A hierarquia balanceada, que é a mais utilizada, é qualquer classificação que tenha como base as relações entre superiores e dependentes.

Por exemplo, do avô ao neto ou do general ao soldado.

Ela requer sempre uma relação de pai-filho, onde o superior pode ter zero, um ou muitos dependentes, mas os dependentes devem ter um e um único superior.

A hierarquia existe apenas nas dimensões, porque a métrica é só um valor, e quem vai dizer se esse valor está correspondendo a um determinado nível da hierarquia é o atributo.

O comum é existir apenas uma hierarquia por dimensão, mas pode existir múltiplas se for necessário.

 

Grão

O grão, também chamado de detalhe, é o menor nível da hierarquia da dimensão. É a informação base, o menor detalhe da informação.

É extremamente importante entender o que é o grão e como definir ele, porque se for mal planejado, vai acabar com todo o projeto.

Mas o que é esse grão?

Em uma dimensão de tempo, nós podemos ter uma hierarquia com ano, mês e dia. O dia é o menor nível, isso é o grão.

Em uma dimensão com diretoria, gerência, departamento e pessoa, a pessoa é o menor nível de detalhamento.

E por que é tão importante?

Ele é o nível mais atômico, o mais detalhado, e é no nível mais atômico em que será armazenada a informação, sem a oportunidade de “descer” mais um nível.

Imagina que o mês seja meu grão. Nesse caso, só posso contemplar ano e mês. Se depois lá na frente perceber que preciso descer para dia, não vai dar.

Aí precisa mexer em tudo, refazer as cargas e rever todo o modelo, porque o grão parou no mês.

Você precisa identificar qual o menor dado necessário, porque quanto menor for o nível do grão, mais ETL terá para fazer e mais demorado será, então não adianta colocar sempre o menor possível para tentar evitar o erro.

 

E como isso tudo se encontra?

Depois que você definiu suas dimensões, vai fazer um join com a tabela fato. É nesse momento que a Foreign Key da fato vai lá e conecta na Surrogate Key da dimensão.

Fica assim:

 

Imagem: Rafael Piton – Tabela Fato e Tabela Dimensão (Data Warehouse – O Que É Star Schema?)

 

Agora você sabe que aquele “200,00”, que é a métrica, pertence ao produto de chave “2” na dimensão de produto.

E assim você vai pegando as Surrogate Keys de todas as dimensões e dando sentido àquela métrica na tabela fato.

É importante você entender todos esses conceitos antes de começar a pôr a mão na massa, pois mesmo utilizando ferramentas, você ainda vai precisar entender a teoria para modelar o Star Schema.

Então, primeiro entenda bem essa parte que no próximo post o assunto será aprofundado um pouco mais e trará um passo a passo para a criação do Data Warehouse.

 

Artigo e imagens publicados originalmente no blog Rafael Piton. Data Warehouse – O Que É Star Schema?; autor: Rafael Piton, publicado em  23/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – O Que É?
Data Warehouse – Para Que Serve?
Data Warehouse – Por Que Você Deve Aprender?
Data Warehouse – Modelagem Dimensional
Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Read More

Data Warehouse – Modelagem Dimensional

Imagem: Rafael Piton – Data Warehouse – Modelagem Dimensional

 

Nos posts anteriores dessa série Rafael Piton já explicou sobre o que é um Data Warehouse, para que ele serve e porque você deve aprender mais sobre ele.

Agora vai ser explicado melhor sobre por onde você deve começar, que é a modelagem dimensional.

Mas antes de começarmos você precisa entender a diferença entre dados normalizados e desnormalizados.

 

Dados normalizados X dados desnormalizados

Os dados normalizados estão na terceira forma normal, utilizada em banco de dados relacional. Se você fez alguma faculdade em TI, provavelmente aprendeu sobre esse tipo de modelagem.

Eles permitem um armazenamento consistente e acesso eficiente aos dados. Essa forma reduz a redundância de dados e as chances de inconsistência. Esse estilo de banco tem como foco inserir, alterar e deletar os dados.

Já os desnormalizados, que é com o que nós trabalhamos, têm foco na consulta.

As consultas feitas em bancos de dados totalmente normalizados têm um mau desempenho, e para isso se usa a desnormalização: para melhorar o desempenho das consultas.

Mas claro, com um custo: com ela não temos a garantia de consistências dos dados, além de termos um banco muito maior.

O objetivo dos dados desnormalizados é entregar informação, é um sistema informacional, feito para ter uma consulta rápida. Vai ter redundância de dados, mas vai ser mais rápido.

 

Mas como funciona isso?

Em um banco normalizado, ou relacional, temos diversas tabelas, cada uma com sua chave primária e informações. Por exemplo, temos uma tabela “cidade” com o ID da cidade e o nome dela, e outra tabela “cliente” com o ID do cliente, o nome dele e a cidade onde mora. Mas nesse último item, ao invés de termos o nome da cidade registrado, temos o ID referente àquela cidade na tabela “cidade”.

Isso serve para evitar a redundância, evitando a repetição do mesmo nome diversas vezes e garantindo que o nome da cidade estará escrito sempre da mesma forma para todos os clientes.

No caso dos dados desnormalizados, nós temos o nome da cidade registrado na tabela de clientes, uma vez para cada cliente que morar naquela mesma cidade, o que aumenta muito o tamanho do banco e não garante tanta consistência dos dados.

Num modelo transacional, ou sistema operacional, você tem que ter integridade dos dados, eles não podem se repetir. Já no modelo dimensional, eles podem. Na verdade, eles devem.

Os mesmos dados se repetem em vários lugares, porque nesse caso ele é desenhado para melhorar o desempenho das consultas, porque o Data Warehouse é feito para consulta, enquanto o operacional é feito para transação.

 

Entendi. Mas e a modelagem dimensional?

Modelo dimensional é uma das técnicas e conhecimentos mais importantes que você precisa ter para modelar o Data Warehouse, o Data Mart ou o que for.

O modelo dimensional existe há muito mais tempo que você imagina, e provavelmente, você que não conhece modelo dimensional, já até usou e não sabe.

Até para utilizar ferramentas, na parte de modelar os metadados ou cubos OLAP, você vai precisar entender de modelagem dimensional, a não ser que você utilize outro tipo de arquitetura de modelo de dados.

Existem dois tipos de metodologias de modelagem de dados usadas no Data Warehouse, a Snowflake e a Star Schema, que é a mais utilizada.

 

Star o quê?

O conceito de Star Schema, ou modelo estrela, foi idealizado por Ralph Kimball.

A ideia dele é propor uma visão para modelagem de base de dados para sistemas de apoio à decisão. Lembra que o Data Warehouse suporta a tomada de decisão e a modelagem dimensional também? O Star Schema, na sua essência, é isso.

Imagem: Rafael Piton – Data Warehouse – Modelagem Dimensional

 

O modelo estrela é composto no centro por uma tabela fato, que é rodeada por dimensões. Por isso que tem o nome de Star Schema, porque parece uma estrela.

Todo esse nome bonito, modelagem dimensional, para eu te mostrar uma estrela? Pois é.

O mercado complica muito as coisas. Para quem já me conhece, sabe que eu não gosto de enrolação, gosto da coisa muito prática e objetiva. Tem por aí muita gente que adora uma teoria, mas a base fundamental é o modelo Star Schema.

 

E aquelas tabelas fato e dimensão?

No Star Schema os dados são modelados em tabelas dimensionais, ligadas a uma fato.

As tabelas dimensão contêm as características de um evento. Por exemplo, quando eu faço uma venda, quero saber por onde a venda foi feita, que produto foi vendido, ou para quem.

Já a tabela fato armazena o que ocorreu, é o fato propriamente dito, por isso ela tem esse nome, porque é o fato ocorrido. A tabela fato está sempre ligada a duas ou mais dimensões, não existe tabela fato com menos de duas dimensões.

A tabela fato conecta com as dimensões e isso forma o modelo dimensional. Ela também é a principal tabela no modelo dimensional.

Quando são feitas consultas, elas ocorrem primeiro nas tabelas de dimensão e depois na fato. É comum quem trabalha com BI acreditar que a consulta começa pela fato, mas você não vai cometer esse erro.

É na tabela fato onde as métricas são armazenadas. Mas isso é conversa para outra hora.

Por enquanto, você precisa entender bem o conceito da modelagem dimensional, para então começar a se aprofundar mais no modelo Star Schema, nos tipos de fatos, de dimensões, métricas, grão, hierarquia e por aí vai, aqui está só o começo.

 

Artigo e imagens publicados originalmente no blog Rafael Piton. Data Warehouse – Modelagem Dimensional; autor: Rafael Piton, publicado em 18/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – O Que É?
Data Warehouse – Para Que Serve?
Data Warehouse – Por Que Você Deve Aprender?
Data Warehouse – O Que É Star Schema?
Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Read More

Data Warehouse – Por Que Você Deve Aprender?

Imagem: Rafael Piton – Data Warehouse – Por Que Você Deve Aprender?

 

O mercado de trabalho é acirrado, e por isso precisamos melhorar constantemente, estar sempre à frente da concorrência.

No mercado de BI é comum vermos gente que não entende os conceitos básicos ou não sabe seu real objetivo. Simplesmente trabalha com BI por influência ou porque apareceu alguma oportunidade na empresa, e ele aprendeu a fazer um relatório achando que isso é BI.

Além disso, também é feita muita confusão entre os conceitos de Business Intelligence e Data Warehouse, assim como entre a diferença de DW e Data Mart.

Com a quantidade de ferramentas de BI surgindo, muita gente acredita que pagar um serviço ou ferramenta vai ser o suficiente para fazer uma solução funcional, mas antes de conseguir realmente criar algo, você precisa entender os conceitos básicos.

É comum pessoas partirem direto para a parte de pôr a mão na massa e esquecerem dos fundamentos. E onde isso implica?

Na hora de fazer o levantamento de requisitos com os setores, gerentes e key users.

Se qualquer pessoa na empresa que tenha uma noção de negócio e tomada de decisão ver que você não sabe do que se trata uma tomada de decisão, eles não acreditarão em você para pôr esse projeto em prática.

Essas pessoas são seus key users, e eles e os patrocinadores precisam acreditar no projeto (e em você) para que ele tenha continuidade.

 

Então, por que você deve aprender mais sobre Data Warehouse

Para começar, porque é o primeiro passo que você precisa dar para entrar no mercado de BI. E segundo, porque se você cometer algum erro nessa parte, vai comprometer todo o projeto.

Você precisa dominar a arquitetura e modelagem de um Data Warehouse.

Você precisa garantir:

  • Que o DW será adaptável e flexível às várias fontes de informação
  • Que o DW será escalável e evolutivo (e você tem que saber planejar essa evolução)
  • Que terá controle do acesso aos dados
  • Que o proprietário terá uma visibilidade da forma que os dados estão sendo utilizados
  • Que além de pôr segurança nos painéis e análises, também garantirá a segurança nas informações

 

O Data Warehouse não é desenhado apenas uma vez para ser usado sempre, ele vive em constante alteração. E você precisa garantir que essas alterações poderão ser feitas. Quando chegar uma nova demanda para a equipe de BI implementar, tanto a ferramenta quanto o banco devem suportar as novas respostas sem problemas.

Você não pode esperar que o Data Warehouse vá ser refeito toda vez que alguma alteração for necessária. Basicamente, ele precisa ser flexível para sofrer alterações contínuas.

 

Tá, mas como era aquela história de comprometer todo o projeto mesmo?

O Data Warehouse é o ponto central, a cabeça do negócio, então é obrigatório que ele esteja bom.

Dentre as partes mais críticas estão as de definição de requisitos e da modelagem dimensional. E se você errar isso, vai errar na construção do DW e dos Data Marts.

Além disso, se o DW estiver uma carroça e o cubo não obtiver resposta para uma consulta, é trabalho em vão.

De nada adianta você saber muito sobre ETL ou criação de cubos se não tiver uma boa habilidade na modelagem do Data Warehouse. Ele é a base do projeto todo, então se pecar nessa parte, o projeto vai estar comprometido e esse conhecimento todo que você tem não vai servir de nada.

 

E o que uma empresa espera quando contrata alguém para criar uma solução de BI?

Empresas precisam tomar decisões importantes diariamente. Seu trabalho como consultor de BI é auxiliar os responsáveis pelas decisões entregando relatórios e dashboards com informações atualizadas e, principalmente, corretas.

O Data Warehouse tem a missão de dar suporte à tomada de decisão. Então você precisa garantir que isso será feito corretamente. De nada vai adiantar a empresa ter milhares de dados se na hora que você modelar o Data Warehouse eles não forem bem aproveitados, porque é isso que garante que serão devidamente transformados em informação.

Se você se basear só no que já existe e fizer algo igual ao transacional, vai acabar limitado sem ter todas as análises que você precisa, e então vai tomar decisão baseada em quê?

Solução de BI custa caro, e isso não é à toa. Enquanto você trabalhar com dados e informações gerenciais de outras pessoas, você não será um trabalhador comum.

Por quê?

Imagina assim, você daria o acesso da sua conta do banco para outra pessoa ver seu extrato?

Porque é isso que as empresas fazem, elas dão acesso a todas as informações para você fazer o que precisar. E quem garante que você não vai colocar uma regra que envia um e-mail com todos os dados para alguém?

É por causa dessa responsabilidade que as empresas estão dispostas a pagar tanto por soluções de BI. E é também por causa dela que exigem profissionais tão qualificados, e não só geradores de relatórios.

No mercado de BI, você tem possibilidade de crescer muito, mas vai precisar estar devidamente qualificado para isso.

 

Artigo e imagem publicados originalmente no blog Rafael Piton. Data Warehouse – Por Que Você Deve Aprender?; autor: Rafael Piton, publicado em 16/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – O Que É?
Data Warehouse – Para Que Serve?
Data Warehouse – Modelagem Dimensional
Data Warehouse – O Que É Star Schema?
Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Read More

Data Warehouse – Para Que Serve?

Imagem: Rafael Piton – Para que serve o Data Warehouse

 

Tá cansado de discutir com os planilheiros de plantão que nunca conseguem chegar em um acordo sobre quais relatórios que estão com os dados corretos?

É pra isso que serve o Data Warehouse.

É esse cara que centraliza os dados da empresa e elimina os ruídos de comunicação entre os departamentos, deixando tudo unificado. É a parte mais crítica de um projeto de BI. Mas caso você ainda não saiba o que é um Data Warehouse, no primeiro post dessa série Rafael Piton explica isso melhor e mostra como os dados chegam até lá.

Mas sabendo isso, vamos partir pra onde utilizá-lo.

 

O objetivo principal do Data Warehouse é garantir a entrega de dados confiáveis para dar suporte à tomada de decisão.

 

Depois que os dados são retirados dos locais de origem, como planilhas, ERPs e CRMs e são transferidos para o Data Warehouse, você passa a ter todas as informações em um único local, que foi criado com foco na consulta. Então, além de os dados já estarem todos organizados e atualizados, consultá-los é muito rápido.

 

Mas então, o que eu faço com esse Data Warehouse?
  • Apresenta e analisa eventos passados, podendo tomar decisões mais precisas com eles
  • Entrega as informações corretas para as pessoas certas no tempo ideal
  • Controla globalmente a visibilidade das informações e sabe onde estão sendo utilizados e por quem
  • Garante a unicidade de conceitos e regras de negócio e a confiabilidade dos dados entre todos os setores da empresa
  • Obtém respostas muito rápidas a consultas feitas em uma base com grande volume de dados
  • Como os dados agora estão centralizados, você gera relatórios com informações reais e atualizadas

 

O Data Warehouse é feito pensando nas necessidades do negócio. Existe para unir e dar sentido a todos os dados de forma que seja possível extrair os relatórios ou dashboards que se precisa.

É adaptável e flexível às várias fontes de dados, além de ser desenhado para sofrer alterações contínuas, garantindo que vai continuar a atender as necessidades da empresa.

Assim, além de garantir que todas informações estão centralizadas, você também garante que todas as permissões de acesso estão corretas, e que os critérios e regras, com os quais os dados estão sendo trabalhados, são únicos.

É só depois de ter o Data Warehouse modelado e pronto que você vai poder dar sequência à implantação da solução de BI na empresa, e é por isso que um profissional que saiba modelar um Data Warehouse livre de falhas é tão procurado no mercado, porque é ele quem garante que os dados estão sendo organizados corretamente e que depois vai ser possível criar os cubos e dashboards como necessário.

 

Artigo e imagem publicados originalmente no blog Rafael Piton. Data Warehouse – Para Que Serve?; autor: Rafael Piton, publicado em 11/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – O Que É?
Data Warehouse – Por Que Você Deve Aprender?
Data Warehouse – Modelagem Dimensional
Data Warehouse – O Que É Star Schema?
Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Read More

Data Warehouse – O Que É?

Imagem: Rafael Piton – Data Warehouse – O Que É?

 

Sabe essa confusão toda sobre o que é Data Warehouse e qual o papel dele em um projeto de BI? Vamos terminar com ela aqui.

Antigamente só se falava em projetos de Data Warehouse, e por isso, ainda se confunde muito Data Warehouse com Business Intelligence. Hoje em dia já temos os projetos de BI, e o Data Warehouse está incorporado nele.

O Data Warehouse é quem otimiza todo o processo de consultas e análises em grandes volumes de dados, sendo o ponto central para a tomada de decisão.

 

Mas antes, vamos dar um pouco de contexto

Onde o Data Warehouse se encontra no ciclo da informação (ou ciclo da tomada de decisão)?

Imagem: Rafael Piton – Arquitetura de BI

 

Vamos olhar as 3 primeiras partes da imagem: data source, data integration e data storage.

Os dados começam no data source, que são as planilhas, ERPs, CRMs etc. Os data source são geralmente compostos por dados estruturados ou semiestruturados, onde não se pode ter redundância, e são modelados para a inserção e edição dos dados, não para a consulta.

Na segunda parte, de data integration, é onde acontece o ETL, mas não vou me aprofundar nele agora. Para resumir essa etapa: os dados são retirados das fontes de origem, transformados de forma que façam sentido juntos e inseridos no Data Warehouse.

Depois vem a terceira parte, que chamamos de data storage, que é onde entra o Data Warehouse e onde temos nossas informações de fato.

É importante avisar que mesmo o Data Warehouse vindo em um estágio depois do ETL, você deve se preocupar com ele antes. O ETL só vai poder ser feito depois que o Data Warehouse estiver pronto, porque é ele quem define de que forma os dados vão ser transformados e onde deverão ser inseridos.

 

Chega de contexto, o que é Data Warehouse afinal?

O Data Warehouse é quem centraliza os dados da empresa e elimina os ruídos de comunicação entre os departamentos, deixando tudo unificado.

Não é incomum acontecer de os dados de setores diferentes não baterem. Por exemplo, o setor de marketing ter registrado um total de vendas diferente do que o setor de vendas. Isso acontece porque os dados de uma empresa vêm de diversas fontes, tanto de sistemas internos como externos, e o Data Warehouse elimina esse tipo de problema, retirando os dados de todas essas fontes e unificando eles.

E assim você consegue ter uma visão total, e não só parcial, do que realmente está acontecendo. Por isso, ele tem um grande enfoque na consistência e confiabilidade dos dados, além de ser modelado pensando na consulta rápida dos dados, e não na inserção ou alteração deles.

Com o Data Warehouse, e com os dados já transformados em informação, você consegue controlar os níveis de acesso, garantindo que cada pessoa receba os relatórios de que precisa – e evitando que veja os que não deve.

O Data Warehouse é todo planejado com foco na tomada de decisão e no que o negócio precisa. É importante tomar cuidado para não se limitar aos dados já existentes na hora de desenhar o Data Warehouse, mas fazer ele pensando no que o negócio precisa e nas informações necessárias para a tomada de decisão.

O Data Warehouse é a parte mais crítica nos projetos de BI. E por isso é tão necessário ter uma boa habilidade de modelagem de Data Warehouse, porque se você errar nessa parte, vai comprometer o ETL, a construção dos cubos, a própria criação dos dashboards e, principalmente, vai fazer com que erre também na entrega da tomada de decisão.

Além de ser a parte mais crítica do projeto, é quem garante a entrega do resultado. Depois que você já entendeu o conceito de BI e como ele funciona, o próximo passo é dominar a modelagem de Data Warehouse.

 

 

Artigo e imagens publicados originalmente no blog Rafael Piton. Data Warehouse – O Que É?; autor: Rafael Piton, publicado em 05/05/2017.

 

Leia também os outros artigos da série Data Warehouse:
Data Warehouse – Para Que Serve?
Data Warehouse – Por Que Você Deve Aprender?
Data Warehouse – Modelagem Dimensional
Data Warehouse – O Que É Star Schema?
Data Warehouse – Passo a Passo para Modelar um Data Warehouse

Read More