Dados, Informaçao, Conhecimento - Business Inteligence e Suas Motivaçoes

Andr Ramos Jorge Correia
Licenciado em Engenharia Informtica
Dados, Informao, Conhecimento, o

Business Intelligence e as suas
motivaes
Dissertao para obteno do Grau de Mestre em

Engenharia Informtica
Orientador: Paulo Orlando Reis Afonso Lopes,

Prof. Doutor, FCT/UNL-DI
Jri:
Presidente: Prof. Doutor Joaquim Francisco Ferreira da Silva, FCT-UNL-DI

Vogais: Prof. Doutor Joo Miguel da Costa Magalhes, FCT-UNL-DI
Prof. Doutor Paulo Orlando Reis Afonso Lopes, FCT-UNL-DI
Setembro de 2011
Ttulo da dissertao
Dados, Informao, Conhecimento, o Business Intelligence e as suas motivaes
Copyright
Andr Ramos Jorge Correia
A Faculdade de Cincias e Tecnologia e a Universidade Nova de Lisboa tm o direito,
perptuo e sem limites geogrficos, de arquivar e publicar esta dissertao atravs de
exemplares impressos reproduzidos em papel ou de forma digital, ou por qualquer meio
conhecido ou venha a ser inventado, e de a divulgar atravs de repositrios cientficos e
de admitir a sua cpia e distribuio com objectivos educacionais ou de investigao,
no comerciais, desde que seja dado crdito ao autor e editor.
II
Agradecimentos
Pretendo atravs destas linhas expressar a minha gratido no s pela ajuda no
desenvolvimento desta dissertao, mas tambm, pela carreira que tenho vindo a
construir, a qual considero positiva.
Em primeiro lugar quero agradecer ao Professor Paulo Lopes, por me ter orientado no
desenvolvimento desta dissertao, com a boa ajuda que me deu, quer atravs de
correces assim como pelas boas ideias que me foi transmitindo, e que, me permitiram
atingir um resultado final mais rico.
Agradeo ainda aos colegas e amigos que conheci ao longo destes anos de carreira, e
que, me permitem hoje, com satisfao, disponibilizar este trabalho. Posso agradecer em
especial Novabase, onde agradeo especialmente ao Fernando Jesus e ao Joo Martins
por terem apostado em mim e pela minha evoluo, ao Armando Mendes. Na Staples,
Carla Marques, ao Pedro Pimenta, Carlos Valente e Joo Silva. E na Maven onde se
torna mais difcil agradecer a algum em especial, pois toda a estrutura funciona como
uma famlia, em que a entreajuda e a amizade base para todo o resto, ainda assim,
deixo um agradecimento especial ao Nuno Costa pela sua aposta na minha pessoa.
Por fim Neuza por sempre me ter acompanhado e ajudado ao longo destes anos de
profisso.
III
IV
N do aluno: 36085
Nome: Andr Ramos Jorge Correia
Ttulo da dissertao:
Palavras-Chave:
Inteligncia
Data Warehouse
Integrao
Relatrio
Profissional
Painel
Keywords:
Business Intelligence
Data Warehouse
Integration
Reporting
Professional
Dashboard
VI
Resumo
O objectivo deste relatrio dar a conhecer, um possvel percurso de carreira para um
aluno que na entrada no mundo profissional, se interessou por sistemas de suporte
deciso. Descrevi a minha experincia profissional desde a entrada no curso de
Engenharia Informtica e as opes que fui tomando durante e depois do curso, que
demonstram o interesse e tendncia para esta rea dentro das TI.
Assim, o facto de aps terminar o curso, ter trabalhado em diversas reas nas trs
empresas que integrei, desde o desenvolvimento aplicacional em ERP e CRM, na
definio de requisitos de arquitecturas de HW e SW, na qualidade e integrao de
dados em mltiplos sistemas e em modelos analticos, sempre em metodologias e
ambientes diversos. Esta multiplicidade de cenrios faz-me pensar que me encontro
actualmente na rea certa, o Business Intelligence.
O curso na FCT-UNL transmitiu-me entre outras, uma capacidade de adaptao ao nvel
das mais diversas tecnologias e metodologias, assim como uma grande tolerncia
frustrao, devido aos inmeros obstculos que foram sendo colocados durante o curso.
Tudo isto tem permitido ao longo da minha carreira ultrapassar as sempre difceis
tarefas a nvel tcnico, funcional e de gesto que me foram surgindo.
Dados, Informao, Conhecimento e Inteligncia um fluxo natural e uma motivao
para criar solues de Business Intelligence. O fluxo descrito deve ser seguido em
qualquer SI/TIC. No profcuo para nenhuma organizao ter dados provenientes de
inmeras aplicaes, se estes no gerarem informao que se traduza em conhecimento.
O fluxo deve ser cumprido, para que o produto final de um projecto de Business
Intelligence seja um acrscimo de conhecimento e valor para a organizao ao qual
pertence.
Espero transmitir claramente como funciona o mundo dos projectos de Business
Intelligence, as suas componentes, dificuldades e particularidades.
VII
VIII
Abstract
The purpose of this report is to demonstrate a possible career path for a student entering
in the professional world and that is interested in decision support systems. I described
my professional experience, since entering the course of Computer Engineering and the
options that I took, either during the course or after. This shows my interest and trend
for this area of IT.
So I think that after finishing the course, having the opportunity to work in various areas
in the three companies which I was integrated in. Ive done a lot, from application
development to ERP and CRM, requirements for hardware and software architectures
definition, data quality, data integration across multiple systems, analytical models and
with different methodologies in various environments. That variety of scenarios made
me believe that Im currently in my vocational area, the Business Intelligence.
The course at FCT-UNL gave me the ability to easily adapt to diverse technologies and
methodologies, as well as, a great resistance to frustration, due to the numerous
obstacles that have been placed for us during the course. All this allowed that during my
career, to always overcome difficult obstacles in technical, functional and management
areas that still arises.
The theme chosen, data, information, knowledge and its connection to building business
intelligence solutions, turns out to be a natural flow and should be followed by any
IS/TIC. It is not useful, for any organization, to have data from many applications, if
they dont generate information that can be translated into knowledge. This flow must
be fulfilled so that the end product of a Business Intelligence project turns out to be an
increase of knowledge and value to the organization which it belongs.
I hope to clearly show how does work the world of Business Intelligence projects, its
various components, and specific difficulties.
IX
ndice
Resumo ..................................................................................................................................... 7
Abstract .................................................................................................................................... 9
ndice ...................................................................................................................................... 11
ndice de Imagens .................................................................................................................. 13
Glossrio ................................................................................................................................. 15
1.
2.
Actividade Profissional .................................................................................................. 17

1.1
Novabase .................................................................................................................. 20
1.2
Staples ...................................................................................................................... 20
1.3
BIMaven .................................................................................................................. 21
Projectos mais relevantes............................................................................................... 23

2.1
Projecto de criao de interface operacional na ACSS ....................................... 23
2.1.1
Contexto ............................................................................................................... 23
2.1.2
Requisitos e Motivao ....................................................................................... 24
2.1.3
Soluo Tcnica e Execuo do Projecto .......................................................... 25
2.1.3.1
Planeamento ..................................................................................................... 25
2.1.3.2
Arquitectura Macro ........................................................................................ 26
2.1.3.3
Infra-estrutura ................................................................................................. 27
2.1.3.4
Modelo Fsico de estruturas de dados ............................................................ 27
2.1.3.5
Processos ........................................................................................................... 29
2.1.3.6
Framework de carregamento ......................................................................... 30
2.1.3.7
Processos de integrao ................................................................................... 35
2.1.4
2.2
Anlise de Resultados ......................................................................................... 35

Projecto de criao de modelo analtico na ACSS ............................................... 36
2.2.1
Contexto ............................................................................................................... 36
2.2.2
Requisitos e Motivao ....................................................................................... 36
2.2.3
Soluo Tcnica e Execuo do Projecto .......................................................... 36

XI
2.2.3.1
Infra-estrutura ................................................................................................. 38
2.2.3.2
Arquitectura Macro e modelo fsico .............................................................. 40
2.2.4
3.
Anlise de Resultados ......................................................................................... 51
Analise aprofundada do percurso profissional............................................................ 53

3.1
Iniciao - NB .......................................................................................................... 53
3.1.1
PT-Sistemas de Informao................................................................................ 53
3.1.2
ESI Espirito Santo Innovation ........................................................................ 54
3.1.3
ESCOB Esprito Santo Cobranas ................................................................. 56
3.2
Evoluo - Staples ................................................................................................... 56
3.3
Consolidao - BIMaven ........................................................................................ 58
3.3.1
BIMaven ............................................................................................................... 59
3.3.2
Media Capital ...................................................................................................... 60
3.3.3
ACSS..................................................................................................................... 61
3.3.4
Groupama Seguros .............................................................................................. 63
3.3.5
FNAC .................................................................................................................... 63
3.3.1
EFACEC .............................................................................................................. 64
3.3.1
ZON ...................................................................................................................... 64
4.
Referncias ...................................................................................................................... 65
5.
Bibliografia adicional ..................................................................................................... 67
Anexos ..................................................................................................................................... 69
1.
ODI .................................................................................................................................. 69
2.
OBIEE ............................................................................................................................. 72
2.1
Principais funcionalidades ..................................................................................... 72
2.2
Modos de visualizao ............................................................................................ 74
2.3
Criao de Indicadores ........................................................................................... 76
XII
ndice de Imagens
Figura 1 - reas Centrais de Actividade nas TI ................................................................. 17
Figura 2 - Cadeiras efectuadas durante a licenciatura da seco de SSDI ...................... 18
Figura 3 - Fases de carreira .................................................................................................. 19
Figura 4 Entidades empregadoras durante a carreira ................................................... 20
Figura 5 - Clientes por Empresa Empregadora ................................................................. 21
Figura 6 - Modelo de Alto Nvel de Integrao Operacional ............................................. 23
Figura 7 - Quadrante Mgico de integrao do Gartner Group para 2009 .................... 26
Figura 8 - Viso Macro do Projecto de Integrao ............................................................ 27
Figura 9 Infra-estrutura da soluo.................................................................................. 27
Figura 10 - Framework de carregamento a partir de RDBMS ......................................... 33
Figura 11 - Framework de carregamento a partir de ficheiros ........................................ 34
Figura 12 Infra-estrutura da Soluo do Modelo Analtico ........................................... 39
Figura 13 Arquitectura Macro do Modelo Analtico ...................................................... 40
Figura 14 - Quadrante Mgico de BI do Gartner Group para 2009 e 2010 .................... 43
Figura 15 - Framework Carregamento de Dimenses ....................................................... 48
Figura 16 - Framework Carregamento de Factuais ........................................................... 49
Figura 17 - Hierarquia de Tempo ........................................................................................ 51
Figura 18 - Arquitectura ETL vs EL-T ............................................................................... 69
Figura 19 - Design Declarativo ............................................................................................. 70
Figura 20 - ODI Operations.................................................................................................. 71
Figura 21 - ODI Hot Pluggable ............................................................................................ 71
Figura 22 - Grfico de rea .................................................................................................. 74
XIII
Figura 23 - Grfico de barras horizontais ........................................................................... 74

Figura 24 - Grfico de Barras Verticais .............................................................................. 74
Figura 25 - Grfico Linear .................................................................................................... 74
Figura 26 - Grfico de Pareto ............................................................................................... 74
Figura 27 - Grfico de Passo ................................................................................................. 74
Figura 28 - Grfico de Bolhas............................................................................................... 75
Figura 29 - Grfico de Radar ............................................................................................... 75
Figura 30 - Grfico Circular................................................................................................. 75
Figura 31 - Grfico Gauge .................................................................................................... 75
Figura 32 - Grfico Ticker .................................................................................................... 75
Figura 33 - Map Locations.................................................................................................... 75
Figura 34 - Map Prompt ....................................................................................................... 76
XIV
Glossrio
ACSS
AIX
AWK
BD
BI
BMC
BSM
CCB
CMMI
CRM
CSV
DB
DBMS
DM
DQ
DSV
DW
EBCDIC
ERP
ETL
FCT-UNL
FGAC
FTE
FTP
HP-UX
HW
ID
IMAP
iSCSI
ITIL
J2RE
JDBC
JVM
KPI
MB
MDN
MS
MS IS
MSTR
NB
Administrao Central dos Sistemas de Sade

Advanced Interactive eXecutive
Linguagem vocacionada para processamento de ficheiros de texto
Base de Dados
Business Intelligence
Empresa especializada em BSM
Business Service Management
Centro Cultural de Belm
Capability Maturity Model Integration
Customer Relationship Management
Comma-separated values
Database
Database Management System
Data Mart
Data Quality
Ambiente de Desenvolvimento
Data Warehouse
Extended Binary Coded Decimal Interchange Code
Enterprise Resource Planning
Extract, Transform & Load
Faculdade de Cincias e Tecnologia da Universidade Nova de Lisboa
Fine-grained access control
Full-Time Equivalent
File Transfer Protocol
Hewlett-Packard Unix
Hardware
Identificador
Internet Message Access Protocol
Internet Small Computer System Interface
Information Technology Infrastructure Library
Java 2 Runtime Environment
Java Database Connectivity
Java Virtual Machine
Key Performance Indicator
Megabyte
Ministrio da Defesa Nacional
Microsoft
Microsoft Integration Services
Microstrategy
Novabase
XV
OBIEE
ODBC
ODI
ODS
OLAP
OLTP
OS400
OTS
OWB
PL/SQL
Plain Text
PM
PME
POP3
PRD
PT
PT-COM
RAC
RDBMS
RFD
RFI
ROI
ROLAP
RTF
SAP
SAP BW
SCM
SI/TIC
SIG
SK
SLA
SMS
SNS
SO
SOA
SPV
SQL
SSDI
STA
SW
TCO
TELCOS
TI
TST
VB
VM
WPMS
XML
ZPL
Oracle Business Intelligence Enterprise Edition

Open Data Base Connectivity
Oracle Data Integrator
Operational Data Storage
Online Analytical Processing
On-Line Transaction Processing
SO IBM desenvolvido para o AS/400
Oracle Transactional Storage
Oracle Warehouse Builder
Procedural Language/Structured Query Language
Ficheiro com texto sequencial de fcil leitura
Project Manager
Pequenas e Mdias Empresas
Post Office Protocol
Ambiente de Produo
Portugal Telecom S.A.
PT Comunicaes
Real Application Clusters
Relational Database Management System
Request For Development
Request For Information
Return Of Investment
Relational Online Analytical Processing
Rich Text Format
System Analysis and Program Development
SAP Business Warehouse
Supply-Chain Management
Sistema de Informao/Tecnologias de Informao e Comunicao
Sistema de Informao de Gesto
Surrogate Key
Service Level Agreement
Short Message Service
Servio Nacional de Sade
Sistema Operativo
Service-Oriented Architecture
Servio Ps-Venda
Structured Query Language
Sistemas Simblicos de Deciso e Informao
Staging Area
Software
Total Cost of Ownership
Telecomunicaes
Tecnologias de Informao
Ambiente de Testes ou Pr Produtivo
Visual Basic
Virtual Machine
Warehouse Physical Management System
eXtensible Markup Language
Z-level Programming Language
XVI
1. Actividade Profissional
Iniciei o meu percurso no mundo laboral e na rea da Engenharia Informtica ainda durante a
faculdade, tendo na altura tentado aproveitar todos os conhecimentos que j trazia e os que fui
adquirindo numa perspectiva de utilizador. Ainda assim, este incio no teve qualquer relao com
aquela que acabou por vir a ser a minha rea central de actividade dentro das TI, o Business
Intelligence.
Figura 1 - reas Centrais de Actividade nas TI
A figura 1 representa de forma integrada as minhas reas de actuao actuais e que circulam em volta
da rea de Business Intelligence. Assim dentro da sequncia apresentada tenho:
As RDBMS, utilizada na maioria dos projectos, entre elas, Oracle [1], MS SQL Server [2],
Teradata [3], Sybase [4], DB2 [5] AS400 1[6], etc
A OLTP, parte integrante da maioria dos projectos como fonte de extraco de dados ou em
alguns como destino.
Minicomputador IBM com arquitectura EBCDIC, actualmente substitudo pelos iSeries
17
Os processos de Integrao que denomino como ETL, e que, estiveram presentes em quase a
totalidade dos projectos. Embora desde h alguns anos exista sempre uma tendncia para os
designar com esta sigla, cada vez far menos sentido faz-lo, pois comeam a existir vrias
abordagens dspares e que no obedecem mesma ordem nas operaes.
Os DW, que so objecto de todo o trabalho de modelao de base so grandes desafios. Estes
esto sempre presentes nas grandes organizaes e comeam a fazer parte de algumas PME.
Os modelos OLAP com todas as variantes existentes e que foram parte integrante de muitos
projectos, tais como com o Microstrategy, o OBIEE e o Discoverer.
Toda a camada de reporting e dashboarding assente no modelo OLAP pr-definido utilizando
ferramentas como Microstrategy, o OBIEE e o BI Publisher.
Considero importante mencionar que de alguma forma existiu uma influncia clara nas opes que
efectuei durante a licenciatura na escolha do meu percurso. Relativamente s disciplinas opcionais
que ento elegi, demonstrei apetncia para a seco central que refiro na figura 2, a SSDI.
A figura 2 d a conhecer as cadeiras que efectuei da seco de SSDI [8]. Nos crculos vermelhos esto
referidas as que eram obrigatrias no plano curricular, nos crculos verdes as que escolhi como
opcionais. O projecto final est num crculo de cor amarela, pois embora seja obrigatrio dentro do
plano curricular, o seu contedo acaba por ser opcional, e tambm aqui, a minha opo acabou por
recair naquele que foi o meu primeiro projecto de Business Intelligence.
Figura 2 - Cadeiras efectuadas durante a licenciatura da seco de SSDI
De seguida apresento o resumo do meu percurso dentro da Engenharia Informtica.

Iniciei a minha actividade, ainda durante o curso, no apoio a vrias empresas e particulares presentes
em vrios sectores de actividades, realizando as seguintes tarefas, entre outras:
Montagem de mquinas e storage;

Instalao e configurao de sistemas operativos MS-DOS, Microsoft Windows e Linux;
Instalao e configurao de inmero software necessrio na rea de actividade de cada
cliente desde SW de restaurao, contabilidade e arquitectura;
18
Desenho de redes e instalao das mesmas, desde a passagem de cablagem entre divises;
acoplagem de fichas Ethernet RJ45. Instalao de Switch e Routers e sua posterior
configurao;
Gesto de sistemas distribudos de storage e impresso em redes Microsoft [9] e Novel [10] ;
Reparao de mquinas.
Este processo anterior ao trmino do curso de Engenharia Informtica deu-me uma noo muito
importante do funcionamento das mquinas e reconhecimento dos problemas de instabilidade no seu
comportamento, do cuidado a ter com os equipamentos com os quais efectivamente necessrio ser
previdente e assim evitar problemas directamente associados ao HW. Para alm disso conheci vrios
SO e tambm a forma de interagir com o seu core o que, me ajuda ainda hoje na forma como abordo
um sistema que me desconhecido.
Durante o ano de 2004, quando estava na fase final do curso na FCT-UNL procurei fazer o trabalho
final numa empresa da rea das TI, particularmente na Consultoria. Isto deveu-se ao facto do meu
objectivo ter sido sempre trabalhar no meio empresarial e principalmente ao ser consultor, poder ter
acesso a inmeros tipos de actividades e negcios e aprender um pouco sobre cada um deles. Assim,
quando surgiu como hiptese na lista de estgios propostos entrar na NB, uma empresa de renome no
s a nvel nacional mas tambm internacional, resolvi propor-me para o mesmo.
Aps uma entrevista e analisadas as candidaturas, fui aceite e iniciei o meu estgio numa empresa do
grupo que apostava especificamente numa rea em que eu sempre procurei estar colocado, e que,
ainda hoje me continua a fascinar, pelo que possvel produzir, o BI.
Aquilo que sempre me interessou no BI foi a capacidade de pegarmos num amontoado de sistemas
que habitualmente existem nas organizaes, seleccionarmos e consolidarmos a informao que
realmente importante para coordenar os objectivos e decises estratgicas das mesmas. No fundo,
acabamos por ter um papel fundamental nas intervenes que levamos a cabo, seja em alturas de
prosperidade econmica aquando os mercados so mais exigentes e esperam ndices elevados de
rendimento e rentabilidade na sua produo ou ainda nas alturas de crises financeiras que por questes
de sobrevivncia muito importante conhecer a realidade da organizao que gerimos.
Assim, este primeiro projecto - o Basileia II2, foi fundamental para perceber como poderia intervir
concretamente a nvel do negcio de uma grande organizao. Esta verso do acordo cuja entrada em
vigor aconteceu em 2007 permitiu s entidades financeiras um conhecimento mais profundo dos seus
clientes. Foi esta vantagem competitiva que passou a permitir-lhes medir o grau de risco associado a
cada cliente. Esta informao uma mais-valia nas suas operaes dirias, sendo que para a poder
atingir ser necessrio possuir um repositrio contendo o histrico das suas operaes, alm de
informao adicional proveniente de fontes externas, de modo a posteriormente estimar os diversos
riscos presentes em cada operao.
Aps cumprir o projecto de final de curso, fui convidado para integrar os quadros da NB. Daqui em
diante consigo dividir a minha carreira em 3 fases, que coincidiram com os momentos de transio
para novas entidades empregadoras, dando origem a um novo conjunto de desafios e
responsabilidades.
Assim o meu percurso ter seguido as seguintes fases:
INICIAO
EVOLUO
CONSOLIDAO
Figura 3 - Fases de carreira
O Acordo de Capital de Basilia II, foi um acordo assinado no mbito do Comit de Basileia em 2004 para
substituir o acordo de Basileia I. Este consiste em 3 pilares (Capital, Superviso, Transparncia e Disciplina de
Mercado) e 25 princpios bsicos sobre contabilidade e superviso bancria.
19
Estas fases tero coincidido em termos temporais:
Figura 4 Entidades empregadoras durante a carreira
1.1 Novabase
Como consultor na Novabase [11] Business Intelligence assumi desde o incio o papel de Analist &
Developer. Isto permitiu-me, devido complexidade e versatilidade exigidas, desenvolver fortemente
a componente tcnica nas reas de Modelao de dados para DW, desenvolvimento de processos ETL
e conhecimentos especficos de componentes de reporting.
A experincia na consultoria permite uma facilidade na compreenso dos problemas e requisitos
apresentados pelos diversos clientes, assim como a necessidade destes obterem solues de qualidade,
sempre com pensamento na evoluo dos sistemas.
1.2 Staples
Aps a sada da Novabase seguiu-se uma experincia numa vertical na rea do Retalho.
Na Staples [12] trabalhei no seu Head Office embora por vezes fizesse projectos especficos para lojas
que me solicitavam a deslocar-me s mesmas. Foram-me atribudas novas funes tendo sido possvel
atingir um maior conhecimento da interaco de todos os sistemas e conhecer on field todo o fluxo de
passagem de informao. Desde os POS nas lojas passando pelas interfaces de integrao especficas
nas RDBMS dos sistemas aplicacionais mais bsicos, a integrao no ERP, CRM, e por fim nos
modelos analticos.
Na Staples acabei por ter uma interaco diferente da que conhecia com fornecedores de Sistemas,
Produtos e Hardware. Estava no papel de comprador e no de vendedor e a minha viso mudou
radicalmente na anlise das necessidades dentro de uma organizao. As minhas responsabilidades
consistiam agora na definio e especificao de requisitos, disponibilizao de ambientes de DSV e
TST e efectuar testes e validar as solues. Mais tarde aquando do meu regresso a Consultoria
considero que esta ter sido umas das grandes mais-valias de ter trabalhado numa vertical,
compradora de recursos externos. Pois quem s trabalhou como consultor, no tem noo de qual o
papel desempenhado pelos elementos que mantm os SI de uma organizao. Hoje, e aps ter
assumido tais funes penso que atingi maturidade na relao com os SI dos clientes com os quais
tenho de lidar.
Outra inovao foi o conhecimento no desenho de novas solues end-to-end. Aprendi a combater e
acompanhar as restries naturais deste tipo de solues, que surgem seja por questes de gesto a
vrios nveis, como sejam budget, espao ou necessidades inerentes prpria estratgia da
organizao, a mdio ou longo prazo.
Consegui alavancar os meus conhecimentos, e, assim ter uma noo mais prxima da realidade da
relao entre o ROI e a gesto de necessidades em termos de timeline.
20
1.3 BIMaven
Com o regresso Consultoria, integrei a BIMaven Consulting [13] a partir de Dezembro de 2008.
Uma startup que tinha arrancado com a sua actividade em 2007 e cujo core era o BI. Em termos de
nvel de carreira assumi imediatamente as funes de Senior Consultant.
O meu contributo at a actualidade focou-se em vrias tecnologias no mundo do Business Intelligence
e Integrao de dados, sendo que em termos de rea de negcio embora tenha passado por vrias
reas, em termos temporais centrou-se na Sade. Um dos objectivos que me foi proposto foi arrancar
e fazer crescer uma parceria com a Oracle na sua rea de Middleware, uma vez que at ento no
estaria deliberadamente a ser potenciado o negcio ou projectos directamente com estes.
Figura 5 - Clientes por Empresa Empregadora
21
22
2. Projectos mais relevantes

2.1 Projecto de criao de interface operacional na ACSS
2.1.1
Contexto
Este projecto tinha como principal objectivo a criao de uma nova interface para um sistema
transaccional. Esta interface funcionava entre aproximadamente 80 repositrios externos alimentados
por uma aplicao criada em Oracle Forms, e um repositrio central.
Assim, a tecnologia utilizada, as Stored Procedures em PL/SQL iria ser substituda por uma
ferramenta visual de integrao, o ODI, por forma a garantir o controlo e automatismo total no
processo de carregamento e, consequentemente o mnimo de interveno humana possvel.
Instituies
OLTP
Corporativo
BD Central
Carregamento automatico ao N dia de cada ms
Instituies
Processo
Manual
Extraco OLTP
Stand-Alone
File
Transfer
ODS
Carregamento automatico ao
N dia de cada ms
Repositrio
PrDefinido
Figura 6 - Modelo de Alto Nvel de Integrao Operacional
Os automatismos criados deveriam permitir um aumento de produtividade, libertando assim as

equipas de manuteno de tarefas rotineiras e consumidoras de tempo, proporcionando a possibilidade
de se focarem noutras mais de acordo com as suas funes.
Esta uma interface crtica para a organizao, pois o repositrio central, destino deste processo de
carregamento, passou a ser fonte de um sistema analtico, o que obrigou a um maior controlo da
qualidade e disponibilidade da informao a ser carregada devido a necessidade de maior consistncia
da informao, fiabilidade e integridade.
Em termos do que foi proposto, as caractersticas do novo processo foram:
Funcionamento de forma totalmente automtica inclusive na gesto de falhas;
Qualquer interveno humana, quando necessria, seria solicitada. Isto garantia a no

alocao de pessoas ao controlo durante o tempo em que decorresse o processamento;
23
Criao de uma framework de controlo de processos comum a todos os projectos gerados na

nova ferramenta de integrao. Esta consistia na criao de tabelas de Log dos processos na
contagem de extraces e carregamentos;
Gesto automtica de registos rejeitados com a gerao de mensagens de aviso;
Controlo de falhas e erros ao longo de todo o processo;
Utilizadores com login de acesso especfico, aos quais s seriam permitidas determinadas
tarefas na ferramenta de integrao, tais como, controlarem a actividade na execuo dos
processos. Passou a ser possvel manter um elevado nvel de segurana no acesso
informao que iria ser processada, os Audit-Trails.
2.1.2
Requisitos e Motivao
O modelo operacional apresentava-se limitado, no tanto pela sua configurao, mas essencialmente
pelas tecnologias envolvidas, neste caso o scripting PL/SQL Oracle com Stored Procedures.
A integrao atravs de scripting habitualmente olhada como uma soluo simples, barata, rpida e
ao alcance de todos. Mas esta viso est comprovada como sendo errada, quer atravs dos custos de
manuteno a longo prazo ou do facto de no ser fcil reutilizar o cdigo gerado. A complexidade dos
processos de integrao, que actualmente so sujeitos a SLAs relacionados com a disponibilidade e
alta qualidade da informao, onde se exige uma metadata robusta, tambm no se coaduna com esta
opo. O scripting alm de extremamente inflexvel resulta habitualmente em redundncia de
processos, recursos subaproveitados e custos elevados habitualmente ligados a infra-estruturas,
desenvolvimento, suporte, manuteno e gesto.
Em termos de requisitos, neste projecto existiam os seguintes:
Substituir o processo antigo onde eram utilizados scripts PL/SQL Oracle, ou seja, uma
tecnologia utilizada de difcil manuteno. Esta obrigava a intervenes demoradas sempre
que se revelava necessrio efectuar alguma alterao ou correco;
A ferramenta de integrao escolhida teria que poder aceder a BD Oracle 7.3, visto serem
estes os repositrios operacionais que seriam fontes do processo;
A ferramenta de integrao escolhida teria que gerar alertas e avisos relativos ao

processamento atravs do envio de mails. Para isso seria necessrio a garantia de que o
servidor onde a ferramenta de integrao se encontrasse, tivesse acesso ao servidor de mail,
para poder gerir o envio de mails despoletados pelos processamentos.
Solucionar a integrao da informao que no podia ser por via DB-Link. Devido ao facto de
provir de diferentes aplicaes que era recebida em ficheiro, convertida manualmente com
Access e s posteriormente carregada.
Em termos de motivao, havia inmeras vantagens nesta nova soluo, tais como:
Eliminar ao mximo a interveno humana na totalidade da execuo e monitorizao dos

processos, dispensando o processo de carregamento de ser efectuado por tcnicos com um
conhecimento profundo;
Optimizar o processo de validao da informao carregada para ser efectuado apenas no

final do carregamento. Esta questo criava grandes perdas de tempo devido ao facto de que
sempre que fosse detectado algum erro, s o seria no final do processamento, o que por vezes
obrigava a reprocessamentos totais ou parciais;
24
Controlar e tratar os erros resultantes do processo, dado que este era rudimentar e pouco
abrangente. No existiam estruturas de logging durante a execuo, apenas contagens de
registos carregados no final do processamento;
Incrementar a controlo nos acessos a BD ou nas operaes sobre a mesma, eliminando

vulnerabilidades relativas informao existente no repositrio central.
2.1.3
Soluo Tcnica e Execuo do Projecto
2.1.3.1 Planeamento
Para iniciarmos o projecto criei um plano no MS Project onde referi todos os pr-requisitos
necessrios para o arranque do mesmo. Defini que iriam existir 3 ambientes de BD e 3 aplicacionais,
o de Desenvolvimento, o de Testes ou Pr-Produo e o Produtivo. Esta metodologia que havia
seguido em outros projectos e clientes proporciona normalmente maior qualidade nos deployments em
produo.
Os ambientes tm os seguintes objectivos:
Ambiente de DSV, onde feita a criao, explorao e testes unitrios;

Ambiente de TST, onde fazemos os chamados testes funcionais, performance e integrao.
Utilizam-se dados provenientes de PRD, como excepo, devendo-se por questes de
segurana dos dados ou de confidencialidade da informao contida criar dados de teste
mascarados e com as condies exigidas pelas novas especificidades.
Ambiente de PRD, onde so efectuados os testes de aceitao, fazendo com que o produto
passe a PRD com um risco mnimo e garantia de utilizao imediata.
Tendo em conta que o projecto foi totalmente desenvolvido nas instalaes do cliente, foi efetuada
uma preparao a nvel dos pr-requisitos para arranque, entre estes:
Disponibilidade do servidor de integrao instalado e configurado com acesso a todos os

utilizadores de BD necessrios. Era um processo que em termos de ambientes tinha uma
janela de tempo que ia acompanhando o mesmo, ou seja no arranque do projecto apenas se
exigia o ambiente de Desenvolvimento nas condies descritas;
Carregamento de informao proveniente de uma das fontes operacionais nos trs ambientes;
Acesso a todas as fontes operacionais.
Antes de iniciar a descrio sobre os desenvolvimentos e a infra-estrutura vou explicar a razo pela
qual a ferramenta de integrao escolhida foi o ODI em detrimento de muitas outras disponveis no
mercado. A Oracle era um lder no Quadrante Mgico da Gartner de Ferramentas de Integrao[14]
em 2009. O que cabea podia ser suficiente por parte do cliente para fazer esta opo mas a
principal razo foi a conectividade a BD Oracle 7.3, isto porque todas as fontes operacionais do
processo tinham esta verso de BD, esta situao condicionava logo a cabea a escolha embora claro
existisse concorrncia, como o Informatica Power Center, lder no quadrante referido. Ainda assim o
ODI apresenta algumas caractersticas prprias que o distingue da restante oferta do mercado e que
esto descritas, no anexo nomeado ODI, as que considero estarem directamente ligadas com o
desenvolvimento deste projecto.
25
Figura 7 - Quadrante Mgico de integrao do Gartner Group para 2009
A componente de logging e gesto do processo tambm teve que ser criada neste projecto com o
objectivo de ser genrica e transversal a todos os projectos desenvolvidos em ODI. S assim
conseguiramos tirar partido total do investimento na tecnologia, potenciando assim a sua utilizao
no futuro em novos projectos e inclusive em outra reas, Esta abordagem considerada uma maisvalia no panorama das best pratices dos projectos de integrao dentro de uma organizao.
2.1.3.2 Arquitectura Macro

Assim, em termos de arquitectura macro, a soluo apresentada em seguida. Existem inmeras
fontes operacionais, na sua maioria RDBMS Oracle 7.3 e as restantes a partir de ficheiros extrados
com uma estrutura igual s tabelas provenientes das RDBMS.
26
Servios Centrais
BD Central Oracle 10g
Integrao com ODI
BD Oracle 7.3
1
BD Oracle 7.3
2
BD Oracle 7.3
3
Extraco
N+1
Extraco
N+2
Extraco
M
BD
Desconhecida
N+1
BD
Desconhecida
N+2
BD
Desconhecida
M
Fontes Externas
Figura 8 - Viso Macro do Projecto de Integrao
2.1.3.3 Infra-estrutura
Para este projecto utilizmos trs mquinas, a infra-estrutura em termos de Hardware era
desconhecida por mim e por esta razo, apenas posso apresent-la ao nvel de Software:
FONTE
FTP/ FILE SERVER
DESTINO
ETL
Servidor Integrao
BD Oracle 10g
LOGGIN
Metadata ETL (ODI)
G
ODI 10.1.3
AIX 5.3 (32bit)
J2RE 1.5
Servidor Integrao
BD Oracle 10g
Metadata ETL
CONTROL
(ODI_CTRL)
ODI 10.1.3
AIX 5.3 (32bit)
J2RE 1.5
BD Central
RDBMS Oracle 10g
SUN OS
16 GB RAM
4 CPU
Figura 9 Infra-estrutura da soluo
2.1.3.4 Modelo Fsico de estruturas de dados

Quanto ao modelo fsico, neste projecto era constitudo por 3 componentes perfeitamente distintos, a
saber:
RDBMS Oracle 7.3

Esta era a fonte operacional do processo de integrao. Foi disponibilizado um utilizador de
BD ao qual poderamos ter acesso via JDBC utilizando o conector especfico do ODI. A nica
necessidade aqui seria o pedido a cada uma das instituies onde se encontravam estas
RDBMS, de abertura na sua rede da porta 1521 a qual o ODI necessita para poder aceder ao
27
agente que contem a configurao para o utilizador de BD destino. Este utilizador tinha uma
estrutura pr-definida em termos de tabelas e no poderia ser alterado enquanto decorressem
os desenvolvimentos no projecto.
A informao era disponibilizada nestas fontes at um dia pr-definido de cada ms e nesse
dia a interface de carregamento era despoletada efectuando uma sequncia de validaes de
forma a determinar se era possvel fazer o carregamento e s aps estas era ento iniciada a
extraco da informao.
Estrutura de ficheiros CSV em Plain Text.

Eram disponibilizados mensalmente e atravs de mail um grupo de ficheiros com uma
estrutura pr-definida que iam sendo colocados numa determinada data, num directrio
especfico, na mquina onde se encontrava o servidor de integrao. Existia um directrio na
respectiva rvore que era adjudicado ao projecto, sendo que neste foram criadas directorias
especficas nomeadas com a sigla da organizao que enviava os ficheiros. Este processo
tinha aqui uma componente manual na qual era necessrio associar o elemento humano para a
cumprir todos os meses. Este teria que descarregar os ficheiros de um mail especfico e
posteriormente via FTP transferir os mesmos para o directrio pr-definido. Esta foi a nica
tarefa manual que ficou associada ao projecto, devido no s ao facto de este ser um processo
alternativo e com um grau de utilizao baixo, relativo integrao por JDBC como tambm
por motivos organizacionais. Foi proposto como alternativa a este processo a utilizao da
task do ODI nomeada ODIREADMAIL, que permitia atravs dos protocolos POP3 ou IMAP,
a recepo e tratamento de mails e de todas as suas componentes
Neste caso iriamos utilizar o subject do mail, como identificador da instituio, para criarmos
o directrio onde seriam colocados os ficheiros que estavam em attachmment. O referido
directrio encontrava-se na mesma mquina fsica, ou seja no servidor de integrao. Aps
efectuada esta tarefa as posteriores aces correspondem s descritas anteriormente.
RDBMS Oracle 10G

Tirando proveito deste projecto, foi decidido fazer a migrao de Oracle verso 8i.
Foi feito um processo de export da RDBMS 8i e posteriormente um import para a 10G, com o
objectivo de disponibilizar a informao necessria para o desenvolvimento do projecto. Pelo
facto de s existir um ambiente, este foi utilizado para desenvolvimento, testes e no final do
projecto passou a produtivo. Esta migrao de verses de BD constituiu tambm uma forma
de termos um ambiente dedicado para o projecto.
Seguindo metodologias de desenvolvimento de projectos de integrao nos quais participei
anteriormente, foram criados nesta RDBMS dois utilizadores, um para o ODS, e outro, o
destino final dos processos de integrao. A vantagem da criao de um ODS reside no facto
de um utilizador de BD estar dedicado a esta tarefa especfica de recepo de informao.
Numa RDBMS Oracle, a tarefa menos consumidora de tempo e recursos de mquina a
insero de dados. Tendo em conta que num processo de integrao com entidades externas
existem limitaes temporais para a concretizao da operao de recepo de informao,
precisamos de um processo o mais leve possvel para a mquina em utilizao. Desta forma,
diminumos o impacto nos canais de comunicao utilizados e nas regras de gesto da prpria
rede. Existem regras em organizaes que no permitem a abertura de conexes externas e
muito menos por tempos indeterminados com mquinas especficas. Assim as boas prticas
sugerem que num ODS o acesso quando efectuado a uma determinada estrutura deve ser o
mais clere possvel. A operao de insert, em termos da segurana lgica da BD actua de um
modo transparente para a ferramenta de integrao. Esta vai gerar um Lock sobre a estrutura
onde estiver a inserir, e durante o tempo em que decorre a operao. Quando feito o unlock,
as outras operaes que estiverem na fila para serem efectuadas vo aceder a BD e assim,
colocar o menor peso nos recursos da mquina.
Em termos das estruturas destino e pelo facto da volumetria de dados ser elevada optamos por
uma soluo de particionamento das tabelas a carregar. A deciso de particionar ou no uma
tabela deve-se essencialmente a questes de performance. O conceito de particionamento
numa tabela um conceito lgico, o que significa que no utilizador de BD vamos ver apenas
28
uma tabela mas em termos fsicos e na gesto da prpria RDBMS vo existir tantas tabelas,
quanto o nmero de parties e subparties que sejam criadas para a mesma. Esta
operao vai permitir alocar parties em tablespaces que inclusive podero ser colocados em
storages diferentes o que vai constituir numa grande ajuda na gesto deste e vai resultar num
incremento de performance.
Na escolha das chaves de partio, optamos na sua maioria por chaves compostas contendo a
instituio e o ano aos quais a informao respeitava. A razo prende-se com o facto de
termos informao com cerca de 20 anos e referente a um total aproximado de 80 instituies.
Relativamente indexao, na gesto da BD Oracle e ao nvel do particionamento, nas
verses posteriores a 10G deixou de ser necessria a criao de ndex para as chaves de
partio, porque na criao desta est associada a operao de criao do ndice. Assim sendo
a prpria BD vai gerir e actualizar este sempre que forem adicionadas ou removidas parties.
2.1.3.5 Processos
Este processo de integrao tinha algumas particularidades, entre elas:
Existncia de registos de substituio nos carregamentos. Ou seja, existiam registos com uma
chave que se encontrava integrada e com a entrada de um novo registo com a mesma chave
iria provocar a sua substituio. Para este processo ser limpo na viso de quem recebe, de
forma a manter a integridade da informao, esta era enviada uma estrutura com cdigos que
deviam ser eliminados do utilizador de BD Central.
Este processo, de forma a no impactar com o de carregamento era executado antes do
mesmo. Assim todos os registos que deviam ser eliminados eram marcados neste passo, e
aquando do processo de carregamento estes j teriam sido eliminados, no sendo gerados
problemas de integridade no sistema.
Num SI, existem utilizadores a quem dada autorizao para criar, ler, actualizar e apagar.
Assim, foram criadas regras especficas do lado das fontes do processo, para que, fosse
possvel do lado de quem apenas queria ler a informao saber, se a poderia carregar. Isto
significa que o delta [15], referente ao ms em questo, teria que estar fechado e a informao
disponibilizada sem problemas.
As estruturas fonte e destino do ODS eram exactamente iguais, com a nuance de ser includo
do lado do ODS um nico campo adicional onde era colocada a data de processamento, e que,
iria servir de base no decorrer do mesmo. A validao efectuada no arranque do processo
referia-se a uma estrutura de logging do lado da fonte Oracle 7.3, que havia sido criada para
consultas por parte das interfaces de leitura. Nesta existia apenas um campo (flag) que referia
se a informao estava correcta e estabilizada, se poderia ser carregada ou ainda se deveria
abortar imediatamente o processo. Esta flag era validada no arranque do processo.
A situao descrita refere-se a uma problemtica que experienciei em vrios projectos
semelhantes, e que est relacionada com a definio de responsabilidades aquando da criao
de novas interfaces entre sistemas, principalmente quando os seus owners so distintos. A
best pratices neste sentido, e pelas quais sempre me regi , que quem chega tem que se
adaptar ao ambiente j existente, isto sempre dentro de um bom senso. Trata-se de uma
questo que no tem a ver tanto com engenharia informtica mas com um cdigo
deontolgico. Por vezes por abusos de poder, estas questes so ultrapassadas sem qualquer
rigor ou lgica e o resultado habitualmente , instabilidade causada no s nos novos sistemas
como ainda nas suas fontes.
No significando que no possam existir adaptaes por razes de necessidade de nova
informao ou at de formatos na informao transferida mas esta situaes devem
habitualmente ser vistas como excepcionais, assim diminumos ao mximo os riscos inerentes
ao projecto para que decorra com sucesso. Por esta razo devem ser evitadas todas as
variveis nas quais o controlo no esteja totalmente do lado de quem est a realizar a nova
implementao.
29
Este processo executado todos os meses e totalmente modular ao mais baixo nvel de
granularidade. Desta forma sempre possvel, em caso de falha em qualquer ponto,
reexecutar o processo a partir da e no na totalidade. Estes pontos de reexecuo foram
escolhidos de acordo com a sequncia global do processo e das dependncias existentes. Isto
significa que antes de executar um package vo ser verificadas as condies para o arranque.
Esta validao feita em concordncia com os seus precedentes. Assim em caso de falha de
qualquer um dos seus precedentes, o package no estar em condies de ser executado.
2.1.3.6 Framework de carregamento

Todos os processos de carregamentos tiveram como base uma framework especfica, por onde se
regeu todo o fluxo de cada processo. Tratou-se de uma framework que desenhei com base na
experincia que fui acumulando ao longo de vrios processos de integrao em que participei e com
alguma informao que fui recolhendo na Web sobre esta matria.
A experincia acumulada neste tipo de processos de integrao transaccional ocorreu principalmente
na Staples onde lidei vrias vezes com problemticas nos processos de night e day run. Dependendo
da forma como vai ser feita a integrao, as frameworks definidas tm que ser adaptadas forma
como interagem com a informao e tambm, dependendo das RDBMS que estiverem em causa. Para
este projecto criei duas verses, uma para carregamento utilizando como fonte as estruturas de uma
RDBMS e outra para utilizar como fonte, ficheiros Plain Text.
Qualquer das frameworks criada inclui a framework de controlo de processos em comum. Esta
genrica para todos os processos gerados, e est disponvel num repositrio central onde se encontra
toda a metadata3 do ODI. Atravs desta ltima, foi construdo o controlo do fluxo dos vrios
processos e respectivas interdependncias, e ainda a gerao de mensagens de erro, que so escritas
em tabelas de logging e posteriormente utilizadas na criao de mails informativos para os gestores do
processo.
A Framework para carregamento a partir da RDBMS pode ser visualizada na figura 10 e consiste nos
seguintes passos:
1. feito um delete s tabelas da STA por Instituio a carregar;
2. Existem dois tipos de tabelas disponveis, as que constituem o universo de informao a ser
carregada, na forma de delta de carregamento, e as que contm os episdios a serem
eliminados de toda a estrutura operacional. O conceito de delta de carregamento a nova
tranche de dados adicionais a serem introduzidos na BD limitados inferior e superiormente
por data;
3. A partir das RDBMS das fontes e num utilizador destinado apenas a leitura de interfaces
efectuado o carregamento directo das tabelas com a mesma nomenclatura relativamente a
STA, onde vamos centralizar a informao. Este carregamento ser efectuado atravs de
operaes de leitura e escrita directa sem efectuar qualquer tipo de transformao. Assim
viabilizamos a mxima performance na leitura BD das Instituies e o mnimo tempo
possvel para os integrar.
4. O processo subsequente tem como fonte a tabela com os registos a eliminar. Esta tabela
contm as chaves a partir das quais podemos seleccionar os registos que sero eliminar. A
partir das chaves definidas, feito um update para marcao dos registos a eliminar;
5. No passo anterior os registos foram marcados, e so agora copiados para as respectivas
tabelas de histrico. Tabelas que tm a mesma estrutura que as de destino do processo
operacional, excepto na incluso do campo correspondente data de remoo, e na
nomenclatura do seu nome onde foram prefixadas por REM_;
6. Neste passo vamos eliminar das tabelas finais os registos marcados para eliminar no passo 4
atravs de um processo de delete por chave de instituio e indicador de remoo;
3
Dados acerca de um ou vrios aspectos dos prprios dados.
30
7. Agora so aplicadas todas as regras de transformao e integridade efectuando o

carregamento a partir das tabelas do ODS para o seu schema final. Este processo teve em
paralelo validaes onde todos os registos que no estivessem em conformidade com as
regras definidas sero inseridos com o respectivo cdigo de erro nas tabelas com o mesma
nomenclatura que as de origem mas prefixadas com ERR_. Com isto, aps o trmino do
processo e a partir das tabelas prefixadas com ERR_ ser fcil analisar problemas na
integridade da informao ou do prprio processo;
8. Neste processo, feita uma comparao entre a informao que est pronta para sair da STA
e entrar nas tabelas finais. Nesta fase, a partir da data de processamento, em cada nova
insero ser actualizado o campo de data de insero e de alterao ou update;
9. Aps o final do processo de carregamento e quando confirmado que decorreu bem, sero
eliminados os registos existentes nas tabelas fonte ao processo.
A Framework para carregamento de ficheiros pode ser visualizada na figura 11 e consiste nos
seguintes passos:
1. Aps serem recebidos por email proveniente de cada instituio, o envio dos ficheiros
efectuado via FTP para uma pasta especfica com o nome da instituio e a partir da qual
foram enviados. Esta directoria est fisicamente localizada no servidor de integrao. De
referir que os ficheiros a ser carregados tm a mesma estrutura das tabelas onde agora sero
inseridos.
2. efectuado um delete, utilizando como chave a instituio a carregar, em todas as tabelas do
ODS que sejam destino de carregamento dos ficheiro.
3. A partir dos ficheiros provenientes das Instituies, efectuado o carregamento das tabelas
com a mesma nomenclatura no ODS. Este carregamento efectuado atravs de mapeamento
directo e sem efectuar qualquer tipo de transformao, garantindo com isto a mxima
performance na insero dos registos. Existe um valor acrescentado em seguir esta
metodologia pois assim no precisamos de passar por um servidor para efectuarmos
transformaes nos dados, estes podem ser carregados a partir dos ficheiros directamente para
o seu RDBMS de destino.
4. O processo subsequente tem como fonte a tabela com os registos a eliminar. Esta tabela
contm as chaves a partir das quais seleccionamos os registos a eliminar. A partir destas,
feito um update para marcao dos registos a eliminar.
5. Os registos a eliminar marcados so agora copiados para as respectivas tabelas de histrico,
que tm uma estrutura igual s de destino do processo operacional, exceptuando na incluso
do campo correspondente data de remoo e na sua nomenclatura, onde so prefixadas por
REM_
6. Neste passo vamos eliminar das tabelas finais os registos marcados para eliminar no passo 4,
atravs de um processo de delete por chave de instituio e indicador de remoo.
7. Aplicando todas as regras de transformao e integridade efectuado o carregamento a partir
do ODS nas restantes tabelas destino. Todos os registos que no estejam em conformidade
com as regras definidas, desde que no seja registado erro na validao de nulidade da sua
chave primria, sero inseridos com o respectivo erro nas tabelas. Assim como, nas tabelas
com o mesmo nome mas prefixadas com ERR_, mas aqui incluindo o cdigo identificador
do erro detectado. Aps o trmino do processo e a partir das tabelas prefixadas com ERR_
fcil analisar problemas que tenham ocorrido no processamento.
8. Neste processo feita uma comparao entre a informao que est pronta para sair da STA e
entrar nas tabelas finais. Nesta fase, a partir da data de processamento, em cada nova insero
actualizado o campo de data de insero e de actualizao ou update.
9. No final do processo e aps confirmao de que o mesmo decorreu sem problemas
efectuado um processo de compresso e cpia dos ficheiros que foram fonte de
processamento, para um directrio no mesmo servidor que serve para manter o histrico dos
ficheiros carregados. A nomenclatura dos ficheiros guardados tem como prefixo o cdigo da
31
instituio qual pertencem e, no sufixo, a data de processamento. Todo este processo

efectuado por Shell Script 4Unix 5 e invocada via ODI.
A Framework de controlo de processos foi criada com o objectivo de ser genrica para todos os
processos desenvolvidos em ODI. A hierarquia pensada contempla um objecto que representa um
projecto global que contem vrios processos, representando os package ou interfaces do ODI a serem
invocados. Cada processo poder estar presente em vrias execues. Para dar suporte a esta
framework, foram criadas as seguintes estruturas:
4
5
CTRL_ACTION Aces a serem despoletadas de acordo com os erros gerados;

CTRL_DEPENDENCIES - Gere as dependncias entre processos;
CTRL_ENTITY Informao respeitante s entidades envolvidas num projecto;
CTRL_ERROR Informao referente a erros gerados em cada processo;
CTRL_EXECUTION Controla a execuo de cada processo e guarda todas as variveis e
parmetros necessrios boa execuo do mesmo;
CTRL_EXTRACT_LOG Log relativo a extraces de origens externas ao projecto;
CTRL_HOLIDAYS Informao relativa a dias de no utilizao do sistema destino;
CTRL_LOAD_LOG Log relativo a inseres no sistema destino;
CTRL_MSG - Controlo e criao de mensagens no processo para envio por email ou SMS;
CTRL_PROCESS Guarda todo o histrico de execuo e reexecuo de cada processo;
CTRL_PROJECT Informao sobre o projecto;
CTRL_SESSION Informao de controlo de sesses. Especfico para projectos de ODI;
CTRL_STATUS Status do projecto;
CTRL_STORAGE Controlo de storage disponvel por projecto e entidade;
CTRL_TIME_WINDOW Possveis dias de execuo por semana.
Linguagem scripting directamente aplicada no SO

Sistema Operativo Multitarefa e Multi-Utilizador original da Bell Labs
32
Start_Process
INSTITUIO
TABELA_FONTE
ODI_CTRL
TABELA_ELIMINADOS
Dia N
Dia N
CTRL_EXTRACT_LOG
ODS
CTRL_DEPENDENCIES
CTRL_SESSION
CTRL_TIME_WINDOW
Insert month
new records.
TABELA_FONTE
Start_Process
TABELA_ELIMINADOS
CTRL_STATUS
...
DAT_PROC
CTRL_HOLIDAYS
...
DAT_PROC
CTRL_PROJECT
End_Process
Insert Error
Code
CTRL_STORAGE
Business Rules
Rej.
Business Rules
Rej.
CTRL_ENTITY
CTRL_EXECUTION
ERR_TABELA_FONTE
ERR_TABELA_ELIMINADOS
...
DAT_PROC
BD CENTRAL
...
DAT_PROC
3
Insert
Start_Process
1
Update
TABLE_NAME
...
DAT_INS
DAT_UPD
2
Insert
CTRL_ERROR
CTRL_ACTION
CTRL_MSG
REM_TABLE_NAME
...
DAT_INS
DAT_UPD
DAT_DEL
CTRL_LOAD_LOG
End_Process
Figura 10 - Framework de carregamento a partir de RDBMS
33
CTRL_PROCESS
ODI_CTRL
INSTITUIO
Start_Process
MAIL
MAIL
CTRL_EXTRACT_LOG
ELIMINADOS
FILE STAGING
Colocar ficheiro em
pasta pr-definida
Dia N
CTRL_SESSION
IGO
COD IO
ITU
INST RCE)
(SOU
CTRL_DEPENDENCIES
CTRL_TIME_WINDOW
CTRL_HOLIDAYS
ODS
CTRL_PROJECT
VALIDATE
End_Process
ERR_TABELA_FONTE
TABELA_FONTE
CTRL_STATUS
Start_Process
VALIDATE
Rejected
Rejected
Insert month
new records.
CTRL_STORAGE
TABELA_ELIMINADOS
CTRL_ENTITY
INS_SAUDE_ID
...
DES_ERR
DAT_PROC
DAT_ERR
...
DAT_PROC
...
DES_ERR
DAT_PROC
DAT_ERR
...
DAT_PROC
CTRL_EXECUTION
Insert Error
Code
ERR_TABELA_FONTE
Business Rules
Rejected
Rejected
...
DAT_PROC
Business Rules
...
DAT_PROC
BD CENTRAL
CTRL_ERROR
3
Insert
1
Update
TABELA_DESTINO
CTRL_ACTION
CTRL_MSG
Start_Process
REM_TABELAS_DESTINO
2
Insert
...
DAT_INS
DAT_UPD
...
DAT_UPD
DAT_INS
DAT_DEL
CTRL_LOAD_LOG
CTRL_PROCESS
End_Process
End_Process
Figura 11 - Framework de carregamento a partir de ficheiros
34
2.1.3.7 Processos de integrao

Foi criado um package Main com a responsabilidade de validar, entre outros, quantas entidades existem
para processar, se uma execuo ou uma reexecuo e ainda, avaliar se a integrao a ser feita por
acesso directo RBDMS ou via ficheiro.
Neste package foram definidas a maioria das variveis usadas no processamento, como sejam a Data de
Processamento ou a Entidade que est a ser processada. Esta informao transportada para os seus
packages dependentes.
Em termos de tarefas do package Main, posso referir:
Avaliar quantas entidades h para processar:

o O package de carregamento ser executado tantas vezes quantas entidades existam, visto
que as entidades so tratadas de forma sequencial. Embora fosse possvel paralelizar este
processamento devido a questes inerentes prpria instituio, esta opo no foi
seguida.
Avaliar se vai ser uma primeira execuo ou de uma reexecuo:
o Para uma execuo normal, as tabelas do mdulo de controlo so actualizadas e os
registos relativos aos vrios processos so inicializados para a Entidade e Data de
Processamento
o Para reexecutar, as tabelas de controlo so actualizadas, mas no so adicionados novos
registos.
Avaliar a entidade quanto sua origem:
o Se existe interface via BD, so executados os processos criados para aceder Base de
Dados;
o Se tratamos uma entidade que envia ficheiros, so lanados os processos preparados para
aceder aos ficheiros;
o Em ambos os casos vai existir um mdulo de controlo de processos comuns;
o Em caso de falha o mdulo de controlo actualizado.
Por fim, ser integrada a informao a partir do ODS no esquema central. Este package ser
partilhado independentemente da origem dos dados, isto porque a estrutura destino no ODS a
mesma.
o Cada um destes interfaces tem um ID correspondente no mdulo de controlo;
o Antes da execuo de determinado interface, a varivel que controla o step onde se
encontra o processo assume o ID, e o mdulo de controlo verificado de forma a
determinar se para a Entidade e Data de Processamento, essa interface j foi executada.
o Caso a interface j tenha sido executado, esta no voltar a ser e a varivel V_STEP
assume o ID do interface seguinte
o Caso contrrio, o interface executado, e o mdulo de controlo actualizado
o O package segue este comportamento padro at no haver mais interfaces a executar
o Caso seja detectada alguma falha nos diversos componentes que constituem este package,
a execuo abortada e o facto registado no mdulo de controlo.
2.1.4
Anlise de Resultados
A soluo proposta e implementada coincidiu quase na sua totalidade. Relativamente ao que poderia ter
ficado melhor e que no foi possvel implementar, devo referir o Paralelismo de processos no ODI.
Devido a um problema detectado aquando dos desenvolvimentos, que no foi possvel solucionar, e que
35
se traduzia em quebras de ligao nas comunicaes. Sempre que eram lanados dois processos em
paralelo o erro de time out gerado pelo ODI no ajudava a despistagem da situao pois era pouco
explcito. Qual a origem deste Time Out, foi uma pergunta para a qual no encontrei resposta. Testei
vrias hipteses, inicialmente pensei que seria na BD destino, mas os processos do ODI quando ocorria
esta falha nem chegavam a BD. Confirmamos e validamos esta situao numa tabela de sistema do
Oracle, a V$Session. Pensmos que poderia ser algum problema nos agentes que eram colocados nas
instituies e sem os quais no seria possvel ligarmos s fontes. Visto que os agentes estavam em
execuo e conseguamos conectar-nos a estes sem problemas, fiquei sem pistas para seguir e pensei que
o problema poderia estar no sistema de gesto da rede, embora sem nunca ter a certeza absoluta. Aquilo
que parecia, era que, por alguma razo, quando o ODI lanava dois processos em paralelo, em
determinado ponto perdia a ligao a um deles e este no retornava qualquer erro e assim, o servidor de
integrao nunca reconhecia a ocorrncia deste at acontecer o time out.
Todos os restantes pressupostos foram cumpridos e a soluo revelou-se uma mais-valia para a ACSS.
2.2 Projecto de criao de modelo analtico na ACSS

2.2.1
Contexto
Este projecto na ACSS teve uma complexidade elevada no s devido ao nmero de componentes
envolvidas mas principalmente devido especificidade de cada uma.
Este consistiu na criao de um modelo analtico criado a partir de DW sobre o qual a partir de uma
ferramenta de explorao de dados se geraram KPIs, relatrios, documentos e dashboards. Antes do
projecto s era possvel criar anlises relacionais, a pedido, feitas directamente sobre o modelo
transaccional, que no estava preparado para dar resposta maioria das necessidades dos responsveis.
2.2.2
Requisitos e Motivao
Este projecto teve como grande motivao o facto de poder disponibilizar um conjunto de informao de
gesto, crtica para a organizao, de forma automtica e com o mnimo de interveno humana possvel.
Os automatismos permitiram aumentar a produtividade, libertando os key users de tarefas rotineiras e
consumidoras de tempo na produo de informao, dando-lhes a possibilidade de se focarem mais na
anlise da mesma e assim melhorar a qualidade dos processos de tomada de deciso.
2.2.3
Soluo Tcnica e Execuo do Projecto
Tendo como ponto de partida que o projecto iria consistir na gerao de um novo modelo analtico e
utilizamos na sua construo as tecnologias ODI e OBIEE, inicimos o desenvolvimento com reunies
com os key users para definio de requisitos.
36
Nesta primeira fase introduzimos uma framework na criao de documentao por forma a facilitar a
manuteno os objectos criados futuramente. S desta forma foi possvel aps o fecho do projecto
conseguir fazer manuteno deste sem a presena de elementos que o conheam profundamente. Sempre
defendi esta metodologia, devido experincia prtica que adquiri, e que me mostrou inmeras vezes as
dificuldades inerentes ao facto conhecer uma soluo, unicamente atravs da sua utilizao, quando no
existia qualquer informao adicional sobre a mesma. Em termos de time consuming, esta nunca ser uma
boa soluo.
Assim, a cada vez maior rigidez nas boas prticas e normas que certificam o trabalho desenvolvido na
rea da consultoria, tal como os modelos CMMI [16] ou ITIL [17], que contemplam um nmero de
pressupostos que em inmeras consultoras so tidos como obrigatrios devido os seu nvel de certificao
obrigam-nos no desenvolvimento do nosso trabalho a adoptar metodologias que se traduzem na utilizao
das melhores best practices do mercado.
Esta questo muito pertinente, e com maior expresso ainda, quando colocada na realidade do mercado
Portugus, onde o dinheiro no abunda. Isto porque os nveis de rentabilidade dos projectos muitas vezes
obrigam as consultoras a no poderem subir o seu nvel de certificao, devido a quantidade de
pressupostos que lhe so colocados para entregar um projecto com o nvel de certificao que j foi
alcanado.
Em termos de mercado internacional esta situao exactamente a oposta, ou seja, se os nveis de
certificao no forem suficientemente elevados provavelmente representaro um factor eliminatrio num
concurso internacional. Assim necessrio racionalizar este tipo de opo tendo em conta os vrios
cenrios.
Posto isto, na altura da definio dos requisitos, desenvolvi um modelo documental para registar toda a
informao sobre os indicadores e seus derivados criados durante o projecto e onde pudessem ser
registados os criados futuramente. A informao aqui introduzida seria a ttulo de exemplo a data de
criao, autor, verso, forma de clculo, variantes, etc..
Desenvolvi tambm um modelo de planeamento para dashboards. Foram desenhados os relatrios que
foram adicionados tal como, a forma como seriam dispostos. Mais uma vez tratou-se de uma
problemtica nova para mim, sendo de realar que este foi o meu primeiro projecto de desenvolvimento
de dashboards. Conclui que estes obedecem a regras no seu desenho muito semelhantes a pginas web,
em que a estrutura visual fundamental para o seu sucesso. importante que sejam fceis de interpretar e
apelativos. Actualmente esta componente passou a ser fundamental nos projectos de BI, e neste caso
tambm o foi.
A definio de dashboarding a forma de disponibilizar visualmente informao objectiva, consolidada e
estruturada, que permita uma fcil e rpida interpretao. Existe um conjunto de best pratices que foram
seguidas no desenvolvimento do projecto e que tomei conhecimento na referncia bibliogrfica [18], s
quais fao referncia em seguida:
Disponibilizar a informao directamente relacionada num nico ecr, ou seja, evitar partir a
informao por vrias pginas;
Evitar a necessidade de scrolling;
Contextualizar a informao disponibilizada;
Incluir factores de comparao e sugerir aces na visualizao dos indicadores;
Utilizar escalas adequadas, que devem dar uma perspectiva real das quantidades apresentadas e
no podem iludir os utilizadores;
Utilizar nveis de preciso adequados nos indicadores, pois evita perdas de tempo com leituras e
interpretaes de informao desnecessrias e pouco relevantes;
37
Escolher os indicadores mais adequados, que facilitem e acelerem a interpretao da informao

disponibilizada;
Escolher solues grficas flexveis e adequadas que facilitem e acelerem a interpretao da
informao disponibilizada;
Uniformizar a leitura ao longo do dashboard:
o Aplicar as mesmas cores para os mesmos indicadores;
o Aplicar os mesmos tipos de grficos para os mesmos tipos de comparao;
o Aplicar os mesmos tipos de alertas;
Facilitar a interpretao da informao disponvel para acelerar a sua leitura. Por exemplo, evitar
cores berrantes, muito prximas, muito apagadas ou um nmero muito elevado de cores;
Apresentar a informao de forma equilibrada, dado que o espao utilizado num dashboard desce
de importncia do canto superior esquerdo para o canto inferior direito, e por esta razo, a
informao que se destaca na visualizao dever ser a mais importante;
Os ttulos no devem ser mais apelativos que os indicadores;
Destacar a informao mais importante e no cair no erro de chamar a ateno para tudo;
Aproveitar bem o espao disponvel, ou seja evitar decoraes desnecessrias e ainda evitar
solues de pesada implementao para responder a pormenores visuais;
Utilizar cores de forma ponderada, ou seja, utilizar cores apelativas apenas para a informao
mais importante, podendo utilizar contrastes;
Manter as cores para os mesmos indicadores ao longo do dashboard ou para o mesmo tipo de
indicador associado;
Podem ser utilizadas figuras geomtricas para alm das cores, tais como o crculo, tringulo ou
quadrado como forma de ajudar utilizadores que sofram de daltonismo;
Criar uma apresentao apelativa, baseando-se no nossa intuio e naquilo que consideramos que
a maioria das pessoas aceita e tolera positivamente.
Feita esta anlise, gerei um documento de especificao funcional e inicimos a anlise tcnica. Nesta
fase era preciso estruturar inmeras componentes do projecto e aqui foi especialmente til a experincia
que tinha em projectos de integrao e reporting em que estive envolvido ao longo da minha carreira.
A primeira preocupao seria a modelao de todo o DW uma vez que somente aps terminada esta
componente do projecto poderamos estruturar as interfaces de carregamento das estruturas criadas.
Conhecamos as fontes disponveis e era preciso desenhar um modelo que desse resposta ao conjunto de
indicadores e relatrios requeridos na fase de anlise. A leitura das publicaes de Ralph Kimball [19]
serviram-me de fonte de conhecimento para muitas situaes de projectos de DW. Uma delas consiste no
facto de a realidade num DW, vista hoje, ou num qualquer perodo futuro, ter de ser obrigatoriamente
igual. Neste projecto tal no se verificou, pois o facto da informao operacional chegar por vezes em
datas posteriores do carregamento, no permitiu disponibilizar um histrico de factos. Com esta
realidade o nosso modelo deixou de ser um DW puro, tendo sido necessrio estrutur-lo, bem como s
suas interfaces de carregamento, por forma a dar suporte a esta situao.
2.2.3.1 Infra-estrutura
Neste projecto a infra-estrutura em termos de Hardware, tal como j acontecia no projecto de integrao
operacional descrito anteriormente, era-nos desconhecida enquanto fornecedores. Por esta razo, apenas
posso apresenta-la ao nvel do Software disponvel. No total foram-nos disponibilizadas 4 mquinas cujo
modelo pode ser visualizado na figura seguinte.
38
WWW
REPORTING
Oracle
OBIEE 10.1.3.4.1
AIX 6.1 (64bit)
J2RE 1.5
http://localhost:9704/analytics
STA
DWH
BD Oracle 10g
Load Balance
Service Name: PRD
BD Oracle 10g
Load Balance
Service Name: PRD
BD
Central
ETL
Servidor Integrao
BD Oracle 10g
Metadata ETL (ODI)
LOGGING
ODI 10.1.3
AIX 5.3 (32bit)
J2RE 1.5
Figura 12 Infra-estrutura da Soluo do Modelo Analtico
39
Servidor Integrao
BD Oracle 10g
Metadata ETL CONTROL
(ODI_CTRL)
ODI 10.1.3
AIX 5.3 (32bit)
J2RE 1.5
2.2.3.2 Arquitectura Macro e modelo fsico

Na definio da arquitectura, utilizei um modelo que j me era conhecido de outros projectos de
carregamento de DW em que participei. Pude comprovar que este modelo facilita a integrao, na criao
dos processos, pois organiza de forma visvel a sua estrutura. Este modelo permite ainda a no
interferncia na performance dos repositrios que lhe servem de fonte, e que deles necessitam para dar
resposta a aplicaes que sobre eles actuam.
Assim, em alto nvel, podemos visualizar o modelo criado na figura seguinte:
Anlise e Reporting com OBIEE
BI
Logical Framework - Oracle 11g
DW - Oracle 11g
Integrao com ODI
STA - Oracle 11g
Integrao com ODI
BD Central
Operacional - Oracle 10g
Figura 13 Arquitectura Macro do Modelo Analtico
40
A arquitectura fsica consistiu numa componente de STA, um DW, e uma Logical Framework. Todas as
componentes so utilizadores de BD que pertencem ao mesmo repositrio fsico, uma RDBMS Oracle
11G. Todas as interfaces entre a fonte, o modelo operacional, a STA e o DW, sero carregadas e
modeladas utilizando o ODI. A ferramenta alm de gerar as interfaces tambm gere todo o processo de
carregamento, a gerao de logs e controlo de erros. A camada lgica denominada Logical Framework
ser desenvolvida atravs da criao de views6 PL/SQL Oracle que assentam na sua totalidade sobre o
modelo fsico de DW.
Separando a soluo em fases distintas, sequenciais em termos temporais, temos:
1.
2.
3.
4.
5.
Utilizando o ODI, extraco da informao do modelo operacional para a STA;

Com o ODI, construo do processo de integrao que vai ler da STA para o DW;
Aps a integrao no modelo fsico do DW, construo da Logical Framework;
Todo o modelo gerado na fase anterior utilizado como fonte da ferramenta analtica, o OBIEE;
Ferramenta de reporting, com acesso atravs de cliente Web para explorao.
Funcionalidade de cada componente:
Staging Area Tem como finalidade fazer a transio da informao entre o modelo OLTP e o
OLAP, ou seja, entre o operacional e o DW. Na STA temos a informao a ser integrada num
delta do processamento mensal. ainda nesta camada que toda a informao estruturada no
mesmo formato que o DW, a diferena reside no facto de no conter SK [20].
DW A forma de modelar esta camada foi recorrendo ao Snowflake, que uma derivao do
Star Schema, divulgada por Ralph Kimball. Este tipo de modelao da informao permite
hierarquizar as dimenses existentes no funcionando de forma diferente do Star Schema em
relao s tabelas de factos. muito utilizada em modelos analticos como DW ou DM [22].
O modelo continha tabelas de factos, tabelas de dimenso hierarquizadas e tabelas agregadoras.
Para alm das referidas, e para dar resposta ao modelo de negcio, durante o projecto optei pela
criao de estruturas adicionais, tabelas agregadoras com indicadores pr-calculados e tabelas de
relao como auxiliares.
Esta forma de modelar definida no projecto era-me conhecida de outros ambientes de DW. Neste
momento considero que a forma mais simples e funcional de modelar, no que diz respeito
construo de um sistema de raiz. Apresenta tambm mais-valias inequvocas, no desenho, pois
pode ser totalmente orientado ao modelo de negcio, e, principalmente na manuteno das
interfaces e estruturas.
Defini como necessrias dimenses de tipo 0, 1 e 2. Existem ainda as de tipo 3, 4 e 6 que no
utilizei neste projecto. Vou explicar de forma breve, o tipo de dimenses existentes e o seu
funcionamento:
o Tipo 0, so as que ao longo do tempo de vida da soluo nunca so alteradas, ou seja no
h inseres ou alteraes;
o Tipo 1, onde no existe manuteno de histrico, funcionando apenas com base em
actualizaes e inseres;
o Tipo 2, onde tem lugar uma gesto de histrico, para tal, inclumos nas respectivas
tabelas, campos, que por defeito se referem validade dos registos, tais como, a data de
incio e fim. Ou seja, um registo considerado activo dependendo da data em que
efectuamos a pesquisa. Quanto aos que consideramos activos data actual, vo conter
como valor por defeito na sua data de fim, um default do tipo data, atribudo
manualmente, e que, no prevemos que seja alcanado durante o tempo de vida til do
sistema, j que assim, conseguimos manter a integridade do modelo.
Tabela lgica baseada em uma ou mais tabelas ou views.
41
Tipo 3, tm um comportamento semelhante s de tipo 2, com a diferena que o histrico

neste caso s mantido em relao ao seu estado original. As evolues so registadas
por updates sempre na mesma linha, no sendo inserida uma nova linha por cada
alterao.
Tipo 4, o comportamento tambm semelhante s do tipo 2, mas aqui temos uma tabela
de histrico adicional, registamos as alteraes que a dimenso for sofrendo. Estas so
guardadas em cada nova iterao mantendo na tabela de dimenso apenas o registo mais
actual.
Tipo 6, referem-se a uma abordagem de Ralph Kimball [19], que as considera como
dimenses com alteraes inesperadas. Trata-se de um misto entre as de tipo 1,2 e 3 com
a diferena que, includo um campo, flag que corresponde validade ou no do registo.
Apenas um registo fica marcado como activo e todos os restantes como inactivos.
Nas tabelas de dimenso, a chave um atributo fundamental. No modelo definido todas as

dimenses tinham um cdigo unvoco de identificao para cada registo. Este cdigo deve ser
preferencialmente numrico por razes relacionadas com storage disponvel e performance.
Assim, a sua chave primria ser composta por um valor inteiro atribudo sequencialmente, e por
essa razo, ser sempre um atributo nico. Neste caso a aposta numa chave de apenas 32 bits
acelera o acesso a um grande volume de dados armazenados. Estas chaves sero utilizadas para
possibilitar a ligao entre tabelas de dimenso e as de factos.
Assim, sempre que se justificou, isto quando se tratavam de dimenses com volumes acima de
10 registos, ou no caso da sua chave original no ser do tipo inteiro, gervamos uma SK.
Existem vrias abordagens seguidas para criar as SK, designadamente a utilizao de um objecto
sequence da SGBD Oracle, isto a gerao de um autonumber na BD. Optmos pela
manuteno duma tabela com uma entrada por cada nova SK segmentada pela dimenso qual
se referia, contendo assim como campos o nome da tabela e a SK disponvel. Assim sempre que
havia uma nova entrada numa dimenso, o processo seguido era a consulta na tabela que
continha as SK, da entrada referente a esta, retornando a chave corrente da mesma. No novo
registo era usado o valor sequencialmente acima do registado e posteriormente actualizado
aquele que se encontrava na tabela de SK para o seu valor actual.
Existem vrias razes para se utilizar as SK ou chaves substitutas, nomeadamente:
o O facto de conseguir manter o DW o mais isolado possvel das regras operacionais, e
assim, sempre que necessrio, gerar, actualizar, remover, reciclar e reutilizar os cdigos
provenientes dos sistemas transaccionais.
o Num DW, no caso de uma integrao de dados, a informao mantida durante muito
tempo e no pode ficar vulnervel a problemas de sobreposio de chaves.
o Desempenho no acesso informao. Os cdigos utilizados em sistemas transaccionais
constitudos por uma cadeia de caracteres alfanumricos apresentam uma deficiente
performance no acesso base de dados relativamente s SK, que utilizam o menor
inteiro possvel.
o Nas alteraes de atributos nos sistemas transaccionais. As chaves genricas sero a base
para mantermos o histrico das alteraes no DW. No caso do modelo carregado, foram
geradas SK em praticamente todas as dimenses que tinham origem no Sistema
Centralizado.
o Todas as dimenses que tenham este conceito implcito, vo ter sempre trs chaves ou
SK por defeito e iguais em todas as dimenses. Sero as chaves referentes ao cdigo
inexistente ou valorizado a null (-1), chave inexistente para determinado cdigo (-2), e
ainda, a chave correspondente a um cdigo invlido onde se inclui cdigos mal
formatados (-3).
42
Apresento em seguida uma dimenso que representou um caso particular neste projecto, a
instituio. Esta dimenso, do tipo 2, era mandatria na quase totalidade da informao, e
influenciava a definio dos processos de carregamento.
A necessidade de efectuar anlises histricas, em que considerada a realidade da instituio no
perodo de anlise, despoletou este processo.
Ao contrrio das dimenses de tipo 1, onde a sua chave primria sua SK, aqui temos uma
chave primria composta, constituda pela SK e a data de fecho do registo. Assim para validar se
uma instituio se encontra activa em determinada data, teramos que validar se este campo
continha o valor default escolhido para data mxima.
Sempre que existia uma nova entrada para a mesma SK, este valor default alterava-se para a data
de processamento corrente, o registo existente era considerado fechado e era inserido um novo,
com o valor default na data de fecho.
O carregamento desta dimenso no formato descrito, afecta directamente o carregamento dos
factos. Ou seja, no histrico de uma entidade existia uma situao que obrigava a manipular os
factos a serem carregados.
Esta situao ocorria quando uma instituio era integrada numa nova ou existente mas
mantendo em funcionamento os seus sistemas. Embora a instituio tivesse uma nova
designao, o facto de a informao provir da mesma fonte obrigava converso do cdigo
dessa instituio, para o novo, onde havia sido integrada.
A situao descrita gerou aquando do carregamento do DW, a criao de uma funo que
validava o registo para as tabelas de factos, o verdadeiro cdigo antes de este ser inserido.
Na escolha da ferramenta de BI, o OBIEE, o facto de no ano de 2009, quando decorreu o
projecto, a Oracle estar integrada no grupo de lderes do Quadrante Mgico da Gartner para
Ferramentas de BI [23], justificou esta escolha, confirmando-se ainda esta boa opo, ao atingir
a liderana em 2010 [24].
Figura 14 - Quadrante Mgico de BI do Gartner Group para 2009 e 2010
43
Todas as tabelas construdas tinham campos por defeito, tais como a data de insero dos
registos e a sua possvel data de actualizao.
Existia uma tabela que era um caso particular, pois tratava-se de uma dimenso que se ligava a
todas as tabelas de factos existentes. Por ser possvel efectuar remoo da informao do DW
posteriormente ao seu carregamento, este no podia ser considerado um DW puro, e por
conseguinte, a referida dimenso apresentava um campo indicador de remoo. Trata-se de uma
flag, que tinha um valor default 0, e que no caso de o registo ser removido na sua fonte, seria
actualizado com o valor 1. Pelo facto da referida tabela centralizar todos os factos existentes no
DW, permitia que nas views ao nvel da camada lgica atravs do cdigo PL/SQL fosse filtrada
toda a informao para que s fosse visvel no modelo OLAP, todos os registos cujo indicador de
remoo tivesse o valor 0.
De forma a dar resposta criao de relatrios mais complexos, e em virtude de num sistema
analtico a performance ser um factor fundamental, foram criadas estruturas para agregar
informao de vrias fontes do prprio DW, as tabelas agregadoras. Pelo facto de apresentarem
especificidades que tornam o seu clculo por via da ferramenta analtica muito complexo e
pesado, esta foi a opo mais valida para solucionar este tipo de situaes.
Crimos ainda tabelas auxiliares especificamente para dar resposta a um conjunto de reports
especficos. O objectivo seria aumentar a performance das anlises.
Quanto ao dimensionamento do DW, foi efectuado um clculo do valor necessrio em termos de
storage a ser atribudo aos tablespaces disponibilizados para este utilizador. Na determinao do
seu valor, foi seguida a seguinte metodologia.
o Dimenses - Foi efectuada uma contagem do nmero de registos na fonte, em cada dimenso.
Calculou-se para cada dimenso, a ocupao de uma linha populada, O valor determinado
era multiplicado pelo nmero de linhas da sua fonte. Por fim, para converter o valor da escala
origem (Bytes) para a final, MB, foi feita a sua diviso duas vezes consecutivas por 1024. No
casos de tabelas com valores de ocupao que considerei baixos fiz uma ponderao,
arredondando estes para o seu superior na mesma escala.
o Factos - Foi calculada a ocupao por linha em cada tabela de factos e o nmero mdio dos
restantes factos associados dimenso por cada linha. Com o nmero mdio, multipliquei o
mesmo pelo nmero de linhas e pela ocupao de cada uma. Mais uma vez, para atingir a
escala destino, MB, efectuei duas vezes consecutivas a diviso por 1024.
o Tabelas agregadoras e Auxiliares Devido sua dimenso ser marginal, no foram
consideradas estas tabelas no clculo do dimensionamento.
Relativamente ao particionamento, vo existir algumas tabelas que devido a sua dimenso foram
particionadas. A deciso sobre qual a melhor chave para este particionamento recaiu, em todas,
sobre o ano e a instituio.
A razo desta deciso deveu-se a questes de performance, uma tabela particionada uma tabela
lgica, isto significa que vista na BD pelo user como uma tabela nica, mas em termos fsicos
para o RDBMS, consiste em tantas tabelas, quantas o nmero de parties que sejam criadas a
partir da mesma. Isto permite por exemplo alocar parties em tablespaces ou at storages
diferentes, facilitando a sua gesto e incremento de performance.
Quanto ao processo de Backup, foi definido um Cold Backup 7 Mensal por tablespace. Este deve
ocorrer dois dias antes do processamento mensal, sendo mantidas imagens dos 2 meses
anteriores.
Cold backup ou offline, Com a BD em modo offline feito um backup evitando que os dados possam sofrer
actualizaes durante o processo de backup. O downtime da BD neste processo extenso.
44
Carregamento inicial - Pelo facto de serem gerados deltas para integrar a informao que j
existia anteriormente no modelo OLTP que serviu de fonte. Foi necessrio efectuar um update ao
nvel do user de BD do OLTP no campo referente data de entrada da informao nas tabelas
fonte, e assim permitir a gerao dos deltas para carregamento da informao. Como fonte para o
referido update, o campo utilizado seria a data do prprio evento ao qual se referisse. Aps a
passagem a produo, este campo passou a comportar o valor referente a data de processamento
para serem identificados os novos registos e integrados no novo delta, independentemente da
data a qual o evento se refere.
Aquando da passagem a PRD, e efectuado o primeiro carregamento, garantimos o carregamento
prvio de todas as dimenses manualmente. Caso esta situao no se verificasse, todas as
tabelas que se relacionem com estas, ficariam sem referncias, ou seja sem a chave estrangeira
que referencia as mesmas.
Processo de Integrao O processo de integrao no ser automtico no carregamento de

todas as estruturas de dados. Algumas dimenses so mantidas atravs de processos manuais.
Neste caso, as que contm apenas descritivos para os cdigos apresentados e cuja manuteno
acontece apenas esporadicamente e por razes especficas. No modelo criado, isto aconteceu por
exemplo, com a hierarquia do tempo, do mbito de anlise, dos grupos etrios e do gnero, sendo
informao base na ferramenta analtica que s pode ser manipulada em situaes especficas.
Existiam tambm dimenses, que no sendo de carregamento manual, pelo facto dos seus
descritivos serem atribudos manualmente e no caso de surgir algum cdigo novo, este era
integrado sem a respectiva descrio, ie, com uma descrio por defeito e igual para todas as
tabelas de dimenso.
Quando este registo era canalizado na mesma operao para a tabela de erros do processo,
permitia que estas situaes fossem detectadas rapidamente e assim de forma manual
adicionadas as respectivas descries.
O fluxo mensal de carregamento garante a actualizao do modelo. Este processo ir ser
executado todos os meses, e aps a integrao no OLTP que a sua fonte. Este processo
modular ao nvel de granularidade mais baixo, e assim, em caso de falha em qualquer ponto do
mesmo, pode ser reexecutado a partir de um ponto especfico anterior a este, e no desde o
primeiro step. Os pontos de r execuo foram especificados de acordo com a sequncia do
processo e das dependncias existentes. Significa que para cada interface antes de ser executada
o processo vai verificar se h condies em concordncia com a interface precedente, em caso de
falha, esta ser reexecutada para dar condio de arranque seu posterior.
o Framework de carregamento
Todos os processos de carregamento tero como base uma framework especfica que ir reger
todo o fluxo de integrao. Assim, com base na experincia adquirida em projectos anteriores, e
aps alguma investigao descobri, numa pesquisa na Web utilizando o Google, uma framework
que apresentava solues especficas para carregamento de DW, embora fosse especfica para
OWB [25]. Adaptei a mesma para a realidade do ODI e construi assim uma verso para
carregamento de tabelas de dimenso e outra para carregamento de tabelas de factos.
A framework de carregamento teve adicionalmente de incluir a framework de controlo de
processos. atravs desta que feito o controlo do fluxo dos vrios processos e as suas
interdependncias. Sendo genrica para todos os processos e disponvel numa BD onde se
encontra toda a metadata do ODI.
Framework de Carregamento de Dimenses

Esta framework definida em 4 passos tem como objectivo efectuar a insero numa tabela
destino no modelo de DW. O seu esquema pode ser visualizado na figura 15.
45
1. feito um truncate a todas as tabelas que sero utilizadas no utilizador de staging

sufixadas com 300_DLT e 400_CHG. O significado destes sufixos ser no caso das
300 a gerao de um delta de carregamento e nas 400 a gerao de um contedo com
formato igual tabela final no DW.
2. A partir da BD (OLTP) central ser efectuado uma leitura de todos os campos
necessrios das fontes de cada uma das dimenses. Esta informao carregada
directamente, sem efectuar qualquer tipo de transformao. O destino deste processo
so as tabelas sufixadas por 300_DLT.
3. Aplicando todas as regras de transformao e integridade ser efectuado o
carregamento a partir das tabelas com sufixo 300_DLT para as 400_CHG. Todos os
registos que no estejam em conformidade com as regras definidas, desde que no
seja registado erro na validao de nulidade so inseridos com o respectivo erro nas
tabelas 400_CHG. Os registos em que sejam detectados erros, so inseridos nas
450_ERR. Aps o trmino do processo e a partir das tabelas sufixadas com 450_ERR
possvel analisar problemas que tenham sido gerados no processamento e verificar a
razo pela qual os registos mostram algum tipo de incongruncia.
4. Ser feita uma comparao entre a informao que est pronta para sair da STA e
entrar no DW e aquela que j existe dentro da tabela final do DW, a dimenso. Assim,
aps esta validao estamos prontos para uma correcta insero ou actualizao dos
registos. Em cada nova insero ser preenchido o campo que contem a data de
insero e em cada nova actualizao o campo referente a data de actualizao ou
update.
Framework de Carregamento de Factos

A framework definida em 5 passos efectua a insero na tabela destino no modelo de
DW, esta pode ser visualizado na figura 16.
1. feito um truncate a todas as tabelas que sero utilizadas no utilizador de STA
sufixadas com 300_DLT, 300_DEL_DLT, 400_CHG e 400_DEL_CHG. O
significado destes sufixos tal como nas dimenses, ser no caso das 300_DLT a
gerao de um delta de carregamento, na 400_CHG a gerao de um contedo com
mesmo formato da tabela final do DW, na 300_DEL_DLT e 400_DEL_CHG
seguindo a mesma lgica em termos de formato mas com a informao a ser marcada
como eliminada no DW.
2. A partir da RDBMS (OLTP) central ser efectuado um carregamento directo de todos
os campos necessrios das respectivas fontes. Este carregamento ser efectuado
atravs de uma leitura e escrita directa sem efectuar qualquer tipo de transformao. O
destino deste processo sero as tabelas sufixadas por 300_DLT.
3. Aplicando todas as regras de transformao e integridade ser efectuado o
carregamento a partir das tabelas com sufixo 300_DLT para as 400_CHG. Todos os
registos que no estejam em conformidade com as regras definidas, desde que no
seja registado erro na validao de nulidade da sua chave, sero inseridos com o
respectivo erro nas tabelas 400, assim como nas 450 com o cdigo de erro respectivo.
Aps o trmino do processo e a partir das tabelas sufixadas com 450_ERR ser
possvel analisar problemas que tenham sido gerados no processamento e verificar a
razo pela qual os registos mostraram algum tipo de incongruncia relativamente ao
esperado.
4. Sero marcados como registos para eliminar, os que se encontram na tabela factual
final, quando comparada com a tabela sufixada com 400_DEL_CHG.
5. Os registos na factual no DW sero inseridos ou actualizados a partir da tabela
400_CHG. Numa insero ser populado o campo referente data de insero e,
em cada nova actualizao o campo referente data de actualizao ou update.
46
A Framework de controlo de processos

Esta framework a mesma que foi utilizada no projecto anterior, de integrao do
sistema operacional e encontra-se descrita no captulo 2.1.3.6.
ODI - Package de lanamento da integrao

Foi criado um primeiro package com a responsabilidade de garantir a sequencialidade do processo,
onde as Dimenses so carregadas antes dos Factos. Assim, sempre que este lanado, vai verificar
se a execuo das Dimenses j ocorreu para aquela data de processamento.
O package seguinte ir validar, quantas entidades existem para processar, e se, ocorrer uma
execuo ou reexecuo, para alm de avaliar se a integrao est a ser feita para Dimenses ou
Factos.
Em termos de tarefas, encontram-se as seguintes:
Avaliar quantas entidades h a tratar:
o O package ir ser executado tantas vezes quantas entidades existam, visto que as
entidades so tratadas de forma sequencial.
Avaliar se execuo normal ou reexecuo:
o Para uma execuo normal, as tabelas do mdulo de controlo so actualizadas e os
registos relativos aos vrios processos so inicializados para a entidade e data de
processamento;
o Para uma reexecuo, as tabelas de controlo so actualizadas, mas no so adicionados
novos registos nestas.
Avaliar o modo de execuo:
o Se vamos executar o processo das Dimenses;
o Se vamos executar o processo dos Factos.
Quando a execuo de uma entidade termina, independentemente de ser com sucesso ou
insucesso, iniciada a integrao da seguinte, at no existirem mais entidades a tratar. Em caso
de falha o mdulo de controlo actualizado.
Aps o trmino da integrao dos dados da ltima entidade, executado um procedimento que
actualiza as materialized views e carrega as tabelas agregadoras e, s aps estas, o package
principal termina a sua execuo.
47
Central
ODI_CTRL
Table_Name
CTRL_EXTRACT_LOG
STA
Start_Process
CTRL_SESSION
Truncate table
300 & 400
CTRL_DEPENDENCIES
CTRL_TIME_WINDOW
Insert month
new records.
T_Table_Name_300_DLT
Start_Package
CTRL_HOLIDAYS
...
DAT_PROC
CTRL_PROJECT
CTRL_STATUS
Insert Error
Code
Business
Rules
Cnf
CTRL_STORAGE
Rej.
CTRL_ENTITY
CTRL_EXECUTION
T_LKP_Table_Name_400_CHG
T_LKP_Table_Name_450_ERR
...
DAT_PROC
...
DSC_ERROR
ERROR_COLUMN
DAT_PROC
DAT_ERROR
Include only
differences to
the final table.
Start_Process
CTRL_ERROR
CTRL_ACTION
CTRL_MSG
Start_Process
DWH
CTRL_LOAD_LOG
Insert or
Update DIM
CTRL_PROCESS
T_LKP_Table_Name
PK
SK
...
DAT_INS
DAT_UPD
End_Process
Figura 15 - Framework Carregamento de Dimenses
48
BD
Central
ODI_CTRL
Table _REM
Table_Name
CTRL_EXTRACT_LOG
Truncate table
300 & 400
Dia 10
Start_Process
Insert month
new records.
CTRL_SESSION
CTRL_DEPENDENCIES
CTRL_TIME_WINDOW
STA
Insert month
new records.
Truncate table
300 & 400
CTRL_HOLIDAYS
T_SCD_EPISODIO _INTS_300_DEL
...
COD_EPIS
COD_INST_SAUDE
COD_MES
COD_ANO
DAT_PROC
T_Table_Name_300_DLT
...
DAT_PROC
CTRL_PROJECT
CTRL_STATUS
Start_Process
CTRL_STORAGE
End _Process
Insert Error
Code
Business Rules
CTRL_ENTITY
Business Rules
Rej.
Rej.
CTRL_EXECUTION
T_FAC_EPIS_400 _DEL
T_FAC_Table_Name_400_CHG
T_FAC_Table_Name_450_ERR
Start_Process
SK_EPIS
SK_INST_SAUDE
COD_ANO
COD_MES
DAT_PROC
...
DAT_PROC
...
DAT_PROC
CTRL_ERROR
CTRL_ACTION
CTRL_MSG
Insert/Update
DWH
Update
Insert & Update

Fact
CTRL_LOAD _LOG
T_FAC_Table_Name
PK
Start_Process
CTRL_PROCESS
SK
...
DAT_INS
DAT_UPD
End_Process
Figura 16 - Framework Carregamento de Factuais
49
8
9
Logical Framework Esta consiste numa camada de views lgicas definidas paralelamente
com a camada de reporting num schema separado do DW, embora na mesma RDBMS fsica.
Esta camada de views l a informao directamente do DW, e constitui o que chamamos de
modelo lgico, tratando-se ainda da fonte da ferramenta analtica OBIEE.
Esta camada permite estruturar a informao por forma a dar resposta o mais directa possvel
aos requisitos de negcio, que o objectivo dos Keys Users. Desta forma fica facilitada a
modelao dentro da ferramenta analtica, OBIEE. Conseguimos ainda diminuir o tempo para
efectuar a modelao no OBIEE. A razo para esta opo centra-se no facto do OBIEE em
termos de modelao ser totalmente fiel ao Star Schema, e por essa razo necessrio
simplificar o modelo para evitar complicaes na tarefa de relacionar os dados.
Existem regras a cumprir na criao desta camada de views que constituem mais-valias na sua
manuteno e principalmente na performance.
o Assim, no existem acessos directos a tabelas no DW, so criados objectos do tipo
Synonym 8que acedem s mesmas. A vantagem desta situao prende-se com o facto
de ser mais fcil quando necessrio, apontar o DW para outra BD ou Schema. Para o
efectuar bastar recriar os sinnimos, ficando as views a apontar para o novo schema,
evitando assim termos de recriar o cdigo de todas as views existentes.
o No existem views que utilizem outras views como fonte, o acesso por parte das views
sempre directo ao DW.
o Todas as tabelas do DW so indexadas de acordo com o cdigo gerado para estas
views, criando ndices de tipos especficos para dar resposta com a maior celeridade
possvel. Criando ndices de tipo Bitmap, nas dimenses com baixo nvel de
granularidade, ndices de tipo Local quando se tratam de tabelas particionadas e
ndices de tipo normal ou B-tree nas restantes situaes. Os ndices Bitmap s devem
ser utilizados nas condies referidas, pois pelo facto de guardarem juntamente com a
chave os rowid 9de cada registo tornam-se demasiado pesados noutras condies.
Quanto ao funcionamento do ndice local, este s pode ser utilizado nas tabelas
particionadas. O facto de uma tabela particionada ser uma tabela lgica que
composta de N tabelas fsicas, permite criar um ndice local por partio e neste tipo
de tabelas quando utiliza a indexao, parte do ndice global da tabela que composto
pela chave da partio, recorre na partio pesquisada ao ndice local que melhor se
adequar pesquisa desejada. Utilizamos ainda que de forma espordica e apenas no
carregamento de tabelas agregadoras, os ndices baseados em funes, os Functionbased indexes.
o Na criao das queries utilizadas nas views, validando a sua performance no explain
plan table do Oracle, justificamos a utilizao de Hint Rules. Existem vrias Hints que
ajudam o motor de BD a tomar melhores decises na construo do caminho que a
querie vai percorrer na RDBMS e assim baixar o custo da mesma. Quando o tempo de
resposta de uma querie demasiado elevado, normalmente deve-se a uma m escolha
na forma de relacionar a informao por parte do motor da mesma. Quando
relacionamos, numa querie, tabelas que esto em utilizadores fsicos de BD distintos e
invocadas atravs de DB Link ou Sinnimos que referenciam um DB-Link, a RDBMS
Oracle no tira partido da utilizao dos ndices. Esta uma das situaes em que
devemos forar a utilizao desses ndices. Outra situao comum e que justifica a
utilizao de Hints, ser quando um universo gerados numa querie, funciona como
uma subquerie e vai servir de fonte principal, num SGBD Oracle, o que ir acontecer
que, por cada linha executada da querie principal, todos os universos dos quais esta
depende, vo ser regenerados. De forma a acelerar a obteno de resultados, podemos
forar a resoluo deste subconjunto numa s iterao, ficando este em memria e
utilizando este resultado para a querie da qual dependente.
Nome alternativo para um objecto de Base de Dados

Pseudocolumn que contm o endereo de cada linha na BD.
50
OBIEE a camada de mais alto nvel e onde foi construdo o modelo OLAP e o reporting,
incluindo ainda a definio dos indicadores, mtricas e respectivos factos.
Assim, com base no modelo do DW, construmos todas as hierarquias que havamos definido
ao nvel do seu modelo base. Foi com base nestas hierarquias que se tornou possvel dentro da
ferramenta analtica fazer o Drill Down dentro dos factos, ou seja partirmos de um nvel de
agregao mximo associado a um facto e podermos descer at ao seu nvel de granularidade
mais baixo. Atravs desta descrio possvel perceber a vantagem da modelao do DW ser
em Snowflake. Se tivermos uma estrutura normalizada, conseguimos percorrer as hierarquias
como se tratassem de ramos de uma rvore. A verso do OBIEE utilizada no projecto tinha
como limitao, o facto de no ser possvel criar hierarquias multidimensionais, ou seja, onde
exista mais de um caminho a seguir. Esta soluo actualmente foi solucionada na verso mais
actual, a 11G.
A ttulo de exemplo do funcionamento das hierarquias, refiro a hierarquia de tempo, que
construda em outros projectos semelhantes, e inclui as dimenses Ano, Semestre, Trimestre e
Ms, no seu nvel mais baixo.
Figura 17 - Hierarquia de Tempo
Em termos da forma como a informao era apresentada, crimos 3 dashboards com filtros e
prompts associados, ou ao nvel do prprio dashboard, ou, de um separador do mesmo.
BI Publisher O OBIEE no permite a gerao de documentao no formato MS Word de

forma directa o que abriu espao para uma nova necessidade aps fechada a soluo.
Sendo esta nova fase, posterior data determinada para fecho do projecto e, por questes
inerentes a necessidades de outros projectos da BIMaven, fiquei sozinho no desenvolvimento
desta componente.
Esta ferramenta tem a capacidade de interagir directamente com as sources do OBIEE, ou seja
os relatrios neles criados. Assim, possvel import-los directamente, aps uma ligao ao
seu servidor, para um template no formato RTF. Estes templates eram formatados em
Linguagem XML, embora a maioria dos objectos fossem disponibilizados atravs de um
plugin para o MS Word integrado no pacote do BI Publisher.
Foi necessrio muito trabalho de customizao dos relatrios pois o formato pretendido,
para ser efectuado em XML, obrigava a muitas alteraes s bases fornecidas, e prpria
segmentao dos dados. Esta situao deve-se ao facto dos relatrios importados do OBIEE
apenas conterem os campos, ou seja, os dados que pretendemos introduzir no BI Publisher, na
realidade estvamos a importar as queries que este efectuava a BD, neste caso, na Logical
Framework. Toda a apresentao e formatos foram trabalhados na camada do BI Publisher.
2.2.4
Anlise de Resultados
A nvel da modelao feita no OBIEE crimos um total de 600 indicadores, sendo entre 15 a 20
por cento a base para os restantes. Crimos 250 relatrios para dar suporte aos 3 dashboards e 2
51
documentos sob o formato de templates. Mencionando aquilo que foi imediatamente palpvel na
soluo desenvolvida, o facto de um documento anual, que antes deste projecto, era produzido em
5 FTE, tenha passado a ser produzido em 30 minutos, um indicador claro da valia do projecto.
52
3. Analise aprofundada do percurso profissional

3.1 Iniciao - NB
Com a entrada na Novabase, fui integrado na unidade de Business Intelligence e assumi a funo
de Assistant Consultant.
3.1.1
PT-Sistemas de Informao
O primeiro projecto para um cliente da Novabase foi numa grande companhia de telecomunicaes
a nvel nacional, a PT, atravs da sua empresa de consultoria, a PT-SI [27], no caso foi um projecto
da PT-COM [28] mas que envolvia todas as empresas do grupo. Foi um projecto de DQ onde
utilizei como ferramenta, o Integrity [29], na altura propriedade de uma SW House10 Sua, a
Ascential. O produto era dos mais evoludos a este nvel e permitia ainda fazer integrao a um
nvel muito bsico. Em termos do Data Profilling possua uma linguagem prpria algo semelhante
ao Assembler e que atravs da manipulao de ponderadores permitia na identificao das strings
de input, a sua manipulao ou marcao de registos. Estas tarefas utilizavam algoritmos prprios
da ferramenta, mas que, funcionalmente eram definidos a partir de regras de negcio criadas em
sede de projecto.
Este projecto foi diferente dos que me surgiram posteriormente como consultor. No s por ser de
DQ, mas tambm porque era totalmente ligado a sistemas transaccionais, sem nenhuma
componente analtica ou mesmo de modelao. Foi um mega projecto envolvendo inmeros
fornecedores desenvolvido de forma modular. Foi afirmado na altura como sendo o maior projecto
de implementao TI a nvel nacional [30].
A fonte que dizia respeito ao meu envolvimento era um ERP SAP R/3 onde estava toda a
informao associada aos trs grandes grupos de informao que eram a base do projecto, Clientes,
Fornecedores e Materiais. Todos estes universos foram alvo de processos de Anlise,
Normalizao, Consolidao e Desduplicao.
O processo era preparado de forma prvia ao longo de semanas e normalmente as execues eram
planeadas para ocorrerem aos fins-de-semana. Esta era uma forma de minimizar o risco, isto
porque aps os nossos processamentos tnhamos uma equipa de validaes que estava pronta para
analisar os dados por ns gerados. Em caso de falha ainda tnhamos tempo para fazer algum acerto
ao nvel do nosso processo e reprocessar. Era feita uma extraco no final do dia de sexta-feira e s
aps, feito o fecho aplicacional. Posteriormente era iniciado o processo, primeiro com uma
extraco da informao utilizando uma rotina feita em SAP [31] que integrava algumas classes de
linguagem C e depois desta execuo, havia uma janela de horas para efectuarmos as execues
associadas aos nossos processos de DQ.
Aps a extraco para ficheiros plain text, eram utilizadas algumas rotinas em HP-UX como o
GAWK 11que preparavam os dados para entrar nos processos do Integrity. Atravs destes
10
Empresa de desenvolvimento medida de produtos de Software

Biblioteca de funes estendida do AWK e com maior capacidade por exemplo no suporte de um maior
nmero de colunas
11
53
processos eram seleccionados os campos pretendidos para o processamento de DQ, e

posteriormente, eram invocados estes mesmos processos sobre a informao proveniente dos
sistemas transaccionais. No final deste processo era feito um processo de backup de todos os
ficheiros fonte e processados antes destes passarem por uma nova interface que os preparava para
serem disponibilizados de novo e carregados no ERP SAP R/3.
Em termos de timings a minha passagem por este projecto durou 4 meses, tendo estado sempre
includo na equipa do cliente. Trs meses com outro colega e no ltimo ms sozinho.
3.1.2
ESI Espirito Santo Innovation
A restante experincia com clientes da Novabase centrou-se na rea da Banca onde estive em
algumas reas verticais dentro do grupo BES, um grande Grupo Bancrio a nvel Nacional e j
com alguma presena a nvel Internacional. A maior parte do tempo na sua empresa de GSI, ESI
[33]. O projecto com maior destaque aconteceu na rea da Recuperao de Crdito, sendo ainda
hoje uma das fontes analticas de referncia.
Em termos temporais, a minha passagem por este cliente durou aproximadamente 2 anos.
O primeiro projecto foi o de maior relevncia tendo-se tratado de um projecto Turn Key 12que teve
um tempo de implementao de aproximadamente 1 ano, e que aps o Roll Out mantive um papel
activo junto do mesmo, tanto na sua manuteno, como posteriormente, e por j estar adjudicado a
outros projectos e reas, na definio de novos requisitos junto dos Key Users. Isto tanto no
planeamento de trabalho para a nova equipa de manuteno, como na definio de novas
funcionalidades.
Em termos de definio, este projecto consistiu na criao de um modelo analtico, um DM, onde
era includa toda a informao associada aos Contratos de Crditos em situao de recuperao
geridos por esta instituio. Diariamente era enviada pelos balces, toda a informao, sob a forma
de eventos, relativa a contratos activos e vencidos, desde as suas posies, movimentos, o status,e
toda a informao processual associada.
A informao era integrada diariamente e existia reporting dirio em MSTR 7i. A fonte do MSTR
era a camada da Logical Framework criada na RDBMS Oracle.
Aps a boa concluso deste projecto, e dado o impacto positivo que o resultado deste causou, foime atribuda uma nota mxima na avaliao anual e atingi um novo nvel de carreira onde assumi
as funes de Consultant.
A partir da entrega do projecto anterior ao cliente fui convidado para integrar a equipa de DW do
cliente e, at minha sada da Novabase, no mais abandonei esta equipa.
Existiram vrios projectos dentro desta entidade, possuindo esta, na altura, um dos maiores DW a
nvel nacional. Todos os processos introduzidos e integrados nos processamentos quer dirios,
mensais ou anuais obedeciam a uma framework especfica, e que, era uma garantia de estabilidade
e fiabilidade para quem estava incumbido da manuteno destes sistemas.
Os processos de integrao no DW tinham obrigatoriamente que passar por trs utilizadores de
BD, o ODS, a STA e o DW.
Toda a informao era enviada em ficheiros provenientes de vrias reas e aplicacionais, incluindo
a informao proveniente do AS400 introduzida nos balces. Esta informao era integrada no
ODS normalmente atravs de processos Datastage [32] ou Shell Script Unix. Independentemente
12
Projecto chave na mo ou fechado
54
da mquina em que estes fossem executados, existia uma ferramenta que centralizava e
calendarizava todos os processos coordenando a ordem e tempo de execuo dos mesmos, o
Control-M13. Esta ferramenta invocava scripts Unix HP-UX onde na sua chamada podiam ser
includos algum tipo de parmetros fornecidos por variveis da prpria aplicao. Toda esta
metodologia, exigia o preenchimento de templates especficos de modo a manter documentao
actualizada de todas as interaces a que obrigava cada um dos novos processos inclusos. Nestes
estava toda a informao associada ao processo, tal como todas as suas dependncias ou variveis
invocadas.
Quanto a framework, esta foi desenhada internamente e consistia numa srie de metodologias de
apoio aos processos de carregamento do DW em PL/SQL, e em especial no ODS. Existiam
funcionalidades pr-definidas como funes e parmetros genricos, que eram utilizadas em todos
os processos no logging ou nas suas operaes.
Toda a estrutura da framework era totalmente customizvel e adaptvel, e permitia, manipulando
apenas tabelas de parmetros, e os parmetros de chamada dos Packages, Functions e Procedures
alterar as fontes e destinos de todos os processos, quer em termos de Schemas ou BD.
A framework tinha como principais objectivos:
Melhorar a performance dos processos na STA:

o Reutilizao de mdulos processuais evitando trabalho repetitivo;
o Uniformizar as ferramentas de desenvolvimento;
Facilitar a manuteno da STA:
o Optimizando a quantidade de informao processual;
o Garantindo processamentos parciais;
Melhorar a adaptao s necessidades do negcio:
o Maior flexibilidade para incluso de novos requisitos;
o Baixar os tempos de desenvolvimento;
o Melhorias na deteco e correco de informao incorrecta;
Adaptao a diferentes sistemas.
Uma componente muito interessante em termos de controlo do risco associado aos processamentos
estava relacionada com o processamento das dimenses. Embora este fosse dirio, existiam 2
utilizadores de BD associados, um que continha a imagem do dia processado e outro tinha sempre
o dia anterior. Para garantir o bom funcionamento de toda a camada de reporting estava criado um
sinnimo ao nvel da BD que servia como base para todas as queries efectuadas pelo modelo do
MSTR. Assim, a grande vantagem residia no facto de em caso de irregularidades no processo
havia uma forma fcil de ter toda a camada de reporting funcional rapidamente, bastando
reapontar o sinnimo existente para o utilizador com os dados do dia anterior. Esta soluo de
recovery no seria uma soluo totalmente satisfatria mas garantia o bom funcionamento do
sistema e era facilmente implementvel.
Em termos da minha participao nos projectos seguintes na ESI, o foco foi a rea de Ratings e
Scores de clientes. Devido iminente entrada em vigor do novo acordo Basileia 2, iniciei o
projecto de criao da sala de mercados e participei ainda na integrao de novas entidades
estrangeiras no DW, como a rede de balces de Espanha, Inglaterra e outros. Toda esta integrao
tinha que ser feita nos mesmos moldes das entidades rplicas que j existiam no DW.
Fiquei ainda durante a minha passagem, responsvel por um prottipo que consistia na gerao de
um DM que antecipava as anlises que se sabiam obrigatrias no futuro acordo Basileia 2. Era
um prottipo com anlises mensais em que no existia qualquer preocupao em termos de
performance, quer a nvel do seu tempo de processamento, quer depois na anlise da informao
13
Ferramenta da BMC para calendarizao de Batch
55
gerada. A posterior anlise desta informao era feita Ad-Hoc atravs de querieng SQL, ou no
Excel, a partir de extraces de informao.
3.1.3
ESCOB Esprito Santo Cobranas
Tive uma interveno pontual, com a durao de um ms, numa das fontes do projecto que
desenvolvi na ESI referente recuperao de crdito. Tive que intervir neste processo operacional
na rea de cobranas. Na fonte SIG, que consistia numa RDBMS em SQL Server 2000 que tinha
uma componente analtica ROLAP em Microstrategy directamente sobre esta ltima. Esta
interveno devido a questes de segurana da prpria instituio teve que ser efectuada
directamente no servidor de integrao, um rack com Intel Xeon. Esta interveno consistiu na
adio de uma nova fonte de dados que passou a fazer parte desse SIG tal como a incluso de
reporting sobre esta nova informao carregada.
3.2 Evoluo - Staples

A integrao na Staples Office Centre [34] permitiu-me assumir diferentes funes e explorar com
maior profundidade uma rea em que eu tinha menor experiencia, os sistemas transaccionais.
Nesta vertical, todas as interfaces aplicacionais existentes tinham sido criadas em Shell Script
Linux Suse 14invocando Oracle SQL Plus 15ou em Pro*C 16compiladas e tambm invocadas via
Linux Suse. Estas interfaces eram invocadas de 4 formas possveis, manualmente em casos de
recovery de alguma situao no esperada, de forma automtica via Shell script no Day Run e no
Night Run, ou ainda, via aplicacional, atravs de Forms ou VB.
Para alm destas interfaces existiam algumas rotinas criadas para a impresso de etiquetas e
listagens, sendo que as primeiras eram criadas atravs de scripts que invocavam cdigo ZPL, no
caso das Sinaltica e Rail Card17, ou ento, utilizando tambm o Pro*C nas de Vitrina. J as
listagens eram habitualmente geradas em Shell Script invocando SQL Plus, sendo estas
redireccionadas directamente para as impressoras de cada loja.
Em termos aplicacionais tnhamos como front-end, um ERP que era totalmente customizado em
tecnologias Oracle. A RDBMS era uma Oracle 9i, posteriormente migrada para 10G. Sendo toda
parte visual programada em Forms e Reports 6i. Possuamos tambm o Oracle Finance 18 e o OTS
integrado no E-Business Suite19.
A nvel de reporting analtico ad-hoc possuamos uma aplicao criada in-house em VB que
invocava os Shell Scripts com SQL Plus. Como ferramenta analtica com alguma complexidade
possuamos o Oracle Discoverer 4i, mas, era apenas utilizado em projectos ligados a rea
financeira e nunca vingou em termos de referencia interna.
Relativamente aplicao de reporting desenvolvida in-house, que j referi, esta possua um frontend desenvolvido em VB onde atravs de caixas e selectores especficos nos permitia executar
reports com parmetros pr-definidos e ger-los directamente para um output definido on-time,
como seja o ecr, ficheiro, impressora ou directamente para um mail. Para criar um report era
necessrio gerar um script em Shell Script Unix, que quando executado gerava um ficheiro de
output do tipo text file sendo este depois redireccionado pela aplicao para um destes outputs
especficos.
14
Verso do SO Linux original da Novell

Linha de comandos Oracle que permite executar PL/SQL e SQL
16
Linguagem de Programao C com SQL Oracle e Sybase embebida
17
Impressora manual de etiquetas
18
ERP integrado no E-Business Suite com foco na rea financeira
19
Suite Midlleware da Oracle que inclui produtos de ERP, CRM e SCM
15
56
Na customizao do ERP participei num projecto interessante de criao de novos ecrs para o
SPV.
Este projecto envolveu a utilizao das tecnologias Oracle Forms e Reports 10. Foi um projecto
importante pois at aqui e para alm da manuteno de todo o ERP, os Forms que havia criado de
raiz tinham uma baixa complexidade. Este conjunto de ecrs para o SPV permitiu-me evoluir
bastante no conhecimento desta tecnologia, assim como na interface com passagem de parmetros
entre o Forms e o Linux.
Este projecto teve como componentes mais interessantes no s a reformulao de todos os ecrs
que j existiam, onde introduzi por exemplo os menus com drop downs para facilitar a navegao,
mas tambm, a centralizao de todo o sistema, e por conseguinte, das suas interfaces, no armazm
em vez de como anteriormente deslocalizado em cada loja.
Assim foi criada uma nova interface com a aplicao WPMS, o que obrigou a trabalho com o
fornecedor externo desta ferramenta. Foi feita ainda uma preparao embora no tendo sido
concretizada na altura para no futuro permitir uma interface directa com os reparadores. Neste
mdulo existia um total de 8 ecrs que interagiam e permitiam a navegao entre si, sendo em cada
um gerada uma instruo para impresso de vrios tipos possveis de guias de reparao. Estas
eram impressas atravs da execuo directa de Shell Scripts e onde seria passado como parmetro
a escolha da impressora, para a qual deveria ser enviada. Os nomes das impressoras eram
partilhadas de loja para loja, e assim sendo, a partir do momento em que efectussemos o login
numa determinada loja, a impresso era redireccionada para o IP correspondente impressora
esperada.
Em termos do projecto com maior relevncia em que participei, ter sido a centralizao do ERP.
Tratou-se de um projecto de elevada complexidade no s pelas componentes que foram
contempladas, como tambm pelo facto de ser um projecto estratgico para a companhia, o que
acrescentou uma presso adicional equipa.
O projecto teve 4 componentes principais:
Soluo de Hardware
Centralizao do RDBMS
Front-End ou componente aplicacional
Programas ou Rotinas
Em termos de soluo de Hardware existiram vrias preocupaes como sejam incremento de

performance, estabilidade, fiabilidade e o TCO. Foram consultados dois fornecedores de HW e a
escolha da soluo acabou por residir na diferena no TCO, pois ambas as solues eram muito
semelhantes nos restantes aspectos.
Em termos especficos a soluo construda era uma arquitectura transaccional de alto dbito
constituda por um rack 20com load balance 21ao nvel do SGBD gerido atravs do Oracle RAC.
Esta arquitectura era escalvel e com grande capacidade evolutiva.
Ao nvel do servidor aplicacional existiam duas mquinas embora ambas partilhassem o mesmo
storage. O storage era iSCSI com interface Fibre Channel.
Tratou-se de um projecto complexo devido ao facto do ERP estar presente em 26 lojas num
servidor central e ainda fazer o mesmo ao nvel da RDBMS, onde existiam 26 instalaes fsicas.
Para alm disso, fizemos uma migrao de verses de BD, neste caso de Oracle 9i para 10G.
Para simplificar este processo de centralizao e devido s inmeras dependncias existentes
foram criados utilizadores lgicos de nvel global que traduziam os utilizadores fsicos j
20
21
Plataforma escalvel destinada a infra-estrutura de IT organizacional.

Repartio de carga de um servio por mais de um recurso da infra-estrutura.
57
existentes. A vantagem seria no facto de permitir manter a estrutura de logins e utilizadores

exactamente igual que estava ao nvel aplicacional. No momento em que um login era efectuado,
e de forma transparente para o ERP, utilizando as chaves FGAC atravs de uma Policy convertia o
login aplicacional, lgico, num login fsico. Com isto conseguia-se aceder a aplicao e esta BD.
Esta soluo minimizou em grande parte o risco associado ao projecto pois garantia a manuteno
da estabilidade j existente nos mdulos utilizados.
3.3 Consolidao - BIMaven

Na integrao na BIMaven Consulting tive como foco o meu regresso ao BI, e hoje, estou convicto
que fiz uma boa opo uma vez que desde a minha entrada tenho sido exposto a desafios diversos
e interessantes, que me proporcionam uma aprendizagem constante. Trata-se de algo altamente
motivante e que faz com que ainda hoje mantenha uma alegria quando me encaminho diariamente
para o meu trabalho.
Logo aps a minha entrada estive envolvido num projecto no grupo Media Capital [35] onde fui
desenvolver uma interface em Integration Services 2005, de forma a integrar informao
proveniente de SAP BW num modelo ROLAP, Microstrategy 8i.
Aps este projecto comecei pela primeira vez a entrar no negcio da sade. Na ACSS [36] estive
inicialmente envolvido no desenvolvimento de vrias propostas comerciais inclusive para resposta
a concursos pblicos. Mais tarde estive envolvido num projecto ligado rea de Financiamento
que permitiu a gerao de reporting mensal. Neste projecto foi efectuado um trabalho de
reorganizao das necessidades da unidade em questo, tendo sido introduzidas vrias
metodologias de trabalho ao nvel da documentao tipo que permitem hoje um controlo do
formato e estrutura de toda a informao gerada e disponibilizada.
Participei na resposta a um RFI para o MDN [37] com o objectivo de criar um sistema analtico a
partir de uma fonte SAP BW.
Estive depois envolvido em dois projectos na Indstria atravs da Efacec [38]. Um primeiro,
apenas de modelao ao nvel da camada de views, a Logical Framework, que iriam alimentar uma
camada de reporting, e, um segundo, mais extenso onde foram desenvolvidas interfaces de
carregamento de todo um modelo j existente e que estavam desenvolvidas anteriormente numa
tecnolgica j obsoleta.
Participei depois numa experincia totalmente nova para mim no mundo laboral. Fui orador numa
palestra no CCB no mbito de um evento da Oracle, com a qual, a BIMaven mantm uma
parceria. O tema apresentado foi Consolidate to Grow.
Posteriormente, voltei rea do retalho, onde estive na FNAC [39]. Foi um projecto em que estive
envolvido apenas na fase de anlise e, o principal objectivo foi tambm tentar captar necessidades
que existissem dentro da FNAC, de forma a estruturar futuramente uma oferta que se adequasse.
Estive depois envolvido num projecto na rea dos seguros na Groupama Seguros [40], foi um
projecto numa rea inovadora para mim, tendo participado na proposta e em toda a fase de anlise.
Voltei a rea das TELCOS onde estive na ZON [41], envolvido em dois projectos, ambos tinham
como objectivo a construo de modelos analticos ROLAP.
Actualmente, estou a desenhar uma soluo BI Real-Time na rea da comunicao social
envolvendo algumas componentes da oferta de Middleware da Oracle. As tecnologias utilizadas
so parte integrante da plataforma de Fusion Middleware da Oracle, o SOA Suite e ainda o ODI.
Assim, vou agora fazer uma referncia mais especfica a cada um dos clientes e aos respectivos
projectos por onde passei e respectivas particularidades e adversidades de cada um deles.
58
3.3.1
BIMaven
Dentro da BIMaven e falando de projectos internos assumi dois tipos de papel, essencialmente, na
anlise de sistemas por forma a poder ou no gerar possveis propostas, na investigao de novas
tecnologias e reas de mercado.
Foi no primeiro papel que estive envolvido na criao de duas propostas para a ACSS.
A primeira tratou-se da resposta a um concurso pblico, ao qual aps uma anlise extensa e de
algum trabalho preparatrio na proposta, se chegou concluso que a relao entre o ROI e o
risco, no era positiva a favor do primeiro. A soluo requerida pelo caderno de encargos consistia
na criao de um sistema aplicacional e analtico onde fosse possvel manter a informao sobre
todas as entidades do SNS, todas as suas caractersticas e existncias, assim como introduzir nova
informao sobre as j existentes, ou introduzir novas entidades. Para esta ultima funcionalidade
seria necessrio criar um sistema aplicacional de raiz, customizado medida, situao esta que
estava fora do core base da BIMaven. Por essa razo decidimos avanar com uma parceria que
sustentasse essa capacidade para efectivamente assumirmos o projecto. Toda a componente
analtica foi ento definida por ns, tal como a respectiva anlise.
Nesta situao, embora o resultado final no fosse o pretendido, a tarefa acabou por ser aliciante e
conter muitas novidades para mim. A resposta a um concurso pblico reveste-se de
particularidades relacionadas com a forma como se estrutura a proposta para ganhar. Esta tem que
se focar muito para alm da qualidade da soluo, a pontuao o mais importante e tentar obter a
mxima em todos os critrios, resultar numa eventual adjudicao. necessrio muitas vezes
sacrificar a qualidade da soluo e, principalmente da equipa de projecto, por forma a conseguir-se
um equilbrio que motive a resposta mesma. Eventualmente quando os critrios so demasiado
rgidos e apertados, ao ponto de o risco da soluo final poder vir a no ter a qualidade que um
implementador gosta de se orgulhar e mostrar ao mercado, pode conduzir por vezes situao de
desistncia, mesmo aps toda a proposta ter sido criada. Isto porque por vezes numa primeira viso
sobre o caderno de encargos, e mesmo com gestores de projecto experientes, torna-se difcil
aquilatar de imediato se o projecto pode ter um interesse real para o implementador. S em
companhias de grande dimenso, com equipas muito estabilizadas e com SLAs j muito bem
definidos, se pode rapidamente analisar o real interesse na resposta a um concurso. E ainda assim,
esta situao no garantida pois inmeras vezes s aps uma anlise exaustiva de todos os
pargrafos de um caderno de encargos, se consegue atingir o real esforo necessrio para levar a
cabo a soluo.
A segunda proposta para a ACSS que efectuei teve como resultado uma adjudicao culminando
assim na sua posterior implementao. Aqui assumi um papel de Team Leader end-to-end, ou seja
desde a criao da proposta comercial, a sua entrega, todo o desenvolvimento e gesto da equipa
de projecto at sua passagem ao ambiente produtivo. O objectivo destes sistemas era a
substituio das interfaces em PL/SQL j existentes, e a sua substituio por uma ferramenta de
integrao. O segundo produto da soluo foi a criao de um sistema analtico tendo por base as
BD fonte das interfaces j referidas.
Assim, escolhemos como ferramenta de integrao o ODI, devido a inmeras vantagens que
apresenta no s em termos do paradigma relativamente concorrncia, como tambm em termos
de conectividade. J para a criao deste sistema analtico, propusemos a criao de um sistema de
DW utilizando uma RDBMS Oracle 11G para o qual tivemos que definir toda as estruturas e
modelao, assim como as interfaces das mesmas. Como ferramenta de integrao mantemos a
aposta no ODI 10G e, como ferramenta de Reporting, o OBIEE 10G. Tratou-se de uma proposta
bastante extensa e complexa, e que, no final teve uma excelente aceitao. Nesta foram invocadas
todas as metodologias da BIMaven, na gesto de projecto, gesto de processos, testes, auditoria e
riscos.
59
Aps estas duas propostas surgiu mais tarde a hiptese de fazer uma resposta a um RFD para um
projecto de CRM/DQ para a Groupama Seguros. A proposta teria que ser criada em parceria com
outra consultora pois as nossas competncias no cobriam todo o desenvolvimento que teria que
ser assumido. Assumi a liderana da equipa que faria a proposta e que foi desenhada em pouco
tempo pois s havia dois dias para a entregarmos. Ainda assim dada a qualidade da mesma e aps
uma reunio onde fomos defender a mesma acabamos por ganhar e fomos escolhidos para
implementar o projecto.
3.3.2
Media Capital
O objectivo aqui era a construo de um modelo analtico em Microstrategy 8i, sendo as fontes em
SAP BW. Embora o Microstrategy tivesse um conector para SAP BW, que permitiu construir
todos o modelos, existia alguma informao financeira das rbricas de balano que no era
possvel integrar.
Assim, foi necessrio construir um processo alternativo que alimentasse o Microstrategy. O
repositrio destino escolhido para o processo foi a RDBMS MS SQL Server 2005. A razo para tal
escolha est muito relacionada com as polticas comerciais das empresas fornecedoras. Neste caso,
falando da MS, existem muitas empresas que adquirem licenciamentos corporativos com
condies vantajosas e, inmeras vezes, so disponibilizados produtos sem custos, isto , se a
ferramenta no for utilizada no h qualquer custo, caso contrrio, este custo adicionado ao
licenciamento corporativo na renegociao do contrato, habitualmente com condies muito
favorveis relativamente a outros fornecedores. No caso da MS, esta tarefa habitualmente
facilitada em grandes organizaes, pois a maioria delas utiliza o MS Office para todos os seus
colaboradores de reas funcionais e de investigao e assim sendo, fica facilitada a tarefa de
conseguir vendas de produtos de reas diferentes.
Foi assim disponibilizada uma VM Windows onde instalei o MS IS 2005. Defini os acessos BD
destino em MS SQL Server 2005 e pude assim desenvolver o novo processo, o qual j havia
preparado previamente de forma a ser mais rpido a sua integrao. Assim s serem necessrias
fazer algumas adaptaes.
Este trabalho prvio, mais do que apenas preparar o processo consistiu na aprendizagem desta
tecnologia, o IS, isto porque embora j conhece as RDBMS SQL Server, s conhecia at ento a
verso 2000 e, nessa altura, esta ferramenta de integrao no existia. Como no havia tempo para
recorrer a formaes, pedi ajuda a um colega da empresa que conhecia a ferramenta pelo menos
nas suas tasks mais bsicas, e comecei a desenvolver o processo. Tal como em muitos projectos
anteriores, resolvi recorrer ajuda na Web do Google, para pesquisar informao que me ajudasse
a solucionar os problemas que me iam surgindo. Fiquei surpreendido pela falta de informao a
altura relativa a esta ferramenta de integrao. Estando habituado a pesquisar informao para
ferramentas Oracle, onde se encontra efectivamente uma grande quantidade de posts, verifiquei
que no existe informao muito diversificada para o MS IS.
O IS uma ferramenta um pouco enganadora numa primeira abordagem, isto porque parece muito
simples de utilizar. Efectivamente muito fcil construir uma interface simples e num ambiente
que j se encontre estvel, esta vai funcionar com toda a certeza, mas apenas no caso as
manipulaes a efectuar nos dados sejam bsicas. Quando queremos explorar as tasks mais
complexas, em que necessrio usar vrios objectos para o conseguir, nem sempre somos bemsucedidos de forma imediata.
Em temos de performance descobri, na altura que quando utilizamos PL/SQL tasks com
implementao de cdigo directo, que o SQL Server melhora a sua performance com queries em
SQL 92, em detrimento do 86.
60
Ainda assim, e aps o ambiente estabilizado, foi muito rpido adaptar o processo que havia sido
feito por forma a responder ao esperado. Este processo consistia na leitura directa a ficheiros que
eram extrados do SAP BW num determinado dia do ms, sendo que o IS atravs do seu Scheduler
nativo, na data esperada, arrancava com este processo.
O objectivo do processo foi carregar duas tabelas factuais com informao relativa s rubricas de
balano mensais das empresas do grupo Media Capital. O processo de ETL foi constitudo por 7
ficheiros do tipo csv, cada um pertencente a uma empresa e com exactamente o mesmo formato,
Ou seja, 6 campos com separador ; e a primeira linha com o cabealho.
Aps o arranque, a primeira task fazia um ping para verificar a existncia no directrio definido
dos ficheiros esperados. Esta task ficava a correr em background e sempre espera que o ping
retornasse o OK. Depois os ficheiros eram copiados para outro directrio definido como
directrio de trabalho e, s partir deste, iriam ser manipulados pelas restantes tasks, primeiro sendo
copiados directamente para tabelas que constituam a STA. Posteriormente, a partir destas, era
feita a manipulao e o carregamento das tabelas finais, sendo as tabelas destino uma factual e
duas dimenses.
Todo o fluxo de execuo do processo era feito posteriormente no SQL Server Management
Studio.
3.3.3
ACSS
Na ACSS estive envolvido em dois projectos, que decorreram simultaneamente, excepo da

data de arranque que estava desfasada em um ms. Foi um projecto Turn Key com a durao de 18
meses. Tratou-se de um processo extenso e muito interessante no desenvolvimento de uma soluo
End-to-End, desde a interface operacional at ao modelo analtico aplicacional.
Estes projectos merecem ser descritos com pormenor pois espelham o que a maioria dos
consultores de BI esperam um dia encontrar na sua carreira e muitos no conseguem, a soluo
End-to-End. At esta data eu conhecia todas as peas da engrenagem de um processo desta
natureza, mas, nunca tinha estado envolvido desde o momento zero at a passagem a PRD, em
projectos deste nvel. De referir que estes dois projectos foram geridos por mim em simultneo,
embora tenham tido interlocutores diversos e mbitos bem diferentes.
A primeira preocupao aps a definio da data de arranque do mesmo foi a definio da equipa.
Tendo em conta a natureza do processo, iriam ser necessrios incluindo o Project Manager, 4
(quatro) elementos. Eu como Project Manager teria que assumir o desenho de toda a arquitectura a
desenvolver, necessitava de dois elementos totalmente operacionais e mais um que me desse apoio
em toda a fase de anlise funcional e tcnica e, por fim, no desenvolvimento da fase de reporting.
Foi necessrio recorrer subcontratao de um dos elementos da equipa. Assim, contactei algumas
empresas conhecidas na rea de tecnologia como especializadas no chamado Body-Shopping. e
comecei a receber currculos que se enquadrassem. Relativamente a este processo, houve algumas
concluses interessantes que retirei, e que considero importantes partilhar pois espelha um pouco o
mercado ao nvel do BI e Integrao que existe em Portugal na actualidade. O perfil procurado
seria algum com as seguintes caractersticas:
Conhecimento em PL/SQL Oracle e na criao de interfaces;

Formao acadmica relevante;
Experincia profissional superior a 1 ano em ambientes de DW;
Conhecimentos de estruturas de Base de dados Oracle em ambiente distribudo;
Conhecimento em ferramentas de integrao visuais, sendo o ODI/Sunopsys preferencial.
Conhecimentos consolidados de OBIEE;
61
Facilidade de relacionamento interpessoal e trabalho em equipa;

Capacidade de pensamento analtico;
Fluncia em Ingls.
Embora estejamos a falar da franja de mercado onde se situam as empresas de Body-Shopping, que
como sabido, possuem perfis muito diversificados e normalmente focados em vrias reas. O seu
objectivo dar resposta s inmeras solicitaes que lhes vo surgindo. A concluso sobre este
processo foi algo inesperada. O conhecimento em ferramentas de integrao visuais constatou-se
que era inexistente na maioria dos candidatos, e o mesmo em ambientes de DW. Alguns
conheciam superficialmente por terem estado associados a aplicaes que alimentavam ou que
recebiam informao dos mesmos, mas poucos conheciam profundamente em que consistia um
DW, exceptuando que era um repositrio de dados. Conhecimento em ODI coisa quase
inexistente no mercado nacional. Esta ltima situao deixou-me surpreendido tendo em conta o
facto de no passado ter estado integrado nestes ambientes, onde existiam equipas de vrias
consultoras com inmeros elementos. A nica coisa que havia efectivamente muitas respostas
positivas era no conhecimento das BD Oracle em Stand-Alone ou distribudos, e, no domnio da
linguagem PL/SQL. Aps vrias entrevistas chegmos a um candidato que embora no conhecesse
o ODI, tinha todos os restantes requisitos pretendidos. A entrevista decorreu com sucesso e assim
acertmos a sua contratao nessa altura.
Aps o processo de seleco da equipa, e ter vencido mais um desafio, marquei a reunio de Kick
Off para dar inicio ao projecto. Na reunio apresentei os seguintes pontos:
A metodologia de desenvolvimento com cada uma das fases, a sua descrio e os seus
produtos;
A metodologia de PM on-field, com o planeamento da periocidade das reunies;
Identificao dos riscos associados, o tipo de impacto causado, o seu status e as aces que
deveriam ser tomadas de forma a evit-los ou control-los;
Um macro plano temporal das vrias fases do projecto;
A definio da equipa com os respectivos papis e responsabilidades;
A Matriz de responsabilidades da BIMaven e da ACSS, onde estavam enquadrados todos
os elementos envolvidos no projecto, desde o Sponsor, o PM, as equipas funcionais e
tcnicas.
Devido a serem dois projectos a decorrer em simultneo tive que definir os tempos de arranque de
ambos e, esta era uma situao que teria que ser considerada, pois havia estruturas comuns entre
eles. As estruturas destino do projecto operacional eram a fonte do analtico. A diviso foi definida
num projecto que teria como objectivo substituir as interfaces operacionais existentes em PL/SQL
por processos desenvolvidos em ODI, e, outro de criao de um modelo analtico onde seria feita
toda modelao para criao e populao do DW, a criao de um modelo lgico e de negcio j
dentro da ferramenta analtica. Esta diviso foi possvel devido ao facto de todas as estruturas do
modelo operacional se terem mantido praticamente inalteradas com este novo processo, e assim
sendo, as estruturas base necessrias ao modelo de negcio estavam disponveis e com dados
disponveis para anlise.
Estes projectos esto descritos na sua componente tcnica nos captulos 2.1 e 2.2.
62
3.3.4
Groupama Seguros
A minha relao com a Groupama iniciou-se com a criao da proposta para um projecto de
CRM/DQ. Foi a minha primeira participao num projecto totalmente focado no CRM, onde
investiguei sobre as metodologias aplicadas.
O grande objectivo deste projecto seria a melhoria da qualidade da informao de Cliente. O
segundo objectivo seria alterar o conceito de Cliente, visto que uma pessoa introduzida num
sistema deste gnero pode no se tratar de um cliente mas de um prospect. O objectivo final do
projecto seria melhorar a ferramenta de CRM j desenvolvida In-House, e aps este processo,
gerar campanhas de Marketing direccionadas. Para atingir esta situao precisvamos de completar
e enriquecer a informao de cliente.
O problema da qualidade da informao, existe em quase todas as organizaes e entre outras, tem
a ver com a no existncia de processos informticos de DQ, o facto de muitas das regras
existentes internamente no passarem de normas no aplicadas informaticamente ajuda a que estas
situaes se propaguem.
Dividimos o projecto em 6 etapas, que consistiam numa primeira fase de anlise AS-IS, com o
objectivo de obter uma viso global das caractersticas do seu Sistema de Gesto de Clientes e
definir com exactido o mbito do projecto. Assim conheci todas as formas de entrada de clientes
na BD Central da Groupama.
Na construo da especificao funcional propus melhorias ao nvel das regras a implementar
informaticamente e de forma centralizada. Esta centralizao foi fundamental uma vez que se
verificou existirem vrias portas de entrada para a informao de cliente, e era fundamental filtrla antes de chegar s estruturas finais.
Com base nos resultados da fase anterior, foi desenvolvido um mdulo aplicacional Web em que
eram utilizadas as regras de DQ, que definimos e que tinham como objectivo fazer o profiling da
informao, ou seja, detectar por exemplo clientes j existentes para que canalizasse o utilizador
para um ecr de actualizao da sua informao pessoal, no lugar de permitir a introduo repetida
desse cliente.
Teramos ainda de solucionar o problema das duplicaes de registos de clientes j existentes. Para
ajudar nesta tarefa recorremos ferramenta Open-Source, Talend Open Profiler [42], a partir da
qual germos relatrios sobre a qualidade da informao e foi proposta uma nova hierarquia de
registos de pessoas com o conceito Master / Slave. Foram definidas regras que garantiam a
unicidade de cliente na BD e com base nestas e na manipulao de ponderadores na ferramenta de
DQ, germos um universo de possveis duplicados de clientes que foram apresentados
Groupama. De referir que a BD analisada era AS/400. A minha participao no projecto terminou
com esta fase da anlise AS-IS.
3.3.5
FNAC
O projecto na Fnac foi um regresso rea do Retalho, onde aps a minha passagem pela Staples,
existiam razes bvias para o meu envolvimento neste projecto.
O objectivo deste projecto foi a criao de uma nova camada de reporting em Microstrategy sobre
uma fonte de dados analtica Teradata. Trata-se de uma DBMS muito utilizada neste tipo de sector
onde necessrio um motor de BD de alta disponibilidade. A DBMS Teradata disponibiliza
mdulos aplicacionais de BI, mas de baixa complexidade comparativamente ao MSTR. As
caractersticas base desta BD so a alta capacidade de processamento em paralelo e a
63
escalabilidade devido a ter uma boa gesto do balanceamento com vrios servidores disponveis. A
conectividade com esta no nosso caso foi via ODBC, embora tambm pudesse ser feita via JDBC
ou com plugins especficos.
Voltei a participar apenas na fase de anlise, pois entrei no projecto com uma perspectiva mais
comercial. O objectivo consistia em validar os sistemas existentes e as perspectivas que poderiam
existir na implementao de novas solues. No participei activamente no desenvolvimento da
soluo, apenas na especificao funcional.
3.3.1
EFACEC
Neste cliente da rea da indstria, estive envolvido em dois projectos. Um primeiro, onde efectuei
apenas um processo de modelao de informao, utilizando queries numa BD SQL Server 2005,
e que, posteriormente, eram consumidas pelo Microstrategy 8i. Neste projecto assumi um papel
puramente tcnico. Esta camada tinha tambm como objectivo a traduo para Ingls de todos os
objectos existentes na BD, que se deveu internacionalizao da empresa, que hoje j conquistou
inmeros mercados a nvel mundial.
O segundo projecto foi complexo porque consistia na substituio do processo de carregamento
dirio de um DW tendo como fonte um conjunto de ficheiros no formato csv, o maior com
aproximadamente 60 milhes de registos. Foi um projecto complexo onde definimos uma
metodologia de carregamento deste DW utilizando como ferramenta de integrao o MS IS 2005.
Tal como descrevi no projecto da Media Capital, trata-se de uma ferramenta complexa para
produzir mapeamentos que fujam um pouco ao que consideramos bsico. Tentei tirar proveito dos
inmeros objectos que possui, e alguns, acabaram por ser bastante teis como as Slowly Changing
Dimensions, que, eram muito fceis de manipular. Apesar das inmeras dificuldades, o resultado
final foi do agrado do cliente.
3.3.1
ZON
A minha estadia na ZON consistiu num regresso a rea das Telcos. Estive envolvido em dois
projectos, um para construo de Dashboards com indicadores de qualidade operacional, tendo
efectuado o seu Roll-Out, e num outro, ligado a construo de um modelo de anlise de Churn
onde procedi sua especificao em conjunto com a rea de Marketing interna. Em ambos as
tecnologias envolvidas foram o Microstrategy 9i e PL/SQL Oracle.
64
4. Referncias
[1]
[2]
[3]
[4]
[5]
[6]
[7]
http://www.oracle.com/index.html
http://www.microsoft.com/sqlserver/en/us/default.aspx
http://www.teradata.com/
http://www.sybase.com/
http://www-03.ibm.com/systems/i/software/db2/
http://www-03.ibm.com/ibm/history/exhibits/rochester/rochester_4010.html
http://www.microstrategy.com
[8] http://ssdi.di.fct.unl.pt/
[9] http://www.microsoft.com/en-us/default.aspx
[10] http://www.novell.com/home/
[11] http://www.novabase.pt/pt/Pages/NovabaseHome.aspx
[12] http://www.staples.pt/
[13] http://www.bimaven.com/
[14] Ted Friedman, Mark A. Beyer, Eric Thoo, Magic Quadrant for Data Integration
Tools, Gartner, 2009

[15]
http://publib.boulder.ibm.com/infocenter/rentrpt/v1r0m0/index.jsp?topic=%2Fcom.ibm.rationa
l.raer.help.doc%2Ftopics%2Fc_deltaload.html
[16] http://www.sei.cmu.edu/cmmi/
[17] http://www.itil-officialsite.com/
[18] Stephen Few, Information Dashboard Design, The Effective Visual
Communication of Data, OReilly,

[19] http://www.kimballgroup.com/
[20] http://www.kimballgroup.com/html/articles_search/articles1998/9805d05.html
[21]
http://www.kimballgroup.com/html/articles_search/articles2001/0106IE.html?TrkID=IE20010
6
[22]
http://ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101
/Default.aspx
[23] James Richardson, Kurt Schlegel, Rita L. Sallam, Bil Hostmann, Magic Quadrant
for Business Intelligence Plataforms, Gartner, 2009
[24] James Richardson, Rita L. Sallam, Bil Hostmann, Andreas Bitterer, Magic
Quadrant for Business Intelligence Plataforms, Gartner, 2010
[25]
http://www.rittmanmead.com/files/OWB%20Best%20Practices%20%26%20Advanced
%20Features.pdf
[26]
[27]
http://download.oracle.com/docs/cd/B13789_01/server.101/b10759/pseudocolumns00
7.htm
[27] http://www.ptsi.pt/
65
[28] http://www.ptcom.pt/
[29] http://www-01.ibm.com/software/data/infosphere/qualitystage/
[30]
http://www.pmo-projects.com/noticiasanteriores/108-o-maior-projecto-de-ti-daactualidade-em-portugal-esta-a-ser-gerido-atraves-do-metodo-de-earned-value-managementcom-o-apoio-da-pmo-consulting.html
[31] http://www.sap.com/portugal/index.epx
[32] http://www-01.ibm.com/software/data/infosphere/datastage/
[33] http://www.esi.pt/
[34] http://www.staples.pt/
[35] http://www.mediacapital.pt/
[36] http://www.acss.min-saude.pt/
[37] http://www.mdn.gov.pt/mdn/pt/
[38] http://www.efacec.pt/
[39] http://www.fnac.pt/
[40] http://www.groupama.pt/
[41] http://www.zon.pt/
[42] http://www.talend.com/products-data-quality/talend-open-profiler.php
66
5. Bibliografia adicional
Tendo em considerao o facto desta dissertao, se tratar de um relatrio profissional,
deixo aqui referencia para alguns livros, que tenho considerado como auxiliares ao
desenvolvimento do meu trabalho at a data.
Kimball, et al. "The Data Warehouse Lifecycle Toolkit", Wiley, 1998

Kimball, Ross. "The Data Warehouse Toolkit: The Complete Guide to
Dimensional Modeling (Second Edition)", Wiley, 2002
Kimball, Caserta. "The Data Warehouse ETL Toolkit", Wiley. 2004
67
68
Anexos
1. ODI
Vou enumerar as mais-valias que encontrei nesta ferramenta relativamente aos concorrentes que
fui conhecendo, considerando maioritariamente o conhecimento adquirido on the job.
A sua arquitectura por ser E-LT em contraponto com o habitual ETL remove a necessidade de um
servidor de ETL hub, que tipicamente fica situado entre os servidores de origem e destino. Assim
com esta arquitectura, os dados podem ser extrados das suas fontes e carregados no seu destino, e
s posteriormente transformados utilizando o motor de base de dados que acharmos que mais se
adequa transformao requerida, ou que, tenha maior disponibilidade em termos de Down Time.
Esta soluo cabea pode apresentar uma mais-valia em termos de reduo de custos, no tanto
por evitarmos a utilizao do servidor de integrao para realizarmos as transformaes, mas
tambm pelo facto de ao utilizarmos o motor de BD de todos os servidores envolvidos no
processo, necessitamos de ter infra-estrutura com menor capacidade, pois mais facilmente fazem
um load balance desta carga e a tornam numa soluo facilmente escalvel.
Figura 18 - Arquitectura ETL vs EL-T
A utilizao do desenho declarativo ajuda a Abstrair a modelao para um desenho de alto nvel,
simplificar o nmero de passos de um processo e gerar automaticamente o fluxo de dados,
quaisquer que sejam as fontes ou destinos.
69
Figura 19 - Design Declarativo
Claro que nem tudo pode ser apontado como bom e perante a minha experincia encontrei uma
grande limitao neste desenho declarativo, e que, torna a ferramenta menos eficiente
relativamente a outras ofertas que existem no mercado. O facto de no ser possvel ter em cada
interface mais de um destino, ou seja, se quisermos carregar duas estruturas com informao
semelhante, temos que criar e executar duas interfaces.
O facto de o ODI ser totalmente Java based apresenta como grande vantagem a sua mltipla
conectividade, isto porque apenas criando um driver utilizando uma framework de
desenvolvimento e fornecendo a ligao JDBC, possvel ligar a qualquer repositrio. Claro que
este facto apresenta como grande desvantagem, o facto das mensagens de erro e isto relativamente
a muitas outras ferramentas de integrao serem pouco intuitivas numa primeira anlise, pois
validar erros de Java quando se lida com problemas ligados a modelao, no o maior desejo de
um implementador.
Com base neste conceito nasce aquilo que chamamos de agente, que no mais que aplicao
desenvolvida em Java e executvel atravs da comand line e que permite fazer o deploy de um
qualquer processo ETL gerado de forma a poder ser executado remotamente. Mais uma vez ser
apenas necessrio serem configuradas as ligaes JDBC destas interfaces remotas, para o local
onde se encontram os repositrios que integram ou de onde provm os dados. Isto muito til para
solucionar problemas de protocolos de segurana em redes de determinadas organizaes, porque
podemos por vezes no ter acesso a uma determinada fonte ou destino de dados a partir do
servidor de integrao. Neste caso basta ser fornecida uma outra mquina que possua este acesso, e
onde apenas temos de colocar o tal agente, sempre a executar em background. Outra vantagem do
conceito de agente o facto de ser permitida a gesto no ODI de vrios agentes e assim fazer o
Load Balance da carga de um processo entre eles. Para isso, os agentes que executam uma mesma
tarefa tero de estar localizados em mquinas diferentes. O processo que faz este controlo
consegue ver o nmero de sesses abertas de cada agente e assim controlar se um agente est
70
parado ou a executar alguma tarefa pedida. Se a esta funcionalidade adicionarmos o paralelismo

nos processos de ETL, permite-nos optimizar os tempos de execuo.
Para alm do que j descrevi, de referir ainda que o ODI suporta todas as estratgias de
carregamento dos dados como o Bulk Load, Changed Data Capture, Incremental Update ou
Slowly Changing Dimension.
Figura 20 - ODI Operations
Os Knowledge Modules (KMs) que sendo Hot-Pluggable permitem criar uma arquitectura
modular, flexvel e extensvel que apresenta grandes benefcios pois aproveita ao mximo as
optimizaes da BD. A construo de processos medida das Best Pratices reconhecidas no
mercado, facilita a administrao dos processos. Estes KMs no so mais que classes criadas numa
linguagem da prpria ferramenta, e que, contm uma srie de tasks base e que podem ser
customizadas medida. Aquilo que aconteceu nos projectos que desenvolvemos, foi que antes
do incio dos desenvolvimentos, foi estipulado tempo para adaptarmos os KMs j existentes s
necessidades especficas do projecto, tendo ainda criado alguns KMs de raiz especficos para
determinadas tarefas. Esta para mim ser a grande mais-valia desta ferramenta de integrao, pois
no s nos fornece objectos que representam tasks parametrizveis, com muitas concorrentes mas
permite customizar medida cada uma no seu mais nfimo pormenor. Estes KMs tm uma
linguagem base utilizada, mas podem invocar cdigo de vrias linguagens, no apenas PL/SQL
mas Jython, classes Java ou at VB.
Figura 21 - ODI Hot Pluggable
71
2. OBIEE
Esta ferramenta tem uma arquitectura cliente-servidor que se divide em 3 camadas, Physical,
Business Model and Mapping e Presentation
2.1 Principais funcionalidades

Oracle BI Dashboards
Trata-se de um painel onde apresentada informao. Um dashboard pode ter vrias pginas
contendo:
Reports
Grficos
Pastas
Textos
Contedo embebido
Links (navegao assistida, navegao de Briefing Books, Web)
Imagens
O contedo de um dashboard pode ser exportado para formato PDF ou HTML. Desta forma os
dados podem ser visualizados sem que o utilizador esteja ligado rede. possvel guardar uma
imagem do dashboard num Briefing Book, e assim conseguimos guardar o histrico do
Dashboard.
Briefing Books
Trata-se de uma Snapshot do dashboard ou de um report. O seu contedo pode ser esttico ou
dinmico, actualizado ou agendado, podendo ser entregue atravs do Oracle BI Delivers.
possvel tambm, reordenar, apagar ou alterar as propriedades dos contedos de um Briefing
Book, criar links, imprimir, descarregar ou ainda adicionar Briefing Books a dashboards.
Oracle BI Answers
Fornece respostas, permite explorar e interagir com a informao, apresent-la e visualiz-la por
meio de grficos, tabelas pivot e reports.
Podemos gravar, organizar e partilhar os resultados. Os resultados podero ser melhorados atravs
de grficos, layout de resultados, clculos ou drill down. ainda possvel ver quais os reports que
esto a ser usados num dashboard.
Os reports e filtros so guardados em pastas que podem ser partilhadas ou simplesmente
guardados na rea reservada do utilizador.
72
Para cada report possvel criar um iBot, que executa o report numa determinada altura, e que
envia os resultados ou notificao para um ou mais utilizadores.
Oracle Business Intelligence Delivers

a interface utilizada para lanar alertas baseados em resultados analticos. Podem ser detectados
resultados especficos de reports e notificar automaticamente utilizadores atravs da Web, wireless
e telemvel. O Oracle BI Delivers utiliza bots inteligentes ( iBots ) para detectar os resultados.
Os iBots so agentes accionados por horrios ou eventos, que acedem, filtram ou executam
anlises nos dados seguindo um critrio.
Os utilizadores com permisso podem usar o Oracle BI Delivers com o objectivo de definir as
condies para lanar um alerta.
Microsoft Office Plugin

Com este plugin possvel importar tabelas e grficos de dashboards para criao de
apresentaes ou documentos. Depois de importados os dados podem, ver visualizados em modo
offline.
73
2.2 Modos de visualizao

Existem inmeras formas de apresentar indicadores em relatrios, atravs do OBIEE. Nas figuras
seguintes apresento o conjunto das mais utilizadas.
Figura 22 - Grfico de rea
Figura 25 - Grfico Linear
Figura 26 - Grfico de Pareto
Figura 23 - Grfico de barras horizontais
Figura 27 - Grfico de Passo
Figura 24 - Grfico de Barras Verticais
74
Figura 28 - Grfico de Bolhas
Figura 31 - Grfico Gauge
Figura 32 - Grfico Ticker
Figura 29 - Grfico de Radar
Figura 30 - Grfico Circular

Figura 33 - Map Locations
75
Figura 34 - Map Prompt
2.3 Criao de Indicadores

O processo de criao de indicadores processa-se na camada de Server do OBIEE. Nesta temos 3
nveis de metadata. Uma que comporta todo o modelo fsico, nomeada Database, outra com o
modelo lgico, nomeada Business Model e uma terceira com o modelo de visualizao, que estar
disponvel na camada de apresentao nomeado Presentation Catalog.
Atravs do OBIEE permitida a gerao de um documento XML onde toda a metadada descrita,
trata-se de um dicionrio de metadata que descreve de forma minuciosa todo o Repositrio criado.
Assim especificando cada uma das camadas disponveis e fazendo uma abordagem bottom-up. Temos
a seguinte estrutura:
Database, onde temos o nome da base de dados fonte, descemos um nvel para o schema
fonte, o modelo lgico, Logical Framework. Em cada uma destas estruturas podemos validar
os campos que cada uma contm e os respectivos formatos.
Business Model, onde podemos ver separadas:
Dimensions - Dimenses de anlise;
Logical Tables Tabelas de Factos e Agregadoras;
Related Objects Todas as relaes lgicas criadas entre objectos deste modelo
lgico.
Presentation Catalog, onde podemos ver as Presentation Tables:

o
Se quisermos ver em detalhe qualquer um dos objectos envolvidos conseguimos

visualizar a que catalogo pertence cada um, assim como os grupos de utilizadores que
tm acesso ao mesmo. Se quisermos validar quem so os utilizadores referenciados
76
pelo grupo que visvel, basta descermos ao nvel deste grupo e podemos ver todos
os seus elementos, tal como as respectivas permisses de utilizao.
Na rvore primria, podem adicionar-se linhas de tipo dummy, geradas de modo a que
na ferramenta possamos ter disponveis pastas para estruturar a informao.
Em qualquer das estruturas disponveis podemos descer a partir dela at ao nvel mais
baixo, isto , conseguimos visualizar qual a fonte fsica da informao, passando pela
lgica igualmente.
Nas pastas dummy podem existir subpastas contendo indicadores, nestes casos,
quando descemos ao nvel lgico possvel avaliar toda a construo do indicador,
assim como as suas fontes, o nvel de segmentao e agregao em que se encontra se
este for constitudo por vrios objectos lgicos, todos os que tm interveno no
clculo do referido.
O Dicionrio de metada encontra-se totalmente descrito numa extraco em XML em dois

formatos possveis, ou rvore, Tree Index ou Dicionrio, Name Index.
77
78
Andr Correia
2011
79

Dados, Informaçao, Conhecimento - Business Inteligence e Suas Motivaçoes

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Dados, Informaçao, Conhecimento - Business Inteligence e Suas Motivaçoes

Hochgeladen von

Copyright:

Verfügbare Formate

Andr Ramos Jorge Correia

Licenciado em Engenharia Informtica

Dados, Informao, Conhecimento, o

Dissertao para obteno do Grau de Mestre em

Orientador: Paulo Orlando Reis Afonso Lopes,

Presidente: Prof. Doutor Joaquim Francisco Ferreira da Silva, FCT-UNL-DI

Actividade Profissional .................................................................................................. 17

Projectos mais relevantes............................................................................................... 23

Projecto de criao de interface operacional na ACSS ....................................... 23

Requisitos e Motivao ....................................................................................... 24

Soluo Tcnica e Execuo do Projecto .......................................................... 25

Arquitectura Macro ........................................................................................ 26

Modelo Fsico de estruturas de dados ............................................................ 27

Framework de carregamento ......................................................................... 30

Processos de integrao ................................................................................... 35

Anlise de Resultados ......................................................................................... 35

Requisitos e Motivao ....................................................................................... 36

Soluo Tcnica e Execuo do Projecto .......................................................... 36

Arquitectura Macro e modelo fsico .............................................................. 40

Anlise de Resultados ......................................................................................... 51

Analise aprofundada do percurso profissional............................................................ 53

ESI Espirito Santo Innovation ........................................................................ 54

ESCOB Esprito Santo Cobranas ................................................................. 56

Evoluo - Staples ................................................................................................... 56

Consolidao - BIMaven ........................................................................................ 58

Media Capital ...................................................................................................... 60

Groupama Seguros .............................................................................................. 63

Bibliografia adicional ..................................................................................................... 67

Principais funcionalidades ..................................................................................... 72

Modos de visualizao ............................................................................................ 74

Criao de Indicadores ........................................................................................... 76

Figura 23 - Grfico de barras horizontais ........................................................................... 74

Administrao Central dos Sistemas de Sade

Oracle Business Intelligence Enterprise Edition

Figura 1 - reas Centrais de Actividade nas TI

Minicomputador IBM com arquitectura EBCDIC, actualmente substitudo pelos iSeries

Figura 2 - Cadeiras efectuadas durante a licenciatura da seco de SSDI

De seguida apresento o resumo do meu percurso dentro da Engenharia Informtica.

Montagem de mquinas e storage;

Figura 3 - Fases de carreira

Estas fases tero coincidido em termos temporais:

Figura 4 Entidades empregadoras durante a carreira

Figura 5 - Clientes por Empresa Empregadora

2. Projectos mais relevantes

Carregamento automatico ao N dia de cada ms

Figura 6 - Modelo de Alto Nvel de Integrao Operacional

Os automatismos criados deveriam permitir um aumento de produtividade, libertando assim as

Em termos do que foi proposto, as caractersticas do novo processo foram:

Funcionamento de forma totalmente automtica inclusive na gesto de falhas;

Qualquer interveno humana, quando necessria, seria solicitada. Isto garantia a no

Criao de uma framework de controlo de processos comum a todos os projectos gerados na

Gesto automtica de registos rejeitados com a gerao de mensagens de aviso;

Controlo de falhas e erros ao longo de todo o processo;

A ferramenta de integrao escolhida teria que gerar alertas e avisos relativos ao

Eliminar ao mximo a interveno humana na totalidade da execuo e monitorizao dos

Optimizar o processo de validao da informao carregada para ser efectuado apenas no

Incrementar a controlo nos acessos a BD ou nas operaes sobre a mesma, eliminando

Soluo Tcnica e Execuo do Projecto

Ambiente de DSV, onde feita a criao, explorao e testes unitrios;

Disponibilidade do servidor de integrao instalado e configurado com acesso a todos os

Figura 7 - Quadrante Mgico de integrao do Gartner Group para 2009

2.1.3.2 Arquitectura Macro

Integrao com ODI

Figura 8 - Viso Macro do Projecto de Integrao