"

! " # !
$
% &#

! ' " !
# ( " )
% &#
%

)* " +,,-
 Micaela Lima, 2009

&&
 #

A migrao de dados pode ser descrita como um conjunto de actividades, que transfere dados a
partir de um ou mais sistemas fonte para um novo sistema, com o objectivo de preservar o core
business e torn-lo acessvel a partir da nova aplicao.
O processo de migrao de dados algo complexo e o seu sucesso depende de vrios factores que
passam por compreender os requisitos do cliente relativamente aos dados a migrar e s respectivas
regras de negcio, de modo a que este se envolva no processo de migrao e apoie as decises sobre
quais os dados a migrar.
A grande variedade de sistemas aplicacionais obsoletos disponveis nas instituies incentiva a
necessidade de migrar os dados dos sistemas aplicacionais legados para novas solues. O trabalho
que a seguir se apresenta, no mbito da migrao de dados, tem como objectivo desenvolver uma
ferramenta de migrao de dados de diversos sistemas fonte, sobre os quais no se tem conhecimento
prvio, para um novo sistema - ALERT, a qual se designa por Data Migration Framework.
Esta nova ferramenta de migrao de dados envolve extraco de dados do sistema fonte, limpeza
para reparar dados corrompidos ou invlidos e remoo de registos duplicados. Efectua-se assim uma
transformao na fonte de dados de modo a que este fique de acordo com as exigncias do sistema
destino, traduzindo os valores para a nova fonte de dados, com base numa rea intermdia onde feito
o primeiro carregamento com informao do sistema fonte, atravs de tabelas de mapeamento e
funes auxiliares que permitem migrar os dados com preciso e num perodo de tempo exguo.
Os resultados principais do trabalho so a ferramenta de migrao de dados e uma ferramenta
complementar de monitorizao do processo. A ferramenta de migrao j foi utilizada para testes
reais num caso concreto, na Holanda, com resultados satisfatrios.

Palavras-chave: Extraco de dados, Transformao de dados, Mapeamento de dados, Migrao

de dados, Carregamento de dados.

&&&
&
 $ %

Data migration can be described as a set of activities, which transfers data from one or more
source systems to a new system, in order to preserve the core business and make it accessible for the
new application.
The data migration process is quite complex and its success depends on several factors, among
them, understanding the customer requirements of the data to be migrated, their business rules so that
the customer become involved in the migration process, and support the decisions to identify what
data must be migrated.
The variety of obsolete application systems within a company or institution encourages the need to
migrate data from legacy systems to new solutions. The work that is presented below, concerning data
migration, is about developing a generic framework to migrate data from different unknown source
systems, to a new system - ALERT, namely Data Migration Framework.
This new Data Migration Framework involves extracting data from different source systems, data
cleansing to repair corrupted or invalid data, removing duplicate records, transforming the source data
in order to match with the requirements of the destination system, reflecting the values for the new
data source, based on a staging area where is done the first upload with the source information, using
mapping tables and auxiliary functions that allow migrating the data accurately and within a short and
limited period of time.
The main results of this work are the data migration framework and an additional framework
to monitoring the data migration process. The data migration framework has already been tested in a
real case in the Netherlands with satisfactory results.

Key words: Extract data, Transform data, Mapping data, Data Migration, Load data.
&
 & % ' %

Nos termos do acordo de confidencialidade celebrado com a ALERT Life Sciences Computing,
S.A. (ALERT), o presente relatrio confidencial e poder conter referncias a invenes,
know-how, desenhos, programas de computador, segredos comerciais, produtos, frmulas, mtodos,
planos, especificaes, projectos, dados ou obras abrangidos por direitos de propriedade industrial
e/ou intelectual da ALERT. Este relatrio s poder ser utilizado para efeitos de investigao e de
ensino. Qualquer outro tipo de utilizao est sujeita a autorizao prvia e por escrito da ALERT.

&&
 %

Ao meu orientador, Professor Doutor Gabriel David, a disponibilidade e motivao

demonstrada, assim como, as crticas e sugestes formuladas que foram fundamentais ao
desenvolvimento deste projecto.

Ao Eng. Hugo Firmino, a oportunidade e apoio necessrio para desenvolver este projecto.

A todos os colegas da ALERT, em especial aos elementos que constituem a equipa de

Migraes, cuja participao neste projecto, contribuiu para a concretizao do mesmo.

Aos meus pais e av, que sempre me incentivaram a continuar mesmo nos momentos de menor
alento.

Ao Pedro Amorim, pela compreenso e pelo tempo que lhe subtra em favor deste projecto.

&&&
&.
( %

RESUMO ............................................................................................................................................................ III

ABSTRACT .......................................................................................................................................................... V

POLITICA DE PRIVACIDADE ..................................................................................................................... VII

AGRADECIMENTOS.....................................................................................................................................VIII

NDICE ................................................................................................................................................................. X

LISTA DE FIGURAS ......................................................................................................................................XIII

LISTA DE TABELAS ...................................................................................................................................... XV

ABREVIATURAS E SMBOLOS .................................................................................................................. XVI

CAPTULO 1 ...................................................................................................................................................... 17

INTRODUO ..................................................................................................................................................... 17
1.1 ALERT Life Sciences Computing, S.A .................................................................................................. 17
1.2 Pertinncia do projecto ........................................................................................................................ 19
1.3 Desafios do projecto ............................................................................................................................ 20
1.4 - Objectivo do projecto............................................................................................................................ 21
1.5 Estrutura da dissertao ...................................................................................................................... 21

CAPTULO 2 ...................................................................................................................................................... 23

MIGRAO DE DADOS ........................................................................................................................................ 23

2.1 Conceito de migrao de dados ........................................................................................................... 23
2.2 Conceito de ETL................................................................................................................................... 25
2.3 Arquitectura ETL ................................................................................................................................. 27
2.4 Arquitectura E-LT no Oracle Data Integrator ..................................................................................... 30
2.5 Estrutura do Oracle Data Integrator ................................................................................................... 34

.
CAPTULO 3 ...................................................................................................................................................... 37

ANLISE DA FERRAMENTA DE MIGRAO DE DADOS ....................................................................................... 37

3.1 Projecto de migrao de dados............................................................................................................ 37
3.2 Dificuldades nos projectos de migrao .............................................................................................. 39
3.3 Requisitos Funcionais e No Funcionais ............................................................................................. 41
3.4 Ambientes no processo de migrao .................................................................................................... 42

CAPTULO 4 ...................................................................................................................................................... 48

DESENVOLVIMENTO DA FERRAMENTA DE MIGRAO DE DADOS ...................................................................... 48

4.1 Definio da Arquitectura .................................................................................................................... 48
4.1.1 Processo de Recolha dos Dados .................................................................................................. 50
4.1.2 Processo de Qualidade dos Dados............................................................................................... 51
4.1.3 Processo de Carregamento .......................................................................................................... 52
4.1.4 Processo de Mapeamento............................................................................................................. 52
4.1.5 Processo de Migrao .................................................................................................................. 53
4.1.6 Processo de Notificao ............................................................................................................... 53
4.1.7 Processo de Monitorizao .......................................................................................................... 54
4.2 Sequenciao das actividades .............................................................................................................. 54
4.3 Modelos de Dados ................................................................................................................................ 57
4.3.1 - Schemas Relacionais..................................................................................................................... 57
4.3.2 Nomenclatura e estrutura das tabelas.......................................................................................... 59
4.3.3 Parametrizao de registos .......................................................................................................... 63
4.4 - Desenvolvimento da Data Migration Framework ................................................................................ 64
4.4.1 - Extraco de Dados em XML ....................................................................................................... 64
4.4.2 Configuraes no Oracle Data Integrator ................................................................................... 67
4.4.3 Desenvolvimentos no Oracle Data Integrator ............................................................................. 76
4.4.4 - Implementao da Data Migration Framework ........................................................................... 91
4.4.5 Ferramenta de monitorizao ...................................................................................................... 91

CAPTULO 5 ...................................................................................................................................................... 98

AVALIAO DA FERRAMENTA DE MIGRAO DE DADOS .................................................................................. 98

5.1 Resultados ............................................................................................................................................ 98

CAPTULO 6 .................................................................................................................................................... 101

CONCLUSES ................................................................................................................................................... 101

REFERNCIAS ................................................................................................................................................ 103

BIBLIOGRAFIA ............................................................................................................................................... 104

.&
ANEXOS ............................................................................................................................................................ 107

ANEXO A - CHECKLIST DE IMPLEMENTAO.................................................................................................... 108

ANEXO B TABELAS DO SCHEMA STAGING .................................................................................................. 114
ANEXO C TABELAS DO SCHEMA MIGRA ...................................................................................................... 116
ANEXO D FERRAMENTA DE MONITORIZAO .............................................................................................. 119

.&&
 ) #

Figura 1- Arquitectura ETL .................................................................................................................................. 25

Figura 2 - Empresas lderes no mercado de ETL .................................................................................................. 26

Figura 3 - Exemplo de arquitectura com rea intermdia no sistema de destino .................................................. 28

Figura 4 - Exemplo de arquitectura com rea intermdia no sistema origem ....................................................... 28

Figura 5 Exemplo de arquitectura com rea intermdia num servidor prprio .................................................. 29

Figura 6 - Arquitectura E-LT ................................................................................................................................ 30

Figura 7 - Arquitecturas E-LT, no processo de migrao, usando o ODI ............................................................. 31

Figura 8 Desenho Declarativo do Oracle Data Integrator ................................................................................ 32

Figura 9 - Definio de regras de integridade e posterior validao ..................................................................... 33

Figura 10 - Interfaces grficos conectados ao repositrio ..................................................................................... 35

Figura 11 - Exemplo de repositrios mestre e de trabalho .................................................................................... 36

Figura 12 - Ambientes envolvidos no processo de migrao ................................................................................ 44

Figura 13 - Processo de migrao para o ALERT............................................................................................... 45

Figura 14 - Progresso do processo de migrao para o ALERT ......................................................................... 47

Figura 15 - Descrio da Data Migration Framework .......................................................................................... 49

Figura 16 - Progresso dos processos da Data Migration Framework ................................................................... 56

Figura 17- Schemas de base de dados ................................................................................................................... 58

Figura 18 - Package para criao de ficheiros XML ............................................................................................ 65

Figura 19 - Package para criao de ficheiros XSD ............................................................................................. 66

Figura 20 Validar o ficheiro XML com o ficheiro XSD .................................................................................... 66

.&&&
Figura 21 Exemplo de contextos ODI ................................................................................................................ 67

Figura 22 - Topologia ODI ................................................................................................................................... 68

Figura 23 - Seleco do contexto de reverse ......................................................................................................... 70

Figura 24 - LKM Oracle to Oracle (DBLINK) ..................................................................................................... 71

Figura 25 - IKM Oracle Incremental Update (PL SQL) ....................................................................................... 72

Figura 26 - JKM Oracle 10g Consistent (LOGMINER) ....................................................................................... 73

Figura 27 - Seleco do JKM, para o modelo ....................................................................................................... 74

Figura 28 - Adicionar tabela ao CDC.................................................................................................................... 75

Figura 29 - Criao de Subscriber ........................................................................................................................ 75

Figura 30 - Activao do Journal .......................................................................................................................... 76

Figura 31 Progresso XML/STAGING ............................................................................................................... 79

Figura 32 - Processos relacionados com as tabelas jornalizadas ........................................................................... 80

Figura 33 - Progresso STAGING/MAP OLD para tabelas do tipo CA_ ........................................................... 81

Figura 34 - Progresso STAGING/MAP OLD para tabelas do tipo CC_ ........................................................... 83

Figura 35 - Progresso STAGING/MAP OLD para tabelas do tipo CO_ ........................................................... 83

Figura 36 - Progresso MAP OLD/MAP NEW para tabelas do tipo CC_ .......................................................... 84

Figura 37 - Progresso MAP OLD/MAP NEW para tabelas do tipo CO_ .......................................................... 85

Figura 38 - Progresso MAP NEW/ALERT para tabelas do tipo CC_ ............................................................. 87

Figura 39 - Progresso MAP NEW/ALERT para tabelas do tipo CO_ ............................................................. 88

Figura 40 - Progresso STAGING/MAP OLD/MAP NEW/ALERT ................................................................... 90

Figura 41 - Progresso global ................................................................................................................................. 90

Figura 42 Pgina 1 (Performance ODI-Package) .............................................................................................. 92

Figura 43 Pgina 2 (Performance ODI-KM)...................................................................................................... 93

Figura 44 Pgina 3 (Validate ODI-KM) ............................................................................................................. 94

Figura 45 Pgina 4 (Validate DB-Package) ....................................................................................................... 95

Figura 46 Pgina 5 (Analyze all errors) ............................................................................................................. 96

.&
 $ &

Tabela 1 - Requisitos Funcionais .......................................................................................................................... 42

Tabela 2 - Requisitos No Funcionais................................................................................................................... 42

Tabela 3 - Descrio da estrutura de uma tabela de mapeamento ......................................................................... 52

Tabela 4 - Definio de alias de tabelas do schema STAGING ........................................................................... 59

Tabela 5 - Exemplo de uma tabela do tipo "CA_" ................................................................................................ 60

Tabela 6 - Exemplo de uma tabela do tipo "CC_" ................................................................................................ 61

Tabela 7 - Descrio de tabelas do tipo "CO_" ..................................................................................................... 61

Tabela 8 - Exemplo de uma tabela de Mapeamento.............................................................................................. 62

Tabela 9 - Exemplo de uma tabela de log ............................................................................................................. 63

Tabela 10 - Prefixo de tabelas e views internas do ODI ........................................................................................ 74

Tabela 11 - Criao das tabelas de mapeamento e de log ..................................................................................... 77

Tabela 12 - Carregamento inicial das tabelas jornalizadas ................................................................................... 81

Tabela 13 - Funes referentes ao processo da STAGING/MAP OLD ................................................................ 82

Tabela 14 - Funes referentes ao processo da MAP OLD/MAP NEW ............................................................... 86

Tabela 15- Funes referentes ao progresso da MAP NEW/ALERT ................................................................. 89

Tabela 16 - Funes de monitorizao .................................................................................................................. 97

Tabela 17 - Resultados da migrao no Hospital de Bernhoven ........................................................................... 99

.
 $ ' # * $ &

ALERT Alert Life Sciences Computing, S.A.

ALERT Suite de produtos ALERT
API Application Programming Interface
DMF Data Migration Framework
E-LT Extract Load Transform
ETL Extract Transform Load
FEUP Faculdade de Engenharia da Universidade do Porto
HIMSS Healthcare Information and Management Systems Society
HITSP Healthcare Information Technology Standards Panel
HL7 Health Level 7
ICD9 International Classification of Diseases version of 2009
ICNP International Classification for Nursing Practice
IHE Integrating the Healthcare Enterprise
LOINC Logical Observations Identifiers, Names, Codes
ODI Oracle Data Integrator
PFH Paper Free Hospital
RHIO Regional Health Information Organizations
SNOMED CT Systematized Nomenclature of Medicine - Clinical Terms
XML eXtensible Markup Language
XSD XML Schema

. &
 /
!

!* #& +

A evoluo da utilizao de sistemas de informao nas organizaes coloca o problema da

migrao de dados das aplicaes legadas para novas solues. Este um problema crucial para a
disseminao de novas aplicaes na rea da sade, uma vez que o grau de informatizao neste sector
j elevado.
Foi este desafio que motivou e impulsionou a presente dissertao, a qual se enquadra no
contexto do desenvolvimento de uma ferramenta genrica que optimize o processo de recepo de
dados de qualquer sistema fonte, da rea da sade, e a integrao num novo sistema, de entre a suite
de produtos da empresa ALERT, produtora de software clnico e no clnico, onde a autora se
encontra a trabalhar.

+,+ - ) % % !# . ,

A misso da empresa ALERT consiste em melhorar a sade e prolongar a vida, alcanar

rentabilidade para benefcio da sociedade e inspirar outros para a excelncia, atravs do seu exemplo.
O Grupo de Empresas ALERT dedica-se ao desenvolvimento, distribuio e implementao do
software de sade ALERT, concebido para criar ambientes clnicos sem papel.
A ALERT comeou a sua actividade em Dezembro de 1999. A actualmente, o Grupo conta com
uma equipa multidisciplinar de cerca de 700 colaboradores a tempo inteiro, que inclui mdicos,
designers, arquitectos, engenheiros, consultores, matemticos e gestores. A ALERT segue directivas
internacionais para interoperabilidade e normalizao no desenvolvimento de software, faz parte da

01
 /
!

iniciativa IHE (Integrating the Healthcare Enterprise) e membro activo da HL7 (Health Level 7). A
ALERT participa na Distributed Interoperability Showcase (RHIO scenario) e New Directions
(HITSP - Healthcare Information Technology Standards Panel) Showcase, eventos promovidos pela
HIMSS (Healthcare Information and Management Systems Society), da qual a ALERT Platinum
Corporate Member. Para alm disto, o ALERT utiliza nomenclaturas padro como o SNOMED CT,
ICD9, LOINC e a ICNP.
O ALERT uma ferramenta operacional para todos os ambientes de prestao de cuidados de
sade e para todos os profissionais da rea da sade com a capacidade amplamente demonstrada de
produzir ambientes totalmente isentos de papel. O dirio online O Mirante publicou recentemente
uma notcia que confirma duas das caractersticas mais relevantes do ALERT, ou seja, a capacidade
de detectar falhas, muitas vezes graves, nos servios de sade e a maior rapidez de comunicao entre
servios ou instituies hospitalares [1].
Na base do ALERT encontra-se a noo de fluxo de trabalho que permite o envio de
informao a utilizadores relevantes e interliga as actividades de todos os profissionais de sade, o que
torna possvel:
Destacar para cada utilizador actividades especficas e reas de trabalho;
Apresentar informao constantemente actualizada em formato de grelha sumrio para cada
perfil de utilizador e utilizador individual;
Alertar cada utilizador para tarefas pendentes.
O ALERT constitudo por uma vasta gama de produtos, entre eles: ALERT EDIS, ALERT
INPATIENT, ALERT OUTPATIENT, ALERT ORIS, ALERT DATA WAREHOUSE, ALERT
PFH. Com estes produtos possvel registar toda a informao em tempo real, permitindo a partilha
da informao, facilitando o acesso ao histrico do utente e evitando problemas de legibilidade e de
comunicao.
O ALERT EDIS (Emergency Department Information System) uma soluo completa
para servios de urgncias hospitalares que possibilita o registo, a anlise e a integrao de toda a
informao relacionada com cada episdio de urgncia. A primeira verso deste produto designada
por ALERT ER (Emergency Room).
O ALERT ORIS (Operating Room Information System) permite gerir toda a informao
relacionada com as aces desempenhadas no bloco operatrio.
O ALERT INPATIENT corresponde a um sistema capaz de gerir informao relativa a
servios de Internamento.
O ALERT OUTPATIENT uma soluo que possibilita a gesto das Consultas Externas
em ambientes de prestao de cuidados de sade.
O ALERT DATA WAREHOUSE, permite analisar no s dados clnicos mas tambm
financeiros e comparar os resultados obtidos com outras instituies.

02
 /
!

O ALERT PFH inclui as solues ALERT EDIS, ALERT OUTPATIENT, ALERT

ORIS e ALERT INPATIENT.

+,/ - 0 % ! 1 %

A adopo do sistema ALERT por parte de uma instituio hospitalar traduz-se num projecto
de difcil implementao, pois, para alm dos aspectos relacionados com a implantao, formao dos
utilizadores e mudana de procedimentos, acarreta ainda os problemas de como lidar com os dados
pr-existentes em papel ou em sistemas aplicacionais variados e de minimizar a durao da fase de
transio.
O mtodo a definir para a migrao de dados utilizado para um determinado sistema depende
fundamentalmente dos sistemas fonte envolvidos, bem como da natureza e do estado dos dados que
sero migrados. Para isso, necessrio fazer uma anlise aos sistemas fonte e ao sistema de destino
para determinar se a migrao pode ser feita com um risco reduzido. A anlise aos sistemas pode ser
realizada em diferentes fases.
Numa primeira fase preciso definir exactamente qual a informao que o cliente pretende
migrar para o sistema ALERT e em que formato se encontra a informao. Os dados esto, muitas
vezes, em formato digital, guardados quer em base de dados, quer em ficheiros de texto. Caso exista
informao que no possa ser incorporada no sistema ALERT, essencial adoptar um mecanismo
para armazenar essa informao, de modo a que os dados do sistema fonte no sejam perdidos.
Numa segunda fase, realiza-se a migrao dos dados. A arquitectura dos sistemas fonte
geralmente muito diferente da do sistema de destino e os sistemas fonte nem sempre cumprem os
critrios estabelecidos no novo sistema. Esta situao pode tornar complexa a migrao de dados para
o sistema de destino. Com efeito, o processo de limpeza e manipulao dos dados pode permitir que
estes fiquem em conformidade com os requisitos do novo sistema. Caso contrrio, tero de ser
adoptadas solues especficas que passam por armazenar determinada informao do sistema fonte
numa rea especificada pelo cliente ou, se possvel, a ALERT poder desenvolver novas
funcionalidades para ir de encontro ao pedido do cliente.
Quando uma organizao passa de um sistema antigo para um novo sistema como o ALERT,
pretende preservar o mximo de dados histricos para fins de auditoria e pesquisa e para as
actividades organizacionais em curso. A migrao de dados entre sistemas a actividade que as
organizaes que pretendem renovar os seus sistemas antigos tm que realizar, com a preocupao de
minimizar a perda de informao na transio para o novo sistema. Numa migrao realizada uma
anlise dos sistemas fonte e do novo sistema com o intuito de identificar o melhor mtodo para migrar
os dados, tendo em ateno os prazos impostos pelo cliente e os perodos de paragem, que afectem
0-
 /
!

minimamente a organizao, at o novo sistema estar operacional. garantida a duplicao de todos

os sistemas fonte para que eventuais erros que possam surgir sejam simples de reparar, permitindo
recuperar os dados do sistema fonte. Aps a anlise efectuada devem ser elaborados testes de todas as
fases importantes da migrao no sentido de se apurar se a mesma est a ser bem executada.
Assim, e face diversidade de aplicaes disponveis nos hospitais, torna-se pertinente
desenvolver uma ferramenta que no dependa exclusivamente de um sistema fonte e permita transferir
mais facilmente os dados para o ALERT.

+,2 - ) ! 1 %

Em situaes anteriores, as migraes na ALERT eram baseadas num nico sistema fonte e
tratadas de forma ad hoc. Nestes casos o sistema fonte e o sistema de destino eram conhecidos, pois
tratava-se da migrao do produto ALERT ER para o produto ALERT EDIS.
Recentemente na Holanda surgiu um novo desafio para a ALERT, que consiste em migrar dados
de vrios sistemas fonte em simultneo, sobre os quais no se tem qualquer conhecimento prvio, para
o sistema ALERT. Este novo desafio impulsionou o desenvolvimento de uma ferramenta especfica e
motivou o presente projecto. Esta nova ferramenta, a qual se designa por Data Migration Framework
(DMF), no de implementao simples, na medida em que constitui um sistema complexo, no qual
existem mltiplas variveis que se inter-relacionam de diferentes formas.
A Data Migration Framework a ferramenta de migrao de dados que vai permitir transferir
mais facilmente dados de vrios sistemas antigos para o ALERT. Todas as transferncias de dados
podero ser executadas manualmente numa base ad hoc, ou programadas em determinados intervalos
de tempo.
Para dar resposta ao desafio definido neste projecto, subdividimo-lo num conjunto de seis
sub-desafios que passam por:
1 - Processar grande volume de dados.
2 - Migrar dados num tempo reduzido.
3 - Minimizar o perodo de paragem.
4 - Gerir interdependncias entre funcionalidades a migrar.
5 - Identificar e suportar as dependncias entre os dados.
6 - Demonstrar o sucesso do processo de migrao de dados.
No desenvolvimento da ferramenta de migrao de dados, estes sub-desafios so de natureza
diversa mas do sucesso na sua ultrapassagem que depende o resultado de um sistema de migrao.

+,
 /
!

+,3 4 $1 % ' ! 1 %

O objectivo global deste projecto consiste em desenvolver uma ferramenta de migrao de dados
para o sistema ALERT, com generalidade no tratamento da informao dos sistemas fonte,
suportando informao estruturada e no estruturada. Nesse sentido, ser dada grande importncia
implementao de uma arquitectura que permita utilizar a ferramenta desenvolvida em cenrios reais.
Para ir de encontro ao objectivo proposto, especifica-se as seguintes caractersticas e
condicionantes:
Permitir migrar dados de vrios sistemas fonte, sobre os quais no se tem qualquer
conhecimento prvio.
Incorporar o mximo de informao histrica, dos sistemas fonte, na aplicao ALERT.
Melhorar a capacidade de organizar os processos envolvidos na migrao.
Maximizar o desempenho do processo de migrao, minimizando o tempo de migrao de
dados.
Utilizar rapidamente a nova aplicao, ALERT, enquanto se desligam os sistemas antigos.
Se necessrio, manter os sistemas antigos em paralelo com a nova aplicao.

+,5 - # #

A presente dissertao encontra-se estruturada em seis captulos.

O captulo um constitui a Introduo, na qual se encontra relatado de forma sucinta todo o
projecto. Neste captulo, tambm descrito a pertinncia, os desafios, o objectivo e a estrutura do
projecto.
No captulo dois inclui-se informao fundamentada e comparada sobre o tema tratado, com
base na reviso da literatura que permitiu adquirir conhecimentos mais precisos sobre como a
comunidade cientfica tem abordado a questo da migrao de dados.
No captulo trs feita uma anlise da ferramenta de migrao de dados, sendo tambm
identificados os respectivos requisitos funcionais e no funcionais.
No captulo quatro descrevem-se os aspectos essenciais ao desenvolvimento deste projecto, que
se traduzem na definio da arquitectura, modelo de dados e questes de implementao. Faz-se ainda
uma referncia aos instrumentos considerados necessrios elaborao da ferramenta de migrao de
dados e ferramenta complementar de monitorizao.
No quinto captulo, so apresentados e analisados os resultados obtidos durante um caso de teste
de aplicao do projecto. Neste captulo procura-se ainda dar significado aos resultados obtidos,
interpretando-os, relacionando-os e integrando-os na reviso da literatura efectuada.
+0
 /
!

No captulo seis, sintetizam-se os resultados mais relevantes do trabalho, apontam-se as

principais limitaes da investigao e definem-se perspectivas para projectos futuros.

++
 /
!

!* #& /

Neste captulo pretende-se abordar a reviso da literatura efectuada com o intuito de adquirir um
conhecimento mais preciso sobre a questo da migrao de dados, os diversos tipos de arquitectura e a
relao com o Oracle Data Integrator.

/,+ - %

A migrao de dados consiste no processo de transferncia de dados de um ou mais sistemas

fonte para um sistema de destino. Esta operao geralmente necessria quando uma organizao
decide mudar o seu sistema aplicacional para um novo, tendo como requisito a preservao dos dados
histricos, o que implica torn-los acessveis a partir do novo sistema aplicacional. No entanto, muitas
empresas deixam de adquirir melhor software e servios pois acreditam que a migrao de dados
difcil, complexa e que ir dificultar o seu normal funcionamento. Actualmente, o processo de
migrao de dados de aplicaes dspares para um nico sistema integrado um desafio bastante
frequente para as organizaes e consequentemente para as equipas responsveis pelo processo.
As tcnicas de migrao de dados so mltiplas e passam por carregar os dados manualmente,
mover ficheiros de um disco para outro, inserir registos numa base dados, desenvolver um software
medida, entre outras. Definir a tcnica a utilizar depende do volume dos dados, da qualidade dos
dados do sistema fonte, da possibilidade de estabelecer uma correspondncia mais ou menos perfeita
entre os modelos fonte e de destino, dos recursos (tempo e oramento) disponveis, etc. Em muitas
situaes recorre-se combinao das vrias tcnicas referidas.

+3
 /
!

O processo de migrao de dados desdobra-se, normalmente, em trs fases:

A fase de anlise do sistema fonte que inclui auditoria qualidade dos dados e consequente
anlise do sistema de destino e estabelecimento do mapeamento dos dados entre ambos os sistemas.
A fase de extraco, transformao e carregamento que consiste em extrair os dados do
sistema fonte, adaptar os dados estrutura do novo sistema e posterior carregamento dos dados no
sistema de destino.
A fase de validao e correco dos dados que normalmente utilizada na migrao com o
objectivo de melhorar a qualidade dos dados, eliminar a redundncia ou informao obsoleta, e ir ao
encontro dos requisitos do novo sistema. A qualidade dos dados um problema particularmente difcil
na migrao de dados entre sistemas, principalmente quando muitos dos dados do sistema fonte no
obedecem s regras definidas no novo sistema.
As diferentes fases da migrao de dados para aplicaes de complexidade moderada a alta, so
normalmente repetidas vrias vezes, em ambiente de pr-produo, antes do novo sistema ser
implementado.
A migrao de dados um processo complexo e o seu sucesso depende de vrios factores, dos
quais se destaca:
Definir as expectativas do projecto com o cliente e geri-las durante o processo dado que de
um modo global o cliente normalmente no compreende o tempo e o esforo necessrio para migrar
os dados, o que resulta em expectativas erradas do projecto de migrao. Ao clarificar as expectativas
o cliente fica preparado para formar as decises necessrias em todo o processo de migrao.
Apreender as exigncias dos dados para o negcio. A migrao de dados requer uma
compreenso do modelo de dados do negcio da organizao de modo a que o cliente apoie as
decises necessrias sobre quais os dados a migrar.
Descrever claramente as responsabilidades no processo de migrao na medida em que
permite definir quem faz o qu nas vrias fases do processo de migrao desde definir quando e como
os problemas sero tratados e quem ir extrair os dados do sistema fonte.
Compreender o sistema de destino, isto , compreender o modo como o sistema de destino
representa os dados essencial para o sucesso da migrao. As associaes suportadas pelo modelo de
destino podem referir-se a dados dispersos por vrios sistemas de origem e consequentemente pode
no ser fcil extrair destes a informao necessria para estabelecer aquelas associaes.

+4
 /
!

/,/ - %

O processo de ETL, adaptado do ingls Extract Transform Load (Extraco Transformao

Carregamento), envolve a extraco de dados de diversos sistemas externos, transformao desses
dados para atender s diferenas de representao entre os modelos antigo e novo e o carregamento
dos dados no sistema de destino, como ilustra a Figura 1.

Figura 1- Arquitectura ETL

O termo ETL representa tanto os nomes como a ordem das operaes a realizar. A fase de
transformao de dados no processo de ETL a que mais esforo computacional requer e realizada
inteiramente pelo motor proprietrio de ETL. O motor de ETL realiza a transformao dos dados e por
vezes a validao da qualidade dos mesmos, linha a linha e, consequentemente pode, com alguma
facilidade, tornar-se no ponto de estrangulamento no processo global.
Os projectos de migrao consolidam frequentemente dados de diferentes fontes. A maioria
dessas fontes tendem a ser bases de dados relacionais ou Flat Files1 podendo, contudo, existir outras
fontes. Um sistema ETL tem que ser capaz de comunicar com as bases de dados e ler diversos
formatos de arquivos utilizados por toda uma organizao. Com efeito, essa pode ser uma tarefa no
trivial e muitas fontes de dados podem ser de difcil acesso. Os processos de ETL podem ser muito
complexos e problemas operacionais significativos podem ocorrer com sistemas de ETL
desenvolvidos inapropriadamente. Quando as regras de validao e transformao so detalhadas,
pode acontecer que o intervalo de valores e a qualidade dos dados no tenham sido correctamente
especificados. A anlise dos dados fundamental para identificar as condies dos dados que
precisam de ser dirigidos pelas especificaes de regras de transformao.
Actualmente, existem vrias empresas especializadas em compreender as necessidades
especficas duma organizao e em desenvolver solues medida para a migrao dos dados. De
acordo com a pesquisa efectuada pela empresa de consultoria Gartner [5], as empresas que fazem

0
Os Flat Files correspondem a ficheiros de dados com uma estrutura muito simples, como por exemplo, ficheiros do tipo TXT ou CSV.

+5
 /
!

parte do quadrante de Lderes de Mercado (ver Figura 2), no desenvolvimento de ferramentas de ETL,
so:
IBM, com o DataStage;
Informatica, com o PowerCenter.

Figura 2 - Empresas lderes no mercado de ETL

Para alm das duas empresas anteriormente referidas, existem ainda trs grandes empresas que
investem significativamente no desenvolvimento de ferramentas de ETL, nomeadamente: BO
(Business Objects), Oracle e SAS. Como o conceito de ETL estvel, o Power Center da Informatica
e o DataStage da IBM apresentam uma estrutura base similar.
A ferramenta de ETL da Oracle, designada por Oracle Data Integrator (ODI), foi a eleita para o
desenvolvimento da ferramenta de migrao de dados para o ALERT. O ODI oferece a capacidade
de integrao de dados heterogneos e alta performance usando a tecnologia de E-LT. Entre outras
vantagens, esta soluo contribui para a diminuio do tempo de desenvolvimento da ferramenta de
migrao de dados, na medida em que dispe de suporte para a integrao de dados em tempo real e
permite a reduo do custo de desenvolvimento e manuteno de mapeamentos de integrao de
dados com a utilizao de bibliotecas de cdigos pr-configuradas, designadas por mdulos de
conhecimento (knowledge modules - KM).

+6
 /
!

/,2 - 6# % #

Dado que actualmente as organizaes no esto dispostas a correr riscos relacionados com a
integridade dos seus dados no processo de migrao, surge a necessidade de definir cuidadosamente a
arquitectura responsvel pelo processo de migrao, desde a fase de extraco dos dados do sistema
fonte, passando pela fase de transformao, at ao carregamento dos dados no sistema de destino.
Em arquitecturas tradicionais de migrao de dados, a abordagem tpica para a migrao
consiste em carregar os dados directamente numa base de dados relacional. No entanto, importante
compreender que, normalmente, os dados a migrar no provem apenas de uma fonte, mas so obtidos
a partir de mltiplas fontes aplicacionais, em certos casos correlacionados.
Para que seja possvel desenvolver a arquitectura adequada ao processo de migrao, para uma
determinada organizao, essencial estabelecer comunicao com o cliente e compreender quais as
suas expectativas face migrao. Frequentemente as organizaes exigem que todos os requisitos
presentes no sistema aplicacional antigo e os dados histricos sejam migrados, o que resulta em meses
de trabalho.
No momento da concepo da arquitectura de migrao, existem vrias questes que devem ser
tidas em considerao e que so entre outras :
Quantos sistemas fonte e destino esto envolvidos?
Qual o volume de dados que vai ser migrado?
Qual a capacidade do processador nos sistemas fonte?
Como se encontra a qualidade dos dados nos sistemas fonte?
Quanto tempo que os sistemas fonte podem ficar parados, durante a migrao?
Quais as reas que o cliente pretende migrar para o sistema ALERT?
possvel migrar para o novo sistema, todas as reas definidas pelo cliente?
exequvel mapear todo o contedo dos sistema fonte com o sistema de destino?
Aps anlise de todos estes aspectos, possvel elaborar a arquitectura mais adequada a cada
organizao.
Durante o processo de migrao o volume de dados a transferir para o sistema de destino pode
ser extremamente elevado e, nestes casos, frequente recorrer-se utilizao de uma rea intermdia
para armazenar os dados do sistema fonte e proceder ao processo de transformao, com o intuito de
adaptar os dados ao sistema de destino. A localizao desta rea intermdia pode variar de acordo com
as exigncias do projecto e os recursos envolvidos. Quando se pretende extrair os dados dos sistemas
fonte, tal como so e mov-los para uma rea intermdia localizada no sistema de destino, onde a
transformao pode ser realizada, a arquitectura pode ser esquematizada do seguinte modo (ver Figura
3):

+1
 /
!

Figura 3 - Exemplo de arquitectura com rea intermdia no sistema de destino

De acordo com a figura anterior (Figura 3) e tendo em considerao que os sistemas de origem e
de destino se encontram em servidores separados possvel depreender que com a utilizao de uma
rea intermdia no sistema de destino, este poder ficar sobrecarregado especialmente perante grande
volume de dados. Se durante o processo de transformao na rea intermdia, vrias tabelas forem
normalizadas em registos diferentes de dados, isso poder resultar num aumento significativo no
volume de dados e agrava a situao no processador do sistema de destino ficaria sobrecarregado.
Existe ainda a possibilidade de outras equipas, que no a de migrao, poderem realizar intervenes
no sistema de destino, em simultneo com a migrao, o que contribuir ainda mais para a sua
sobrecarga.
Uma outra abordagem, para o processo de migrao, passa por mover a rea intermdia do
sistema de destino para o sistema de origem, como ilustra a Figura 4:

Figura 4 - Exemplo de arquitectura com rea intermdia no sistema origem

+2
 /
!

Dada a possibilidade dos sistemas de origem e destino estarem operacionais em paralelo,

recorrendo anlise da figura anterior, possvel reconhecer que esta arquitectura poder contribuir
para uma sobrecarga no sistema de origem.
Embora as arquitecturas descritas na Figura 3 e na Figura 4 sejam suficientes para a converso
de sistemas obsoletos, pobres em volume de dados, no correspondem s expectativas definidas para a
Data Migration Framework, dado que esta nova ferramenta de migrao ir permitir realizar
migraes entre sistemas aplicacionais de origem e de destino, com possibilidade de funcionamento
em paralelo. Face volatilidade das tarefas de migrao, o nmero de sistemas fonte e de destino
podem alterar-se com frequncia ao longo do tempo. Uma vez que o volume de dados a ser
processado cresce diariamente, as iniciativas deste tipo exigem uma arquitectura robusta e flexvel que
aceite as mudanas que possam ocorrer no sistema de destino e que esteja preparada para geri-las com
cuidado. A arquitectura que melhor se adequa a esta soluo pode ser exemplificada na Figura 5:

Figura 5 Exemplo de arquitectura com rea intermdia num servidor prprio

Considerando que o sistema de transformao se encontra num servidor independente dos

sistemas de origem e de destino, possvel constatar atravs da Figura 5, que com este tipo de
arquitectura possvel suportar qualquer nmero de sistemas fonte e destino, sem sobrecarga para os
mesmos, independentemente da quantidade de volume de dados a migrar. Esta arquitectura vai de
encontro ao objectivo geral deste projecto, cuja finalidade consiste em migrar dados de diversos
sistemas fonte desconhecidos para o sistema ALERT, que pode sofrer periodicamente alteraes, a
nvel de verses de produto, e a possibilidade de ter sistemas em funcionamento paralelo. Nesse
sentido, a rea intermdia deve ser flexvel para poder suportar todas as alteraes e no necessitar de
constantes actualizaes, assim como estar presente num servidor prprio para no provocar
sobrecarga nos sistemas envolvidos. Neste sentido, a arquitectura que mais se adequa s necessidades
da Data Migration Framework a que se encontra ilustrada na Figura 5.

+-
 /
!

/,3 - 6# % # 4

A migrao de aplicaes numa organizao e a consolidao dos dados num nico sistema
integrado uma tarefa complexa.
O Oracle Data Integrator uma ferramenta que permite transformar eficientemente grandes
quantidades de dados, processar eventos em tempo real atravs da sua avanada capacidade de captura
de alteraes de dados (CDC) e fornecer funcionalidades robustas de controlo de integridade dos
dados, que asseguram a coerncia e exactido dos mesmos. Resume, deste modo, os requisitos de
desempenho, flexibilidade, produtividade e modularidade de uma plataforma de integrao, devido ao
seu ncleo constitudo por mdulos de conhecimento, desenho declarativo e arquitectura E-LT. A
arquitectura E-LT facilita a utilizao da programao manual e a abordagem ETL na mesma soluo.
Tradicionalmente, as ferramentas de ETL comeam por extrair os dados de diversos sistemas
fonte, transformam-nos e por fim carregam os dados transformados no sistema de destino. A
abordagem E-LT, exemplificada na Figura 6, desloca o passo de transformao de dados para o
sistema de destino, mudando a ordem de operaes para a seguinte:
1 - Extrair os dados das tabelas do sistema fonte,
2 - Carregar os dados no sistema de destino,
3 - Transformar os dados no sistema de destino.

Figura 6 - Arquitectura E-LT

Embora a arquitectura E-LT, utilizada pelo ODI, no v de encontro arquitectura ETL definida
para a Data Migration Framework (Figura 5), possvel estruturar a arquitectura ETL recorrendo a
trs arquitecturas E-LT relativamente a diferentes fases do processo de migrao de dados, tendo por
base o ODI, como exemplifica a Figura 7.

3,
 /
!

Figura 7 - Arquitecturas E-LT, no processo de migrao, usando o ODI

Pela anlise da Figura 7 e considerando que o sistema de transformao independente do

sistema fonte e de destino, possvel descrever as trs arquitecturas E-LT do seguinte modo:
1 - Extrair os dados do sistema fonte para posterior carregamento e transformao no sistema de
transformao, constitudo pelo schema STAGING, que possui a informao do sistema fonte a
migrar, e pelo schema MIGRA, que possui tabelas de mapeamento entre os dados do sistema fonte e
do sistema de destino;
2 - Extraco dos dados do sistema de transformao (schema STAGING) seguido do processo
de carregamento e transformao (schema MIGRA) com o intuito de adaptar os dados ao novo
sistema - ALERT;
3 - Extraco dos dados do sistema de transformao (schema MIGRA) e posterior
carregamento e transformao no sistema de destino. Como o sistema de transformao se encontra
com uma estrutura idntica ao ALERT, esta fase pode ser descrita apenas como a exportao directa
dos dados do sistema de transformao para o sistema de destino, no proporcionando a sobrecarrega
do sistema de destino.
Em sntese, a arquitectura ETL da Data Migration Framework, utilizando o ODI, pode
corresponder juno de trs arquitecturas E-LT, relativo a cada fase no processo de migrao de
dados para o ALERT, sem sobrecarregar o sistema fonte e de destino.
Uma vez que nenhum servidor extra, tecnologia, ou aptido exigida entra em jogo, a arquitectura
E-LT fornece um ptimo desempenho e facilita a gesto de integrao de infra-estruturas. Para
conceber um processo de integrao com sistemas convencionais de ETL, preciso planear cada
passo do processo, assim como os aspectos lgicos e tcnicos de integrao. No entanto, com o
desenho declarativo do Oracle Data Integrator apenas necessrio especificar aquilo que o processo
faz, sem ser necessrio descrever como ir ser feito.

30
 /
!

Figura 8 Desenho Declarativo do Oracle Data Integrator

O desenho declarativo, como exemplificado na Figura 8, utiliza o paradigma relacional para

declarar sob a forma de um interface, as regras declarativas para uma tarefa de integrao de dados,
que inclui a designao de fonte, destino e transformao. Com o desenho declarativo, o foco est
naquilo que realmente importa, ou seja, nas regras para a integrao em vez do foco nos aspectos
tcnicos subjacentes do processo de integrao. Os aspectos tcnicos so descritos nos mdulos de
conhecimento.
Os KM, do Oracle Data Integrator, implementam o modo como os processos de integrao
ocorrem. Um KM um modelo de cdigo para uma dada tarefa de integrao. Este cdigo
independente do interface, que define a fonte, o destino, e as transformaes que sero processadas.
Os metadados so fundidos com os mdulos de conhecimento para gerar cdigo pronto para ser
executado. No momento da execuo, o Oracle Data Integrator envia este cdigo para os sistemas
fonte e destino que utiliza na execuo do processo. Os mdulos de conhecimento proporcionam
maior flexibilidade, dando acesso soluo mais adequada para uma tarefa especfica numa
determinada situao. Os mdulos de conhecimento tambm so totalmente extensveis. O seu cdigo
aberto e pode ser editado atravs de um interface grfico por tcnicos especializados dispostos a
aplicar novos mtodos de integrao ou aplicar as melhores prticas.

3+
 /
!

A abordagem de integrao dos dados envolve extrair todos os dados do sistema fonte e, em
seguida, integrar toda a informao no sistema de destino. No entanto, esta abordagem pode revelar-se
ineficaz quando o processo de integrao reflectir a necessidade de uma integrao orientada a
eventos. Outro uso deste tipo de integrao pode exigir captar mudanas ao nvel de base de dados.
A capacidade de captura de alteraes de dados (CDC - Changed Data Capture) do Oracle Data
Integrator identifica e captura inseres, actualizaes ou eliminaes de dados do sistema fonte e
torna disponvel para processos de integrao. A ferramenta CDC usada para gerir alteraes, que
frequentemente envolvem vrios sistemas fonte ao mesmo tempo, genrica e aberta, de modo a que
o mtodo de monitorizao de alteraes possa ser personalizado. Este mdulo permite processar
conjuntos de alteraes para as quais a consistncia dos dados garantida.
O Oracle Data Integrator utiliza regras declarativas de integridade de dados definidas no seu
repositrio de metadados centralizado, como demonstra a Figura 9. Estas regras so aplicadas para
garantir a integridade e a coerncia da informao empresarial. Os benefcios da integridade dos dados
so essenciais para as iniciativas de qualidade de dados e facilitam a integrao com processos
empresariais actuais e futuros.

Figura 9 - Definio de regras de integridade e posterior validao

O Oracle Data Integrator recupera, automaticamente, regras definidas a nvel dos dados, como
o caso das constraints a nvel de base dados, por um processo de reverse engineering. Permite, ainda,

33
 /
!

definir regras declarativas adicionais que podem ser deduzidas a partir da descoberta de dados e perfis
dentro do Oracle Data Integrator e imediatamente verificadas. Regras declarativas para a integridade
dos dados incluem regras nicas, validao de regras que foram a consistncia a nvel do registo e
regras de referncia simples ou complexas possivelmente envolvendo tecnologias heterogneas.
Dada a complexidade de todo o processo de migrao de dados, os desenvolvimentos
necessrios especificao da arquitectura adequada Data Migration Framework sero
pormenorizados nos prximos captulos.

/,5 - # #

A ferramenta Oracle Data Integrator (ODI), utilizada no desenvolvimento da Data Migration

Framework, traduz-se numa soluo de integrao de dados de alta performance para sistemas de
origem e destino heterogneos. A alta performance assegurada pela tecnologia de E-LT (extraco,
carregamento e transformao), que possibilita executar as operaes de transformao dentro do
sistema de origem ou de destino. Esta ferramenta ajuda a informatizar a migrao dos dados e a
movimentao dos mesmos em lote, ao mesmo tempo que assegura que as informaes sejam precisas
e concisas entre sistemas complexos.
O ODI constitudo por vrias componentes que trabalham em conjunto sobre um repositrio de
metadados central, que constitudo por um repositrio mestre e vrios repositrios de trabalho. Estes
repositrios so armazenados em sistemas de gesto de base dados relacionais. Todos os objectos que
que forem necessrios configurar, desenvolver, ou utilizar so armazenados num destes repositrios, e
so acedidos pelas diferentes componentes da arquitectura, no modo de cliente-servidor.
Geralmente utilizado apenas um repositrio mestre, que contem informao de segurana
(perfis de utilizador e privilgios), informao da topologia (definio das tecnologias e servidores) e
as verses dos objectos.
A arquitectura do ODI organizada em torno dos repositrios mestre e de trabalho, que so
acedidos atravs do modo cliente-servidor por componentes que so desenvolvidos inteiramente em
Java. Estas componentes podem ser interfaces grficos e agentes. Os interfaces grficos so quarto:
Designer, Operador, Topologia e Segurana, como se ilustra na Figura 10.

34
 /
!

Figura 10 - Interfaces grficos conectados ao repositrio

A informao que se encontra no repositrio mestre conservada nos interfaces de Topologia e

Segurana, ao passo que a informao presente nos repositrios de trabalho conservado nos
interfaces de Design. Os interfaces grficos podem ser descritos do seguinte modo:

Designer
- Mdulo central para os programadores e administradores de metadados.
- Permite definir regras declarativas para a transformao dos dados e a integridade dos mesmos.
- Utiliza metadados e regras para gerar cenrios de produo.
- Todos os desenvolvimentos que englobam a criao de projectos ocorrem neste mdulo.
- Neste mdulo so definidos o sistema de base de dados e o sistema aplicacional.

Operador
- Controla e monitoriza actividades de produo.
- Permite visualizar logs de erros, o nmero de registos processados, estatsticas e o cdigo que
realmente executado.
- Na fase de desenvolvimento este mdulo essencial para questes de debug.

Topologia
- Permite definir a arquitectura fsica e lgica da infra-estrutura
- Est ligado ao repositrio mestre.
- Atravs deste mdulo possvel registar servios, agentes, schemas no repositrio mestre.

Segurana
- Responsvel pela gesto dos perfis dos utilizadores e os seus respectivos privilgios de acesso.
- Este mdulo permite atribuir privilgios de acesso a objectos e recursos.

35
 /
!

O modelo grfico que permite compreender melhor a relao entre o repositrio mestre e os
repositrios de trabalho exemplificado na Figura 11.

Figura 11 - Exemplo de repositrios mestre e de trabalho

No ODI, os objectos do projecto so armazenados no repositrio de trabalho. Vrios repositrios

de trabalho podem existir na mesma instalao. Esta situao importante para manter os ambientes
separados ou ainda para reflectir o ciclo de vida de uma verso particular, como por exemplo:
ambiente de desenvolvimento e ambiente de produo.
Um repositrio de trabalho armazena informao correspondente a modelos, projectos e
execuo de informao em tempo real.
Os modelos correspondem a modelos de base de dados, que incluem tipo de colunas,
constraints de integridade dos dados, referncias cruzadas, etc.
Os projectos contm regras declarativas, packages, procedures, pastas, mdulos de
conhecimento e variveis.
A execuo da informao em tempo real inclui cenrios, agendamentos de tarefas e logs.
A arquitectura do ODI inclui um aplicativo Web que permite aos utilizadores aceder
informao atravs de um interface Web.
Pelo facto de todos os componentes poderem ser executados independente de qualquer sistema
compatvel com Java, arquitectura e ao facto de ser de instalao rpida em qualquer plataforma, o
ODI foi o software escolhido para desenvolver a Data Migration Framework.

36
 /
!

!* #& 2

7&

A palavra projecto usada pela primeira vez por altura do sc. XVI, deriva do Latim projicere
(lanar para a frente), sugerindo movimento, trajectria, uma relao exacta com espao e tempo.
Um projecto pode ser definido, segundo o PMBOK Guide [3], como um conjunto de
actividades no repetitivas, planeadas e realizadas de acordo com determinadas especificaes
tcnicas, que visam alcanar objectivos pr-definidos (de custo, prazo e resultados).
De um modo geral, um projecto de migrao pode ser resumido em quatro fases,
respectivamente: planeamento, anlise, desenvolvimento e concluso. extremamente importante que
a fase de anlise seja rigorosa de modo a permitir identificar e documentar todas as regras para a
migrao de dados, com a correspondente aceitao de todas as partes envolvidas. A correcta
definio de regras permite elaborar a ferramenta mais apropriada para o processo de migrao de
dados de vrios sistemas fonte para o ALERT.

2,+ - 1 %

Um projecto de migrao de dados composto por um ciclo de vida mais ou menos extenso,
consoante o tipo de projecto e assenta, essencialmente, nas fases de planeamento, anlise,
desenvolvimento e concluso. Todas as fases so essenciais para atingir os objectivos propostos e por
conseguinte, todas devem ser tratadas com igual ateno.

31
 /
!

1 - A fase de planeamento tem como propsito definir o mbito, tempo e custos necessrios
para concluir o projecto. Envolve a definio dos objectivos, a seleco e alocao de recursos
materiais e humanos, calendarizao, definio do oramento e obteno de aprovao para a
implementao do projecto. Esta fase inclui, tambm, anlises viabilidade do projecto em termos
funcionais, tcnicos e financeiros, bem como estudos prvios de mercado (a nvel tcnico e financeiro)
e anlise de alternativas.
2 - A fase de anlise tem como objectivo detalhar a definio do mbito do projecto e com base
no custo e tempo aprovados na fase de planeamento, analisar de que forma o projecto ser
desenvolvido.
3 - A fase de desenvolvimento corresponde implementao do projecto tendo em conta o
planeamento efectuado, a nvel dos prazos, custos e qualidade. Esta fase inclui a definio da
organizao, a alocao e gesto dos recursos humanos, materiais e financeiros, a contratao de
equipamentos e de servios, a verificao e controlo dos prazos, dos custos e da qualidade, e o
replaneamento.
4 - A fase de concluso corresponde libertao dos recursos, elaborao de documentao e
entrega dos resultados do projecto.
A migrao de dados uma tarefa complexa correspondendo, por isso, a um projecto de difcil
implementao e controlo. Para minimizar o risco de encarar dificuldades ao nvel da rectificao de
requisitos, possveis atrasos na migrao de dados, custos que ultrapassam o oramentado, falhas de
documentao, entre outros, necessrio uma definio rigorosa das diferentes fases especficas do
projecto de migrao de dados, que pode ser dividido em cinco fases, nomeadamente:
1 - Fase de Preparao: Nesta fase so analisados e documentados todos os dados do sistema
fonte por reas, com o intuito de definir qual a informao que o cliente pretende migrar para o novo
sistema, bem como esclarecer o que deve ser feito com a informao que no possa ser migrada.
tambm pertinente analisar as diferenas entre as funcionalidades do sistema fonte e de destino, bem
como mapear os dados das diversas funcionalidades do sistema fonte para os dados necessrios ao
correcto funcionamento do sistema de destino. Nesta fase dever ser descrito como os dados sero
migrados, mapeados e como sero apresentados no novo sistema, tendo em considerao requisitos a
nvel de hardware no perodo de migrao.
2 - Fase de Configurao: A fase de configurao consiste em preparar o ambiente para a
migrao, definindo as ligaes entre os diferentes sistemas, configurando as relaes entre o sistema
aplicacional fonte e os dados de referncia do sistema de destino, assim como definir o mtodo de
extraco dos dados do sistema fonte, num dos formatos suportados pela Data Migration Framework,
ou seja, recorrendo a ficheiros XML ou Flat Files.
Nesta fase alm de ser definido o mtodo de extraco dos dados do sistema fonte, tambm
executada a sua exportao e a respectiva importao na rea intermdia, onde sero realizadas todas
as transformaes necessrias para a correcta importao no sistema de destino.
32
 /
!

3 - Fase de Migrao em Pr-Produo: A fase de migrao dos dados do sistema fonte para
o sistema de destino, num ambiente de pr-produo, pode ser descrita como uma primeira migrao
que, normalmente, executada cerca de um ms antes da migrao final (num ambiente de produo).
Nesta fase, o sistema aplicacional fonte mantm-se activo sem interferir com o processo de migrao
no sistema de destino.
4 - Fase de Teste: A fase de teste essencial para compreender o sucesso da migrao e como
tal so executados vrios testes quer por parte do cliente quer por parte da equipa responsvel pela
migrao dos dados, recorrendo a testes internos de migrao ou a testes de aceitao definidos pelo
prprio cliente. Os testes de aceitao permitem evitar surpresas desagradveis antes que o novo
sistema entre em funcionamento e determinar se a implementao est de acordo com os objectivos
definidos. Caso seja necessrio possvel realizar pequenas correces para ajustar algum aspecto que
esteja ligeiramente fora do objectivo definido. Entende-se como testes internos de migrao, os testes
realizados pela equipa responsvel pela migrao com o objectivo de avaliar o processo de migrao,
como por exemplo, verificar se a quantidade de informao no sistema fonte igual no sistema de
destino, entre outros.
5 - Fase de Migrao em Produo: Nesta fase executada a primeira migrao em ambiente
de produo, com o sistema fonte apenas em modo de leitura, que se pretende que seja realizado no
menor tempo possvel. Aps a primeira migrao pode ser necessrio realizar migraes diferenciais,
mas neste caso sem que o sistema fonte se encontre apenas em modo de leitura. No fim de cada
migrao existe um perodo de estabilizao para ser possvel identificar possveis incoerncias nos
dados migrados.
necessrio referir que as diferentes fases dum projecto de migrao de dados no devem ser
vistos como etapas de importncia desigual, uma vez que a sua inadequada considerao muitas
vezes a causa de grande parte das falhas de projectos deste tipo. A adopo de uma metodologia
adequada factor fundamental para o sucesso da migrao de dados.

2,/ - ) %#& ! 1 %

Os projectos de migrao de dados desempenham um papel fundamental em mltiplas

iniciativas de negcio. Todavia, possvel encontrar vrios problemas inerentes sua implementao.
De acordo com a pesquisa efectuada pela Bloor Research2 [4], quando existe atraso ou falha nos

+
Fundada em 1989, a Bloor Research uma das organizaes lderes mundiais, de tecnologias de informao (TI), na rea de investigao,
anlise e consultoria. Distribuem solues de TI s organizaes em todo o mundo atravs de inscries on-line, adaptada a servios de
investigao e consultoria de projectos.

3-
 /
!

projectos de migrao de dados, o plano inicial do projecto pode sofrer mudanas no cronograma ou
at mesmo fracassar. Deste modo, para que o projecto de migrao ocorra dentro do prazo e dos
oramentos requeridos, importante compreender os factores necessrios ao sucesso do projecto. Em
minha opinio, o factor essencial ao sucesso do projecto consiste em estabelecer um bom
relacionamento com o cliente para definir com exactido qual a informao a migrar para o novo
sistema aplicacional, assim como, determinar solues para a informao que no poder ser migrada
para o novo sistema. A tendncia descobrir que muitas, se no a maioria, das suposies iniciais em
relao aos dados do sistema fonte, no se encontram correctas ou so alteradas pelo cliente j na fase
de migrao, por isso, muito importante definir os requisitos da migrao no incio do projecto.
Devido complexidade do projecto, o processo de migrao constitudo por diversos desafios.
Um dos maiores desafios no projecto de migrao, consiste em obter o menor tempo possvel de
paragem do sistema aplicacional fonte antes do novo sistema aplicacional ser activado. A
oportunidade para extrair e carregar os dados pode ser extremamente limitada e nesse sentido,
essencial dialogar com o cliente assim que o projecto se inicia. Para diminuir o tempo de
carregamento e os riscos durante a migrao importante obter alguma informao pertinente por
parte do cliente, nomeadamente:
Qual o intervalo de tempo que o cliente est disposto a conceder exportao dos dados
para o novo sistema e operaes de carregamento em ambientes de produo?
Qual a quantidade de registos esperados para o processo de migrao?
O sistema de origem tem diferentes interfaces aplicacionais?
Quais as reas funcionais que sero migradas para o novo sistema aplicacional?
O que deve ser feito com a informao que no pode ser incorporada no novo sistema?
A resposta a estas questes permite elaborar testes referentes s taxas indicativas de
carregamento, antes da fase de migrao, em pr-produo.
Para compreender a problemtica da migrao de sistemas fonte desconhecidos para o ALERT,
foi elaborado um projecto-piloto, em Outubro de 2008, com dados reais provenientes do Hospital de
Bernhoven, na Holanda, com informao referente rea dos profissionais e pacientes. Durante a fase
de preparao e configurao do projecto-piloto, foi identificado, uma outra problemtica no projecto
de migrao de dados. Uma vez que o objectivo deste projecto consiste em desenvolver uma
ferramenta que permita migrar dados de diferentes sistemas fonte desconhecidos para o sistema
ALERT, surge a dvida de como dever ser realizada a identificao da informao a migrar e como
relacionar os diferentes sistemas fonte. Assim, torna-se pertinente definir uma rea intermdia que
permita identificar a estrutura da informao a migrar dos diferentes sistemas fonte para o ALERT.
A ampla diversidade de ferramentas que existe nas organizaes no vai de encontro aos
requisitos de performance, flexibilidade e modularidade. Com efeito, um outro factor problemtico no
desenvolvimento da Data Migration Framework passa por conseguir integrar a informao dos

4,
 /
!

diversos sistemas fonte no novo sistema ALERT, sem perda de integridade nem performance.
Deste modo, na definio da arquitectura da ferramenta de migrao de dados, foi pertinente
desenvolver uma rea intermdia independente dos sistemas de origem e de destino para no
sobrecarregar os sistemas envolvidos e que permitisse reunir toda a informao proveniente de
diversos sistemas fonte numa nica rea. A utilizao da rea intermdia ir tambm suportar as
alteraes que ocorram no produto ALERT, minimizando o impacto desta alterao na Data
Migration Framework.

2,2 - 6# # % # %

Tradicionalmente, os requisitos expressam as caractersticas e restries do produto do ponto de

vista da satisfao das necessidades do cliente. Geralmente, so independentes da tecnologia utilizada
na construo da soluo, no entanto, so a parte mais crtica e propcia a erros no desenvolvimento do
software. Os requisitos a nvel de software so separados em requisitos funcionais e no funcionais.
Os requisitos funcionais correspondem descrio de diversas funcionalidades que o cliente
pretende ou precisa que o software realize. A especificao de um requisito funcional deve determinar
o que se espera que o software faa, sem a preocupao de como ele o faz.
Os requisitos no funcionais correspondem s qualidades globais de um software, como por
exemplo, usabilidade, desempenho, custos entre outras. Normalmente, estes requisitos so descritos de
maneira informal e no so de validao simples.
As Tabela 1 eTabela 2 apresentam a listagem referente aos requisitos funcionais e no funcionais
da Data Migration Framework.

REQUISITOS FUNCIONAIS

A quantidade de registos no sistema fonte no momento anterior migrao tem de ser o mesmo no
sistema de destino aps a migrao.

A migrao deve ser realizada apenas para as reas escolhidas pelo cliente.

A fase de transformao deve preservar o significado da informao proveniente do sistema fonte.

Toda a informao que no pode ser migrada para o ALERT deve ser armazenada de acordo com o
que for previamente acordado com o cliente.

A ferramenta de migrao dever estar adaptada a qualquer mercado, em termos de lngua e de

standards de contedos clnicos e no clnicos.

40
 /
!

A sincronizao dos dados deve ser estabelecida, enquanto todos os sistemas fonte ainda se
encontrarem activos e no forem migrados para o novo sistema.

Dever ser disponibilizado um recurso de visualizao do estado do progresso da migrao.

Dever ser disponibilizado um interface para analisar os erros que possam ter ocorrido na migrao.

Tabela 1 - Requisitos Funcionais

REQUISITOS NO FUNCIONAIS

A migrao deve ser realizada no menor tempo possvel

A utilizao da ferramenta de migrao deve ser simples.

As operaes devem ser fceis de executar e consumir pouco tempo.

O correcto funcionamento da ferramenta de migrao implica a disponibilizao de um servidor com

o mnimo de 3x a capacidade do sistema fonte e o Oracle DB.

A DMF ser utilizada apenas para migraes de diversos sistemas fonte para o ALERT.

A ferramenta de migrao de dados para o ALERT dever ser instalada, configurada e considerada
pronta para ser utilizada num perodo de tempo reduzido. Nunca mais de 4 horas.

Dever ser disponibilizado um documento para que o cliente compreenda o processo de migrao.

A DMF ter de estar adaptada para qualquer plataforma que o sistema fonte possua.

A Data Migration Framework dever permitir migrar grande volume de dados em tempo reduzido.

O passo final de comutao dos sistemas antigos para o sistema novo (go-live) deve ter uma
durao inferior a 24 horas.

Tabela 2 - Requisitos No Funcionais

2,3 - $ ! %

A migrao de dados de vrios sistemas fonte para o ALERT um processo que envolve
ambientes de Pr-produo e de Produo. A utilizao do ambiente de pr-produo tem como
objectivo permitir realizar testes internos e de aceitao ao processo de migrao, assim como,
efectuar as actualizaes necessrias ao ambiente do cliente. Com este ambiente intercalar, a

4+
 /
!

implementao de um projecto de migrao de dados ganha mais fiabilidade, consistncia e

celeridade, j que os constrangimentos e anomalias deste sistema so identificados e tratados numa
fase prvia do projecto. Com a concluso dos testes de aceitao efectuados pelo cliente, a
implementao deste sistema no ambiente de produo passar pela instalao da soluo j testada e
a subsequente execuo.
A utilizao de dois ambientes distintos no processo de migrao tem como propsito diminuir o
tempo de paragem do sistema aplicacional fonte, executar uma pr-validao do processo de migrao
e analisar a qualidade dos dados.
No ambiente de pr-produo, os dados dos sistemas fonte so migrados para a rea intermdia
(1 Recolha de Informao), a partir da qual executada uma primeira migrao para o ALERT,
com o intuito de migrar a maior quantidade de informao possvel, para reduzir o tempo de migrao
na altura do GO-LIVE (migrao no ambiente de produo, na qual o sistema ALERT substitui o
sistema fonte). Aps a primeira migrao so efectuadas migraes diferenciais com o objectivo de
manter a informao actualizada na rea intermdia, relativamente informao presente no sistema
de origem, at ao momento do GO-LIVE.
No ambiente de produo, existe uma cpia da rea intermdia que se encontrava em
pr-produo (2 Cpia da rea intermdia para o sistema de produo), na qual ser realizada uma
nova migrao, com a informao mais actual do sistema fonte (3 Recolha de Informao) at ao
momento da migrao. O objectivo da utilizao de um ambiente de pr-produo reduzir ao
mnimo o tempo de paragem do sistema aplicacional fonte, uma vez que mais de 90% dos dados j
foram tratados no ambiente de pr-produo.
Aps cada processo de migrao em ambiente de pr-produo ou produo, uma bateria de
testes executada quer pelo cliente quer pela equipa responsvel pelo processo de migrao, com a
finalidade de garantir que todos os dados foram migrados correctamente.
Os dois ambientes envolvidos no processo de migrao podem ser visualizados na Figura 12.

43
 /
!

Figura 12 - Ambientes envolvidos no processo de migrao

Com o objectivo de evidenciar a evoluo do processo de migrao de dados, que vai desde que
o sistema aplicacional antigo est activo at ao momento em que o sistema aplicacional ALERT fica
operacional e o antigo deixa de ser usado, desenhou-se um esquema detalhado que se encontra na
Figura 13.

44
 /
!

Figura 13 - Processo de migrao para o ALERT

Pela observao da Figura 13 possvel constatar que o processo de migrao mais pesado a
nvel de quantidade de dados a migrar o que realizado no ambiente de pr-produo. Deste modo,
quanto menor for a quantidade de dados a migrar em produo, menor ser o tempo de paragem
aplicacional do sistema fonte e mais rpido ser possvel utilizar o sistema aplicacional ALERT, com
toda a informao que existia no sistema anterior.
45
 /
!

Ao longo do processo de migrao de dados para o ALERT, vrias tarefas devero ser
executadas com determinada ordem. Assim, antes de se dar incio ao processo de migrao
fundamental que todo o universo de contedos ALERT esteja disponvel para ser possvel mapear os
dados do cliente com o que j existe no ALERT. O processo de mapeamento de dados compara os
descritivos do universo do cliente com os descritivos do universo ALERT e, caso os descritivos
sejam iguais, assinala-se uma correspondncia. A informao que no encontra correspondncia ter
de ser analisada manualmente pela equipa de contedos, responsvel por este gnero de actividades.
Realizada a fase de mapeamento, d-se incio ao processo de migrao propriamente dito atravs
do carregamento dos dados a migrar do sistema fonte na rea intermdia, seguido de uma primeira
migrao e de migraes diferenciais, da rea intermdia para o ALERT. A migrao de dados para o
ALERT executada numa primeira fase num ambiente de pr-produo e numa segunda fase num
ambiente de produo.
Posteriormente ao processo de migrao dos dados fundamental validar os dados que foram
migrados para o novo sistema, no sentido de validar o sucesso da migrao, no s pelo cliente mas
tambm pela equipa responsvel pelo processo de migrao.
O progresso do processo de migrao, descrito anteriormente, pode ser ilustrado atravs da
Figura 14.

46
 /
!

Figura 14 - Progresso do processo de migrao para o ALERT

Como possvel analisar atravs da figura anterior, o processo de migrao em si s tem incio
aps a anlise e o mapeamento entre os dados do sistema fonte e o sistema de destino. O projecto de
migrao s termina quando todos os testes so realizados e validados com sucesso, assim como o
alcance de todos os requisitos estabelecidos pelo cliente.

41
 /
!

!* #& 3

' &'

O desenvolvimento e a implementao do projecto tiveram incio em Outubro de 2008, no

Hospital de Bernhoven, na Holanda, atravs da elaborao e apresentao do prottipo com
informao referente a profissionais, pacientes e laboratrio de anlises. Nesta apresentao foram
descritas as vantagens da implementao, o rcio tempo/custo disponibilizado e as ferramentas
utilizadas.

3,+ - ) 6# % #

A Data Migration Framework, esquematizada na Figura 15, consiste numa ferramenta de

suporte a processos de migrao de dados estruturados essencialmente em trs fases. Numa primeira
fase pretende-se receber dados de um qualquer sistema externo (Base de Dados do cliente) para a
DMF. A segunda fase corresponde ao processo de transformao necessrio adaptao dos dados do
sistema externo para o ALERT e a terceira fase responsvel por enviar os dados que se encontram
na DMF para o ambiente de dados ALERT (Base de Dados ALERT).

42
 /
!

Figura 15 - Descrio da Data Migration Framework

A utilizao de uma rea intermdia, durante o processo de migrao, apresenta trs grandes
vantagens:
1 - Constitui uma plataforma autnoma para a transformao e consolidao dos dados no
modelo ALERT, relativamente aos sistemas fonte e destino, onde se condensam as regras de
transformao acumuladas pela experincia da equipa de migrao;
2 - Garante independncia relativamente aos detalhes do modelo ALERT, isolando o modelo da
interface com os sistemas fonte dos processos de migrao, o qual pode ser simplificado e estvel, o
que facilita a extraco de dados dos sistemas fonte;
3 - Permite boa adaptao s evolues das sucessivas verses do sistema ALERT atravs de
um segundo modelo, voltado para o carregamento de dados no sistema destino.
Ao tirar partido desta utilizao, consegue-se decompor um problema muitos-para-muitos em
dois sub-problemas, um muitos-para-um na extraco e outro um-para-muitos no carregamento,
ficando ambos ligados por um processo de transformao interno rea intermdia.
possvel, ainda, suportar um nmero qualquer de sistemas fonte, ficando tipicamente a cargo
do cliente, conhecedor dos sistemas fonte, extrair da os dados para o formato de entrada na DMF.
Alguns sistemas, e nomeadamente a Data Migration Framework, so constitudos por uma
arquitectura que impede o acesso directo ao modelo de dados de destino. Esta plataforma possibilita o
abstrair das tecnologias subjacentes, bem como uma integrao mais rpida nos novos sistemas,
possibilitando criar solues mais rpidas e competitivas. Todavia, o carregamento dos dados em tais
sistemas deve passar pela utilizao de uma rea intermdia ou pela utilizao de uma API

4-
 /
!

(Application Programming Interface). O conceito de API pode ser descrito como uma srie de funes
acessveis somente por programao, e que permitem utilizar caractersticas do software menos
evidentes por parte do cliente. No caso da DMF, utilizado uma rea intermdia para impedir o
contacto directo com o modelo de dados do sistema de destino. Qualquer outra soluo, como o caso
do carregamento directo para o modelo de dados de destino, poderia dificultar o seu suporte devido
sua complexidade.
A arquitectura da Data Migration Framework decompe-se em sete processos de que a seguir se
d conta.

3,+,+ - % % &8

No processo de recolha dos dados, o cliente deve disponibilizar os dados que pretende migrar
para o sistema ALERT, num formato previamente definido (de acordo com o modelo da rea
intermdia).
A exportao dos dados do cliente pode ser realizada recorrendo a ficheiros no formato XML,
em Flat Files ou directamente atravs de DBLinks, para a rea intermdia. Independentemente do
modo como a informao exportada do sistema fonte, sempre necessrio validar se realmente os
dados se encontram numa estrutura previamente definida.
A validao dos dados exportados do sistema fonte pode ser efectuada em vrios aspectos:
Range: Valida se a informao se encontra no intervalo de valores definido. Por exemplo, o
profissional de sade no pode ter menos de 20 anos;
Mandatory value: Garante que todos os dados que so de preenchimento obrigatrio so
preenchidos;
Length: Valida se determinado valor tem o tamanho esperado;
Data type: Garante que o valor a migrar do tipo previamente definido. Por exemplo: o
nome do profissional de sade do tipo VARCHAR2;
Data profile: Verifica se a informao se encontra no formato definido. Por exemplo, o
formato do cdigo postal;
Primary key: Identifica univocamente cada registo.
Referential integrity: Valida se todas as chaves externas existem nas tabelas referidas.
de citar que estes vrios aspectos de validao apenas nos dizem que os dados esto de acordo
com as regras formais e de consistncia interna, no permitindo validar se a informao est correcta,
isto , se corresponde a factos reais, uma vez que a validao feita ao nvel da sintaxe e no ao nvel
da semntica.

5,
 /
!

Os ficheiros gerados para permitir carregar a rea intermdia com informao do sistema fonte,
podem ser validados do seguinte modo:
No caso de ficheiros no formato XML, a validao ser feita recorrendo ao XML Schema
(XSD), que uma linguagem baseada no formato XML para a definio de regras de validao em
documentos no formato XML (ver seco 4.4.1).
No caso de Flat Files, atravs do SQL*Loader possvel analisar o ficheiro de log e
identificar todos os casos que falharam.
No caso de utilizar directamente DBLink, s possvel validar os contedos no momento da
insero dos dados na rea intermdia.
Se, durante o processo de validao, for identificado algum erro, essa situao reportada ao
cliente, para que este corrija a informao. Caso no seja detectada nenhuma inconformidade, a
informao migrada para a rea intermdia (schema STAGING).

3,+,/ - % 9# &

Uma vez que o processo de recolha dos dados j foi executado e toda a informao enviada pelo
cliente encontra-se na rea intermdia necessrio validar a qualidade dos dados.
A qualidade dos dados pode ser avaliada atravs de duas componentes principais que nos
ajudam a garantir que os dados do sistema fonte se encontram suficientemente aptos para serem
migrados para o sistema de destino.
As componentes de avaliao so as seguintes:
Mtricas para medir a qualidade dos dados;
Mtricas para melhorar as actividades.
As mtricas para medir a qualidade dos dados do informao do estado em que se encontram os
nossos dados. Neste caso, a regra que nos permite determinar a qualidade dos dados a de no poder
existir duplicao de informao.
As mtricas para melhorar as actividades tm como objectivo ajudar a gerir eventuais erros nos
dados. No caso de se encontrar registos duplicados, a migrao falha. Para melhorar esta situao,
devem ser definidas determinadas actividades que passam primeiramente por informar o cliente e
definir com ele a melhor soluo, que pode passar pela eliminao do registo ou a actualizao do
mesmo, caso tenha sido encontrado um erro no sistema fonte.

50
 /
!

3,+,2 - %

O processo de carregamento consiste em transportar os dados que se encontram no schema

STAGING para o schema MIGRA, que constitudo por um conjunto de tabelas de mapeamento (ver
Tabela 3), geradas de forma automatizada com recurso a um package de base de dados em PL/SQL,
com a seguinte informao:
MAP OLD corresponde na ntegra informao que estava no schema STAGING,
proveniente do sistema de origem.
MAP NEW contm a informao que ser migrada para o ALERT.
FLG_STATUS identifica se a informao deve ser migrada ou no para o ALERT.

TABELA DE MAPEAMENTO

MAP OLD MAP NEW FLG_STATUS

ID DESCRIO ID DESCTIO

Tabela 3 - Descrio da estrutura de uma tabela de mapeamento

Neste processo, apenas a informao correspondente MAP OLD preenchida.

3,+,3 - % !

O processo de mapeamento considerado o ncleo do movimento dos dados de um sistema para

outro. Ao nvel mais baixo, campo a campo, fundamental saber de onde que cada item de
informao proveniente, para onde vai e o que necessrio para registar a informao de modo a
ficar de acordo com o sistema de destino. Na maioria das situaes, o mapeamento envolve uma
correspondncia de um para um (1-1) do sistema fonte para o de destino. No entanto, tambm pode
acontecer o caso de ter de dividir um valor do sistema fonte em vrios valores para o sistema de
destino e vice-versa.
O processo de mapeamento, alm de identificar a correspondncia da informao do schema
STAGING para o de destino (ALERT), tem como objectivo validar de forma automtica se
determinada informao j existe ou no no ALERT. Se ocorrerem erros no decorrer deste processo,

5+
 /
!

os registos identificados so marcados como errados e lanada uma mensagem de erro, no sentido de
permitir a posterior actualizao do registo e novo processamento.
Todos os registos que estejam de acordo com as regras definidas, permitem replicar a
informao que est na MAP OLD para a MAP NEW.

3,+,5 - %

O processo de migrao consiste em transportar a informao referente MAP NEW, que se

encontra nas tabelas de mapeamento, e migr-los para a base de dados do sistema ALERT. No caso
de ser detectado algum erro durante o processo de migrao, a informao no migrada para o
ALERT, mas sim registada como errada nas tabelas de mapeamento (Tabela 3), na coluna designada
por estado. Se no for detectado nenhum erro, a informao migrada para a base de dados ALERT.
Os dados que so migrados para o ALERT nunca so eliminados do schema STAGING, nem
do schema MIGRA, com o intuito de se preservar todo o histrico do processo de migrao. Desta
forma, d-se o processo de migrao de dados como concludo, informando o cliente da situao.

3,+,: - % )%

O processo de notificao responsvel por identificar todos os erros que possam ocorrer,
durante o processo de migrao.
A partir do processo de carregamento at ao processo de migrao, registado em tabelas de
log, todos os erros que possam ocorrer em cada processo, permitindo assim, ter uma percepo do
estado do processo da migrao, e recorrer a estas tabelas para validar os dados migrados. Caso seja
verificado algum erro, ser enviado um e-mail com essa informao para os responsveis do processo
de migrao, com a finalidade de que determinada situao seja resolvida o mais brevemente possvel.
Este processo de extrema importncia para a Data Migration Framework, j que permitir uma
monitorizao activa e em tempo real do processo de migrao de dados, para que a equipa
responsvel pelo processo de implementao, possa actuar com prontido, preciso e sem grande
perda de tempo.

53
 /
!

3,+,; - % <

O processo de monitorizao responsvel por controlar e registar o desempenho de todas as

etapas que decorrero durante o processo de migrao. Assim, foi pertinente desenvolver uma
ferramenta especfica em PL/SQL, com resultado visvel em HTML, designada por Monitoring
Framework (MF).
Com este processo ser possvel identificar qual a etapa que est a ser executada em menor
tempo, qual a mais longa, quantos registos foram processados at uma determinada altura e qual o
tempo total que demorou a executar o processo de migrao.
A utilizao da Monitoring Framework um factor importante para a Data Migration
Framework, pois permite que a equipa de implementao seja capaz de monitorizar a performance do
processo de migrao de dados, com vista a uma reaco atempada para manter o processo sem
bloqueios. de salientar que se trata de um processo que lida com enorme quantidade de informao.

3,/ - 6# % % '

Nesta rea do documento, pretende-se descrever os aspectos funcionais da Data Migration

Framework, que tem como objectivo definir um mecanismo que permita migrar os dados de diferentes
sistemas fonte para o sistema ALERT.
Numa primeira etapa executa-se um processo que permite receber dados de qualquer sistema
externo, em diversos formatos, e validar se essa informao se encontra de acordo com o que foi
previamente definido, aquando da elaborao do modelo de dados do schema STAGING. A
exportao dos dados do cliente, para o schema STAGING, pode ser realizada recorrendo a ficheiros
no formato XML, Flat Files ou directamente atravs de DBLinks. Independentemente do modo como
a informao exportada, sempre necessrio legitimar se realmente os dados se encontram na
estrutura previamente definida. Se durante o processo de validao, for identificado algum erro, essa
situao reportada ao cliente, para que este actualize a informao. Caso contrrio, a informao
migrada para o schema STAGING.
Numa segunda etapa, uma vez que o processo de recolha de dados j foi executado e toda a
informao enviada pelo cliente se encontra de acordo com o que foi definido, torna-se possvel enviar
os dados recolhidos para o schema STAGING e passar a um processo de verificao da qualidade dos
mesmos. Esta fase de verificao da qualidade dos dados pode cobrir os seguintes aspectos:
Duplicao de registos
Integridade dos dados
Tipo de dados

54
 /
!

Propriedades de tabela
Caso seja detectado algum erro a este nvel, ser necessrio marcar o registo como encontrando-
se errado e enviar um e-mail ao cliente a informar desta situao, para que os dados sejam corrigidos.
Assim que a informao esteja verificada, possvel proceder-se transformao dos dados para
o schema MIGRA, que constitudo por diversas tabelas que contm informao do sistema fonte
(MAP OLD) e do sistema ALERT (MAP NEW). O primeiro carregamento a ser executado, neste
schema, consiste no preenchimento da MAP OLD. De seguida analisado se existe mapeamento entre
esse contedo e o contedo que j existe no ALERT. Em caso afirmativo, realizado o mapeamento
para a MAP NEW. Em caso negativo, feita uma cpia do contedo da MAP OLD para a MAP
NEW. Em qualquer situao pertinente registar os novos identificadores (ID) na MAP NEW, que
vo estar presentes no ALERT.
Por ltimo, necessrio identificar os registos que esto em condies para serem migrados para
o sistema ALERT, ou seja, os registos que foram carregados correctamente na rea intermdia e que
passaram pela fase de transformao sem erros. No entanto, durante o processamento dos registos
marcados, pode ser identificado algum erro e caso isso acontea, necessrio marcar esse registo
como errado e lanar uma mensagem, para que o registo identificado seja actualizado.
Terminado este processo e caso no seja detectado nenhum erro, a informao migrada para o
ALERT, dando-se assim por concludo o processo de migrao de dados, informando o cliente desta
situao. Com o intuito de manter um histrico do processo de migrao, os dados no sero apagados
do schema MIGRA.
Na Figura 16, que se apresenta de seguida, possvel obter uma viso global dos processos que
esto envolvidos na migrao de dados para o sistema ALERT, com recurso Data Migration
Framework.

55
 /
!

Figura 16 - Progresso dos processos da Data Migration Framework

56
 /
!

3,2 - &

Uma base de dados pode ser descrita como um simples repositrio de informao relacionada
entre si, com um determinado tema ou assunto. constituda por uma coleco de dados
estruturados de determinada maneira que permite a sua consulta, actualizao e outro tipo de
operaes processadas por meios informticos.
Para uma melhor operacionalizao da Data Migration Framework, foram desenvolvidos
diversos objectos a nvel de base dados, nomeadamente, tabelas, sequncias, triggers, DBLinks e
packages, organizados por diferentes schemas e que a seguir se descrevem.

3,2,+ 4 & %

Devido necessidade de organizar a informao e os objectos gerados durante o processo de

migrao de dados, foram criados seis schemas associados plataforma de migrao:
1 - STAGING representa a rea intermdia onde vo ser inseridos e validados os dados a
serem migrados para o ALERT. O modelo de base dados elaborado para o schema STAGING,
referente rea dos profissionais, encontra-se parcialmente ilustrado no Anexo B Tabelas do schema
STAGING;
2 - MIGRA representa a rea onde sero efectuados os mapeamentos dos registos migrados. O
modelo de base dados elaborado para o schema MIGRA, referente rea dos profissionais, encontra-
se parcialmente ilustrado no Anexo C Tabelas do schema MIGRA;
3 - MIG_LOG_STG - representa a rea onde sero registados todos os logs do processo de
migrao do schema STAGING para o MIGRA;
4 - MIG_LOG_ALERT representa a rea onde sero registados todos os logs do processo de
migrao do schema MIGRA para o ALERT;
5 - MIG_CONTROL_STG representa a rea onde sero criados os objectos temporrios,
devido utilizao do Oracle Data Integrator, que auxiliam o processo de migrao do schema
STAGING para o MIGRA.
6 - MIG_CONTROL_ALERT representa a rea onde sero criados os objectos temporrios
que auxiliam o processo de migrao do schema MIGRA para o ALERT.
O sistema ALERT, para o qual se pretende migrar os dados constitudo por quatro schemas
designados por: ALERT, ALERT_ADTCOD, ALERT_ADTCOD_CFG, FINGER_DB. A relao
entre os diferentes schemas, quer da plataforma de migraes quer do ALERT, descrita na Figura
17.

51
 /
!

Figura 17- Schemas de base de dados

Pela observao da Figura 17 possvel identificar todos os schemas que esto envolvidos no
processo de migrao de dados entre a rea intermdia e o sistema de destino ALERT. Torna-se
ainda possvel constatar que existe uma ordem entre os diferentes schemas que vo desde a recepo
dos dados do sistema fonte at insero dos mesmos no sistema de destino. O primeiro schema a
receber os dados a STAGING que, depois de os validar, envia os dados para o schema MIGRA. A
fase intermdia que se encontra no schema MIG_CONTROL_STG utilizada para armazenar todos
os objectos temporrios que auxiliam o processo de migrao, gerados atravs da utilizao do Oracle
Data Integrator. Caso o processo de migrao dos dados da STAGING para o MIGRA, ou do
MIGRA para ele prprio origine algum erro, essa informao armazenada no schema
MIG_LOG_STG. A migrao entre o schema MIGRA e ele prprio corresponde ao processo de
mapeamento, descrito na seco 4.1.4.

52
 /
!

Aps a fase de mapeamento, necessrio migrar toda a informao que esteja validada para os
diferentes schemas de destino, nomeadamente: ALERT, ALERT_ADTCOD,
ALERT_ADTCOD_CFG e FINGER_DB. A rea intermdia entre o schema MIGRA e um dos
sistemas de destino utilizada para armazenar os objectos temporrios gerados pela utilizao do ODI
e designada por MIG_CONTROL_ALERT. Este schema possui a mesma funcionalidade que o
schema MIG_CONTROL_STG, mas encontra-se numa fase mais avanada do processo de migrao.
O schema MIG_LOG_ALERT possui todos os objectos que permitem averiguar se ocorreu algum
erro no carregamento dos dados do schema MIGRA para os schemas de destino.

3,2,/ - %& # # # $ &

Para o bom desenvolvimento de todo o processo de migrao de dados, necessrio que os

objectos a nvel de base de dados obedeam a uma determinada estrutura e nomenclatua nos diferentes
schemas, nomeadamente:

Schema STAGING
No schema STAGING existem trs tipos de tabelas que se diferenciam pelo tipo de dados que
possuem, nomeadamente: dados transaccionais (operacionais), dados com contedo ALERT, os
quais devero ser mapeados, e dados com contedos do cliente, que podem ser migrados ou mapeados
com o contedo ALERT. Consoante o tipo de contedos, estas tabelas devem incluir os seguintes
prefixos:
Contedos do sistema fonte que tm de ser mapeados com o ALERT: CA_;
Contedos a migrar ou a mapear caso exista correspondncia no ALERT: CC_;
Contedos operacionais a migrar para o ALERT: CO_.
O nome das tabelas no schema STAGING dever ser similar s correspondentes no ALERT,
respeitando os prefixos anteriormente referidos, como exemplificado na Tabela 4. Note-se que, os
nomes das tabelas devero estar no singular, excepo das tabelas que j esto no plural no
ALERT.

NOME DA TABELA NO ALERT NOME DA TABELA NA STAGING

CC_HEALTH_PLAN CC_HPLN

CC_BED CC_BED

Tabela 4 - Definio de alias de tabelas do schema STAGING

5-
 /
!

Todas as tabelas da STAGING devero ter uma coluna FLG_MIGRATION obrigatria, que
permite identificar se o registo j foi migrado para o ALERT.
As tabelas de contedo ALERT, exemplificadas na Tabela 5, iro herdar das tabelas ALERT
apenas as colunas do tipo ID_ e FLG_, se necessrio, ou outras colunas com informao
relevante. Estas tabelas tambm devero ter duas colunas do tipo CODE_, que tero o descritivo do
contedo do cliente e o descritivo traduzido do contedo ALERT, respectivamente. Estas colunas,
relativas ao contedo ALERT, devero ter o prefixo CA_. As colunas relativas ao contedo do
sistema externo devero ser idnticas s colunas do ALERT.

ALERT.DEPT STAGING.CA_DEPT

ID_DEPT ID_DEPT

CODE_DEPT CODE_DEPT

ID_INSTITUTION ID_INSTITUTION

ABBREVIATION

RANK

CA_ID_DEPT

CA_CODE_DEPT

CA_ID_INSTITUTION

FLG_MIGRATION

Tabela 5 - Exemplo de uma tabela do tipo "CA_"

O nome das colunas das tabelas do schema STAGING dever ser similar s correspondentes no
ALERT. No entanto, para se poder adoptar mais facilmente a rea intermdia ao contedo
proveniente do sistema fonte, foi necessrio definir o tipo de dados da STAGING diferente do tipo de
dados presente no ALERT (exemplo: Number(7) no ALERT e Varchar2(7) na STAGING).
No que diz respeito, s tabelas com contedo a migrar ou a mapear (CC_), estas tambm vo
herdar das tabelas ALERT apenas as colunas do tipo ID_ e FLG_, se necessrio, ou outras
colunas com informao relevante. Assim como uma coluna do tipo CODE_, que ter o descritivo
do contedo do cliente, como exemplifica a Tabela 6.

6,
 /
!

ALERT.BED STAGING.CC_BED

ID_BED ID_BED

CODE_BED CODE_BED

ID_ROOM ID_ROOM

FLG_TYPE FLG_TYPE

FLG_STATUS FLG_STATUS

DESC_BED DESC_BED

NOTES NOTES

RANK

FLG_AVAILABLE

FLG_MIGRATION

Tabela 6 - Exemplo de uma tabela do tipo "CC_"

Conforme se pode observar na Tabela 6, a coluna RANK do ALERT no foi mapeada para a
tabela do schema STAGING. Assim, s necessrio mapear as colunas do ALERT com informao
relevante a ser migrada.
Relativamente, as tabelas do tipo CO_ do schema STAGING, devero corresponder a todas as
tabelas transaccionais do ALERT com relaes de 1-1, como exemplifica a Tabela 7.

TABELAS ALERT (1-1) TABELA STAGING

ALERT.PROFESSIONAL

(informao referente identificao dos profissionais de

sade) STAGING.CO_PROFESSIONAL

ALERT.SYS_USER (informao referente aos profissionais de

sade e respectiva informao de login)
(informao referente ao processo de login de cada
profissional de sade. Cada profissional tem apenas um
processo de login)

Tabela 7 - Descrio de tabelas do tipo "CO_"

Schema MIGRA
O schema MIGRA contm tabelas de mapeamento que tero, no prprio nome, o prefixo
MAP_. Estas tabelas devero ter colunas que iro conter os dados provenientes do sistema fonte,
com o prefixo OLD_, e os dados a migrar, com o prefixo NEW_. Para auxiliar o processo de
60
 /
!

migrao, as tabelas de mapeamento, exemplificadas na Tabela 8, devero ter uma coluna denominada
FLG_STATUS. Esta coluna indicar, por exemplo, se o registo j est mapeado, ou se para migrar,
ou ainda se migrou com sucesso ou com erro.

ALERT.PROFESSIONAL MIGRA.MAP_PROFESSIONAL

ID_PROFESSIONAL OLD_ID_PROFESSIONAL

NEW_ID_PROFESSIONAL

NAME OLD_NAME

NEW_NAME

FLG_STATE OLD_FLG_STATE

NEW_FLG_STATE

FLG_STATUS

Tabela 8 - Exemplo de uma tabela de Mapeamento

Schema MIG_LOG
Os schemas MIG_LOG_STG e MIG_LOG_ALERT contm as tabelas de log do processamento
do schema STAGING para o schema MIGRA e do schema MIGRA para o schema ALERT, que
devero ter, no prprio nome, os prefixos ERR$_MAP_ e ERR$_, respectivamente. Estas tabelas
tm uma estrutura idntica s tabelas de origem (tabelas do schema MIGRA ou ALERT) com mais
cinco colunas:
ORA_ERR_NUMBERS$ nmero do erro do Oracle;
ORA_ERR_MESG$ mensagem em texto do erro Oracle;
ORA_ERR_ROWID$ Rowid da linha em erro (para actualizar ou apagar);
ORA_ERR_OPTYP$ Tipo de operao: inserir (I), actualizar (U) e apagar (D);
ORA_ERR_TAG$ Valor da tag fornecida pelo utilizador na clusula do erro.
As tabelas de log, exemplificadas na Tabela 9, so geradas automaticamente atravs da
utilizao de uma funo de base dados designada por
PK_MIGRA_MODEL_ERROR.F_CREATE_ERR_INDIV.

6+
 /
!

MIG_LOG.ERR$_MAP_PROFESSIONAL MIG_LOG.ERR$_PROFESSIONAL

ORA_ERR_NUMBERS$ ORA_ERR_NUMBERS$

ORA_ERR_MESG$ ORA_ERR_MESG$

ORA_ERR_ROWID$ ORA_ERR_ROWID$

ORA_ERR_OPTYP$ ORA_ERR_OPTYP$

ORA_ERR_TAG$ ORA_ERR_TAG$

OLD_ID_PROFESSIONAL ID_PROFESSIONAL

NEW_ID_PROFESSIONAL

OLD_NAME NAME

NEW_NAME

OLD_FLG_STATE FLG_STATE

NEW_FLG_STATE

FLG_STATUS

Tabela 9 - Exemplo de uma tabela de log

3,2,2 - <

Na estrutura de migraes existe uma tabela geral de configurao de sistema, designada por
SYS_CONFIG que contm opes de configurao do processo de migrao. As diversas colunas
desta tabela devem ser preenchidas com base em:
ID_SYS_CONFIG Identificador de configurao;
VALUE Valor do parmetro de configurao;
DESC_SYS_CONFIG Descrio de configurao.
Para o bom funcionamento do processo de migrao, as regras de configurao de registos so
essenciais, visto que o cdigo construdo volta desta tabela parte do pressuposto de que os registos
so parametrizados sob determinada forma.

63
 /
!

3,3 4 ' &'

Nesta seco pretende-se descrever todas as fases relacionadas com o processo de

implementao e desenvolvimento da Data Migration Framework, assim como o processo de
extraco de dados do sistema fonte para a rea intermdia, recorrendo a ficheiros no formato XML.

3,3,+ 4 = % >

O Altova XMLSpy um editor de XML (eXtensible Markup Language) padro e corresponde a

um ambiente de desenvolvimento XML para modelagem, edio, depurao e transformao de todas
as tecnologias XML. O XMLSpy oferece uma produtividade aperfeioada para os programadores que
trabalham com as tecnologias XML, Web services e base de dados.
O recurso ao XML permite uma maior simplicidade, extensibilidade, interoperabilidade e
flexibilidade, o que oferece uma maior performance para representar dados independentes de
programao, linguagem, plataforma ou sistema operacional. Hoje, as tecnologias XML possuem uma
funo crtica em todo o software de desenvolvimento de projectos, e dos programadores que
precisam de ferramentas para criao, edio e depurao nas tecnologias XML.
O recurso ao XML possibilita a representao dos dados com base num formato padro,
independente do sistema operacional, plataforma e linguagens de programao usadas.
Para ir de encontro a um dos objectivos traados, que permitir que o cliente carregue a rea
intermdia atravs de ficheiros em XML, foi desenvolvida uma ferramenta que possibilita criar
ficheiros XML a partir de queries de base de dados.
Uma outra situao inerente a esta questo, consiste em elaborar um mtodo que possibilite
validar rapidamente o ficheiro XML que o cliente vai enviar, com os dados a migrar. Ou seja,
preciso validar se a informao que est nos ficheiros se encontra de acordo com o modelo de base de
dados desenvolvido (schema STAGING). Uma vez que um documento em XML , basicamente, um
conjunto de dados estruturados, com relaes entre si, recorreu-se ao XML Schema (XSD), cujo
principal objectivo a validao do documento XML a que est associado.
A validao pode ser realizada a vrios nveis, entre eles:
Primary keys;
Check Constraints;
Unique keys;
Tamanho dos campos de cada tabela.
O padro XSD ou XS (XML Schema) a recomendao oficial do W3C [2] desde 2001 para
validao de documentos XML. Atravs do XSD possvel construir tipos prprios derivados de tipos

64
 /
!

mais bsicos, realizar relacionamentos entre elementos de dados dentro do XML, de modo semelhante
aos relacionamentos entre tabelas de base de dados.
O XML Schema corresponde a um mecanismo eficiente para assegurar a qualidade dos dados,
assim como uma base de dados. Esta proximidade, no entanto, no significa que os documentos XML
devam substituir uma base de dados relacional ou devam ser utilizados como tal. Ainda que o XML
Schema possua estruturas muito similares de validao, os ficheiros de XML no apresentam algumas
das caractersticas essenciais encontradas em bases de dados como o caso da gesto da concorrncia,
na eficincia da organizao interna de dados mais eficiente, na segurana, etc.
Para gerar ficheiros XML a partir de uma query, foi criado um package na base dados,
designado por PK_GEN_XML_RESULT (Figura 18).

Figura 18 - Package para criao de ficheiros XML

Atravs da visualizao da Figura 18 possvel constatar que esta funcionalidade permite uma
maior facilidade de gerao de ficheiros XML, para o cliente, uma vez que independentemente do
sistema de base de dados que este utilize. Com esta funo apenas necessrio identificar a query a
exportar, a tabela de destino da rea intermdia e o nmero de registos que se pretende por ficheiro.
Para a validao do ficheiro XML, foi criado um package na base de dados que permite gerar
ficheiros XSD, indicando apenas o nome da tabela da STAGING. Existe, contudo, um outro
parmetro de entrada que permite, aquando da gerao do ficheiro, esconder uma coluna da tabela da
STAGING uma vez que existem campos da tabela que no so de interesse para o cliente, mas sim
para o processo de migrao. A Figura 19 ilustra o package que necessrio executar para gerar o
ficheiro de validao do XML.

65
 /
!

Figura 19 - Package para criao de ficheiros XSD

Para validar o ficheiro XML com o XSD, basta executar as linhas de comando ilustradas na
Figura 20. Esta validao permite testar se o ficheiro XML elaborado pelo cliente est apto para ser
integrado na rea intermdia e posteriormente migrado para o ALERT.

Figura 20 Validar o ficheiro XML com o ficheiro XSD

O processo de validao do ficheiro XML, com o ficheiro XSD, fundamental para avaliar se a
estrutura dos dados que o cliente est a enviar se encontra de acordo com a estrutura do modelo de
dados da rea intermdia (schema STAGING). A utilizao do ficheiro XSD torna o processo de
validao numa tarefa simples, rpida e eficiente.

66
 /
!

3,3,/ - ) # ?

Para se proceder migrao dos dados para o sistema ALERT, foram desenvolvidas as
seguintes tarefas:

Definio da Topologia
Na topologia do ODI necessrio configurar a arquitectura lgica e fsica e definir os contextos.
Entende-se por contexto, todo o processo de migrao dos sistemas fonte para um determinado
sistema de destino. O nmero de contextos vai ser igual ao nmero de schemas que se encontram no
sistema de destino, abaixo descritos:
O processo que MIGRA informao do schema STAGING para o schema ALERT
(STAGING -> MIGRA -> ALERT),
O processo que consiste em migrar a informao do schema STAGING para o schema
FINGER_DB (STAGING -> MIGRA -> FINGER_DB).
O processo responsvel por migrar a informao do schema STAGING para o schema
ALERT_ADTCOD (STAGING -> MIGRA -> ALERT_ADTCOD).
O processo encarregue em migrar a informao do schema STAGING para o schema
ALERT_ADTCOD_CFG (STAGING -> MIGRA -> ALERT_ADTCOD_CFG).
A existncia de quatro schemas de destino diferentes vai dar origem a quatro processos de
migrao diferentes, o que implica ter quatro contextos distintos. A Figura 21 exemplifica a relao
entre o conceito de contexto, processo de migrao e schemas de destino.

Figura 21 Exemplo de contextos ODI

61
 /
!

No Oracle Data Integrator, todos os desenvolvimentos, bem como as execues so realizadas

em cima de uma arquitectura lgica, relacionada com um determinado contexto e uma arquitectura
fsica. A arquitectura lgica corresponde a uma representao do modelo de base de dados
incorporada no ODI, ao passo que, a arquitectura fsica corresponde estrutura real do modelo de base
de dados. A definio dos contextos permitem alternar a execuo dos objectos de um ambiente para
outro. Atravs da Figura 22 possvel descrever graficamente como a topologia no ODI foi definida
para o desenvolvimento da Data Migration Framework.

Figura 22 - Topologia ODI

62
 /
!

Pela visualizao da Figura 22, possvel constatar que a topologia no ODI constituda por trs
camadas, nomeadamente: arquitectura fsica, arquitectura lgica e contextos.
A arquitectura fsica constituda pelo DEV_ALERT e DEV_STAGING que representam dois
servidores, distintos, a nvel de base de dados. O DEV_ALERT constitudo pelos schemas do
sistema de destino e o DEV_STAGING constitudo pelos schemas que contm informao referente
ao sistema fonte.
A arquitectura lgica abranje um conjunto de schemas lgicos que representam os respectivos
schemas fsicos, definidos na arquitectura fsica. A quantidade de schemas lgicos idntica
quantidade de schemas fsicos, ou seja, na Data Migration Framework vai haver um total de oito
schemas lgicos e oito schemas fsicos.
No que diz respeito definio dos contextos, como existem quatro schemas de destino
diferentes, ter-se- quatro processos de migrao diferentes, o que implicar ter quatro contextos.

Criao do Agente
O agente uma componente especial do Oracle Data Integrator, que coordena os processos de
integrao enviando comandos a diferentes tecnologias, em background. Com esta componente
possvel agendar tarefas, como por exemplo definir uma data e hora para iniciar o processo de
migrao sem ser necessrio o apoio presencial de um tcnico.
Para criar ou configurar um agente, necessrio executar os seguintes passos:
1 - Localizar o ficheiro odiparams.bat, em \\<ODI_oracle_home>\ODI\oracledi\bin.
2 - Editar o ficheiro e actualizar a informao referente ligao com os repositrios mestre e
trabalho.
3 - Criar o servio.
4 - Definir o agente na arquitectura fsica do ODI.
5 - Testar o agente fsico, no ODI.
6 - Definir o agente na arquitectura lgica do ODI.
7 - Testar o agente lgico, no ODI.
8 - Aps estas operaes, possvel iniciar o servio associado ao agente e test-lo.
Posteriormente, para fazer uso do agente, necessrio associar contextos ao agente.

Execuo do Reverse Engineering

O Oracle Data Integrator permite utilizar o processo de reverse engineering para reverter o
modelo de dados da base de dados, para o modelo de dados do ODI. Este mdulo inclui a descrio de

6-
 /
!

schemas, estrutura de base de dados, campos e colunas de tabelas, regras para a integridade dos dados,
referncias cruzadas, entre outros.
Quem desenvolve no ODI pode igualmente criar novas regras declarativas
sem codificao, usando o interface grfico designado por Designer.
Para reverter as tabelas que se encontram na base de dados para o modelo de dados do ODI,
necessrio seleccionar a tab Reverse no mdulo de Designer do ODI, como ilustra a Figura 23:

Figura 23 - Seleco do contexto de reverse

Nesta execuo, define-se o contexto que ir ser utilizado para o reverse engineering do modelo
de dados, previamente determinado. Posteriormente, na tab Selective Reverse escolhe-se as tabelas a
importar e selecciona-se a opo Reverse.
Devido a um problema interno do ODI, que no momento do reverse engineering converte os
campos do tipo TIMESTAMP ou TIMESTAMP WITH LOCAL TIME ZONE com dimenso seis para
campos do mesmo tipo com dimenso 11, foi necessrio adicionar um trigger na tabela SNP_COL
que se encontra no repositrio de trabalho. Esta alterao essencial para que no momento do reverse,
o tipo e a dimenso do campo no sejam alterados e deste modo garantir a coerncia entre o modelo
de dados da base dados e o modelo de dados do ODI.

1,
 /
!

Configurao de mdulos de conhecimento (KM)

Os KM do Oracle Data Integrator so componentes que implementam transformaes
reutilizveis. O poder dos KM reside na sua reutilizao e flexibilidade, que permite desenvolver e
implementar uma estratgia para carregar os dados do sistema fonte nas diferentes tabelas do sistema
de destino, uma vez que possvel misturar e combinar vrias linguagens de programao, tipos e
estilos num KM. O Oracle Data Integrator executa cinco diferentes tipos de KM e cada um deles
abrange uma fase do processo de migrao do sistema fonte ao sistema de destino. Seguidamente so
descritos os trs mdulos de conhecimento que foram utilizados e alterados para se adaptarem ao
processo de migrao de dados na Data Migration Framework:
1 Loading Knowledge Module (LKM)
Para o desenvolvimento da DMF utilizado o LKM Oracle to Oracle (DBLINK), por ser
apropriado para grande volume de dados. Este LKM utilizado para carregar a informao que ser
migrada entre uma base de dados Oracle e uma base de dados Oracle intermdia, usando DBLinks
para aceder aos dados de origem a partir de uma base de dados intermdia. de considerar a
utilizao deste LKM apenas se as tabelas fonte estiverem localizadas numa base de dados Oracle
diferente da base de dados da rea intermdia. A informao fonte no duplicada na rea intermdia,
simplesmente referenciada atravs de um sinnimo. Para fins de optimizao possvel melhorar o
LKM adicionando um passo extra que copia o contedo do sinnimo remoto para uma tabela real na
rea intermdia. A Figura 24, que a seguir se apresenta, ilustra em detalhe todas as tarefas inerentes a
este LKM.

Figura 24 - LKM Oracle to Oracle (DBLINK)

10
 /
!

2 Integration Knowledge Module (IKM)

Para o desenvolvimento da DMF utilizado apenas o Oracle Incremental Update (PL SQL),
ilustrado na Figura 25. Este IKM cria uma tabela intermdia, temporria, para preparar a fase de
passagem dos dados para o sistema de destino. Posteriormente, compara o contedo presente na tabela
temporria com a tabela do sistema de destino para identificar quais os registos que devem ser
inseridos e quais os que devem ser actualizados. Este IKM deve ser utilizado no caso de se pretender
inserir registos em falta no sistema de destino ou actualizar registos recentes.

Figura 25 - IKM Oracle Incremental Update (PL SQL)

3 - Journalization Knowledge Module (JKM)

Para o desenvolvimento da DMF usado o Oracle 10g Consistent (LOGMINER). Este JKM cria
uma infra-estrutura jornalizada para que seja possvel jornalizar, de um modo consistente, as tabelas
que se pretendem monitorizar. Os dados alterados so capturados pela funcionalidade Log Miner que
permite a captura consistente de alteraes nos dados. A Figura 26 ilustra, em pormenor, as tarefas
inerentes ao JKM utilizado na DMF.

1+
 /
!

Figura 26 - JKM Oracle 10g Consistent (LOGMINER)

Para cada um dos KM descritos anteriormente, o ODI cria internamente tabelas e views
temporrias, com um prefixo especfico, como ilustra a Tabela 10. Estes objectos so criadas no
schema MIG_CONTROL_STG ou MIG_CONTROL_ALERT, dependendo da fase em que se
encontre o processo de migrao.

13
 /
!

PREFIXO DESCRIO

I$_<nome da tabela> Tabelas temporrias e internas de integrao

C$_<nome da tabela> Tabelas temporrias e internas de carregamento

E$_<nome da tabela> Tabelas internas de erro

J$_<nome da tabela> Tabelas temporrias e internas de Jornalizao

JV$_<nome da tabela> Views de Jornalizao

Tabela 10 - Prefixo de tabelas e views internas do ODI

Criao de Tabelas Jornalizadas

A definio das tabelas do modelo de dados do ODI que sero monitorizadas pelo Oracle
Change Data Capture (CDC), s pode ser executado depois do reverse do modelo de dados.
Associado ao processo de aplicao da jornalizao, necessrio considerar os seguintes passos:
1 - Seleccionar o JKM do modelo, ou seja, o JKM Oracle 10g Consistent (LOGMINER). Esta
operao realizada uma nica vez e para tal dever seleccionar-se a opo Consistent Set, na tab
Journalizing, das propriedades do modelo, ao qual se aplica o Journal das tabelas, como
evidenciado na Figura 27:

Figura 27 - Seleco do JKM, para o modelo

14
 /
!

2 - Adicionar a todas as tabelas, sobre as quais se pretende aplicar o Journal ao CDC, a opo
Add to CDC, visvel na Figura 28.

Figura 28 - Adicionar tabela ao CDC

3 - Criao dos Subscribers. O nmero de Subscribers a criar depende do mtodo de ETL

adoptado. Para o desenvolvimento da Data Migration Framework foi criado apenas um subscriber
(Figura 29) designado por STAGING_25, uma vez que se optou por ter apenas um subscriber para
cada schema com objectos jornalizados. Como s existe o schema STAGING com tabelas
jornalizadas, ento ter-se- apenas um subscriber.

Figura 29 - Criao de Subscriber

15
 /
!

4 - Activar o Journal, para todas as tabelas do modelo, atravs da tab Models (Figura 30).

Figura 30 - Activao do Journal

Aps seguir os passos descritos anteriormente e exemplificados na Figura 27, Figura 28, Figura
29 e Figura 30, exequvel monitorizar qualquer alterao que ocorra a nvel do modelo de base de
dados. Recorrendo a esta funcionalidade possvel manter os dados do sistema de destino sempre
actualizados, permanecendo de acordo com a informao presente no sistema fonte.

3,3,2 - ' &' %&

A camada intermdia da plataforma de migrao de dados para o ALERT desenvolvida

usando o Oracle Data Integrator. importante referir que a dimenso do projecto de migrao de
dados elevada e como tal implica a criao de um grande nmero de objectos no ODI e que, por essa
razo, fundamental que sejam definidas regras desde o incio e prioritizadas tarefas.
Nesta seco sero identificados os diferentes cenrios desenvolvidos durante o processo de
criao da Data Migration Framework, assim como as funes a nvel de base dados adequadas a
cada fase do processo de migrao de dados.
O processo de desenvolvimento da Data Migration Framework pode ser dividido em seis fases.

Fase I - criao das tabelas de Mapeamento e de Log

A primeira fase corresponde criao de todos os objectos auxiliares ao processo de migrao
de dados, ou seja, a criao das tabelas de mapeamento e de log. Nesse sentido foram criados dois

16
 /
!

packages de base de dados, que criam de forma automtica as tabelas de mapeamento e de log,
designados por:
PK_GENERATE_MAP_TABLE.F_CREATE_SCRIPT_TABLE_MAP responsvel por
criar as tabelas de mapeamento;
PK_MIGRA_MODEL_ERROR.F_CREATE_ERR_INDIV responsvel por criar as
tabelas de log.
de realar que as tabelas de mapeamento e o package responsvel pela sua criao so
armazenados no schema MIGRA. O package responsvel pela criao das tabelas de log, assim como
os objectos gerados por ele, so armazenados em schemas prprios de base de dados designados por
MIG_LOG_STG e MIG_LOG_ALERT. A utilizao destes dois schemas prende-se com o facto de
ser necessrio separar as tabelas de log que ocorrem durante a passagem de informao do schema
STAGING para o schema MIGRA, da que ocorre durante a passagem da informao do schema
MIGRA para o schema ALERT. A descrio de cada funo utilizada nesta fase registada na Tabela
11 e que a seguir se d conta.

FUNES DESCRIO

Esta funo permite gerar de uma forma automatizada

PK_GENERATE_MAP_TABLE.
as tabelas de mapeamento, utilizadas no schema
f_create_script_table_map
MIGRA.

Esta funo responsvel por criar de forma

PK_MIGRA_MODEL_ERROR. automatizada as tabelas de log, utilizando a funo

F_CREATE_ERR_INDIV DML Error Logging da Oracle, nos schemas

MIG_LOG_STG e MIG_LOG_ALERT.

Tabela 11 - Criao das tabelas de mapeamento e de log

Fase II - carregamento da STAGING, utilizando ficheiros XML

O processo de carregamento da STAGING realizado por reas e de forma ordenada,
comeando pela informao base, seguido da informao dos profissionais, pacientes, visitas,
episdios, entre outros. de salientar que o nmero de visitas a que um paciente est associado
corresponde ao nmero de vezes que o paciente se deslocou a uma determinada instituio hospitalar.
Uma vez na instituio, o paciente pode, por exemplo, dar entrada no servio de urgncia, de seguida
ser internado e por fim ter alta e ir para casa. Isto significa que o paciente, naquela instituio, tem
uma visita e dois episdios.
Para cada rea so utilizados vrios ficheiros no formato XML com contedo do sistema fonte,
no entanto, para uma determinada tabela de destino da STAGING pode corresponder mais do que um

11
 /
!

ficheiro no formato XML, o que vai de encontro a uma limitao do ODI que obriga existncia de
uma arquitectura fsica por cada ficheiro XML distinto, mesmo que tenha a mesma estrutura, ou seja,
mesmo que os ficheiros XML sejam carregados na mesma tabela de destino da STAGING. Assim,
necessrio definir uma estrutura de pastas que possibilite que todos os ficheiros XML, responsveis
por carregar a mesma tabela de destino da STAGING, sejam carregados usando a mesma arquitectura
fsica.
Esta alterao tem como objectivo tornar o processo de carregamento mais genrico, ou seja,
permite carregar vrios ficheiros XML com nomes diferentes mas com a mesma estrutura (exemplo:
documento1.xml, documento2.xml) de forma sequencial, usando para isso um nome genrico por cada
tabela da STAGING (exemplo: documento.xml).
A estrutura de pastas utilizada para ultrapassar esta limitao do ODI a seguinte:
ODI_IncomingFiles, onde so colocados todos os ficheiros, no formato XML, a migrar para
a STAGING;
ODI_Logs, onde so armazenados os ficheiros com informao do processo de
carregamento da STAGING;
ODI_FileLoad, onde so armazenados os ficheiros XSD, para validao dos ficheiros XML
e o ficheiro XML a ser processado no momento.
ODI_FileTemp, onde se encontram o ficheiro XML original a ser processado no momento
do processo de carregamento.
ODI_FileOK, onde so armazenados os ficheiros que foram carregados na STAGING com
sucesso;
ODI_FileFail, onde so armazenados os ficheiros que no foram carregados na STAGING
com sucesso.
Assim que a estrutura de pastas se encontre implementada, dever criar-se um package no
Oracle Data Integrator por cada tabela de destino a carregar na STAGING, que dever incluir os
seguintes elementos:
Interfaces, que consistem num conjunto de regras que definem o carregamento do modelo de
dados do sistema de destino a partir de um ou mais sistemas fonte.
Variveis, que devem ser criadas sempre ao nvel do projecto e com informao da aco
igual a NOT PERSISTENT, para que o valor da varivel seja sempre actualizado;
Procedimentos, que correspondem chamada de uma funo a nvel de base de dados.
Cada package no ODI tem a seguinte estrutura de tarefas nesta fase:
1 - Actualizar todas as variveis;
2 - Definir o valor da varivel VAR_IVC2_< nome da tabela> para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3 - Apagar o ficheiro que j foi processado da pasta ODI_FileLoad (caso exista);

12
 /
!

4 - Mover o ficheiro a processar da pasta ODI_IncomingFiles para a pasta ODI_FileTemp;

5 - Copiar o ficheiro da pasta ODI_FileTemp para a ODI_FileLoad, mudando o nome com o
intuito de generalizar o processo;
6 - Executar o procedimento PRC_XML_<STAGING nome da tabela>, para guardar o nome
original do ficheiro a ser processado;
7 - Em caso de erro, copiar o ficheiro da pasta ODI_FileTemp para a pasta ODI_FileFail;
8 - Executar o interface;
9 - Em caso de erro, copiar o ficheiro da pasta ODI_FileTemp para a pasta ODI_FileFail, caso
contrrio, copiar para a pasta ODI_FileOK;
10 - Actualizar o documento de log.
A Figura 31 permite uma melhor compreenso desta estrutura de tarefas.

Figura 31 Progresso XML/STAGING

Fase III carregamento inicial das tabelas jornalizadas

A utilizao de tabelas jornalizadas permite identificar qualquer alterao que ocorra a nvel de
base dados, ou seja, actividades de insero, actualizao e remoo. Deste modo, possvel garantir
que toda a informao que inserida na STAGING, independentemente da fase temporal em que se
encontre, seja migrada para o ALERT.
Para aplicar a jornalizao de uma tabela no interface do ODI necessrio activar a opo
Journalized Data only, na tabela que se pretende monitorizar as alteraes. Esta aco cria um filtro
ao qual se dever:
Acrescentar a condio JRN_FLAG <> 'D'. Desta forma, garante-se que os dados nunca
sero eliminados do sistema de destino. Os dados sero apenas inseridos ou actualizados.

1-
 /
!

Alterar o Subscriber para o pretendido.

Devem ser criados diferentes interfaces, por cada uma das tabelas jornalizadas que intervm no
carregamento da tabela de destino.
Atravs da Figura 32 possvel identificar os passos necessrios para a correcta migrao de
dados utilizando tabelas jornalizadas.

Figura 32 - Processos relacionados com as tabelas jornalizadas

O processo de migrao deve ter incio com a operao de Start (start journalizing e add
subscribers) no ODI, seguido da execuo do carregamento inicial recorrendo funo de base de
dados PK_LOAD_OLD.F_LOAD. Aps a fase de carregamento executada a operao Iniciar
(extend window e lock subscribers), seguido do respectivo package e terminando o processo com a
operao Terminar (purge journal e unlock subscribers).
A operao de carregamento inicial deve ser executada apenas na primeira vez que o processo de
migrao executado, uma vez que, as migraes diferenciais no necessitam desta opo, porque o
ODI j processou uma vez e encontra-se a monitorizar as alteraes realizadas desde ento (tabelas
jornalizas activas).
As operaes descritas anteriormente so importantes e como tal sero descritas em detalhe:
A operao de Start utilizada para registar qualquer alterao a nvel de base de dados,
mais concretamente nas tabelas que foram jornalizadas;
A operao de Iniciar responsvel por definir uma janela de aco, sobre o respectivo
subscriber e permitir identificar todas as alteraes que ocorram a nvel de base de dados, nas tabelas
jornalizadas, at aquele momento;
A operao Terminar fecha a janela de aco e limpa os dados processados;
A operao de STOP faz com que as tabelas jornalizadas deixem de estar vigiadas, ou seja,
qualquer alterao que ocorra nessas tabelas deixem de ser monitorizadas.
A funo de base de dados responsvel pelo carregamento inicial das tabelas jornalizadas
descrita na Tabela 12.

2,
 /
!

FUNO DESCRIO

Aps a tarefa de insero dos dados no schema

STAGING necessrio carregar essa informao nas
tabelas jornalizadas. Esta funo responsvel por
PK_LOAD_OLD.F_LOAD
fazer o primeiro carregamento das tabelas jornalizadas,
ou seja copiar a informao da tabela da STAGING
para uma tabela temporria e interna do ODI.

Tabela 12 - Carregamento inicial das tabelas jornalizadas

Fase IV - Migrao de dados da STAGING para a MAP OLD

A fase de migrao de dados da STAGING para a MAP OLD consiste em migrar a informao
que se encontra no schema STAGING, que contm tabelas do tipo CA_ (Tabela 5), CC_ (Tabela
6) e CO_ (Tabela 7), para o schema MIGRA.
Nesta fase, cada package no ODI varia consoante o tipo de tabelas. A estrutura do package, para
tabelas do tipo CA_, tem a seguinte estrutura de tarefas, como ilustra a Figura 33:
1 - Actualizar todas as variveis;
2 - Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3 - Executar o respectivo interface;
4 - Executar o procedimento PROC_MIGRA_VALIDATE_CA_STAGING, que referncia a
funo de base de dados PK_VALIDATE.F_VALIDATE_CA_STAGING, para analisar a existncia
ou no de mapeamento com o contedo ALERT.

Figura 33 - Progresso STAGING/MAP OLD para tabelas do tipo CA_

20
 /
!

A descrio de todas as funes de base de dados utilizados nesta fase encontram-se assinaladas
na Tabela 13.

FUNO DESCRIO

Para cada registo que est na tabela de mapeamento

(MAP OLD) necessrio analisar se j existe aquela

descrio no ALERT . Se no existir porque no
existe mapeamento entre o contedo do cliente e o do
PK_VALIDATE.
ALERT , logo actualiza-se a FLG_STATUS para N e
F_VALIDATE_CA_STAGING a FLG_MIGRATION tambm para N.
Caso exista mapeamento, a tabela de mapeamento e a
tabela da STAGING so actualizadas com
FLG_STATUS igual a Y e FLG_MIGRATION igual
a Y, respectivamente.
Funo que encripta a password do profissional com

PK_MIGRA_MODEL_ERROR. acesso ao sistema aplicacional ALERT . Esta funo

f_get_hash_val utiliza o DBMS_OBFUSCATION_TOOKIT.MD5, da

Oracle.
Uma vez que o ODI no permite utilizar campos do tipo
BLOB, foi necessrio criar esta funo para permitir a
migrao das fotos dos profissionais e dos pacientes.
PK_MIGRA_MODEL_ERROR.
Esta funo vai correr todos os registos da tabela do
F_INSERT_LOB_INDIV
schema STAGING para ir buscar as fotos e migrar para
a tabela de mapeamento, no schema MIGRA (MAP
OLD).

Tabela 13 - Funes referentes ao processo da STAGING/MAP OLD

A estrutura do package do ODI, para tabelas do tipo CC_ e CO_, semelhante e tem a
seguinte estrutura de tarefas, como ilustra a Figura 34 e a Figura 35, repectivamente:
1 - Actualizar todas as variveis;
2 - Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3 - Executar o respectivo interface.

2+
 /
!

Figura 34 - Progresso STAGING/MAP OLD para tabelas do tipo CC_

Figura 35 - Progresso STAGING/MAP OLD para tabelas do tipo CO_

Fase V - migrao de dados da MAP OLD para a MAP NEW

A fase de migrao de dados da MAP OLD para a MAP NEW corresponde fase em que a
informao proveniente do sistema fonte sofre uma transformao para se adaptar ao novo sistema.
Esta fase apenas para as tabelas do tipo CC_ (Figura 36) e CO_ (Figura 37).

23
 /
!

A estrutura do package do ODI, para tabelas do tipo CC_ tem a seguinte estrutura de tarefas
(Figura 36):
1. Actualizar todas as variveis;
2. Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3. Executar o procedimento PRC_MIGRA_F_MAP_DATA, que referncia a funo
PK_MAPING.F_MAP_DATA, para analisar o mapeamento entre o contedo do cliente e o contedo
ALERT;
4. Executar o procedimento PRC_MIGRA_F_UPDATE_SEQUENCE, que referncia a funo
de base de dados PK_SEQUENCE.F_UPDATE_TABLE_SEQUENCE, para gerar novos
identificadores, necessrios para a migrao dos dados para o ALERT;
5. Executar o respectivo interface.

Figura 36 - Progresso MAP OLD/MAP NEW para tabelas do tipo CC_

A diferena entre os packages do ODI para tabelas do tipo CC_ e do tipo CO_ consiste no
facto de no ser utilizado o procedimento PRC_MIGRA_F_MAP_DATA nos packages das tabelas do
tipo CO_, como visvel atravs da Figura 37. A estrutura do package do ODI, para tabelas do tipo
CO_ fica deste modo com a seguinte estrutura de tarefas:
1. Actualizar todas as variveis;
2. Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;

24
 /
!

3. Executar o procedimento PRC_MIGRA_F_UPDATE_SEQUENCE que referncia a funo

de base de dados PK_SEQUENCE.F_UPDATE_TABLE_SEQUENCE, para gerar novos
identificadores necessrios para a migrao dos dados para o ALERT;
4. Executar o respectivo interface.

Figura 37 - Progresso MAP OLD/MAP NEW para tabelas do tipo CO_

As funes de base de dados utilizadas nesta fase encontram-se descritas na Tabela 14.

FUNO DESCRIO

Esta funo percorre todos os registos da tabela de

mapeamento que se encontra no schema MIGRA (MAP
OLD) com FLG_STATUS igual a V e analiza se j
existe, ou no, aquela informao no ALERT. A
primeira actividade consiste em tentar mapear a
PK_MAPING.F_MAP_DATA informao presente na MAP OLD com o contedo

activo no ALERT , no entanto, caso no encontre
nenhuma informao, ento o registo da MAP OLD ir
tentar ser mapeado com a informao do contedo

ALERT inactivo.
Se no existir mapeamento ento actualiza-se a tabela

25
 /
!

de mapeamento com FLG_STATUS igual a 'V'. Se

existir mapeamento ento actualiza-se a FLG_STATUS
para M e todo o registo com a informao do

ALERT . Caso ocorra algum erro nesta fase o registo
actualizado com FLG_STATUS igual a E.
Esta funo percorre todos os registos da tabela de
mapeamento, identifica os registos que tm
FLG_STATUS igual a V e a sequncia

correspondente daquela tabela no ALERT . De seguida

PK_SEQUENCE. a tabela de mapeamento actualizada com a nova

F_UPDATE_TABLE_SEQUENCE sequncia do ALERT . Quando for executada a
migrao para o sistema de destino, estes sero os

identificadores que aqueles registos tero no ALERT .

Tabela 14 - Funes referentes ao processo da MAP OLD/MAP NEW

Fase VI - migrao de dados da MAP NEW para o ALERT

A fase correspondente migrao dos dados da MAP NEW para o ALERT corresponde fase
final do processo geral de migrao. A estrutura do package do ODI, para tabelas do tipo CC_
(Figura 38) fica deste modo com a seguinte estrutura de tarefas:
1 - Actualizar todas as variveis;
2 - Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3 - Executar o respectivo interface;
4 - Executar o procedimento PRC_MIGRA_F_VALIDATE_MIGRATION_INDIV que
referncia a funo de base dados PK_VALIDATE.F_VALIDATE_MIGRATION_INDIV;
5 - Executar o procedimento PRC_MIGRA_F_INSERT_TRANSLATION_INDIV que
referncia a funo de base de dados PK_INSERT_TRANSLATION.F_TRANSLATION_INDIV;
6 - Executar o procedimento PRC_MIGRA_F_VALIDATE_CC_STAGING que referncia a
funo de base de dados PK_VALIDATE.F_VALIDATE_CC_STAGING.

26
 /
!

Figura 38 - Progresso MAP NEW/ALERT para tabelas do tipo CC_

A diferena entre os packages do ODI para tabelas do tipo CC_ e do tipo CO_ assenta no
facto de ser utilizada a funo PRC_MIGRA_F_API_ALERT_SET_DATA_GOV nos packages das
tabelas do tipo CO_, como visvel atravs da Figura 39. A estrutura do package no ODI, para
tabelas do tipo CO_ fica deste modo com a seguinte estrutura de tarefas:
1. Actualizar todas as variveis;
2. Definir o valor da varivel VAR_IVC2_TABLE_NAME para ser o mesmo nome da tabela
da rea intermdia a ser carregada;
3. Executar o respectivo interface;
4. Executar o procedimento PRC_MIGRA_F_VALIDATE_MIGRATION_INDIV que
referncia a funo de base dados PK_VALIDATE.F_VALIDATE_MIGRATION_INDIV;
5. Executar o procedimento PRC_MIGRA_F_INSERT_TRANSLATION_INDIV que
referncia a funo de base de dados PK_INSERT_TRANSLATION.F_TRANSLATION_INDIV;
6. Executar o procedimento PRC_MIGRA_F_API_ALERT_SET_DATA_GOV que referncia
a funo de base de dados PK_MIGRA_MODEL_ERROR.F_INSERT_ALERT_LOB_INDIV;
7. Executar o procedimento PRC_MIGRA_F_VALIDATE_CC_STAGING que referncia a
funo de base de dados PK_VALIDATE.F_VALIDATE_CC_STAGING.

21
 /
!

Figura 39 - Progresso MAP NEW/ALERT para tabelas do tipo CO_

As funes de base de dados utilizadas nesta fase encontram-se descritas na Tabela 15.

FUNO DESCRIO
Esta funo identifica todos os registos da tabela de
mapeamento com FLG_STATUS = C e analisa se na
tabela de log correspondente foi identificado algum
erro. Se for detectado algum erro ento a tabela de
PK_VALIDATE.
mapeamento actualizada com FLG_STATUS igual a
F_VALIDATE_MIGRATION_INDIV
E. Caso contrrio pode-se actualizar a FLG_STATUS
com o valor T para que de seguida, caso exista, seja
actualizada a tabela Translation correspondente no
ALERT.
Percorre todos os registos da tabela de mapeamento
com FLG_STATUS igual a T e actualiza a descrio

PK_INSERT_TRANSLATION. desse registo no ALERT. Actualiza tambm no

F_TRANSLATION_INDIV schema MIGRA a FLG_STATUS para Y.

Em caso de erro a FLG_STATUS actualizada para E
e inserido um registo informativo dessa situao na

22
 /
!

tabela ERR$_TRANSLATION.
Se no tiver nada para actualizar no ALERT, ento a
tabela de mapeamento actualizada com
FLG_STATUS igual a Y.
Esta funo procura todos os registos da tabela de
mapeamento com FLG_STATUS igual a E, Y ou
M e todos os registos nas tabelas da STAGING com
PK_VALIDATE.
FLG_MIGRATION igual a N. Se a FLG_STATUS
F_VALIDATE_CC_STAGING
for igual a Y ou M ento a tabela da STAGING
actualizada para FLG_MIGRATION = Y, caso
contrrio actualizada para E.
Identifica todos os registos das tabelas da STAGING
com FLG_MIGRATION = N e para cada registo
valida se aquela informao j existe na tabela de
mapeamento com FLG_STATUS = Y ou M. Se

PK_VALIDATE. existir, ento actualiza a tabela correspondente no

F_VALIDATE_CO_STAGING schema STAGING com FLG_MIGRATION = Y.

Caso contrrio, se no existe na tabela de mapeamento
pode ou no ser erro. Se for erro, ento a
FLG_MIGRATION fica igual a E, caso contrrio fica
igual a N.
Como o ODI no permite utilizar campos do tipo
BLOB, foi necessrio criar esta funo auxiliar para
permitir a migrao das fotos referente rea dos
PK_MIGRA_MODEL_ERROR. profissionais e dos pacientes.
F_INSERT_ALERT_LOB_INDIV Esta funo vai correr todos os registos da tabela de
mapeamento para ir buscar as fotos que esto no schema

MIGRA (MAP NEW) e migrar para o ALERT .
Esta funo tem como objectivo chamar uma API do
PRC_MIGRA_F_API_ALERT_SET_DATA_GOV
ALERT , relacionada com as tabelas de acesso rpido.

Tabela 15- Funes referentes ao progresso da MAP NEW/ALERT

Com o intuito de agilizar o processo de migrao, so gerados cenrios a partir dos packages
definidos no ODI. Pela utilizao destes cenrios possvel exportar do ambiente de desenvolvimento
e incorporar no cliente apenas um objecto que contm o conjunto de todos os outros cenrios
necessrios ao processo de migrao de dados. Para tornar este processo exequvel, foram
desenvolvidos trs tipos de cenrios:

2-
 /
!

1 - Um cenrio corresponde a uma cpia de cada package do ODI;

2 - Um cenrio corresponde juno dos cenrios referentes fase IV (STAGING- MAP
OLD), fase V (MAP OLD MAP NEW) e fase VI (MAP NEW - ALERT), exactamente por esta
ordem, como visvel na Figura 40;

Figura 40 - Progresso STAGING/MAP OLD/MAP NEW/ALERT

3 - Um cenrio que agrupa todos os outros cenrios descritos no ponto anterior, como
exemplifica a Figura 41.

Figura 41 - Progresso global

-,
 /
!

3,3,3 4 !&

Definir o processo de implementao da Data Migration Framework fundamental para que

seja possvel compreender quais as tarefas inerentes definio do ambiente de migrao de dados.
A preparao do ambiente de migrao obriga a certos requisitos, dos quais se destaca:
1 - Instalao do Oracle Data Integrator;
2 - Criao do repositrio mestre e de trabalho na base de dados;
3 - Instalao do repositrio mestre e de trabalho no Oracle Data Integrator;
4 - Configurao da topologia no Oracle Data Integrator, ou seja, da arquitectura lgica e fsica,
bem como do agente;
5 - Importao dos cenrios responsveis pelo processo de migrao;
6 - Importao dos ficheiros XML, com informao do cliente, para a rea intermdia;
7 - Definio de agendamentos, caso seja necessrio.
Para uma melhor exemplificao de todo este processo de implementao foi elaborado um
documento detalhado de todas as tarefas necessrias preparao do ambiente de migrao de dados.
Este documento encontra-se disponvel no Anexo A - Checklist de implementao.

3,3,5 - <

Para alm da Data Migration Framework, foi desenvolvida uma ferramenta web de
monitorizao, designada por Monitoring Framework, com o objectivo de validar o progresso da
migrao de dados e analisar qualquer anomalia que possa ocorrer durante a migrao de dados.
A ferramenta de monitorizao, disponvel no Anexo D Ferramenta de Monitorizao, foi
desenvolvida em PL/SQL, criando-se cinco packages a nvel de base de dados, cujo resultado visvel
em HTML, permitindo deste modo a monitorizao do processo de migrao, por qualquer pessoa,
sem que para isso seja necessrio conhecimento prvio em PL/SQL. A partir dos cinco packages
criados a nvel de base de dados foram elaboradas vrias queries ao repositrio mestre e de trabalho,
dado que nestes repositrios que se encontra armazenas todas as actividades que ocorrem a nvel do
Oracle Data Integrator. Alm destes dois repositrios, foram analisadas algumas tabelas de log
presentes noutros schemas, nomeadamente: MIGRA, MIG_LOG_STG e MIG_LOG_ALERT.
De seguida sero apresentadas todas as pginas web desenvolvidas na ferramenta de
monitorizao, bem como a informao que pode ser analisada em cada uma delas.
A primeira pgina diz respeito anlise do desempenho da migrao de dados ao nvel dos
objectos internos a cada package do ODI, ou seja, a informao referente s variveis utilizadas, aos
interfaces, s chamadas a procedimentos de base dados, entre outros. Nesta pgina possvel analisar

-0
 /
!

o tempo de execuo de cada uma das etapas definidas para cada objecto presente no package do ODI,
assim como quantos registos foram actualizados, inseridos ou eliminados em cada etapa.
A Figura 42 permite a visualizao da informao referente primeira pgina Web da
ferramenta de monitorizao.

Figura 42 Pgina 1 (Performance ODI-Package)

Para uma melhor compreenso da informao, existem quatro aspectos que na minha opinio
so importantes, nomeadamente:
Alternncia de tonalidade nas linhas pares e mpares da tabela;
Informao presente na tabela de forma agregada, permitindo visualizar pequenas
quantidades de registos de cada vez;
Utilizao de cores mais escuras na seleco de um registo especfico, com o intuito de
analisar apenas um parmetro em particular;
Informao no rodap da pgina com a informao necessria para entrar em contacto com
algum que possa ajudar a compreender algum assunto relacionado com a migrao.
Uma outra rea que importante avaliar a performance no processo de migrao a informao
executada em cada knowledge module, principalmente o LKM e o IKM. A Figura 43 apresenta a
segunda pgina Web disponvel na ferramenta de monitorizao.

-+
 /
!

Figura 43 Pgina 2 (Performance ODI-KM)

A informao presente nesta rea encontra-se ordenada por ordem temporal decrescente, cujo
objectivo manter a tarefa mais recente sempre no topo da tabela, assim como identificar a ordem de
execuo das tarefas internas nos mdulos de conhecimento.
A terceira pgina Web da ferramenta de monitorizao, ilustrada na Figura 44, permite
identificar qualquer aco que tenha ocorrido durante o processo de migrao a nvel dos packages de
base de dados.
A informao que consta nesta tabela contm a mensagem de erro, a data e a tabela em que
ocorreu o erro, assim como uma varivel designada por v_result que no caso de ser igual a zero
significa que a tarefa processada deu erro e caso seja igual a um significa que a tarefa processada
terminou com sucesso. Nesta rea existe ainda a possibilidade de filtrar a informao da tabela por
data e hora de incio e fim. Caso no seja escolhido nenhum valor, nenhum filtro ser aplicado e toda a
informao ser apresentada.

-3
 /
!

Figura 44 Pgina 3 (Validate ODI-KM)

A quarta pgina Web da ferramenta de monitorizao, visvel na Figura 45, permite identificar a
data de incio e de fim do processo de migrao de dados, assim como todas as anomalias que possam
ter ocorrido, a nvel dos mdulos de conhecimento, durante esse perodo.
Nesta pgina tambm possvel pesquisar a informao presente na tabela por data e hora, assim
como identificar o nmero e a mensagem de erro Oracle, a tabela onde ocorreu o erro, assim como a
data em que ocorreu.

-4
 /
!

Figura 45 Pgina 4 (Validate DB-Package)

Dado que existe a possibilidade de ocorrer migraes diferenciais e considerar-se importante no

eliminar nenhuma informao entre migraes, esta pgina encontra-se estruturada do seguinte modo:
1 - Registo com a informao da data de incio da migrao de dados (status = I).
2 - Registos com a informao das anomalias ocorridas durante o processo de migrao.
3 - Registo com a informao da data de fim da migrao de dados (status = F).
Os registos com status igual a E correspondem s anomalias que ocorreram durante o processo
de migrao de dados.
A Figura 46 representa a quinta e ltima pgina Web da ferramenta de monitorizao da
migrao de dados. Nesta pgina encontra-se a informao de todas as anomalias, que ocorreram
durante a migrao de dados, independentemente do tipo de erro. Toda a informao visualizada nesta
ltima pgina web encontra-se organizada pela data de ocorrncia e a respectiva mensagem de erro.

-5
 /
!

Figura 46 Pgina 5 (Analyze all errors)

Com o objectivo de permitir identificar as funes de base dados utilizadas em cada pgina Web
da ferramenta de monitorizao, assim como a respectiva figura que a identifica, foi construda a
Tabela 16 que a seguir se apresenta.

FUNO PGINA WEB

Corresponde segunda pgina Web que se encontra

VALIDATE_DMF_V25032.Perf_ODI_KM
ilustrada na Figura 47 - Performance ODI-KM.

Corresponde primeira pgina Web da ferramenta de

VALIDATE_DMF_V25032.Perf_ODI_Pkg monitorizao que est exemplificada na Figura 42 -
Performance ODI-Package.

VALIDATE_DMF_V25032.V_ODI_BD_Pkg

(dt_ini in VARCHAR2 default null, Corresponde quarta pgina Web que est ilustrada na

dt_end in VARCHAR2 default null, Figura 45 - Validate DB-Package.

submit String default null);

VALIDATE_DMF_V25032.V_ODI_KM Corresponde terceira pgina Web da ferramenta de

(dt_ini in VARCHAR2 default null, monitorizao que est ilustrada na Figura 44 - Validate

-6
 /
!

ODI-KM.
dt_end in VARCHAR2 default null,

submit String default null);

VALIDATE_DMF_V25032.V_LOG_TOTAL

(dt_ini in VARCHAR2 default null, Corresponde quinta pgina Web que est exemplificada na

dt_end in VARCHAR2 default null, Figura 46 - Analyze all errors.

submit String default null);

Tabela 16 - Funes de monitorizao

Em suma, esta ferramenta de monitorizao designada por Monitoring Framework permite

analisar, em detalhe, todas as tarefas intrnsecas ao processo de migrao de dados para o ALERT
utilizando a Data Migration Framework.

-1
 /
!

!* #& 5

' &

A elaborao da ferramenta de migrao de dados para o ALERT teve incio em Outubro de

2008 com a participao do Hospital de Bernhoven, na Holanda. Os primeiros testes do processo de
migrao de dados ocorreram em Agosto de 2009, num ambiente de pr-produo.
Neste captulo pretende-se, sobretudo, analisar os resultados obtidos nos testes realizados no
referido hospital, tendo em ateno o objectivo deste projecto.
Com efeito, os resultados que se apresentam nesta seco no so irrevogveis servindo apenas
como preparao para desenvolver um trabalho posterior, ou seja, a migrao de dados com
informao proveniente do Hospital de Bernhoven para o ALERT, num ambiente de produo.
Ao longo do desenvolvimento de todo o processo, foram realizados diversos testes que incidiram
sobre o processo de migrao de dados com recurso Data Migration Framework (DMF) e
Monitoring Framework (MF).

5,+ - #&

O processo de elaborao da DMF teve incio com uma prova de conceito realizada em Outubro
de 2008, referente migrao de dados da rea dos profissionais e pacientes, com informao
provenientes do Hospital de Bernhoven. Merc desta prova foi possvel melhorar o processo de
migrao a nvel de desempenho, definio da topologia do ODI e ao mesmo tempo testemunhar a

-2
 /
!

importncia do uso de uma rea intermdia na arquitectura da DMF que permite que esta fique
independente do sistema ALERT e das constantes alteraes que ocorrem nas verses do produto, de
modo a minimizar o impacto entre verses.
Os testes executados na Holanda, no ambiente de pr-produo, foram realizados recorrendo
extraco dos dados do sistema de origem atravs de ficheiros no formato XML, referente apenas a
algumas reas suportadas pelo ALERT, nomeadamente: informao referente a profissionais,
pacientes, visitas e episdios. A extraco dos dados em ficheiros XML para a rea intermdia revelou
ser um processo pouco invasivo no sistema de origem e independente do formato de base de dados do
cliente.
A relao entre a quantidade de informao a migrar, por reas, o tempo de execuo de cada
uma e o nmero de tabelas que vo ser carregadas no sistema de destino encontra-se descrita na
Tabela 17 que a seguir se apresenta.

TEMPO DE NMERO DE
NMERO DE
EXECUO TABELAS NO
REAS
REGISTOS
MIGRADAS (Horas) SISTEMA DE DESTINO

PROFISSIONAIS 4.141 0.05 (3 minutos) 19

PACIENTES 539.040 3 17

VISITAS 5.173.822 28 2

EPISDIOS 2.000.000 11 9

Tabela 17 - Resultados da migrao no Hospital de Bernhoven

Com base na anlise sumria da Tabela 17 possvel compreender o quanto esta ferramenta de
migrao pode ser vantajosa no que diz respeito ao tempo necessrio execuo do processo de
migrao de dados para o ALERT, uma vez que precisou, somente, de cerca de 42 horas para migrar
7.717.003 registos.
importante referir e comprovar pela observao da Tabela 17 que a migrao de dados no
realizada de uma tabela do sistema de origem para uma tabela do sistema de destino (relao 1-1), mas
sim de uma tabela do sistema de origem para vrias tabelas no sistema de destino (relao 1-N), o que
aumenta a complexidade de todo o processo de migrao, bem como o tempo necessrio para
processar a informao em cada rea.
Dado que a migrao de dados realizada no hospital de Bernhoven est pela primeira vez a ser
realizada a partir de variados sistemas fonte desconhecidos para o ALERT e tendo em considerao o
volume de informao a migrar, que em Portugal no ultrapassa em mdia os seiscentos mil episdios,
possvel confirmar que a DMF revelou-se uma ferramenta de sucesso.
--
 /
!

Contudo, no caminhar do processo foi observado um constrangimento que se prende com o

desenvolvimento da DMF que residiu no baixo conhecimento prtico inicial do ODI e que dificultou,
de algum modo, a adaptao dos mdulos de conhecimento para a rea intermdia estabelecida.
Todavia e apesar deste constrangimento a Data Migration Framework revelou-se uma
ferramenta de implementao simples e eficaz na realizao da migrao de dados para o ALERT,
com um tempo de processamento diminuto perante um grande volume de informao oriundo do
sistema fonte.
A Monitoring Framework permitiu uma anlise detalhada ao progresso da migrao de dados
para o ALERT, que se traduziu na observao de todas as actividades inerentes ao processo de
migrao e identificao de qualquer anomalia que possa ocorrer durante a migrao de dados. Deste
modo, possvel responder de forma atempada resoluo de qualquer erro que possa ocorrer durante
o processo de migrao.

0,,
 /
!

!* #& :

%&# ?

Reflectindo sobre todo o projecto desenvolvido concluiu-se que em contexto real a Data
Migration Framework aumenta a confiana no processo de migrao de dados para o ALERT,
adaptando-se a qualquer sistema fonte.
Com recurso utilizao da Monitoring Framework no processo de migrao de dados
possvel identificar, mais objectivamente, o tempo disponibilizado em cada tarefa, a quantidade de
informao migrada, assim como qualquer tipo de problema que possa ter ocorrido durante o processo
de migrao de dados para o ALERT.
Devido elevada confiana no processo de migrao que a Data Migration Framework revelou,
assim como a capacidade de gerar relatrios do resultado da migrao, atravs da Monitoring
Framework, resulta numa maior facilidade de aceitao mudana para o ALERT, por parte do
cliente, uma vez que se est a lidar com informao muito sensvel, ligada rea da sade, no
havendo margem para erros.
A arquitectura definida para a Data Migration Framework, dividida nas fases de extraco,
transformao e carregamento, revelou-se, no processo de migrao de dados, muito til e adequada
pelas razes a seguir expostas:
A fase de extraco dos dados dos sistemas fonte, recorrendo a ficheiros XML, possibilita
uma maior simplicidade nas tarefas a serem realizadas por parte do cliente. Com recurso a ficheiros
XML, deixa de ser necessrio um profundo conhecimento do sistema fonte e possvel validar o
respectivo ficheiro recorrendo a ficheiros no formato XSD.
A fase de transformao, definida por uma rea intermdia, independente dos sistemas de
origem e de destino, constituda pelos schemas STAGING e MIGRA. O schema STAGING
representa a plataforma de integrao dos dados a migrar para o ALERT, de acordo com as regras

0,0
 /
!

estipuladas pelo prprio. Devido a esta independncia, a DMF no necessita ser alterada sempre que
ocorra um upgrade ao produto ALERT. O schema MIGRA possibilita transformar os dados que se
encontravam no sistema fonte para irem de encontro estrutura do sistema ALERT. Este schema
permite garantir que a informao proveniente do sistema de origem no se perde durante o processo
de migrao de dados para o ALERT, dado que toda a informao dos sistemas de origem e destino
se encontram mapeados. Caso algum erro seja identificado no ALERT, possvel identificar e
garantir se esse erro surgiu com o processo de migrao ou se j se encontrava assim no sistema de
origem. de realar que o recurso a uma rea intermdia na arquitectura da DMF permite no s
migrar de diversos sistemas fonte desconhecidos para o ALERT, mas tambm de outros sistemas
ALERT para o ALERT.
A fase de carregamento pode ser definida como o processo de exportao dos dados da rea
intermdia (schema MIGRA MAP NEW) para o ALERT.
O correcto funcionamento do sistema aplicacional ALERT foi mantido e toda a informao
migrada encontra-se correctamente disponvel no sistema de destino.
Embora a ferramenta de migrao desenvolvida se tenha revelado um sucesso no teste realizado
no Hospital de Bernhoven, na Holanda, necessrio sublinhar que, actualmente, a Data Migration
Framework encontra-se em fase de desenvolvimento, uma vez que ainda no foram desenvolvidas
todas as reas suportadas pelo ALERT, nomeadamente, a rea referente informao correspondente
aos meios complementares de diagnstico e teraputico, a rea referente informao da alta da
instituio hospitalar, a rea referente informao de documentos dos profissionais e pacientes, entre
outros.
Para se obter um maior e melhor sucesso da aplicao desta ferramenta de migrao de dados
igualmente necessrio desenvolver outros mdulos, no sentido de permitir que a Data Migration
Framework consiga receber informao do sistema fonte, no s no formato XML, mas tambm
recorrendo a Flat Files ou a DBLinks.
Aps a realizao dos testes verificou-se, a possibilidade de um novo desenvolvimento na Data
Migration Framework, que passaria por utilizar uma API (Application Programming Interface) na
fase de carregamento da informao dos diversos sistemas fonte para a rea intermdia, com o intuito
de facilitar a execuo das tarefas, desta fase, por parte do cliente.
Considera-se, assim, que a Data Migration Framework e a Monitoring Framework representam
um passo importante na caminhada da internacionalizao da empresa ALERT.

0,+
 /
!

) 0 %

[1] Casos de sucesso da suite de produtos ALERT. [Acedido a 03 de Agosto de 2009].

Disponvel em http://www.alert-online.com/?msg=online&idLang=1

[2] Extensible Markup Language (XML). [Acedido a 31 de Julho de 2009]. Disponvel em

http://www.w3.org/XML/

[3] PMI Standards Committee; WILLIAM, Duncan A Guide to the Project Management Body
of Knowledge (PMBOK Guide) Fourth Edition. Project Management Institute, 2008.

[4] SUELEN, Mendona O papel estratgico dos projectos de migrao de dados. IN IT

Web, 2009 [Acedido a 07 de Maro de 2009]. Disponvel na Internet:
http://www.itweb.com.br/voce_informa/interna.asp?cod=4294.

[5] VANDER, Emiro ETL: Quais as ferramentas mais poderosas do mercado? [Acedido a
18 de Janeiro de 2009]. Disponvel na Internet:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=6727.

0,3
 /
!

@ $& )

Celona Software desenvolvido para Migrao de dados [Acedido a 01 de Agosto de 2009].

Disponvel na Internet: http://www.celona.com/about-celona.

CHRISTOPHER, B.; DAVID, M. How to plan for data migration. IN Computerworld,

2004 [Acedido a 01 de Agosto de 2009]. Disponvel na Internet:
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=93284

Dicionrio Priberam da Lngua Portuguesa. Priberam Informtica, S.A., 2009 [Acedido a

10 de Janeiro de 2009]. Disponvel na Internet: http://www.priberam.pt/DLPO/.

JOHN, Morris Practical Data Migration. BCS, 2006.

KeepSolutions Software desenvolvido para Migrao de dados [Acedido a 17 de Junho de

2009]. Disponvel na Internet: http://www.keep.pt/node/36.

MCBURNEY, Vincent So what is better, ETL or ELT?, 2006 [Acedido a 17 de Junho de

2009]. Disponvel na Internet: http://it.toolbox.com/blogs/infosphere/so-what-is-better-etl-or-elt-
13572

Microsoft CRM Data Migration Framework Ferramenta de Migrao de dados [Acedido a

17 de Junho de 2009]. Disponvel na Internet: http://www.sonomapartners.com/articles/data-
migration-framework.aspx.

Migraes para bases de dados open source. [Acedido a 17 de Junho de 2009]. Disponvel
na Internet:
http://www.dri.pt/pt/servicos_open_source/sistemas_open_source/migracao_bases_dados.html.

0,4
 /
!

Moving Global Electronics Data using Sunopsis, 2006 [Acedido a 11 de Janeiro de 2009].
Disponvel na Internet: http://www.rittmanmead.com/2006/11/30/moving-global-electronics-data-
using-sunopsis/.

National Tuberculosis Controllers Association. Data Migration [Acedido a 27 de Maio de

2009]. Disponvel na Internet: http://www.infotechnet.org/ntca/DataMigration.htm.

Oracle Data Integrator Getting Started with an ETL Project. Oracle, 2007 [Acedido a 09
de Dezembro de 2009]. Disponvel na Internet: http://www.oracle.com/technology/products/
oracledataintegrator/10.1.3/htdocs/documentation/oracledi_getting_started.pdf.

Oracle Data Integrator Installation Guide. Oracle Corporation, 2008 [Acedido a 19 de

Janeiro de 2009]. Disponvel na Internet: http://www.oracle.com/technology/products/oracle-data-
integrator/10.1.3/htdocs/documentation/oracledi_setup.pdf

Oracle Data Integrator Users Guide. Oracle, 2007 [Acedido a 09 de Dezembro de 2009].
Disponvel na Internet: http://www.oracle.com/technology/products/oracledataintegrator/10.1.3/
htdocs/documentation/oracledi_users.pdf.

PEREIRA, Alexandre; POUPA, Carlos Como escrever uma tese monografia ou livro
cientfico usando o Word. 3 ed. Lisboa: Edies Slabo, 2006.

Regras para a Apresentao de Dissertaes de Cursos de Mestrado da FEUP. Porto:

Faculdade de Economia da Universidade do Porto, 2009 [Acedido a 06 de Janeiro de 2009].
Disponvel na Internet: http://paginas.fe.up.pt/~gtd/mgi/regrasformais.html.

Sunopsis Data Conductor : Creating an Oracle Project. Oracle, 2006 [Acedido a 24 de

Junho de 2009]. Disponvel na Internet: http://www.rittmanmead.com/2006/11/16/sunopsis-data-
conductor-creating-an-oracle-project/.

Symantec Ferramenta de Migrao de dados [Acedido a 17 de Junho de 2009]. Disponvel

na Internet:
http://www.symantec.com/pt/br/business/services/overview.jsp?pcid=consulting_services&pvid=data
_migration.

0,5
 /
!

The essential online community resource for the data migration profession. Comunidade
online para profissionais responsveis por realizarem Migraes de dados [Acedido a 13 de Novembro
de 2008]. Disponvel na Internet: http://www.datamigrationpro.com/data-migration-news-journal/.

WANG, Richard; ZIAD, Mostapha & LEE, Yang Data Quality. Kluwer Academic
Publishers [Acedido a 13 de Novembro de 2008]. Disponvel na Internet:
http://books.google.pt/books?id=A_TxcokcIA8C&printsec=frontcover&source=gbs_v2_summary_r&
cad=0.

What is Data Migration? Conjecture Corporation [Acedido a 13 de Novembro de 2008].

Disponvel na Internet: http://www.wisegeek.com/what-is-data-migration.htm.

0,6
 /
!

0,1
 /
!

= 4 !&

0,2
 /
!

0,-
 /
!

00,
 /
!

000
 /
!

00+
 /
!

003
 /
!

= @ - $ &

004
 /
!

005
 /
!

= - $ &

006
 /
!

001
 /
!

002
 /
!

= - <

00-
 /
!

create or replace package VALIDATE_DMF_V25032 is

-- Author : MICAELA
-- Created : 19-07-2009 00:45:09
-- Purpose : Validate data migrations
-- Public function and procedure declarations
PROCEDURE Perf_ODI_KM;
PROCEDURE Perf_ODI_Pkg;
PROCEDURE V_ODI_BD_Pkg(dt_ini in VARCHAR2 default null,
dt_end in VARCHAR2 default null,
submit String default null);
PROCEDURE V_ODI_KM(dt_ini in VARCHAR2 default null,
dt_end in VARCHAR2 default null,
submit String default null);
PROCEDURE V_LOG_TOTAL(dt_ini in VARCHAR2 default null,
dt_end in VARCHAR2 default null,
submit String default null);
end VALIDATE_DMF_V25032;
/

create or replace package body VALIDATE_DMF_V25032 is

PROCEDURE Perf_ODI_KM IS
var_result VARCHAR2(4000);
lvc2_error_title error.title%TYPE := NULL;
lvc2_error_origin error.origin%TYPE := NULL;
lvc2_error_desc error.description%TYPE := NULL;
lvc2_level error.err_level%TYPE := NULL;

CURSOR get_data IS
SELECT sstl.sess_no,
sstl.nno,
sstl.scen_task_no,
sst.task_name1 as task_name,
sst.task_type as task_type,
sst.task_name2 as task_PKG,
sst.ord_trt as id_task_KM,
sst.task_name3 as task_KM,
sst.ind_log_nb as type_task_KM,
sst.def_lschema_name as LKM_schema,
sstl.task_beg,
sstl.task_end,
to_char(trunc(sysdate) + (((sstl.task_dur / 60) / 60) / 24),
'hh24:mi:ss') as duracao,
sstl.task_status,
sstl.nb_ins,
sstl.nb_upd,
sstl.nb_del,
sstl.nb_err
from MIGRA_WORK.snp_sess_task_log sstl,
MIGRA_WORK.snp_sess_task sst
where sstl.sess_no = sst.sess_no
and sstl.nno = sst.nno
and sstl.scen_task_no = sst.scen_task_no
order by sstl.sess_no, scen_task_no;

BEGIN
lvc2_error_origin := 'Perf_ODI_KM';

htp.p('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
htp.p('<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">');
htp.p('<head>');
htp.p('<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />');
htp.p('<title>Performance ODI-Package</title>');
htp.p('<script type="text/javascript" src="js/paginate.js"></script>');
htp.p('<link href="css/tablecloth.css" rel="stylesheet" type="text/css"
media="screen" />');
htp.p('<script type="text/javascript" src="js/tablecloth.js"></script>');

0+,
 /
!

htp.p('<link rel="stylesheet" href="css/style.css" type="text/css"

media="screen" />');
htp.p('</head>');
htp.p('<body>');
htp.p('<div>');
htp.p('<div id="container">');
htp.p(' <div id="header">');
htp.img('/Migration/images/logo.jpg');
htp.p(' </div>');
htp.p(' <div>');
htp.p(' <ul id="menu">');
htp.p(' <li class="trans">a</li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_Pkg" title="">Performance ODI-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_KM" title="" class="current">Performance
ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-mig/migra_25/VALIDATE_DMF_V25032.v_odi_km"
title="">Validate ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_ODI_BD_Pkg" title="">Validate DB-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_LOG_TOTAL" title="">Validate Total
Logs</a></li>');
htp.p(' </ul>');
htp.p(' </div>');
htp.p(' </div>');
htp.p(' <div id="content">');
htp.p(' <h1>Performance ODI-KM</h1>');
htp.p(' <p>As Oracle Data Integrator loads and transforms data from many
different database platforms and uses message-based technologies such as Web
services while being able to respond to events, the technology used to access and
load these different datasources needs to be flexible, extensible, and yet
efficient.');
htp.p(' <p>Oracle Data Integrator solves this situation through the use of
knowledge modules that are simply "plug-ins" to Oracle Data Integrator that
encapsulate a best practice in loading, transforming, or integrating data for a
specific datasource or target.');
htp.p(' <br/>');
htp.p(' <p>In this area we will be able to analyze the progress of the Data
Migration at the KM level.');
htp.p('<div id="dataTable">');
htp.p('<table cellspacing="0" cellpadding="0" class="paginate-10 max-pages-
7">');
htp.p(' <tr>');
htp.p(' <th >SESS_NO</th>');
htp.p(' <th >NNO</th>');
htp.p(' <th >SCEN_TASK_NO</th>');
htp.p(' <th >TASK_NAME</th>');
htp.p(' <th >TASK_TYPE</th>');
htp.p(' <th >TASK_PKG</th>');
htp.p(' <th >ID_TASK_KM</th>');
htp.p(' <th >TASK_KM</th>');
htp.p(' <th >TYPE_TASK_KM</th>');
htp.p(' <th >LKM_SCHEMA</th>');
htp.p(' <th >TASK_BEG</th>');
htp.p(' <th >TASK_END</th>');
htp.p(' <th >DURACAO</th>');
htp.p(' <th >TASK_STATUS</th>');
htp.p(' <th >NB_INS</th>');
htp.p(' <th >NB_UPD</th>');
htp.p(' <th >NB_DEL</th>');
htp.p(' <th >NB_ERR</th>');
htp.p(' </tr>');

FOR i IN get_data LOOP

0+0
 /
!

htp.p('<tr>');
htp.p(' <td>' || i.SESS_NO || '</td>');
htp.p(' <td>' || i.NNO || '</td>');
htp.p(' <td>' || i.SCEN_TASK_NO || '</td>');
htp.p(' <td>' || i.TASK_NAME || '</td>');
htp.p(' <td>' || i.TASK_TYPE || '</td>');
htp.p(' <td>' || i.TASK_PKG || '</td>');
htp.p(' <td>' || i.ID_TASK_KM || '</td>');
htp.p(' <td>' || i.TASK_KM || '</td>');
htp.p(' <td>' || i.TYPE_TASK_KM || '</td>');
htp.p(' <td>' || i.LKM_SCHEMA || '</td>');
htp.p(' <td>' || to_char(i.TASK_BEG, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || to_char(i.TASK_END, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || i.DURACAO || '</td>');
htp.p(' <td>' || i.TASK_STATUS || '</td>');
htp.p(' <td>' || i.NB_INS || '</td>');
htp.p(' <td>' || i.NB_UPD || '</td>');
htp.p(' <td>' || i.NB_DEL || '</td>');
htp.p(' <td>' || i.NB_ERR || '</td>');
htp.p('</tr>');
END LOOP;

htp.p(' </table>');
htp.p(' </div>');
htp.p(' <div id="footer">In need of assistance please contact the <a
href="mailto:micaela.lima@alert.pt">migration team</a>. </div>');
htp.p('</div>');
htp.p('</div>');
htp.p('</body>');
htp.p('</html>');

EXCEPTION
WHEN OTHERS THEN
var_result := 'Resultado com erro: ' || SQLCODE || ' -ERROR- ' ||
SQLERRM;
lvc2_error_title := var_result;
lvc2_level := 'ERR';
lvc2_error_desc := lvc2_error_origin || '-' || lvc2_error_title;
pk_ia_util.insert_error(lvc2_error_origin,
lvc2_error_title,
SQLERRM,
lvc2_error_desc,
lvc2_level);
END Perf_ODI_KM;

PROCEDURE Perf_ODI_Pkg IS
var_result VARCHAR2(4000);
lvc2_error_title error.title%TYPE := NULL;
lvc2_error_origin error.origin%TYPE := NULL;
lvc2_error_desc error.description%TYPE := NULL;
lvc2_level error.err_level%TYPE := NULL;

CURSOR get_data IS
SELECT ss.sess_no as numero,
ss.sess_name as package_name,
ss.scen_version as version,
sss.nno as step_order,
sss.step_name as int_step_name,
sss.step_type as int_step_type,
sss.var_name,
sss.var_value,
to_char(trunc(sysdate) + (((ss.sess_dur / 60) / 60) /
24),'hh24:mi:ss') as duracao,
ss.sess_beg as dt_ini,
ss.sess_end as dt_end,

0++
 /
!

ss.sess_status as status,
ss.sess_rc as code_error,
ssl.nb_err as n_errors,
ssl.nb_ins as n_inserts,
ssl.nb_upd as n_updates,
ssl.nb_del as n_deletes
from migra_work.snp_session ss,
migra_work.snp_step_log ssl,
migra_work.snp_sess_step sss
where ss.sess_no = ssl.sess_no
and ss.sess_no = sss.sess_no
AND SSL.NNO = SSS.NNO
order by ss.sess_no, ss.sess_name, ss.scen_version, sss.nno;

BEGIN
lvc2_error_origin := 'Perf_ODI_Pkg';
htp.p('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
htp.p('<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">');
htp.p('<head>');
htp.p('<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />');
htp.p('<title>Performance ODI-Package</title>');
htp.p('<script type="text/javascript" src="js/paginate.js"></script>');
htp.p('<link href="css/tablecloth.css" rel="stylesheet" type="text/css"
media="screen" />');
htp.p('<script type="text/javascript" src="js/tablecloth.js"></script>');
htp.p('<link rel="stylesheet" href="css/style.css" type="text/css"
media="screen" />');
htp.p('</head>');
htp.p('<body>');
htp.p('<div>');
htp.p('<div id="container">');
htp.p(' <div id="header">');
htp.p('<img src="/Migration/images/logo.jpg"/>');
htp.p(' </div>');
htp.p(' <div>');
htp.p(' <ul id="menu">');
htp.p(' <li class="trans">aa</li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_Pkg" title="" class="current">Performance
ODI-Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_KM" title="">Performance ODI-
KM</a></li>');
htp.p(' <li><a href="http://alert-mig/migra_25/VALIDATE_DMF_V25032.v_odi_km"
title="">Validate ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_ODI_BD_Pkg" title="">Validate DB-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_LOG_TOTAL" title="">Validate Total
Logs</a></li>');
htp.p(' </ul>');
htp.p(' </div>');
htp.p(' </div>');
htp.p(' <div id="content">');
htp.p(' <h1>Performance ODI-Package</h1>');
htp.p(' <p>To create and manage Oracle Data Integrator projects are used
four graphical modules. We will focus on the Designer module, that is used to
define data stores (tables, files, Web services, and so on), interfaces (data
mappings), and packages (sets of integration steps, including interfaces).');
htp.p(' <br/>');
htp.p(' <p>In this area its possible to analyze the performance of the Data
Migration Framework in a Package level.');
htp.p('<div id="dataTable">');
htp.p('<table cellspacing="0" cellpadding="0" class="paginate-10 max-pages-
7">');
htp.p(' <tr>');

0+3
 /
!

htp.p(' <th >NUMERO</th>');

htp.p(' <th >PACKAGE_NAME</th>');
htp.p(' <th >VERSION</th>');
htp.p(' <th >STEP_ORDER</th>');
htp.p(' <th >INT_STEP_NAME</th>');
htp.p(' <th >INT_STEP_TYPE</th>');
htp.p(' <th >VAR_NAME</th>');
htp.p(' <th >VAR_VALUE</th>');
htp.p(' <th >DURACAO</th>');
htp.p(' <th >DT_INI</th>');
htp.p(' <th >DT_END</th>');
htp.p(' <th >STATUS</th>');
htp.p(' <th >CODE_ERROR</th>');
htp.p(' <th >N_ERRORS</th>');
htp.p(' <th >N_INSERTS</th>');
htp.p(' <th >N_UPDATES</th>');
htp.p(' <th >N_DELETES</th>');
htp.p(' </tr>');

FOR i IN get_data LOOP

htp.p('<tr>');
htp.p(' <td>' || i.NUMERO || '</td>');
htp.p(' <td>' || i.PACKAGE_NAME || '</td>');
htp.p(' <td>' || i.VERSION || '</td>');
htp.p(' <td>' || i.STEP_ORDER || '</td>');
htp.p(' <td>' || i.INT_STEP_NAME || '</td>');
htp.p(' <td>' || i.INT_STEP_TYPE || '</td>');
htp.p(' <td>' || i.VAR_NAME || '</td>');
htp.p(' <td>' || i.VAR_VALUE || '</td>');
htp.p(' <td>' || i.DURACAO || '</td>');
htp.p(' <td>' || to_char(i.DT_INI, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || to_char(i.DT_END, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || i.STATUS || '</td>');
htp.p(' <td>' || i.CODE_ERROR || '</td>');
htp.p(' <td>' || i.N_ERRORS || '</td>');
htp.p(' <td>' || i.N_INSERTS || '</td>');
htp.p(' <td>' || i.N_UPDATES || '</td>');
htp.p(' <td>' || i.N_DELETES || '</td>');
htp.p('</tr>');
END LOOP;

htp.p(' </table>');
htp.p(' </div>');
htp.p('<div id="footer">In need of assistance please contact the <a
href="mailto:micaela.lima@alert.pt">migration team</a>. </div>');
htp.p('</div>');
htp.p('</div>');
htp.p('</body>');
htp.p('</html>');

EXCEPTION
WHEN OTHERS THEN
var_result := 'Resultado com erro: ' || SQLCODE || ' -ERROR- ' ||
SQLERRM;
lvc2_error_title := var_result;
lvc2_level := 'ERR';
lvc2_error_desc := lvc2_error_origin || '-' || lvc2_error_title;
pk_ia_util.insert_error(lvc2_error_origin,
lvc2_error_title,
SQLERRM,
lvc2_error_desc,
lvc2_level);
END Perf_ODI_Pkg;

0+4
 /
!

PROCEDURE V_ODI_BD_Pkg(dt_ini in VARCHAR2 default null,

dt_end in VARCHAR2 default null,
submit String default null) IS
var_result VARCHAR2(4000);
lvc2_error_title error.title%TYPE := NULL;
lvc2_error_origin error.origin%TYPE := NULL;
lvc2_error_desc error.description%TYPE := NULL;
lvc2_level error.err_level%TYPE := NULL;

CURSOR get_data IS
SELECT ID,
TABLE_NAME,
TABLE_NAME_ROWID,
ORA_ERR_ROWID,
ORA_ERR_NUM,
ORA_ERR_MSG,
ORA_ERR_OPTYPE,
ORA_ERR_TAG,
STATUS,
DT_BEGIN,
DT_END
FROM mig_control_error
order BY ID, TABLE_NAME;

CURSOR get_some_data IS
SELECT ID,
TABLE_NAME,
TABLE_NAME_ROWID,
ORA_ERR_ROWID,
ORA_ERR_NUM,
ORA_ERR_MSG,
ORA_ERR_OPTYPE,
ORA_ERR_TAG,
STATUS,
DT_BEGIN,
DT_END
FROM mig_control_error
where (DT_BEGIN >= to_date(dt_ini, 'dd-mm-yyyy hh24:mi:ss') or
DT_BEGIN is null)
and (DT_END <= to_date(dt_end, 'dd-mm-yyyy hh24:mi:ss') or
DT_END is null)
order BY ID, TABLE_NAME;

BEGIN
lvc2_error_origin := 'V_ODI_BD_Pkg';

htp.p('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
htp.p('<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">');
htp.p('<head>');
htp.p('<meta name="generator" content="HTML Tidy for Windows (vers 22 March
2008), see www.w3.org" />');
htp.p('<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"
/>');
htp.p('<title>Performance ODI-Package</title>');
htp.p('<script type="text/javascript" src="js/paginate.js"></script>');
htp.p('<link href="css/tablecloth.css" rel="stylesheet" type="text/css"
media="screen" />');
htp.p('<script type="text/javascript" src="js/tablecloth.js"></script>');
htp.p('<script type="text/javascript"
src="js/datetimepicker_css.js"></script>');
htp.p('<link rel="stylesheet" href="css/style.css" type="text/css"
media="screen" />');
htp.p('</head>');
htp.p('<body>');
htp.p('<div>');
htp.p('<div id="container">');
htp.p(' <div id="header">');

0+5
 /
!

htp.img('/Migration/images/logo.jpg');
htp.p(' </div>');
htp.p(' <div>');
htp.p(' <ul id="menu">');
htp.p(' <li class="trans">a</li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_Pkg" title="">Performance ODI-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_KM" title="">Performance ODI-
KM</a></li>');
htp.p(' <li><a href="http://alert-mig/migra_25/VALIDATE_DMF_V25032.v_odi_km"
title="">Validate ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_ODI_BD_Pkg" title="" class="current">Validate
DB-Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_LOG_TOTAL" title="">Validate Total
Logs</a></li>');
htp.p(' </ul>');
htp.p(' </div>');
htp.p(' </div>');
htp.p(' <div id="content">');
htp.p('<h1>Validate DB-Package</h1>');
htp.p('<p>');
htp.p('It''s also possible to validate the Data Migration at a Database
level.');
htp.p('In this are we will analyze te result of the Data Migration with the
possibilite to filter the data according to a start date/time and an end
date/time.');
htp.p('</p>');
htp.p('<h2>Search</h2>');
htp.p('<form action="VALIDATE_DMF_V25032.v_odi_bd_pkg" method="post">');
htp.p('Start Date/Time: <input type="text" name="dt_ini" id="startDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''startDate'',''ddmmyyyy'',''arrow'',true,24,false)"><im
g src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('End Date/Time: <input type="text" name="dt_end" id="endDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''endDate'',''ddmmyyyy'',''arrow'',true,24,false)"><img
src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('<input name="submit" type="submit" value="Search class="but"" />');
htp.p('</form>');
htp.p('<div id="dataTable">');
htp.p('<table cellspacing="0" cellpadding="0" class="paginate-10 max-pages-
7">');
htp.p(' <tr>');
htp.p(' <th >ID</th>');
htp.p(' <th >TABLE_NAME</th>');
htp.p(' <th >TABLE_NAME_ROWID</th>');
htp.p(' <th >ORA_ERR_ROWID</th>');
htp.p(' <th >ORA_ERR_NUM</th>');
htp.p(' <th >ORA_ERR_MSG</th>');
htp.p(' <th >ORA_ERR_OPTYPE</th>');
htp.p(' <th >ORA_ERR_TAG</th>');
htp.p(' <th >STATUS</th>');
htp.p(' <th >DT_BEGIN</th>');
htp.p(' <th >DT_END</th>');
htp.p(' </tr>');

if submit = 'Search' and (dt_ini IS NOT NULL or dt_end IS NOT NULL) then
FOR i IN get_some_data LOOP
htp.p('<tr>');
htp.p(' <td>' || i.ID || '</td>');
htp.p(' <td>' || i.TABLE_NAME || '</td>');
htp.p(' <td>' || i.TABLE_NAME_ROWID || '</td>');

0+6
 /
!

htp.p(' <td>' || i.ORA_ERR_ROWID || '</td>');

htp.p(' <td>' || i.ORA_ERR_NUM || '</td>');
htp.p(' <td>' || i.ORA_ERR_MSG || '</td>');
htp.p(' <td>' || i.ORA_ERR_OPTYPE || '</td>');
htp.p(' <td>' || i.ORA_ERR_TAG || '</td>');
htp.p(' <td>' || i.STATUS || '</td>');
htp.p(' <td>' || to_char(i.DT_BEGIN, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || to_char(i.DT_END, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p('</tr>');
END LOOP;
elsif dt_ini IS NULL and dt_end IS NULL then
FOR i IN get_data LOOP
htp.p('<tr>');
htp.p(' <td>' || i.ID || '</td>');
htp.p(' <td>' || i.TABLE_NAME || '</td>');
htp.p(' <td>' || i.TABLE_NAME_ROWID || '</td>');
htp.p(' <td>' || i.ORA_ERR_ROWID || '</td>');
htp.p(' <td>' || i.ORA_ERR_NUM || '</td>');
htp.p(' <td>' || i.ORA_ERR_MSG || '</td>');
htp.p(' <td>' || i.ORA_ERR_OPTYPE || '</td>');
htp.p(' <td>' || i.ORA_ERR_TAG || '</td>');
htp.p(' <td>' || i.STATUS || '</td>');
htp.p(' <td>' || to_char(i.DT_BEGIN, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || to_char(i.DT_END, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p('</tr>');
END LOOP;
end if;

htp.p(' </table>');
htp.p(' </div>');
htp.p('<div id="footer">In need of assistance please contact the <a
href="mailto:micaela.lima@alert.pt">migration team</a>. </div>');
htp.p('</div>');
htp.p('</div>');
htp.p('</body>');
htp.p('</html>');

EXCEPTION
WHEN OTHERS THEN
var_result := 'Resultado com erro: ' || SQLCODE || ' -ERROR- ' ||
SQLERRM;
lvc2_error_title := var_result;
lvc2_level := 'ERR';
lvc2_error_desc := lvc2_error_origin || '-' || lvc2_error_title;
pk_ia_util.insert_error(lvc2_error_origin,
lvc2_error_title,
SQLERRM,
lvc2_error_desc,
lvc2_level);
END V_ODI_BD_Pkg;

PROCEDURE V_ODI_KM(dt_ini in VARCHAR2 default null,

dt_end in VARCHAR2 default null,
submit String default null) IS
var_result VARCHAR2(4000);
lvc2_error_title error.title%TYPE := NULL;
lvc2_error_origin error.origin%TYPE := NULL;
lvc2_error_desc error.description%TYPE := NULL;
lvc2_level error.err_level%TYPE := NULL;

CURSOR get_data IS
SELECT ID, O_RESULT, V_RESULT, DATA, TABLE_NAME
FROM LOG_MIGRA
order BY DATA DESC;

0+1
 /
!

CURSOR get_some_data IS
SELECT ID, O_RESULT, V_RESULT, DATA, TABLE_NAME
FROM LOG_MIGRA
where (DATA >= to_date(dt_ini, 'dd-mm-yyyy hh24:mi:ss') or
dt_ini is null)
and (DATA <= to_date(dt_end, 'dd-mm-yyyy hh24:mi:ss') or
dt_end is null)
order BY DATA DESC;

BEGIN
lvc2_error_origin := 'V_ODI_KM';

htp.p('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
htp.p('<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">');
htp.p('<head>');
htp.p('<meta name="generator" content="HTML Tidy for Windows (vers 22 March
2008), see www.w3.org" />');
htp.p('<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"
/>');
htp.p('<title>Performance ODI-Package</title>');
htp.p('<script type="text/javascript" src="js/paginate.js"></script>');
htp.p('<link href="css/tablecloth.css" rel="stylesheet" type="text/css"
media="screen" />');
htp.p('<script type="text/javascript" src="js/tablecloth.js"></script>');
htp.p('<script type="text/javascript"
src="js/datetimepicker_css.js"></script>');
htp.p('<link rel="stylesheet" href="css/style.css" type="text/css"
media="screen" />');

htp.p('</head>');
htp.p('<body>');
htp.p('<div>');
htp.p('<div id="container">');
htp.p(' <div id="header">');
htp.img('/Migration/images/logo.jpg');
htp.p(' </div>');
htp.p(' <div>');
htp.p(' <ul id="menu">');
htp.p(' <li class="trans">a</li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_Pkg" title="">Performance ODI-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_KM" title="">Performance ODI-
KM</a></li>');
htp.p(' <li><a href="http://alert-mig/migra_25/VALIDATE_DMF_V25032.v_odi_km"
title="" class="current">Validate ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_ODI_BD_Pkg" title="">Validate DB-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_LOG_TOTAL" title="">Validate Total
Logs</a></li>');
htp.p(' </ul>');
htp.p(' </div>');
htp.p(' </div>');
htp.p(' <div id="content">');

htp.p('<h1>Validate ODI-KM</h1>');
htp.p('<p>');

htp.p('Oracle Data Integrator (ODI) includes Knowledge Modules (KMs) that are
components, which contain the information for ODI to perform a specific set of
tasks against a specific technology.');
htp.p('There are 6 different types of KMs, but in this area we will only
validate in detail the tasks in 2 different types:');

0+2
 /
!

htp.p('<br/>');
htp.p(' LKM (Loading Knowledge Modules) are used to extract data from the
source database tables and other systems (files, middleware, mainframe, etc.).');
htp.p('<br/>');
htp.p(' IKM (Integration Knowledge Modules) are used to integrate (load) data
to the target tables.');
htp.p('</p>');
htp.p('<h2>Search</h2>');
htp.p('<form action="VALIDATE_DMF_V25032.v_odi_km" method="post">');
htp.p('Start Date/Time: <input type="text" name="dt_ini" id="startDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''startDate'',''ddmmyyyy'',''arrow'',true,24,false)"><im
g src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('End Date/Time: <input type="text" name="dt_end" id="endDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''endDate'',''ddmmyyyy'',''arrow'',true,24,false)"><img
src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('<input name="submit" type="submit" value="Search" class="but"/>');
htp.p('</form>');
htp.p('<div id="dataTable">');
htp.p('<table cellspacing="0" cellpadding="0" class="paginate-10 max-pages-
7">');
htp.p(' <tr>');
htp.p(' <th >ID</th>');
htp.p(' <th >O_RESULT</th>');
htp.p(' <th >V_RESUL</th>');
htp.p(' <th >DATA</th>');
htp.p(' <th >TABLE_NAME</th>');
htp.p(' </tr>');

if submit = 'Search' and (dt_ini IS NOT NULL or dt_end IS NOT NULL) then
FOR i IN get_some_data LOOP
htp.p('<tr>');
htp.p(' <td>' || i.ID || '</td>');
htp.p(' <td>' || i.O_RESULT || '</td>');
htp.p(' <td>' || i.V_RESULT || '</td>');
htp.p(' <td>' || to_char(i.data, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || i.TABLE_NAME || '</td>');
htp.p('</tr>');
END LOOP;
elsif dt_ini IS NULL and dt_end IS NULL then
FOR i IN get_data LOOP
htp.p('<tr>');
htp.p(' <td>' || i.ID || '</td>');
htp.p(' <td>' || i.O_RESULT || '</td>');
htp.p(' <td>' || i.V_RESULT || '</td>');
htp.p(' <td>' || to_char(i.data, 'dd-mm-yyyy hh24:mi:ss') ||
'</td>');
htp.p(' <td>' || i.TABLE_NAME || '</td>');
htp.p('</tr>');
END LOOP;
end if;

htp.p(' </table>');
htp.p(' </div>');
htp.p('<div id="footer">In need of assistance please contact the <a
href="mailto:micaela.lima@alert.pt">migration team</a>. </div>');
htp.p('</div>');
htp.p('</div>');
htp.p('</body>');
htp.p('</html>');

EXCEPTION
WHEN OTHERS THEN
var_result := 'Resultado com erro: ' || SQLCODE || ' -ERROR- ' ||

0+-
 /
!

SQLERRM;
lvc2_error_title := var_result;
lvc2_level := 'ERR';
lvc2_error_desc := lvc2_error_origin || '-' || lvc2_error_title;
pk_ia_util.insert_error(lvc2_error_origin,
lvc2_error_title,
SQLERRM,
lvc2_error_desc,
lvc2_level);
END V_ODI_KM;

PROCEDURE V_LOG_TOTAL(dt_ini in VARCHAR2 default null,

dt_end in VARCHAR2 default null,
submit String default null) IS
var_result VARCHAR2(4000);
lvc2_error_title error.title%TYPE := NULL;
lvc2_error_origin error.origin%TYPE := NULL;
lvc2_error_desc error.description%TYPE := NULL;
lvc2_level error.err_level%TYPE := NULL;

CURSOR get_data IS
SELECT LTE_ID,
LTE_ERROR_TYPE,
LTE_ERROR_NUM,
LTE_ERROR_DESC,
LTE_DT_CREATION
FROM LOG_TOTAL_ERROR
order BY LTE_DT_CREATION DESC;

CURSOR get_some_data IS
SELECT LTE_ID,
LTE_ERROR_TYPE,
LTE_ERROR_NUM,
LTE_ERROR_DESC,
LTE_DT_CREATION
FROM LOG_TOTAL_ERROR
where (LTE_DT_CREATION >= to_date(dt_ini, 'dd-mm-yyyy hh24:mi:ss') or
dt_ini is null)
and (LTE_DT_CREATION <= to_date(dt_end, 'dd-mm-yyyy hh24:mi:ss') or
dt_end is null)
order BY LTE_DT_CREATION DESC;

BEGIN
lvc2_error_origin := 'V_LOG_TOTAL';

htp.p('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">');
htp.p('<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">');
htp.p('<head>');
htp.p('<meta name="generator" content="HTML Tidy for Windows (vers 22 March
2008), see www.w3.org" />');
htp.p('<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"
/>');
htp.p('<title>Performance ODI-Package</title>');
htp.p('<script type="text/javascript" src="js/paginate.js"></script>');
htp.p('<link href="css/tablecloth.css" rel="stylesheet" type="text/css"
media="screen" />');
htp.p('<script type="text/javascript" src="js/tablecloth.js"></script>');
htp.p('<script type="text/javascript"
src="js/datetimepicker_css.js"></script>');
htp.p('<link rel="stylesheet" href="css/style.css" type="text/css"
media="screen" />');

htp.p('</head>');
htp.p('<body>');
htp.p('<div>');
htp.p('<div id="container">');
htp.p(' <div id="header">');

03,
 /
!

htp.img('/Migration/images/logo.jpg');
htp.p(' </div>');
htp.p(' <div>');
htp.p(' <ul id="menu">');
htp.p(' <li class="trans">a</li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_Pkg" title="">Performance ODI-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.Perf_ODI_KM" title="">Performance ODI-
KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.v_odi_km">Validate ODI-KM</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_ODI_BD_Pkg" title="">Validate DB-
Package</a></li>');
htp.p(' <li><a href="http://alert-
mig/migra_25/VALIDATE_DMF_V25032.V_LOG_TOTAL" title="" class="current">Validate
Total Logs</a></li>');
htp.p(' </ul>');
htp.p(' </div>');
htp.p(' </div>');
htp.p(' <div id="content">');

htp.p('<h1>Validate ODI-KM</h1>');
htp.p('<p>');

htp.p('Oracle Data Integrator (ODI) includes Knowledge Modules (KMs) that are
components, which contain the information for ODI to perform a specific set of
tasks against a specific technology.');
htp.p('There are 6 different types of KMs, but in this area we will only
validate in detail the tasks in 2 different types:');
htp.p('<br/>');
htp.p(' LKM (Loading Knowledge Modules) are used to extract data from the
source database tables and other systems (files, middleware, mainframe, etc.).');
htp.p('<br/>');
htp.p(' IKM (Integration Knowledge Modules) are used to integrate (load) data
to the target tables.');
htp.p('</p>');
htp.p('<h2>Search</h2>');
htp.p('<form action="VALIDATE_DMF_V25032.v_odi_km" method="post">');
htp.p('Start Date/Time: <input type="text" name="dt_ini" id="startDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''startDate'',''ddmmyyyy'',''arrow'',true,24,false)"><im
g src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('End Date/Time: <input type="text" name="dt_end" id="endDate"
maxlength="25" readonly="readonly size="19" /><a
href="javascript:NewCssCal(''endDate'',''ddmmyyyy'',''arrow'',true,24,false)"><img
src="/Migration/images/cal.gif" alt="Pick a date" width="16" height="16"
class="calImg" /></a>');
htp.p('<input name="submit" type="submit" value="Search" class="but"/>');
htp.p('</form>');
htp.p('<div id="dataTable">');
htp.p('<table cellspacing="0" cellpadding="0" class="paginate-10 max-pages-
7">');
htp.p(' <tr>');
htp.p(' <th >DT_CREATION</th>');
htp.p(' <th >ERROR_TYPE</th>');
htp.p(' <th >ERROR_NUM</th>');
htp.p(' <th >ERROR_DESC</th>');
htp.p(' </tr>');

if submit = 'Search' and (dt_ini IS NOT NULL or dt_end IS NOT NULL) then
FOR i IN get_some_data LOOP
htp.p('<tr>');
htp.p(' <td>' ||
TO_CHAR(i.lte_dt_creation, 'YYYY-MM-DD HH24:MI:SS') ||

030
 /
!

'</td>');
htp.p(' <td>' || i.lte_error_type || '</td>');
htp.p(' <td>' || i.lte_error_num || '</td>');
htp.p(' <td>' || i.lte_error_desc || '</td>');
htp.p('</tr>');
END LOOP;
elsif dt_ini IS NULL and dt_end IS NULL then
FOR i IN get_data LOOP
htp.p('<tr>');
htp.p(' <td>' ||
TO_CHAR(i.lte_dt_creation, 'YYYY-MM-DD HH24:MI:SS') ||
'</td>');
htp.p(' <td>' || i.lte_error_type || '</td>');
htp.p(' <td>' || i.lte_error_num || '</td>');
htp.p(' <td>' || i.lte_error_desc || '</td>');
htp.p('</tr>');
END LOOP;
end if;
htp.p(' </table>');
htp.p(' </div>');
htp.p(' <div id="footer">In need of assistance please contact the <a
href="mailto:micaela.lima@alert.pt">migration team</a>. </div>');
htp.p(' </div>');
htp.p('</div>');
htp.p('</body>');
htp.p('</html>');

EXCEPTION
WHEN OTHERS THEN
var_result := 'Resultado com erro: ' || SQLCODE || ' -ERROR- ' ||
SQLERRM;
lvc2_error_title := var_result;
lvc2_level := 'ERR';
lvc2_error_desc := lvc2_error_origin || '-' || lvc2_error_title;
pk_ia_util.insert_error(lvc2_error_origin,
lvc2_error_title,
SQLERRM,
lvc2_error_desc,
lvc2_level);
END V_LOG_TOTAL;

end VALIDATE_DMF_V25032;
/

03+