Um passo de cada vez...

Este é um momento especial.

Há pouco mais de 2 (dois) meses fiz a primeira postagem de um total de 13 até o momento, gerando mais de 1000 visualizações de amigos / conhecidos e pessoas que nem conheço ou nem conhecia (pois já conheci novas pessoas por conta deste projeto).

Pessoas espalhadas por quatro continentes, que usam os mais diversos sistemas operacionais, navegadores consagrados e outros que eu nem sabia que existiam como o Flipboard e o SimplePie, até o Netscape ainda está ativo.

Estou gostando da forma que o "Diário de Bordo" está tomando, refletindo novos aprendizados e servindo como base de conhecimento / consulta.

Muito obrigado a todos que direta ou indiretamente apoiaram este projeto e vamos em frente, em breve novas postagens abordando aspectos mais práticos.

Até breve e sinta-se a vontade para deixar o seu comentário.

Abraços.

Modelagem multidimensional IV

Agora vamos aos "fatos", ao centro das atenções, pois são as tabelas fatos que irão guardar no data warehouse a respota para todas as questões.

É na tabela fato que o analista de SAD armazenará as métricas do negócio, possibilitando recuperar dados quantitativos e responder por exemplo quanto foi vendido de um determinado produto? em determinada época? em determinado local? dentre outras questões.

Os fatos ou métricas armazenadas podem ser de três tipos:

• Aditivas: São as métricas que podem ser sumarizadas adicionando seus valores ao longo do tempo. Por exemplo o valor, o custo e/ou a quantidade de um pedido podem ser somados independente das combinações dos parametros das dimensões;
• Não-aditivas: É o inverso das aditivas, por exemplo valores percentuais (no geral não são somados) e como normalmente são derivadas de outras métricas aditivas, fica mais prático calcular em tempo de execução do que armazenar estas métricas.
• Semi-aditiva: Estas métricas podem ser sumarizadas apenas em algumas dimensões, como exemplo temos o saldo de uma conta corrente, que pode ser sumarizada na dimensão cliente, na dimensão agência mas não faz sentido somar o saldo da conta ao longo do tempo.

Ampliando esta questão dos tipos de métricas, temos o exemplo da temperatura (métrica não-aditiva) e do saldo da conta (métrica semi-aditiva) que não faz sentido somar, mas podemos utilizar outras operações como média, máximo e mínimo;

Normalmente na tabela fato a chave primária (PK) é composta, sendo que cada elemento é uma chave estrangeira (FK) vinculada à uma tabela dimensão, sendo que a dimensão tempo sempre faz parte deste conjunto.

Em alguns casos podemos ter uma tabela sem fato, onde apenas a relação entre as dimensões já é o suficiente para a área de negócios, conforme o exemplo:

Modelagem multidimensional - Parte I


Modelagem multidimensional - Parte II


Modelagem multidimensional - Parte III

Modelagem multidimensional III

Vamos falar um pouco sobre a tabela "dimensão", um item importante na modelagem multidimensional e que tem algumas caracteristicas próprias que devemos observar:

• Projete a tabela dimensão na perspectivas do usuário. Utilize textos descritivos e códigos que sejam de fácil entendimento do usuário final, não tente economizar alguns bytes neste quesito.
• Evite utilizar técnicas de normalização dos dados. Esta técnica aumenta a complexidade das consultas, impactando no desempenho, além de não compensar a economia de espaço obtida.
• Utilize uma chave primária genérica e simples. Este procedimento evita problemas de atualização que surgem aos utilizar, por exemplo, o próprio código do cliente ou produto como chave primária, além de proporcionar um melhor desempenho na utilização dos índices.
• Utilize múltiplas colunas de atributos. Com isto ficará mais fácil identificar a chave em questão.

Abaixo alguns exemplos de atributos que podem ser utilizados para ajudar a detalhar uma chave facilitando na definição dos parametros da consulta OLAP.


Atributos estruturais para relacionamentos pai-filho;

Fonte: HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley, 1998. 362 p.

   

Atributos para definição de nível;

Fonte: HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley, 1998. 362 p.

Atributos tipo "flag" de resolução e/ou de seqüência;

Fonte: HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley, 1998. 362 p.

Modelagem multidimensional - Parte I


Modelagem multidimensional - Parte II


Modelagem multidimensional - Parte IV

Modelagem multidimensional II

Vamos conversar um pouco sobre escopo e granularidade dentro do contexto da modelagem multidimensional.

ESCOPO
A experiência e o conhecimento do analista de SAD sobre o negócio é fundamental para a correta definição do escopo de um projeto de DW.

É imprescindível ter uma visão do que é importante para o negócio, ou melhor, saber que informação será necessária extrair dos dados armazenados no DW para que a organização obtenha algum conhecimento novo e a partir deste ponto os gestores possam tomar as decisões mais acertadas.

Vale lembrar que cada projeto é único e portanto deve ser analisado individualmente e que muitas variáveis influenciam as decisões, por exemplo: tempo para implantação, custo, capital humano e recursos tecnológicos disponíveis, etc. Estes dentre outros fatores influenciarão na escolha de um dos dois paradigmas que envolvem os projetos de DW que são as propostas de Inmon e Kimball.

Inmon propõe que o projeto do DW deve partir do DW corporativo para depois desmembrar nos DM departamentais com isto ganha-se na consistência dos dados armazenados mas o tempo para a obtenção de resultados práticos aumenta, em contrapartida Kimball propõe o caminho inverso, partir de DM departamentais para o DW corporativo buscando observar à consistência das informações, neste processo os resultados aparecem mais rapidamente porém o risco de inconsistência aumenta.

O bom senso entre as pessoas envolvidas sempre deve ser levado em conta no momento da decisão do projeto, para se buscar um equilibrio entre o melhor dos dois mundos.


GRANULARIDADE
Durante o desenho da solução o analista de SAD define quais métricas serão armazenadas nas tabelas fatos e quais parametros serão armazenados nas tabelas dimensões, observe a figura abaixo.

Fonte: http://hub05.neogrid.com.br/Docs/help/pt_BR/release_notes.htm

A definição correta da granularidade de uma tabela fato implica no desempenho das consultas OLAP, tomando como base o modelo proposto imagine os seguintes cenários:

• Poucas lojas e pouca abrangência (poucos CEP´s);
• Muitas lojas e pouca abrangência (poucos CEP´s);
• Poucas lojas e abrangência nacional;
• Muitas lojas e abrangência nacional;

É de se concordar que o volume de dados armazenados na tabela fato na última situação poderá chegar a bilhões de registros, podendo impactar no desempenho das consultas que não necessitem de um detalhamento maior.

Nestes casos uma alternativa é quebrar a tabela fato em domínios menores, onde além de uma tabela com o nível máximo de detalhes existiriam outras tabelas sumarizadas por cidade ou estado por exemplo.

No geral para granularidades distintas teremos tabelas fatos distintas.

Participe! Registre seu comentário abaixo e vamos construir o conhecimento juntos.

Abraços e até mais,

Modelagem multidimensional - Parte I

Modelagem multidimensional - Parte III

Modelagem multidimensional - Parte IV

Modelagem multidimensional I

Um DW tem como principal objetivo servir de repositório para a analise de grandes massas de dados através de consultas OLAP, neste cenário observa-se dados centrais (os fatos ou métricas) que serão consultados sob diversas perspectivas (as dimensões ou parâmetros) criando a abstração do cubo de dados, conforme figura abaixo:

Fonte: http://www.devmedia.com.br/parceiros/fig02.jpg

Conceitualmente uma base de dados multidimensional é representada pelo cubo de dados; mas partindo para o modelo lógico e físico a forma mais simples de representar uma base de dados multidimensional é a figura abaixo:

Fonte: http://www.ime.usp.br/~jef/apostila.pdf

Essencialmente teremos no centro do modelo uma ou mais "tabelas fatos" contendo de 0 (zero) à n (várias) métricas cada tabela e nas bordas teremos pelo menos 1 (uma) "tabela dimensão" podendo ter quantas forem necessárias.

Durante o processo de modelagem da base de dados multidimensional, os itens abaixo devem ser analisados cuidadosamente:

• Escopo;
• Granularidade;
• Dimensões e;
• Métricas.

Por último deve-se definir o esquema que será utilizado: Estrela ou Floco de neve.

Nas próximas postagens aprofundaremos estes tópicos. Por enquanto se existir alguma dúvida, curiosidade, sugestão ou se quiser registrar um elogio, deixe seu comentário no espaço abaixo.
 

Até mais,

Modelagem multidimensional - Parte II 

Modelagem multidimensional - Parte III

Modelagem multidimensional - Pàrte IV

O ambiente do DW

Devido às diferenças existentes entre os dados primitivos e os dados derivados como vimos em OLTP & OLAP, outros aspectos por consequencia necessitam de nova abordagem segundo Inmon.

OS NÍVEIS DE DADOS
Estas diferenças acabam por gerar 4 (quatro) níveis de dados na organização, como segue:

• Operacional ==> Contém os dados primitivos que atende às transações OLTP, refletindo o valor atual dos registros;
• Atômico / Data Warehouse ==> Contém dados primitivos que não são atualizados e alguns dados derivados, não existe a sobreposição de valores, mantendo um histórico dos registros através da utilização de um elemento tempo associado a chave de cada registro;
• Departamental ==> Contém apenas dados derivados e agrupados por departamento, tem-se uma base de dados para o Marketing, outro para o RH, outro para o Financeiro e assim por diante. Também existe neste nível o elemento tempo associado a chave de cada registro.
• Individual ==> Contém dados que serão utilizados nas análises heurísticas, normalmente são dados temporários de pequenas proporçoes e utilizados pelos Sitemas de Informações Executivas (EIS).

CICLO DE VIDA DO DESENVOLVIMENTO DE SISTEMAS
As diferenças entre os sistemas tradicionais e um DW não termina na forma de armazenar / modelar os dados, o desenvolvimento de sistemas para um ambiente de DW é praticamente o oposto ao tradicional SDLC (Systems Development Life Cycle), conforme abaixo:

SDLC Clássico	SDLC de um DW
Ciclo de vida baseado em requisitos	Ciclo de vida baseado em dados
Levantamento de necessidades	Implementar o warehouse
Análise	Integrar os dados
Projeto	Procurar distorções
Programação	Programas para os dados
Teste	Projetar sistemas SAD
Integração	Analisar os resultados
Implementação	Entender necessidades

UTILIZAÇÃO DO HARDWARE
Em um sistema OLTP o consumo do hardware mantém um certo padrão / média de utilização durante o tempo. É possível planejar o crescimento / upgrade do sistema.

É possível prever os picos de utilização por conta da sazonalidade, por exemplo, no natal o sistema das operadoras de cartão de crédito têm um pico de utilização.

Em contrapartida um sistema DW / SAD terá picos de utilização do hardware apenas quando houver solicitações de ETL e / ou consultas OLAP dos usuários e logo em seguida o hardware voltará a ficar ocioso.

Neste cenário consegue-se prever o ritmo de crescimento da base de dados, porém o consumo de CPU / memória RAM e espaço para dados temporários já fica mais complicado.

Ou seja, a configuração / ajuste fino do hardware que vai atender às demandas dos sistemas legados (OLTP) é totalmente diferente das necessidades / especificações dos sistemas que irão atender às demandas dos sistemas DW / OLAP.

CONCLUSÃO
Só estes três argumentos já justificam porque deve-se ter um ambiente separado para os sistemas DW / OLAP.

Na sequência vamos iniciar os estudos sobre modelagem multidimensional.

Qualquer dúvida, sugestão, crítica ou elogio registre abaixo. Abraços e até a próxima.

OLTP & OLAP

OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) caracteriza-se por um grande número de transações (INSERT, UPDATE e DELETE) envolvendo uma pequena quantidade de dados em um ambiente multi-acesso, mantendo a integridade referencial.

No planejamento do banco de dados busca-se reduzir o tamanho e a redundância dos dados e normalmente se aplica a 3FN (terceira Forma Normal) na modelagem, são os dados primitivos ou dados operacionais segundo W. H. Inmon.

OLAP (Online Analytical Processing ou Processamento Analítico em Tempo Real) caracteriza-se por poucas transações (INSERT e SELECT) envolvendo um volume muito grande de dados.

Na busca por eficiência das consultas, os dados armazenados no DW ou DM´s, normalmente são desnormalizados e utilizam esquemas multi dimensionais, são os dados derivados ou dados SAD segunda W. H. Inmon.

Fonte: http://datawarehouse4u.info/OLTP-vs-OLAP.html

Juntamente com o OLAP surgiram novos termos como DOLAP, ROLAP, MOLAP, HOLAP, slice and dice, pivot table, drill down/up que ampliaremos posteriormente.

A tabela abaixo extraída do livro "Como construir o Data Warehouse" de W. H. Inmon apresenta algumas diferenças conceituais entre os dados primitivos e os dados derivados, vejamos:

DADOS PRIMITIVOS ou DADOS OPERACIONAIS	DADOS DERIVADOS ou DADOS SAD
Baseados em aplicações	Baseados em assuntos ou negócios
Detalhados	Resumidos ou refinados
Exatos em relação ao momento do acesso	Representam valores de momentos já decorridos ou instantâneos
Atendem à comunidade funcional	Atendem à comunidade gerencial
Podem ser atualizados	Não são atualizados
São processados repetitivamente	Processados de forma heurística
Requisitos de processamento conhecidos com antecedência	Requisitos de processamento não são conhecidos com antecedência
Compatíveis com o SDLC	Ciclo de vida completamente diferente
Performance é fundamental	Performance atenuada
Acessados uma unidade por vez	Acessados um conjunto por vez
Voltados para transações	Voltados para análises
O controle de atualizações é atribuição de quem tem a posse	O controle de atualizações não é problema
Alta disponibilidade	Disponibilidade atenuada
Gerenciados em sua totalidade	Gerenciados por subconjuntos
Não contemplam a redundância	A redundância não pode ser ignorada
Estrutura fixa; conteúdos variáveis	Estrutura flexível
Pequena quantidade de dados usada em um processo	Grande quantidade de dados usada em um processo
Atendem às necessidades cotidianas	Atendem às necessidades gerenciais
Alta probabilidade de acesso	Baixa ou modesta probabilidade de acesso

Por enquanto é só, até o próximo assunto.

Persistindo alguma dúvida, curiosidade ou querendo dar uma sugestão, crítica ou elogio envie seu comentário.

DataWarehouse (DW) & Data Mart (DM)

Um DW (Data Warehouse ou Armazém de Dados) é uma coleção de dados orientada por assunto, integrada, variante no tempo e não volátil que tem por objetivo dar suporte aos processos de tomada de decisão.

É um repositório central que armazena dados de várias fontes, transformando-os em um modelo comum, multidimensional, para a realização de consultas e análises mais eficientes.

A diferença entre um DW e um DM basicamente consiste no volume de dados, abrangência e foco. Enquanto o DW foca na organização como um todo os DM´s focam em um determinado departamento ou conjunto especifíco de usuário, por exemplo.

A construção deste armazém pode acontecer de duas formas, cada abordagem têm seus prós e contras. As circunstâncias e particularidades de cada projeto é que determinarão qual utilizar.

Na abordagem Top-Down primeiro se monta o DW (corporativo) para num segundo momento criar os DM (departamentais).

Fonte:http://www.dataprix.net/pt-pt/24-data-mart 

Ou utilizar a abordagem Bottom-UP onde primeiro é criado os DM´s para em seguida montar o DW da organização.

Fonte:http://www.dataprix.net/pt-pt/24-data-mart 

BI (Business Intelligence)

O termo Business Intelligence ou Inteligência Empresarial foi utilizado pela primeira vez na década de 80 pelo Gartner Group, porém o conceito remonta desde a antiguidade onde, por exemplo, se observavam a posição dos astros, os períodos de sol / chuva e as marés para a tomada de decisões.


Com o desenvolvimento dos sistemas computacionais ao longo das últimas décadas, observa-se também o desenvolvimento do BI, impulsionado pela permanente necessidade das organizações de manterem a competitividade.


Atualmente, pode-se sintetizar BI como um conjunto de ferramentas, conceitos e metodologias que se utiliza da tecnologia da informação (TI) para coletar dados, analisá-los e transformá-los em informação. Com isso, os sistemas de BI concedem às organizações conhecimento sobre seus negócios, contribuindo para que os gestores optem pela decisão mais acertada.

http://revistas.utfpr.edu.br/pb/index.php/CAP/article/viewFile/933/544

Os componentes de uma estrutura de BI são basicamente:

• Dados operacionais;
• É a matéria prima do BI, são os dados originados das aplicações utilizadas no dia-a-dia da organização, por exemplo o ERP.
• ODS (Operacional Data Store);
• Armazena os dados operacionais de forma consolidada, porém não possuem características dimensionais (como o DW e DM).
• Ferramentas de ETL (Extração, Transformação e Carga);
• Veremos com mais detalhes posteriormente.
• Data Warehouse (DW) e Data Marts (DM);
• Veja postagem.
• Data Mining (Mineração de Dados);
• Veremos com mais detalhes posteriormente.
• Visualização dos resultados;
• Ferramentas que permitem ao usuário final visualizar de forma amigável as informações para auxiliar na tomada das decisões.

Este é um breve resumo sobre BI, persistindo alguma dúvida ou necessitando de maiores esclarecimentos, registre seu comentário e vamos aprender juntos.

Fonte:

ANTONELLI, Ricardo A. Conhecendo o Business Intelligence (BI) - Uma Ferramenta de Auxílio à Tomada de Decisão. Revista TECAP. v. 3, n. 3, 2009. Disponível em: http://revistas.utfpr.edu.br/pb/index.php/CAP/article/viewFile/933/544 acesso em: 14 de mar. 2012.

SAD - Sistemas de Apoio à Decisão

A definição do termo SAD (Sistema de Apoio à Decisão) ainda provoca divergência entre vários autores, mas sinteticamente pode-se definir como: "Conjunto de ferramentas que visa auxiliar os gestores na tomada de decisões".

Um SAD se diferencia de outros sistemas existentes nas organizações basicamente por:

- Manipular grandes volumes de dados;

- Obter dados de fontes diferentes (internas e externas);

- Flexibilidade de relatórios gerenciais;

- Execução de rotinas de otimização e heurística;

- Execução de análises de simulação;

- Suporte para diversos níveis na tomada de decisão;

Com a utilização de um SAD as organizações tem melhores condições de, por exemplo:

- Decidir sobre fazer ou não uma promoção, de qual produto e quando;

- Projetar o risco ou o sucesso do investimento em determinado empreendimento ou do lançamento de um produto;

- Decidir se deve contratar ou não novos funcionários no próximo mês;

Ou seja, com este sistema os gestores têm condições de tomar decisões não apenas na intuição.

Fonte:
FALSARELLA, Orandi M.; CHAVES, Eduardo O. C. Sistemas de Informação e Sistemas de Apoio à Decisão. Disponivel em: http://www.chaves.com.br/TEXTSELF/COMPUT/sad.htm Acesso em: 13 de mar. 2012.
BORTOLIN, Sérgio A. M. Sistema de Apoio à Decisão. Disponível em: http://www.al.urcamp.tche.br/infocamp/edicoes/nov05/Apoio%20a%20Decisao.pdf Acesso em: 13 de mar. 2012.

PRIMAK, Fabio Vinicius. Decisões com B.I. Business Intelligence. Brasil. 1a edição. Ciência Moderna. 2008. 168 p. ISBN 8573937149.

Quebra cabeça

Em resumo um DW (datawarehouse) pode ser definido como um banco de dados especializado, que integra e gerencia o fluxo de informações a partir de bancos de dados corporativos e fonte de dados externas à organização.

Por trás de uma solução de DW  existe uma série de ferramentas / tecnologias /  conceitos (peças) que precisam ser combinadas para atingir um objetivo específico. E para não sair do padrão temos a tradicional sopa de letrinhas: SAD, OLAP, OLTP, ETL, ODS além de alguns termos como Data Mart, Data Mining, Metadados, etc...

Gradativamente estes tópicos serão abordados com maior profundidade para que possamos construir a nossa base de conhecimentos.

Fontes:

MARTINS, C. E. W.; SILVA, E. L. da.; MUSSI, E. A. S. Implantação de um ODS no Banco do Brasil visando um DATA WAREHOUSE - Estudo de Caso. 1999. 51 f. Tese (MBA em Tecnologia) - Escola Politécnica, Universidade de São Paulo, Brasília. 1999.

HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley, 1998. 362 p.

Tudo é uma questão de tempo...

Este período de início de atividades em uma nova função / setor, para trabalhar em algo novo, me faz lembrar de situações semelhantes já vividas, do friozinho na barriga, da expectativa com relação ao aprendizado, daquela pergunta que não quer sair da cabeça nestes momentos (será que vou conseguir dar conta?), dentre outros sentimentos e sensações. 

Bom, a vantagem de ter alguns km rodados, é que, junto com os sentimentos acima (inevitáveis neste momento) recordamos também dos momentos seguintes, onde conseguimos através de muito estudo, determinação, comprometimento e paciência, gradativamente amadurer o conhecimento necessário para a execução das tarefas e com isto conquistar a auto-confiança e a confiança dos colegas de trabalho.

É um período de grande aprendizado... É um período onde teremos que trabalhar / desenvolver várias das nossas inteligências... É um período...

Por isso escrevo estas linhas, para não me esquecer que tudo é uma questão de tempo e lembrar aos colegas e amigos que porventura estejam na mesma situação, que tudo é uma questão de tempo.

Abraços, e sinta-se a vontade para postar o seu comentário.

Superando os concorrentes

"No ambiente comercial moderno, a informação é um dos bens mais valiosos que uma empresa pode usar para sobreviver às batalhas competitivas e defender sua posição no mercado. O capital intelectual alcançou um status igual - se não superior - ao do capital financeiro."

"As empresas proeminentes superam a concorrência sendo mais rápidas e eficientes, ajustando velozmente planos de ação competitiva e desafiando continuamente os rivais. O objetivo é identificar oportunidades mais rápido, planejar ações geniais, executar com maior presteza e efetuar redirecionamentos antes da concorrência."

"Um datawarehouse contém informações como avaliações de desempenho operacional e inteligência competitiva que facilitam a tomada de decisões. Um datawarehouse, no entanto, armazena simplesmente dados brutos nas linhas e colunas de um banco de dados."

"Um datawarehouse armazena os dados 'brutos' como 'fatos' individuais. Diferentemente de um SGBD, um datawarehouse armazena fatos para cada período de tempo, criando um histórico do desempenho." 

Fonte: HARRISON, Thomas H. Intranet Data Warehouse. São Paulo, Berkeley, 1998. 362 p.

Resumidamente um DW (Datawarehouse) sintetiza as informações das aplicações utilizadas no dia-a-dia (no âmbito operacional), criando uma massa de dados que possibilite às organizações a tomada de decisões estratégicas. Ou seja, com um bom projeto de DW as organizações terão maiores chances de manter a competitividade.


Concorda?

Start - Novas experiências...

Após um período de treinamentos / cursos, para digamos "nivelar" o conhecimento dos participantes do programa de ingresso na DITEC do BB, iniciamos agora a etapa de aprendizado junto à equipe de trabalho (vida real).

Estarei na equipe que trabalha com DW (Datawarehouse), BI (Business Intelligence) e CRM (Customer Relationship Management) portanto estes serão primordialmente os assuntos tratados neste espaço.

Fiquem a vontade para registrar seus comentários, levantar dúvidas / questionamentos, dar sugestões, emitir criticas enfim participar.

Abraços a todos,