Workshop Business Intelligence

www.brq.com

Hugo Ayres Cardoso Especialista em BI

Agenda
Conceitos Diferenas

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

Propsito de Business Intelligence

Converter o volume de dados em valor para o negcio atravs de relatrios analticos.
Deciso

Conhecimento

Informao

Dado

www.brq.com

Evoluo de BI

www.brq.com

Decision support systems (DSS)

Bases Dispersas

Usurios

www.brq.com

Decision support systems (DSS)

Desvantagens dessa abordagem

Relatrios desenvolvidos sob Problemas com Qualidade do demanda Dado no Processamento de Alto tempo de resposta Extrao Pouca capacidade de anlise Base de Tempo no comum Impacto de desempenho do Algoritmos de clculo ambiente de produo diferentes Baixa credibilidade nas Nveis de extrao informaes diferentes Baixa produtividade Nveis de granularidade Inabilidade de transformar diferentes dado em informao Nomes de campos diferentes Esforo Duplicado Significados de campos Mltiplas Tecnologias diferentes Relatrios Obsoletos Informao faltante Nenhum metadado Nenhuma regra de correo
www.brq.com

Data Warehousing e Business Intelligence

Sistemas Origens Staging Area
Apresentao

Ferramentas de Acesso

Legado

DW
Input Externo

Data Marts

ODS

Repositrio de Metadados
www.brq.com

Propriedades do Data Warehouse

A data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of managements decisions. W.H. Inmon
Dado categorizado e armazenado pelo Interesse ao Negcio em vez de ser pela aplicao simplesmente

Dado em determinada rea de interesse definido e armazenado somente uma vez

Tipicamente o dado num data warehouse no atualizado nem deletado

Dado armazenado numa srie de snapshots, cada um representando um perodo de tempo

www.brq.com

Alterando o Dado do Warehouse

Base de Dados Operacional Base de Dados Warehouse

Carga inicial

Atualizao

Atualizao

Expurgo ou Arquivamento

www.brq.com

Data Warehouse
Caractersticas Implementao em grande escala Abrange todo o negcio Dados de todas as reas Desenvolvido incrementalmente Fonte nica para o dado corporativo Dado corporativo sincronizado Ponto de distribuio nico para data marts

www.brq.com

Data Warehouse vs. Data Marts

Propriedade Escopo Data Warehouse Corporativo Data Mart Departamental

rea de Negcio
Origem Tempo de Implementao

Mltiplas
Vrias Mdio a Longo prazo

nica linha de Negcio

Poucas Curto a Mdio prazo

Data Mart Dependente

org1 DM Fin org2

Data Mart Independente

org1 DM Fin

org2

DW
org3

DM RH org3 DM CSC

DM RH

DM CSC org4

www.brq.com

org4

Data Warehouse
Staging Area
a rea de trabalho do data warehouse. o lugar onde se colocam os dados primrios, onde se limpa, combina, arquiva e, ao final, exportam esses dados para um ou mais data marts. O propsito da prea de data staging preparar os dados para carrega-los em um servidor de apresentao (um SGBD relacional ou software OLAP). Assumimos que a rea de data staging no um servio 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
ODS
Inmon Kimball

Uma estrutura hbrida projetada para apoiar tanto processamento operacional transacional quanto processamento analtico. Base de dados integrados, voltil, retrato instantneo do Negcio. Estrutura til para relaes de um-para-um entre o setor de marketing e cliente, e para reas onde apenas as transaes mais recentes so importantes.
www.brq.com

Depsito de dados histrico, frequentemente alimentado, de dados detalhados e integrados, constituindo-se no nvel atmico do ambiente de DW.

Data Warehouse
Metadados
dados sobre os dados Quaisquer informaes que permitam identificar, localizar, utilizar e entender os dados

Metadado Tcnico e Administrativo Altamente estruturado Informaes com definies, transformaes, gerncia e operao Geralmente tratvel via uma ferramenta de repositrio
Metadado de Negcio Tanto no-estruturado quanto estruturado Mais difcil de ser tratado e integrado por uma ferramenta altamente estruturada tipo um repositrio
www.brq.com

Data Warehouse
Outros Componentes de um Ambiente de DW
Repositrio de Metadados Ferramentas de Projeto CASE Ferramentas de Extrao, Transformao e Carga (ETL) Ferramentas para Qualidade e Limpeza Ferramentas para Replicao Provedores de Interfaces de BD ODBC/OLE Ferramentas de Gateway para BD Legados Bancos de Dados Relacionais Bancos de Dados No-Relacionais (Legados) Bancos de Dados Multidimensionais Ferramentas OLAP Ferramentas de Relatrio e Consulta Ferramentas de Data Mining Cross-Platform Batch Schedulers Ferramentas de Monitoramento e Controle Pacotes de Aplicao para Data Warehouse
www.brq.com

Data Warehouse
Modelo Dimensional
Dimenso
As dimenses identificam um indicador de anlise sobre um empreendimento, negcio ou ao feita. Atravs das dimenses possvel identificar quando (ms, ano), onde (estado, regio) e com quem (segurado, produto) ocorreu um indicador de anlise (prmio emitido). As dimenses relacionam-se atravs de hierarquias. Isto permite que um indicador, embora estando ligado a apenas uma dimenso da hierarquia, possa ser visto por todas as dimenses superiores a ela na hierarquia. Por exemplo, o indicador prmio pago identificado pela dimenso dia emisso. Como essa dimenso pertence hierarquia de tempo, o indicador tambm pode ser visto pelas dimenses ms emisso, trimestre emisso, semestre emisso e ano emisso. A chave primria de uma dimenso sempre uma chave substituta (surrogate key). Isso facilita a integrao de diferentes fontes de dados. Na carga da tabela de dimenso podem ser feitas operaes de insero (insert) e atualizao (update).

Fato
Um fato representa um indicador de anlise elementar. O indicador de anlise uma medio numrica que pode, por exemplo, representar medidas relacionadas ao negcio (ex.: valor do prmio emitido, valor do sinistro pago) ou quantificar uma caracterstica da transao (ex.: quantidade de propostas implantadas, quantidade de beneficirios). Utilizado para monitorar resultados, permitindo anlises gerenciais dos processos nas reas usurias da aplicao analtica. Os indicadores podem ser classificados como: Indicadores elementares no podem ser fracionados em outros valores. Os indicadores elementares que apresentam as mesmas caractersticas e que podem ser visualizados pelas mesmas dimenses so agrupados nas chamadas tabelas de fatos. Indicadores compostos so resultantes de clculos realizados com outros indicadores. Para cada indicador composto ser apresentada a sua frmula de clculo. (ex.: Taxa de Cancelamento de Proposta a razo entre o indicador Quantidade de Propostas Canceladas e o indicador Quantidade de Propostas Emitida). A chave primria da tabela de fatos composta das chaves primrias das dimenses que a qualifica. Na carga da tabela de fatos so feitas somente operaes de insero (insert).

www.brq.com

Data Warehouse
Modelo Dimensional Snowflake
As dimenses so normalizadas. Cada nvel da hierarquia implementada em uma tabela de dimenso.
Dim Ano Aviso Cod. ID Ano Ano de Aviso

Dim UF Segurado Cod. ID UF Segurado Nome UF

Dim Cidade Segurado Cod. ID Cidade Segurado Nome Cidade Cod ID UF Segurado

Dim Ms Aviso Cod. ID Ms Ms de Aviso

Dim Semana Aviso Cod. ID Semana Semana de Aviso

Dim Bairro Segurado Cod. ID Bairro Segurado Nome Bairro Cod ID Vidade Segurado Dim Segurado Cod. ID Segurado Cod. Segurado Nome Segurado Cod ID Bairro do Segurado Cod ID Sexo Cod ID Estado Civil

Dim Tempo Aviso Cod. ID Data de Aviso Dia de Aviso Cod. ID Ms Cod. ID Semana

Dim Sexo Cod. ID Sexo Desc Sexo

Fato Sinistro Cod. ID Data de Aviso Cod. ID Segurado Cod. ID Corretor Cod. ID Aviso Val Sinistro

Dim Corretor Cod. ID Corretor Cod. Corretor Nome Corretor Cod. ID Sucursal

Dim Sucursal Cod. ID Sucursal Cod. Sucursal Nome Sucursal

Dim Estado Civil Cod. ID Estado Civil Desc Estado Civil

Dim Aviso Sinistro Cod. ID Aviso Cod. Aviso Cod. ID Motivo

Dim Motivo Sinistro Cod. ID Motivo Cod Motivo Desc Motivo

www.brq.com

Data Warehouse
Modelo Dimensional Star
As dimenses so desnormalizadas. Uma hierarquia implementada em uma nica tabela, ou os nveis so associados diretamente tabela de fatos.
Dim Tempo Aviso Cod. ID Data de Aviso Dia de Aviso Semana de Aviso Ms de Aviso Ano de Aviso

Dim Segurado Cod. ID Segurado Cod. Segurado Nome Segurado Bairro do Segurado Cidade do Segurado UF do Segurado Desc Sexo Desc Estado Civil

Fato Sinistro Cod. ID Data de Aviso Cod. ID Data de Ocorrncia Cod. ID Segurado Cod. ID Corretor Cod. ID Aviso Val Sinistro

Dim Corretor Cod. ID Corretor Cod. Corretor Nome Corretor Cod. Sucursal Nome Sucursal

Fato Aviso Sinistro Cod. ID Aviso Cod. Aviso Cod. Motivo Desc Motivo

www.brq.com

Data Warehouse
Modelo Dimensional Starflake
um hbrido entre os modelos star e snowflake, aproveitando o melhor de cada um.
Dim Ano Aviso Cod. ID Ano Ano de Aviso

Dim Ms Aviso Cod. ID Ms Ms de Aviso

Dim Semana Aviso Cod. ID Semana Semana de Aviso

Dim Localizao Segurado Cod. ID Bairro Segurado Nome Bairro Nome Cidade Nome UF

Dim Tempo Aviso Cod. ID Data de Aviso Dia de Aviso Cod. ID Ms Cod. ID Semana

Dim Sexo Cod. ID Sexo Desc Sexo

Dim Segurado Cod. ID Segurado Cod. Segurado Nome Segurado Cod ID Localizao Segurado Cod ID Sexo Cod ID Estado Civil

Dim Sucursal Cod. ID Sucursal Cod. Sucursal Nome Sucursal

Fato Sinistro Cod. ID Data de Aviso Cod. ID Segurado Cod. ID Corretor Cod. ID Aviso Cod ID Sucursal Val Sinistro

Dim Corretor Cod. ID Corretor Cod. Corretor Nome Corretor

Dim Estado Civil Cod. ID Estado Civil Desc Estado Civil

Dim Aviso Sinistro Cod. ID Aviso Cod. Aviso Cod. ID Motivo

Dim Motivo Sinistro Cod. ID Motivo Cod Motivo Desc Motivo

www.brq.com

Data Warehouse
Conceito de Operaes Dimensionais de Seleo
Conceito Pontual
O valor pontual representa a interseo de valores (fatos) com relao aos eixos das dimenses. Por exemplo, o produto P na regio R no dia D vendeu a quantidade Q.

Conceito Slicing
Diz respeito a um plano de valores, com uma das dimenses fixa em um elemento. Por exemplo, o produto P na regio R no dia 25/09/2007 vendeu a quantidade Q.

www.brq.com

Data Warehouse
Conceito de Operaes Dimensionais de Seleo
Conceito Dicing
Diz respeito a um cubo de valores, com os elementos das dimenses sendo fixados em intervalos ou conjuntos. Por exemplo, o conjunto de produtos P1, P2 e P3 nas regioes R1 e R2 do incio do ms at hoje vendeu a quantidade Q.

Conceito Pivoting
Por esse conceito, a seleo pode sofre rotao em seus eixos (colunas viram linhas, linhas viram colunas).

www.brq.com

Data Warehouse
Conceito Drilling UP, Down e Across
Estes conceitos esto relacionados com a granularidade que se deseja nos relatrios. Os comando de drill up, down e across dizem respeito granularidade existente dentro de um nico datamart.
Ms Loja 2007 A 2007 B Valor da Venda R$ 5.250,00 R$ 3.300,00
Drill UP Subindo nvel de Hierarquia

Ms jan/07 jan/07 fev/07 fev/07

Loja A B A B

Valor da Venda R$ 1.500,00 R$ 500,00 R$ 3.750,00 R$ 2.800,00

Drill Down Descendo nvel de Hierarquia

Drill Across Mudana de Hierarquia

Ms

Produto jan/07 Nescau fev/07 Nescau

Valor da Venda R$ 200,00 R$ 300,00

Dia 01/01/2007 01/01/2007 02/02/2007 02/02/2007 03/02/2007 03/02/2007

Loja A B A B A B

Valor da Venda R$ 1.500,00 R$ 500,00 R$ 2.000,00 R$ 1.200,00 R$ 1.750,00 R$ 1.600,00

www.brq.com

Data Warehouse
Conceitos de ETL
Efetivos processos de ETL representam o fator de sucesso nmero um para seu projeto de data warehouse e podem absorver at 70% do tempo gasto num tpico projeto de data warehousing - DM Review, Maro de 2001 Para que os dados saiam de um modelo origem e migrem para um modelo dimensional, so necessrios 5 tratamentos diferentes (filtro, integrao, condensao, converso e derivao), divididos em 3 processos (extrao, transformao e carga). Filtro de Dados Relaciona os procedimento e condies para selecionar os dados desejveis no modelo dimensional. Por exemplo, selecionar apenas os segurados ativos. Integrao de Dados Define a forma de se correlacionar informaes existentes me fontes de dados distintas. Por exemplo: segurado de Automvel e segurado de Sade com informaes comuns (nome, endereo) e informes especficas a cada rea; Cdificao diferenciada em dimenses (sexo, estado civil e outras). Condensao de Dados Define a forma de reduzir o volume de dados visando obter informaes resumidas e sumariadas (agregaes). Converso de Dados Define os procedimentos para se transformar dados em unidades e formatos diferentes. Por exemplo, converso de datas, unidades monetrias, taxas. Derivao de Dados Define os meios e frmulas para se produzir dados virtuais, a partir de dados existentes, minimizando a complexidade de uma consulta ou aumentando a sua performance. Por exemplo, clculo de percentuais, participaes, mdias ponderadas, desvios padres.

www.brq.com

Data Warehouse
Processos de ETL
Extrao Executa o tratamento de Filtro de Dados.extraindo as informaes dos sistemas transacionais. Transformao Executa os tratamentos de Integrao de Dados, Condensao de Dados, Converso de Dados e Derivao de Dados. Carga Carrega na base dimensional os dados devidamente processados e integrados.

Sistemas Origens

Staging Area

Legado

Carga

DW

Input Externo

Transfor mao

Extrao

Data Marts

www.brq.com

Data Warehouse
Abordagem para construo de um DW
Atualmente muitas organizaes precisam se utilizar de grandes volumes de dados, armazenados ao longo do tempo, como fonte de anlise para apoiar a tomada de deciso. Isto possvel criando estruturas chamadas de data warehouse. Uma organizao precisa escolher qual o conjunto de ferramentas de desenho e manuteno destas estruturas que melhor se adaptaro suas necessidades. Nem todas so compatveis entre si ou apropriadas para todas as metodologias de desenvolvimento. As ferramentas e metodologias utilizadas geralmente esto 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 hbrido (utilizando abordagens, ferramentas ou metodologias de ambos os modelos), necessrio entender onde estes dois modelos so similares e onde eles diferem, e qual a arquitetura e metodologia bsica de cada um. Conhecendo as abordagens existentes, podemos identificar, para cada organizao, qual modelo melhor se ajusta s suas necessidades de negcio.

www.brq.com

Data Warehouse
Abordagem Bottom Up
A abordagem bottom up defendida por Ralph Kimball sugere a criao de data marts para cada processo de negcio. Ou seja, deve- se construir data marts orientados por assuntos para posteriormente integr-los e assim chegar ao data warehouse corporativo.
org1 DM Fin DM RH DM CSC

org2

DW

org3

org4 Modelagem

Data marts orientados por assuntos com pontos de conexo entre eles, que seriam as tabelas de fatos e dimenses em conformidade. Desta forma, informaes entre diferentes data marts poderiam ser geradas de maneira ntegra e segura. Kimball batizou esse conceito de Data Warehouse Bus Architecture

Segundo Kimball, o data warehouse deve utilizar a modelagem de dados dimensional. Na modelagem dimensional so criadas tabelas de fatos e tabelas de dimenses. As tabelas de fatos contm as mtricas e as tabelas de dimenses contm os atributos das mtricas.

As restries e filtros aos dados so realizadas nas tabelas dimensionais indexadas, e s ento as tabelas de fatos so atacadas, de uma s vez, a partir das chaves das tabelas dimensionais que satisfaam as restries.
A modelagem dimensional aproveita ao mximo os requisitos de um data warehouse. Tabelas de fatos associadas a dimenses altamente desnormalizadas resultam em data marts altamente acessveis aos usurios finais, alm de normalmente fornecer alto nvel de performance (tempo de resposta s consultas).

www.brq.com

Data Warehouse
Abordagem Bottom Up Concluso
Cada data mart baseado em um nico processo de negcio. Ralph Kimball argumenta que os data marts no podem ser departamentais, mas sim orientados aos dados ou a fontes dos dados. Assim, as informaes tratadas por um determinado assunto, em um data mart , podero ser acessados por todas as pessoas que precisam destas informaes, independente dos departamentos a que pertenam. A abordagem de Kimball recomenda construir um data mart por processo de negcio. A soma de todos os data marts o data warehouse da organizao. O data warehouse bus architecture defendida por Kimball assegura interoperabilidade entre os vrios data marts, pois exige que todos os data marts sejam modelados obedecendo a uma padronizao dos dados, atravs da criao de dimenses em conformidade. Kimball recomenda tambm 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 contm dados de mtricas e tabelas de dimenses que alteram aqueles dados. Ferramentas de modelagem dimensional podem ser amplamente usados por usurios finais com um mnimo de treinamento. Isto ajuda a garantir que os usurios finais estejam inteiramente envolvidos no desenvolvimento do data warehouse. Com a modelagem de dados dimensional os usurios podem esperar, a partir dos data marts gerados, facilidade no uso e bons tempos de respostas.

www.brq.com

Data Warehouse
Abordagem Top Down
A abordagem top-down defendida por Inmon sugere a construo de um data warehouse modelando-se toda a empresa, para se chegar a um nico modelo corporativo, partindo posteriormente para os data marts construdos por assuntos ou departamentais.
org1 org2 org3 org4 DM Fin

DW

DM RH DM CSC

Segundo Inmon, no se deve construir data marts antes do data warehouse. Data marts devem atender a requisitos proprietrios, departamentais. Sendo assim, para cada data mart, seriam delineadas regras especficas de negcios, bem como procedimentos especficos de extrao, transformao e carga dos dados oriundos dos sistemas transacionais. Ou seja, comeando pelo data mart a viso corporativa da empresa ficaria em segundo plano.

Raramente recomendvel 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 iteraes.

www.brq.com

Data Warehouse
Abordagem Top Down Concluso
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), definio dos itens de dados para cada entidade (DISs), e a conduo do projeto a partir de uma derivao da abordagem de desenvolvimento em espiral. Ou seja, os mtodos e as ferramentas de Inmon so adaptaes de mtodos 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 construo de data warehouses atmicos e data marts departamentais. A abordagem Inmon mais evolucionria do que revolucionria. Suas ferramentas e mtodos so direcionados aos profissionais de IT. Por conta disso, usurios finais tm uma participao menos ativa durante o processo de desenvolvimento. A ateno de Inmon para os aspectos tcnicos do processo de desenvolvimento do data warehouse aumentam as chances de uma soluo tcnica quase perfeita. Para os usurios finais, isto provavelmente significar timos tempos de respostas s suas consultas.

www.brq.com

Data Warehouse
Similaridades entre os modelos
As similaridades mais visveis entre os modelos de Inmon e Kimball esto no tratamento da informao de tempo, e nos processos de extrao, transformao e carga (ETL) dos dados, a partir dos sistemas transacionais. Embora existam pequenas diferenas conceituais, os resultados e os objetivos so muito similares.

Ralph Kimball
Kimball chama o atributo tempo de dimenso data A dimenso data possui uma chave de data, que uma chave artificial que define a dimenso em conformidade, e todos os atributos necessrios para representar a dimenso data Os dados depois de tratados devem ser carregados em uma srie de pequenos bancos de dados (data marts)

Bill Inmon
Inmon chama o atributo tempo de elemento de tempo Os atributos podem estar em vrias tabelas (modelo mais normalizado) ou at mesmo serem calculados em tempo de execuo (a escolha entre armazenar ou calcular deve ser guiadas por questes de performance) Os dados depois de tratados devem carregados diretamente no data warehouse ser

www.brq.com

Data Warehouse
Diferena entre os modelos Metodologia e Arquitetura
Bill Inmon Abordagem Top down Ralph Kimball Bottom up

Arquitetura

Data warehouses corporativos e atmicos, que alimentam os bancos de dados departamentais (data marts)
Muito complexo Derivao/adaptao da metodologia de desenvolvimento em espiral

Bancos de dados departamentais (data marts) que modelam um nico processo de negcio. A consistncia alcanada atravs do conceito de data warehouse bus architecture
Razoavelmente simples Processo em quatro etapas, derivada de metodologia RDBMS

Complexidade do mtodo Comparativo com as metodologias de desenvolvimento j existentes Discusso sobre desenho/modelo fsico

Razoavelmente completa

Razoavelmente simples

Na metodologia defendida por Inmon, o data warehouse atmico deve servir a toda a empresa, e os bancos de dados departamentais (data marts) devem obter seus dados a partir dele. O esfoo de desenvolvimento a partir de abordagens top down tm um grau maior de complexidade, e a metodologia de Inmon no exceo. Alm disso, a metodologia e a arquitetura de Inmon so orientadas para a rea tcnica. Seu principal interesse garantir que a soluo tcnica funcione. Em contraste, a metodologia em quatro etapas de Kimball muito acessvel aos usurios finais, que podem entender (moderadamente) os conceitos tcnicos do data warehouse bus architecture e dimenses em conformidade, sem ter que aprender a ler/interpretar os ERDs, e sem precisar estar familiarizados com todos os conceitos de um processo de negcios (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 fcil para os usurios entenderem.

www.brq.com

Data Warehouse
Diferena entre os modelos Modelagem de Dados
Bill Inmon Orientao aos dados Ferramentas Direcionado aos dados ou aos assuntos Tradicionais (ERD Diagramas de entidaderelacionamento, e DIS Conjuntos de itens dos dados) Baixa Ralph Kimball Orientado a processos Modelagem dimensional; uma adaptao da modelagem relacional Alta

Acessibilidade pelo usurio final

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 tambm que os membros de IT (equipe de data warehouse) tm a responsabilidade principal pela modelagem dos dados. E os usurios pouco podem contribuir com as revises e validaes dos ERDs ou DISs. Em contraste, Kimball segue a orientao por processos, que signifca que a modelagem torna-se uma tentativa de definir a interao dos dados atravs dos processos de negcio. Por sua natureza, tais processos de negcio 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 mtricas (fatos) e atributos (dimenses) so importantes e devem reclamar um lugar no data warehouse. Ferramentas de modelagem dimensional permitem aos usurios finais participarem ativamente do processo de modelagem de dados.

www.brq.com

Data Warehouse
Diferena entre os modelos Filosofia
Bill Inmon Pblico principal Lugar na organizao Profissionais de IT Parte integrante do Corporate Information Factory (CIF) Entregar uma soluo tcnica perfeita baseada em mtodos e tecnologias j provadas de desenvolvimento de bancos de dados Ralph Kimball Usurios finais Transformador e retentor dos dados operacionais

Objetivo

Entregar uma soluo que torna fcil para usurios finais consultar os dados diretamente e ainda obter razoveis 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 usurios finais e os profissionais de IT compartilhando deveres e obrigaes igualmente. Assegurando a participao ativa dos usurios finais por todo o processo de desenvolvimento, a probabilidade de aceitao do data warehouse muito maior. Ambos so cuidadosos ao afirmar que projetos de data warehouse que no envolvem usurios finais em todos os pontos de seu ciclo de vida, tm uma probabilidade muito grande de fracasso.

www.brq.com

Data Warehouse
Escolhendo a Melhor Abordagem
Para identificar qual abordagem melhor se ajusta s necessidades organizacionais, recomenda-se a avaliao de critrios que focam nas necessidades, no ambiente, na cultura e na expertise tcncia de uma organizao que planeja criar um data warehouse. Na tabela a seguir descrevemos as caractersticas bsicas relacionadas a oito destes critrios, apontando, para cada um deles, qual abordagem mais favorvel.

Caractersticas Natureza das requisies da tomada de deciso da organizao Requerimentos na integrao dos dados Estrutura dos dados

A favor de Ralph Kimball Ttico

A favor de Bill Inmon Estratgico

reas de negcios individuais Mtricas de negcio, mtricas de performance e scorecards Necessidades altamente volteis dentro de um escopo limitado Sistemas fontes esto relativamente estveis Pequenas equipes de generalistas Primeira aplicao data warehouse urgente Baixo custo de start-up, com cada projeto subseqente custando quase o mesmo

Integrao organizacional Dados que no sejam mtricas necessariamente, e dados que sero utilizados para mltiplas e variadas necessidades informacionais Crescimento do escopo e requisio de mudanas so crticos Alta taxa de mudanas dos sistemas fontes Grandes equipes de especialistas Os requerimentos da organizao permitem um tempo maior para visualizar os resultados Alto custo de start-up, com desenvolvimento de projetos subseqentes com custos menores

Escalabilidade Persistncia dos dados Requerimentos do Staffing e habilidades Tempo para entrega Custo para desenvolver

www.brq.com

Data Warehouse
Escolhendo a Melhor Abordagem Concluso
Os modelos de Inmon e Kimball so similares em alguns aspectos, tais como o registro e tratamento da informao tempo (embora existam algumas diferenas na forma em que cada modelo trata esta informao) e no processo de carga e tratamento dos dados a partir dos sistemas de origem (cada um enderea a carga para locais diferentes, mas o processo e o resultado so similares). Existem caractersticas nas organizaes que favorecem a adoo de um modelo em detrimento de outro. Algumas destas caractersticas incluem os requisitos de suporte a deciso da organizao, habilidades necessrias, tempo de entrega e custo para desenvolver. Analisar estas caractersticas podem auxiliar as organizaes a comear um processo de escolha da abordagem para desenvolver seus data warehouses. Outras pesquisas mostram que ter o conjunto certo de soft skills to importante, se no mais importante, do que habilidades tcnicas e conhecimento. A chave para o sucesso no est somente na natureza tcnica. Projetos no so bem sucedidos porque usam um modelo inovador ou tecnologias novas e radicais. Eles so bem sucedidos por conta da liderana, comunicao, planejamento e relacionamentos inter-pessoais. O grande desafio que projetos para desenvolvimento de data warehouse so relativamente novos em comparao com outros projetos de desenvolvimento. Por-isso, uma equipe que tenha um bom conhecimento dos modelos defendidos por Inmon e por Kimball ter melhores condies para articular e identificar uma viso do data warehouse que ir atender s necessidades e caractersticas da organizao, e aos objetivos para a tomada de deciso.

www.brq.com

Data Warehouse
Projeto de DW Diferencial dos Projetos de BI Desafios
Dificuldade de entendimento sobre a complexidade de projetos de natureza BI Necessidade de definio incremental de requisitos Desconhecimento de que estes projetos normalmente so iniciativas interdepartamentais, no podendo ser desenvolvidos setorizados de forma isolada Necessidade de patrocinadores com autoridade e engajamento Definio de estrutura e dinmica particular e adequada para uma equipe de projeto de BI Estabelecimento de uma metodologia de desenvolvimento especfica para este tipo de projeto Necessidade da atuao efetiva de analistas de negcio Definio e adoo de padres como requisito obrigatrio Forte impacto de eventuais inconsistncias e baixa qualidade dos dados fonte Entendimento da necessidade e do uso de metadados
www.brq.com

Data Warehouse
Projeto de DW Complexidade Fatores que determinam a complexidade Estabelecer claramente a diferena entre um projeto de BI e projetos tradicionais Entender a funo de cada um dos componentes especficos da infraestrutura de uma aplicao de BI Reconhecer quais so os fatores impactantes em um projeto de BI Determinar a quantidade e os tipos de recursos, tanto tcnicos como humanos Definir a arquitetura da aplicao, como o projeto de dados multidimensional ou consultas ad-hoc

www.brq.com

Data Warehouse
Projeto de DW Definio incremental dos requisitos
Avaliao da Verso da Aplicao Oportunidade de Negcio Apoio s Decises Estratgicas

A cada nova iterao no desenvolvimento da aplicao, os requisitos de informaes estratgicas so revistos e incrementados Motivo: Uma aplicao de BI orientada s oportunidades de negcio, fazendo do processo de desenvolvimento uma atividade dinmica e iterativa. Os dados e funcionalidades so disponibilizados em verses (releases) iterativas Cada nova verso inicia o processo de levantamento de novos requisitos para a prxima verso

Implantao

Plano de Projeto

Teste

Requisitos de Informaes Estratgicas

Implementao Projeto

Anlise do Negcio

www.brq.com

Data Warehouse
Projeto de DW Aplicaes BI x Transacionais Aplicaes Business Intelligence Direo/Orientao Implementao Requisitos Analises
www.brq.com

Transacionais
Necessidades do Negcio Apoio s atividades departamentais Funcionalidades Operacionais Sobre o sistema

Oportunidades de Negcio Apoio s decises estratgicas organizacionais Informaes Estratgicas Sobre o negcio (atividade mais importante)

Data Warehouse
Projeto de DW Escopo das Etapas de um Projeto de BI
Etapa do Desenvolvimento
Avaliao dos Casos de Negcio Avaliao da Infra-estrutura Corporativa Planejamento do Projeto Levantamento de Requisitos Anlise de Dados Prototipao da Aplicao de BI

Escopo Especfico do Projeto Inter-departamental

Anlise do Repositrio de Metadados

Projeto do Banco de Dados Projeto do ETL Projeto do Repositrio de Metadados Desenvolvimento da Aplicao de BI Desenvolvimento do ETL Desenvolvimento do Repositrio de Metadados Implantao

www.brq.com

Avaliao das Aplicaes

Data Warehouse
Projeto de DW
Equipe Central
Lder de Desenvolvimento da Aplicao Arquiteto de Infra-estrutura Representante do Negcio Administrador de Dados Expert em Data Mining Analista de Qualidade de dados Administrador de Banco de Dados Lder de Desenvolvimento de ETL Administrador de metadados Gerente de Projeto

Equipe Estendida
Desenvolvedor de Aplicao
Instrutor da equipe do negcio Desenvolvedor de ETL Auditor de TI ou Analista de Qualidade Desenvolvedor de repositrio de metadados Equipe de rede Equipe de operao (cargas e atualizaes de dados) Analista de segurana Stakeholders Arquiteto de Informao Equipe de apoio de TI Testadores Administradores de Ferramentas

www.brq.com

Desenvolvedores Web

Data Warehouse
Projeto de DW Fases e atividades do Desenvolvimento de Solues de BI
Justificativa Avaliao dos Casos de Negcio

Implantao Produo Avaliao da Aplicaes

Planejamento Avaliao da Infraestrutura Corporativa Planejamento do Projeto

Implementao Desenvolvimento do ETL Desenvolvimento da Aplicao Data Mining Desenvolvimento do Repositrio de Metadados

Anlise do Negcio Levantamento de Requisitos Anlise de Dados Prototipao da Aplicao de BI Anlise do Repositrio de Metadados

www.brq.com

Projeto Projeto do Banco de Dados do ETL Projeto do Repositrio de Metadados Projeto da aplicao analitica

Diferenas

www.brq.com

Sistemas Transacionais x Analticos

OLTP - On-Line Transaction Processing Orientao do Dados
Orientado por Aplicao Diferentes sistemas armazenam diferentes tipos de dados Construo orientada a processo

OLAP - On-Line Analytical Processing

Orientado por dimenso Todos os tipos de dados so integrados em um sistema Construo orientada a objetivos

Integrao do Dados
Geralmente no integrados Diferentes estruturas de chaves Diferentes convenes de nomes Diferentes formatos de arquivos Diferentes plataformas de hardware Devem ser integrados Estruturas de chaves padronizadas Conveno de nomes padronizados Formatos de arquivos padronizados Servidor de warehouse nico (servidor lgico)

Histrico do Dados
Somente valores atuais, geralmente 60-90 dias de dados No existe a chave Tempo No existem anlises ao longo do tempo Fonte de acesso primria Posies histricas, armazenamento superior a 2 anos Existe a chave Tempo Existem anlises ao longo do tempo Fonte de acesso secundria

Acesso e Manipulao do Dados

Incluso, Alterao, Excluso e Seleo Atualizao on-line registro a registro Acesso e atualizao de dados Pequeno volume de dados envolvido em cada transao RDBMS (tratamento de lock, concorrncia, leitura de registro) Apenas seleo (leitura) Atualizao via carga de dados (em blocos) Acesso e anlise de informaes Grande volume de dados envolvido em cada consulta RDBMS (tratamento de join, carga paralela, leitura de bloco)

www.brq.com

Sistemas Transacionais x Analticos

Uso de CPU Operacional Analtico

www.brq.com

Vantagens

www.brq.com

Vantagens dos Ambientes de Processamento de Warehouse

Controlado e Confivel Qualidade da informao nica origem dos dados Nenhum esforo duplicado Nenhuma necessidade de ferramentas para suportar vrias tecnologias Nenhuma disparidade nos dados, no significado, ou na representao Nenhum conflito de perodo de tempo Nenhuma confuso de algoritmo Nenhuma restrio a drill-down O ROI garantido a mdio e longo prazo, pois a criao dos relatrios automatizada.

www.brq.com

Fatores de Sucesso para Ambiente Dinmico de Negcio

Conhecer o negcio Reinventar frente a novos desafios Investir em produtos Investir em clientes Reter clientes Investir em tecnologia Ser lucrativo Fornecer servios e produtos superiores Melhorar acesso s informaes de negcio

www.brq.com

Drivers do Negcio para Data Warehouses

Fornecer sistemas de informao que suportam o negcio Obter informaes de Qualidade Reduzir custos Conduzir o negcio Melhorar margens

www.brq.com

Cases

www.brq.com

Toyota Motor Sales USA

Problema
A gerncia da TLS exige rastreamento preciso e gerenciamento da cadeia de fornecimento para assegurar que os carros certos vo para os revendedores certos a tempo. O agendamento manual e outros processos relacionados com negcios que forma conduzidos com informaes 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 gerncia que os navios nunca chegaram a um porto, semanas aps os navios chegarem seguramente ao estaleiro.)

Soluo
Usando um Data Warehouse da Oracle e a plataforma do Business Intelligence da Hyperion, foi criado um novo sistema. O sistema tambm inclua o recurso de Dashboard da Hyperion, que permite que os executivos vejam as reas que merecem ateno em suas unidades de negcio e investiguem mais para identificar os problemas com exatido, bem como as suas causas. Usando cores diferentes (por exemplo, o vermelho para perigo), um gerente de negcios pode ver em tempo real, por exemplo, quando os tempos de entrega esto se tornando vagarosos e encontrar imediatamente as fontes do problema e at mesmo avaliar solues potenciais do tipo e se.

Resultado
Dentro de poucos dias, o sistema comeu 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 nmero de funcionrios em apenas 3%; Um estudo independente realizado pela IDC Inc. acerca da justificao do gerenciamento de desempenho de negcios e sistemas de BI indica que a Toyota alcanou um retorno de 506% sobre o investimento em BI. (O retorno de investimento mdio para as 43 outras empresas citadas pela Fortune 500, que participaram do estudo, foi de 112%)

www.brq.com

RJZ Cyrela
Problema
As reas de inteligncia de mercado, comercial e terrenos so as mais crticas da empresa, pois elas que fazem a pesquisa para detectar a demanda dos clientes, os terrenos disponveis das cidades e as estratgias de venda.

Soluo
As trs reas para quem a soluo serviria diretamente inteligncia de mercado, comercial e terrenos participaram ativamente, inclusive com funcionrios testando passo-a-passo cada ferramenta. O envolvimento dos usurios chaves foi essencial para o sucesso da implantao. Foram dois ou trs funcionrios de cada rea trabalhando diretamente com TI.

Dificuldades Enfrentadas
O processo para definir o fornecedor de BI no foi simples. At escolher o Front-end da Cognos, a Cyrela desenvolveu um questionrio com 150 questes que foram preenchidas por dez diferentes empresas. Apenas trs foram chamadas para realizar projeto piloto.

Resultado
Com o BI, a equipe das reas selecionadas pode, fazer uso de informaes georeferenciadas. o software composto por mapas do Brasil inteiro, com dados precisos de latitude e longitude. Sabendo assim onde esto os empreendimentos, onde ser bem-vindo um lanamento, se determinado padro bom para esta rea, que tipo de carncia existe. Tambm conseguimos saber sobre o trfego da localidade, populao, renda, oferta de transporte pblico. Com base em tudo isso que desenvolvem seus produtos. Dados relativos a finanas e recursos humanos so facilmente visualizados e cruzados para direcionar melhor as aes de negcio. E a fim de tornar mais geis as tomadas de decises, a empresa est caminhando para o acesso mvel via Blackberry.

www.brq.com

ANVISA
Problema
Por ano, 12 milhes de pessoas so internadas nos hospitais do Sistema nico de Sade (SUS). Ainda no esto 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.

Soluo
Foram produzidos os primeiros relatrios a partir da ferramenta de business intelligence (BI) fornecida pela MicroStrategy. Atualmente existem mais de 10 aplicaes em reas como a de arrecadao, de medicamentos, ouvidoria, produtos de sade, recursos humanos e outras. A cada cinco meses, aproximadamente, a TI consegue atender a um novo departamento, aps passar por todo os processos de modelagem, avaliao, homologao e treinamento, seguindo metodologia prpria.

Dificuldades enfrentadas
Integrar informaes que vm de diferentes fontes, como Ministrio da Sade, o IBGE e entre outras; Muitas informaes so incompatveis entre si. Como por exemplo, para criar grupos parecidos de diagnsticos, se uma pessoa internada por dor de cabea e uma segunda vez porque quebrou o brao, no se pode incluir no mesmo grupo de informaes; Meta de atender a trs tipos de pblico: o interno, o de outras reas da sade na esfera federal, e ao cidado.

Resultado
Atuar de forma preventiva em duas frentes: a de mortalidade, para saber quantas pessoas saem com vida de um hospital, e a de reinternao, para descobrir ao longo do tempo se o mesmo paciente se internou mais de uma vez em diferentes instituies de sade pblicas. Assim, haver um controle geral dos hospitais, o que vai ser til em situaes de epidemiologias, por exemplo. Cerca de 2,5 mil pessoas tm acesso produo de relatrios. Com o uso ampliado do BI, vai resultar em ainda mais controle, resposta rpida ao usurio, dados confiveis e a possibilidade de descobrir fraudes www.brq.com

Vale S/A
Problema
Para gerar seus KPIs, a empresa possua 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 codificao em VBA. Tornando assim, um ambiente extremamente catico, pois no tem controle, e custoso tanto de recursos tecnolgicos quanto humano.

Soluo
Como a empresa no 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, automatizao de criao dos indicadores e analise das informaes utilizando front end para criao de relatrios OLAP e de cubos.

Dificuldades Enfrentadas
Algumas informaes tiveram de ser armazenadas como operacionais, conforme alinhada com o usurio Muita dificuldade no entendimento dos insumos do projeto (queries, bases Access, planilhas Excels). Pois no tinha documentao e o usurio desconhecia certos conceitos. E conseqentemente, a homologao foi bastante extensa.

Resultado
Retorno de investimento a curto prazo, devido ao corte dos recursos envolvidos na gerao de queries e na manuteno dos insumos Maior flexibilizao na manipulao dos dados analticos devido ao cubo oferecido pela ferramenta de front end. Atualizao dos dados automatizada por meios de rotinas de ETL.

www.brq.com

Fim Dvidas???

www.brq.com