Conceitos de Data Webhouse - D.W

Prévia do material em texto

Noções sobre Data Webhouse
Com o advento do Data Warehouse, surgiu a necessidade de mapear melhor as questões gerencias dos Sites da Web. O aumento significativo de páginas dedicadas a E-Businnes, fizeram com que fosse pensada uma maneira de criar um Armazém de Dados que seguisse conceitos e características semelhantes aos do Data Warehouse criando assim uma espécie de Armazém de Dados para Web, ao qual podemos chamar de Data Webhouse.
Seguindo as mesmas características do Data Warehouse, o Data Webhouse deve ser orientado por assunto, não volátil, variável no tempo e integrado. 
O Data Webhouse permite analisar todo o caminho realizado por um visitante em um Site da Web, permite mapear cada clique, conhecer melhor cada cliente através da informação disponibilizada nos arquivos de Log do servidor e Cookies. Tornando muito mais fácil e real uma análise de cada evento realizado dentro do Site pelo visitante ( Cliente ).
Noções sobre Data Webhouse
Com o advento do Data Warehouse, surgiu a necessidade de mapear melhor as questões gerencias dos Sites da Web. O aumento significativo de páginas dedicadas a E-Businnes, fizeram com que fosse pensada uma maneira de criar um Armazem de Dados que seguisse conceitos e características semelhantes aos do Data Warehouse criando assim uma espécie de Armazem de Dados para Web, ao qual podemos chamar de Data Webhouse.... ( Leia Mais )
- Data Mart para Data Webhouse
Fundamentalmente queremos analisar todos os cliques de nossa Rede, construir uma visão compreensível do fluxo dos inúmeros cliques que chegam ao nosso servidor, também achamos importante saber com que tipo de usuário estamos lidando, se acessam de uma Intranet ou uma Extranet. A isso chamamos de Data Mart de Fluxo de Cliques ( DM-FC). O DM-FC pode nos detalhar bastante o comportamento de um cliente. Se você possui informações sobre cada clique de seus clientes, ou seja, o caminho seguido por ele dentro do Site, provavelmente poderá responder a essas perguntas.... ( Leia Mais )
O que é Data Webhouse ? 
Como responder as questões gerenciais do seu Site ? 
Como construir um Data Mart para seu Site ? 
Como mapear cada Click no seu Site ? 
Como conhecer melhor seu cliente ? 
Como localizar as áreas com problemas no seu Site ? 
Leia mais sobre a Missão deste Site e conheça seus Produtos e Serviços
Clique aqui
Um pouco sobre OLAP
As ferramentas OLAP são as aplicações que nossos usuários finais têm acesso para extrairem os dados de suas bases com os quais gera relatórios capazes de responder as suas questões gerenciais. Elas surgiram juntamente com os sistemas de apoio a decisão para fazerem a extração e análise dos dados contidos nos Data Warehouses e Data Marts.
Vamos ver algumas características dessas ferramentas:
Consultas ad-hoc
Segundo Inmon “são consultas com acesso casual único e tratamento dos dados segundo parâmetros nunca antes utilizados, geralmente executado de forma iterativa e heurística”. 
Isso tudo nada mais é do que o próprio usuário gerar consultas de acordo com suas necessidades de cruzar as informações de uma forma não vista e com métodos que o levem a descoberta daquilo que procura.
Slice-and-Dice
Essa característica das ferramentas OLAP é de extrema importância. Com ela nós podemos analisar nossas informações de diferentes prismas limitados somente pela nossa imaginação. Utilizando esta tecnologia conseguimos ver a informação sobre ângulos que anteriormente inexistiam sem a confecção de um DW e a utilização de uma ferramenta OLAP. 
Drill Down/Up
Consiste em fazer uma exploração em diferentes níveis de detalhe das informações. Com o Drill Down você pode “subir ou descer” dentro do detalhamento do dado, como por exemplo analisar uma informação tanto diariamente quanto anualmente, partindo da mesma base de dados. 
Geração de Queries
A geração de queryes no OLAP se dá de uma maneira simples, amigável e transparente para o usuário final, o qual precisa ter um conhecimento mínimo de informática para obter as informações que deseja.
Cada uma destas tecnologias e técnicas tem seu lugar no mercado de DSS (Decision Support System) e apoia diferentes tipos de análises. É importante lembrar que as exigências do usuário devem ditar que tipo de Data Mart você está construindo. Como sempre, a tecnologia e técnicas devem estar bem fundamentadas para atenderem da melhor maneira possível essas exigências. 
Os Data Warehouses/Data Marts, servem como fonte de dados para estas aplicações, assegurando a consistência, integração e precisão dos dados. Os sistemas transacionais não conseguem responder essas questões por isso, é necessária a criação de um ambiente de apoio de decisão robusto, sustentável e confiável. 
Data Mart
Os primeiros projetos sobre Data Warehouse (DW) referiam-se a uma arquitetura centralizada. Embora fosse interessante fornecendo uniformidade, controle e maior segurança, a implementação desta abordagem não é uma tarefa fácil. Requer uma metodologia rigorosa e uma completa compreensão dos negócios da empresa. Esta abordagem pode ser longa e dispendiosa e por isto sua implementação exige um planejamento bem detalhado. Com o aparecimento de data mart ou warehouse departamental, a abordagem descentralizada passou a ser uma das opções de arquitetura data warehouse.Os data marts podem surgir de duas maneiras. A primeira é top-down e a outra é a botton-up.
Top-down: é quando a empresa cria um DW e depois parte para a segmentação, ou seja, divide o DW em áreas menores gerando assim pequenos bancos orientados por assuntos departamentalizados. Botton-up: é quando a situação é inversa. A empresa por desconhecer a tecnologia, prefere primeiro criar um banco de dados para somente uma área. Com isso os custos são bem inferiores de um projeto de DW completo. A partir da visualização dos primeiros resultados parte para outra área e assim sucessivamente até resultar num Data Warehouse.
A tecnologia usada tanto no DW como no Data Mart é a mesma, as variações que ocorrem são mínimas, sendo em volume de dados e na complexidade de carga. A principal diferença é a de que os Data Marts são voltados somente para uma determinada área, já o DW é voltado para os assuntos da empresa toda. Portanto, cabe a cada empresa avaliar a sua demanda e optar pela melhor solução. O maior atrativo para implementar um data Mart é o seu custo e prazo. Segundo estimativas, enquanto um Data Mart custa em torno de US$ 100 mil a US$ 1 milhão e leva cerca de 120 dias para estar pronto, um DW integral começa em torno dos US$ 2 milhões e leva cerca de um ano para estar consolidado.
Metadados
Desde que surgiram os bancos de dados sempre se falou sobre a importância da documentação dos sistemas e dos próprios bancos. Com o surgimento do conceito de Data Warehouse, isso não diminuiu a importância, pelo contrário, aumentou e muito. 
As Corporações estão exigindo cada vez mais funcionalidades dos sistemas de TI (Tecnologia da Informação), e repositórios de metadados não são nenhuma exceção a esta regra. Mas o que são metadados ?
Acima vimos que sempre houve preocupação com a documentação dos sistemas e bancos de dados das corporações, sabemos que no Data Warehouse documentar tudo é vital para a sobrevivência do projeto, pois o DW pode ser um projeto gigantesco e se não houver uma documentação eficiente ninguém conseguirá entender nada.
Os metadados são definidos como dados dos dados. Só que a complexidade desses dados no Data Warehouse aumenta muito. Num sistema OLTP gera-se documentos somente sobre o levantamento dos dados, banco de dados e o sistema que alimenta o mesmo. No Data Warehouse além do banco, gera-se uma documentação muito maior. Além de falar sobre o levantamento de dados e o banco, temos ainda o levantamento dos relatórios a serem gerados, de onde vem os dados para alimentar o DW, processos de extração, tratamento e rotinas de carga do dados. Ainda podem gerar metadados as regras de negócio da empresa e todas as mudançasque elas podem ter sofrido, e também a frequência de acesso aos dados.
Segundo Inmon os metadados englobam o DW e mantém as informações sobre o que está onde. Ele ainda define quais informações os metadados mantém:
- A estrutura dos dados segundo a visão do programador;
- A estrutura dos dados segundo a visão dos analista de SAD;
- A fonte de dados que alimenta o DW;
- A transformação sofrida pelos dados no momento de sua migração para o DW;
- O modelo de dados;
- O relacionamento entre o modelo de dados e o DW;
- O histórico das extrações de dados;
- Acrescentamos ainda os dados referentes aos relatórios que são gerados pelas ferramentas OLAP assim como os que são gerados nas camadas semânticas.
Os metadados podem surgir de vários locais durante o decorrer do projeto. Eles provêm de repositórios de ferramentas case, os quais geralmente já estão estruturados, facilitando a integração da origem dos metadados e o repositório dos mesmos. Essa fonte de metadados é riquíssima. 
Outros dados que devem ser guardados no repositório de metadados, é o material que surgirá das entrevistas com os usuários. Destas entrevistas podem obter-se informações preciosas que não estão documentadas em nenhum outro lugar além de regras para validação dos dados após carregados no Data Warehouse.
Como pudemos ver, o volume de metadados gerados é muito grande. Existem hoje algumas ferramentas que fazem única e exclusivamente o gerenciamento dos metadados. Elas têm algumas características peculiares.
Falando de uma maneira simplista, essas ferramentas conseguem mapear o dado em todas as etapas de desenvolvimento do projeto, desde a conceitual até a de visualização dos dados em ferramentas OLAP/EIS.
Agora vamos discutir os desafios arquitetônicos mais complexos que surgem ao implementarmos um repositório de metadados que requer funcionalidade mais avançada. Enquanto a maioria dos repositórios não tentam implementar estas características, eles representam o tipo de funcionalidade que é exigida através das corporações.
As fontes metadados, (ferramentas de modelagem de dados, ferramentas de extração, transformação e carga, etc.) devem ser integradas no repositório por várias necessidades. Uma arquitetura de metadados bidirecional permite que os dados modificados na fonte possam ser alterados também no repositório automaticamente.
Esta arquitetura é altamente desejável por duas razões chaves. Primeiro: permite a essas ferramentas compartilhar metadados. Isto é desejável no mercado de ferramentas de apoio de decisão. A maioria das corporações que construíram um sistema de apoio a decisão não pensou na integração das ferramentas. Estas não são integradas, por isso, não se comunicam facilmente. Até mesmo essas ferramentas que podem ser integradas tradicionalmente requerem bastante programação manual para compartilhar dados.Segundo: metadados bidirecional é atraente para corporações que querem implementar um repositório de metadados em toda empresa.
Como vimos os metadados são importantíssimos para o sucesso de um DW. Ao começarmos qualquer projeto devemos sempre nos preocupar com os mesmos, pois são eles que servirão de bússula para nos guiar pelo emaranhado de tabelas, relatórios e dados quando estivermos perdidos.
A fase de levantamento de um data warehouse, onde a equipe de consultoria está em contato direto com os usuários tomadores de decisão, está intimamente ligada ao sucesso ou ao fracasso do projeto.
Alguns pontos simples, como estar conversando com as pessoas erradas ou como a demora na implantação do projeto, bem como a falta de flexidade do mesmo podem levá-lo a construir um amontoado de dados estáticos e inúteis ao invés de um Data Warehouse.
Veja o que também pode afundar o seu projeto:
1 - Não descubra quem são os verdadeiros conhecedores do Negócio.
2- Não entenda os objetivos e as demandas dos usuários finais. 
3- Faça com que tudo fique muito, muito, complicado.
4- Faça com que tudo fique extremamente e irritantemente lento.
5- Arraste o projeto por mais de um ano.
6- Faça com que seu DW não se adapte a novos tempos e regras de negócio.
Por Luiz Claudio Paz