Metodologia para Implantação de Data Warehouse

METODOLOGIA PARA IMPLEMENTAÇÃO DE PROJETOS DE DATA WAREHOUSE

Autor: Felipe Ferreira E-mail: [email protected] [email protected] Rio de Janeiro, 6 de dezembro de 2004

Trusted by over 1 million members

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.













ii

RESUMO Motivado pelo interesse nas diversas tecnologias e ferramentas de apoio à decisão, este trabalho foi desenvolvido com o objetivo de organizar uma metodologia eficiente no desenvolvimento evolutivo de data warehouse, baseado nos conceitos e técnicas existentes. Implementar um data warehouse está longe de ser uma tarefa fácil, mesmo considerando o desenvolvimento por assuntos (Data Marts). Faz-se necessária uma atenção especial para o método de desenvolvimento. Este trabalho apresenta as fases do projeto de implementação do data warehouse: levantamento, modelagem, extração, modelagem multidimensional, análise de resultados, visões pré-definidas e segurança.















iii

SUMÁRIO Resumo

ii

1.

Introdução

1

2. 3.

Tecnologias Infra-estrutura

3 5

4.

Metodologia 4.1. Levantamento 4.2. 4.3. 4.4. 4.5. 4.6.

Modelagem Extração Extração de dados Modelagem Modelagem Multidimensional Multidimensional Análise de Resultados Visões Pré-definidas

9 9 11 14 17 19 20

4.7. Segurança da Informação Informaçã o 6. Estudo de Caso 7. Conclusão Conclusão 8. Lista de Abreviações e Siglas

21 24 27 28

9.

29

Referências Bibliográficas Bibliográ ficas















1. INTRODUÇÃO Com o advento da computação, surgiram os primeiros programas para transformação de dados em informação. Junto vieram alguns complicadores, como: tempo de processamento, volume de dados, formas de acesso, meios físicos etc. As tecnologias evoluíram, porém o conceito permanece. Transformar dados em informação é a principal razão da existência da informática. Os primeiros programas comerciais foram criados para auxiliar os processos organizacionais, tais como folhas de pagamento, contabilização e controles de estoque. Apesar da evolução das tecnologias estes aplicativos ainda são tão essenciais quanto os sistemas especialistas. Com o passar do tempo muitos aplicativos foram desenvolvidos para automatizar os processos. Como conseqüência o volume de dados crescia ainda mais, dificultando a obtenção de informações para análise e tomada de decisão. Na década de 80 surgiram os primeiros sistemas comerciais para auxílio à tomada de decisão. Tinham como objetivo resumir os dados essências e organizá-los. O crescente volume e a complexidade para obter os dados, de diferentes fontes, tornaram estes aplicativos ineficientes à medida que não disponibilizavam as informações necessárias para tomada de decisão em tempo hábil. Observa-se que não importa ter apenas os dados se a informação não está disponibilizada em momentos decisivos. Surgiram na década seguinte os sistemas integrados (ERP) que agilizaram processos, otimizando recursos. Como promessa destes mega-sistemas, todas as informações necessárias seriam obtidas a partir deles. Porém, outros sistemas especialistas ainda permaneciam por serem estratégicos e mais eficientes. Permanecia também o problema da disponibilização da informação no momento certo. A concorrência de transações da operação das empresas com busca de informações em altos volumes de dados começaram a comprometer o ambiente. Ficando bem caracterizado a que se destinavam os sistemas integrados: otimizar as transações das empresas. A evolução das tecnologias de busca de informação para tomada de decisão e a















2 não volátil e variável em relação ao tempo, de apoio às decisões”. (1997, pág 33) Ele demonstra em sua obra as principais técnicas para construção de um data warehouse. A integração dos dados, associadas a técnicas e ferramentas, no data warehouse proporcionam um ambiente de dados organizados por assuntos para obtenção de informações para tomada de decisão. Imagina-se então que o DW seja um ambiente onde todas as informações, para tomada de decisão, são obtidas. Construir um DW está longe de ser uma tarefa fácil. As técnicas e as ferramentas não são suficientes para garantir o êxito na construção. É necessária uma metodologia capaz de levar à sua implementação. INMON acrescenta que “ a tentativa de aplicar ferramentas e técnicas de desenvolvimento inadequadas conduz apenas a desperdício e confusão. Por exemplo, no mundo CASE predomina a análise baseada em requisitos. Tentar aplicar as ferramentas e técnicas CASE ao mundo do Data warehouse não é aconselhável e vice-versa ”. (1997, pág 24) No ciclo de vida do DW predominam os dados e a informação resultante da organização da base de dados. Mesmo considerando seu desenvolvimento em partes (Data Marts) deve-se ter a visão do todo para garantir a integração das informações. O armazém de dados (DW) não pode ser apenas um repositório, onde os dados de diferentes aplicações estão na mesma base de dados centralizada. Os dados devem estar organizados para refletir a visão do negócio de forma integrada. A metodologia descrita a seguir tem como objetivo uma orientação para desenvolvimento evolutivo do data warehouse. Dividida em fases bem caracterizadas pelo agrupamento das principais técnicas relacionadas. Ela descreve a finalidade de cada fase, identificando os pontos críticos e descrevendo sucintamente as principais técnicas. As fases do projeto de implementação do data warehouse, por assunto, são: levantamento de dados, modelagem de dados, extração de dados, modelagem multidimensional, análise de resultados, visões pré-definidas e segurança da informação. Além da descrição das fases do projeto também são abordadas neste trabalho as tecnologias relacionadas ao data warehouse, a infra-estrutura necessária e















3

2. TECNOLOGIAS Em parte o data warehouse é a evolução de algumas tecnologias. Outras que surgiram em paralelo ao conceito de DW também evoluíram e possuem grandes benefícios se estiverem integradas. Também existe um grupo de tecnologias mais recente que foram influenciadas pela deficiência ou amadurecimento do conceito. A seguir são definidas algumas das técnicas e ferramentas relacionadas com o data warehouse. Os Sistemas de Informações Gerenciais (SIGs) foram uma das primeiras tentativas de criação de um ambiente único de informações para tomada de decisão. Eles foram desenvolvidos para disponibilizar relatórios que atendessem ao corpo gerencial das organizações. Porém, estes sistemas ainda não utilizavam técnicas de organização de dados específicas que suportassem um ambiente com crescimento escalar. Como evolução dos SIGs os Executive Information Systems (EIS) foram desenvolvidos para melhorar a interface com os executivos e solucionar alguns problemas de performance. De acordo com INMON “por meio dos EIS o analista executivo pode localizar problemas com precisão e detectar tendências que são de vital importância para a gerência ”.(1997, pág 237) Estes sistemas também eram suportados pela tecnologia OLAP. A tecnologia OLAP (On-Line Analytical Process) constitui um sistema de armazenamento de dados agregados. Determinadas informações são obtidas a partir de dados pré-calculados disponíveis para consulta direta, sem a necessidade da pesquisa dos dados elementares e consolidação em tempo de execução, otimizando assim o processo de consulta de dados. Estes sistemas também são conhecidos como multidimensionais ou cubos, por permitirem a consulta de informações por múltiplas visões. O armazém de dados (DW), em si, é suportado por um Sistema Gerenciador de Banco de Dados (SGBD), onde os dados extraídos dos sistemas transacionais são armazenados. O DW também utiliza a tecnologia OLAP para permitir as consultas

















4 É importante contextualizar algumas tecnologias que são influenciadas ou dependentes do DW para preparação de um ambiente que suporte de forma eficaz tais tecnologias. Atualmente os EISs, associados com o data warehouse, podem ser considerados como sistemas de BI (Business Intelligence). Outras tecnologias como Data Mining também influenciam o BI, na descoberta de conhecimento. Obter informação de uma grande base de informações (DW) pode se tornar uma tarefa difícil, mesmo que organizada por assuntos. Explorar as informações, por meio de ferramentas analíticas, pode não ser eficaz quando não se tem a certeza do que se está procurando. A tecnologia de Data Mining, com seus algoritmos e técnicas pode ser facilitada se existir uma fonte de dados organizada. CARVALHO relata que “ em uma empresa que deseja analisar o conteúdo da massa de dados criada por suas atividades, um processo de unificação precisa ser efetuado de forma a possibilitar o acesso de um indivíduo (analista) às múltiplas faces desta informação. Para que o data mining seja realizado, é necessário o acesso a uma massa de dados limpa, consistente e unificada em sua linguagem e lógica. Certamente que analistas vêm realizando data mining há muitos anos, utilizando ferramentas simples e bancos de dados separados, porém a construção de um data warehouse em muito facilita o processo de mineração de dados e de decisão”. (2001, pág 193) SWIFT define que “CRM é totalmente dependente de um local centralizado de

dados detalhados sobre clientes, seus comportamentos e suas preferências, incluindo detalhes específicos sobre privacidade de dados: o data warehouse ”. (2001, pág 65) Analisar as informações contidas no data warehouse, com crescente volume de dados, pode não ser eficiente com relatórios, books, gráficos etc. São muitas















5 Management (EPM), que definem as metas dos indicadores. indicadores . Estes sistemas, muitas vezes, utilizam o histórico dos indicadores como fonte para cálculo das metas. Fica evidente assim que a construção do data warehouse deve levar em consideração como as informações serão utilizadas e integradas a outros sistemas e processos das instituições. A metodologia de implementação de data warehouse, por assuntos, é descrita neste trabalho pelas fases de: Definição da infra-estrutura Levantamento de dados Modelagem de dados Extração Extração de dados Modelagem multidimensional Análise de resultados Visões pré-definidas Segurança da informação Administração

3. INFRA-ESTRUTURA A infra-estrutura deverá suportar o ambiente projetado, com alto crescimento de dados, consultas complexas e não previstas (ad-hoc), diversidade de integração, diferentes tipos de tecnologias etc. O produto final do DW serão os dados, organizados















6 armazenados. Ele deverá suportar: grandes volumes de dados, alta performance para carga de dados e consulta de informações, flexibilidade para alteração de estruturas, fácil administração e operação, baixo custo por usuário, integração com diferentes plataformas e sistemas, etc. Devem-se evitar utilizar características que dificultem a migração para outra plataforma. Em longo prazo, por questões de custo, pode ser necessária uma mudança de plataforma. Com tanta integração e a utilização do DW por toda organização o custo de licença de uso, por usuário, deve ser considerado desde o início como um fator crítico. Sendo os dados o mais importante, a estrutura de organização dos dados deve ser muito bem conhecida, documentada e de fácil acesso. Para suportar consultas complexas e não previstas (ad-hoc) é necessário que tanto dados detalhados quanto totalizadores, fórmulas e conjuntos de dados possam ser consultados com o menor tempo de resposta possível. A infra-estrutura do data warehouse deve possuir uma ferramenta que suporte este tipo de consulta. As ferramentas OLAP possuem tais características, simplificando assim o trabalho de agregação e visualização das informações. THOMSEN define que “ os

conceitos de OLAP incluem a noção ou idéia de

múltiplas dimensões hierárquicas e podem ser usados por qualquer um para que se pense mais claramente a respeito do mundo, seja o mundo material da escala atômica à escala galáctica, o mundo econômico dos micros agentes à macro economias, ou o mundo social dos relacionamentos interpessoais aos internacionais. Em outras palavras, mesmo sem qualquer tipo de linguagem formal, é útil apenas sermos capazes de pensar em termos de um mundo multidimensional e com múltiplos níveis, independentes da sua posição na vida”. “Outras linguagens for mais, mais,

incluindo Data Definition Language (DDL), Data















7 “Produtos OLAP completos, que precisam incluir um

compilador e métodos de

armazenamento e acesso, são otimizados para acesso a dados e cálculos rápidos, sendo usados para a modelagem descritiva de dados, derivada de sistemas de suporte à tomada de decisão (DSS – Decision Support Systems). A fronteira entre linguagens e produtos OLAP não é demarcada com clareza ”.(2002, pág 5) Resumidamente, as ferramentas OLAP fazem parte da infra-estrutura do Data Warehouse para consolidação de dados (agregação), aplicação de regras de negócio, cálculos (fórmulas) e disponibilizar a visão multidimensional. Para obter os dados do ambiente operacional para o data warehouse, podem ser utilizadas várias linguagens, formas de acesso, conectores de dados e meios físicos diferentes (discos, fitas, rede etc). Segundo INMON, “à primeira vista, quando os dados são movidos do ambiente herdado para o ambiente do data warehouse, parece que nada além de simples extrações de dados de um local para o próximo está ocorrendo. Em virtude dessa enganosa simplicidade, muitas empresas começaram a construir seus data warehouses manualmente. O programador olha para a movimentação de dados do antigo ambiente operacional para o novo data warehouse e declara: “Eu posso fazer isso”!

Munido de lápis e formulário de codificação, nos três primeiros minutos do

projeto e desenvolvimento do data warehouse, o programador ansiosamente mergulha na criação do código”. “Contudo, primeiras impressões podem ser muito

enganadoras. O que em um

primeiro momento parece ser nada mais do que a movimentação de dados de um local para outro transforma-se, rapidamente, em uma grande e complexa tarefa – muito maior e mais complexa do que o programador negociou ”.(1997, pág 115) Como veremos adiante, em detalhes, no tópico de extração de dados, são















8 a integração e operacionalização. Considerando que a fase de extração pode consumir cerca de 70% do tempo de desenvolvimento do projeto. Abrir mão de uma ferramenta de ETL pode ser um grande risco para o projeto e comprometê-lo. Investir numa ferramenta, que garanta a integração e atenda aos requisitos da extração de dados, é no mínimo aconselhável. Além disso, usualmente os fornecedores não cobram por conectores ou pontos de integração e sim como um pacote, portanto investir mais nestas ferramentas não irá aumentar os custos à medida que o data warehouse se expandir. Para que a arquitetura do data warehouse esteja completa é necessário uma última camada. A consulta, análise e visualização das informações compõem esta camada. Apesar dos bancos de dados possuírem formas de acesso e as ferramentas OLAP visões multidimensionais, é necessário que os usuários possam acessar as informações de forma integrada ao seu ambiente de trabalho. Como requisito mínimo para a arquitetura do data warehouse deve-se considerar uma ferramenta que acesse os dados armazenados e de forma exploratória possam analisar os dados. Outra forma de acesso, de forma orientada, são os portais de informação, que são constituídos por visões pré-definidas, consultas e relatórios pré-formatados. Nas quatro camadas descritas acima (armazenamento, extração, consolidação e análise) devemos considerar o alto volume de dados, múltiplos acessos simultâneos e alta disponibilidade. Esta preocupação garantirá a escalabilidade do ambiente do data warehouse. Outro fator muito importante está na flexibilidade que o ambiente deve possuir para atender as constantes mudanças de visão do negócio. Uma empresa que opera com apenas um produto pode passar a comercializar outros, assim como uma empresa pode se tornar uma grande organização composta por diferentes unidades de negócio. Não é

















9 funciona. Você pode otimizar sua máquina para o processamento operacional ou pode otimizar sua máquina para o processamento do data warehouse, mas não é possível ter ambas as situações ao mesmo tempo e no mesmo equipamento”. (1997, pág 25)

Esta característica de utilização determina que o ambiente deve ser completamente separado do operacional, sendo assim, todos os equipamentos devem ser separados, sem nenhum tipo de compartilhamento. Isto nos leva a crer que a utilização de rede também terá algum impacto e deve ser levada em consideração na arquitetura. O armazenamento de dados em discos externos também não deve ser compartilhado. Considerando que os dados são históricos e não voláteis no data warehouse, podemos chegar à conclusão que as contingências podem ser reduzidas, ou seja, sem redundância de disco por exemplo. Porém, a disponibilidade do DW para tomada de decisão tende a aumentar e correr o risco de não ter a informação em tempo hábil não é compatível com este ambiente.

4. METODOLOGIA 4.1. LEVANTAMENTO Sendo o data warehouse um grande repositório de dados e possuindo como origem os dados dos sistemas transacionais, podemos concluir que a principal análise















10 A principal abordagem para construção do DW é pela implementação de Data Marts, que são assuntos específicos das áreas das empresas. Os Data Marts têm sua origem na construção de cubos, pela utilização da tecnologia OLAP. Esta abordagem é considerada por alguns autores como ineficiente por não considerar a integração com outras bases de dados dentro do data warehouse. Outra característica dos Data Marts, a ser considerada, é a implementação em partes para se chegar ao todo (Bottom-Up). Mesmo considerando a construção do DW por partes, alguns Data Marts podem ser muito complexos. Os Data Marts podem ter como origem mais de uma base de dados e cada uma com dezenas ou centenas de tabelas. Como orientação para o trabalho de levantamento de dados outras fontes devem ser analisadas. Analisando as principais questões, referentes ao assunto, pode-se observar que existirá a carência por algum tipo de informação específica ou que a informação atual não é confiável, conflitante com dados de outra área da empresa ou fora do tempo para tomada de decisão. Desta forma são identificados problemas analíticos que não são solucionados pelos sistemas transacionais, como exemplo a análise de comportamento dos clientes ao longo do tempo. Caso o sistema transacional tente solucionar este tipo de questão ele pode se tornar ineficaz para as transações ou gerar a informação fora do tempo.















11 A análise das bases de dados dos sistemas transacionais pode ser iniciada pela pesquisa das tabelas com maior volume de dados. Estas tabelas normalmente são referentes a eventos ou fatos que ocorrem com freqüência, indicados por campos de data ou período. Comumente estas tabelas são definidas como ordens, itens, detalhamento etc. Os atributos destas tabelas são compostos, em grande parte, por chaves estrangeiras (foreign key) e indicadores. Os indicadores são dados quantitativos, monetários, taxas e medidas. As tabelas relacionadas com a tabela de eventos (ou fatos) podem dar origem às dimensões, que são as diferentes visões que se poderá ter do assunto. Após a análise das bases de dados, dos relatórios e reuniões de levantamento deve ser produzida uma especificação com a definição do assunto, os objetivos da análise do assunto, as principais questões, a definição das regras de negócio, os indicadores, as múltiplas visões do assunto, o mapeamento dos dados das bases de origem e a periodicidade para extração dos dados. O mapeamento dos dados deve ser bastante detalhado para facilitar o trabalho na fase de extração de dados. Neste mapeamento de dados devem ser indicados as bases de dados, arquivos, tabelas, campos, atributos, formatos etc. Esta especificação será utilizada durante todo o projeto do Data Mart como orientação para que os objetivos sejam atingidos.















12 N para N, ou seja, um fato não pode estar relacionado com mais de um elemento de uma tabela de dimensão. Os elementos das tabelas de dimensão estarão relacionados com vários itens da tabela de fatos, caracterizando assim a necessidade de agregação. A desnormalização de dados no data warehouse é aceita e em muitos casos indicada para solucionar problemas de performance e espaço em disco, combinando dados de várias tabelas do modelo de dados dos sistemas transacionais em uma tabela de fatos ou dimensão. INMON “É interessante observar que, no data warehouse, essas circunstâncias ocorrem regularmente em função de os dados serem baseados em parâmetros de tempo. Os dados do data warehouse sempre apresentam relevância em relação a um determinado momento, e unidades de tempo ocorrem com grande regularidade. Em um data warehouse, a criação de um array por mês, por exemplo, é algo muito natural. Outra importante técnica de projeto especialmente relevante para o ambiente de data warehouse consiste na introdução intencional de dados redundantes”.(1997 , pág 100) Contudo, algumas ferramentas de mercado estão cada vez mais adaptadas aos conceitos de data warehouse. Tirando grande proveito do ambiente relacional, sem perder o conceito, para construir bases multidimensionais (OLAP) com maior eficiência. Sendo assim, não devemos abrir mão da desnormalização para tudo, mas sempre que necessário.















13 e identificados com uma marca de tempo, onde poderemos observar as mudanças de comportamento, seja de clientes ou produtos. Algumas dimensões no data warehouse devem ser observadas com mais atenção, pois possuem grande relevância para a integração dos dados. Quando importamos os fatos dos sistemas transacionais para o DW observamos sempre que possuem o atributo de tempo. Portanto, a dimensão de tempo terá grande importância para o modelo de dados do data warehouse. Outra característica importante é podermos definir atributos comuns para os fatos, através do tempo, como: feriados, acontecimento importante (externos ou internos da organização), dia da semana etc. Fatos diferentes podem dar origem à outra dimensão que deve ser observada com atenção. A relação de fatos realizados com previstos ou calculados é o conceito de versão, que é representado usualmente nos data warehouses como uma dimensão de versão. Mais recentemente, com a evolução dos conceitos de marketing, e mais especificamente do marketing de relacionamento, o cliente tem ganhado maior atenção dos analistas de data warehouse, com o intuito de atender as necessidades dos sistemas de CRM (Customer Relationship Management). Modelar os dados dos clientes de forma que seja possível observar as mudanças do mesmo, ao longo do tempo, é fundamental

















14 dados e no acesso a eles bem como pela possibilidade de analisar dados em maior detalhe. (Em outras palavras, a organização quer fazer o gol e defender ao mesmo tempo!) Quando uma organização possui grandes quantidades de dados no data warehouse, faz sentido pensar em dois (ou mais) níveis de granularidade na parte detalhada do data warehouse”.

(1997, pág 49) Deve ser observado que, efetuando este

tipo de modelagem, alguma informação será perdida ao longo do tempo. Outro aspecto a ser considerado no modelo físico é o particionamento dos dados. O particionamento permitirá o gerenciamento flexível dos dados e a distribuição de bases de dados por unidades de negócio de forma descentralizada. Resumidamente o modelo de dados do data warehouse refletirá a organização dos fatos e dimensões na base de dados.

4.3. EXTRAÇÃO DE DADOS















15 ferramentas de ETL (Extract Transform and Load) são de suma importância para a integração dos ambientes transacionais e o data warehouse. Com base na especificação definida no levantamento de dados serão produzidas novas especificações de desenvolvimento: definição dos extratores e especificação das importações dos dados. Tendo estas especificações bem definidas é possível executá-las em paralelo. As especificações dos extratores conterão a definição da seleção dos dados, critérios de seleção, formato de saída, objetos que devem ser criados, parâmetros da interface, script de teste e controles de erro. A seleção dos dados e os critérios de seleção definirão quais os objetos, campos e tabelas, dos sistemas transacionais serão manipulados e qual a relação entre eles. Os critérios de seleção também poderão conter restrições fixas da seleção dos















16 definida na especificação de levantamento de dados e alinhada com a necessidade da área de negócio, os extratores devem possuir a capacidade de serem executados a qualquer tempo para correção de problemas adversos. Com a periodicidade definida, deve-se buscar o menor volume de dados possível dos sistemas transacionais. INMON “Outro importante problema diz respeito ao acesso eficiente aos dados dos sistemas existentes. Como pode o programa que varre os sistemas existentes saber se um arquivo já foi varrido anteriormente? Há uma enorme quantidade de dados no ambiente de sistemas existentes e a tentativa de efetuar varreduras completas toda vez que é feita uma varredura para o data warehouse é antieconômica e pouco realista. Há três tipos de carga que podem ser feitos do ambiente operacional para o data warehouse: o carregamento de dados históricos, o carregamento de dados de valor corrente no ambiente operacional e o carregamento de alterações do data warehouse a partir de alterações (atualizações) que tenham ocorrido no ambiente















17 próximas fases do projeto até a análise de resultados, onde algumas validações podem ser executadas e possivelmente trará modificações para os extratores de dados. Por fim, após as modificações, os dados devem ser convertidos por períodos. Tentar trazer todos os dados de uma só vez não é recomendado, podendo causar grande impacto nos sistemas transacionais, que já estão em ambiente produtivo. É comum verificarmos que, após a carga dos dados dos sistemas transacionais para o data warehouse, muitas informações não possuem o valor esperado. Após as primeiras cargas de dados, é necessário fazer uma análise criteriosa das informações. Muitos dados podem não estar qualificados, ou seja, os dados contidos nos sistemas transacionais não estão consistentes. Este problema de qualificação e análise dos dados é abordado com mais detalhes na fase de análise de resultados, onde o analista de suporte a decisão tem grande participação no processo.















18 A característica de ser multidimensional, das ferramentas OLAP, permite que os assuntos (Data Marts) sejam analisados por diferentes visões (prismas, ângulos etc). Esta característica está intimamente ligada a análise exploratória que permite ao analista de suporte a decisão investigar os dados, adquirindo conhecimento, validando suposições, análise de tendências e confrontando diferentes aspectos do assunto, entre outras análises possíveis. Se considerássemos uma base de dados ideal que, para qualquer consulta executada, o tempo de resposta fosse sempre imediato, uma das questões mais importantes tratadas pelas ferramentas OLAP não seria necessária. A agregação das informações, executada pelo processamento das ferramentas OLAP, disponibilizará imediatamente as informações, independente da complexidade da consulta. Se as agregações foram feitas por demanda deve ser de forma imperceptível para os analistas de suporte à decisão. De forma simplista as ferramentas OLAP devem calcular (agregar)

















19

4.5. ANÁLISE DE RESULTADOS Esta fase pressupõe que as informações já estão disponíveis para análise. Não é necessário que todos os dados já tenham sido carregados para o data warehouse, mas uma parte significativa que permita a avaliação dos resultados. Neste ponto do projeto o analista de suporte a decisão tem a responsabilidade de validar as informações contidas no data warehouse. O analista deverá observar a conformidade das informações















20 fazer com que os executivos percam a confiança nas informações de tal modo que se determine a descontinuidade do projeto todo. O comprometimento dos executivos e analistas de suporte a decisão é fundamental para o sucesso do projeto, garantindo confiança nas informações e continuidade.

4.6. VISÕES PRÉ-DEFINIDAS















21 funções específicas das linguagens de consulta de dados das ferramentas OLAP ou da utilização de ferramentas de Data Mining. Algumas das principais questões, documentadas na especificação do levantamento de dados, poderão ser respondidas com a criação de visões pré-definidas, já que as informações estão disponíveis. Os indicadores da empresa poderão estar disponibilizados como visões















22 Por outro lado, de que adiantaria todo o esforço para construir o data warehouse se as informações ficarem confinadas no repositório de dados. Alguns analistas podem desenvolver uma visão analítica, crítica e consciente, com o acesso as informações do data warehouse.

5. ADMINISTRAÇÃO Na maior parte do tempo a administração do data warehouse estará voltada















23 Em alguns casos manter os padrões de desenvolvimento podem ser mais interessante que obter a melhor performance possível. Utilizar linguagens de pouco conhecimento da equipe, ou de profissionais do mercado, pode não ser uma estratégia segura para a administração do data warehouse. O data warehouse deve possuir ao menos dois ambientes similares, um de produção e outro de desenvolvimento. Para implementações críticas é aconselhável um ambiente de validação dos desenvolvimentos e de performance. Os ambientes de

















24 problemas emergenciais e entenda perfeitamente as características dos dois ambientes.















25 Em 99, apoiado pelas áreas financeira e comercial, inicio-se o projeto de















26 Com o sucesso da área financeira e confiança na arquitetura do data















27 deste Data Mart, a área passou a poder executar análises dos melhores clientes, de















28 não se aplicar às condições da realidade. As instituições estão em constante mudança,















Metodologia para Implantação de Data Warehouse

Recommend Documents