(E) Como transformar a informação e a tecnologia da informação em fatores de crescimento e de alto desempenho nas organizações

De vez em quando sou questionado por profissionais e alunos: como transformar a informação e a tecnologia da informação em fatores de crescimento e de alto desempenho nas organizações?

E sempre me encontro em uma situação delicada para responder a este questionamento, porque é um assunto complexo, não dá para ser resumido em uma única linha. A sua complexidade é devido ao fato que atualmente a tecnologia aplicada com sucesso, pode ser vista por muitos como inovação. Mas nem sempre a tecnologia é garantia de sucesso para muitas organizações. É preciso ir além, é preciso integrar processos, pessoas, e principalmente entregar informação na hora certa.

A informação já é considerada o principal insumo e, em muitos casos, o principal produto das organizações. Quando bem gerenciada, ela se transforma em recurso estratégico: é fator de crescimento de lucros, de redução de custos operacionais, de otimização do processo decisório, de solução de problemas e de eliminação de barreiras de comunicação, entre outros benefícios trazidos para o desempenho organizacional. Com o aumento da complexidade e do dinamismo das organizações, estas passaram a depender de mecanismos mais eficazes de administração da informação, a fim de reduzir o quadro de incerteza em que suas decisões são tomadas e de melhorar o relacionamento com parceiros, clientes, fornecedores e agentes reguladores.

Gerenciar adequademente os recursos informacionais e seus fluxos na organização representa, hoje, uma necessidade cada vez maior em qualquer tipo de negócio. Para serem eficazes, as organizações precisam ter seus processos decisórios e operacionais alimentados com informações de qualidade, obtidas dentro de uma boa relação de custo-benefício e principalmente, conforme as necessidades do negócio. A simples ação de tornar as informações prontamente disponíveis para os vários colaboradores da empresa, pode melhorar de forma significativa os resultados por ela a serem obtidas. Algumas dezenas de vezes por dia, colaboradores dos mais diversos níveis hierárquicos, dentro da organização precisam resolver problemas, tomar decisões, controlar processos, compartilhar informações e relacionar-se com outras pessoas, e em todas essas situações o desempenho pode ser aperfeiçoado caso as informações apropriadas estejam presentes no momento oportuno. Compreender as formas pelas quais se pode otimizar o uso dos recursos informacionais e de TI representa, hoje, um aspecto fundamental para a melhoria do desempenho de qualquer organização.

Por esta razão, resolvi aproveitar este canal de comunicação para compartilhar com todos vocês, conceitos e ideias para melhorar a gestão da informação nas organizações, desta forma, ajudar na transformação da informação e da tecnologia da informação de mero recurso operacional em ativo estratégico para o negócio.

Estarei divulgando, em primeira mão, nas próximas semanas, uma série de publicações, que fazem parte do meu próximo livro (ainda sem título), sobre business intelligence e gestão da informação. Acompanhe aqui, o que eu denominei de: Série Gestão Estratégica da Informação.

Um grande abraço a todos!

BI e o software de código aberto

O impacto da crise financeira tem obrigado muitas empresas a cortar custos, ao mesmo tempo que a concorrência aumenta. É neste contexto, que o analista do Gartner Group recentemente informou que o interesse em alternativas open source para soluções de business intelligence (bi), em relação às ferramentas comerciais, tem sido crescente.

Em um relatório divulgado há algumas semanas, "Open-Source Business Intelligence Tools Production Deployments Will Grow Five-Fold through 2012", o analista afirmou que, embora nas alternativas de código aberto, ainda faltam algumas funcionalidades importantes que podem ser encontradas nas aplicações comerciais, o interesse no menor custo é crescente, ferramentas de código aberto a partir de empresas como JasperSoft, Pentaho.

Segundo o Gartner, o custo médio de um projeto de BI usando solução open-source é de cerca de US$ 30.000,00 (R$ 60.000,00) por ano aproximadamente, mas alguns acabam ultrapassando os US$ 500.000, valores este que acabam sendo similar ao gasto de um projeto de BI usando uma solução comercial.

O analista ainda acrescentou que enquanto as empresas de software comercial tradicionais, rejeitam a idéia de que seus modelos de negócio poderiam estar sob a ameaça de aplicações de código aberto, outras estão respondendo à esta possível ameaça.

Mas, enquanto algumas empresas parecem estar aproveitando o potencial do código aberto para ajudá-los a cortar custos e evitar a cobrança punitiva de alguns fornecedores de software comercial, outros têm rejeitado a idéia de utilizar software open-source como um risco para a sua infra-estrutura.

E você o que acha sobre tudo isso. Afinal o software de código aberto é um risco? As empresas deveriam adotar o software de código aberto em operações de missão crítica?

Participe, mande a sua opinião, até a próxima.

Um grande abraço a todos!

(T) Indexação no Data Warehouse - Parte 2

Consideração sobre o predicado

Digamos que um data mart processasse continuamente consultas usando as colunas PURCHASE_DATE e CUST_NUM como parte do predicado. Essas duas colunas devem ser consideradas para índices. As colunas apresentadas como parte dos resultados da consulta, mas não utilizadas como parte de um predicado, não são boas candidatas para índice. Em outras palavras, a coluna em itálico na listagem a seguir pode não ser conveniente para um índice, enquanto a que parece em negrito pode ser uma candidata ideal:

select sum(aggr_day), region, ...

from day_summary, region

where trans_date between '01-jan-2002' and '31-jan-2002' ...;

Isso nos leva à segunda diretriz de indexação importante.

DICA: As colunas que normalmente fazem parte de critérios de seleção de consulta são candidatas para índices.

Naturalmente, como essa é uma regra (na verdade, uma diretriz), existem exceções. As colunas continuamente mencionadas em um predicado, mas nas quais uma função ou operação é efetuada, não são candidatas para índices. Se uma função deve ser executada em uma coluna, o índice da coluna não é usado. Chamamos isso de supressão de índice. A listagem a seguir mostra dois exemplos de como a coluna TRANS_DATE, da listagem anterior, pode ser usada, mas que não garante um índice:

select sum(aggr_day), region, ...

from day_summary, region

where to_char(trans_date, 'Dy') in ('Mon', 'Tue') ...;

select sum(aggr_day), region, ...

from day_summary, region

where months_between (trans_date, sysdate) > 6 ...;

Existe mais uma diretriz que trata com colunas mencionadas em predicados, com e sem função. Suponha que tenhamos um exemplo de quando a coluna TRANS_DATE de DAY_SUMMARY é usada na instrução SQL:

select ...

from day_summary ...

where to_char (trans_date) ...;

Assim como na instrução SQL:

select ...

from day_summary ...

where trans_date between ...;

DICA: Uma coluna que é usada em um predicado - com e sem função executada nela - ainda pode ser candidata para um índice. Analise o número de instruções SQL que estão usando uma função e implemente um índice, caso ele otimize as instruções sem uma função.

Exclusividade do data warehouse

De certa forma, verificamos aqui que a indexação de um data warehouse ou mesmo um data mart é um ponto importante a ser observado e tratado pelos arquitetos de solução juntamente com os administradores de banco de dados e que não pode ser colocado em segundo plano. Uma ocorrência comum encontrada no projeto de sistemas operacionais/transacionais é que o banco de dados usado durante o desenvolvimento é muito diferente de seu equivalente de produção. Por exemplo, ele poderia conter apenas um pequeno subconjunto dos dados de produção ou as tabelas usadas seriam uma fração de seu tamanho de produção.

Em algumas empresa é possível encontrar tabelas muito grandes, com 30 ou 40 milhões de linhas na produção e um subconjunto de 30 ou 40 mil linhas no desenvolvimento. No ambiente de data warehouse ou data mart, devem existir dados de desenvolvimento suficientes para que decisões de indexação bem pensadas possam ser tomadas em relação a volumes de dados realistas. Sob essas condições, torna-se mais fácil avaliar a eficiência dos índices e realizar testes para ajustar os índices adicionais que poderiam ajudar no desempenho das consultas a serem realizadas. As tabelas podem ser analisadas e cálculos sobre a seletividade podem ser feitos, para decidir quais são as colunas apropriadas para indexação.

DICA: As colunas indexadas nos sistemas operacionais/transacionais não são necessariamente boas candidatas à indexação no data warehouse.

(T) Indexação no Data Warehouse - Parte 1

Um índice é, na maior parte dos casos, uma estrutura separada dos dados da tabela a que ele se refere. Ele armazena a localização de linhas no banco de dados, baseado nos valores de coluna especificados quando o índice é criado. Os índices são como minicópias dos dados da tabela a que se referem. Vamos supor que uma consulta fosse restrita a LAST_NAME e procurasse nomes que começassem com o texto "SM". Sem um índice em LAST_NAME, o banco de dados leria da primeira linha até a última, procurando as linhas com o string de pesquisa desejado. Com um índice, o banco de dados percorreria, obteria um endereço da linha qualificada e, em seguida, apresentaria os dados da linha qualificada, para o processo que fez a consulta. Em resumo, é para isso que servem os índices.

As pequisas de índice são o segredo da otimização do tempo de resposta da maior parte das consultas e são usados sistematicamente em um data warehouse para melhorar seu desempenho de saída.

Um desempenho de saída melhorado contribui para as quatro palavras tão importantes para o sucesso de um projeto de data warehouse - maior satisfação do cliente. No entanto, para se atingir este estágio se faz necessário decidir onde colocar os índices. De muitas maneiras, essa é uma faca de dois gumes: índices demais levam a uma sobrecarga maior do sistema, mas índices de menos podem facilmente diminuir a velocidade de recuperação dos dados no momento da consulta. Então...

Quais colunas indexar?

Existem duas regras ou diretrizes principais com relação a quais colunas indexar no banco de dados: seletividade e critérios de seleção. Seletividade, é uma medida do número de valores distintos na coluna de uma tabela, comparado ao número de linhas da tabela inteira. O predicado de uma instrução SQL é aquela parte onde os critérios de seleção são especificados. Esses critérios de seleção especificam quais linhas de informação devem ser incluídas no conjunto de resultados da consulta. O primeiro critério com a palavra-chave WHERE; todos os critérios subseqüentes começam com a palavra-chave AND. O conjunto de resultados é um conjunto de uma ou mais linhas que se qualificam para inclusão em uma consulta específica.

Consideração sobre a seletividade

Vamos supor que existissem 79.000 linhas em uma tabela, em um data mart financeiro, e que a coluna ACC_TYPE tivesse 8 valores distintos. A seletividade de qualquer linha em uma tabela é calculada de acordo com a seguinte fórmula:

seletividade = (linhas na tabela / valores distintos) * ( 1 / linhas na tabela)

Isso é o mesmo que dizer que a seletividade é o inverso do valor encontrado em NUM_DISTINCT para essa coluna. Em nosso exemplo, a seletividade é igual ao inverso de 8, o que dá 0,125, ou 12,5, expresso como uma porcentagem. Isso leva à primeira das três diretrizes de indexação.

Quando é encontrado um valor de coluna menor do que 5% de todas as linhas em uma tabela, essa coluna é uma boa candidata para um índice.

Espero que esta primeira parte deste importante tópico, tenha sido útil para todos vocês. Na próxima semana falarei da outra diretriz de indexação: consideração sobre o predicado.

Um grande abraço a todos!

(T) Oracle Essbase Studio 11 – Parte 1

O Essbase Studio 11 é a novidade da Oracle. Esta versão fornece aos usuários uma interface gráfica para desenvolver, implantar e manter cubos Essbase (OLAP) com base em uma ou mais fontes de dados. Antes do Oracle Essbase Studio 11 ser lançado, para se conseguir isso, era necessário uma combinação das seguintes ferramentas: Essbase Integration Services (EIS) e do Essbase Administration Services (EAS). Agora só o Essbase Studio basta para se construir um modelo multidimensional a partir de fontes de dados que variam a partir de tabelas de banco de dados relacional, exibições e arquivos simples para OBIEE e dimensões EPMA. Além disso, o Essbase Studio faz uso de várias interfaces 'wizard-driven', buscando tornar as operações mais fáceis para os usuários finais, desta forma a Oracle busca aumentar a adoção da ferramenta.
Os profissionais envolvidos com o desenvolvimento de soluções Business Intelligence e EPM deverão prestar especial atenção ao aparecimento do Essbase Studio, como a integração de cubos Essbase com as ferramentas do OBIEE.

No entanto, os exemplos que são incluídos com a aplicação são limitados e não tem muito a ver com o mundo real. Além disso, os exemplos disponíveis são pré-construídos e sem qualquer denotação. Estão disponíveis na aplicação sob a forma de construtores (step-by-step) de um modelo no Essbase Studio.
Estarei a partir de hoje, postando neste blog, vários artigos (na forma de um mini-tutorial), no intuito de esclarecer e demonstrar algumas das principais funcionalidades desta nesta nova versão que na minha opinião promete ser uma das melhores.

Essbase Studio - Criar uma fonte de dados
Uma fonte de dados pode ser um arquivo texto (.txt), um arquivo CSV (.csv), OBIEE, DRM, ou um banco de dados relacional. Neste nosso exemplo, vamos utilizar o demo que se encontra no banco de dados Oracle 'Regime AdvWorks' para construir uma fonte de dados.

Iniciando o Essbase Studio
Antes de iniciar o Essbase Studio, certifique-se que todos os serviços necessários estão iniciados. A maneira mais fácil de iniciar o Studio é a partir de um atalho (se disponível) na sua área de trabalho. No entanto, você pode usar a estrutura do programa pelo 'Iniciar >> Todos os Programas >> Oracle EPM System >> Essbase >> Essbase Studio >> Essbase Studio Console'.

Depois do Studio ser iniciado, todos os elementos de 'designer' são visíveis através do 'layout' de navegação da aplicação. Para este primeiro artigo especificamente, vamos nos concentrar na criação de uma fonte de dados. Irei expor os outros elementos do aplicativo nos próximos artigos.

HOW-TO: Criar fonte de dados (MiniSchema Start)

1- Selecione o item 'Data Source' a partir do menu 'File >> New'.

2- Na tela 'Connection Wizard' complete os campos com as seguintes informações:

>> Connection Name = AdventureWorks

>> Data Source Type = Oracle

>> Server Name = localhost, ou o nome do servidor onde está o seu BD (Ex.: o nome da minha máquina é "binapratica")

>> User Name = AdvWorks

>> Password = Oracle1

>> SID = XE (ou, configure o TNSNAMES, que se conecta ao seu BD)

3- Teste a conexão e tenha a certeza de que está funcionando corretamente. Se por alguma razão o teste falhar, verifique se o 'username' e a 'password' foram digitadas corretamente. Se o problema estiver com o usuário 'AdvWorks', você pode criar um novo usuário com privilégios de leitura e usar este novo usuário aqui.

4- Clique Next.

5- Em 'Select Tables', selecione todos os objetos que deseja importar exceto : DimEmployee, DimReseller e DimSalesReason.

6- Clique Next.

7- Em 'Select minischema' escolha 'Create a new schema diagram'. O nome padrão aparece no campo, então não precisa alterá-lo.

8- Desmarque a opção 'Use Introspection to Detect Hierarchies'.

>> Esta opção ativa uma operação 'default wizard' para transformar todos os elementos de uma dimensão em hierarquias.

9- Clique Next.

10- Em 'Populate Minischema' certifique-se que todas as tabelas que estão em 'Available' (lado esquerdo) foram passados para 'Tables in Schema' (lado direito).

11- Clique Finish.

12- Clique OK em 'Data Source created successfully'.

Neste primeiro artigo aprendemos a iniciar o Essbase Studio e a criar uma fonte de dados. Além disso, criamos um mini-esquema com base na fonte de dados. Podemos observar neste artigo que esta nova versão 'Essbase Studio' é impulsionada por wizards (assistentes). Mostrei também que o 'assistente de conexão' nos possibilita ter controle sobre a forma como os elementos de modelagem serão construídos. Propusemo-nos a criar uma fonte de dados, e na segunda etapa do 'Assistente para conexão', depois de selecionar as tabelas, poderíamos ter simplesmente clicado no botão 'Finish' para concluir a criação da fonte de dados. Em vez disso, fomos para o passo 'Select Minischema' que poderia ter sido completamente omitido ou iniciado a partir de outro assistente no Studio em um momento posterior. Temos agora uma fonte de dados e um mini-esquema para trabalhar, mas isto fica para o próximo artigo.

Abraço a todos!

(O) Populando um BW Data Warehouse

Existem algumas diferenças entre usar o PowerCenter para carregar dados para dentro do BW versus usar o PowerCenter para carregar dados para dentro de um DW construído sobre um SGBD. Estas diferenças incluem:

♦Formas de comunicação-> BW deve requisitar dados de um sistema fonte antes do sistema fonte poder enviar dados para o BW. Para o BW obter os dados do PowerCenter, o PowerCenter deve primeiro ser registrado com o BW usando o protocolo SAP RFC (Remote Function Call). Além disso, o PowerCenter usa o SAP BW Service para se registrar com o BW. Na verdade você configura o SAP BW Service no PowerCenter Administration Console.

♦A interface nativa para carga de dados para o BW é BAPIs-> esta é uma aplicação API publicada e suportada pelo SAP.
O Integration Service usa o BAPIs para realizar verificação de metadados e carga de dados para dentro do BW.

♦Os programas de comunicação com o BW usa o arquivo padrão do SAP saprfc.ini para se comunicar com o BW-> este arquivo é similar ao 'tnsnames' no Oracle. Ele contém o tipo de conexão e os parâmetros específicos requeridos para se conectar ao BW. Dois tipos de entrada são requeridos para o PowerCenter. O SAP BW Service usa um tipo de entrada 'R' no arquivo saprfc.ini para se registrar como um servidor RFC com o BW e receber solicitações para executar workflows. O Designer usa um tipo de entrada 'A' no arquivo saprfc.ini. Como um cliente RFC, o Designer importa os metadados do BW para as estruturas de transferência target.

♦BW requer que você defina os metadados complementares no BW Administrator Workbench-> criar e ativar componentes no BW. Sistemas externos, como o PowerCenter não pode criar estruturas no BW. Deste modo, a função de gerar e executar no Designer não se aplica aos targets BW. Logo, para carregar dados para dentro de um target BW, você precisa importar os 'target definition' para dentro do Designer. O mapping do PowerCenter usa este target para representar uma estrutura de transferência quando carregar os dados para dentro do BW.

♦Controlar todos os agendamentos-> quando você configura uma session no PowerCenter para carregar dados para dentro do BW, o agendamento de execução do workflow é 'on demand'. Você pode controlar os agendamentos criando um InfoPackage no BW que faça referência a esta session no PowerCenter. O BW então chama o workflow no PowerCenter quando o InfoPackage é agendado para ser executado no BW.

♦O PowerCenter só pode ser usado para inserir dados no BW-> você não pode fazer 'update' ou 'delete' de dados.

Passos para carregar dados para dentro do BW

1.Criar os componentes BW-> criar e ativar um InfoSource no BW.

2.Criar mappings->importar o InfoSource para dentro do repositório PowerCenter e construir um mapping usando o InfoSource como um target.

3.Carregar dados->criar uma session no processo de workflow do PowerCenter e um InfoPackage no BW e depois encadear todo este processo no BW.

(O) Métodos de integração entre o PowerCenter e o SAP BW

Hoje vou falar sobre a integração de dados entre o PowerCenter uma poderosa ferramenta de integração de dados da Informatica e o SAP BW, ferramenta OLAP para a construção de cubos da SAP a partir de dados do SAP/R3.

Esta integração de dados pode se dá em dois momentos:
♦ Extração de dados a partir do BW.
♦ Importação de dados para dentro do BW.

A integração com o BW se dá através de InfoCubos e InfoSources. Um InfoCubo é um cubo virtual criado a partir de um ou mais InfoSources. Um InfoSource é uma coleção de dados que pode pertencer a um ou mais cubos.

1- Extração de dados BW

É possível extrair dados do BW e usá-lo como um source em uma session no PowerCenter através do BW Open Hub Service (OHS). Open Hub Service é um framework SAP para extração de dados. OHS usa dados de múltiplos data sources BW, incluindo InfoSources e InfoCubos. O OHS framework inclui também programas InfoSpoke, que extrai dados do BW e escreve a sua saída para tabelas (transparentes) do SAP.

A comunicação do 'PowerCenter SAP BW Service' com o BW é feita via RFC e inicia workflows dentro do PowerCenter que extrai dados do BW. Você configura o SAP BW Service no 'PowerCenter Administration Console'.

Figure 1- representação de como é a integração do PowerCenter e o BW na extração de dados.

2- Importação de dados para o BW

Você pode usar o BAPI (Business Application Program Interface), como método para unir componentes para dentro do Business Framework, para trocar metadados com o BW. Além disso, você também pode usar BAPIs para carregar dados para dentro do BW a partir de aplicações externas.

Na verdade você importa para dentro do Designer 'target definitions' BW e usa este target em um mapping para carregar dados para dentro do BW. Durante o processo de workflow do PowerCenter, o 'Integration Services' usa um método de transferência para carregar os dados para dentro das estruturas de transferência do BW.

Estes métodos de transferência são configurados no BW para especificar como carregar os dados para dentro de uma estrutura de transferência do BW. No BW, os dados podem ser movidos de uma estrutura de transferência para InfoCubos e InfoSources através de estruturas de comunicação. Ou seja, para mover dados para uma estrutura de comunicação ele usa regras de transferência e para mover dados a partir destas estruturas de comunicação para InfoCubos e InfoSources ele usa regras de update.

Figure 2-mostra como é a integração do PowerCenter com o BW para carga de dados.

Para executar uma session no PowerCenter, você precisa configurar um InfoPackage no BW. Um InfoPackage especifica os agendamentos de workflows do BW e as solicitações de dados do PowerCenter.

(E) O que entra no Data Warehouse?

Muitos projetistas de data warehouse iniciantes veem o warehouse como o repositório final de todos os dados da empresa. Eles farão declarações ingênuas, como "Toda a produção de relatórios da empresa será feita a partir do warehouse". Geralmente, essa não é uma estratégia viável. Conforme já mencionei, o warehouse é apenas um componente de uma estratégia de produção de relatórios empresarial, eu diria até um importante componente.

Outro motivo pelo qual é importante "posicionar" o warehouse na arquitetura de produção de relatórios corporativa é para proteger o projeto de uma construção grande demais. No desenvolvimento de sistemas, aumentos no tamanho aumentam o risco. Cada nova tabela, cada nova coluna, cada nova restrição, aumenta o volume de trabalho de desenvolvimento que deve ser estimado, agregado e executado. Eles também aumentam a possibilidade de que um objeto na arquitetura venha a falhar. Assim, posicionar o warehouse efetivamente é uma ferramenta para o gerenciamento de sua abrangência e para ajudar a garantir seu sucesso.

Dessa forma, recomendo que, ao projetar um warehouse, você faça uma declaração (uma espécie de missão do projeto), explícita quanto ao lugar que este sistema vai se encaixar no processo de produção de relatórios na sua organização. Essa declaração deve pormenorizar as regras que serão usadas para determinar quais dados serão armazenados e quais serão excluídos. Um exemplo de declaração: "O warehouse vai focalizar a entrega de dados em um formato agregado dos principais relatórios disponibilizados atualmente para a alta direção cujo seu acompanhamento e monitoramento é diário e possuem impacto financeiro."

Declarações como esta (talvez com um pouco mais de detalhes) proporcionam aos desenvolvedores de warehouse uma base para decidir o que será incluído e o que será excluído do warehouse. Essa declaração de posição do warehouse deve ser desenvolvida enquanto se estiver reunindo os requisitos da empresa e de usuário.

A comunidade de usuários deve indicar seu entendimento e concordar com a declaração de posição do warehouse. Isso não apenas os ajuda a entender o papel do warehouse, mas também proporciona a eles outra maneira de fazer planos para sua utilização.

(E) Comece com os requisitos da empresa - não com a tecnologia

O que o deixou interessado em construir sistemas? Para muitos de nós,foi a paixão pela tecnologia. Gostamos de escrever sistemas elegantes, que apresentam belas figuras na tela de algum usuário injustiçado. Nossa resposta para praticamente todo problema é "construir um novo sistema".

Bem, infelizmente, o data warehouse não tem a ver com tecnologia. Ele tem a ver com resolução de problemas empresariais. Um segredo para o sucesso do data warehouse é começar focalizando as informações de que a empresa precisa para prosperar e não a tecnologia que vamos usar para entregar essas informações.

As tecnologias de consulta e navegação de dados são "bacanas" e os desenvolvedores tendem a querer mexer com elas. Na verdade, já vi projeto, onde a equipe passou os primeiros seis meses escolhendo a ferramenta de consulta e navegação de dados e depois aprendendo a utilizá-la. As estruturas de dados ficaram relegadas a segundo plano. Os gerentes e os usuários finais não são pessoas estúpidas. Eles podem e sabem identificar quando um progresso real está ocorrendo e quando não está. No final, os gerentes dessa empresa ficaram tão frustrados, que cancelaram o projeto inteiro. Posteriormente, ele foi reiniciado, mas com um novo gerente de projeto, que foi instruído a retirar a ênfase nas ferramentas.

É importante lembrar que a maior parte dos data warehouses corretamente projetados será acessada por uma variedade de tecnologias. Assim, focalizar qualquer tecnologia de consulta e navegação de dados pode desviar a concentração da equipe com relação à construção da flexibilidade necessária para o projeto inteiro.

Também lembre-se de que as tecnologias aparecem e desaparecem. O prato do dia pode ser Oracle Hyperion, mas amanhã, pode ser MicroStrategy. Independentemente do que um vendedor de soluções possa dizer, a peça estratégica real do data warehouse são os dados. É fundamental que as estruturas de dados reflitam precisamente as exigências da empresa e que elas contenham dados corretos e confiáveis. É só lembrar do ditado LE/LS ou "lixo que entra é igual ao lixo que sai". Faça todo o possível para proteger a integridade dos dados armazenados em seu data warehouse.

Há uma advertência. Determinadas ferramentas ou tecnologias de consulta e navegação de dados exigem típos específicos de estruturas de dados para funcionar. Sendo assim, recomendo que tais ferramentas sejam vistas como tecnologias de consulta com função restrita, em vez de uma solução com componentes integrados capaz de propiciar à empresa um ambiente de informação gerencial e estratégica robusta, confiável e escalável.

(E) Como dar poderes aos usuários

Quantas vezes você já ouviu ou leu em revistas e sites especializadas de negócios, que a empresa tal estava sendo reestruturada? As empresas fazem isso principalmente em época de crise. Ao se aprofundar nos detalhes da reestruturação, é possível descobrir, em algum lugar, que a diretoria da nova organização depois da reestruturação dará poderes aos seus funcionários (remanescentes). O que se quer dizer com isso “dar poderes”? Será que o que eles querem dizer é que, agora, os vários funcionários poderão tomar muitas das decisões que antes só a alta gerência participava. Contudo, vamos pensar no seguinte: o quanto os funcionários serão eficientes em tomar decisões, se eles não possuírem dados e informações necessários para tomar tais decisões?
Implementar um depósito de dados integrados (data warehouse) é uma maneira efeciente de entregar esses dados. Isso não apenas libera quem necessita do dado de recorrer à diretoria em cada decisão, mas, também o libera da necessidade de recorrer a área de sistemas de informações (TI) para solicitar este ou aquele relatório que poderá levar dias.
Esse “poder” a que estou me referindo, possibilita que os consumidores da informação controlem o seu próprio destino – não recorrendo aos programadores de plantão para solicitar relatórios, programados para atender aquela necessidade imediata. Quantas vezes isso ocorre em um ambiente operacional? A todo instante novo relatório é identificado e demandado, colocados em perspectiva e programados, após o que, você descobre que o usuário encontrou outras fontes para a saída desejada. Existe aí um atraso de tempo inevitável entre a identificação de novos requisitos e a sua entrega. Não se trata de uma falha da área de sistemas, mas sim da realidade.

O uso de ferramentas de produção de relatórios e portais de informação (dashboards) a partir de um depósito de dados integrado (data warehouse) dá aos funcionários (usuários) o “poder” que mencionamos anteriormente, para obter e analisar dados e, respaldados com informações de qualidade (coerentes e concisas), tomar as decisões que lhe cabem. Podemos dar como exemplo, as ferramentas OLAP (On-Line Analytical Processing), que permitem aos usuários a partir de dados disponíveis no data warehouse fazer previsões, refinar e procurar tendências sobre todos os aspectos de seu negócio. Com o data warehouse, o usuário passa a ter acesso aos dados de forma fácil e rápido, podendo ainda trabalhar de maneiras nunca antes imaginadas. Desta forma novas informações são produzidas e descobertas e assim nasce uma nova maneira de pensar e agir dentro da empresa. De posse dessa liberdade de acessar os dados e produzir os relatórios sobre o que deseja, o pessoal de desenvolvimento de sistemas fica livre para construir novos aplicativos. Esses aplicativos podem ser personalizados para implementar sistemas especialistas a serem utilizados pela diretoria e pela gerência, com base nas informações extraídas do data warehouse. Eles também podem até ser aplicativos para corrigir algum problema de inconsistência de dados que o data warehouse por ventura tenha identificado.

Conclusão, dar “poder” ao usuário é ter a possibilidade de transformar a empresa em uma empresa mais dinâmica, ágil e criativa. E a principal maneira de viabilizar isso, é criar uma infra-estrutura de dados capaz de entregar os dados certos para quem é de direito de forma fácil e rápido.

(T) Verificando a consistência de um repositório

Atualmente é possível verificar a consistência das seguintes maneiras:

• Pode-se verificar a consistência global do repositório a partir do menu ‘Arquivo’ e do ‘Consistency Check Manager (Check All Objects)’. Se você desativou quaisquer regras de verificação do ‘Consistency Check Manager’, essas regras não serão verificadas.

NOTA: Se você desativar um objeto e ele está inconsistente, você receberá uma mensagem perguntando se você quer torná-lo disponível para consultas.

• Pode-se verificar a consistência de um modelo de negócios a partir do menu do botão direito de um modelo de negócio.
• Pode-se verificar a consistência de alguns ou todos os objetos no repositório a partir da verificação do ‘Consistency Check Manager’. Para limitar os objetos que são controlados, na verificação do ‘Consistency Check Manager’, na guia ‘Opções’, você pode desativar as regras para os objetos que deseja excluir.
  

Para verificar a consistência de um repositório:

1. Em ‘Administration Tool’, a partir do menu ‘Tools’, selecione ‘Show Consistency Checker’.

Se você verificou a consistência na sessão atual, as mensagens da última verificação aparecem na guia ‘Mensagens’.

2. Em ‘Consistency Check Manager’, clique na tab ‘Options’ e verifique se as regras estão configuradas corretamente.

3. Clique na tab ‘Messages’ e clique em ‘Check All Objects’.

Se você já tiver verificado a consistência na sessão atual e, em seguida, mudar as regras, você poderá notar mensagens diferentes.

4. Para editar o repositório para corrigir inconsistências, realize os seguintes passos:

1. Dê um duplo clique em qualquer célula em uma linha e uma caixa de diálogo ‘Propriedades’ para esse objeto é aberta.

2. Na caixa de diálogo ‘Propriedades’ para o objeto, corrigir a inconsistência, e clique em OK.

5. Para copiar as mensagens para que você possa colá-los em outro arquivo como uma planilha, clique em ‘Copiar’.

6. Para verificar a consistência de novo, clique em ‘Check All Objects’.

Quando você selecionar ‘Show Consistency Checker’ a partir do menu ‘Tools’ ou ‘Check Global Consistency’ a partir do menu ‘File’, o botão de atualização no canto superior direito da caixa de diálogo do ‘Consistency Check Manager’ verifica todos os objetos.

7. Quando finalizar, clique ‘Close’.
   

Para verificar a consistência de um simples objeto no repositório:

1. Em ‘Administration Tool’, clique com o botão direito do mouse sobre um objeto, e então selecione ‘Check Consistency’.

Se o objeto não está consistente, uma lista de mensagens aparece.

2. Para editar o repositório para corrigir as inconsistências, realiza os seguintes passos:

1. Dê um duplo clique em qualquer célula em uma linha e uma caixa de diálogo ‘Propriedades’ para esse objeto é aberta.

2. Na caixa de diálogo ‘Propriedades’ para o objeto, corrigir a inconsistência, e clique em OK. .

3. Para copiar as mensagens para que você possa colá-los em outro arquivo como uma planilha, clique em ‘Copiar’.

4. Para verificar a consistência do objeto novamente, clique no botão atualizar no canto superior direito da caixa de diálogo.

NOTA: Se você clicou em ‘Check All Objects’, todos os objetos no repositório serão verificados.

(T) Configurando o “Consistency Check Manager” no Oracle BI

Durante a instalação, um subconjunto de regras padrão está instalado. Em cada estação de trabalho, os usuários podem usar o subconjunto padrão das regras ou alterar o subconjunto, adicionando ou excluindo regras. Por padrão, todas as regras de verificação de consistência são ativadas e todos os tipos de mensagens são definidos para mostrar depois que você executar uma verificação de consistência. Você pode desativar qualquer das regras de verificação de consistência e alterar as mensagens da lista, para que um ou mais dos seguintes tipos de mensagens não aparecem.

Entretanto, pelo menos um tipo de mensagem deve ser ativado.

Para configurar o “Consistency Check Manager” :

1. Em ‘Administration Tool’, selecione ‘Tools’ > ‘Show Consistency Checker’.
2. Em ‘Consistency Check Manager’, na tab ‘Messages’, faça o seguinte:
3. Desmarque o check box para quaisquer tipos de mensagens que você não deseja exibir.
4. Se você deseja que a mensagem mostre o nome completo de cada objeto, selecione o check box ‘Show Qualified Name’.
5. Clique na tab ‘Options’.
6. Expanda cada tipo de mensagem.
7. Para desativar uma regra ativada, selecione a regra e clique em ‘Disable’.
8. Para habilitar uma regra desativada, selecione a regra e clique em ‘Enable’.
9. Se você não deseja verificar a consistência, neste momento, clique em ‘Close’.