ppt - workshop - bi
TRANSCRIPT
www.brq.com
Workshop
Business Intelligence
Hugo Ayres Cardoso – Especialista em BI
www.brq.com
Agenda
Conceitos
Diferenças
Vantagens
Cases
www.brq.com
Conceitos
www.brq.com
O que é Business Intelligence?
“Business Intelligence is the process of transforming data into information and through discovery transforming that information into knowledge.”
Gartner Group
www.brq.com
Converter o volume de dados em valorpara o negócio através de relatórios
analíticos.
www.brq.com
Propósito de Business Intelligence
Decisão
Conhecimento
Informação
Dado
Valor
Volume
www.brq.com
Evolução de BI
Decision Support System
Business Intelligence
www.brq.com
Decision support systems (DSS)
Bases Dispersas
Usuários
www.brq.com
Decision support systems (DSS)
Relatórios desenvolvidos sob demanda
Alto tempo de resposta Pouca capacidade de
análise Impacto de desempenho
do ambiente de produção Baixa credibilidade nas
informações Baixa produtividade Inabilidade de
transformar dado em informação
Esforço Duplicado Múltiplas Tecnologias Relatórios Obsoletos Nenhum metadado
Problemas com
Qualidade do Dado no Processamento de Extração
Base de Tempo não comum
Algoritmos de cálculo diferentes
Níveis de extração diferentes
Níveis de granularidade diferentes
Nomes de campos diferentes
Significados de campos diferentes
Informação faltante Nenhuma regra de
correção
Desvantagens dessa abordagem
www.brq.comwww.brq.com
Data Warehousing e Business Intelligence
InputExterno
ODS
DW
Repositório de Metadados
Sistemas Origens
StagingArea Apresentaç
ão
Ferramentas de Acesso
Legado
DataMarts
www.brq.com
Propriedades do Data Warehouse
Dado é categorizado e armazenado pelo
Interesse ao Negócio em vez de ser pela
aplicação simplesmente
Dado em determinada área de interesse é
definido e armazenado somente uma vez
Tipicamente o dado num data warehousenão é atualizado nem
deletado
Dado é armazenado numa série de
snapshots, cada um representando umperíodo de tempo
“A data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of management’s decisions.”
W.H. Inmon
www.brq.com
Alterando o Dado do WarehouseBase de Dados Operacional Base de Dados Warehouse
Carga inicial
Atualização
AtualizaçãoExpurgo ou Arquivamento
www.brq.com
Data Warehouse
Características Implementação em grande escala Abrange todo o negócio Dados de todas as áreas Desenvolvido incrementalmente Fonte única para o dado corporativo Dado corporativo sincronizado Ponto de distribuição único para data marts
www.brq.com
Data Warehouse vs. Data MartsPropriedade Data Warehouse Data Mart
Escopo Corporativo Departamental
Área de Negócio Múltiplas Única linha de Negócio
Origem Várias Poucas
Tempo de Implementação
Médio a Longo prazo
Curto a Médio prazo
Data Mart Dependente Data Mart
Independenteorg1
DMFin
org2
org3
org4
DMRH
DMCSC
org1
org2
org3
org4
DW
DMFin
DMRH
DMCSC
www.brq.com
Data Warehouse
Staging Area É a área de trabalho do data warehouse. É o lugar onde se colocam os dados primários, onde se limpa, combina, arquiva e, ao final, exportam esses dados para um ou mais data marts. O propósito da párea de data staging é preparar os dados para carrega-los em um servidor de apresentação (um SGBD relacional ou software OLAP). Assumimos que a área de data staging não é um serviço de consulta. Em outras palavras, qualquer banco de dados que é usado para consultas assume-se que esteja fisicamente ajusante da área de data staging.
www.brq.com
Data Warehouse
ODSInmon Kimball
Uma estrutura híbrida projetada para apoiar tanto processamento operacional transacional quanto processamento analítico.
Base de dados integrados, volátil, retrato instantâneo do Negócio.
Estrutura útil para relações de um-para-um entre o setor de marketing e cliente, e para áreas onde apenas as transações mais recentes são importantes.
Depósito de dados histórico, frequentemente alimentado, de dados detalhados e integrados, constituindo-se no nível atômico do ambiente de DW.
www.brq.com
Data Warehouse
Metadados
“dados sobre os dados” Quaisquer informações que permitam identificar, localizar,
utilizar e entender os dados
Metadado Técnico e Administrativo Altamente estruturado Informações com definições, transformações, gerência
e operação Geralmente tratável via uma ferramenta de repositório
Metadado de Negócio Tanto não-estruturado quanto estruturado Mais difícil de ser tratado e integrado por uma
ferramenta altamente estruturada tipo um repositório
www.brq.com
Data Warehouse
Outros Componentes de um Ambiente de DW
Repositório de Metadados Ferramentas de Projeto CASE Ferramentas de Extração, Transformação e Carga (ETL) Ferramentas para Qualidade e Limpeza Ferramentas para Replicação Provedores de Interfaces de BD ODBC/OLE Ferramentas de Gateway para BD Legados Bancos de Dados Relacionais Bancos de Dados Não-Relacionais (Legados) Bancos de Dados Multidimensionais Ferramentas OLAP Ferramentas de Relatório e Consulta Ferramentas de Data Mining Cross-Platform Batch Schedulers Ferramentas de Monitoramento e Controle Pacotes de Aplicação para Data Warehouse
www.brq.com
Data Warehouse
Modelo DimensionalDimensão
As dimensões identificam um indicador de análise sobre um empreendimento, negócio ou ação feita. Através das dimensões é possível identificar quando (mês, ano), onde (estado, região) e com quem (segurado, produto) ocorreu um indicador de análise (prêmio emitido).
As dimensões relacionam-se através de hierarquias. Isto permite que um indicador, embora estando ligado a apenas uma dimensão da hierarquia, possa ser visto por todas as dimensões superiores a ela na hierarquia. Por exemplo, o indicador “prêmio pago” é identificado pela dimensão ‘dia emissão’. Como essa dimensão pertence à hierarquia de tempo, o indicador também pode ser visto pelas dimensões ‘mês emissão’, ‘trimestre emissão’, ‘semestre emissão’ e ‘ano emissão’.
A chave primária de uma dimensão é sempre uma chave substituta (surrogate key). Isso facilita a integração de diferentes fontes de dados.
Na carga da tabela de dimensão podem ser feitas operações de inserção (insert) e atualização (update).
Fato
Um fato representa um indicador de análise elementar. O indicador de análise é uma medição numérica que pode, por exemplo, representar medidas relacionadas ao negócio (ex.: valor do prêmio emitido, valor do sinistro pago) ou quantificar uma característica da transação (ex.: quantidade de propostas implantadas, quantidade de beneficiários). Utilizado para monitorar resultados, permitindo análises gerenciais dos processos nas áreas usuárias da aplicação analítica.
Os indicadores podem ser classificados como: Indicadores elementares não podem ser
fracionados em outros valores. Os indicadores elementares que apresentam as mesmas características e que podem ser visualizados pelas mesmas dimensões são agrupados nas chamadas tabelas de fatos.
Indicadores compostos são resultantes de cálculos realizados com outros indicadores. Para cada indicador composto será apresentada a sua fórmula de cálculo. (ex.: Taxa de Cancelamento de Proposta é a razão entre o indicador Quantidade de Propostas Canceladas e o indicador Quantidade de Propostas Emitida).
A chave primária da tabela de fatos é composta das chaves primárias das dimensões que a qualifica.
Na carga da tabela de fatos são feitas somente operações de inserção (insert).
www.brq.com
Data Warehouse
Modelo Dimensional – Snowflake As dimensões são normalizadas. Cada nível da
hierarquia é implementada em uma tabela de dimensão.
Fato SinistroCod. ID Data de AvisoCod. ID SeguradoCod. ID CorretorCod. ID AvisoVal Sinistro
Dim Tempo AvisoCod. ID Data de AvisoDia de AvisoCod. ID MêsCod. ID Semana
Dim CorretorCod. ID CorretorCod. CorretorNome CorretorCod. ID Sucursal
Dim SeguradoCod. ID SeguradoCod. SeguradoNome SeguradoCod ID Bairro do SeguradoCod ID SexoCod ID Estado Civil
Dim Aviso SinistroCod. ID AvisoCod. AvisoCod. ID Motivo
Dim Bairro SeguradoCod. ID Bairro SeguradoNome BairroCod ID Vidade Segurado
Dim Cidade SeguradoCod. ID Cidade SeguradoNome CidadeCod ID UF Segurado
Dim UF SeguradoCod. ID UF SeguradoNome UF
Dim SexoCod. ID SexoDesc Sexo
Dim Estado CivilCod. ID Estado CivilDesc Estado Civil
Dim Motivo SinistroCod. ID MotivoCod MotivoDesc Motivo
Dim Semana AvisoCod. ID SemanaSemana de Aviso
Dim Mês AvisoCod. ID MêsMês de Aviso
Dim Ano AvisoCod. ID AnoAno de Aviso
Dim SucursalCod. ID SucursalCod. SucursalNome Sucursal
www.brq.com
Data Warehouse
Modelo Dimensional – Star As dimensões são desnormalizadas. Uma hierarquia é
implementada em uma única tabela, ou os níveis são associados diretamente à tabela de fatos.
Fato SinistroCod. ID Data de AvisoCod. ID Data de OcorrênciaCod. ID SeguradoCod. ID CorretorCod. ID AvisoVal Sinistro
Dim Tempo AvisoCod. ID Data de AvisoDia de AvisoSemana de AvisoMês de AvisoAno de Aviso
Dim CorretorCod. ID CorretorCod. CorretorNome CorretorCod. SucursalNome Sucursal
Dim SeguradoCod. ID SeguradoCod. SeguradoNome SeguradoBairro do SeguradoCidade do SeguradoUF do SeguradoDesc SexoDesc Estado Civil
Fato Aviso SinistroCod. ID AvisoCod. AvisoCod. MotivoDesc Motivo
www.brq.com
Data Warehouse
Modelo Dimensional – Starflake É um híbrido entre os modelos star e snowflake,
aproveitando o melhor de cada um.
Fato SinistroCod. ID Data de AvisoCod. ID SeguradoCod. ID CorretorCod. ID AvisoCod ID SucursalVal Sinistro
Dim Tempo AvisoCod. ID Data de AvisoDia de AvisoCod. ID MêsCod. ID Semana
Dim CorretorCod. ID CorretorCod. CorretorNome Corretor
Dim SeguradoCod. ID SeguradoCod. SeguradoNome SeguradoCod ID Localização SeguradoCod ID SexoCod ID Estado Civil
Dim Aviso SinistroCod. ID AvisoCod. AvisoCod. ID Motivo
Dim Localização SeguradoCod. ID Bairro SeguradoNome BairroNome CidadeNome UF
Dim SexoCod. ID SexoDesc Sexo
Dim Estado CivilCod. ID Estado CivilDesc Estado Civil
Dim Motivo SinistroCod. ID MotivoCod MotivoDesc Motivo
Dim Semana AvisoCod. ID SemanaSemana de Aviso
Dim Mês AvisoCod. ID MêsMês de Aviso
Dim Ano AvisoCod. ID AnoAno de Aviso
Dim SucursalCod. ID SucursalCod. SucursalNome Sucursal
www.brq.com
Conceito Pontual O valor pontual representa a interseção de valores (fatos) com relação aos eixos das dimensões. Por
exemplo, o produto P na região R no dia D vendeu a quantidade Q.
Conceito Slicing Diz respeito a um plano de valores, com uma das dimensões fixa em um elemento. Por exemplo, o produto
P na região R no dia 25/09/2007 vendeu a quantidade Q.
Data Warehouse
Conceito de Operações Dimensionais de Seleção
www.brq.com
Conceito Dicing Diz respeito a um cubo de valores, com os elementos das dimensões sendo fixados em intervalos ou
conjuntos. Por exemplo, o conjunto de produtos P1, P2 e P3 nas regioes R1 e R2 do início do mês até hoje vendeu a quantidade Q.
Conceito Pivoting
Por esse conceito, a seleção pode sofre rotação em seus eixos (colunas viram linhas, linhas viram colunas).
Data Warehouse
Conceito de Operações Dimensionais de Seleção
www.brq.com
Conceito Drilling UP, Down e Across
Estes conceitos estão relacionados com a granularidade que se deseja nos relatórios. Os comando de drill up, down e across dizem respeito à granularidade existente dentro de um único datamart.
Mês Loja Valor da Venda2007 A 5.250,00R$ 2007 B 3.300,00R$
Mês Loja Valor da Vendajan/07 A 1.500,00R$ jan/07 B 500,00R$ fev/07 A 3.750,00R$ fev/07 B 2.800,00R$
Dia Loja Valor da Venda01/01/2007 A 1.500,00R$ 01/01/2007 B 500,00R$ 02/02/2007 A 2.000,00R$ 02/02/2007 B 1.200,00R$ 03/02/2007 A 1.750,00R$ 03/02/2007 B 1.600,00R$
Mês Produto Valor da Vendajan/07 Nescau 200,00R$ fev/07 Nescau 300,00R$
DrillUP
Subindonível de
Hierarquia
DrillDown
Descendo nível de
Hierarquia
Drill AcrossMudança de Hierarquia
Data Warehouse
www.brq.com
Conceitos de ETL
Para que os dados saiam de um modelo origem e migrem para um modelo dimensional, são necessários 5 tratamentos diferentes (filtro, integração, condensação, conversão e derivação), divididos em 3 processos (extração, transformação e carga).
Filtro de Dados Relaciona os procedimento e condições para selecionar os dados desejáveis no modelo dimensional. Por exemplo, selecionar apenas os segurados ativos.
Integração de Dados Define a forma de se correlacionar informações existentes me fontes de dados distintas.Por exemplo: segurado de Automóvel e segurado de Saúde com informações comuns (nome, endereço) e informções
específicas a cada área; Códificação diferenciada em dimensões (sexo, estado civil e outras).
Condensação de Dados Define a forma de reduzir o volume de dados visando obter informações resumidas e sumariadas
(agregações).Conversão de Dados Define os procedimentos para se transformar dados em unidades e formatos diferentes. Por exemplo, conversão de datas, unidades monetárias, taxas.
Derivação de Dados Define os meios e fórmulas para se produzir dados virtuais, a partir de dados existentes, minimizando a
complexidade de uma consulta ou aumentando a sua performance. Por exemplo, cálculo de percentuais, participações, médias ponderadas, desvios padrões.
Data Warehouse
“Efetivos processos de ETL representam o fator de sucesso número um para seu projeto de data warehouse e podem absorver até 70% do tempo gasto num típico projeto de data warehousing” - DM Review, Março de 2001
www.brq.com
Processos de ETLExtração Executa o tratamento de Filtro de Dados.extraindo as informações dos sistemas transacionais.
Transformação Executa os tratamentos de Integração de Dados, Condensação de Dados, Conversão de Dados e Derivação
de Dados.Carga Carrega na base dimensional os dados devidamente processados e integrados.
Data Warehouse
Sistemas Origens
Staging Area
InputExterno
LegadoDW
DataMarts
Extração
Transformação
Carga
www.brq.com
Data Warehouse
Abordagem para construção de um DW Atualmente muitas organizações precisam se utilizar de grandes volumes de dados, armazenados ao longo do tempo, como fonte de análise para apoiar a tomada de decisão. Isto é possível criando estruturas chamadas de data warehouse.
Uma organização precisa escolher qual o conjunto de ferramentas de desenho e manutenção destas estruturas que melhor se adaptarão à suas necessidades. Nem todas são compatíveis entre si ou apropriadas para todas as metodologias de desenvolvimento.
As ferramentas e metodologias utilizadas geralmente estão baseadas em dois modelos: o modelo defendido por Bill Inmon, a partir de uma abordagem top down, e o modelo defendido por Ralph Kimball, a partir de uma abordagem bottom up.
Basicamente, os dois autores divergem sobre o melhor approach. Kimball sugere que o DW deva ser “dividido para depois ser conquistado”, construindo-se data marts para posteriormente chegar ao data warehouse. Inmon sugere que o DW deva ser projetado de uma só vez, modelando-se toda a empresa e chegando-se a um único modelo corporativo, partindo-se posteriormente para os data marts.
Para escolher entre um modelo ou outro, ou até mesmo um modelo híbrido (utilizando abordagens, ferramentas ou metodologias de ambos os modelos), é necessário entender onde estes dois modelos são similares e onde eles diferem, e qual a arquitetura e metodologia básica de cada um.
Conhecendo as abordagens existentes, podemos identificar, para cada organização, qual modelo melhor se ajusta às suas necessidades de negócio.
www.brq.com
Data WarehouseAbordagem Bottom Up
A abordagem bottom up defendida por Ralph Kimball sugere a criação de data marts para cada processo de negócio. Ou seja, deve- se construir data marts orientados por assuntos para posteriormente integrá-los e assim chegar ao data warehouse corporativo.
Data marts orientados por assuntos com pontos de conexão entre eles, que seriam as tabelas de fatos e dimensões em conformidade. Desta forma, informações entre diferentes data marts poderiam ser geradas de maneira íntegra e segura. Kimball batizou esse conceito de Data Warehouse Bus Architecture
Modelagem
Segundo Kimball, o data warehouse deve utilizar a modelagem de dados dimensional. Na modelagem dimensional são criadas tabelas de fatos e tabelas de dimensões. As tabelas de fatos contém as métricas e as tabelas de dimensões contém os atributos das métricas.
As restrições e filtros aos dados são realizadas nas tabelas dimensionais indexadas, e só então as tabelas de fatos são “atacadas”, de uma só vez, a partir das chaves das tabelas dimensionais que satisfaçam as restrições.
A modelagem dimensional aproveita ao máximo os requisitos de um data warehouse. Tabelas de fatos associadas a dimensões altamente desnormalizadas resultam em data marts altamente acessíveis aos usuários finais, além de normalmente fornecer alto nível de performance (tempo de resposta às consultas).
org1
DMFin
org2
org3
org4
DMRH
DMCSC
DW
www.brq.com
Data WarehouseAbordagem Bottom Up
ConclusãoCada data mart é baseado em um único processo de negócio. Ralph Kimball argumenta que os data marts não podem ser departamentais, mas sim orientados aos dados ou a fontes dos dados. Assim, as informações tratadas por um determinado assunto, em um data mart , poderão ser acessados por todas as pessoas que precisam destas informações, independente dos departamentos a que pertençam.
A abordagem de Kimball recomenda construir um data mart por processo de negócio. A soma de todos os data marts é o data warehouse da organização. O data warehouse bus architecture defendida por Kimball assegura interoperabilidade entre os vários data marts, pois exige que todos os data marts sejam modelados obedecendo a uma padronização dos dados, através da criação de dimensões em conformidade.
Kimball recomenda também um processo de desenvolvimento em quatro etapas, para cada data mart, nas quais a modelagem de dados dimensional desempenha um papel central.
Modelagem de dados dimensional envolve tabelas de fatos que contém dados de métricas e tabelas de dimensões que alteram aqueles dados. Ferramentas de modelagem dimensional podem ser amplamente usados por usuários finais com um mínimo de treinamento. Isto ajuda a garantir que os usuários finais estejam inteiramente envolvidos no desenvolvimento do data warehouse.
Com a modelagem de dados dimensional os usuários podem esperar, a partir dos data marts gerados, facilidade no uso e bons tempos de respostas.
www.brq.com
Data WarehouseAbordagem Top Down
A abordagem top-down defendida por Inmon sugere a construção de um data warehouse modelando-se toda a empresa, para se chegar a um único modelo corporativo, partindo posteriormente para os data marts construídos por assuntos ou departamentais.
Segundo Inmon, não se deve construir data marts antes do data warehouse. Data marts devem atender a requisitos proprietários, departamentais. Sendo assim, para cada data mart, seriam delineadas regras específicas de negócios, bem como procedimentos específicos de extração, transformação e carga dos dados oriundos dos sistemas transacionais. Ou seja, começando pelo data mart a visão corporativa da empresa ficaria em segundo plano.
Raramente é recomendável construir um enterprise data warehouse utilizando uma abordagem big-bang. Tentar construir um data warehouse todo de uma só vez é totalmente imprudente e arriscado. O ideal é construir um data warehouse por meio de iterações.
org1
org2
org3
org4
DW
DMFin
DMRH
DMCSC
www.brq.com
Data WarehouseAbordagem Top Down
Conclusão
A abordagem de Inmon enfatiza o desenvolvimento top down utilizando metodologias de desenvolvimento de banco de dados já consagradas, tais como diagramas de entidade-relacionamento (ERDs), definição dos itens de dados para cada entidade (DISs), e a condução do projeto a partir de uma derivação da abordagem de desenvolvimento em espiral. Ou seja, os métodos e as ferramentas de Inmon são adaptações de métodos e ferramentas tradicionais para desenvolvimento de bancos de dados operacionais.
Inmon enxerga o data warehouse como parte de um enorme ambiente informacional, que ele chama de Corporate Information Factory (CIF). Para assegurar que o data warehouse se ajuste bem neste grande ambiente, ele defende a construção de data warehouses atômicos e data marts departamentais.
A abordagem Inmon é mais evolucionária do que revolucionária. Suas ferramentas e métodos são direcionados aos profissionais de IT. Por conta disso, usuários finais têm uma participação menos ativa durante o processo de desenvolvimento.
A atenção de Inmon para os aspectos técnicos do processo de desenvolvimento do data warehouse aumentam as chances de uma solução técnica quase perfeita. Para os usuários finais, isto provavelmente significará ótimos tempos de respostas às suas consultas.
www.brq.com
Data WarehouseSimilaridades entre os modelos
As similaridades mais visíveis entre os modelos de Inmon e Kimball estão no tratamento da informação de tempo, e nos processos de extração, transformação e carga (ETL) dos dados, a partir dos sistemas transacionais. Embora existam pequenas diferenças conceituais, os resultados e os objetivos são muito similares.
Kimball chama o atributo tempo de dimensão data
A dimensão data possui uma chave de data, que é uma chave artificial que define a dimensão em conformidade, e todos os atributos necessários para representar a dimensão data
Os dados depois de tratados devem ser carregados em uma série de pequenos bancos de dados (data marts)
Ralph Kimball
Inmon chama o atributo tempo de elemento de tempo
Os atributos podem estar em várias tabelas (modelo mais normalizado) ou até mesmo serem calculados em tempo de execução (a escolha entre armazenar ou calcular deve ser guiadas por questões de performance)
Os dados depois de tratados devem ser carregados diretamente no data warehouse
Bill Inmon
www.brq.com
Data WarehouseDiferença entre os modelos
Metodologia e ArquiteturaBill Inmon Ralph Kimball
Abordagem Top down Bottom up
Arquitetura Data warehouses corporativos e atômicos, que alimentam os bancos de dados departamentais (data marts)
Bancos de dados departamentais (data marts) que modelam um único processo de negócio. A consistência é alcançada através do conceito de data warehouse bus architecture
Complexidade do método
Muito complexo Razoavelmente simples
Comparativo com as metodologias de desenvolvimento já existentes
Derivação/adaptação da metodologia de desenvolvimento em espiral
Processo em quatro etapas, derivada de metodologia RDBMS
Discussão sobre desenho/modelo físico
Razoavelmente completa Razoavelmente simples
Na metodologia defendida por Inmon, o data warehouse atômico deve servir a toda a empresa, e os bancos de dados departamentais (data marts) devem obter seus dados a partir dele. O esfoço de desenvolvimento a partir de abordagens top down têm um grau maior de complexidade, e a metodologia de Inmon não é exceção. Além disso, a metodologia e a arquitetura de Inmon são orientadas para a área técnica. Seu principal interesse é garantir que a solução técnica funcione.
Em contraste, a metodologia em quatro etapas de Kimball é muito acessível aos usuários finais, que podem entender (moderadamente) os conceitos técnicos do data warehouse bus architecture e dimensões em conformidade, sem ter que aprender a ler/interpretar os ERDs, e sem precisar estar familiarizados com todos os conceitos de um processo de negócios (pois o escopo de um data mart é bem menor).
Deve-se ressaltar que a metodologia adotada por Inmon torna o escopo do data warehouse corporativo (que é muito mais abrangente) menos intimidador, mas o escopo menor do data mart é consideravelmente mais fácil para os usuários entenderem.
www.brq.com
Data WarehouseDiferença entre os modelos
Modelagem de Dados
Bill Inmon Ralph Kimball
Orientação aos dados Direcionado aos dados ou aos assuntos Orientado a processos
Ferramentas Tradicionais (ERD – Diagramas de entidade-relacionamento, e DIS – Conjuntos de itens dos dados)
Modelagem dimensional; uma adaptação da modelagem relacional
Acessibilidade pelo usuário final
Baixa Alta
Inmon segue uma abordagem orientada ou direcionada a assuntos para a modelagem dos dados. Isto significa que a natureza dos dados direciona o processo de modelagem, o que se ajusta muito bem às ferramentas de modelagens tradicionais, tais como ERDs e DISs. Significa também que os membros de IT (equipe de data warehouse) têm a responsabilidade principal pela modelagem dos dados. E os usuários pouco podem contribuir com as revisões e validações dos ERDs ou DISs.
Em contraste, Kimball segue a orientação por processos, que signifca que a modelagem torna-se uma tentativa de definir a interação dos dados através dos processos de negócio. Por sua natureza, tais processos de negócio usualmente cruzam as linhas/fronteiras que dividem os diversos departamentos em uma empresa. Isto vai de encontro com a modelagem dimensional, em que os processos determinam quais métricas (fatos) e atributos (dimensões) são importantes e devem reclamar um lugar no data warehouse. Ferramentas de modelagem dimensional permitem aos usuários finais participarem ativamente do processo de modelagem de dados.
www.brq.com
Data WarehouseDiferença entre os modelos
Filosofia
Bill Inmon Ralph Kimball
Público principal Profissionais de IT Usuários finais
Lugar na organização Parte integrante do Corporate Information Factory (CIF)
Transformador e retentor dos dados operacionais
Objetivo Entregar uma solução técnica perfeita baseada em métodos e tecnologias já provadas de desenvolvimento de bancos de dados
Entregar uma solução que torna fácil para usuários finais consultar os dados diretamente e ainda obter razoáveis tempos de respostas
Inmon enxerga a área de IT como a principal desenvolvedora e fornecedora do data warehouse. Ele acredita que a performance do data warehouse estará assegurada com o processo de desenvolvimento bem orientado tecnicamente.
Por outro lado, Kimball enxerga os usuários finais e os profissionais de IT compartilhando deveres e
obrigações igualmente. Assegurando a participação ativa dos usuários finais por todo o processo de desenvolvimento, a probabilidade de aceitação do data warehouse é muito maior.
Ambos são cuidadosos ao afirmar que projetos de data warehouse que não envolvem usuários finais em todos os pontos de seu ciclo de vida, têm uma probabilidade muito grande de fracasso.
www.brq.com
Data WarehouseEscolhendo a Melhor Abordagem
Características A favor de Ralph Kimball A favor de Bill Inmon
Natureza das requisições da tomada de decisão da organização
Tático Estratégico
Requerimentos na integração dos dados
Áreas de negócios individuais Integração organizacional
Estrutura dos dados Métricas de negócio, métricas de performance e scorecards
Dados que não sejam métricas necessariamente, e dados que serão utilizados para múltiplas e variadas necessidades informacionais
Escalabilidade Necessidades altamente voláteis dentro de um escopo limitado
Crescimento do escopo e requisição de mudanças são críticos
Persistência dos dados Sistemas fontes estão relativamente estáveis Alta taxa de mudanças dos sistemas fontes
Requerimentos do Staffing e habilidades
Pequenas equipes de generalistas Grandes equipes de especialistas
Tempo para entrega Primeira aplicação data warehouse é urgente Os requerimentos da organização permitem um tempo maior para visualizar os resultados
Custo para desenvolver Baixo custo de start-up, com cada projeto subseqüente custando quase o mesmo
Alto custo de start-up, com desenvolvimento de projetos subseqüentes com custos menores
Para identificar qual abordagem melhor se ajusta às necessidades organizacionais, recomenda-se a avaliação de critérios que focam nas necessidades, no ambiente, na cultura e na expertise técncia de uma organização que planeja criar um data warehouse. Na tabela a seguir descrevemos as características básicas relacionadas a oito destes critérios, apontando, para cada um deles, qual abordagem é mais favorável.
www.brq.com
Data WarehouseEscolhendo a Melhor Abordagem
Conclusão
Os modelos de Inmon e Kimball são similares em alguns aspectos, tais como o registro e tratamento da informação tempo (embora existam algumas diferenças na forma em que cada modelo trata esta informação) e no processo de carga e tratamento dos dados a partir dos sistemas de origem (cada um endereça a carga para locais diferentes, mas o processo e o resultado são similares).
Existem características nas organizações que favorecem a adoção de um modelo em detrimento de outro. Algumas destas características incluem os requisitos de suporte a decisão da organização, habilidades necessárias, tempo de entrega e custo para desenvolver. Analisar estas características podem auxiliar as organizações a começar um processo de escolha da abordagem para desenvolver seus data warehouses.
Outras pesquisas mostram que ter o conjunto certo de soft skills é tão importante, se não mais importante, do que habilidades técnicas e conhecimento. A chave para o sucesso não está somente na natureza técnica. Projetos não são bem sucedidos porque usam um modelo inovador ou tecnologias novas e radicais. Eles são bem sucedidos por conta da liderança, comunicação, planejamento e relacionamentos inter-pessoais.
O grande desafio é que projetos para desenvolvimento de data warehouse são relativamente novos em comparação com outros projetos de desenvolvimento. Por-isso, uma equipe que tenha um bom conhecimento dos modelos defendidos por Inmon e por Kimball terá melhores condições para articular e identificar uma visão do data warehouse que irá atender às necessidades e características da organização, e aos objetivos para a tomada de decisão.
www.brq.com
Data WarehouseProjeto de DW
Diferencial dos Projetos de BI
Desafios
Dificuldade de entendimento sobre a complexidade de projetos de natureza BI
Necessidade de definição incremental de requisitos Desconhecimento de que estes projetos normalmente são iniciativas inter-
departamentais, não podendo ser desenvolvidos setorizados de forma isolada
Necessidade de patrocinadores com autoridade e engajamento Definição de estrutura e dinâmica particular e adequada para uma equipe
de projeto de BI Estabelecimento de uma metodologia de desenvolvimento específica para
este tipo de projeto Necessidade da atuação efetiva de analistas de negócio Definição e adoção de padrões como requisito obrigatório Forte impacto de eventuais inconsistências e baixa qualidade dos dados
fonte Entendimento da necessidade e do uso de metadados
www.brq.com
Data WarehouseProjeto de DW
Complexidade
Fatores que determinam a complexidade
Estabelecer claramente a diferença entre um projeto de BI e projetos tradicionais
Entender a função de cada um dos componentes específicos da infra-estrutura de uma aplicação de BI
Reconhecer quais são os fatores impactantes em um projeto de BI
Determinar a quantidade e os tipos de recursos, tanto técnicos como humanos
Definir a arquitetura da aplicação, como o projeto de dados multidimensional ou consultas ad-hoc
www.brq.com
Oportunidadede Negócio
Apoio àsDecisões
Estratégicas
Plano de Projeto
Requisitos de Informações Estratégicas
Análise do Negócio
Projeto
Implementação
Teste
Implantação
Avaliação da Versão da Aplicação
Data WarehouseProjeto de DW
Definição incremental dos requisitos
A cada nova iteração no desenvolvimento da aplicação, os requisitos de informações estratégicas são revistos e incrementados
Motivo: Uma aplicação de BI é orientada às oportunidades de negócio, fazendo do processo de desenvolvimento uma atividade dinâmica e iterativa.
Os dados e funcionalidades são disponibilizados em versões (releases) iterativas
Cada nova versão inicia o processo de levantamento de novos requisitos para a próxima versão
www.brq.com
Data WarehouseProjeto de DW
Aplicações BI x Transacionais
Aplicações
Business Intelligence Transacionais
Direção/Orientação
Oportunidades de Negócio Necessidades do Negócio
ImplementaçãoApoio às decisões estratégicas organizacionais
Apoio às atividades departamentais
Requisitos Informações Estratégicas Funcionalidades Operacionais
AnalisesSobre o negócio(atividade mais importante)
Sobre o sistema
www.brq.com
Data WarehouseProjeto de DW
Escopo das Etapas de um Projeto de BI
Etapa do DesenvolvimentoEscopo
Específico do Projeto Inter-departamental
Avaliação dos Casos de Negócio
Avaliação da Infra-estrutura Corporativa
Planejamento do Projeto
Levantamento de Requisitos
Análise de Dados
Prototipação da Aplicação de BI
Análise do Repositório de Metadados
Projeto do Banco de Dados
Projeto do ETL
Projeto do Repositório de Metadados
Desenvolvimento da Aplicação de BI
Desenvolvimento do ETL
Desenvolvimento do Repositório de Metadados
Implantação
Avaliação das Aplicações
www.brq.com
Data WarehouseProjeto de DW
Líder de Desenvolvimento da Aplicação
Arquiteto de Infra-estrutura
Representante do Negócio
Administrador de Dados
Expert em Data Mining
Analista de Qualidade de dados
Administrador de Banco de Dados
Líder de Desenvolvimento de ETL
Administrador de metadados
Gerente de Projeto
Equipe Central
Desenvolvedor de Aplicação
Instrutor da equipe do negócio
Desenvolvedor de ETL
Auditor de TI ou Analista de Qualidade
Desenvolvedor de repositório de metadados
Equipe de rede
Equipe de operação (cargas e atualizações de dados)
Analista de segurança
Stakeholders
Arquiteto de Informação
Equipe de apoio de TI
Testadores
Administradores de Ferramentas
Desenvolvedores Web
Equipe Estendida
www.brq.com
Data WarehouseProjeto de DW
Fases e atividades do Desenvolvimento de Soluções de BIJustificativa•Avaliação dos Casos de Negócio
Planejamento•Avaliação da Infraestrutura Corporativa
•Planejamento do Projeto
Análise do Negócio•Levantamento de Requisitos
•Análise de Dados•Prototipação da Aplicação de BI
•Análise do Repositório de Metadados
Projeto•Projeto do Banco de Dados do ETL
•Projeto do Repositório de Metadados
•Projeto da aplicação analitica
Implementação•Desenvolvimento do ETL
•Desenvolvimento da Aplicação
•Data Mining•Desenvolvimento do Repositório de Metadados
Implantação•Produção•Avaliação da Aplicações
www.brq.com
Diferenças
www.brq.com
Orientação do Dados Orientado por dimensão Todos os tipos de dados são integrados em um
sistema Construção orientada a objetivos
Orientado por Aplicação Diferentes sistemas armazenam diferentes tipos de
dados Construção orientada a processo Integração do Dados
Devem ser integrados Estruturas de chaves padronizadas Convenção de nomes padronizados Formatos de arquivos padronizados Servidor de warehouse único (servidor lógico)
Geralmente não integrados Diferentes estruturas de chaves Diferentes convenções de nomes Diferentes formatos de arquivos Diferentes plataformas de hardware
OLTP - On-Line Transaction Processing
OLAP - On-Line Analytical Processing
Histórico do Dados Posições históricas, armazenamento superior a 2 anos Existe a chave “Tempo” Existem análises ao longo do tempo Fonte de acesso secundária
Somente valores atuais, geralmente 60-90 dias de dados
Não existe a chave “Tempo” Não existem análises ao longo do tempo Fonte de acesso primáriaAcesso e Manipulação do Dados
Apenas seleção (leitura) Atualização via carga de dados (em blocos) Acesso e análise de informações Grande volume de dados envolvido em cada consulta RDBMS (tratamento de join, carga paralela, leitura
“de bloco”)
Inclusão, Alteração, Exclusão e Seleção Atualização on-line registro a registro Acesso e atualização de dados Pequeno volume de dados envolvido em cada
transação RDBMS (tratamento de lock, concorrência, leitura
“de registro”)
Sistemas Transacionais x Analíticos
www.brq.com
Sistemas Transacionais x Analíticos
Uso de CPU
Operacional Analítico
www.brq.com
Vantagens
www.brq.com
Vantagens dos Ambientes deProcessamento de Warehouse
Controlado e Confiável Qualidade da informação Única origem dos dados Nenhum esforço duplicado Nenhuma necessidade de ferramentas para suportar
várias tecnologias Nenhuma disparidade nos dados, no significado, ou na
representação Nenhum conflito de período de tempo Nenhuma confusão de algoritmo Nenhuma restrição a drill-down O ROI é garantido a médio e longo prazo, pois a criação
dos relatórios é automatizada.
www.brq.com
Fatores de Sucesso paraAmbiente Dinâmico de Negócio
Conhecer o negócio Reinventar frente a novos desafios Investir em produtos Investir em clientes Reter clientes Investir em tecnologia Ser lucrativo Fornecer serviços e produtos superiores Melhorar acesso às informações de negócio
www.brq.com
Drivers do Negócio paraData Warehouses
Fornecer sistemas de informação que suportam o negócio
Obter informações de Qualidade Reduzir custos Conduzir o negócio Melhorar margens
www.brq.com
Cases
www.brq.com
Toyota Motor Sales USAProblema
A gerência da TLS exige rastreamento preciso e gerenciamento da cadeia de fornecimento para assegurar que os carros certos vão para os revendedores certos a tempo. O agendamento manual e outros processos relacionados com negócios que forma conduzidos com informações incorretas, causaram mais problemas. Por exemplo, se uma pessoa ocasionou um erro de entrada de dados quando um navio chegou ao estaleiro, o erro persistirá em toda a cadeia de fornecimento. (Por exemplo, alguns dados indicaram à gerência que os navios nunca chegaram a um porto, semanas após os navios chegarem seguramente ao estaleiro.)
Solução Usando um Data Warehouse da Oracle e a plataforma do Business Intelligence da Hyperion, foi criado um novo
sistema. O sistema também incluía o recurso de Dashboard da Hyperion, que permite que os executivos vejam as áreas que merecem atenção em suas unidades de negócio e investiguem mais para identificar os problemas com exatidão, bem como as suas causas. Usando cores diferentes (por exemplo, o vermelho para perigo), um gerente de negócios pode ver em tempo real, por exemplo, quando os tempos de entrega estão se tornando vagarosos e encontrar imediatamente as fontes do problema e até mesmo avaliar soluções potenciais do tipo “e se…”.
Resultado
Dentro de poucos dias, o sistema começõu a apresentar resultados fascinantes. Por exemplo, o sistema ajudou a descobrir que a Toyota era cobrada duas vezes por um envio especial por trem (um erro de US$ 800.000);
Toyota USA conseguiu aumentar o volume de carros que negociava em 40% entre 2001 e 2005, enquanto aumentou o número de funcionários em apenas 3%;
Um estudo independente realizado pela IDC Inc. acerca da justificação do gerenciamento de desempenho de negócios e sistemas de BI indica que a Toyota alcançou um retorno de 506% sobre o investimento em BI. (O retorno de investimento médio para as 43 outras empresas citadas pela Fortune 500, que participaram do estudo, foi de 112%)
www.brq.com
RJZ CyrelaProblema
As áreas de inteligência de mercado, comercial e terrenos são as mais críticas da empresa, pois elas que fazem a pesquisa para detectar a demanda dos clientes, os terrenos disponíveis das cidades e as estratégias de venda.
Solução As três áreas para quem a solução serviria diretamente – inteligência de mercado, comercial e terrenos –
participaram ativamente, inclusive com funcionários testando passo-a-passo cada ferramenta. O envolvimento dos usuários chaves foi essencial para o sucesso da implantação. Foram dois ou três funcionários de cada área trabalhando diretamente com TI.
Dificuldades Enfrentadas
O processo para definir o fornecedor de BI não foi simples. Até escolher o Front-end da Cognos, a Cyrela desenvolveu um questionário com 150 questões que foram preenchidas por dez diferentes empresas. Apenas três foram chamadas para realizar projeto piloto.
Resultado
Com o BI, a equipe das áreas selecionadas pode, fazer uso de informações georeferenciadas. o software é composto por mapas do Brasil inteiro, com dados precisos de latitude e longitude. Sabendo assim onde estão os empreendimentos, onde será bem-vindo um lançamento, se determinado padrão é bom para esta área, que tipo de carência existe. Também conseguimos saber sobre o tráfego da localidade, população, renda, oferta de transporte público. Com base em tudo isso é que desenvolvem seus produtos.
Dados relativos a finanças e recursos humanos são facilmente visualizados e cruzados para direcionar melhor as ações de negócio.
E a fim de tornar mais ágeis as tomadas de decisões, a empresa está caminhando para o acesso móvel via Blackberry.
www.brq.com
ANVISAProblema
Por ano, 12 milhões de pessoas são internadas nos hospitais do Sistema Único de Saúde (SUS). Ainda não estão em funcionamento um sistema que identifique quais foram os pacientes que foram a qual hospital, se precisaram ser reinternados, mas em outra unidade e assim por diante.
Solução Foram produzidos os primeiros relatórios a partir da ferramenta de business intelligence (BI) fornecida pela
MicroStrategy. Atualmente existem mais de 10 aplicações em áreas como a de arrecadação, de medicamentos, ouvidoria, produtos de saúde, recursos humanos e outras.
A cada cinco meses, aproximadamente, a TI consegue atender a um novo departamento, após passar por todo os processos de modelagem, avaliação, homologação e treinamento, seguindo metodologia própria.
Dificuldades enfrentadas
Integrar informações que vêm de diferentes fontes, como Ministério da Saúde, o IBGE e entre outras; Muitas informações são incompatíveis entre si. Como por exemplo, para criar grupos parecidos de diagnósticos, se
uma pessoa é internada por dor de cabeça e uma segunda vez porque quebrou o braço, não se pode incluir no mesmo grupo de informações;
Meta de atender a três tipos de público: o interno, o de outras áreas da saúde na esfera federal, e ao cidadão.
Resultado
Atuar de forma preventiva em duas frentes: a de mortalidade, para saber quantas pessoas saem com vida de um hospital, e a de reinternação, para descobrir ao longo do tempo se o mesmo paciente se internou mais de uma vez em diferentes instituições de saúde públicas. Assim, haverá um controle geral dos hospitais, o que vai ser útil em situações de epidemiologias, por exemplo.
Cerca de 2,5 mil pessoas têm acesso à produção de relatórios. Com o uso ampliado do BI, vai resultar em ainda mais controle, resposta rápida ao usuário, dados confiáveis e a
possibilidade de descobrir fraudes
www.brq.com
Vale S/AProblema
Para gerar seus KPIs, a empresa possuía uma estrutura complexa de bases distintas (DSS), onde sua origem de dados era um pool de queries do seu ERP Oracle de alta complexidade, geradas por uma equipe terceirizada para alimentar bases em MS Access e Planilhas Excel com codificação em VBA. Tornando assim, um ambiente extremamente caótico, pois não tem controle, e custoso tanto de recursos tecnológicos quanto humano.
Solução Como a empresa não tinha uma boa maturidade no conceitos de BI, o primeiro passo foi traduzir essas queries,
bases Access, planilhas Excels em uma arquitetura de BI estruturada com bases separadas por assunto, automatização de criação dos indicadores e analise das informações utilizando front end para criação de relatórios OLAP e de cubos.
Dificuldades Enfrentadas
Algumas informações tiveram de ser armazenadas como operacionais, conforme alinhada com o usuário Muita dificuldade no entendimento dos insumos do projeto (queries, bases Access, planilhas Excels). Pois não tinha
documentação e o usuário desconhecia certos conceitos. E conseqüentemente, a homologação foi bastante extensa.
Resultado
Retorno de investimento a curto prazo, devido ao corte dos recursos envolvidos na geração de queries e na manutenção dos insumos
Maior flexibilização na manipulação dos dados analíticos devido ao cubo oferecido pela ferramenta de front end. Atualização dos dados automatizada por meios de rotinas de ETL.
www.brq.com
Fim
Dúvidas???