apresentação do powerpoint · formação analista de bi microsoft staging area a staging area...

Formação Analista de BI Microsoft Formação Analista de BI Microsoft

MÓDULO 2 ESTRUTURA E COMPONENTES DO DATA WAREHOUSE

CICLO DE VIDA DO DATA WAREHOUSE


Componentes do Data Warehouse


Sistema de fontes ou Sistemas legados

Os sistemas legados são aqueles que servem como base das informações do Data Warehouse. São responsáveis pela entrada de dados, aplicação das regras de negócio e

suporte a legislação.

Pode ser uma fonte único ERP ou CRM, ou informações de diversos sistemas. Pode-se preparar uma interface de saída dos dados para o DW ou mesmo acessar

diretamente as tabelas internas de dados.


Staging Area

A Staging Area também conhecida como Back Room, é responsável pelo recebimento dos dados, limpeza e tratamento inicial dos dados. Comparando a um restaurante a Staging Area

pode ser considerada a cozinha, onde o alimento é preparado. Os dados recebidos na Staging podem ser armazenados em arquivos texto, XML ou banco de

dados. Sendo a última opção mais usual. Assim como o restaurante, os clientes não tem acesso a ela. Pode ser classificada como Persistente ou Transiente.

A Staging Area é propriedade do Time de ETL


Data Apresentation

Na camada de apresentação os dados estão limpos e tratados de acordo com as regras definidas. Nessa área os dados podem ser acessados pelos usuários ou por outros sistemas.

Comparando a um restaurante, essa área é a parte das mesas onde o cliente almoça. É altamente aconselhável que somente os processos de ETL escrevam nessa camada.

Geralmente é modelada com técnicas de Modelagem Dimensional. Alguns modelos possuem dados sumarizados e outros nível atômico.


Data Access Tools

Podem ser utilizadas diversos tipos de ferramentas para acessar os dados. As ferramentas de query report são as mais comuns.

Outras ferramentas de Budgeting, Forecasting ou Data Mining também podem ser utilizadas. Essas ferramentas somente consultam os dados não podendo alterá-los.

90% dos usuários podem ser considerados usuários de informação, ou seja, nunca vão construir uma consulta complexa


Ciclo de Vida do Data Warehouse

Formação Analista de BI Microsoft

Objetivos do Módulo

Dividir um Data Warehouse em partes gerenciáveis.

Demonstrar as práticas mais comuns no mercado.

Demonstrar todas as etapas de um sistema de DW


Ciclo de Vida do Data Warehouse - DWLC

Conceitos Fundamentais do Ciclo de Vida Kimball:

Foco no negócio.

Estruturas dimensionais para entrega dos dados via ferramentas de query e relatórios.

Ciclo de Vida interativo e gerenciável ao invés do “Big Bang” da implantação do DW..


Ciclo de Vida do Data Warehouse - DWLC


Planejamento do Projeto


Problemas Problemas que podem dificultar a implantação :

Dados de baixa qualidade.

Patrocinador fraco ou somente TI.

Muitas demandas de patrocinadores diferentes.

Sistemas Legados de baixa performance.


Definindo o Projeto Na maioria dos casos, os projetos podem ter as seguintes origens :

Área de Negócios

Demanda a partir de um entusiasta do DW

Demanda à partir de diversas áreas de negócios

Tecnologia

Buscando por uma demanda

Resolver outros problemas através de um DW


Sua empresa está pronta para o DW ?

Seu projeto tem um patrocinador forte ?

Existe uma forte motivação por parte da área de negócios ?

TI e a Área de Negócios são realmente parceiras ?

Existe uma Cultura de Análise de Informações?

Existe viabilidade para implantação do DW ?


Técnicas que podem ajudar no Planejamento do DW

Análise de Alto Nível sobre os Requisitos de Negócios.

Priorização dos Requisitos de Negócio.

Prova de Conceito (POC).


Análise Inicial sobre os Requisitos de Negócio

Entender as iniciativas estratégicas de negócio.

Identificar quais indicadores de performance ou métricas para cada iniciativa estratégica.

Determinar os processos de negócios que devem ser monitorados e os impactos.

Determinar os benefícios que serão incorporados ao negócio, com um melhor acesso a informação


Priorização dos Requisitos de Negócio

Devem ser avaliados a viabilidade e o impacto dos processos no projeto do DW.


Prova de Conceito (POC) O POC deve utilizado para demonstrar o impacto do DW nos negócios da empresa.

Alguns vendedores de ferramentas, tem utilizado-o como maneira de demonstrar as potencialidades dos softwares.

O POC pode ser usado como protótipo, para se avaliar as informações e o funcionamento futuro do DW


Escopo Preliminar É necessário definir o escopo do projeto sendo esse escopo totalmente justificável.

Focar inicialmente em um processo de negócio de somente uma fonte de dados.

Algumas dicas para elaboração do escopo :

Escopo é um trabalho conjunto entre TI e Negócios.

O escopo inicial deve ser significativo e gerenciável.

Limite a quantidade de usuários que vai acessar o DW inicialmente.

Defina critérios de sucesso juntamente com o escopo.


Escopo Preliminar - Documentação

A documentação do escopo é de extrema importância para todo o Ciclo de Vida do DW.

O entendimento, a aceitação, as exclusões, critérios de sucesso, os riscos e planos de ação, devem sempre estarem declarados e aceitos por todo o grupo de trabalho


Justificativa para o Negócio Determinando os Investimentos e Custos :

Hardware e software comprados ou alugados.

Despesas de manutenção.

Recursos Internos para o Projeto.

Recursos Externos.

Treinamentos para o Time do Projeto e usuários finais.

Despesas de suporte aos usuários.

Despesas para crescimento do DW


Determinando o Retorno Financeiro e os Benefícios

Geralmente os benefícios são mais difíceis de serem determinados do que os custos.

O melhor acesso a informação é um dos itens sempre comentado pelos usuários, mas tem pouco significado quando falamos de retorno financeiro.

Podem ser citados :

Aumento das vendas para os mesmos clientes.

Melhor controle dos custos.

Menor ciclo de lançamento de produtos, etc.


Planejamento do Projeto Tarefas :

Estabelecer uma Identidade para o Projeto.

Determinar o Staff do Projeto.

Desenvolver o Plano do Projeto


Planejamento do Projeto Estabelecer uma Identidade para o Projeto.

Pode ser uma sigla, que defina o nome do projeto.

Essa identidade vai ser usada na construção das tabelas, mapas, etc.

Em alguns casos, são criados logos, camisetas, etc.


Planejamento do Projeto Determinar o Staff do Projeto.

Front Office – linha de frente

Coaches – treinadores

Regular Lineup – equipe regular (dia a dia)

Special Teams – times especiais

Free Agents - consultores


Planejamento do Projeto Front Office – linha de frente :

Patrocinador

Direcionador

Gerente/Diretor de BI/DW ou Gerente de Programa


Planejamento do Projeto Coaches – treinadores :

Gerente de Projetos

Líder de Negócios


Planejamento do Projeto Regular Lineup – equipe regular (dia a dia) :

Analista de Negócios.

Analista de Dados/Qualidade

Arquiteto/Modelador de Dados

Gerente/Analista de Metadados

Arquiteto/Desenvolvedor de ETL

Arquiteto/Desenvolvedor de BI


Planejamento do Projeto Special Teams – times especiais :

Arquiteto/Especialista Infra

Gerente/Analista de Segurança

Testador/Equipe Testes

Estatístico/Data Mining

Educador


Planejamento do Projeto Free Agents – consultores :

Consultores Externos

IMPORTANTE: Na utilização de consultores, programe transferência de conhecimento

para o time interno.


Planejamento do Projeto Desenvolva um Plano de Projeto O plano deve ser Integrado e Detalhado.

Deve ser detalhado o bastante para que as tarefas sejam acompanhadas.

Invista tempo na montagem de um Plano de Projeto Detalhado, ele é muito útil durante todo Ciclo de Vida.


Planejamento do Projeto Desenvolva um Plano de Projeto

O plano de projeto deve conter :

Recursos

Esforço – Previsto

Data de Início

Data de Término – Prevista

Data de Término – Efetiva

Status ( Percentual )

Dependências


Em Resumo

O planejamento determina a abrangência do Projeto.

Nessa fase determinamos custos e benefícios.

Definimos o time de trabalho


Documentos da Fase

Documento de Escopo

Plano de Projeto


Gerenciamento do Projeto


Gerenciamento do Projeto O projeto de DW tem alguns itens que podem fragilizar o seu gerenciamento :

Equipe de Implementações MultiFuncionais.

Ciclo de Desenvolvimento Interativo e Complexo.

Problemas inevitáveis com dados.

Visibilidade Elevada


Gerenciamento do Projeto Itens importantes no Gerenciamento de Projetos de DW :

Reunião Inicial ( Kickoff Meeting )

Monitoramento do Status do Projeto Reuniões de Status

Relatórios de Status

Manutenção do Plano de Projetos e Documentação.

Gerenciamento do Escopo Registrando os problemas

Controlando as mudanças

Documento de requisito de mudanças

Gerenciamento de Expectativas


Kickoff Meeting Exemplo de uma agenda para Reunião de Kickoff


Monitoramento do Status do Projeto

Relatórios de Status

Acompanhamento dos trabalhos

Trabalhos Planejados x Realizados

Problemas encontrados


Monitoramento do Status do Projeto

Reuniões de Status

Revisão do Plano de Projetos Tarefas Planejadas x Executadas

Tarefas Pendentes

Discussão de Problemas e Encaminhamento Atribuição de pessoas para a resolução dos problemas

Mudanças Requeridas no Plano de Projetos Status das mudanças requeridas e encerradas

Avaliação de novos pedidos de mudanças

Revisão das mudanças em aberto


Manutenção do Plano de Projetos e Documentação.

O Plano de Projetos é a ferramenta de acompanhamento do Gerente de Projetos, de nada adianta um planejamento se ele não é atualizado.

A documentação é importante para demonstrar e arquivar o que foi feito no projeto. O ideal é que seja datada e sempre atualizada.


Gerenciamento do Escopo Para gerenciar o escopo dividimos essa tarefa em 2 itens:

Registro do Problema – Issue ou Ocorrência

Controle de Mudanças


Gerenciamento do Escopo Registrando os problemas (Issues)

Os problemas devem ser expostos para serem discutidos e resolvidos.

Podem gerar impactos ou não.

Alguns registros podem ser de alterações no escopo do projeto que não foram levantadas, nesse caso devem ser negociadas.


Gerenciamento do Escopo Registrando do problema (Issues)

Item #

Tarefa /

Tópico

Problema / Item Levantado

Data

Resp

Data

Fechamento

Status

Prioridade

Reportado

Por


Gerenciamento do Escopo Controlando as mudanças

Qualquer item que impactar em alteração de cronograma, custo ou escopo, deve ser gerenciado como mudança.

Geralmente os maiores impactos são causados por pequenas tarefas que se acumulam e não endereçados corretamente.


Gerenciamento do Escopo

No.

Mudança

Requerimento da Mudança

Req.

Por

Data Req.

Priorid.

Resp.

Esforço

Custo

Data Fecha

Status

Planilha de controle de mudanças

Documento de Requisição de Mudança Usuário requisitante, aprovador. Data Requisição, Data Encerramento. Esforço e Custo


Gerenciamento do Escopo

Documento de Requisição de Mudança :

Usuário requisitante, aprovador. Data Requisição, Data Encerramento. Esforço e Custo


Gerenciamento de Expectativas Gerenciando as Expectativas dos :

Time do Projeto

Patrocinadores e Direcionadores

Comunidades dos Usuários


Sinais de Problemas no Projeto Sem envolvimento Senior dos usuários.

Priorização de tecnologia em relação ao negócio.

Muitos Problemas nos dados de origem.

Desenho do DW igual ou semelhante ao legado.

Falta de aceite dos usuários para as entregas do projeto.


Gerenciamento do Programa

Após ser implantado, o projeto se torna um programa, devemos atentar :

Estabelecer processos e governança dos dados

Sempre focar na visão “empresarial”

Pensar no investimento de longo prazo.

Manter TI e Negócios alinhados.

Manter estrutura, processos e metadados.

Manter a comunicação, sempre.


Em Resumo

O gerenciamento determina as ferramentas de comunicação e controles do projeto.

A comunicação pode ser feita por relatórios ou reuniões.

Todo pedido de alteração deve ser registrado e negociado.

Toda mudança deve ser controlada.


Documentos da Fase

Relatório de Status

Ata da Reunião de Status

Plano de Projeto ( Revisão e Atualização )

Planilha de Registro de Problemas e Itens

Planilha de Controle de Mudanças

Documento de Requisição de Mudanças


Definição dos Requisitos de Negócio


Requisitos de Negócio

Os Requisitos orientam todo projeto do Data Warehouse.

A mudança dos requisitos impactam em todo o projeto.

Dedique um tempo considerável para essa etapa.


Abordagens para Definição de Requisitos

Converse com seus usuários.

Não utilize linguagem técnica.

Converse sobre seus objetivos, desafios, problemas enfrentados atualmente, processos mais dispendiosos e como eles tomam decisões.

Sempre considere os requisitos dos usuários em conjunto com os dados disponíveis.


Entrevistas ou Sessões Facilitadas

Entrevistas

Individuais ou com pequenos grupos.

Maior facilidade para agendamento.

Maior participação individual dos usuários.

Geralmente tem nível de detalhe mais profundo.

Sessões Facilitadas

Grupos maiores.

Dificuldade maior de agendamento

Geralmente trata de tópicos mais genéricos.

Define os próximos passos.


Pesquisas Pré-Entrevistas

Identifique os objetivos principais da empresa/departamento.

Quais as principais necessidades de informações.

Entenda a estrutura hierárquica e de processos básicos da empresa/departamento.

Procure alinhar os objetivos do Data Warehouse com os da empresa/departamento.


Selecione os Entrevistados

Área de Negócios

Representantes de negócios das áreas envolvidas no projeto.

Entreviste de maneira horizontal, em um mesmo nível hierárquico para todas as áreas.

Entreviste também de maneira vertical para maiores esclarecimentos de determinados processos de negócio.

Os usuários finais da informação podem passar maiores detalhes das necessidades do Data Warehouse, mas lembre-se o projeto é seu !


Selecione os Entrevistados

Especialista em Dados/Sistemas Legados.

Entrevistas mais específicas

Mais Técnicas.

Direcionadas para o entendimento do sistema legado.

Entendimento dos processos de captura dos dados.


Desenvolva os Questionários

Sempre desenvolva um questionário para as entrevistas.

O questionário varia de acordo com o perfil e área de negócio do usuário.

Use o questionário como guia e não somente como fonte única de questões.

O questionário é uma excelente ferramenta para padronização do levantamento.


Agendamento das Entrevistas

Monte o agendamento em função dos usuários.

Atenção a seqüência das Entrevistas

Hora e Local

Se possível, faça todas de um mesmo assunto antes de iniciar um novo tema.


Preparação dos Entrevistados

O ideal é que todos os entrevistados tenham participado do KickOff.

Sempre introduza o assunto a ser discutido previamente no convite para entrevista.

Pode-se enviar um documento prévio para que o usuário se prepare para a entrevista.

Se possível, peça que o usuário demonstre relatórios que fazem parte da sua rotina.


Conduzindo as Entrevistas

Não esqueça seu papel na Entrevista

Você irá aprender

Verifique a Comunicação

Defina a Terminologia

Mantenha a Flexibilidade na Agenda

Cuidado com o Excesso de Entrevistas

Gerencie as Expectativas


Iniciando as Entrevistas

Executivos/Líderes de Negócios

Quais são os objetivos da empresa/corporação ?

Como o sucesso pode ser medido ?

Como saber se as coisas estão indo bem ?

Quais os principais problemas de negócios são enfrentados atualmente ?

Como pode se identificar os problemas ?

Como pode se melhorar a informação na empresa ?



Gerentes ou Analistas de Negócio

Quais são os objetivos do seu departamento ?

Como o sucesso pode ser medido ?

Como saber se as coisas estão indo bem ?

Quais os principais problemas de negócios são enfrentados atualmente ?

Descreva seus produtos e processos de negócio.

Quais dados são usados ? Como os dados são capturados atualmente ?

Quais análises são executadas ?



Especialistas em Dados ou Sistemas Legados

Overview nos pontos chaves do Sistema Legado.

Como a informação é disseminada para os usuários ? Quais ferramentas ? Meios ?

Quais os maiores gargalos atualmente ?

Quais as expectativas em relação ao Data Warehouse ?

Existem migrações ou grandes alterações previstas para o legado ?


Analise os dados disponíveis

Analise os dados

Veja as estruturas disponíveis

Qualidade

Data Profiling ( Perfil de Dados )

Como Capturar


Encerrando as Entrevistas

Se necessário implemente métricas Quantidade de usuários entrevistados

Sistemas mapeados

Previsto x Realizado.

Envolvimento dos usuários

Entendimento dos requisitos


Sugestão para coleta de requisitos :

Sessão com todos os envolvidos, para : Definição dos processos de negócios. Responsáveis. Visões necessárias. Sistemas Fontes.

Entrevistas Individuais, para : Detalhar os processos de negócios. Sistemas Legados.

Quem vamos entrevistar : Gestores de Negócios. Analistas de Negócios. Analistas dos Sistemas Legados.


Revisando os Resultados das Entrevistas

Discuta com o time do projeto cada tópico das entrevistas

Direcione as dúvidas de volta aos grupos entrevistados

Revise os materiais das entrevistas, relatórios, e esquemas feitos para elucidar quaisquer dúvidas.


Preparando e publicando os resultados

Descrição minuciosa das Entrevistas

Transcreva todo o resultado das entrevistas

Envie para uma revisão dos usuários

Faça isso de uma maneira clara e intuitiva

Documento de Descrição dos Requisitos

Unifique as entrevistas orientadas por assuntos e relacione os tópicos mais relevantes com seus entrevistadores.

Monte um documento final de entendimento


Finalizando o Levantamento de Requisitos

Elabore um documento estruturado com :

Visão Executiva

Visão Geral do Projeto

Requisitos do Negócio Revisão dos Objetivos do Negócio

Requisitos para análise

Análise do Sistema Fonte

Critério de sucesso


Bus Matrix / Matriz de Barramento

Nesse momento podemos desenhar um rascunho da bus-matrix onde iremos ter uma visão inicial dos processos de negócios e suas quebras.


Próximos Passos

Facilitação para Confirmação, Priorização e Consenso.

Workshops


Em Resumo

Talvez a fase mais importante do Projeto.

Responsável por entender e documentar as necessidades dos usuários.

Os requisitos levantados determinam as próximas etapas do DW


Documentos da Fase

Email de Pré-Entrevista para os usuários

Questionários :

Para executivos

Para Gerentes e Analistas de Negócio

Para Analistas de Sistemas Legados

Resumo/Transcrição das Entrevistas

Documento Final de Requisitos


Trilha de Tecnologia


Technology Track ( Trilha de Tecnologia )

Desenho da Arquitetura Técnica

(Technical Architecture Design)

Seleção e Instalação de Produtos

(Product Selection & Installation)


Arquiteturas de Data Warehouse

Kimball – Bottom-up

Stagings para Data Marts

Inmon – TopDown (CIF)

Data Warehouse Central para Data Marts

Abordagem Hibrida

Combinação das duas técnicas


Estrutura do DW – segundo Kimball


Estrutura do DW – Inmon Corporate Information Factory (CIF)


Visão geral do CIF


Abordagem Híbrida – CIF e Kimball


Visão Geral de Arquitetura

Back Room

Front Room

Metadados Infra Estrutura e Segurança


Arquitetura do Back Room (ETL)

Considere que seu ETL deve prover :

Produtividade

Usabilidade

Gerenciamento de Meta Dados

Comprar, Construir ou open source ?


Funções do ETL

Extração

Captura dos dados e extração

Limpeza e Padronizãção

Corrigir, Limpar

Padronizar remover duplicações

Entrega

Atividades ligadas ao modelo dimensional

Gerenciamento


Armazenamento de Dados no ETL

Armazenamos :

Dados dos Sistemas Origens

Tabelas de Lookup e Decode

Tabelas de Qualidade de Dados.

Como :

Bancos de Dados

Arquivos


Arquitetura da Camada de Apresentação

Considere :

Acesso a todos os dados de análises

Acesso a dados atômicos e sumarizados.

Camada única de acesso aos dados.


Principais funções

Armazenamento dos Dados

Performance para as consultas

Modelada em Modelo Dimensional


Arquitetura do Servidor de BI

Principais Funções:

Interface que os usuários acessam os dados

Prover segurança

Monitorar uso

Gerenciamento de Consultas

Portal de BI


Infra Estrutura para o BI

Fatores Determinantes

Volume de Dados

Volatilidade

Número de Usuários

Número de Processos de Negócio

Natureza do Uso

SLA’s Acordados

Depêndencias técnicas

Disponibilidade do Software

Recursos Financeiros


Processo de Desenvolvimento da Arquitetura


Plano de Arquitetura

Monte uma força tarefa

Recolha os requisitos de Arquitetura

Crie um rascunho inicial (draft)

Revise o rascunho com os usuários e pessoal de TI e incorpore os feedbacks

Crie um modelo de arquitetura técnica

Determine fases de implantação

Identifique entregas para cada fase

Finalize o Plano de Arquitetura


DWLC – Desenho da Arquitetura Técnica – Modelo de Arquitetura


DWLC – Desenho da Arquitetura Técnica – Plano de Infra-estrutura


Seleção de Produtos

Mantenha sempre o foco no negócio.

Produtos comumente avaliados :

Plataforma de Hardware

Plataforma de Banco de Dados

Ferramenta de ETL ( Staging )

Ferramenta de Acesso aos Dados (BI)


Seleção de Produtos

Duas linhas principais guiam a seleção dos produtos :

Requisitos de Negócios

Requisitos Técnicos

Podem ser utilizados protótipos ou POC ( Proof of Concept ) para análise dos produtos.


Processo de Avaliação Não pode ser longo demais, pois pode prejudicar o projeto.

Desenvolva uma matriz de avaliação.

Faça pesquisas no mercado

Visite outros clientes de determinado produto

Estude a construção de um protótipo

Esse protótipo deve ter dados significativos

Monte casos de teste

Defina critérios de comparação


Em Resumo ( Trilha de Tecnologia )

Responsável pela definição da arquitetura técnica

Responsável pela seleção dos produtos


Trilha de Dados


Data Track ( Trilha de Dados ) Modelagem Dimensional

(será abordado nos cursos Modelagem Dimensional – I e II)

Desenho Físico

(será abordado nos curso Modelagem Dimensional – I)

Desenho e Desenvolvimento da Área de Preparação de Dados.

(será abordado no curso de ETL)


Modelagem Dimensional

Traduz os requisitos levantados em modelos de dados.

Transforma os dados dos sistemas de origem em dados mais fáceis de serem analisados


Documentos da Fase

4 Passos

Data Mart Matrix ( Bus Matrix )

Documentação do Modelo de Dados

Logical Data Map ( Source to Target )

apresentação do powerpoint · formação analista de bi microsoft staging area a staging area...

Documents