www.bibrasil.

net

PERFIL BUSINESS INTELLIGENCE

marcelokrug@gmail.com

SEU PAPER PELA INTERNET

Desde Maro/2015 pp24

LONGOS PROJETOS DE BUSINESS INTELLIGENCE: FUGIR DA ROTINA

Quando estamos muito tempo no desenvolvimento de um projeto, de Business Intelligence ou outros em TI, sentimos falta do
momento do erro. o momento de sairmos da rotina e nos motivamos para resolver os problemas
Passa-se dia aps dia no desenvolvimento em projetos de
Business Intelligence e acabamos por ficar muito focados no
processo de finalizao e entrega das tarefas. Com todo o
planejamento, acabamos por quase estar fazendo os
desenvolvimentos de uma forma automatizada. Sabemos o
que tem para fazer, como fazer e tudo mais. Quase uma
estrutura replicvel, guardadas as propores. Pois tenho as
dimenses e fact tables e, no vemos mais a dimenso como
algo extraordinrio em relao outra. Tenho atributos de
controle de verses, por exemplo, e os atributos do contedo
especfico da dimenso. Uma a uma com esta estrutura.
O mesmo acontece nas fact tables. Os atributos de controle e
depois os relacionamentos que caracterizam o fato. Claro que
os atributos de controle ficam de fora do modelo OLAP. Na
quase totalidade dos casos. Visto que o versionamento fica do
lado do Data warehouse e no da anlise dimensional e
relatrios.
Os nossos desafios comeam quando passamos a publicar os
desenvolvimentos. Normalmente nos desenvolvimentos,
tudo corre bem. Erros aqui e ali, mas trata-se de ambiente de
desenvolvimento. Com dados de desenvolvimento. E no
ambiente acima deste, j comeamos a ver a adrenalina
subir. Com um certo nervosismo para no estragar uma
estrutura que est em funcionamento e que pode afetar uma
grande quantidade de projetos tambm em testes.

Ainda nos longos projetos, muito do desenvolvimento

acaba por ser reaproveitado. Packages ETL para popular
dimenses so copiados para atender s necessidades
da dimenso seguinte. E assim vai at o final. E depois
pode ocorrer ainda com as fact tables. muito comum
encontrarmos estas situaes em projetos. Vamos
encontrar bases OLAP com 20 cubos e 100 dimenses.
realmente comum uma estrutura assim. De 20 cubos,
cada um deles com cerca de 10 fact tables.
Acabamos armazenando em um repositrio de cdigo,
as queries para uma determinada lookup, de Data por
exemplo. Que chamamos pelo menos uma vez,
obrigatoriamente, em cada fact table.
Os problemas, quando surgem movimentam toda a
equipe. Uns com mais experincias que outros e
dependendo do ambiente, o problema acaba por ser
resolvido mais cedo que voc imagina. Quando em
ambiente DEV, voc o principal interessado. E quanto
mais alto a relevncia do ambiente, os interessados na
resoluo vo aumentando em nmero rapidamente.
Alm do que, para uma publicao sempre deve ter em
conta um plano de contingncia e rollback. Na falha e se
houver necessidade real, volta-se ao que havia antes.
uma das decises que o lder deve tomar nestas
situaes mais crticas.

Na primeira execuo com erro, tentamos correr contra o tempo para logo
normalizar a situao. Em uma situao de erro no processamento de um
cubo por exemplo. Algo pode dar errado e todos os cubos daquela base de
dados OLAP ficarem com o estado de unprocessed. Muito chato e muito
comum.
o estado de prontido que adotamos e que nos mantm responsabilizados
para as operaes de correo. Que mesmo no sendo um ambiente de
Produo final, temos a responsabilidade de o manter sempre ativo. Em
semelhana com o ambiente final.
Muitos desenvolvedores pensam que o ambiente de qualificao mais
confivel que o ambiente de Produo. J que o ambiente de produo pode
conter algum workaround especfico para o bom funcionamento. E no
ambiente de Qualificao, suposto que o desenvolvimento esteja
implementado. Conforme pressuposto no projeto e como foi planejado
anteriormente.